Beiträge von TCRserver

Zitat von kk

Die Preview wurde eben auf Version v2.5.0-r4692 aktualisiert. Damit wird die NGINX-Konfiguration verbessert:

• falls NGINX durch LiveConfig verwaltet wird, dann wird während des Upgrades eine Datei namens /etc/nginx/conf.d/resolver.conf angelegt. Diese enthält die DNS-Resolver (aus /etc/resolv.conf).
  NGINX löst ansonsten alle Hostnamen (z.B. für Reverse-Proxy URLs) nur einmalig (beim Start/Reload) auf - auf den System-Resolver kann NGINX aus Architekturgründen nicht zurückgreifen...

Hallo Herr Keppler,

anscheinend wird die resolver.conf Datei falsch angelegt.
Beim starten des NGINX wird folgender fehler geworfen:

Zitat

# systemctl status nginx.service
* 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 Mon 2017-10-02 08:29:14 CEST; 13s ago
Docs: man:nginx(8)
Process: 2577 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

Okt 02 08:29:14 s7 systemd[1]: Starting A high performance web server and a reverse proxy server...
Okt 02 08:29:14 s7 nginx[2577]: nginx: [emerg] invalid port in resolver "2a01:4f8:0:a0a1::add:1010" in /etc/nginx/conf.d/resolver.conf:11
Okt 02 08:29:14 s7 nginx[2577]: nginx: configuration file /etc/nginx/nginx.conf test failed
Okt 02 08:29:14 s7 systemd[1]: nginx.service: Control process exited, code=exited status=1
Okt 02 08:29:14 s7 systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Okt 02 08:29:14 s7 systemd[1]: nginx.service: Unit entered failed state.
Okt 02 08:29:14 s7 systemd[1]: nginx.service: Failed with result 'exit-code'.

Alles anzeigen

Die von LiveConfig erzeugte resolv.conf ist wie folgt aufgebaut:

resolver 213.133.98.98 213.133.99.99 213.133.100.100 2a01:4f8:0:a0a1::add:1010 2a01:4f8:0:a102::add:9999 2a01:4f8:0:a111::add:9898;

Laut der (an dieser Stelle etwas verwirrenden) NGINX Doku müssen aber die IPv6 Adressen geklammert werden:

Zitat

Configures name servers used to resolve names of upstream servers into addresses, for example:
resolver 127.0.0.1 [::1]:5353;

Danach startet NGINX wieder ohne Probleme.

Hallo Hr. Keppler,

mit v2.5.0-r4692 tritt bei mir bei Verwendung von Apache über einen NGINX Reverse Proxy der Fehler auf, dass die gewählte PHP Version nicht verwendet wird. Statt dessen wird die Systemweite PHP7 Version verwendet.

Sobald ich den Webspace von Apache/NGINX Reverse Proxy auf NGINX ohne Reverse Proxy umschalte, wird wieder die gewählte PHP Versipon verwendet.

Zitat von kk

Wir haben nun auch PHP 7.0 für Stretch und Wheezy aktualisiert. Falls es noch irgendwo hakt, bitte kurz melden.

Funktioniert jetzt auch bei Stretch und Wheezy. Danke!

Das Problem besteht anscheinend auch noch bei Debian Wheezy.
Hier zeigt mir APT als aktuelle Version 7.0.23-1+wheez an und die Abhängigkeiten sind hier auch wieder nicht auflösbar.

Zitat

root@v1-wheezy ~ # apt-cache depends php-7.0-opt
php-7.0-opt
Hängt ab von: libbz2-1.0
Hängt ab von: libc-client2007e
Hängt ab von: libcurl3
Hängt ab von: libfreetype6
Hängt ab von: <libgd3>
Hängt ab von: <libicu55>
Hängt ab von: libjpeg8
Hängt ab von: libkeyutils1
Hängt ab von: libmcrypt4
Hängt ab von: libpng12-0
Hängt ab von: libsqlite3-0
Hängt ab von: libssl1.0.0
Hängt ab von: libxml2
Hängt ab von: libxslt1.1
Hängt ab von: zlib1g
Kollidiert mit: <none>
Ersetzt: <none>

Alles anzeigen

Bei Debian Stretch scheint auch ein fehlerhaftes Paket hinterlegt zu sein.
Hier zeigt er als aktuelle Version 7.0.23-1+xenia an.

Kann es sein, dass die Pakete noch irgendwo auf einem Quell Server in einem Cache sind?
Den Stretch Server habe ich gerade eben neu als virtuellen Server aufgesetzt. Der dürfte noch keinen eigenen Cache gehabt haben.

