Beiträge von mkpd15

Hier das kleine Skript als Referenz sollte jemand auch danach suchen.

Es sollte kurz nachdem pd-admin via dehydrated / cron alle SSL Certs erneuert hat aufgerufen werden.

# call renewal of letsencrypt wildcard cert
certbot certonly --manual --preferred-challenges=dns --force-renewal --email admin@my.domain.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d my.domain.com -d *.my.domain.com

# we only need to remove the symbolic links to the files below, the actual files created by dehydrated will/need to remain
rm /opt/pdadmin/sslcerts/__dehydrated/www.my.domain.com/cert.pem
rm /opt/pdadmin/sslcerts/__dehydrated/www.my.domain.com/chain.pem
rm /opt/pdadmin/sslcerts/__dehydrated/www.my.domain.com/fullchain.pem
rm /opt/pdadmin/sslcerts/__dehydrated/www.my.domain.com/privkey.pem

# copy letsencrypt to dehydrated
cp /etc/letsencrypt/live/my.domain.com/cert.pem /opt/pdadmin/sslcerts/__dehydrated/www.my.domain.com/
cp /etc/letsencrypt/live/my.domain.com/chain.pem /opt/pdadmin/sslcerts/__dehydrated/www.my.domain.com/
cp /etc/letsencrypt/live/my.domain.com/fullchain.pem /opt/pdadmin/sslcerts/__dehydrated/www.my.domain.com/
cp /etc/letsencrypt/live/my.domain.com/privkey.pem /opt/pdadmin/sslcerts/__dehydrated/www.my.domain.com/

# restart apache
svc -du /service/apache24/

Spitze, habe mir ein kleines Skript geschrieben, dass die relevanten Dateien zeitgesteuert überschreibt. Danke nochmals!

Ok, das wäre zu einfach gewesen.

Die Domain ist Teil eines Kunden, der in diesem Account auch andere Domains drinnen hat.

Daher ist das Häkchen keine Option weil damit die restlichen Domains auch nicht mehr mit letsencrypt verlängert werden.

Und ich kann diese Domain leider auch nicht in einen neuen Account umsiedeln weil das Basisverzeichnis in dem bestehenden Account liegen muss.

Somit bleibt mir wohl nur eine Skriptlösung übrig, die täglich nachdem dehydrated den Check gemacht hat sicherheitshalber mit dem manuell erstellten Wildcard überschreiben.

Danke auf jeden Fall!

Danke für den Tipp mit dem Häkchen - werde ich probieren.

Danke für deine schnelle Rückmeldung

Ja, dehydrated scheint doch etwas komplexer zu sein in der Konfiguration.

Dann werde ich das wohl mit certbot machen, das hat schon funktioniert.

Ein Problem diesbezüglich habe ich noch:

Ich möchte das Wildcard Zert dann für eine Domain verwenden, die bereits die letsencrypt Option aktiviert hat und damit auch die automatische Verlängerung- was mir dann ja das Wildcard jedes Mal überschreibt.

Hast du eine Idee wie ich das bestnöglich automatisieren könnte oder ggf diese 1 Domain von letsencrypt ausnehme?

Hallo zusammen,

im Einsatz ist Reihe 8 auf Debian 13 mit 484.

Ich würde gerne mittels dehydrated (oder anderem Tool) ein Wildcard SSL Zertifikat erstellen.

Wie lautet hier der Aufruf mittels dehydrated sofern das möglich ist? Oder wenn eine andere Option sinnvoller ist bitte um Hinweise dazu.

Zu Testzwecken habe ich erfolgreich ein manuelles Wildcard Zertifikat mittels certbot erstellt. Nachdem hier aber dehydrated im Einsatz

ist würde ich gerne die bestehende Infrastruktur wenn möglich nutzen.

Besten Dank!

Danke Herr Bradler, das habe ich bereits eingerichtet - nur werden die IPv6 Einträge für den Hostname nicht korrekt erstellt.

Für angelegte Domains jedoch schon.

Danke für die Rückmeldung und gut zu wissen.

Ich habe soweit alle Dienste auf dem System IPv6 gemacht, inkl. jetzt auch dem Apache mit automatischen Let's Encrypt Zertifikaten. Somit ist das Thema für mich derzeit einmal erledigt.

Wie im Titel angegeben habe ich auf der aktuellsten Version das Problem, dass der Aufruf von httpd_vhost.pl

nur den IPv4 Port 443 VirtualHost Eintrag für den Hostname erstellt und keinen für die IPv6 Adresse.

Hinweis: Der 443 Eintrag wird für alle anderen Domains korrekt erstellt, nur nicht für den Hostname selbst.

Was muss ich hier noch konfigurieren damit auch der IPv6 443 Eintrag korrekt erstellt wird?

Ich "behelfe" mir derzeit in dem ich den Eintrag als manuellen Vhost Eintrag anlege, aber ich denke, dass

dies nicht notwendig sein sollte?

Besten Dank für Hinweise!

Ok, vielen Dank für die Erfahrungsberichte und Ergänzungen!

Ich könnte schwören in der Vergangenheit schon (mehrfach) via IPv6 zugegriffen zu haben aber scheinbar noch nicht...

Nochmals Danke - ich werde das Setup nun einmal ohne IPv6 belassen.

