Beiträge von monderka

    Nach dem Dist-Upgrade von debian9 zu debian10 und Update der SE-Reihe6-370 und PD-Admin v4.72_64 verhält sich pecl.sh nun so.

    Bei PHP8 denke ich liegt es einfach daran das es noch zu früh ist und deshalb nicht geht. Woher der Speicherzugriffsfehler kommt weiß ich nicht.


    sorry, das hatte ich zwar gelesen, aber gerade nicht auf dem Schirm. Wollte auch nur nochmal drauf hinweisen, denn im ersten Moment schreckt ja so eine Fehlermeldung. Wenn jetzt noch das certbot-auto Problem gelöst wird bin ich schon wieder glücklich ;-)

    Auf dem Debian10 System kommt folgende Meldung während ./update.sh


    ......

    mysql: [Warning] Using a password on the command line interface can be insecure.

    ln: die symbolische Verknüpfung '/lib64/libssl.so.10' konnte nicht angelegt werden: Die Datei existiert bereits

    ln: die symbolische Verknüpfung '/lib64/libcrypto.so.10' konnte nicht angelegt werden: Die Datei existiert bereits

    Writing /usr/local/pd-admin2/conf/httpd.conf

    Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf

    webserver = <AP24>

    Apache 24 is already selected

    Update erfolgreich.


    Das /lib64 - Verzeichnis hat bereits Links, damit sollte diese Meldung keinen erschrecken müssen:

    10616835 0 lrwxrwxrwx 1 root root 32 Mai 1 2019 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.28.so

    10616836 0 lrwxrwxrwx 1 root root 43 Dez 9 11:23 libcrypto.so.10 -> /usr/local/pd-admin2/lib/libcrypto.so.1.0.0

    10616834 0 lrwxrwxrwx 1 root root 40 Dez 9 11:23 libssl.so.10 -> /usr/local/pd-admin2/lib/libssl.so.1.0.0

    Also die Funktionsfähigkeit des Certbot mit symlink auf die Snap-Installation hängt direkt von der Namensgebung des symlinks ab.


    Im Verzeichnis /op/pdadmin/bin funktioniert der certbot-Link, aber der certbot-auto Link nicht.


    Also, der certbot-auto ist wohl für ALLE Debian-System und Ubuntu nicht länger unterstützt:


    Quelle: https://community.letsencrypt.…an-based-systems/139702/2

    What happened?

    In our 1.10.0 release on Tuesday, we deprecated certbot-auto, one of the ways to install Certbot, on Debian based systems including Ubuntu. In our 1.11.0 release, we plan to deprecate the script on every OS. It is only certbot-auto that we deprecated. Our other distribution methods or Certbot more generally was not deprecated on Debian.

    The behavior you can expect from certbot-auto on a deprecated OS is that if you had run the script before and had an existing Certbot installation from it, that installation will continue to work, however, you will no longer receive updates and a message will be printed every time the script is run explaining this. If you do not have an existing certbot-auto installation, the script will refuse to install Certbot and say that you need to use a different installation method.

    Why did it happen?

    If certbot-auto had been working well for you, I'm glad to hear it, but it became infeasible for our small team to maintain. It's a custom, self-updating shell script that tries to support all popular UNIX OSes. Keeping this script working in all the different environments out there and the changes being made to them was just too much work.

    The biggest factor that drove this deprecation now was Python 2 reaching its end-of-life this year. When this script was initially written 5 years ago, it was written to use Python 2 on most systems. While Python 2 is still receiving security support by various distros, the Python ecosystem has moved on and many of our dependencies are dropping support for Python 2. In order to continue to provide updates to our users, we have to get them on Python 3. We tried to migrate certbot-auto users to Python 3 in the past, but it's a ton of work and extremely error prone. Instead of trying to do this work and hope we didn't break anything (like we did last time 1), we decided to sunset the script in favor of other distribution methods.

    How do I install Certbot now?

    The way we recommend most users install Certbot is through snaps. You can find instructions for doing this at https://certbot.eff.org/instructions 13.

    Some of the benefits of installing Certbot this way are:

    • Certbot automatically stays up-to-date, giving you access to the latest features including updates to the TLS configuration Certbot uses when installing certificates with Apache and Nginx.
    • Automatic renewal comes preconfigured, so there is no need to manually set up a cron job or systemd timer.
    • All of our DNS plugins are available and it is possible for 3rd parties to write their own Certbot snap plugins 1 as well.

    If you don't want to install Certbot through snaps, other installation methods are documented at https://certbot.eff.org/docs/install.html 32. (certbot-auto is still documented there but that will be removed soon.)

    Finally, while I do not recommend this, if certbot-auto was working for you, it's possible to continue to use the last version of the script that worked on Debian based OSes. Taking this approach means you will not receive any bug fixes, security fixes, or compatibility fixes with Let's Encrypt's servers. If that does not deter you, you can find the last version of the script that worked on Debian at https://raw.githubusercontent.com/certbot/certbot/v1.9.0/certbot-auto 8. If you use this, make sure you are fully comfortable with all of these downsides and include --no-self-upgrade on the command line to prevent the script from updating itself to a deprecated version.

    So wie es mir scheint ist Debian komplett depricated bei certbot-auto.
    Denn auf der Debian10.7 maschine gelingt mir eine saubere Ausführung mit dem certbot-auto nicht mehr.


    Folgender Workaround hat nun erstmal geholfen das der certbot-auto, so wie er im PD-Admin verbaut ist wieder geht:


    - certbot-auto 1.9.0 heruntergeladen

    - eff.org in /opt umbenannt

    und dann den certbot-auto190 ausgeführt mit --no-self-upgrade
    /opt/pdadmin/bin/certbot-auto_190 --no-self-upgrade


    Beim zweiten oder dritten mal hat er dann das eff.org Verzeichnis neu generiert.


    Danach klappt auch der 1.10.1 certbot erstmal, aber immer mit der Meldung das Debian 10.7 von certbot-auto nicht mehr unterstützt wird.


    root@server05 /opt/pdadmin/bin # ./certbot-auto renew

    Your system is not supported by certbot-auto anymore.

    Certbot will no longer receive updates.

    Please visit https://certbot.eff.org/ to check for other alternatives.

    Saving debug log to /var/log/letsencrypt/letsencrypt.log


    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Processing /etc/letsencrypt/renewal/test.domain.de.conf

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Cert not yet due for renewal



    Das der Symlink aus /opt/pdadmin/bin/certbot-auto -> /usr/bin/certbot der gleiche ist stimmt.

    Aber er heißt halt certbot-auto und nicht certbot. Vielleicht macht snap anhand von dem Link das fest, den auch der Link /usr/bin/certbot auf /snap/bin/certbot führt zu einem weiteren Link


    root@server05 /snap/bin # ls -lisa

    17301516 0 lrwxrwxrwx 1 root root 13 Dez 11 10:39 certbot -> /usr/bin/snap

    Danke für die Idee, aber das funktioniert komischerweise nicht:

    Code
    root@server05 /opt/pdadmin/bin # mv certbot-auto certbot-auto_0
    root@server05 /opt/pdadmin/bin # ln -sf /snap/bin/certbot /opt/pdadmin/bin/certbot-auto
    root@server05 /opt/pdadmin/bin # /opt/pdadmin/bin/certbot-auto renew
    error: unknown command "renew", see 'snap help'.
    root@server05 /opt/pdadmin/bin #

    Wenn man aber direkt /usr/bin/certbot renew aufruft kommt


    Mir scheint der certbot, der über /usr/bin auf /snap/bin verlinkt ist identisch zu sein.

    Nur der /opt/pdadmin/bin/letsencrypt kann man nicht auf den neuen certbot umstellen.


    Auf allen unseren Systemen funktionieren die Zertifikate nur noch wenn dort bereits das /opf/eff... Verzeichnis korrekt geniert ist. Neu wird das gar nicht mehr angelegt.


    Ehrlich gesagt überrascht mich das vorgehen von letsencrypt schon auch, hier einfach funktionalitäten abzuschalten.

    Ja. in der TXT-Datei steht: BootstrapDebCommon 1

    wenn man das ganze mit dem /opt/pdadmin/bin/certbot-auto renew startet geht nix mehr...

    a) /opt/eff.org/certbot_0 (umbenannt wie in dem Link ganz oben empfohlen)

    root@server05 /opt/eff.org/certbot_0/venv # /opt/pdadmin/bin/certbot-auto renew

    Skipping bootstrap because certbot-auto is deprecated on this system.

    Your system is not supported by certbot-auto anymore.

    Certbot cannot be installed.

    Please visit https://certbot.eff.org/ to check for other alternatives.



    b) /opt/eff.org/certbot so belassen wie es vor der Umstellung auf debian9 war

    ###############################

    /opt/pdadmin/etc/ssl-validation/ -d www.domain.de -d domain.de

    ###############################


    Your system is not supported by certbot-auto anymore.

    Certbot will no longer receive updates.

    Please visit https://certbot.eff.org/ to check for other alternatives.

    Traceback (most recent call last):

    File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 7, in <module>

    from certbot.main import main

    File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 2, in <module>

    from certbot._internal import main as internal_main

    File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/_internal/main.py", line 6, in <module>

    import logging.handlers

    File "/usr/lib/python2.7/logging/__init__.py", line 26, in <module>

    import sys, os, time, cStringIO, traceback, warnings, weakref, collections

    File "/usr/lib/python2.7/weakref.py", line 14, in <module>

    from _weakref import (

    ImportError: cannot import name _remove_dead_weakref


    Mit dem neuen certbot über snap lasst sich der certbot renew ja durchaus irgendwie machen, auch wenn ich nicht abschätzen kann wie gut das mt pdadmin zusammen geht.
    Aber neue Domain bekommen keine Zertifikate valididert weil der Start der /opt/pdadmin/bin/letsencrypt --all immer auf die pdadmin-certbot-auto geht und dann immer der Fehler kommt. wie man das umgehen kann bin ich überfragt.

    Hallo, ich möchte euch an meinen "fummeleien" teilhaben lassen um anderen vielleicht Arbeit zu ersparen.

    Also auf der von Debian9 zu Debian10 geupdateten Maschine habe ich nun snap installiert.
    Das hat im Endeffekt dazu geführt das man aus dem /usr/bin/certbot vorhandene Zertifikate verlängern könnte, glaube ich.



    Aber mit dem "/opt/pdadmin/bin/letsencrypt --all" greift das System nicht auf den neuen certbot zu.

    Code
    root@server05 /usr/bin # /opt/pdadmin/bin/letsencrypt --all
    ###############################
    /opt/pdadmin/etc/ssl-validation/ -d www.domain.de -d domain.de
    ###############################
    Skipping bootstrap because certbot-auto is deprecated on this system.
    Your system is not supported by certbot-auto anymore.
    Certbot cannot be installed.
    Please visit https://certbot.eff.org/ to check for other alternatives.

    Hat von euch niemand diese Meldung?


    Macht es vielleicht sind auf dem PD-Admin Server das snap zu installieren und den Certbot wie bei eff beschrieben aus dem snap paketmanager zu installieren. Und anschließend von /opt/pdadmin/bin/certbot auf /snap/bin/certbot einen symlink zu setzen? was passiert beim pd-admin update? wird der symlink dann wieder überschrieben? und funktionieren dann die letsencrypt -all etc. aus dem pdadmin sauber?

    Hat da jemand schon mal auf einem Testsystem probiert? Oder gibt es von Herrn Bradler eine empfehlung?

    Folgender Link hat den Hinweis gegeben das man das /op/eff.org/certbot löschen soll.

    https://community.letsencrypt.…emove-dead-weakref/104556


    Wenn man das aber tut dann kommt man wieder dazu das der Certbot-auto nicht mehr unterstützt ist und nicht installiert werden kann.


    Skipping bootstrap because certbot-auto is deprecated on this system.

    Your system is not supported by certbot-auto anymore.

    Certbot cannot be installed.

    Please visit https://certbot.eff.org/ to check for other alternatives.


    hm. hat da jemand einen workaround der funktioniert?

    Hallo Zusammen,


    gestern haben wir auf der ersten Live-Maschine ein Debian-Upgrad von 9 auf 10 gemacht. Das hat scheinbar auch gut funktioniert.

    Lediglich der letsencrypt zickt. Ob das nun auch mit dem certbot-Problem zu tun hat erschließt sich mir jetzt nicht sofort.


    Folgende Meldung hat der Cronjob ausgegeben:


    ###############################

    /opt/pdadmin/etc/ssl-validation/ -d www.domain.de -d domain.de

    ###############################


    Your system is not supported by certbot-auto anymore.

    Certbot will no longer receive updates.

    Please visit https://certbot.eff.org/ to check for other alternatives.

    Traceback (most recent call last):

    File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 7, in <module>

    from certbot.main import main

    File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 2, in <module>

    from certbot._internal import main as internal_main

    File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/_internal/main.py", line 6, in <module>

    import logging.handlers

    File "/usr/lib/python2.7/logging/__init__.py", line 26, in <module>

    import sys, os, time, cStringIO, traceback, warnings, weakref, collections

    File "/usr/lib/python2.7/weakref.py", line 14, in <module>

    from _weakref import (

    ImportError: cannot import name _remove_dead_weakref


    Hat jemand eine Idee was da das Problem ist?


    Manfred

    Das scheint aber auf unterschiedlichen Installationen immer mal wieder so zu sein und auch nicht einheitlich.


    Auf einer anderen Maschine mit Debian9


    root@server03 / # find /service -type f -name run -print0 |xargs -0 grep '^#!/bin/sh'

    /service/qmail-smtpSd/run:#!/bin/sh

    /service/qmail-smtpSd/log/run:#!/bin/sh

    /service/qmail-msa/run:#!/bin/sh

    /service/qmail-msa/log/run:#!/bin/sh

    /service/proftpd/log/run:#!/bin/sh

    So wie es aussieht wird im qmail-msa/run die sh anstatt der bash verwendet.


    root@server05 /service # find /service -type f -name run -print0 |xargs -0 grep '^#!/bin/sh'

    /service/proftpd/log/run:#!/bin/sh

    /service/qmail-msa/log/run:#!/bin/sh

    /service/qmail-msa/run:#!/bin/sh

    /service/qmail-smtpSd/log/run:#!/bin/sh


    dann werde ich die mal in bash ändern.

    Bei Updaten des ersten Livesystems von Debian9 auf Debian10 und dem Update mit der PD-Admin 64bit 4.70 taucht das wieder auf:


    root@server05 /usr/lib/x86_64-linux-gnu # ps ax | grep readproc

    522 ? S 0:00 readproctitle service errors: ...enabled. Mail files support enabled. OLE2 support enabled. PDF support enabled. SWF support enabled. HTML support enabled. XMLDOCS support enabled. HWP3 support enabled. Self checking every 600 seconds. ./run: 9: test: Illegal number: ./run: 10: test: Illegal number: ./run: 14: [: server05: unexpected operator ./run: line 12: test: : integer expression expected SelfCheck: Database status OK.

    13148 pts/0 S+ 0:00 grep readproc


    Keine Ahnung was diese Tests machen und wo da der Fehler ist. Das System läuft aber scheinbar problemlos.

    Hallo Zusammen,


    gestern habe ich auf allen unseren Servern (meistens Debian 9) folgende Info im /opt/pdadmin/bin/certbot-auto renew Cronjob-Status erhalten.


    Upgrading certbot-auto 1.9.0 to 1.10.1...

    Replacing certbot-auto...

    Your system is not supported by certbot-auto anymore.

    Certbot will no longer receive updates.

    Please visit https://certbot.eff.org/ to check for other alternatives.


    Ich habe dann das hier gefunden: https://certbot.eff.org/lets-e…debianstretch-apache.html

    Interpretiere ich das richtig das der certbot, so wie er bisher verwendet wurde nicht mehr unterstützt wird? Wird das problematisch für die Verlängerung der letsencrypt-Zertifikate?


    viele Grüße

    Manfred