[Workarounded] Apache Probleme nach gestopptem ISPC Update (nix geht mehr)

DarkTrinity

DarkTrinity

Member
Hallo liebe Community,

ich war so dämlich und habe im falschen Terminal (also auf dem falschen Server) ein ISP-Config Update (enforce) gemacht und dieses mit STGR+C abgebrochen. Eigentlich lief da aber noch alles...

Gegen 1:00 nachst kamen ohne Ende Emails:
ERROR - httpd is down! Rescue will not help!
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Seit dem geht nichts mehr, weil Apache nicht mehr startet... Folgende wenige Erkenntnisse habe ich gewonnen:


systemctl status apache2
Nov 05 09:10:15 SERVERHOSTNAME systemd[1]: Starting The Apache HTTP Server...
Nov 05 09:10:15 SERVERHOSTNAME systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE
Nov 05 09:10:15 SERVERHOSTNAME systemd[1]: apache2.service: Failed with result 'exit-code'.
Nov 05 09:10:15 SERVERHOSTNAME systemd[1]: Failed to start The Apache HTTP Server.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

journalctl -xeu apache2.service
Nov 05 09:06:38 SERVERHOSTNAME systemd[1]: Starting The Apache HTTP Server...
░░ Subject: A start job for unit apache2.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit apache2.service has begun execution.
░░
░░ The job identifier is 1631027.
Nov 05 09:06:38 SERVERHOSTNAME systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ An ExecStart= process belonging to unit apache2.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Nov 05 09:06:38 SERVERHOSTNAME systemd[1]: apache2.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit apache2.service has entered the 'failed' state with result 'exit-code'.
Nov 05 09:06:38 SERVERHOSTNAME systemd[1]: Failed to start The Apache HTTP Server.
░░ Subject: A start job for unit apache2.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit apache2.service has finished with a failure.
░░
░░ The job identifier is 1631027 and the job result is failed.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Dann den Apache-Loglevel auf Debug gestellt und folgendes in er error log gefunden:
[Mon Nov 04 20:45:14.736230 2024] [ssl:info] [pid 40701:tid 40701] AH01883: Init: Initialized OpenSSL library
[Mon Nov 04 20:45:14.737528 2024] [ssl:debug] [pid 40701:tid 40701] ssl_engine_init.c(364): AH01886: OpenSSL has FIPS mode disabled
[Mon Nov 04 20:45:14.737568 2024] [ssl:info] [pid 40701:tid 40701] AH01887: Init: Initializing (virtual) servers for SSL
[Mon Nov 04 20:45:14.748561 2024] [ssl:info] [pid 40701:tid 40701] AH01914: Configuring server 127.0.0.1:8080 for SSL protocol
[Mon Nov 04 20:45:14.748782 2024] [ssl:debug] [pid 40701:tid 40701] ssl_engine_init.c(536): AH01893: Configuring TLS extension handling
[Mon Nov 04 20:45:14.748789 2024] [ssl:debug] [pid 40701:tid 40701] ssl_util_stapling.c(966): AH01960: OCSP stapling initialized
[Mon Nov 04 20:45:14.749514 2024] [ssl:emerg] [pid 40701:tid 40701] AH02565: Certificate and private key 127.0.0.1:8080:0 from /usr/local/ispconfig/interface/ssl/ispserver.crt and /usr/local/ispconfig/interface/ssl/ispserver.key do not match
AH00016: Configuration Failed
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Die crt- & Keydateien scheinen also nicht zusammenb zu passen, was diesen Fehler wahrscheinlich verursacht....
Wenn ich mit certbot ein renewal vornehme (certbot renew), bekomme ich solche Ausgaben:

certbot renew
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/subdom.sld.tld.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for subdom.sld.tld

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: subdom.sld.tld
Type: connection
Detail: <IPV4>: Fetching http://subdom.sld.tld/.well-known/acme-challenge/9t-gpQEQ7eQ50BXNpLU57qLVrfEIu_0KrmxSLAprB1o: Connection refused

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Failed to renew certificate subdom.sld.tld with error: Some challenges have failed.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Wenn ich ein ISPConfig Update Enforce vornehmen möchte und sage "erstelle die Zertifikate neu" - dann fällt er darauf zurück, selbstsignierte Zertifikate zu erzeugen....

