Beiträge von browsingman

Zitat von monderka

nimmst Du dann eine alternative in rbl.conf?
Ich habe erstmal all rbl.conf raus genommen und teste gerade mal dnsbl.sorbs.net und dnsbl-1.uceprotect.net

Für Empfehlungen was ihr nutzt und was das ggf. kostet würde ich mich sehr freuen.

Ich verwende auch den Eintrag dnsbl-1.uceprotect.net. Das funktioniert soweit super sauber.

Jetzt würde ich mir noch wünschen, das für Fail2ban eine Regel etabliert würde, die beim Suchstring ": in blacklist dnsbl-1.uceprotect.net." das ganze dann gegebenenfalls noch in der Firewall sperrt.

Mal so eine Frage in die Runde:

Es sieht so aus, als ob die PD-Admin SE Umgebung noch den SpamAssassin der 3er Reihe verwendet (Version 3.4.6)

Jetzt ist mir aufgefallen, das es auch den SpamAssassin 4.01 gibt.

Liegt da ein bestimmter Grund vor, bei dieser Version zu bleiben?

So,
mit starker Verzögerung jetzt endlich gelöst:
Der Preview-Generator der Nextcloud Instanz nutzt einen Cron-Job, welcher den convert Befehl des ImageMagick Pakets aufruft.

PHP wiederum zieht die PATH Variable abgeleitet von der Apache Instanz.

Per Default ist folgender Pfad gesetzt:

PATH=/command:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11R6

Ich habe jetzt die Datei /service/apache24/run wie folgt angepasst:
#!/bin/bash

hostname $(/opt/pdadmin/bin/hostname.pl)

PATH=/command:/usr/local/pd-admin2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

export PATH

killall -9 httpd 2>&1 >/dev/null

rm /usr/local/pd-admin2/httpd-2.4/logs/httpd.pid

ulimit -n 64000

cmd=(

exec /usr/local/pd-admin2/httpd-2.4/bin/httpd

-D NO_DETACH

-DSSL

)

"${cmd[@]}"

Das Ergebnis:
Apache gibt den Pfad an PHP weiter und PHP greift nun zuerst auf den convert Befehl aus der PD-Admin SE Umgebung zu.

Problem gelöst. Das könnte man ggfs. bei Neuinstallationen auch gleich berücksichtigen.

Update 2:

Mal auf meinem System nachgeschaut. Ich habe das ImageMagick Paket einmal als RPM auf dem System und einmal in der PD-Admin SE Umgebung

Scheint mir, als ob die lokale ImageMagick Version angezogen wird, die keinen HEIC Support hat. Die vom PD-Admin scheint nicht angezogen zu werden.

Jetzt muss ich nur noch verstehen, warum ....

Update:

Zu früh gefreut. Wenn ich versuche, HEIC Dateien zuzugreifen, bekomme ich folgende Fehlermeldung:

