Beiträge von browsingman

    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.

    Soll das bedeuten, das Du noch eine SE der Reihe 1-3 installiert hast?


    Falls schon Reihe 4 installiert ist, reicht es doch, die pd-admin 64bit Version drüberzuinstallieren und gut ist.

    Und falls es wirklich nicht funktionieren würde, kann man die 32bit Version einfach wieder drüberinstallieren.

    UPDATE:
    Ich habe es zum Laufen bekommen.

    Vorgehensweise:


    Runterladen des Source-Codes

    Code
    git clone https://github.com/Imagick/imagick.git


    Anpassen der Datei /usr/local/pd-admin2/bin/MagickWand-config (dort den Pfad auf die pkg-config überall austauschen, der verweist aktuell auf einen nicht existierenden Pfad).


    Durchführen der Konfiguration und Compilierung:

    Code
    /usr/local/pd-admin2/php-8.0.3/bin/phpize
    PKG_CONFIG_PATH=/usr/local/pd-admin2/lib/pkgconfig/
    export PKG_CONFIG_PATH
    ./configure CFLAGS="-I/usr/local/pd-admin2/include/ -I/usr/local/pd-admin2/include/ImageMagick-6/ -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16" --with-php-config=/usr/local/pd-admin2/php-8.0.3/bin/php-config --bindir=/usr/local/pd-admin2/bin --includedir=/usr/local/pd-admin2/include --libdir=/usr/local/pd-admin2/lib:/usr/local/pd-admin2/syslib4:/usr/local/pd-admin2/syslib3:/usr/local/pd-admin2/syslib:/usr/local/pd-admin2/lib
    make clean
    make

    Das Compilat liegt dann unterhalb des Ordners imagick im Ordner modules.


    Test der Abhängigkeiten / Installation der Library

    Abschließend noch die php.ini anpassen, um die Extension imagick.so zu aktivieren sowie den FPM-Service neu durchstarten.


    Und danach sollte es laufen.

    Bei den aktuellen Server-Umgebungen ist im PHP 8 noch kein imagick.so Modul enthalten.


    Über pecl läßt es sich nicht installieren, da dort die Änderungen aus dem aktuellen git noch nicht eingepflegt sind.

    Ich habe daher die Sourcen runtergeladen, kann sie aber nicht so final kompilieren, das sie mit dem php 8 funktioniert.


    Die aktuell in git eingepflegte imagick Version soll aber mit php 8 lauffähig sein.


    Bisherige Vorgehensweise:

    Code
    git clone https://github.com/Imagick/imagick.git
    /usr/local/pd-admin2/php-8.0.3/bin/phpize
    ./configure CFLAGS="-I/usr/local/pd-admin2/include/ -I/usr/local/pd-admin2/include/ImageMagick/" --with-php-config=/usr/local/pd-admin2/php-8.0.3/bin/php-config --bindir=/usr/local/pd-admin2/bin --includedir=/usr/local/pd-admin2/include --libdir=/usr/local/pd-admin2/lib:/usr/local/pd-admin2/syslib4:/usr/local/pd-admin2/syslib3:/usr/local/pd-admin2/syslib:/usr/local/pd-admin2/lib
    make


    Das Konfigurieren schlägt fehl, da er den Verweis auf die MagickWand Header nicht findet. Wenn ich aus dem include Verzeichnis der pdaminse die Dateien übernehme, kann ich zwar die Konfiguration machen und auch das Erstellen des .so Files durchführen, aber am Ende funktioniert es nicht, weil in dem Kompilat libpath Verweise auf das Stammsystem sind und nicht auf die pdadminse Umgebung referenziert wird. Ein make test schlägt auch entsprechend fehl.


    UPDATE:

    Mit dem geänderten configure Aufruf, der dei Include Files dem make mitgibt, läßt sich das Modul kompilieren.

    Wenn ich allerdings das Modul im php 8 einbinde, kann ich den FPM Service nicht mehr starten, der Start schlägt fehl.


    Hat jemand eine Idee, wie man dennoch zu einem funktionsfähigen Kompilat gelangt bzw. woran es liegt, das sich der FPM Service mit eingebundenen Modul nicht mehr starten läßt?

    Wenn die Verbindung fehlschlägt, kommen im wesentlichen 3 Gründe in Betracht:
    1. Verbindung abgelehnt, weil geblacklistet (aus welchen Gründen auch immer)
    2. Verbindung abgelehnt, weil eine Verschlüsselung gefordert ist
    (viele Server setzen mittlerweile TLS 1.2 als Mindestlevel voraus)
    3. Verbindung abgelehnt, weil ein Kommunikationsfehler auftritt (Socket-Fehler, MTU-Size, fehlerhafte Namensauflösung, Netzbereich per Firewall blockiert)

    -> Blockierte Netwerkbereiche


    Das muss dann halt alles geprüft werden.

    Abseits dessen, das diese Konfiguration sehr ungewöhnlich ist und sicherlich auch geeignet ist, den eigenen lokalen Internet-Anschluß gut auszulasten, versuche ich mal zu verstehen, was jetzt die eigentliche Frage ist:
    a) Wie kann ich die Mails mit einer anderen IP-Adresse versehen?

    b) Fehlen noch iptables-Einträge (generell)?


    Falls die Frage sich auf Punkt a) bezieht, so ist meine Einschätzung, das die für den Versand verwendete eMail Adresse ja nicht auf der IP-Konfigurationsebene festgelegt wird, sondern in dem betreffenden Service (in diesem Falle wohl qmail(-smtpd).


    Somit sollte es eigentlich ausreichend sein, in qmail die IP-Konfiguration zu hinterlegen, welche verwendet werden soll.

    Das müsste dann folgende Datei sein, sofern der entsprechende qmail-patch eingebunden wurde:

    /var/qmail/control/outgoingip


    Normalerweise existiert diese Datei nicht, so das die jeweilige IP des Hosts verwendet wird, auf welchem der Dienst läuft.

    Ich bin mir allerdings auch nicht mehr ganz sicher, welche qmail-Patches seitens pd-admin berücksichtigt worden sind.


    Grundsätzlich ist es aber eine Konfiguration, welche nicht auf Firewall-Ebene mit iptables anzupassen wäre, sondern in der jeweiligen Konfiguration des Mail-Services, welcher für den Versand verwendet wird.

    Mit 0.375 wurde als Neuerung coreruleset mit aufgeführt.

    Gleichwohl ist in den Templates dazu keine Konfiguration in der pdadmin SE-Umgebung zu finden.

    Ich vermute mal, das hier noch weitere Anpassungen / Konfiguration von Herrn Bradler für Folge-Releases geplant sind.


    Aus meiner Sicht müsste hier auch eine .conf Datei für mod_security beigefügt werden.


    Ich habe testhalber mal eine Datei modsecurity.conf erstellt:

    Ergänzend habe ich dann noch folgende Zeilen in der httpd24.conf-template eingefügt:

    Code
    include /usr/local/pd-admin2/httpd-2.4/conf/modsecurity.conf
    include /usr/local/pd-admin2/httpd-2.4/conf/coreruleset-3.3.0/crs-setup.conf
    include /usr/local/pd-admin2/httpd-2.4/conf/coreruleset-3.3.0/rules/*.conf


    Im Ordner coreruleset-3.3.0 sowie im Ordner coreuleset-3.3.0/rules habe ich die *.example in *.conf umbenannt und in der Konfigurationsdatei crs-setup.conf noch folgende Regel aktiviert, damit die gängigen Produkte wie nextcloud und wordpress nicht pauschal geblockt werden.


    Code
    SecAction \
    "id:900130,\
    phase:1,\
    nolog,\
    pass,\
    t:none,\
    setvar:tx.crs_exclusions_drupal=1,\
    setvar:tx.crs_exclusions_dokuwiki=1,\
    setvar:tx.crs_exclusions_nextcloud=1,\
    setvar:tx.crs_exclusions_wordpress=1


    Grundsätzlich würde das nach einem Neustart des Apache Webservers so gut funktionieren, ABER es muss noch eine weitere Voraussetzung erfüllt sein:

    Das mod_security Modul müsste mit JSON Support kompiliert werden. Aktuell ist es das nicht.


    Es wäre schön, wenn man diesen "Bug" noch mit dem nächsten SE-Update lösen würde ;-)

    Hmm,


    ich habe dehydrated in der aktuellen Version runtergeladen. Das ist soweit ich weiss die 0.7


    Nach Recherche im Internet:

    EC PRIVATE KEY not recognized


    Demzufolge kann man wohl mit der Option KEY_ALGO=RSA das Verhalten ändern.

    Ausprobiert habe ich es allerdings noch nicht und weiß auch nicht, ob das beim Verlängern der Zertifikate so angewendet wird. Das sehe ich dann in 3 Monaten.


    Unabhängig hiervon scheint ja KEY_ALGO=SECP384R1 wohl sicherere Keys zu erzeugen, so das es natürlich sinnwohl wäre, alle Produkte so anzupassen, das sie es unterstützen.

    Ich bin mir nicht sicher, ob es eine Nebenwirkung der Umstellung auf dehydrated ist, aber seit ich das umgestellt habe, bekommen Anwender beim Versand von Mails per smtp mit TLS immer folgende Meldung:

    Fehler bei der Verbindung:

    454 TLS no valid RSA private key: error: 02001002:system library:fopen:No such file or directory (#4.3.0).


    Die Datei /var/qmail/control/servercert.pem existiert aber.


    Einziger Unterschied zu früher:

    Statt ein Block "Beginn Private Key" sind jetzt die folgenden zwei Blöche enthalten

    -----BEGIN EC PARAMETERS-----

    <Inhalt entfernt>

    -----END EC PARAMETERS-----

    -----BEGIN EC PRIVATE KEY-----

    <Inhalt entfernt)

    -----END EC PRIVATE KEY-----


    Kann es sein, das der qmail Patch ggfs. das neue Format noch nicht unterstützt?


    Nachtrag:

    Alte Datei nochmal eingespielt (das letsencrypt Zertifikat ist Gott sei Dank noch gültig). Damit geht es.
    Der QMAIL Patch hat also noch keine Unterstützung für elliptische Kurven bzw. den neuen Format.


    Hoffentlich gibt es da bald einen Patch für ;-)

    Am Ende des Tages ist das Rätsel einfach zu lösen.


    Der dehydrated Aufruf für die Registrierung braucht noch die Angabe des Config-Pfades für die Registrierung.

    Sonst legt er den Accounts Ordner standardmäßig unterhalb des Aufrufpfades ab (also /opt/pdadmin/bin statt /opt/pdadmin/etc).


    Mit Angabe des Config-Pfades klappt auch der nachgelagerte letsencrypt --import Befehl reibungslos.


    Also zur Registrierung von dehydrated folgenden Befehl ausführen:

    /opt/pdadmin/bin/dehydrated --config /opt/pdadmin/etc/dehydrated.conf --register --accept-terms


    Den Import hätte ich mir allerdings ein wenig anders vorgestellt.

    Der hat faktisch einfach alle Zertifikate bei letsencrypt komplett neu beantragt.

    Ob das so im Sinne des Erfinders ist oder man nicht einfach die bestehenden Zertifikate übernehmen hätte können?

    Die ist wohl nicht ganz korrekt (wahrscheinlich nicht alle Klassen einkompiliert?):

    Can't load '/opt/pdadmin/lib/DBI.so' for module DBI: /opt/pdadmin/lib/DBI.so: falsche ELF-Klasse: ELFCLASS64 at PERL2EXE_STORAGE/DynaLoader.pm line 230.

    at PERL2EXE_STORAGE/DBI.pm line 261

    BEGIN failed--compilation aborted at PERL2EXE_STORAGE/DBI.pm line 261.

    Compilation failed in require at /opt/pdadmin/bin/letsencrypt line 11.

    BEGIN failed--compilation aborted at /opt/pdadmin/bin/letsencrypt line 11.


    Die letsencrypt Datei ist auch wesentlich kleiner ...

    Ich erhalte beim Import Versuch immer folgende Meldung:

    Dies erscheint auch, wenn der dehydrated Registrierungsbefehl schon ausgeführt wurde.


    Gibt es da noch einen weiteren zu berücksichtigenden Schritt oder ist das nur informativ während des Imports und nachher funktioniert trotzdem alles?


    Nachtrag:

    In der /opt/pdadmin/etc/dehydrated.conf steht

    CERTDIR=/opt/pdadmin/sslcerts/__dehydrated

    WELLKNOWN=/opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge

    CONTACT_EMAIL=<meine email adresse>


    Das Verzeichnis __dehydrated ist aber nicht existent.

    Hallo zusammen,


    ich musste gerade feststellen, das ich in meiner Nextcloud Installation keine Bilder im Format HEIC anschauen kann.

    Nextcloud verlässt sich hier auf das ImageMagick Modul.


    Da sind auch irrsinnig viele Formate drin abgebildet, aber leider fehlt das HEIC Format.

    Vielleicht könnte man das ja in einem der nächsten Updates zu pdadminse Umgebung noch mit reinkompilieren/aufnehmen?