Beiträge von webby

    Hallo Jungens, :)


    musste heute feststellen dass die automatische Zertifikatsverlängerung via folgendem Cronjob

    Code
    1. 38 5 * * 2 /opt/pdadmin/bin/certbot-auto renew

    wohl nicht ausreicht, um auch das Zertifikat für den MailServer aktuell zu halten.


    Sprich: Das bestehende Zertifikat "/opt/pdadmin/sslcerts/server-{key,cert,cacert}" wird via "certbot" zwar erfolgreich verlängert, hat aber keinen Einfluss auf das Zertifikat vom MailServer :(


    Ich habe daher meinen Cronjob wie folgt erweitert

    Code
    1. 38 5 * * 2 /opt/pdadmin/bin/certbot-auto renew --post-hook "cat /opt/pdadmin/sslcerts/server-key /opt/pdadmin/sslcerts/server-cert /opt/pdadmin/sslcerts/server-cacert > /var/qmail/control/servercert.pem"

    Und hoffe das funktioniert zuverlässig. Wie macht Ihr das? Geht das eleganter oder sollte der eigentlich aufruf ohne meine anpassungen funktionieren?


    Habe gelesen das einer auch extra ein Skript dafür geschrieben hat:

    Umstellung auf SSL - Datensicherung

    Ich habe heute mal meinen Server auf 0.312 aktualisiert und anschliessend erneut versucht wie folgt ein Zertifikat zu beantragen

    Code
    1. #> /opt/pdadmin/bin/letsencrypt www.eine.tld


    und siehe da es hat auf anhieb funktioiniert...


    NOCH EIN WICHTIGER HINWEIS:
    Domains müssen offenbar als "Haupt-Domain" eingetragen sein. Mit "Co-Domains" funktioniert das anscheinend nicht...


    Der Vollständigshalber die nun vorhandenen einträge aus der httpd.conf

    Vorrausgesetzt er konnte es lösen wäre es ja einfach gewesen ^^
    Aber hier etwaige Fehlermeldungen in der Hoffnung das wir eine Lösung finden:


    FileZilla


    Meldung in messages

    Code
    1. May 2 16:53:02 SERVER proftpd: 2018-05-02 16:53:02,615 SERVER.FQDN proftpd[2951] 127.0.0.2 (x1x.x2x.x3x.x4x[x1x.x2x.x3x.x4x]): FTP session opened.
    2. May 2 16:53:03 SERVER proftpd: 2018-05-02 16:53:03,735 SERVER.FQDN proftpd[2951] 127.0.0.2 (x1x.x2x.x3x.x4x[x1x.x2x.x3x.x4x]): USER PDUSERID: Login successful.
    3. May 2 17:03:04 SERVER proftpd: 2018-05-02 17:03:04,221 SERVER.FQDN proftpd[2951] 127.0.0.2 (x1x.x2x.x3x.x4x[x1x.x2x.x3x.x4x]): Client session idle timeout, disconnected
    4. May 2 17:03:04 SERVER proftpd: 2018-05-02 17:03:04,223 SERVER.FQDN proftpd[2951] 127.0.0.2 (x1x.x2x.x3x.x4x[x1x.x2x.x3x.x4x]): FTP session closed.


    Denke übrigens das es am "MLSD" anstelle von "LIST" liegt...
    Aber das setzen von

    Code
    1. <IfModule mod_facts.c>
    2. FactsAdvertise off
    3. </IfModule>


    in der /usr/local/pd-admin2//etc/proftpd.conf hatte keinen Erfolg.


    Wenn man im FileZilla-Client hingegen beim
    Servermanager bei „Verbindungsart“ auswählt: „Nur unverschlüsseltes FTP verwenden (unsicher)
    klappt es übrigens :/

    *buddel*
    Hi RudiX,
    ich habe das gleiche Problem mit [php]PD-Admin Version: pd-admin version v4.58
    Installierte SE : 0.310[/php]
    Wie konntest Du das Problem seinerzeit lösen?

    Der Hinweis bzgl. des Dir "/usr/local/pd-admin2/htdocs/" ist interessant - wusste ich nicht :) ... finde in der httpd.conf aber auch keinen hinweis diesbezüglich... hmm..


    ungeachtet dessen, DNS technisch ist alles wunderbar. Wieso hier ein Timeout kommt ist mir noch immer nicht klar... insbesondere da es ja mit certbot ohne weiteres funktioniert (zuletzt für ein Zertifikat für den Server - richtig)


    Meine Vermutung war/ist das letsencrypt hier die abzufragende Datei nicht anlegt (kann?) und es deshalb zur Meldung kommt... falls "timout" hier tatsächlich "timout" heisst, weil der Server an sich nicht antwortet, muss das Problem wohl an anderer stelle sein...


    Wenn der Kunde mich wieder an das System bestellt, werde ich mal schauen was sich ich sonst noch so finde und würde mich ggf. noch einmal melden.


    Erst einmal vielen Dank!

    Ich bin eben zumindest schnell die vadmin DB durchgegangen und konnte keinen Punkt um da so zu beeinflussen... wäre natürlich nett wenn man definieren könnte, was im Dropdown für Versionen angezeigt werden kann...
    vielleicht ist ja hier etwas mit den pdadmin config files möglich?...

    Hi,
    und Danke für eure Beiträge.


    Selbstverständlich habe ich mir die Fehlermeldung durchgelesen und auch sichergestellt das es DNS-Technisch definitiv funktionieren müsste. Wenn ich die Links selbst aufrufe klappt es ja auch.. zumindest eine "test.txt" im erwarteten verzeichniss kann ich aufrufen - Die Datei die von letsencrypt angelegt werden müsste ist halt nicht da.


    An sich sollte es ja gehen, schliesslich funktioniert der aufruf mit dem "certbot" (siehe mein letzter Post) ja ohne weiteres.


    Was übersehen wir? :*(

    Sumeragi vielen Dank für Deinen Beitrag. HAbe jetzt einen neuen Thread erstellt siehe hier :)


    Und:
    Erfolg habe ich mit folgendem Befehl gehabt

    Code
    1. [root@myserver ~]# cd /opt/pdadmin/bin/
    2. [root@myserver bin]# ./certbot-auto certonly --webroot -w /opt/pdadmin/etc/ssl-validation/ --rsa-key-size 4096 -d myserver.domain.tld


    Wieso will "letsencrypt" da nicht mitspielen wenn doch der certbot anscheinend keine probleme hat...

    Irgendwie will das letsencrypt bei mir nicht funktionieren...


    * in der serverkonfiguration aktiviert
    * beim endkundenangebot aktiviert


    wenn ich nun aufrufe:


    /opt/pdadmin/bin/letsencrypt www.meineseite.tld


    bekomme ich letztlich





    In meiner VirtualHost scheint alles korrekt



    Jemand eine Idee? :*(

    Irgendwie will das letsencrypt bei mir nicht funktionieren...


    * in der serverkonfiguration aktiviert
    * beim endkundenangebot aktiviert


    wenn ich nun aufrufe:


    /opt/pdadmin/bin/letsencrypt www.meineseite.tld


    bekomme ich letztlich


    In meiner VirtualHost scheint alles korrekt



    Jemand eine Idee? :*(

    Das mit dem "ignorewronganswer" klingt interressant - werde ich definitiv im Hinterkopf behalten. Hatte das am Freitag übrigens noch wie folgt gelöst

    Code
    1. # yum install epel-release
    2. # dnsip `dnsqr ns . | awk '/answer:/ { print $5; }' |sort` > /etc/ndjbdns/servers/roots
    3. # vi /etc/ndjbdns/servers/roots
    4. # /etc/init.d/dnscache restart
    5. # /etc/init.d/network restart

    Wo liegt eigentlich das Problem den Patch zu implementieren?


    Gibt es eine step by step Anleitung um diesen "dnscache"/djbdns auf einem pdAdmin Server zu installieren? In einem Thread gibt es einen link vom Bradler aber damit komme ich iwie nicht klar :*(

    Hallo Jungs,


    ich bin von einem Kunden auf folgenden „Bug“ aufmerksam gemacht worden.


    Obwohl bei der Einrichtung einer Domain (auch bei Co-Domain!) der Punkt „Mailserver einrichten“ rausgenommen wird fühlt sich der MailServer
    für diese Domain erst einmal verantwortlich!


    Ich kann das ganze wie folgt reproduzieren:

    Code
    1. PD-Admin Version: pd-admin version v4.57
    2. Installierte SE : 0.303


    Ich lege die Domain im pdAdmi-WebInterface wie gewohnt an und nehme den Punkt bei "Mailserver einrichten" raus!


    Nachdem die Domain im pdAdmin angelegt wurde, mache ich folgenden Test:


    hervorzuheben, ist der letzte Punkt "550 sorry, user unknown".
    Die Domain selbst kümmert Ihn also nicht weil er diese Domain zu kennen scheint - obwohl in der Datei

    Code
    1. /var/qmail/control/rcpthosts


    die Domain auch tatsächlich vom pdAdmin nicht eingetragen wurde!


    Gehe ich jetzt wieder im Admin-Interface auf den Endkungen und dort auf "Domains" um hier die "MX" funktionalität unter "Aktionen" zu betrachten, sehe ich:

    Code
    1. Mailserver-Eintrag: Eingeschaltet


    Wir rekapitulieren:

    • ich hatte bei der Erstellung gesagt das der MailServer nicht eingerichtet werden soll
    • in der rcpthosts wurde die Domain auch nicht eingetragen
    • bei den "MX" zur Domain steht "Eingeschaltet"


    Wenn ich den letzten Punkt nun von "Eingeschaltet" auf "Ausgeschaltet" stelle, und meinen test anschliessend wiederhole, bekomme ich zum Ende

    Code
    1. rcpt to:<info@zieldomain.tld>
    2. 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)
    3. quit
    4. 221 mein.server.tld
    5. Connection closed by foreign host.


    Die Meldung "sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)" ist genau das, was ich schon zu beginn erwartet habe.


    Es scheint das es sich hierbei um einen Bug handelt. Oder wie seht Ihr das?

    Hallo Eisenherz,
    vielen Dank für Dein Feedback.


    Das ist schon eigenartig. Ich habe noch mehrmals versucht die Seite unter 7.1.12 zum laufen zu bewegen - vergebens. Selbst mit pdadmin im cgiwrap und zurückstellen auf fastcgi hatte nicht geholgen.


    Heute habe ich mal nachgesehen welche Version von WP drauf ist: 4.8.4.
    Also schon aktueller als Deine installation.. habe dann - weil es sich anbot ein Update auf 4.9.1 inkl. Updates der Plugins/Themes ausgeführt und evoila auch mit der version 7.1.12 und sogar 7.2 funktioniert die Seite nun...


    Wollte das hier zusammenfassend noch einmal festhalten. Danke noch einmal :)

    Nachdem soeben die Version 0.302 veröffentlich wurde habe ich insgeheim die Hoffnung gehabt das das problem damit behoben sein könnte... Leider war dies nicht der Fall.


    Ich habe das oben beschriebene Problem weiterhin.
    Wäre klasse wenn einer das Problem einmal bei seiner Installation Prüfen könnte um festzustellen, ob es ein Generelles Problem von der in der SE mitgelieferten php version 7.12 mit der auch von mir genutzten CentOS Version zu tun hat.


    :*(

    - Welche Version von pd-admin wird eingesetzt? v4.57
    - Welche Version der Serverumgebung wird eingesetzt? 0.301
    - Welche Fehlermeldung erhalten Sie? / - Welche Logfile-Einträge (zB. Webserver- oder Mail-Logfile) gibt es?

    Code
    1. Dec 1 13:12:46 SERVER kernel: traps: php-fcgi[2618] general protection ip:6f3b43 sp:7ffee2099de0 error:0 in php-fcgi[400000+a31000]


    - Wie sind die problematischen Dienste konfiguriert?

    Darüber hinaus eine Standart pdAdmin-Installation.


    Das Problem taucht bei mir in Verbindung mit der PHP-Version 7.1.12 und 7.2.0RC6 auf!
    Hingegen mit der Verison 7.1.11 funktioniert alles.
    Bemerkt habe ich dies als meine WordPress installation plötzlich ein

    Code
    1. Internal Server Error
    2. The server encountered an internal error or misconfiguration and was unable to complete your request.
    3. Please contact the server administrator, webmaster@meinedomain and inform them of the time the error occurred, and anything you might have done that may have caused the error.
    4. More information about this error may be available in the server error log.


    brachte - in der PHP-Auswahl vom pdAdmin habe ich normalerweise stehen "letzte 7.1". Ausgespuckt wird die besagte Fehlermeldung aus dem obigen "Fragebogen".
    Mit der SE 0.300 hatte ich das Problem nicht.

    Hat hierzu vielleicht jemand anderes über andere Wege in Erfahrung bringen können weshalb dies für die pdAdmin-Entwickler offenbar nicht in Frage kommt?