# Logs werden nicht aktualisiert



## yel (29. Mai 2018)

Kann mir bitte jemand weiterhelfen? Im ISPC Panel werden die logs nicht mehr aktualisiert und auch sonst zeigt es falsche Daten an...

Protokolldateien seit März und oben das Systemprotokoll seit April nicht mehr.
Ansonsten scheint alles zu funktionieren. Die Logs werden im Hintergrund auch sauber geführt.
Gestern habe ich den Update auf 3.1.12 fehlerfrei durchgeführt, im Panel zeigt es aber immer noch 3.1.11 an... Ich habe aber /usr/local/ispconfig/server/lib/config.inc.php überprüft: define('ISPC_APP_VERSION', '3.1.12')

Ich hatte in letzter Zeit beim Update Probleme mit Kernels und dem Dpkg, diese sollten aber behoben sein.

Server läuft unter Ubuntu 16.04.4 LTS


----------



## nowayback (29. Mai 2018)

läuft der cronjob?


----------



## yel (29. Mai 2018)

Ja. Laut /var/log/ispconfig/cron.log läuft alles und auch unter /var/log/syslog hat es Einträge (u.a. munin/getmail) dazu.

Müsste /var/log/ispconfig/ispconfig.log nicht auch Einträge aufweisen? Das ist leer...

freshclam und clamav sind die einzigen Protokolle die im Interface korrekt angezeigt werden.

Könnte es ein Rechte-Problem sein? Wo würde das geloggt?

Hat folgende Meldung ggf damit zu tun? Erscheint immer wieder... Die beiden config.inc.php beinhalten dieselben PWs...
May 29 17:49:49 rootcloud mysqld[1415]: 2018-05-29 17:49:49 140673705162496 [Warning] Aborted connection 52145 to db: 'dbispconfig' user: 'ispconfig' host: 'localhost' (Got timeout reading communication packets)
May 29 17:49:50 rootcloud mysqld[1415]: 2018-05-29 17:49:50 140673706071808 [Warning] Aborted connection 56055 to db: 'dbispconfig' user: 'ispconfig' host: 'localhost' (Got timeout reading communication packets)

Habe mal zum Test im Interface bei der Firewall einen Port hinzugefügt --> wurde sofort in der dbsipconfig-tabelle 'firewall' eingetragen. Die connection zur DB scheint also da zu sein.


----------



## florian030 (31. Mai 2018)

Es gibt zwei Richtungen für die DB bei einem Slave: Änderungen erhalten und Änderungen schicken. Und wenn der Server nicht dbispconfig kommt, kann sich auch nichts aktualisieren.


----------



## yel (31. Mai 2018)

Danke @florian030 : Das ist ein Singleserver.

Komisch ist wirklich, dass im Hintergrund alles zu laufen und nur einzelne Elemente in der DB nicht aktualisiert werden: 
-> Übersicht zeigt falsche Version, aber korrekt, wenn ein OS-Update ansteht, bzw wieder grün, wenn aktualisiert
-> System-Protokoll hat einige Hinweise vom April
-> Server meldet sei 17 Tagen online, obwohl ich ihn am Montag morgen neu gestartet habe
Alle E-Mail-, das System-, Cron- und Fail2Ban Protokoll hängen seit Mitte März.

Einzig ClamAV und FreshClam sind korrekt (hatte ich am Montag neu installiert)

unter /var/log sind sind alle logs aktuell und korrekt.

Ich habe mir die monitor_data tabelle in dbispconfig angeschaut: Checks sind alle OK, ich habe sie geflushed, weiss nun aber nicht, ob es schlau wäre, den Inhalt zu leeren.
Was triggert das Schreiben in die Tabelle? Warum werden die ClamAV-Logs reingeschrieben, die anderen aber nicht?


----------



## Till (31. Mai 2018)

poste mal die Ausgabe von:

crontab -l -u root


----------



## yel (31. Mai 2018)

Hallo @Till 

40 3 * * *      /etc/back-res 1>/dev/null 2>/dev/null
30 02 * * 1 /usr/bin/cetbot renew --quiet >> /var/log/ispconfig/cron.log;
* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
* * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done


----------



## Till (31. Mai 2018)

Sieht soweit ok aus, den certbot würde ich aber da raus nehmen, denn Zertifikate werden durch ISPConfig erneuert, rufst Du das so manuell auf werde die neuen certs nicht korrekt angewendet.


----------



## florian030 (31. Mai 2018)

Ich würde bei Warning] Aborted connection  ansetzen. Kannst Du dich bei mysql mit den Werten aus /usr/local/ispconfig/server/lib/config.inc.php anmelden?

