Beiträge von browsingman

In überhaupt keiner PHP Datei.
Wenn du für die Mails DKIM aktivierst, wird dir eine Textzeile angezeigt, die einen Schlüssel (Key) enthält.
Dieser muss in den DNS Records als TXT Record eingetragen werden.

Wo du das machst, hängt maßgeblich davon ab, wer den DNS Server für deinen Hostnamen verwaltet.

Solltest du einen Anbieter haben, der dir die DNS Konfiguration macht, musst du ihn fragen.

Hallo zusammen,

nach jedem Update der Server-Umgebung muss ich manuell wieder folgenden Eintrag in /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/conf.d/10-ssl.conf hinzufügen:

ssl_ca = </usr/local/pd-admin2/share/imapd.cacert

Hintergrund:

Ich habe Nextcloud auf meinem Server installiert. Wenn ich das Mail-Modul hiervon benutzen will und verschlüsselte Verbindungen aufbauen möchte, wird die SSL Verbindung abgelehnt, weil das Host-Zertifikat mangels passendem Stammzertifikat nicht erfolgreich verifiziert werden kann.

Die verantwortliche Routine ist in der se-upgrade.sh Datei zu finden:

#  enable SSL/TLS for POP3 & IMAP
#
if [ -f /usr/local/pd-admin2/share/imapd.pem ]; then
   echo "certificate found, enable ssl/tls"
   cat >> $DCBASE/etc/dovecot/conf.d/10-ssl.conf <<_
ssl = yes
ssl_key = </usr/local/pd-admin2/share/imapd.pem
ssl_cert = </usr/local/pd-admin2/share/imapd.pem
ssl_dh_parameters_length = 2048

Es wäre toll, wenn beim nächsten Update der Server-Umgebung diese Zeile (wieder) mit aufgenommen würde, damit man das nicht jedesmal händisch wieder anpassen muss ....

Es handelt sich um folgende Datei:

/usr/local/pd-admin2/httpd-2.4/conf/httpd24.conf-template

Dort die Zeile(n) suchen, in der drinsteht:

Listen 80

Listen 443

Und vor die Ports jeweils die gewünschte IP-Adresse schreiben.

Dann die Datei speichern und zum Schluss einmal folgenden Befehl ausführen:

/opt/pdadmin/bin/httpd_vhosts.pl

Damit wird die eigentliche Apache Konfigurationsdatei neu generiert und der Apache-Webserver neu gestartet.

Per Default steht das da auch nicht drin.

Du musst folgende Zeile(n) hinzufügen:

extension=imagick.so
extension=intl.so

Und davon ab musst du in der von dir verwendeten PHP Version schauen, ob die Extension auch vorhanden ist.

Nehmen wir mal an, du würdest die letzte php-8.0-25 Version verwenden. Dann sollte die Datei imagick.so in folgendem Verzeichnis gelistet sein:

/usr/local/pd-admin2/php-8.0.25/lib/php/extensions/no-debug-non-zts-20200930

-rwxr-xr-x. 1 root root 482728 16. Nov 07:17 imagick.so

-rwxr-xr-x. 1 root root 450048 16. Nov 07:17 intl.so

Ok .. neue Update-Routine heruntergeladen:

wget http://download.pd-admin.de/seu3-2022112100.tar.gz

Dann entpackt und die se-update.sh ausgeführt.

Ergebnis:

Augenscheinlich scheint alles zu laufen.

Warum er allerdings bei 2 Endkunden das PHP plötzlich auf 8.1 statt 8.0 umgestellt hat, hat sich mir nicht richtig erschlossen.

Aber soweit ich sehen kann, scheint alles gut zu laufen.

Insofern:

Danke für die prompte Unterstützung!

Nope, das ist nicht der Fall. Läuft ja auch alles mit der SE einwandfrei. Nur updaten kann ich nicht.
Ich werde heute abend mal ein Backup machen und das ganze lokal durchspielen. Vielleicht finde ich dann ja mehr raus.

Mir auch nicht wirklich ... deswegen habe ich ja gefragt.

Aber aufgrund dieser Tatsache wird das Update dann nicht durchgeführt und es erfolgt ein Rollback.

Finde ich etwas unglücklich. Lief jahrelang problemlos durch und nun seit der 0.401 geht es nicht (mehr).

Ich habe ja schon überlegt, die Prüfung in der se-update.sh einfach auszukommentieren und zu schauen, was passiert, aber leider weiss ich nicht, was die Entwickler sich dabei gedacht haben und kann die Auswirkung nicht wirklich abschätzen.

Welche Version von pd-admin wird eingesetzt?

4.102

Welche Version der Serverumgebung wird eingesetzt?

0.401 Reihe 6

Welche Fehlermeldung erhalten Sie?

- siehe unten -