Ich bin für jeden Tip Dankbar, mit dem sich dieses Riesenproblem lösen lässt
 
Zuletzt bearbeitet:
T

Till

Administrator
Zitat von DarkTrinity:
Wenn ich ein ISPConfig Update Enforce vornehmen möchte und sage "erstelle die Zertifikate neu" - dann fällt er darauf zurück, selbstsignierte Zertifikate zu erzeugen....
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Ja, weil er dafür Apache benötigt, und der läuft ja nicht mehr. Lass ihn ein selbstsigniertes cert erstellen, danach läuft Apache wieder, und dann nochmal ein forced update um ein LE cert zu bekommen.
 
DarkTrinity

DarkTrinity

Member
Zitat von Till:
Ja, weil er dafür Apache benötigt, und der läuft ja nicht mehr. Lass ihn ein selbstsigniertes cert erstellen, danach läuft Apache wieder, und dann nochmal ein forced update um ein LE cert zu bekommen.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Das klappt leider nicht - nach dem Update bekomme ich ein - hier die Meldung wenn er auf self-signed zurück fällt:
Checking / creating certificate for <hostname> Using certificate path /etc/letsencrypt/live/<hostname> Server's public ip(s) (<IPV4>, <IPV6>) not found in A/AAAA records for <hostname>: 127.0.1.1 Ignore DNS check and continue to request certificate? (y,n) [n]: y Using apache for certificate validation Saving debug log to /var/log/letsencrypt/letsencrypt.log An unexpected error occurred: The server will not issue certificates for the identifier :: Invalid identifiers requested :: Cannot issue for "<hostname>": Domain name needs at least one dot Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details. Issuing certificate via certbot failed. Please check log files and make sure that your hostname can be verified by letsencrypt Could not issue letsencrypt certificate, falling back to self-signed.

Nach dem Update läuft Apache immer noch nicht:
Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xeu apache2.service" for details.
Update finished.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

journalctl -xeu apache2.service
Support: http://www.ubuntu.com/support ░░ ░░ A start job for unit apache2.service has begun execution. ░░ ░░ The job identifier is 2778629. Nov 05 18:18:17 <hostname> apachectl[1109539]: AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/sites-enabled/000-ispconfig.vhost:7 Nov 05 18:18:17 <hostname> apachectl[1109539]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Nov 05 18:18:17 <hostname> systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ An ExecStart= process belonging to unit apache2.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Nov 05 18:18:17 <hostname> systemd[1]: apache2.service: Failed with result 'exit-code'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ The unit apache2.service has entered the 'failed' state with result 'exit-code'. Nov 05 18:18:17 <hostname> systemd[1]: Failed to start The Apache HTTP Server. ░░ Subject: A start job for unit apache2.service has failed ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ A start job for unit apache2.service has finished with a failure. ░░ ░░ The job identifier is 2778629 and the job result is failed. Nov 05 18:25:17 <hostname> systemd[1]: Starting The Apache HTTP Server... ░░ Subject: A start job for unit apache2.service has begun execution ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ A start job for unit apache2.service has begun execution. ░░ ░░ The job identifier is 2794093. Nov 05 18:25:17 <hostname> apachectl[1116512]: AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/sites-enabled/000-ispconfig.vhost:7 Nov 05 18:25:17 <hostname> apachectl[1116512]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Nov 05 18:25:17 <hostname> systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ An ExecStart= process belonging to unit apache2.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Nov 05 18:25:17 <hostname> systemd[1]: apache2.service: Failed with result 'exit-code'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ The unit apache2.service has entered the 'failed' state with result 'exit-code'. Nov 05 18:25:17 <hostname> systemd[1]: Failed to start The Apache HTTP Server. ░░ Subject: A start job for unit apache2.service has failed ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ A start job for unit apache2.service has finished with a failure. ░░ ░░ The job identifier is 2794093 and the job result is failed.
 