$conf['db_host'] = 'localhost';
$conf['db_port'] = '3306';
$conf['db_database'] = 'dbispconfig';
$conf['db_user'] = 'ispconfig';
$conf['db_password'] = '...';

mysql -h $conf['db_host'] -u $conf['db_user'] -p$conf['db_password'] $conf['db_database']


----------



## yel (31. Mai 2018)

@Till  Danke, habe ich rausgenommen. Sonst noch eine Idee, warum das nicht klappt?

@florian030  Der Login über Bash mit den Angaben aus config.inc.php klappt. Hier die DB und Status-Ausgabe:


```
MariaDB [dbispconfig]> show tables;
+--------------------------+
| Tables_in_dbispconfig    |
+--------------------------+
| aps_instances            |
| aps_instances_settings   |
| aps_packages             |
| aps_settings             |
| attempts_login           |
| client                   |
| client_circle            |
| client_message_template  |
| client_template          |
| client_template_assigned |
| country                  |
| cron                     |
| directive_snippets       |
| dns_rr                   |
| dns_slave                |
| dns_soa                  |
| dns_template             |
| domain                   |
| firewall                 |
| ftp_traffic              |
| ftp_user                 |
| help_faq                 |
| help_faq_sections        |
| iptables                 |
| mail_access              |
| mail_backup              |
| mail_content_filter      |
| mail_domain              |
| mail_forwarding          |
| mail_get                 |
| mail_mailinglist         |
| mail_relay_recipient     |
| mail_traffic             |
| mail_transport           |
| mail_user                |
| mail_user_filter         |
| monitor_data             |
| openvz_ip                |
| openvz_ostemplate        |
| openvz_template          |
| openvz_traffic           |
| openvz_vm                |
| remote_session           |
| remote_user              |
| server                   |
| server_ip                |
| server_ip_map            |
| server_php               |
| shell_user               |
| software_package         |
| software_repo            |
| software_update          |
| software_update_inst     |
| spamfilter_policy        |
| spamfilter_users         |
| spamfilter_wblist        |
| support_message          |
| sys_config               |
| sys_cron                 |
| sys_datalog              |
| sys_dbsync               |
| sys_filesync             |
| sys_group                |
| sys_ini                  |
| sys_log                  |
| sys_remoteaction         |
| sys_session              |
| sys_theme                |
| sys_user                 |
| tpl_ispc_clean           |
| tpl_ispc_clean_app       |
| tpl_ispc_clean_cat       |
| web_backup               |
| web_database             |
| web_database_user        |
| web_domain               |
| web_folder               |
| web_folder_user          |
| web_traffic              |
| webdav_user              |
| xmpp_domain              |
| xmpp_user                |
+--------------------------+
82 rows in set (0.00 sec)

MariaDB [dbispconfig]> status
--------------
mysql  Ver 15.1 Distrib 10.2.10-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Connection id:          99669
Current database:       dbispconfig
Current user:           ispconfig@localhost
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server:                 MariaDB
Server version:         10.2.10-MariaDB-10.2.10+maria~xenial-log mariadb.org binary distribution
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    utf8
Conn.  characterset:    utf8
UNIX socket:            /var/run/mysqld/mysqld.sock
Uptime:                 3 days 4 hours 32 min 31 sec

Threads: 31  Questions: 1576294  Slow queries: 0  Opens: 6887  Flush tables: 2  Open tables: 400  Queries per second avg: 5.720
--------------

MariaDB [dbispconfig]>
```


----------



## yel (1. Juni 2018)

@Till Ich habe hier einen alten Eintrag von Dir gefunden und mal die monitor_data truncated. Ich warte mal ab, ob es morgen wieder gefüllt sein wird... Zzt. ist es seit ca 1h leer

Eine andere Frage. Ich habe folgendes im System-Log gefunden. Das ist mir vorher nicht aufgefallen. Ich verwende Mailboxen, damit einzelne Benutzer Mails über meinen SMTP-Server senden können, ankommende Mails sollen aber direkt zu ihrem Provider (Gmail/Hotmail o.a) weitergeleitet werden. Funktioniert wunderbar, der Fehler erscheint auch nur, wenn ich eine Mailbox editere und speichere

[INTERFACE]: PHP IDS Alert.Total impact: 7<br/> Affected tags: xss, csrf, id, rfe, lfi<br/> <br/> Variable: POST.custom_mailfilter | Value: redirect &quot;name@mailcom&quot;; stop;<br/> Impact: 7 | Tags: xss, csrf, id, rfe, lfi<br/> Description: Detects unknown attack vectors based on PHPIDS Centrifuge detection | Tags: xss, csrf, id, rfe, lfi | ID 67<br/> <br/> 