Wie sind die problematischen Dienste konfiguriert?

Standard SE Installation

Wenn ich ein Update der SE-Umgebung machen möchte, wird die Installation abgebrochen und es erfolgt ein automatischer Rollback.

Es erscheint die Fehlermeldung auf dem Bildschirm (und im Log):

checking subdirectory structure before importing changed files

/var/mysql: alt:Verzeichnis, zu importieren:Symbolischer Link

*** Import der neuen/ge▒nderten Dateien/Verzeichnisse ***

*** kann wegen eines Dateitypkonflikts nicht vorge- ***

*** men werden. ***

Wenn ich mir nun die data.inf und data2.inf anschaue, steht in der entsprechenden Zeile

data.inf -> DA 0000000000000000000000 /var/mysql

data2.inf -> 0,0

Im der Pd-Admin SE Umgebung ist /usr/local/pd-admin2/var/mysql ein symbolischer Link auf /home/mysql

Hat jemand eine Idee, wieso das Update hier nicht durchläuft?

Ich habe mir das jetzt mal näher angeschaut und bin zu folgender Erkenntnis gekommen:

a) Der Übergabeparameter $1 übergibt den Hostnamen und nicht die IP-Adresse oder die Port-Adresse

b) Das führt dazu, das jede Domäne in der Regel zweimal übergeben wird (einmal für den Port 80 und einmal für den Port 443).

c) Es gibt leider keine Unterscheidungsmöglichkeit, ob es der Container für Port 80 oder der Container für Port 443 ist.

Das führt dann dazu, das ich ohne großen Aufwand für beide Container nur den gleichen Inhalt hinterlegen kann.

Wenn ich also eine Proxy-Umleitung nur für SSL anlegen möchte, aber nicht für HTTP, dann müsste ich im Prinzip auch noch einen Zähler einbauen, um hier unterschiedliche Inhalte übergeben zu können.

Wäre es nicht möglich, den Port als Übergabeparameter $2 mit zu übergeben, damit man das direkt unterscheiden kann?

Tja,

dann lebt ihr im Land der Glücklichen und habt entweder kein MySQL 8 oder verwendet MySQL 8 auf einem System mit SSD.

Auf Systemen mit normalen Festplatten ist MySQL 8 in der Regel um den Faktor 5 - 10 bei UPDATE und INSERT Kommandos langsamer.

Deswegen dauert dann das Hochstarten des MySQL 8 auch wesentlich länger.

Als ich noch normale HDD Festplatten hatte, konnte es nach dem Update bis zu 5 Minuten dauern, bis der MySQL Server wirklich verfügbar war.

Durch den reinen Tausch auf eine SSD dauerte es dann nur noch 30 Sekunden. Also wirklich krass der Unterschied und auch in unendlich vielen Foren bis zum Ende ausdiskutiert (Tuning von Parametern, IIOPS , etc ...).

Standardmäßig wird MySQL im Verzeichnis /home/mysql abgelegt.

Ich würde gerne das Verzeichnis auf ein anderes Verzeichnis verlagern, um eine SSD nutzen zu können, die wesentlich mehr IOPS unterstützt.

Hat jemand hier im Forum Erfahrung, ob das im Zusammenspiel mit pd-admin möglich ist und welche Schritte dafür benötigt werden?

Ein Hard-Link dürfte ja ausscheiden, da anderes Volume und ob ein Soft-Link ausreichend wäre, vermag ich nicht so schnell zu beurteilen.

Ok, manchmal hilft es sich das genauer anzuschauen:

/usr/local/pd-admin2/var/mysql ist ein Symlink auf das eigentliche Data-Verzeichnis.

Den kann man einfach umbiegen, da die Update Skripts mit readlink immer den eigentlich Pfad auslesen und wiederherstellen.

Ich betreibe seit mehreren Monaten die Reihe 8 auf einem meiner Server und kann sagen:
- Sie läuft soweit stabil

- Die Datenbank-Performance ist mit herkömmlichen Festplatten wesentlich schlechter als mit MySQL 5.5
(MySQL 8 ist wohl sehr stark auf SSDs optimiert

-> Teilweise Abhilfe: innodb_buffer_pool_size sowie innodb_buffer_pool_instances so anpassen, das mher Arbeitsspeicher verwendet wird
-> Update und Inserts sind trotzdem immer noch deutlich langsamer als mit MySQL 5.5)

Muss man sich also seinen Use Case genau anschauen

Zum Thema Update wurde ja schon in anderen Forenbeiträgen aufgezeigt, das man erst alle Datenbanken exportieren muss, um sie dann in einer neuen Installation wieder zu importieren. Die dafür von Daniel Bradler bereitgestellten Skripte haben bei mir soweit einwandfrei funktioniert.