T

Till

Administrator
Dann ist vermutlich der Hostname Deines Systems falsch konfiguriert. Wenn Du den folgenden Befehl eingibst:

hostname -f

dann muss da ein vollständiger Domainname mit subdomain raus kommen, sowas wie "server1.meinedomain.tld". Kommt da was falsches raus, kannst Du kein SSL cert bekommen. Du musst dann den Hostname eichtig konfigureiern in /etc/hostname und /etc/hosts
 
DarkTrinity

DarkTrinity

Member
ein "hostname -f" ergab host (also ohne fqdn)

ich habe jetzt in den Backups geguckt und in der hosts Datei stand die FQDN eigentlich nie drinne...

Egal - wie folgt geändert:
  1. in der /etc/hostname stand der hostname - also richtig
  2. in der /etc/hosts habe ich die FQDN nun ergänzt (siehe codesnip unten)
  3. Reboot
Datei hosts:
127.0.0.1 localhost
127.0.1.1 hostname.domain.tld hostname

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback hostname.domain.tld hostname
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Apache + das ISPC Update verhalten sich nach wie vor gleich + fehlerhaft.

Beim Serverreboot sind mir einige "Fails" aufgefallen - aber das geht ja so schnell, daß Du das kaum mit bekommst. Wo der Bootvorgang per Log fest gehalten wird, weiß ich leider nicht....

