NC tot nach Urgent security issue in NGINX/php-fpm

Ich habe auf meinem Raspberry Pi PHP auf Version 7.3.11 geupgradet und dann die hier empfohlenen Anpassungen in /etc/nginx/sites-enabled/default vorgenommen. Seither ist meine Nextcloud 17 mausetot. Ein Reboot des Rechners hat daran nichts geÀndert.

Wie kann ich den Fehler finden und beheben?

Wie bei jeder Fehlersuche ist es hilfreich einen Blick in die Logdateien zu werfen. Da Du Anpassungen an den nginx-Einstellungen vorgenommen hast wĂŒrde ich dort beginnen :wink:

1 Like

Ist das das richtige Logile?

/var/log/nginx/error.log

2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: still could not bind()

Ja, dies ist die richtige Datei, welche eindeutig das Problem ausweist: "bind () to 0.0.0.0:80 failed (98: Address already in use)". Stelle sicher, dass ein Zugriff auf Port 80/tcp nicht mehrfach in der Konfiguration existiert.

1 Like

Ohje. Das ĂŒberfordert meine beschrĂ€nkten Kenntnisse.

Muss ich dazu in /etc/nginx/sites-enabled/default etwas Àndern? Die Datei hat derzeit folgenden Inhalt:

upstream php-handler {
 #server 127.0.0.1:9000;
 server unix:/var/run/php/php7.3-fpm.sock;
}

server {
 listen 80;
 listen [::]:80;
 server_name v_______d.f_______y.com;
 # enforce https
 #return 301 https://$server_name$request_uri;
 root /var/www/html/;
}

server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 server_name v_______d.f_______y.com;

 ssl_certificate /etc/letsencrypt/live/v_______d.f_______y.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/vv_______d.f_______y.com/privkey.pem;

# Add headers to serve security related headers
 # Before enabling Strict-Transport-Security headers please read into this
 # topic first.
 add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
 #
 # WARNING: Only add the preload option once you read about
 # the consequences in https://hstspreload.org/. This option
 # will add the domain to a hardcoded list that is shipped
 # in all major browsers and getting removed from this list
 # could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;

# Path to the root of your installation
 root /var/www/html/;

# Add headers to serve security related headers
 # Before enabling Strict-Transport-Security headers please read into this
 # topic first.
 add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
 #
 # WARNING: Only add the preload option once you read about
 # the consequences in https://hstspreload.org/. This option
 # will add the domain to a hardcoded list that is shipped
 # in all major browsers and getting removed from this list
 # could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;

# Path to the root of your installation
 root /var/www/html/;

location = /robots.txt {
 allow all;
 log_not_found off;
 access_log off;
 }

# The following 2 rules are only needed for the user_webfinger app.
 # Uncomment it if you're planning to use this app.
 #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
 #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
 # last;

location = /.well-known/carddav {
 return 301 $scheme://$host/remote.php/dav;
 }
 location = /.well-known/caldav {
 return 301 $scheme://$host/remote.php/dav;
 }

# set max upload size
 client_max_body_size 512M;
 fastcgi_buffers 64 4K;

# Enable gzip but do not remove ETag headers
 gzip on;
 gzip_vary on;
 gzip_comp_level 4;
 gzip_min_length 256;
 gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
 gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+$

# Uncomment if your server is build with the ngx_pagespeed module
 # This module is currently not supported.
 #pagespeed off;

location / {
 rewrite ^ /index.php;
 }

location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
 deny all;
 }
 location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
 deny all;
 }

location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
 fastcgi_split_path_info ^(.+\.php)(/.*)$;
 try_files $fastcgi_script_name =404;
 include fastcgi_params;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 fastcgi_param PATH_INFO $fastcgi_path_info;
 fastcgi_param HTTPS on;
 #Avoid sending the security headers twice
 fastcgi_param modHeadersAvailable true;
 fastcgi_param front_controller_active true;
 fastcgi_pass php-handler;
 fastcgi_intercept_errors on;
 fastcgi_request_buffering off;
 }

location ~ ^/(?:updater|ocs-provider)(?:$|/) {
 try_files $uri/ =404;
 index index.php;
 }