Gibt es eigentlich einen speziellen Grund, warum die Tabellen in der vadmin Datenbank noch im MyISAM Format sind?

Bzw. sprich was dagegen, diese nach InnoDB zu konvertieren?

Und wer dabei den Error 1067 bekommt:

Der Defaultwert für Date (0000-00-00) muss durch 1000-01-01 ersetzt werden.

0000-00-00 wird bei neueren mySQL Versionen nicht mehr als Defaultwert akzeptiert (zumindest wenn der Strict-Mode für Transaktionen gesetzt ist).

Ich habe immer wieder mal das Problem, das ich einzelne vhost Container mit benutzerdefinierten Einträgen ergänzen müsste, die ich aber so nicht ohne viel Aufwand einbinden kann, das die httpd_vhosts.pl die Änderungen immer wieder überschreibt.

Ich würde mir daher eine Erweiterung der httpd_vhosts.pl in der Form wünschen, das man die benutzerdefinierten Einträge in einem Ordner ablegen könnte und diese von der httpd_vhosts.pl zusätzlich mit eingelesen werden.

Beispiel:

/opt/pdadmin/etc/vhosts_custom

-> <domain-name>.ini

Der Vorteil wäre, das man zum Beispiel benutzerdefinierte Proxy-Einträge oder Spezialeinstellungen für Module hier ergänzen könnte.

In der Vergangenheit gab es schon mal aus der Community ein Plugin hierzu, das aber zum einen nicht weitergepflegt wurde und zum anderen das mehrfache Schreiben der httpd.conf (einmal durch die httpd_vhosts.pl, einmal durch das Modul-Addon) bedingte, was nicht unbedingt optimal für die Funktionsweise des Apache Webservers ist.

Ich kann das Problem auf meinen Systeme (Systeme mit Serie 4 und Serie nicht nachvollziehen.

Du bist dir schon im Klaren, das sowohl CentOS 6 als auch Serie 3 End of Life ist?

Ich würde dir empfehlen, mindestens auf CentOS 7 sowie Serie 4 zu wechseln.

Besser wäre, generell mal auf aktuelle Versionen zu gehen.

Davon ab solltest du vielleicht mal checken, ob die Verlinkung von Perl auf das Perl vom der pd-admin Umgebung zeigt.
Nicht das da Libraries nicht gefunden werden, weil nicht die pd-admin se perl Bibliotheken nicht angezogen werden.

Was mir auch noch aufgefallen ist (das habe ich aber schon seit der 4.81:

[Sun Jul 4 20:52:41 2021] administrator.cgi: get <http://www.pd-admin.de/download/VERSION> failed: _rc = <501> _msg = <Protocol scheme 'https' is not supported (Crypt::SSLeay not installed)> at /opt/pdadmin/www/administrator/administrator.cgi line 590.

[Sun Jul 4 20:52:41 2021] administrator.cgi: get <http://www.pd-admin.de/download/SE-LATEST> failed: _rc = <501> _msg = <Protocol scheme 'https' is not supported (Crypt::SSLeay not installed)> at /opt/pdadmin/www/administrator/administrator.cgi line 590.

In der WebGUI zeigt er auch folglich die neuen Versionen nicht mehr an ....

Wenn ich versuche auf pd-admin 4.82 zu updaten, erhalte ich folgende Fehlermeldung:

DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'function varchar(32) NOT NULL default '',

auid int(11) NOT NULL auto_increment' at line 4 at ./mysql-update.pl line 47.

Kann Tabelle audit nicht erstellen.

Kann MySQL-Datenbank nicht anpassen.

Kann natürlich daran liegen, das ich aktuell MySQL 8 einsetze; sollte aber eigentlich grundsätzlich nicht passieren ....

Update:

Scheint daran zu liegen, das das Keyword "function" ein reserviertes Wort ist.

Der generierte Befehl für die Erstellung der Tabelle lautet:

CREATE TABLE audit (

args text NOT NULL default '',

user int(11),

auid int(11) NOT NULL auto_increment,

status varchar(12),

function varchar(32) NOT NULL default '',

ts timestamp,

type enum('user','reseller','pop3'),

PRIMARY KEY (auid)

);

Packe ich das Keyword function in `` (also `function`) und nehme ihm beim args text NOT NULL noch das "default ''" weg, dann kann er die Tabelle zwar anlegen. Aber das hilft dann auch nicht wirklich -> pd-admin 4.82 läuft installationstechnisch durch, protokolliert aber nichts in die audit Tabelle.

Was passiert denn, wenn du folgenden Export vor der Installation machst:

export CFLAGS="-dM -E"

Hmm,

irgendwie haut das bei mir noch nicht so hin.

Er legt die Datei .dovceot-shared-mailboxes.db nicht an.

Kann es sein, das da noch eine kleine Konfiguration fehlt?