Beiträge von Sumeragi

    Zitat

    Original von IP-Logic
    OK, meine Hoffnung war, das es inzwischen einen "Knopf-Druck-Standardweg" gäbe.


    Eine Knopfdruck Lösung gibt es leider nicht. Ich halte Let's Encrypt für den professionellen Einsatz jedoch für nicht ungeeignet. In meinem Blog habe ich eine Anleitung für die Einrichtung in pdadmin geschrieben. Bei mir läuft dies problemlos.


    Und sicherlich gibt es Möglichkeiten Zertifikate regelmäßig zu prüfen, so dass bei möglichen Problemen diese schnell auffallen.


    Zitat

    Original von IP-Logic
    -wenn die Serverdomain abgesichert ist, ist dann auch jeder Mailserver der einzelnen Domains automatisch abgesichert oder muss das für jede Domain gemacht werden?


    Der Mailserver kann nur ein Zertifikat verwenden. Dieses sollte identisch mit dem Hostnamen sein.


    Wird für den Mailverkehr die Kundendomain verwendet, kommt es in der Regel zu einer Zertifikatswarnung.


    Zitat

    Original von IP-Logic
    -in der Serverkonfig ist letencrypt aktiv und in der Angebotsverwaltung angehakt. Müssen die Kunden selbst im Customer Account noch etwas aktivieren??


    Wenn Let's Encrypt in der Serverkonfiguration und im Angebot aktiviert ist muss der Kunde nichts mehr machen.

    Segmentaktion fault deutet auf ein Problem beim Arbeitsspeicher hin. qmail-smtpd wird mit einem softlimit ausgeführt. Oft ist dies zu niedrig. Wie hoch ist der Wert in

    Code
    /service/qmail-smtpd/run


    ? Bei meinem Server ist der Wert auf

    Code
    [..] softlimit -m 75000000 [..]

    gesetzt. Ich würde den werde einmal sukzessiv erhöhen, bis der Fehler nicht mehr auftritt.

    Vielleicht hilft folgendes bei der Fehlersuche:


    1. Wrapper Skript erstellen:


    Code
    cat /opt/pdadmin/bin/debug_greylist.sh
    #!/bin/bash
    strace -o /tmp/smtp_greylist.log-$(date "+%s") /opt/pdadmin/bin/smtp_greylist.pl "$@"


    Code
    chmod 755 /opt/pdadmin/bin/debug_greylist.sh


    2. qmail anpassen



    Unter /tmp/smtp_grelist.log-* finden sich dann die Logs zu der Ausführung des Skripts.

    Der Fehler sagt mir so leider nichts... :( Eingetragen/Aufgerufen wird die Datei hier:



    Vielleicht kann man die Datei über ein wrapper script aufrufen und darin debuggen?

    Mir ist leider nicht klar was mit dem Hash gemeint ist. Soll die Mail unkenntlich gemacht werden?


    Es gibt für Dovecot ein Plugin, um Mails zu verschlüsseln und entschlüsseln:


    https://wiki.dovecot.org/Plugins/MailCrypt


    Damit wären Mails zumindest nicht unmittelbar lesbar. Wenn man jedoch root Zugriff hat, kann man trotzdem den Key auslesen und Nachrichten entschlüsseln. Und bei der Verarbeitung der Mails, also Annahme bis Speicherung, bleibt die Mail unverschlüsselt.
    Daher sollte es in jedem Fall Ziel sein den root account sehr gut abzusichern und nach Möglichkeit nur wenigen Zugriff darauf zu geben.

    Zitat

    Original von Twilo
    ja einzeln sieht es korrekt aus, ist nur die Frage, ob es an den neuen Befehl korrekt übergeben wird, ich vermute nicht ;)


    Ja verstehe. Wobei dies doch nur gemacht werden muss, wenn eine neue Shell (Subshell) gestartet wird. Dies passiert hier ja nicht ?(


    Analog dazu kann ich ja einfach PATH=/usr/local/pd-admin2/php-7.2.5/bin/:$PATH setzen. Wenn man nun php -v oder pecl install redis aufruft, werden die Binaries aus /usr/local/pd-admin2/php-7.2.5/bin/ verwendet. Gleiches gilt doch dann auch für das Skript.


    Ich habs jetzt erst einmal in einer Zeile belassen, da dies am Ergebnis nichts ändert ;)

    Wenn ich mir die Zeilen ausgeben lasse kommt:


    Code
    [...]
    /usr/local/pd-admin2/php-7.2.5/bin:/usr/local/pd-admin2/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/root/bin
    /usr/local/pd-admin2/php-7.2.5/bin/pecl install blub


    Sieht mir also korrekt aus. Ich lasse mich aber gern eines Besseren belehren.


    Die Semikolons habe ich teils entfernt, da diese afaik nur zum Trennen von Befehlen in der gleichen Zeile benötigt werden. Ein Zeilenumbruch reicht der Bash zur Trennung aus.

    Danke für die Verbesserungen! So ist der Code auch ordentlicher ;) Ich habe ihn auch noch mal etwas abgeändert. Einige Semikolons werden nicht benötigt und statt


    Code
    PATH="${DIR}:${PATH_O}" ${DIR}/pecl install "$1";


    steht dort nun


    Code
    PATH="${DIR}:${PATH_O}" ${DIR}/pecl "$@";


    Damit kann man dann u.a. Extensions wieder deinstallieren und upgraden.


    Ich habe dazu mal ein HowTo Thread erstellt, da dieser Thread soweit erledigt ist.


    PHP Extensions mit PECL installieren

    Möchte man PHP Extensions installieren, kann dies mittels der pecl Binary durchgeführt werden. Diese wird in der Serverumgebung mitgeliefert. Da je PHP einmal die Extension installiert werden muss, hilft hier folgendes Skript:



    Verwendet werden kann das Skript im Grunde wie die pecl Binary selbst. In den Beispielen wurde das Skript als pecl.sh abgespeichert.


    Installieren von Extension

    Code
    ./pecl.sh install <extensionName>


    Deinstallieren von Extension

    Code
    ./pecl.sh uninstall <extensionName>


    Upgrade von Extension

    Code
    # Zeigt verfügbare Upgrades an
    ./pecl.sh list-upgrades
    
    
    # Aktualisiert ein bestimmtes Paket/Extension
    ./pecl.sh upgrade <extensionName>


    Original Code aus Thread: REDIS Cache nutzen


    Danke Twilo für die Verbesserungen

    Zitat

    Original von Twilo
    warum merkst Du Dir den PATH und setzt ihn danach wieder zurück? Das ist doch unnötig ;)


    Ja, im Grunde schon. Nur wächst die PATH Variable durch die Schleife immer weiter an. Am Ende sieht es dann so aus:


    Code
    /usr/local/pd-admin2/php-7.2.4/bin:/usr/local/pd-admin2/php-7.2.3/bin:/usr/local/pd-admin2/php-7.1.16/bin:/usr/local/pd-admin2/php-7.1.15/bin:/usr/local/pd-admin2/php-7.0.29/bin:/usr/local/pd-admin2/php-7.0.28/bin:/usr/local/pd-admin2/php5-5.6.35/bin:/usr/local/pd-admin2/php5-5.6.34/bin:/usr/local/pd-admin2/php5-5.5.38/bin:/usr/local/pd-admin2/php5-5.4.45/bin:/usr/local/pd-admin2/php5-5.3.29/bin:/usr/local/pd-admin2/php5/bin:/usr/local/pd-admin2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin


    Mir ist schon bewusst, dass die Variable nur während der Skriptlaufzeit so aussieht und dies die weitere Ausführung auch nicht beeinflusst... mich störte es aber irgendwie :P


    Zitat

    Original von Twilo
    Muss es nicht auch ./pecl install "$1"lauten?


    Richtig, danke! Der Fehler fiel mir nicht auf, da /usr/local/pd-admin2/bin/ in meiner PATH Variable enthalten ist und dort auch eine pecl Binary liegt. So sollte es aber richtig sein:


    Zitat

    Original von Sumeragi
    Sicherlich kann dies auch per Skript automatisiert werden.


    Habe mich mal dran gemacht :)



    Für


    Code
    yum -y install autoconf


    muss bei Debian Systemen natürlich das passende Äquivalent genutzt werden. Ausgeführt werden kann es dann mit


    Code
    $ pecl.sh redis


    Damit wird dann die redis Extension für alle PHP Versionen >= PHP 5.3 installiert.

    Ich habe dies nur über die GUI gemacht. Man kann dies in der Kommandozeile auch mit


    Code
    /opt/pdadmin/bin/select-webserver.sh [AP22|AP24]


    machen.


    Bei mir sehe die Stellen in der pdadmin.conf so aus:



    Ich bin aber gerade am überlegen... Es kann sein, dass ich die letzte Zeile


    Code
    $apacherestart = '/usr/local/pd-admin2/httpd-2.4/bin/apachectl graceful';


    vor Urzeiten selber eingefügt hatte. Die pdadmin.conf habe ich jedenfalls schon sehr sehr lange nicht mehr angerührt gehabt.


    ---


    Der Apache 2.4 läuft bei Ihnen jedenfalls und deswegen kann der Apache 2.2 nicht gestartet werden. Vermutlich liegt dies tatsächlich am falsche Restart Befehl in der pdadmin.conf. Versuchen Sie es mal mit der Anpassung wie oben angegeben.

    Zitat

    Original von Twilo
    woher kommt dieser Pfad?


    Ich vermute der Pfad ist in der letsencrypt binary fest implementiert. Zumindest habe ich weder in der DB, noch pdadmin.conf eine entsprechende Angabe gesehen. Sobald also ein Zertifikat für den Server Hostnamen ausgestellt werden soll, wird dieser Pfad verwendet.


    Zitat
    Code
    There were too many requests of a given type :: Error creating new authz :: too many failed authorizations recently: see [URL]https://letsencrypt.org/docs/rate-limits/[/URL]
    Please see the logfiles in /var/log/letsencrypt for more details.

    :evil: ;(


    Das ist natürlich jetzt ärgerlich. Aber das sollte in einer Stunde wieder funktionieren.


    EDIT:

    Zitat

    EDIT: warum überhaupt --email daniel@bradler.com ?! verwirrt


    Vermutlich ist auch dies in der binary so implementiert...


    Man kann dies aber glaub ich unter


    Code
    /etc/letsencrypt/accounts/...../regr.json


    anpassen. Ist aber nicht getestet...

    Zitat

    Original von serverfreak1982
    Seit der Umstellung auf Apache 2.4 funktioniert die (ich nenne sie mal) Logration bzw. der Reload des Apache nicht mehr:


    ... daher ging ich davon aus, dass die Umstellung quasi gerade erfolgte und es zu den Fehlern kam.



    Die Fehlermeldung ist eigentlich klar. Port 80 ist belegt und es kann kein Service dafür gestartet werden. Daher ist interessant zu wissen, welcher Dienst aktuell auf Port 80 lauscht:


    Code
    $ lsof -i:80
    COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
    httpd    551 root    4u  IPv6  14954      0t0  TCP *:http (LISTEN)
    httpd   6313  www    4u  IPv6  14954      0t0  TCP *:http (LISTEN)
    httpd   6314  www    4u  IPv6  14954      0t0  TCP *:http (LISTEN)
    httpd   6315  www    4u  IPv6  14954      0t0  TCP *:http (LISTEN)
    httpd   6316  www    4u  IPv6  14954      0t0  TCP *:http (LISTEN)


    Mit


    Code
    $ ps aux | grep httpd


    bekommt man dann die Prozesse + Pfad ausgegeben. Bsp:


    Code
    [...]
    root 551 0.0 0.3 131408 5664 ? Ss 21:50 0:00 /usr/local/pd-admin2/httpd-2.4/bin/httpd -D NO_DETACH -DSSL
    [...]


    /usr/local/pd-admin2/bin/apachectl restart ist in sofern falsch, da diese Binary für den Apache 2.2 ist. Da Port 80 bereits belegt ist, kommt es zu dem Fehler. Wenn der Apache 2.4 verwendet wird muss


    Code
    /usr/local/pd-admin2/httpd-2.4/bin/apachectl


    verwendet werden. Zum manuellen Neustarten des Apache sollte aber besser


    Code
    $ svc -du /service/apache24


    verwendet werden.

    Zitat

    Original von Twilo
    In /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/ wird aber während des Aufrufes immer noch keine Datei erzeugt :(


    Das liegt daran, dass weiterhin /usr/local/pd-admin2/htdocs als WebRoot beim certbot verwendet wird.


    Zitat

    Original von Twilo

    Code
    [...]
    Using the webroot path /usr/local/pd-admin2/htdocs for all unmatched domains.
    [...]


    Wenn /opt/pdadmin/etc/ssl-validation verwendet werden soll, müsste in diesem Fall der certbot einmal manuell ausgeführt werden. Den Befehl findet man auch im letsencrypt log unter /var/log/letsencrypt.


    Ich denke auch nicht, dass dies ein DNS Problem, sondern viel mehr ein Konfig Problem ist...

    Ich habe es bei mir für PHP 7.2 wie folgt installiert:


    Code
    $ cd /usr/local/pd-admin2/php-7.2.4/bin/
    $ export PATH=/usr/local/pd-admin2/php-7.2.4/bin:$PATH
    $ pecl install redis


    Damit wurde /usr/local/pd-admin2/php-7.2.4/lib/php/extensions/no-debug-non-zts-20170718/redis.so installiert. Dies kann analog für jede PHP Version durchgeführt werden. Sicherlich kann dies auch per Skript automatisiert werden.


    Für die Installation wird auch autoconf benötigt:


    Code
    $ yum install autoconf