Logrotate löscht nur dann alte Logfiles, wenn eine Rotation durchgeführt wird.
Wenn Sie eben erst auf tägliche Rotation umgestellt haben, kann es entsprechend bis zu 24 Std. dauern, bis logrotate die alten Logs löscht.
Interessant ist, dass die error.log nicht rotiert wurde, da sollte LiveConfig eigentlich auch konsequent sein. Werden wir gleich mal prüfen.
Hab ich vergessen zu schreiben, die Umstellung der Lösch-Regeln erfolgte am Sonntag.
Somit sollte heute Morgen alles durchrotiert sein.
Und ein drittes kleines Problem:
[Blockierte Grafik: https://www.python-forum.de/Unbenannt.JPG]
Meiner Ansicht nach, sollte bei der Anziege der Logfiles kein HTML Code ausgeführt werden.
Ein weiteres Problem habe ich mit den Logfiles bzw. dem automatischen löschen der Logfiles.
Ich habe alle Verträge umgestellt auf "tägliches rotieren" und "löschen nach einem Tag".
Allerdings werden damit nicht alle Logfiles im Kundenverzeichnis gelöscht.
Ich würde mir wünschen, dass hier alle "alte" Logfiles gelöscht werden.
-rw-r--r-- 1 webh_158 webh_158 2,4M Mai 15 08:30 access.log
-rw-r--r-- 1 webh_158 webh_158 4,8M Mai 1 06:25 access.log.1
-rw-r--r-- 1 webh_158 webh_158 209K Apr 1 06:26 access.log.2.gz
-rw-r--r-- 1 webh_158 webh_158 105K Mär 1 06:26 access.log.3.gz
-rw-r--r-- 1 webh_158 webh_158 296K Feb 13 06:25 access.log.4.gz
-rw-r--r-- 1 root root 9,6K Apr 30 2015 error.log
drwxrwx--- 2 webh_158 webh_158 4,0K Aug 16 2013 phpBeim anlegen eines neuen Benutzers (Benutzer>Benutzerverwaltung>Benutzer hinzufügen) erhalte ich mit der aktuellen Preview folgenden Fehler
ZitatError 503: Service Unavailable
An error occured while processing your request: Column count doesn't match value count at row 1
Im Logfile gibt es folgenden Eintrag dazu
Zitat[2018/05/15 08:20:25.668402] [7925|7928] ERROR: Releasing db connection, but still have running transaction (-> forcing ROLLBACK)
[2018/05/15 08:20:25.668859] [7925|7928] Database Exception: Column count doesn't match value count at row 1 (SQL: INSERT INTO USERS (U_CUSTOMERID, U_CONTACTID, U_LOGIN, U_PASSWORD, U_LOCKED, U_LANGUAGE, U_TIMEZONE, U_DELETED, U_PWEXPIRE) VALUES (:1, :2, :3, :4, :5, :6, :7, 0))
LC Datenbank läuft auf einem Debian8 mit MySQL
.htaccess ist der richtige Ort, das ist Sache des Webmasters. LC hat andere Aufgaben.
+1
10 Zeichen Dingens
Du hast ioncube scheinbar nicht über die PHP-Einstellungen in LC eingebunden, oder? Bzw. mit dem Hinweis, dass /usr/local/ioncube/ioncube_loader_lin_5.6.so nur für PHP >= 5.6 und <7 gilt.
Doch klar, einbinden von IonCube erfolgt immer über LC.
In dem Bsp. ist IonCube in den PHP Einstellungen eingebunden für PHP >= 5.6 und <5.7
Also ich kenne das Problem ebenfalls von einigen, aber nicht von allen Servern.
Bei allen betroffenen Servern wurde ein Upgrade von Debian 7 auf Debian 8 durchgeführt und systemweit PHP5.x durch PHP7.0 als Standard ersetzt.
Seither liefert der LiveConfig CronJob "/usr/lib/liveconfig/cron.php.sh" eine Fehlermeldung
ZitatFailed loading /usr/local/ioncube/ioncube_loader_lin_5.6.so: /usr/local/ioncube/ioncube_loader_lin_5.6.so: undefined symbol: zval_update_constant_inline_change
Failed loading /usr/local/ioncube/ioncube_loader_lin_5.6.so: /usr/local/ioncube/ioncube_loader_lin_5.6.so: undefined symbol: zval_update_constant_inline_change
Eine Korrelation zwischen irgendeinem Kunden CronJob bzw. in LiveConfig angelgeten CronJob kann ich nicht bestätigen.
Allerdings ist bei einem (!!!) Vertrag auf dem Server der IonCube Loader aktiviert.
Und das mit der PHP Version 5.6
Da cron.php.sh aber NICHT mit PHP5.6 ausgeführt wird (systemweit ist ja PHP7 aktiv) wird hier die Fehlermeldung erzeugt und per Mail verschickt.
Wenn ich in dem einen Vertrag den IonCube Loader deaktiviere, wird logischerweise auch die Fehlermeldung nicht mehr ausgegeben.
Dazu ist anscheinend in LC 2.5.2-r4777 auch eine Änderung in LC eingeflossen.
ZitatPrüfung der PHP-Version (php-cli) damit Session-Aufräum-Script per Cron die richtige php.ini verwendet
Allerdings scheint der Patch das obige Problem nicht (korrekt) zu lösen.
EDIT: Auf den betroffenen Servern läuft entweder LC 2.6.0-r4817 oder LC 2.5.3-r4805
Bei uns laufen inwzischen auch über 80 % der Domains im Bestand (absolut problemlos) mit LC Nameserver.
Wir haben 4 NameServer die sich wunderbar via AXFR synchronisieren. Und auch die DNSSEC Implementation sowie die DynDNS Funktion laufen super.
Das einzigste was ich vermisse ist eine Funktion um die Domains auch via API zu verwalten.
Für die Nameserver (wenn es reine Nameserver sein sollen) reicht auch eine Basic Lizenz. Der Master bzw. ein Master Server mit Business Lizenz muss aber sein.
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!