Ist das ein FalsePositive wie hier angesprochen? Wäre es korrekt ein ids.whitelist.custom zu erstellen und folgende Zeile einzutragen?
admin:/mail/mail_user_edit.phpOST.custom_mailfilter

(--> Soll ich dafür eine neue Diskussion eröffnen?)


----------



## yel (3. Juni 2018)

Update: Ausser Freshclam,ClamAV und RKHunter sind alle Protokolle leer...


----------



## Till (4. Juni 2018)

Zitat von yel:


> [INTERFACE]: PHP IDS Alert.Total impact: 7<br/> Affected tags: xss, csrf, id, rfe, lfi<br/> <br/> Variable: POST.custom_mailfilter | Value: redirect &quot;name@mailcom&quot;; stop;<br/> Impact: 7 | Tags: xss, csrf, id, rfe, lfi<br/> Description: Detects unknown attack vectors based on PHPIDS Centrifuge detection | Tags: xss, csrf, id, rfe, lfi | ID 67<br/> <br/>
> 
> Ist das ein FalsePositive wie hier angesprochen? Wäre es korrekt ein ids.whitelist.custom zu erstellen und folgende Zeile einzutragen?
> admin:/mail/mail_user_edit.phpOST.custom_mailfilter


Das ist ok soweit, es ist ein FP aber er liegt ja deutlich unter dem score abd em die Aktion geblocked wird.


----------



## yel (24. Sep. 2018)

Habe soeben auf 3.1.13 (update auf noch unter ubuntu 16.04.*5*) upgedatet. Leider besteht das Problem immer noch...
Folgende Module zeigen 'keine Daten' an (z.B. 'Derzeit stehen keine Daten der EMail Warteschlange zur Verfügung.Bitte später erneut überprüfen. '):
RAID Status
Serverauslastung
Speicherauslastung
Dienste
alle Protokolldateien ausser Freshclam, ClamAV, RKHunter

Im Mai gab es im ispconfig_install.log folgende Fehler:
ERROR 1060 (42S21) at line 1: Duplicate column name 'ssl_letsencrypt_exclude'
ERROR 1060 (42S21) at line 2: Duplicate column name 'remote_access'
ERROR 1060 (42S21) at line 3: Duplicate column name 'remote_ips'
Im Juni hatte ich den 12 Update nochmals laufen lassen und nun heute auf 13 (beide male ohne Fehler)

Wenn ich mir die Tabelle monitor_data anschaue sind das alle Einträge. Das sind genau jene, welche mir auch im Interface angezeigt werden:


> disk_usage1532951701a:6:{i:1;a:7:{s:2:"fs";s:4:"udev";s:4:"type";s:8:"
> cpu_info1532951701a:208:{s:11:"processor 0";s:1:"0";s:11:"vendor_id ...no_state
> email_quota1532952901a:20:{s:16:"user@domain.com";a:1:{s:4:"used";i:10...ok
> rkhunter1537740067a:1:{s:6:"output";s:19407:"[ Rootkit Hunter versio...no_state
> ...


Sollten da nicht auch die anderen Daten drin stehen?
Mit welcher Aktion werden die 'gefüttert'? Kann es sein, dass im Filesystem eine Rechteproblem besteht?
Unter var/log/ispconfig sind nur auth.log (rw-rw---- für ispconf), cron.log (rw-r--r-- für root) und ispconfig.log (leer rw-r--r-- für root)
unter /var/log wird scheinen die anderen Logs OK zu sein (meist syslog oder root mit rw-r----)


----------



## Till (24. Sep. 2018)

Hast Du mal in phpmyadmin ein repair auf alle Tabellen in der dbispconfig DB laufen lassen? Nicht das eine defekt ist.


----------



## yel (25. Sep. 2018)

@Till ja hatte ich. Habe heute nochmals alle überprüft: Alles OK. In welcher Tabelle sollten denn z.B. die Mailprotokolle stehen?


----------



## RalphGL (26. Okt. 2020)

@yel Ich bin auf diesen Thread gestoßen, weil auch bei mir aktuell die auth.log und die ispconfig.log keine Einträge enthalten (allerdings mit der aktuellen ispconfig 3.2 unter debian 10). Auch bei mir wird server.sh und cron.sh korrekt ausgeführt. Die cron.log enthält auch Einträge. Hast Du bei Deiner Recherche noch Hinweise gefunden, wie die Ursache des Problems gefunden werden kann - bzw. wie bist Du vorgegangen?
Auffällig ist, dass owner und group von auth.log nun ispconfig ist, von cron.log und ispconfig.log aber root.


----------

