Danke für die Info!
Ich hab schon an mir gezweifelt, als ich das Feld gesucht und nicht gefunden habe.
Danke für die Info!
Ich hab schon an mir gezweifelt, als ich das Feld gesucht und nicht gefunden habe.
In der Prview 2.5.3 gibt es ein Problem mit der PHP Versions Auswahl.
Nachdem ich einen neuen Vertrag angelegt und eine Domain zugewiesen habe, erscheint das Dropdown Menü für die PHP Versionsauswahl nicht.
Wenn ich den Vertrag händisch bearbeite und nur das Feld "abweichend" bei Webspace/PHP/CGI/SSI aktiviere (alle Werte lasse ich unverändert), wird das Dropdown Menü wieder eingeblendet und ich kann eine PHP Version zuweisen.
Perfekt, vielen Dank!
Hallo Herr Keppler,
Firefox unterstützt mit der aktuellen Beta (FF57) FIDO U2F ohne die Verwendung von Plugins. https://wiki.mozilla.org/Secur…eering#Web_Authentication
Allerdings funktioniert es zusammen mit LiveConfig nicht.
Der Login funktioniert mit FF57 nicht, und auch die Einrichtung eines neuen Token funktioniert nicht.
Bei der Registrierung eines neuen U2F Gerätes scheint Firefox den Yubikey nicht zu erkennen und bleibt beim 2. Schritt ("Bitte aktivieren bzw. schließen Sie Ihr U2F Gerät nun an,...") hängen.
Auch beim Login wird die U2F Funktion des Yubikeys nicht erkannt, sondern statt dessen (in meiner Konfiguration) das One Time Password ausgegeben.
Mit FF56 + U2F Plugin funktioniert die Zwei Faktor Authentifizierung weiterhin korrekt.
Und auch mit Chrome funktioniert alles.
Hat sich erledigt - ist vermutlich mit MySQL als DB-Backend, da gibt es noch einen (bekannten) Fehler.
(der CAA-Record hat den Typ 257, im entsprechenden Feld können aber nur "unsigned char"-Werte gespeichert werden). Wird kurzfristig noch geändert.
Ja genau, MySQL mit Debian
Danke fürs veröffentlichen der Hooks Skripte.
Die eigenen sich vielleicht auch um die NGINX Konfiguration von LC zu ändern.
Mich stören da immer wieder zwei Zeilen in der original Konfiguration.
Wir beschäftigen uns auch schon länger mit Benno, fahren aber ebenfalls Aufgrund mangelnder Nachfrage das Projekt nur auf Sparflamme weiter.
Ein weiteres Problem scheinen bei mir die CAA Records zu verursachen.
Nach dem ausfüllen und speichern des Formulars wird die GUI leer wieder angezeigt.
[Blockierte Grafik: http://static.tcrserver.de/Unbenannt.jpg]
Auch ein CAA Record scheint nicht in der Zone gesetzt zu werden.
Zumindest liefert ein "dig" auf den Nameserver und die entsprechende Domain ein negatives Resultat.
In den Logfiles liveconfig.log, lcclient.log und syslog gibt es keine relevanten Fehlereinträge.
heißt für alle mit vielen Servern wieder selbst in der sqlite rumbasteln um das überall zu aktivieren?
Manchmal hab ich echt das Gefühl LC wird primär/nur für Gelegenheits-Admins mit 5-10 Servern ausgelegt...
Lässt sich in der GUI aktivieren.
Serververwaltung > Web > IP-Adressen
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:
ZitatAlles anzeigen
# 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'.
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.
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.
ZitatAlles anzeigen
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>
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.
ZitatAlles anzeigen
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>
ZitatAlles anzeigen
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>
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!
Alles anzeigenWas 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
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.
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.