Hat funktioniert, Danke!

Dachte ich auch zuerst, aber es ist jessie ausgewählt und es passiert auf allen Servern.
Vor dem update der Listen ist die Abhängigkeit libicu52 und nach dem Update libicu55.

Zitat

root@v7 ~ # apt-cache depends php-7.0-opt
php-7.0-opt
Hängt ab von: libbz2-1.0
Hängt ab von: libc-client2007e
Hängt ab von: libcurl3
Hängt ab von: libfreetype6
Hängt ab von: libgd3
Hängt ab von: libicu52
Hängt ab von: <libjpeg62>
libjpeg62-turbo
Hängt ab von: libkeyutils1
Hängt ab von: libmcrypt4
Hängt ab von: libmhash2
Hängt ab von: libpng12-0
Hängt ab von: libsqlite3-0
Hängt ab von: libssl1.0.0
Hängt ab von: libxml2
Hängt ab von: libxslt1.1
Hängt ab von: zlib1g
Kollidiert mit: <none>
Ersetzt: <none>

Alles anzeigen

Zitat

root@v7 ~ # apt-cache depends php-7.0-opt
php-7.0-opt
Hängt ab von: libbz2-1.0
Hängt ab von: libc-client2007e
Hängt ab von: libcurl3
Hängt ab von: libfreetype6
Hängt ab von: libgd3
Hängt ab von: <libicu55>
Hängt ab von: <libjpeg8>
Hängt ab von: libkeyutils1
Hängt ab von: libmcrypt4
Hängt ab von: libpng12-0
Hängt ab von: libsqlite3-0
Hängt ab von: libssl1.0.0
Hängt ab von: libxml2
Hängt ab von: libxslt1.1
Hängt ab von: zlib1g
Kollidiert mit: <none>
Ersetzt: <none>

Alles anzeigen

Kann es sein, dass beim zusammenstellen der Test Repos für Debian ein Fehler passiert ist?

Bei unserem Test System (Debian Jessie) will er PHP7.0-OPT deinstallieren weil eine Abhängigkeit zu libicu55 und libjpeg8 nicht erfüllt ist.

Zitat

- wenn BIND mit NAT IPs konfiguriert wurde, enthielt die "interfaces"-Option die NAT-IPs statt der physikalischen IPs

Mit der neuen Lab Version 2.4.0 (r4598) funktioniert es jetzt korrekt.
Danke fürs umsetzen!

Zitat von kk

Was genau funktioniert denn bei Ihnen nicht?
In unseren Testszenarien klappt nämlich alles, und ein paar Kunden nutzen dieses Feature erfolgreich im Produktivbetrieb.

Es ist lediglich deshalb noch nicht offiziell dokumentiert, weil wir das Bearbeiten der IPs noch über die GUI ermöglichen möchten (damit niemand in die DB eingreifen muss).

Viele Grüße

-Klaus Keppler

Alles anzeigen

Für einen vServer (Hetzner mit NAT) habe ich unter IPS.IP_NAT die öffentliche IP Adresse eingetragen und unter IP_ADDRESS steht die von LC erkannte private IP Adresse (172.31.1.100).
Wenn ich jetzt den Server neu konfiguriere, wird aber bei Bind9 in die 'named.conf.options' die öffentliche IP-Adresse geschrieben und nicht die private IP Adresse.
Somit hört Bind auf die falsche IP Adresse und ist nicht von außen erreichbar.

Zitat von Benni-chan

Wo und wie kann man denn die IP fürs NAT einstellen?

Noch gar nicht. Die Funktion ist bisher nur vorbereitet worden. In der DB gibt es eine neue Spalte 'IPS.IP_NAT', dort werden zukünftig die IP's eingetragen. Man kann die Spalte schon händisch füllen (absolut nicht zu empfehlen, händisch in der LC DB herum zu operieren!) und dann funktioniert ein Teil von der NAT Umsetzung schon. Was definitiv noch nicht funktioniert ist die korrekte Serverkonfiguration von z.B. Bind9. Somit ist die Funktion bisher nur sehr eingeschränkt nutzbar

Wenn ich mich richtig erinnere, dann könnte hier Spamassassin nicht installiert oder nicht konfiguriert sein.
Gibt es die Datei /var/run/lcsam.sock überhaupt?

Bei uns kann ich den Fehler nicht nachvollziehen.
Alle Domains die ich überprüft habe, sind mit einem gültigen MX Record versehen.

