Apache Probleme nach gestopptem ISPC Update (nix geht mehr)

DarkTrinity · 5. Nov. 2024

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!

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.

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.

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

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.

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

Till · 5. Nov. 2024

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....

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 · 5. Nov. 2024

Vielen lieben Dank, lieber Till

Probiere ich heute nachmittag gleich aus

DarkTrinity · 5. Nov. 2024

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.

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.

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.

Till · 5. Nov. 2024

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 · 6. Nov. 2024

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:

in der /etc/hostname stand der hostname - also richtig
in der /etc/hosts habe ich die FQDN nun ergänzt (siehe codesnip unten)
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

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

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.

Strontium · 7. Nov. 2024

Zitat von DarkTrinity:
Wo der Bootvorgang per Log fest gehalten wird, weiß ich leider nicht....

dmesg

DarkTrinity · 9. Nov. 2024

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

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>

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

DarkTrinity · 9. Nov. 2024

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 · 9. Nov. 2024

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 · 9. Nov. 2024

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

Klappt aber auch nicht natürlich

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.

Till · 9. Nov. 2024

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

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.

Strontium · 11. Nov. 2024

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

Mach mal einen Neustart und gib unmittelbar danach den Befehl

Code:

dmesg | less

als root ein.

Strontium · 11. Nov. 2024

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

Es steht hier unter § 2.

DarkTrinity · 12. Nov. 2024

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.

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.

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

DarkTrinity · 12. Nov. 2024

Zitat von Strontium:
Es steht hier unter § 2.

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 · 12. Nov. 2024

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

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>

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

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...

DarkTrinity · 12. Nov. 2024

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

Apache Probleme nach gestopptem ISPC Update (nix geht mehr)

DarkTrinity

Member

Till

Administrator

DarkTrinity

Member

DarkTrinity

Member

Till

Administrator

DarkTrinity

Member

Strontium

Member

DarkTrinity

Member

DarkTrinity

Member

DarkTrinity

Member

DarkTrinity

Member

Till

Administrator

Strontium

Member

Strontium

Member

DarkTrinity

Member

DarkTrinity

Member

DarkTrinity

Member

DarkTrinity

Member

Werbung

Wir schützen deine Privatsphäre