Best way to install FW on a Raspberry Pi?


#41

Did I say thanks in advance to all.


#42

@d

You can safely ignore this error, it’s due to a guenuine bug in Python 3.5 but that’s not affecting anything :slight_smile:

This one likely happpens because there is nothing to play in the radio (the error handling is quite bad here). Do you have any favorites / music to play on your instance?

It’s the client trying to connect to the websocket endpoint, retrying in case of failure. It may indicate that something websocket related is not working properly

The server was down last night, which explain the error. You can visit /api/admin/music/libraryscan/ to delete the failed scan and relaunch a new one :slight_smile:


#43

Issue 1 (migrate) - Ok, thanks for the clarification.

Issue 2 (Radios) - I have 18 tracks (Bruce Spring…) in my library. You were correct I had no favorites… So I added a few favorites and Radio favorites and Random work fine. When I try Less Listened nothing happens ? I have listened to all 18 tracks so does that imply less listened radio will not work?

Issue 3 (Websocket endpoint) - ignore for the moment as I don’t have the skills to troubleshoot… are there any CLI commands I can run to check what is going on?

Issue 4 (Remote Libraries). Deleted library scans that had failed. I now have this pending job? when will this start/complete execution? In general is there any doco with a list of remote libraries that I can
subscribe too?

As always thanks in advance.


#44

Issue 2 (Radios)… Ignore my previous ramblings on the topic. Further clarification. With no radios playing and I hit Less Listened radio on the left side of the screen the system tells me “You have a radio playing” I obviously do not. I will provide before and after screenshots.

!


#45