Danke für die Hinweise!

Ich habe testweise IPv6 am System deaktiviert - und siehe da nun funktioniert es wieder...

Ich verstehe es dennoch nicht, weil der Server in dieser Konfiguration schon ewig läuft und nie Probleme gemacht hat.

Also, zu meinem Verständnis:

Der Check in der Admin Oberfläche wird auf Basis des Clientzugriffs gemacht? Also wenn mein Client mit IPv6 auf die URL

zugreift funktioniert es per Definition derzeit nicht?

Du meinst systemweit, also gesamt Debian?

Wegen dem Hinweis "ob IPv6 aktiviert ist" habe ich festgestellt, dass offenbar kein (?)

443 Eintrag für den SERVERNAME in der httpd.conf erstellt wird und damit die httpS

Verbindung zu SERVERNAME nicht mehr korrekt funktionieren kann.

=> Ist das ein bekanntes Thema? Bis dato hat es wie gesagt immer funktioniert.

Ich habe daher zu Testzwecken den entsprechenden IPv6 Eintrag in der http24-conf.template

ergänzt.

Damit komme ich weiterhin auf die AdminOberfläche (und phpMyAdmin etc.), die standardmäßig

installiert sind.

Das eigentliche Problem mit der Lizenz besteht aber weiterhin.

Bin echt ratlos...

Ich verstehe zudem nicht ganz warum die Lizenzdatei offensichtlich korrekt abgerufen werden kann der Zugriff dann aber mit dieser Fehlermeldung fehlschlägt...

Da ich derzeit keine Verwaltung machen kann wäre ich um Hinweise sehr dankbar!

Ja, IPv6 ist aktiv aber auch schon ewig und daher gab es dazu keine Änderung meinerseits in der letzten Zeit.

Es sollte ja auch mit IPv6 gehen?

Wann kann ich tun um hier weiter zu testen?

Besten Dank!

Da ich einmal nicht von einem Bug ausgehe (...) -> Herr @Bradler könnten Sie dies bitte kontrollieren?

Besten Dank.

Ich musste heute das SSL Zertifikat für den Servernamen neu erstellen da es Probleme mit certbot gab.

Das Zertifikat ist nun wieder eingerichtet und die Anmeldung in der Admin Oberfläche funktioniert.

Es erscheint jedoch trotz gültiger Light Lizenz der Fehler "Too many domains.Type: free".

Die Server IP wurde nicht geändert, lediglich wie gesagt das SSL Zertifikat für den $$SERVERNAME.

=> Was muss / kann ich hier tun damit die Lizenz wieder korrekt erkannt wird?

Einen manuellen Aufruf von /opt/pdadmin/bin/get_license.sh habe ich schon versucht - bringt aber keine Veränderung.

SE und PD-ADMIN sind auf einem aktuellen Stand und haben bis dato immer einwandfrei funktioniert.

Der Inhalt der license conf sieht auch korrekt aus:

Bradler & Krantz GmbH & Co. KG
Kurt Schumacher Platz 8 - 44787 Bochum
Lizenzfile V 1.0
---- SIGNED ----
LICENSE PRODUCT: pd-admin-4
LICENSE REFERENCE NO: 2129
LICENSE MAC_ADDR:
LICENSE IP_ADDR: xx.xx.xx.xx
LICENSE IPv6_ADDR:
LICENSE DATE: 20251023
LICENSE EXPIRES ON: 20251123
LICENSE TYPE: light30
LICENSE VERSION: 4
---- SIGNED ----
88fac5bb4d4b56e938b0bfa3a9815f48

Bitte um Hinweise!

Herzlichen Dank!

Funktioniert - vielen Dank!

Tipp: Es wäre gut diese Funktion etwas besser allgemein zu dokumentieren, zB in den FAQs (oder ich war ganz einfach unfähig die Doku zu finden).

Denke einmal, dass ich nicht der einzige bin, der das verwendet.

Vielen Dank für den Hinweis!

Ich werde die Option nochmals damit testen.

Zu Testzwecken habe ich geschaut ob sich mit dem Setzen der Option für den "Externen Datenbank Zugriff" in der Tabelle mysql.user etwas ändert -> Tut es nicht. Auch habe ich explizit bind_address auf "*" gesetzt und MySQL neu gestartet.

Bei dem besagten DB Benutzer für den ich den Remote Access freischalten möchte steht trotz setzen dieser Option bei Host immer noch "localhost" und es wird auch kein weiterer Eintrag für den Asterix erstellt.

Was soll/kann ich denn noch tun um für diesen Benutzer den Host auf "*" zu setzen - was diese Option offensichtlich ja machen sollte?

Was ich auch schon probiert habe ist den "Host" in der mysql.user für diesen Benutzer manuell auf "*" zu setzen. Jedoch ändert sich dieser jedes Mal bei einem FLUSH PRIVILEGES; wieder auf den localhost zurück.

Bzw. führt ein manueller Aufruf als root von

GRANT USAGE ON some_db_user_db.* TO `some_db_user`@`*`

zum Fehler

 #1410 - You are not allowed to create a user with GRANT

Bin etwas ratlos da diese Option offensichtlich nicht so funktioniert wie es sein sollte...