Allerdings hatten wir auch auf allen Servern (Debian 8.7) schon seit Monaten die Lab-Version im Einsatz.

Dürfte nicht funktionieren, da die Server Dienste wie z.B. Apache ja auf die 172.31.... konfiguriert werden müssen. Und LC verwendet für die Zone automatisch die Server IP Adresse.

Zitat von HBO

Na dann mal anders rum, wenn die korrekte öffentliche IP bekannt ist wieso diese nicht als Fake IP in der VM mit irgendeiner Konfiguration anlegen nur damit LC diese erkennt und in den Einstellungen vorhanden ist um genutzt zu werden?

Die ist ja nicht bekannt! Zumindest nicht innerhalb von LC oder deinem Server.
Deswegen entsteht ja dieser Bug, weil LC bsp. bei Debian die /etc/network/interfaces ausliest und anhand dieser deine IP's ermittelt. Und da steht bei neueren Hetzner VM's eben die 172.31... drin.

LC braucht ein zusätzliches eingabe Feld z.B. unter Serververwaltung wo du die reale IP eintragen kannst und dann alle möglichen Konfig und Zonefiles dementsprechend korrekt generiert werden.

Das Problem haben wir auch. Die beste Lösung ist hierfür im LC die IP Adresse manuell konfigurieren und nicht die 172.31.... von LifeConfig.

LiveConfig > Domains > SubDomains bearbeiten > Eigene DNS Einträge
Dort einen A und ggf. einen AAAA Eintrag erstellen und dann den Haken bei "keine automatischen A/AAAA-Einträge für den Webspace anlegen" anklicken.

Somit ist das Problem erstmal bis zu einem IP wechsel des Servers gelöst.

Hallo Herr Keppler,

auf dem Server den es gestern getroffen hat läuft je Kunde nur ein einziges PHP Skript welches eine Weiterleitung macht.
Ansonsten läuft dort eine Gunicorn Instanz mit einer Django (Python) Seite.
Zusätzlich hat der NGINX noch die Aufgabe die statische Dateien wie Bilder, CSS usw. auszuliefern, muss dazu aber auch kein PHP verarbeiten.

Trotzdem stirbt immer mal wieder ein einzelner FCGI Prozess und legt damit den ganzen Webspace lahm.
Arbeitstsspeicher und andere Resourcen sind noch reichlich frei und es gibt auch keine entsprechende Meldung im Syslog.

Bei uns stirbt auch immer wieder mal ein einzelner nginx-php-fcgi Prozess.

Logfile:

2016/07/26 11:43:29 [error] 26843#0: *8794 connect() to unix:/var/www/feuerdbt/conf/sockets/nginx-php-fcgi.php56.sock failed (111: Connection refused) while connecting to upstream, client: 213.153.79.45, server: www.xxxxxx.de, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/www/feuerdbt/conf/sockets/nginx-php-fcgi.php56.sock:"

Diag:

# liveconfig --diag
Running OS diagnostics... (LiveConfig 2.2.0-r4254)


 - Found 'nginx' web server
   Version: '1.6.2'
   Package version: '1.6.2-5+deb8u2'
   SNI support: yes
 - PHP 5.3.29 (code='php53', bin='/opt/php-5.3/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/opt/php-5.3/etc/php.ini'
 - PHP 5.5.38 (code='php55', bin='/opt/php-5.5/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/opt/php-5.5/etc/php.ini'
 - PHP 5.6.24 (code='php56', bin='/opt/php-5.6/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/opt/php-5.6/etc/php.ini'
 - PHP 5.6.23 [DEFAULT] (code='php5', bin='/usr/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/etc/php5/cgi/php.ini'

Wir haben auch die Probleme mit FileZilla und proFTP...

Aber zum Dienste entfernen gibt es doch von Hr. Keppler eine Anleitung:
https://www.liveconfig.com/de/…=5477&viewfull=1#post5477

Ist zwar für NGINX/Apache gemacht funktioniert aber vermutlich auch mit proFTP.

Wir verwenden dieses Script https://github.com/frdmn/LiveC…ter/nginx_post_vhost_hook von frdmn um Domainspezifische Änderungen an den Konfigurationen zu machen.

Die Mails haben wir auch für alle auslaufenden Zertifikate bekommen.

Wird evtl. mit LC 2.1 gefixt?

Zitat

Let's Encrypt: auslaufende Zertifikate werden automatisch 30 Tage vor Ablauf verlängert und auf den Webservern ersetzt (für Mail/FTP wird das auch in Kürze automatisch erfolgen, ist aber noch in Arbeit).