Beiträge von Twilo

    Wenn man nur $HOME/logs angibt, kommt /root/logs raus, da die Variable schon in der backup.pl ausgewertet wird, durch \ kann man es eigentlich an einen Skript durchreichen, warum es dann in der backup_user.sh nicht ausgewertet wird … hm …


    der Aufruf sieht dann wie folgt aus

    Code
    1. USER 22357 14.5 0.0 26140 2576 pts/0 SN+ 09:19 0:00 tar --preserve-permissions --exclude=$HOME/logs -czf /backup/user/USER/0/backup.tar.gz /home/USER

    erwartet hätte ich

    Code
    1. USER 22357 14.5 0.0 26140 2576 pts/0 SN+ 09:19 0:00 tar --preserve-permissions --exclude=/home/USER/logs -czf /backup/user/USER/0/backup.tar.gz /home/USER

    :/

    Hallo,


    beim Angebot ist die Option "SAPI-Änderung erlaubt" deaktiviert, warum hat der Kunde trotzdem die Möglichkeit "PHP ausführen über" zu ändern?


    Wie kann verhindert werden, dass der Kunde Werte an der php.ini ändern kann?

    Warum wird beim Kunden im Homeverzeichnis neuerdings eine php.ini angelegt, obwohl die Variable phprc in der pdadmin.conf nicht auf 'home' gesetzt ist?


    Wie kann das Kundenmenü "FTP-Konten" deaktiviert werden? Wir verwenden ausschließlich SFTP.


    pd-admin: 4.60

    SE: 0.325 (Reihe 3)


    mfg

    Twilo

    Laut

    Code
    1. Certificate did not match expected hostname: acme-v02.api.letsencrypt.org.

    passt das Zertifikat des Servers nicht zum Hostnamen. Worauf löst der Hostname auf?

    wie meinst Du das?

    Was gibt

    Shell-Script
    1. echo "" | openssl s_client -servername acme-v02.api.letsencrypt.org -connect acme-v02.api.letsencrypt.org:443 | openssl x509 -noout --dates

    aus?

    Code
    1. > echo "" | openssl s_client -servername acme-v02.api.letsencrypt.org -connect acme-v02.api.letsencrypt.org:443 | /usr/local/pd-admin2/bin/openssl x509 -noout -dates
    2. depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
    3. verify return:1
    4. depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    5. verify return:1
    6. depth=0 CN = acme-v02.api.letsencrypt.org
    7. verify return:1
    8. DONE
    9. notBefore=Dec 21 01:51:44 2018 GMT
    10. notAfter=Mar 21 01:51:44 2019 GMT

    Woran kann es liegen, dass das Zertifikat für eine Domain nicht aktualisiert wurde?

    Code
    1. Saving debug log to /var/log/letsencrypt/letsencrypt.log
    2. Non-interactive renewal: random delay of 308 seconds
    3. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    4. Processing /etc/letsencrypt/renewal/www.NNN.de.conf
    5. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    6. Cert is due for renewal, auto-renewing...
    7. Plugins selected: Authenticator webroot, Installer None
    8. Certificate did not match expected hostname: acme-v02.api.letsencrypt.org. Certificate: {'subjectAltName': [('DNS', 's3.XXX.de'), ('DNS', 'www.s3.XXX')], 'subject': ((('commonName', u's3.XXX.de'),),)}
    9. Attempting to renew cert (www.siebenfelder.de) from /etc/letsencrypt/renewal/www.siebenfelder.de.conf produced an unexpected error: hostname 'acme-v02.api.letsencrypt.org' doesn't match either of 's3.XXX.de', 'www.s3.XXX.de'. Skipping.


    Nach einem Aufruf von /opt/pdadmin/bin/letsencrypt http://www.NNN.de, wurde das Zertifikat ersetzt.

    Bei der Meldung stand, dass das Zertifikat am 18.12.2018 abgelaufen ist …


    Wie kann ich überprüfen, bei welchen Domains das noch vorkommt/vorkam?


    mfg

    Twilo

    Hallo,


    es ist seit Jahren so, dass bei Debian und Ubuntu /bin/sh ein Link auf /bin/dash ist


    https://en.wikipedia.org/wiki/Almquist_shell#Slimness

    Zitat

    Because of its slimness, Ubuntu decided to adopt the dash as the default /bin/sh[4] [5] in 2006.
    […]
    Dash became the default /bin/sh in Ubuntu starting with the 6.10 release in October 2006.[8] Dash replaced ash and became the default /bin/sh in Debian 6 (Squeeze).[9]


    Macht es nicht eher Sinn, in den run-Files /bin/sh durch /bin/bash zu ersetzen? :/


    mfg

    Twilo