Beiträge von TCRserver

Ich vermisse eine Funktion zum exportieren des DKIM Keys, eine Import Funktion ist ja schon vorhanden.

Zudem fehlt eine Funktion zum exportieren und zum importieren von DNSSEC Keys.

Auf einem neu in installierten Server wird die liveconfig-vhost Datei nicht korrekt geschrieben. Auf dem Server sind folgende Host konfiguriert (alle identisch in den LiveConfig Einstellungen)

Server: Debian 9.5
LiveConfig: 2.7.0-r5064 - lcclient

Konfigurierte Verträge:

root@s10 /var/www # l
insgesamt 64
drwxr-xr-x 16 root root 4096 Aug 13 14:41 .
drwxr-xr-x 13 root root 4096 Jun 21 14:33 ..
drwxr-xr-x  7 root root 4096 Aug 10 15:09 domain-dummy
drwxr-xr-x  2 root root 4096 Jun 17 20:29 html
drwxr-xr-x  7 root root 4096 Aug 13 14:41 phpMyAdmin
drwxr-xr-x  7 root root 4096 Aug 12 16:07 s10server
drwxr-xr-x  7 root root 4096 Aug 10 15:39 s10_sms
drwxr-xr-x 10 root root 4096 Jul  2 20:56 s10_status
drwxr-xr-x  7 root root 4096 Aug 12 10:26 s10_Com
drwxr-xr-x  7 root root 4096 Aug 12 15:03 s10_De
drwxr-xr-x  7 root root 4096 Aug 12 10:24 s10_Net
drwxr-xr-x  3 root root 4096 Aug 13 09:22 s10_Info
drwxr-xr-x  9 root root 4096 Jun 28 16:24 s10_portal
drwxr-xr-x  2 root root 4096 Aug 20 06:25 webalizer

liveconfig-vhost Datei:

#  _    _          ___           __ _     (R)
# | |  (_)_ _____ / __|___ _ _  / _(_)__ _
# | |__| \ V / -_) (__/ _ \ ' \|  _| / _` |
# |____|_|\_/\___|\___\___/_||_|_| |_\__, |
#                                    |___/
# Copyright (c) 2009-2018 Keppler IT GmbH.
# ----------------------------------------------------------------------------
# DO NOT MODIFY - ANY CHANGES WILL BE OVERWRITTEN!
# Last updated at: 2018-08-18 02:43:31 CEST
# ----------------------------------------------------------------------------