So langsam befürchte ich, ich muss den Server "platt machen" :(

Ach ja - in den Logs fand ich jetzt Folgendes:
cat error.log
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

cat error.log.1
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
SIGTERM handler "exitall" not defined.
AH00016: Configuration Failed
AH00016: Configuration Failed
SIGTERM handler "exitall" not defined.
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
AH00016: Configuration Failed
SIGTERM handler "exitall" not defined.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

:oops:
 
Zuletzt bearbeitet:
DarkTrinity

DarkTrinity

Member
Also in der /var/log/dmesg finde ich keine fail-Einträge auzs dem letzten Bootvorgang.

Ich erhalte aber immer wieder folgendes:
Server's public ip(s) (<ipv4>, <ipv6>) not found in A/AAAA records for host.dom.tld: 127.0.1.1
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Ich glaube daß das die federführende Ursache ist - hab aber absolut keinen Plan was ich hier tun könnte ...
Nur kann ich eben, wenn ich Server und Backups vergleiche, unter anderem auch in der Netplan Datei keine Änderung fest stellen.

Auf meinem lokalen PC scheint die DNS des Servers im Web stimmig zu sein:
nuria@DeskBox:~> host host.domain.tld
host host.domain.tld has address <richtige IPV4>
host host.domain.tld has IPv6 address <richtige IPV6>
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Es müssen irgendwelche A/AAA Records auf dem Server selbst falsch sein irgendwie.... ?
 
DarkTrinity

DarkTrinity

Member
Von meiner Verzweiflung angetrieben spiele ich jetzt die letzten funktionierenden Backups auf Dateiebene auf:
  • Dateiebene
    • /etc
    • /var/www
    • /usr/local/ispconfig
  • Datenbank Ebene
    • erstmal noch nicht ...
      • aber auch hier gibt es Backups natürlich
Mal gespannt - theoretisch kann es ja nicht schaden ^^
 
DarkTrinity

DarkTrinity

Member
Die o.g. Backups wieder aufgespielt
Neu gestartet
Immer noch der gleiche Murks

Das enforced update fällt nach wie vor auf die gleiche Weise auf die Nase - auch selbstsignierte Certs helfen hier nicht, weil Apache nach wie vor nicht startet

Ich bin mit meinem Latein am Ende glaube ich
 
DarkTrinity

DarkTrinity

Member
Wollte jetzt eigentlich mit Clonezilla einen vollständigen Snap des SeRvers aufspielen (stand März).

Klappt aber auch nicht natürlich :mad: Es ist ein 1blu VServer

1. Ich übertrage die ISO Datei (umbenannt in boot.iso) per FTP im binären Übertragungsmodus an die entsprechende FTP Ressource
2. Serverneustart über das Kundenpanel bei 1blu von "DVD Rom"

Ergebnis: Die ISO wird nicht gebooted, statt dessen das normale OS der HDD

Frage: Weiss jemand welche ISO man hier nehmen muss - es gibt ja mehrere unter https://clonezilla.org/downloads.php#google_vignette

Ich weiß es nämlich leider nicht mehr

Nach der Aufspielung des ISOs würde ich ein Systemupdate vornehmen und dann die "normalen Backups" einspielen.

Wenn es dann immer noch nicht geht, wirds wohl die Zeit die Kiste platt zu machen.
 
T

Till

Administrator
Zitat von DarkTrinity:
Das enforced update fällt nach wie vor auf die gleiche Weise auf die Nase - auch selbstsignierte Certs helfen hier nicht, weil Apache nach wie vor nicht startet
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Als erstes musst Du den Hostnamen richtig setzen, der Befehl:

hostname -f

muss den kompletten (langen) hostnamen ausgeben. das wird aussvhließlich über die dateien /etc/hostname uund /etc/hosts geregelt, danach ggf neu starten wenn Du die geändert hast. was da drin stehen muss und vor allem in welcher reihenfolge steht in den ISPconfig Installations Tutorials. Denn wenn Du die reihenfolge der Hostnamen umdrehst, geht es nicht. Beispiel /etc/hosts:

Richtig:

Code: 
127.0.1.1 server1.example.com server1

Falsch:

Code: 
127.0.1.1 server1 server1.example.com

und in /etc/hostname steht dann nur:

Code: 
server1

Wenn das ok ist, bekommst Du auch ein LE Zertifikat.

Wenn Apache dann immer noch nicht startet, dann ist vielleicht eine Deiner webseiten zusätzlich defekt. Dann müsstest Du mal die Symlinks Apache sites-enabled Verzeichnis raus kopieren und dann Apache neu starten, wenn er läuft kopierst Du die einzeln zurück und startest jedes mal neu um zu sehen bei welcher webseite er hakt.
 
DarkTrinity

DarkTrinity

Member
Zitat von Till:
[...]

Wenn Apache dann immer noch nicht startet, dann ist vielleicht eine Deiner webseiten zusätzlich defekt. Dann müsstest Du mal die Symlinks Apache sites-enabled Verzeichnis raus kopieren und dann Apache neu starten, wenn er läuft kopierst Du die einzeln zurück und startest jedes mal neu um zu sehen bei welcher webseite er hakt.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Das war die Lösung - zumindest für die Webdomains. Die laufen alle wieder.

Aber das ISPC Panel (und damit FTP & Email) laufen noch über das selbstsignierte Zertifikat.

Das ISPC-Update fiel jetzt mit folgender Fehlermeldung auf die Nase:
Issuing certificate seems to have succeeded but /etc/letsencrypt/live<fqdn>/cert.pem seems to be missing. Falling back to self-signed.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Ich habe diese Datei aus dem Backup gefischt und eingespielt. Das Update macht jetzt keine Fehlermeldung mehr - aber wenn ich das Panel im Browser aufrufe, bleibt die Warnung bzgl. des Certs erhalten.

Hier der Dialog (alles augenscheinlich clean):
Code: 
>> Update

Operating System: Ubuntu 22.04.5 LTS (Jammy Jellyfish)

This application will update ISPConfig 3 on your server.

Shall the script create a ISPConfig backup in /var/backup/ now? (yes,no) [yes]:

Creating backup of "/usr/local/ispconfig" directory...
Creating backup of "/etc" directory...
Creating backup of "/etc/letsencrypt" directory...
Checking MariaDB version 10.6.18 .. OK
Checking ISPConfig database .. OK
Starting incremental database update.
Loading SQL patch file: /tmp/update_runner.sh.9rm5uQVmv5/install/sql/incremental/upd_dev_collection.sql
Reconfigure Permissions in master database? (yes,no) [no]:

Reconfigure Services? (yes,no,selected) [yes]:

The following local config override templates were found, be sure to incorporate upstream changes if needed:

/usr/local/ispconfig/server/conf-custom/install/dovecot_custom.conf.master

Configuring Postfix
Configuring Dovecot
postconf: warning: /etc/postfix/main.cf: unused parameter: smtp_tls_auth_only=yes
Configuring Mailman
Configuring Spamassassin
Configuring Amavisd
Configuring Rspamd
postconf: warning: /etc/postfix/main.cf: unused parameter: smtp_tls_auth_only=yes
postconf: warning: /etc/postfix/main.cf: unused parameter: smtp_tls_auth_only=yes
Configuring Getmail
Configuring BIND
Configuring Pureftpd
Configuring Apache
Configuring vlogger
Skipping config of Apps vhost
Configuring Jailkit
Configuring Ubuntu Firewall
Configuring Database
Updating ISPConfig
ISPConfig Port [8080]:

Create new ISPConfig SSL certificate (yes,no) [no]: yes

Checking / creating certificate for <FQDN>
Using certificate path /etc/letsencrypt/live/<FQDN>
Using apache for certificate validation
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Symlink ISPConfig SSL certs to Postfix? (y,n) [y]:

Symlink ISPConfig SSL certs to Pure-FTPd? Creating dhparam file may take some time. (y,n) [y]:

Reconfigure Crontab? (yes,no) [yes]:

Updating Crontab
Restarting services ...
Update finished.

Die FQDN war auch als noormale Webdomain in ISPC angelegt. Diese war abrufbar über Port 443 - LE Cert.
Aber über Port 8080 (also ISPC) verhält es sich eben wie bei selbstsignierten Zertifikaten. Dies wirkt sich natürlich auch auf Maildienste sowie FTP aus ....

WebDomain in ISPC gelöscht - nix gebracht natürlich
 
Zuletzt bearbeitet:
DarkTrinity

DarkTrinity

Member
Zitat von Strontium:
Es steht hier unter § 2.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Wenn ich nicht die folgenden Einträge in der /etc/hosts habe ...
Code: 
<public ipv4> <fqdn>
<public ipv6> <fqdn>
bekomme ich beim ISPC Update diese Meldung zu DNS:
Code: 
Server's public ip(s) (<public ipv4>, <public ipv6>) not found in A/AAAA records for <fqdn>: 127.0.1.1

Aber wenn ich in meine backups gucke, waren diese Einträge doch zuvor auch nie in der /etc/hosts drinne - und trotzdem lief alles

Aber egal ob ich diese Einträge in der /etc/hosts habe oder nicht - die Befehle "hostname" sowie "hostname -f" liefern korreckte Ausgaben ....

Und was dmesg angeht - die Fehlermeldungen da beziehen sich offenbar nur auf Rocketchat und das ist erstmal egal jetzt
 
DarkTrinity

DarkTrinity

Member
Wenn ich auf meinem Laptop ein "host <fqdn>" mache, so erhalte ich 2 richtige Antworten - einmal für IPV4 und einmal für IPV6

Wenn ich auf dem betroffenen Server ein "host <fqdn>" mache, so erhalte ich:
<FQDN> has address 127.0.1.1
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Das ist aber falsch - andere, korreckt laufende Server geben hier nämlich die ausschließlich seine Public IP aus (und nix local)

Setze ich die o.g. Public IPs wieder in die /etc/hosts - so erhalte ich alle 3:
<fqdn> address 127.0.1.1
<fqdn> has address <public ip>
<fqdn> has IPv6 address <public ip>
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Ein "resolvectl --no-pager" gibt folgende DNS aus:
Link 2 (ens3)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 178.254.16.151
DNS Servers: 178.254.16.151 178.254.16.141 2001:4860:4860::8888 2001:4860:4860::8844
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Das passt nicht zu meinem Providerdaten - hier nutzt 1Blu laut Kundenpanel folgende DNS Server:
Nameserver 1: ns01.1blu.de (via ping sollte das die 87.238.195.66 sein
Nameserver 2: ns02.1blu.de (via ping sollte das die 178.254.5.130 sein

Ob das die Ursache ist ? Ob 1blu die DNS Server verändert hat ? Aber eigentlich sollte doch jeder DNS Server das Routing erledigen können - für IPV6 nutze ich ja zB die Google Public DNS, was bis vor kurzem auch nie ein Problem war....

Ich glaube es liegt irgendwie an den lokalen DNS Einstellungen auf dem betroffenen Server...
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
 
Zuletzt bearbeitet:
DarkTrinity

DarkTrinity

Member
im Verzeichnis /etc/letsencrypt/live habe ich für die FQDN Domain mittlerweile sage und schreibe 4 Verzeichnisse ...

FQDN
FQDN-001
FQDN-002
FQDN-003
 
DarkTrinity

DarkTrinity

Member
Mittlerweile habe ich das Problem behoben. Es war ja nur noch das Panelzertifikat für ISPC betroffen. Das wird natürlich auch für FTP sowie Maildienste verwendet,,,

Ich habe das wie folgt gework-arounded :)

1. Ganz einfach mit ISPC eine Website angelegt, die der FQDN entspricht. Hier LE aktiviert. TADA - somit haben wir immerhin schon mal das begehrte funktionierte Cert

2. Die in Punkt 1 erzeugten Zertifikate in ISPC verlinken

cd /usr/local/ispconfig/interface/ssl/
mv ispserver.crt ispserver.crt-$(date +„%y%m%d%H%M%S“).bak
mv ispserver.key ispserver.key-$(date +„%y%m%d%H%M%S“).bak
mv ispserver.csr ispserver.csr-$(date +„%y%m%d%H%M%S“).bak
ln -s /etc/letsencrypt/live/FQDN.TLD/fullchain.pem ispserver.crt
ln -s /etc/letsencrypt/live/FQDN.TLD/privkey.pem ispserver.key
cat ispserver.{key,crt} > ispserver.pem
chmod 600 ispserver.pem
systemctl restart apache2
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

3. ICron installieren und ein entsprechendes Script triggern, wenn das Verzeichnis /etc/letsencrypt/archive/FQDN.TLD eine Änderung erfährt. Dazu ein Script mit folgendem Inhalt anlegen und ausführbar machen

vi /etc/init.d/le_ispc_pem.sh
chmod +x /etc/init.d/le_ispc_pem.sh
echo „root“ >> /etc/incron.allow
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Inhalt le_ispc_pem.sh:
cd /usr/local/ispconfig/interface/ssl/
mv ispserver.pem ispserver.pem-$(date +"%y%m%d%H%M%S").bak
cat ispserver.{key,crt} > ispserver.pem
chmod 600 ispserver.pem
chmod 600 /etc/ssl/private/pure-ftpd.pem
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Den Folgenden ICRON- Trigger hinzufügen via incrontab -e
/etc/letsencrypt/archive/FQDN.TLD IN_MODIFY ./etc/init.d/le_ispc_pem.sh
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

4. Entsprechende Anpassungen für Pure-FTPD, Postfix & Dovecot - also gelinkte Keyfiles verwenden und Dienste neu starten

Ergebnis:
  • Alles läuft wieder, sauberes LE auf allen Diensten incl. Port 8080
  • Bei der Erneuerung der Keyfiles wird die Pem- File automatisch neu generiert
Ok - ist vielleicht ein wenig "old school" - aber ich bin zufrieden mit diesem Workaround :)

Das Kernproblem liegt wahrscheinlich i-wie bei Certbot und könnte womöglich eleganter behoben werden. Aber ein einfaches, manuelles renewal reicht eben schon mal nicht ....

In etc/letsencrypt/live sind 5 Domänenverzeichnisse für die FQDN:
FQDN.TLD
FQDN.TLD-0001
FQDN.TLD-0002
FQDN.TLD-0003
FQDN.TLD-0004

Lieben Dank für Eure Tips und LG
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top