# Adding the cache control header for js and css files
 # Make sure it is BELOW the PHP block
 location ~ \.(?:css|js|woff|svg|gif)$ {
 try_files $uri /index.php$uri$is_args$args;
 add_header Cache-Control "public, max-age=15778463";
 # Add headers to serve security related headers (It is intended to
 # have those duplicated to the ones above)
 # Before enabling Strict-Transport-Security headers please read into
 # this topic first.
 # add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
 #
 # WARNING: Only add the preload option once you read about
 # the consequences in https://hstspreload.org/. This option
 # will add the domain to a hardcoded list that is shipped
 # in all major browsers and getting removed from this list
 # could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;
 # Optional: Don't log access to assets
 access_log off;
 }

location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
 try_files $uri /index.php$uri$is_args$args;
 # Optional: Don't log access to other assets
 access_log off;
 }
}

Ich selbst nutze zwar kein Nginx, wĂŒrde aber sagen dass Du die genannte Zeile einmal auskommentieren solltest. Bitte auch direkt die weiter unten aufgefĂŒhrte Zeile mit dem Port 443 auskommentieren und danach den Server neu starten.

Bringt nichts. NC bleibt tot. Im Logfile hat sich (fast) nichts verÀndert:

2019/10/30 16:07:57 [emerg] 672#672: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 16:07:57 [emerg] 672#672: still could not bind()

