Es wäre optimal wenn neben der aktuellen Speicherplatzbelegung pro Kunde auch noch wie beim Traffic historische Speicherplatzbelegung als Statististik angezeigt werden würde.

So muss man sich derzeit ein cronscript basteln um dies zu erreichen, was nicht Ziel der Sache sein sollte.

So ists

Bin aber auch dank Sumeragi auf den Mozilla Konfig Generator gestoßen.

Funktioniert soweit alles prächtig.

Ist zwar schon ein älterer Thread aber dennoch hier die Info wie ich es erfolgreich konfiguriert habe um A+ Ratings auf https://www.ssllabs.com/ssltest ereicht habe - und damit nur mehr TLS 1.2 und TLS 1.3 unterstütze in den passenden Cipher Suites:

SSLProtocol +TLSv1.2 +TLSv1.3
SSLCipherSuite HIGH:!kRSA:!ADH:!eNULL:!LOW:!EXP:!MD5:!3DES

Klar. Eigentlich ganz einfach:

1) Dovecot

a) 90-acl.conf

plugin {

acl = vfile

acl_shared_dict = file:/home/popuser/popboxen/.dovecot-shared-mailboxes.db

}

b) 20-imap.conf

protocol imap {

mail_plugins = $mail_plugins imap_quota imap_acl

}

=> Nach dem Einrichten Dovecot neu starten.

2) RC ACL Plugin

config.inc.php

<?php// Default look of access rights table

// In advanced mode all access rights are displayed separately

// In simple mode access rights are grouped into four groups: read, write, delete, full

$config['acl_advanced_mode'] = false;

// LDAP addressbook that would be searched for user names autocomplete.

// That should be an array refering to the $config['ldap_public'] array key

// or complete addressbook configuration array.

$config['acl_users_source'] = '';

// The LDAP attribute which will be used as ACL user identifier

$config['acl_users_field'] = 'mail';

// The LDAP search filter will be &'d with search queries

$config['acl_users_filter'] = '';

// Enable LDAP groups in user autocompletion.

// Note: LDAP addressbook defined in acl_users_source must include groups config

$config['acl_groups'] = false;

// Prefix added to the group name to build IMAP ACL identifier

$config['acl_group_prefix'] = 'group:';

// The LDAP attribute (or field name) which will be used as ACL group identifier

$config['acl_group_field'] = 'name';

// Include the following 'special' access control subjects in the ACL dialog;

// Defaults to array('anyone', 'anonymous') (not when set to an empty array)

// Example: array('anyone') to exclude 'anonymous'.

// Set to an empty array to exclude all special aci subjects.

$config['acl_specials'] = array('anyone', 'anonymous');

Ich habe in der Zwischenzeit über ein Roundcube Plugin (ACL) und der dazugehörigen Dovecot Config eine sehr brauchbare Lösung gefunden mit der das Teilen in RC direkt komfortabel ist und gut funktioniert.

Kann ich bei Interesse gerne teilen.

Das würde ich auch gerne wissen... Ich muss nun immer manuell die dovecot Config wiederherstellen, was mühsam ist.

Definitv ein Rückschritt dahingehend.

Gibt es hier andere Möglichkeiten?

Danke für den Hinweis - der verlinkte Link bezieht sich aber auf den Fix für Debian 10. Hier war jedoch wie eingangs erwähnt Debian 9 im Einsatz.

Das Problem wurde aber nun gelöst:

1) Upgrade auf Debian 10 durchgeführt

2) Symlinks erzeugt wie in RE: Internal Server Error: End of script output before headers: administrator.cgi erwähnt

3) update.sh erneut durchgeführt

Und siehe dazu --> nun klappt es.

Besten Dank & schönes We

So, also nochmals probiert - und neben dem oben bereits genannten Fehlermeldung beim Aufruf von update.sh bekomme ich nun folgenden Fehler beim Aufruf des Web Admin Interface:

Software error:

Can't load '/opt/pdadmin/lib/mysql.so' for module DBD::mysql: libssl.so.10: cannot open shared object file: No such file or directory at PERL2EXE_STORAGE/DynaLoader.pm line 200. at /opt/pdadmin/www/administrator/administrator.cgi line 93
Compilation failed in require at /opt/pdadmin/www/administrator/administrator.cgi line 93.
BEGIN failed--compilation aborted at /opt/pdadmin/www/administrator/administrator.cgi line 93.

Als Referenz:

$ file /opt/pdadmin/lib/mysql.so
/opt/pdadmin/lib/mysql.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=5abd1f5d3a21a4ff3aa8d407584576dd59afc47f, stripped

sowie

$ file /opt/pdadmin/lib/DBI.so
/opt/pdadmin/lib/DBI.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=a551185821490263018e69911fc5e516b07045ec, stripped

D.h. das Problem scheint "nur" eines mit Perl und pdadmin konkret zu sein?

Der Rest scheint normal zu funktionieren, also zB ein Aufruf mit

perl test-mysql.pl

mit dem Inhalt

#!/bin/env perl

use DBI;

$dsn = "DBI:mysql:database=...;host=localhost;port=3306";
$dbh = DBI->connect($dsn, '...', '...');

geht problemlos durch.

=> Aber ohne perl geht Web Admin Interface einfach nicht...

=> Kann es evtl. am dynamic linking und einem falschen (altem 32bit) Link hier liegen?

Bin für weitere Hinweise dankbar.

Danke, das habe ich prinzipiell so gemacht (Aufruf von update.sh mittels der 64bit Variant) - nur dann kam eben der Fehler wie eingangs erwähnt.

D.h. prinzipiell sollte ein Aufruf mittels update.sh das "Upgrade" auf die 64bit erfolgreich durchführen können? Und manuell sollten keine weiteren Schritte notwendig sein?

