Since the February 13th update I can't connect to the server, Radio always works.
Safari cannot open the page "? 217.182.128.137" because Safari cannot connect to the server "217.182.128.137".
@ckeurk Nginx was updated back to its normal latest version without nchan integrated, so it's possible things didn't restart correctly. Try running service nginx restart and see if that helps?
Doesn't work.
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
â nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since mer. 2018-02-14 06:26:26 CET; 5min ago
Process: 17893 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
@ckeurk Seems nchan wrote a configuration that the old nginx doesn't like. Working on it right now.
Ok Thank you ;)
@ckeurk Newest push should force a proper configuration file into the nginx root...try it out!
always the same problem : Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since mer. 2018-02-14 07:15:20 CET; 24s ago
Process: 13616 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
févr. 14 07:15:20 vps407479 systemd[1]: Starting A high performance web server and a reverse proxy server...
févr. 14 07:15:20 vps407479 nginx[13616]: nginx: [emerg] unknown directive "nchan_publisher" in /etc/nginx/sites-enabled/00-azuracast:7
févr. 14 07:15:20 vps407479 nginx[13616]: nginx: configuration file /etc/nginx/nginx.conf test failed
févr. 14 07:15:20 vps407479 systemd[1]: nginx.service: Control process exited, code=exited status=1
févr. 14 07:15:20 vps407479 systemd[1]: Failed to start A high performance web server and a reverse proxy server.
févr. 14 07:15:20 vps407479 systemd[1]: nginx.service: Unit entered failed state.
févr. 14 07:15:20 vps407479 systemd[1]: nginx.service: Failed with result 'exit-code'.
@ckeurk The latest update script should be forcing that file to be the correct new version. I've verified on my local install that it's doing that correctly; I'm not sure why your updater isn't doing that.
Try running ./update.sh --full or just manually replace /etc/nginx/sites-enabled/00-azuracast with:
client_max_body_size 50M;
server {
listen 80;
listen 443 default_server ssl;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
root /var/azuracast/www/web;
index index.php;
server_name localhost;
add_header X-XSS-Protection 1;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
access_log /var/azuracast/www_tmp/access.log;
error_log /var/azuracast/www_tmp/error.log;
location / {
try_files $uri @clean_url;
}
location @clean_url {
rewrite ^(.*)$ /index.php last;
}
location ~ \.php$ {
fastcgi_hide_header Cache-Control;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
# NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/azuracast/www/web$fastcgi_script_name;
include fastcgi_params;
fastcgi_read_timeout 1800;
}
# Reverse proxy all possible radio listening ports (8000, 8010...8480, 8490)
location ~ ^/radio/(8[0-4][0-9]0)(/?)(.*)$ {
proxy_buffering off;
proxy_ignore_client_abort off;
proxy_intercept_errors on;
proxy_next_upstream error timeout invalid_header;
proxy_redirect off;
proxy_connect_timeout 60;
proxy_send_timeout 21600;
proxy_read_timeout 21600;
proxy_set_header Host localhost:$1;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://127.0.0.1:$1/$3;
}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
location ~ /\.ht {
deny all;
}
}
@ckeurk I need to get to sleep so I can't keep working on diagnosing this tonight; try those out and let me know if they helped.
To modify the file you're asking me for "replace /etc/nginx/sites-enabled/00-azuracast", I can't because no software even textwrangler (I'm on Mac) can open it.
Hello !! After update full, removing of all blocks containing "nchan" in the nginx config file seems to work. But how to be sure it don't break my installation ?
I do not understand why I should even delete "nchan" ? What does it even give except problems?
Don't know :smile: But it worked for me. I did not do reverse engineering. Probably only @SlvrEagle23 can reply to this at now. nchan components removed from Nginx ? Or need to be loaded differently ?
For the moment he sleeps the answer arrives in not long. đ
Yup, no problem, it's not urgent in our case.
Good morning all! Explaining time. @FrBillyD @ckeurk @susl16c
At one point, I was getting complaints that the updates to the "now playing" data on the web site didn't always line up very well with when the actual song title had changed on the radio station. I wanted to streamline that entire stack, so I added a ping tool that monitors the station for changes (station-watcher), more responsive updates to the now-playing manager, and a frontend tool called nchan that allowed live, websocket-based updates to the now-playing data on the client side.
Unfortunately, it turns out nchan not only doesn't build binaries for ARM processors (meaning as long as I used it, Raspberry Pi's were out of the question) but it requires that I use prepackaged copies of nginx that are missing some crucial security fixes, especially in light of the recent spectre/meltdown situation.
Fortunately, the other changes I mentioned are actually sufficient to produce more response, faster "now playing" updates that line up better with the actual song changes on the station, so nchan isn't really needed.
The latest updates have been trying to remove it cleanly from traditional installs. It's already removed from Docker installs, and there were no problems in that transition (since it's easier to do things like this in Docker). I've pushed out another update today that should do a "harder" removal of the old nginx and install the new one more cleanly.
In the event that even the latest fix doesn't work, the copy of nginx being used now is just the updated version straight from the Ubuntu 16.04 repos, so you could just as well install it via apt-get install nginx if you wanted.
Hope that answers some questions!
Great, it's working again thanks.
Most helpful comment
Great, it's working again thanks.