Bitte vor einem neuen Startversuch unbedingt prĂŒfen, ob nicht ein anderer Dienst bereits auf Port 80/tcp hört: netstat -alpn | grep ":80"
Falls wirklich kein anderer Dienst lÀuft muss es eine weitere, fehlerhafte Konfigurationszeile gebe. Was findest Du denn in Zeile 98 Deiner Konfiguration?
Eventuell gibt es auch eine weitere Konfigurationdatei in welcher versucht wird Port 80/tcp zu belegen. grep ":80" /etc/nginx/sites-enabled/*

1 Like
sudo netstat -alpn | grep ":80"
tcp6       0      0 :::80                   :::*                    LISTEN      673/apache2

Interpretiere ich das richtig? Bei mir lĂ€uft außer nginx noch ein Apache, der ebenfalls auf den Port 80 zugreift. Aber warum lĂ€uft da plötzlich ein Apache herum, der vor dem PHP-Update nicht aktiv war?

Oder ist meine Interpretation falsch?

So sieht es scheinbar aus. Beende doch einmal den apache2 Webserver und versuche dann Nginx zu starten. Falls dies klappt kannst Du im Anschluss ja wieder mit den zuvor auskommentierten EintrÀgen experimentieren :wink:

1 Like

NextCloudPi v1.18.0 released

sic


Wird denn bitte NextCloudPi verwendet oder aber stattdessen nur eine andere Standardumgebung von Linux auf einem Pi-Rechner?

Es tut mir leid, von diesem sicherlich Ă€rgerlichen Fehlerumstand zu hören. Und natĂŒrlich mag ich mich irren. Leider kann ich, auch mangels eigener Erfahrung mit dem tatsĂ€chlichen Umgang bei Nextcloud auf Pi-Rechnern, auch nicht wirklich groß helfen.

Zu beachten ist allerdings (und bei Nachlesen der oben von mir angefĂŒhrten Dokumente auch vielleicht nachvollziehbar) daß man anscheinend gehörig aufpassen muss, um nicht Ă€rgerlichen MissverstĂ€ndnissen zum Opfer zu werden:

  1. Bei NextCloudPi sollte man auf keinen Fall allgemeine RatschlĂ€ge aus anderen Linux-Paketen zu Software-Aktualisierungen (wie z.B. das sonst ĂŒbliche apt-Kommando) ohne kritische PrĂŒfung (und wenn ob ĂŒberhaupt) verwenden. NextCloudPi hat dazu ganz offensichtlich zwei besondere Befehle ncp-update und ncp-dist-upgrade, die man unbedingt nutzen sollte, damit die speziellen Anforderung fĂŒr Pi-Rechner ĂŒberhaupt erst erfĂŒllt werden können.
  2. Das “angebliche” Problem von ‘NGINX/php-fpm’ dĂŒrfte bei NextCloudPi eigentlich ĂŒberhaupt keine Rolle spielen, weil nĂ€mlich (aus guten GrĂŒnden) stattdessen Apache 2.4 als Web-Server verwendet wird, womit die Dinge bekanntlich ganz anders laufen.

Soweit dazu.

Zur allgemeinen Beachtung:
Bei anderen Installierungen (z.B. Debian, Ubuntu, ArchLinux etc.) und bei (wie auch immer) entstandenen abweichenden (z.B. “selbstgestrickten” ?) Konfigurierungen ist ohne Frage mit den beschriebenen Problemen durch NGINX zu rechnen und mĂŒssen diese auch zielfĂŒhrend gelöst werden.

Sorry for your mishap.

Hope this helps.
:smile:

Nein. Meine Konfiguration beschrieb ich im Ausgangspost. Im Prinzip bin ich nach dieser Anleitung vorgegangen.

Ich habe jetzt mal mutig den Apachen gestoppt.

sudo systemctl stop apache2.service

Und dann nginx gestartet.

sudo systemctl restart nginx.service

Jetzt lÀuft meine Nextcloud wieder.

Wo und wie kann ich herausfinden, wer den Apachen gestartet hatte und fĂŒr die Zukunft verhindern, dass das wieder passiert?

Nun ja, nicht so ganz vollstÀndig leider.

Wie war das oben noch geschrieben?
:smirk:

:smirk_cat:

Da fehlte wohl noch so einiges an Information, daher ja auch meine vorsichtige Frage. Abw es macht ja nix, nur in Zukunft bitte vielleicht etwas mehr auf die technischen Details achten.

Übrigens könnte die NC Issue Template App vielleicht helfen, etwas mehr Informationen anzugeben, wenn man mal etwas mehr Hilfe bei Nextcloud braucht. In diesem Fall natĂŒrlich völlig zwecklos, weil NC ja “tot” war.

@vatolin Na das hört sich doch gut an. Gratuliere.
:+1:

NB Eine kleine Geste der Zufriedenheit als ein “dieser Beitrag gefĂ€llt mir” (mit einem Klick auf das Herz :heart: am unteren Rand) bei einem oder mehreren meiner obigen BeitrĂ€ge wĂŒrde mich freuen. Der Applaus wĂ€re (nicht nur aber auch fĂŒr mich) ein schöner Dank und schon genug Motivation fĂŒr kĂŒnftige Ă€hnliche Hilfestellungen

:smiley:

Der Apache-Webserver gehört zum Standardrepertoire von Debian und wird meistens gleich mit installiert, wenn man nicht von Anfang an streng auf eine Mininimalaustatttung setzt. Zum “wer” einfach mal in den Spiegel schauen? Zum “wie” wĂŒrde ich mir keine großen Gedanken machen, ist halt mal passiert.

Die apt-Paketverwaltung hilft ĂŒblicher Weise weiter.

Mit apt list apache2* nach den entsprechenden Paketen aus dem Apache-Umfeld schauen. Es werden mehr Pakete angezeigt, als tatsÀchlich installiert sind. Die wirklich installierten Pakete aber haben ein [installiert 
 ] bzw. [installed 
] am Zeilenende in der erzeugten Liste stehen.

Danach mit apt remove apache2 (also ohne ‘*’) den Hauptteil wegrĂ€umen, damit es nicht irrtĂŒmlich nochmals von vorne los geht. Nochmals mit apt list apache2* nachschauen und sofern noch etwas ĂŒbrig geblieben sein sollte, diese weiteren Pakete dann einzeln mit dem entsprechenden Namen und vorangestelltem apt remove ... löschen.

Mit apt purge apache2 kann man die Reste grĂŒndlich auskehren, muss man aber nicht.

Viel GlĂŒck!
:four_leaf_clover:

1 Like

Oha. Da hast Du in der Tat recht. Hab ich vor Schreck, dass die Cloud offline war, glatt vergessen.

Danke fĂŒr die zielfĂŒhrende Hilfestellung.

1 Like