gickException Unsupported feature: Unsupported codec (4.3000) `/home/browsdb9/cloud_data/data/Sascha/files/Photos/Camera/20210125_174658.heic' @ error/heic.c/IsHEIFSuccess/146
File: /Sascha/files/Photos/Camera/20210125_174658.heic Imagick says:

Ich versuche noch zu verstehen, ob es an der Endung liegt. Aber unsupported codec klingt erstmal nach etwas anderen.

Dazu muss ich sagen, das ich versuche, das aus meiner Nextcloud Instanz zu nutzen.

Original-Message:

Danke für den Hinweis. Lag wohl eher daran, das php 8.3.8 dem Kunden fest zugewiesen war und nach dem letzten PD-Admin Update zwar das Verzeichnis noch existiert, aber nicht mehr befüllt war. Ich habe die ImageMagick Library jetzt explizit in die php.ini eingetragen und die aktuelle PHP Version aktiviert.

Sieht jetzt besser aus

Gerade mal in der aktuellen PD-Admin SE Version geprüft und:
Immer noch nicht das HEIC Format integriert.

Die Libpng Library ist sollte ja eigentlich gegeben sein (> 1.6.3 ist die Basis, damit ImageMagick mit HEIC Support kompiliert werden kann.

Es wäre schon super, wenn das mal beim nächsten Update mit berücksichtigt werden könnte.

Es gibt ja immer noch kleine Verbesserungen:

In der PECL.sh sollte noch der Package Configuration Pfad mitgegeben werden.

Einfach folgende Zeile noch in das Shell-Script am Anfang einfügen:

export PKG_CONFIG_PATH=/usr/local/pd-admin2/lib/pkgconfig/

Hintergrund:

Damit werden dann beim Kompilieren auch notwendige Abhängigkeiten (wie zum Bespiel libxml-2.0) gefunden. Das wird beispielsweise von xmlrpc benötigt.

Und xmlrpc ist bei PHP 8.2/PHP 8.3 noch nicht standardmäßig dabei, da der normale Kanal das noch nicht bereitstellt. Da hilft dann der Aufruf:

./pecl.sh install xmlrpc channel://pecl.php.net/xmlrpc-1.0.0RC3

Wobei ich mir das Shell-Script noch so angepasst habe, das es nicht immer alle PHP-Umgebungen aktualisiert, sondern nur punktuell diejenigen, welche ich aktuell einsetze.

Das obige Skript macht den Kopiervorgang ja immer (unconditional). Das fand ich etwas suboptimal und habe es etwas angepasst.

regenerate_mail_certs.sh updated:

#!/bin/bash
echo "Update mail certificates (if needed)"
echo
echo "Check hostname ..."
H=$1

if [ "${H}" == "" ]; then
    echo " ... no parameter given, read host name from config file"
    H=`/opt/pdadmin/bin/hostname.pl`
fi
if [ "${H}" == "" ]; then
   echo " ... Hostname not set ... exiting script."
   exit 11
fi
echo " ... Hostname is set to ${H}"


echo " ... check if certificate needs to be refreshed"
if [ "/opt/pdadmin/sslcerts/${H}-cacert" -ot "/usr/local/pd-admin2/share/imapd.cacert" ]; then
   echo " ...... Certificate is still valid, exiting script."
   exit 0
else
   echo " ...... Certificate is different, copy to mail services"
   set -e
   set -x
   cat /opt/pdadmin/sslcerts/${H}-key /opt/pdadmin/sslcerts/${H}-cert /var/qmail/control/smtpSd_dhparams4096.pem > /var/qmail/control/smtpSd_servercert.pem
   cat /opt/pdadmin/sslcerts/${H}-key /opt/pdadmin/sslcerts/${H}-cert /opt/pdadmin/sslcerts/${H}-cacert > /var/qmail/control/servercert.pem
   cat /opt/pdadmin/sslcerts/${H}-key /opt/pdadmin/sslcerts/${H}-cert /opt/pdadmin/sslcerts/${H}-cacert > /usr/local/pd-admin2/share/imapd.pem
   cat /opt/pdadmin/sslcerts/${H}-cacert > /usr/local/pd-admin2/share/imapd.cacert
   cat /opt/pdadmin/sslcerts/${H}-cacert > /etc/ssl/cert.pem
   set +e
   set +x
   echo " ...... restarting mail services"
   set -e
   set -x
   /usr/local/bin/svc -du /service/dovecot22 /service/qmail-*
   set +e
   set +x
   echo " Servics restarted ... existing script"
   exit 0
fi
[root@host bin]# vi regenerate_mail_certs.sh 
[root@host bin]# vi regenerate_mail_certs.sh 
[root@host bin]# ./regenerate_mail_certs.sh 
Update mail certificates (if needed)

Check hostname ...
 ... no parameter given, read host name from config file
 ... Hostname is set to host.zk1.de
 ... check if certificate needs to be refreshed
 ...... Certificate is still valid, exiting script.

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?