/var/www/s10_portal/logs/*.log /var/www/s10_portal/logs/priv/*.log {
    daily
    compress
    delaycompress
    maxage 1
    rotate 1
    nocreate
    missingok
    notifempty
    sharedscripts
    postrotate
      /usr/bin/killall -HUP lclogsplit
    endscript
}


# <EOF>-----------------------------------------------------------------------

Zudem hätte ich inzwischen erwartet, dass in LiveConfig unter Vertrag > Log-Dateien eine der DSGVO entsprechende Default Einstellung vorhanden ist.
Meiner Meinung nach gehört per Default "Logdateien täglich rotieren" und "Archivierte Logs nach 1 Tag löschen", sowie die Anonymisierung der IP-Adressen eingetragen.

Zitat von dicker

Hat noch jemand das Problem?

Zumindest unsere Server laufen alle Stabil durch.
Gibt es irgendwelche Logfile Einträge?
Läuft zu der Uhrzeit ein CronJob?

Ein frisch installierter Server (Debian9) mit lcclient, liefert bei mir permanent folgende Fehlermeldung:

Zitat

Jun 17 17:04:18 s10 lclogsplit[21318]: /var/lib/liveconfig/accesslog.map: No such file or directory

Das ganze ist auch eher wieder ein "kosmetischer" Fehler.
Da es noch keinen Account auf dem Server gibt, ist die Fehlermeldung logisch.
Kann aber unter Umständen zu Verwirrungen führen.

Leider noch ein Punkt zu den Logfiles/Logrotate

Auf 2 Servern mit lcclient Installation bekomme ich nach dem ausführen des CronJobs folgende Fehlermeldung.

/etc/cron.daily/logrotate:
error: liveconfig-vhosts:12 duplicate log entry for /var/www/web_xxxx/logs/access.log

In der Datei liveconfig-vhost gibt es aber keinen doppelten Eintrag.

Aber es gibt jetzt 3 Dateien im logrotate Verzeichnis die von LC stammen

~# l /etc/logrotate.d
-rw-r--r-- 1 root root  904 Mai 16 14:58 lcclient
-rw------- 1 root root 8762 Mai 16 21:30 liveconfig
-rw------- 1 root root 9193 Mai 25 00:04 liveconfig-vhosts

Muss hier eigentlich nicht die liveconfig Datei gelöscht werden?
Auf dem LiveConfig Master-Server wurde die Datei bereinigt und enthält nur noch einen Eintrag für LiveConfig selbst.

Hallo Herr Keppler,

danke für das Update.
Für mich noch eine Verständnisfrage:
Die error.log wird weiterhin nicht rotiert und gelöscht, richtig?

Zudem werden noch immer nicht alle alten Logfiles gelöscht.
Ich hätte erwartet, dass die *.gz Dateien mit altenLogfiles gelöscht werden.

-rw-r--r-- 1 root     root     264K Mai 17 10:22 access.log
-rw-r--r-- 1 root     root     1,1M Mai 17 06:15 access.log.1
-rw-r--r-- 1 root     root     3,1M Mär  1 06:16 access.log.3.gz
-rw-r--r-- 1 root     root     5,0M Feb  1 06:26 access.log.4.gz
-rw-r--r-- 1 root     root     9,9M Mär 10  2016 error.log
drwxrwx--- 2 webh_158 webh_158 4,0K Mai 15 15:14 priv

Die Ausgabe von logrotate -df /etc/logrotate.d/liveconfig-vhosts

rotating pattern: /var/www/webh_158/logs/access.log  forced from command line (1 rotations)
empty log files are not rotated, old logs are removed
considering log /var/www/webh_158/logs/access.log
  log needs rotating
rotating log /var/www/webh_158/logs/access.log, log->rotateCount is 1
dateext suffix '-20180517'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
compressing log with: /bin/gzip
renaming /var/www/webh_158/logs/access.log.1.gz to /var/www/webh_158/logs/access.log.2.gz (rotatecount 1, logstart 1, i 1),
renaming /var/www/webh_158/logs/access.log.0.gz to /var/www/webh_158/logs/access.log.1.gz (rotatecount 1, logstart 1, i 0),
renaming /var/www/webh_158/logs/access.log to /var/www/webh_158/logs/access.log.1
running postrotate script
running script with arg /var/www/webh_158/logs/access.log : "
      /usr/bin/killall -HUP lclogsplit
"
removing old log /var/www/webh_158/logs/access.log.2.gz
error: error opening /var/www/webh_158/logs/access.log.2.gz: Datei oder Verzeichnis nicht gefunden

Es scheint als ob Logrotate an der fehlenden access.log.2.gz Datei abbricht und dann nicht mehr weiter bereinigt. Den Fehler kann ich an mehreren Accounts so nachvollziehen.

Ein kosmetischer Fehler in der aktuellen Preview:
Beim anlegen oder ändern eines Postfachs scheint die deutsche Übersetzung nicht korrekt zu funktionieren.

Hier wird jetzt "self service | allow e-mail user to log in
and edit mailbox settings" angezeigt.

dron.daily läuft auf dem Server um 06:15 Uhr.

Und die Config Datei auf dem Server ist zumindest auch nicht leer.
Aber es gibt nur Einträge für die access.log, für die error.log und auch die priv/php_errors.log gibt es keine Einträge.

Dafür wirft logrotate -df /etc/logrotate.d/liveconfig einen Fehler:

rotating pattern: /var/www/webh_158/logs/access.log  forced from command line (1 rotations)
empty log files are not rotated, old logs are removed
considering log /var/www/webh_158/logs/access.log
  log needs rotating
rotating log /var/www/webh_158/logs/access.log, log->rotateCount is 1
dateext suffix '-20180515'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
compressing log with: /bin/gzip
renaming /var/www/webh_158/logs/access.log.1.gz to /var/www/webh_158/logs/access.log.2.gz (rotatecount 1, logstart 1, i 1),
renaming /var/www/webh_158/logs/access.log.0.gz to /var/www/webh_158/logs/access.log.1.gz (rotatecount 1, logstart 1, i 0),
renaming /var/www/webh_158/logs/access.log to /var/www/webh_158/logs/access.log.1
running postrotate script
running script with arg /var/www/webh_158/logs/access.log : "
      /usr/bin/killall -HUP lclogsplit
"
removing old log /var/www/webh_158/logs/access.log.2.gz
error: error opening /var/www/webh_158/logs/access.log.2.gz: Datei oder Verzeichnis nicht gefunden

Zitat von kk

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 php

Beim anlegen eines neuen Benutzers (Benutzer>Benutzerverwaltung>Benutzer hinzufügen) erhalte ich mit der aktuellen Preview folgenden Fehler

Zitat

Error 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

Zitat von lebenszeit

.htaccess ist der richtige Ort, das ist Sache des Webmasters. LC hat andere Aufgaben.

+1

10 Zeichen Dingens

Zitat von clickpress

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

Zitat

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
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.

Zitat

Prü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!