Debian 9, 64bit ist hier im Einsatz.

Wie gesagt beim update.sh Aufruf kam der zuvor genannte Fehler im verlinkten Beitrag.

$ ll /opt/pdadmin/lib/libmysql*
lrwxrwxrwx 1 root root     41 Jun 16 17:26 /opt/pdadmin/lib/libmysqlclient.so -> /opt/pdadmin/lib/libmysqlclient.so.15.0.0
lrwxrwxrwx 1 root root     41 Jun 16 17:26 /opt/pdadmin/lib/libmysqlclient.so.15 -> /opt/pdadmin/lib/libmysqlclient.so.15.0.0
-r--r--r-- 1 root root 404828 Aug  6  2007 /opt/pdadmin/lib/libmysqlclient.so.15.0.0

$ file /opt/pdadmin/lib/libmysqlclient.so.15.0.0 
/opt/pdadmin/lib/libmysqlclient.so.15.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

Gibt es eine Möglichkeit von einer bestehenden 32 bit pd-admin Variante auf die 64 bit Variante "upzugraden"?

Installiert ist v4.69 mit 6-0.366.

Beim Versuch die 64 bit Variante mittels der aktuellen pdadmin_v4_64.tar.gz zu installieren führt zu den bekannten Problemen, wie im Forum bereits erwähnt.

Besten Dank.

Ich würde es sehr hilfreich finden wenn es eine Möglichkeit gäbe Kommentare zu Endkunden-Einträgen (Bereich "Übersicht" unter "Kunden und Domains") hinzuzufügen und diese dann in der Übersicht anzuzeigen.

Kommentare gibt es derzeit ja bereits für andere Bereiche wie z.B. FTP Zusatzaccounts.

Update:

Offenbar scheint das Problem mit dem täglichen Aufruf des backup.pl Skripts in Verbindung zu stehen.

DBD::mysql:t execute failed: MySQL server has gone away at /opt/pdadmin/bin/backup.pl line 95.

cannot execute query 'select t1.id, t1.login, t2.backup from users as t1, accounts as t2 where t2.backup > 0 and t1.account=t2.id' at /opt/pdadmin/bin/backup.pl line 95.

Ich hätte im Forum nichts dazu gefunden - ausser strace noch andere Tips zu diesem Thema?

Beste Dank

Besten Dank Herr Bradler ich werde dies untersuchen.

Derzeit ist es aber so, dass nach einem Neustart des MySQL Servers diese Seiten eine Zeit lang aufgerufen werden können, dann aber wieder dasselbe Problem auftritt.

Auf diesem Server laufen einige Projekte, die MySQL verwenden. Keines davon weist abnormales Verhalten, hinsichtlich Timeouts oder höherer Latenz bei Requests auf. Lediglich pd-admin macht hier in der Admin Oberfläche Probleme mit diesem Verhalten.

Besten Dank für die Infos.

Ich habe neben wait_timeout und interactive_timeout auch noch ein paar andere InnoDB Optimierungen

vorgenommen (verwende ausschließlich InnoDB hier), die in Richtung caching und buffer sizes abzielen und

werde dies weiter beobachten.

Danke für den Hinweis, MySQL Tuner kenne ich und ist bereits im Einsatz.

Dennoch ist das eine Vanilla mysql 5.7 Konfiguration aus pd-admin heraus, daher verstehe ich nicht ganz

warum es hier bei Requests zur pd-admin Oberfläche via administrator.cgi zu Timeouts kommt.

Ich werde weiter analysieren und ein Update geben sobald ich eines habe.

Follow-up wegen der Timeouts hier: Timeout bei Aufruf diverser Seiten via administrator.cgi

Ich würde diesen Thread dennoch nicht als erledigt markieren weil "Löschen der Templates" im Reseller Home nicht wirklich die Lösung zu diesem Problem sein kann, oder?

Im Einsatz ist v4.63 mit 6-0.354 - installiert über ein Reihenupgrade von Reihe 4 auf 6.

Nach dem Upgrade gibt es derzeit Timeouts beim Aufruf diversen Seiten via administrator.cgi, z.B. Serverkonfiguration.

Neben den bekannten Logs aus einem anderen Bugreport (Aborted connection) sehe ich keine Fehler.

Ein SHOW FULL PROCESSLIST um auf Table Locks Hinweise zu bekommen zeigt, dass einige vadmin relevante Prozesse im Sleep mode sind - darunter auch immer jener, wenn

ich z.B. die Serverkonfiguration öffne => daher kommt dann auch wohl der Timeout.

Ein SHOW ENGINE INNODB STATUS liefert den Output im Anhang.

Welche Logs könnten für die Fehlersuche noch hilfreich sein?

Besten Dank.

Habe ich bereits gemacht und laut diff ident. Sehr merkwürdig das ganze.

Gibts sonst Logs wo ich weitere Infos erhalten könnte?

In /usr/local/pd-admin2/logs/error_log scheint nicht wirklich etwas auf ausser die Timeouts, die ich oben bereits genannt habe.

Ok, habe die email.* Dateien aus diesem Ordner verschoben.

Hat aber leider keine Auswirkung auf das bestehende Verhalten bei

1) Anlege neuer Endkunden

2) Aufruf div. Seiten wie etwa der Serverkonfiguration

Ausserdem denke ich nicht, dass die das Problem sind hier ganz ehrlich, weil diese 3 Files ja auch nicht für den Aufruf von

Seite wie der Serverkonfiguration benötigt werden...

Daher würde ich gerne als einfachste Fehlerquelle gerne eine funktionierende administrator.cgi für eine Reihe 6 bekommen.

Damit könnte ich dies rasch verifizieren. Optimal wäre eine aktuelle 6-0.354.