You can delete all of them and relaunch a scan from the UI (or in /api/admin/music/library/, by checking the one you want to scan and select scan in the actions :slight_smile: There is no list of public libraries you can follow, but we intend to make this easier to discover in future releases.

I don’t have anything easy to offer you right now, sorry :confused: What if you refresh completely the page, do those logs still appear?


#46

Issue 4 (Remote Libraries)…I have deleted and started again but still no joy…Is there another remote library
I could try? As this is public I presume there are no permissions? Is the library always online? I am stumped.


#47

Is your funkwhale-worker.service service up and running? You can check with sudo journalctl -xn -u funkwhale-worker.


#48

Hi Eliot,
Firstly – would you and @dmurphydrtc mind moving Dave’s questions to a new topic? It seems to me his questions are a bit different from mine – although I might bump into the same issues as him down the line :slight_smile:

Update: my Pi is now finally accessible from the outside world! Woohoo!
Thanks for your help in this.

You suggest that I remove the “default host” – I suppose you’re referring to the 000-default.conf virtual host file located in /etc/apache2/sites-available , right?
I have tried doing that, and made sure that the only .conf file that could be triggered was funkwhale.conf.
However, even after restarting Apache, when visiting my server IP, I still fall onto the Apache2 Debian Default Page…

In a previous reply, you mentioned:

I realise now I haven’t actually “converted” the nginx file at all – because I’m not sure how to do this… (Currently, my Apache funkwhale.conf file is basically the template you made available online, with the Define funkwhale-sn variable set to my funkwhale server URL.) The Nginx and Apache .conf file structures seem widely different… and I fail to find much help online on this. Could this be the source of the issue?

==
(EDITED from 5 min ago)


#49

We’ll move the discussion somewhere else, sorry for the noise!

Yes, I was referring to this one. If it’s not present anymore, and you still get the apache default page, I’m not sure what else you can do though :s

Yeah, ths template is a bit out of date, but I think @renon got it working recently, so maybe he’ll be able to help here?


#50

Sorry for the late answer.

@daoyang : Can you give me your Apache conf file ?

Also, don’t forget to symlink the conf you have in sites-available to sites-enabled to actually load the conf.


#51

Hi Eliot,
I found the root cause of my problems!
As often, it was a stupid detail… Namely, I forgot to forward port 443 on my router (duh), so https traffic wasn’t going through. And I cannot do this until I go back to my flat, in February…

You mentioned on another thread that using http is not recommended, and might cause issues. So is it really not possible?

Just in case, I’m trying my luck with the unsafe protocol.

So I commented out anything to do with https on my funkwhale.conf and also changed ‘https’ to ‘http’ in the .env file – and now I finally see the Funkwhale interface appear! Hallelujah!! :champagne:

… However… I cannot log in using the superuser I defined during the install :joy:
I get the error:

“An unknown error happend, this can mean the server is down or cannot be reached”

(see screenshot)

15%20PM
Screen Shot 2019-01-11 at 7.32.15 PM.jpg1120x476 44.2 KB

This is what my funkwhale error log says:
[Fri Jan 11 18:27:54.323055 2019] [proxy:warn] [pid 4913:tid 1915745328] [client 86.193.35.78:53866] AH01144: No protocol handler was valid for the URL /api/v1/instance/settings/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule., referer: http://<url>/login
[Fri Jan 11 18:27:54.331260 2019] [proxy:warn] [pid 4914:tid 1865413680] [client 86.193.35.78:53862] AH01144: No protocol handler was valid for the URL /api/v1/instance/nodeinfo/2.0/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule., referer: http://<url>/login
[Fri Jan 11 18:28:01.328667 2019] [proxy:warn] [pid 4914:tid 1882190896] [client 86.193.35.78:53869] AH01144: No protocol handler was valid for the URL /api/v1/token/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule., referer: http://<url>/login

… but still no joy.

Maybe I’ve missed another setting having to do with the https protocol somehow?

EDIT: When I try systemctl status funkwhale-server.service, I get the following:
Invalid HTTP_HOST header: '<url>'. You may need to add '<url>' to ALLOWED_HOSTS.

However, I already added this url to the DJANGO_ALLOWED_HOSTS in my .env file. Hmm.


#52

It is possible and it should work. Butt it’s really not recommended if you plan to connect to other servers using the federation :slight_smile:

If you’re accessing your instance using http://yourdomain.com, you need to have DJANGO_ALLOWED_HOSTS=yourdomain.com in your env file (no need for the protocol, just the domain name). Does if fail again if you fix that and restart your server?


#53

Yep, I’ll definitely enable https as soon as I can!

I did make sure my domain name is written after DJANGO_ALLOWED_HOSTS in the env file…

Whenever I try logging in, the “loading” circle keeps spinning in the green box “Login” box. I cannot create a new account either (another spinning wheel)


#54

Yes, this is because the server likely answer with an error. You can confirm that by reading the server logs (journalctl -xnf -u funkwhale-server.service).

Can you please share the content of your apachae virtualhost? It feels like the X-Forwarded-Host header is somehow missing, hence the Invalid HTTP_HOST header: '<url>'. You may need to add '<url>' to ALLOWED_HOSTS Invalid HTTP_HOST header: '<url>'. You may need to add '<url>' to ALLOWED_HOSTS. message. But it’s weird, do both domain names match in this message?


#55

I just get the error message “Failed to parse lines 'f'” when trying this command…

Here’s my funkwhale.conf virtualhost file:

# Following variables MUST be modified according to your setup
Define funkwhale-sn <url>

# Following variables should be modified according to your setup and if you
# use different configuration than what is described in our installation guide.
Define funkwhale-api http://localhost:5000
Define funkwhale-api-ws ws://localhost:5000
Define MUSIC_DIRECTORY_PATH /srv/funkwhale/data/music

# HTTP requests redirected to HTTPS
# <VirtualHost *:80>
   # ServerName ${funkwhale-sn}

   # Default is to force https
   # RewriteEngine on
   # RewriteCond %{SERVER_NAME} =${funkwhale-sn}

   # <Location "/.well-known/acme-challenge/">
     # Options None
     # Require all granted
   # </Location>
   # RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
# </VirtualHost>


# <IfModule mod_ssl.c>
<VirtualHost *:80>
   ServerName ${funkwhale-sn}

   # Path to ErrorLog and access log
   ErrorLog ${APACHE_LOG_DIR}/funkwhale/error.log
   CustomLog ${APACHE_LOG_DIR}/funkwhale/access.log combined

   # TLS
   # Feel free to use your own configuration for SSL here or simply remove the
   # lines and move the configuration to the previous server block if you
   # don't want to run funkwhale behind https (this is not recommended)
   # have a look here for let's encrypt configuration:
   # https://certbot.eff.org/lets-encrypt/debianstretch-apache.html
   # SSLEngine on
   # SSLProxyEngine On
   # Include /etc/letsencrypt/options-ssl-apache.conf

   # Tell the api that the client is using https
   # RequestHeader set X-Forwarded-Proto "https"

   DocumentRoot /srv/funkwhale/front/dist

   FallbackResource /index.html

   # Configure Proxy settings
   # ProxyPreserveHost pass the original Host header to the backend server
   ProxyVia On
   ProxyPreserveHost On
   <IfModule mod_remoteip.c>
      RemoteIPHeader X-Forwarded-For
   </IfModule>

   # Turning ProxyRequests on and allowing proxying from all may allow
   # spammers to use your proxy to send email.
   ProxyRequests Off

   <Proxy *>
      AddDefaultCharset off
      Order Allow,Deny
      Allow from all
   </Proxy>

   # Activating WebSockets
   ProxyPass "/api/v1/instance/activity" ${funkwhale-api-ws}/api/v1/instance/activity

   <Location "/api">
      # similar to nginx 'client_max_body_size 30M;'
      LimitRequestBody 31457280

      ProxyPass ${funkwhale-api}/api
      ProxyPassReverse ${funkwhale-api}/api
   </Location>
   <Location "/federation">
      ProxyPass ${funkwhale-api}/federation
      ProxyPassReverse ${funkwhale-api}/federation
   </Location>

   # You can comment this if you don't plan to use the Subsonic API
   <Location "/rest">
      ProxyPass ${funkwhale-api}/api/subsonic/rest
      ProxyPassReverse ${funkwhale-api}/api/subsonic/rest
   </Location>

   <Location "/.well-known/">
      ProxyPass ${funkwhale-api}/.well-known/
      ProxyPassReverse ${funkwhale-api}/.well-known/
   </Location>

         Alias /media /srv/funkwhale/data/media

Alias /staticfiles  /srv/funkwhale/data/static

   # Setting appropriate access levels to serve frontend
   <Directory "/srv/funkwhale/data/static">
      Options FollowSymLinks
      AllowOverride None
      Require all granted
   </Directory>

   <Directory /srv/funkwhale/front/dist>
      Options FollowSymLinks
      AllowOverride None
      Require all granted
   </Directory>

   <Directory /srv/funkwhale/data/media>
      Options FollowSymLinks
      AllowOverride None
      Require all granted
   </Directory>

   # XSendFile is serving audio files
   # WARNING : permissions on paths specified below overrides previous definition,
   # everything under those paths is potentially exposed.
   # Following directive may be needed to ensure xsendfile is loaded
   #LoadModule xsendfile_module modules/mod_xsendfile.so
   <IfModule mod_xsendfile.c>
      XSendFile On
      XSendFilePath /srv/funkwhale/data/media
      XSendFilePath ${MUSIC_DIRECTORY_PATH}
      SetEnv MOD_X_SENDFILE_ENABLED 1
   </IfModule>
   # SSLCertificateFile /etc/letsencrypt/live/ioupi.zapto.org/fullchain.pem
   # SSLCertificateKeyFile /etc/letsencrypt/live/ioupi.zapto.org/privkey.pem
</VirtualHost>
# </IfModule>

Yep, both URLs here are the public domain name that I set in my .env and funkwhale.conf files


#56

does adding RequestHeader set X-Forwarded-Host "yourhostname" and restarting apache changes anything?


#57

Alas, nope… I also tried uncommenting RequestHeader set X-Forwarded-Proto and changing https into http, but still no joy.
Do you think this issue could be due to my not using https? Or is it something more troublesome?


#58

Possibly, but it’s really hard to tell since I’m really not well-versed into apache :confused:
I’m sorry, I’m running out of ideas for now :frowning: