Bei einer neuen Website wollte ich ebenfalls so einfach wie bisher mit einem Haken in der Website-Konfiguration das Let's Encrypt SSL-Zertifikat aktivieren. Da es nicht auf anhieb ging, dachte ich an die gerade erst eingegebenen DNS-Records liegen und wartete einen Tag.
Als es dann noch immer nicht ging konnte es der DNS-A-Record nicht mehr sein. Ich fand an dieser Stelle eine Seite die beschreibt, wie man ISP-Config in den Debug-Log-Modus setzt (Unter System->Serverkonfiguration->Server auswhählen->Loglevel->Debug) und den Cronjob erst mal pausiert um den dann selber manuell durchführen zu können und somit die Logs zu der Zeit zu bekommen, wenn man sie braucht.
crontab -e
Auskommentieren der Zeile "* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done" durch ein setzen einer "#" davor und dann kann man den cronjob manuell starten
/usr/local/ispconfig/server/server.sh
Promt kam auch auch schon der Fehler:
15.05.2018-15:05 - WARNING - Could not verify domain xx.testdomain.com, so excluding it from letsencrypt request.
15.05.2018-15:05 - WARNING - Could not verify domain www.xx.testdomain.com, so excluding it from letsencrypt request.
Was ja auch wieder auf eine fehlerhafte DNS-Abfrage hindeutete. Nach einer kurzen suche kam ich auf https://www.niih.de/gelost-warning-could-not-verify-domain-so-excluding-it-from-letsencrypt-request/#comment-274 - hier war nun die Entscheidende sowie einfache Lösung:
ISP-Config hat eine vorab-Überprüfung der Domainnamen eingeführt welche standardmäßig aktiviert ist. Diese Überprüfung ist wohl dazu da um bei fehlerhaften Anfragen nicht gesperrt zu werden. Offensichtlich funktioniert diese Abfrage aber bei Servern hinter einem NAT nicht gut und führt zu Fehlern. Die gute Nachricht:
Man kann diese Funktion einfach unter
System->Serverkonfiguration->Server auswhählen->Web->SSL-Einstellungen->Skip Lets Encrypt Check deaktivierten und schon läuft die Zertifikatserstellung wieder problemlos!
Nun nicht vergssen das Debugging wieder auf normal stellen und den Cronjob wieder in Gang zu setzen :)
Hier geht es um Probleme die ich bereits hatte und um Lösungen dafür.
Freitag, 15. Juni 2018
Dienstag, 5. Juni 2018
RTL8111/RTL8168 mit Kernel 4.4 unter Ubuntu 14.04
Nach dem Update auf den neuesten Kernel funktionierte bei mir die Netzwerkverbindung nur noch wenn ich mit dem alten Kernel bootete. Da ich das Problem mit dem Netzwerktreiber schon mal hatte, stellte ich mich schon mal auf eine lange Suche ein. Nach einigen Fehlversuchen fand ich eine eigentlich ganz einfache Lösung unter https://linhaiting.wordpress.com/2015/07/04/ubuntu-rtl8111rtl8168-network-connection-fix/ :
- Herunterladen der Treiber für RTL8111/RTL8168 von der Realtek-Website.
- Entpacken der Datei, entweder in der Konsole per tar -xvf 0010-r8168-8.045.08.tar.bz2 oder in der grafischen Oberfläche -> Rechtsklick -> Hier entpacken.
- Wechseln in das Verzeichnis z.B. cd Downloads/r8168-8.045.08
- Ausführen der Installation per sudo ./autorun.sh
- Fertig!
Sonntag, 24. Dezember 2017
Error contacting apcupsd @ :3551: No such process
Ich hatte vor einiger Zeit mal den Befehl apcaccess verwendet um den Status meiner per USB angeschlossenen USV auf einem Ubuntu 16.04.2 abzurufen. Aus irgendeinem Grund funktionierte dies nicht mehr und der Aufruf des Befehls
hatte die Fehlermeldung
zur Folge. Nach einigem Googeln ergänzte ich die /etc/hosts um den hostnamen des Servers (vmhost) bei 127.0.0.1 nach localhost:
Es kam nun die Fehlermeldung
Eine Durchführung div. Tests funktionierte aber:
und auch der Dienst läuft
aber der Dienst lauschte anscheinend nicht auf dem Port, denn mit
wurde er nicht angeführt.
Nun ergänzte ich die /etc/apcupsd/apcupsd.conf um den Wert NISIP 0.0.0.0 auf:
Nach einem
sudo service apcupsd force-reload
funktionierte das Kommando apcaccess wieder.
apcaccess
hatte die Fehlermeldung
Error contacting apcupsd @ :3551: No such process
zur Folge. Nach einigem Googeln ergänzte ich die /etc/hosts um den hostnamen des Servers (vmhost) bei 127.0.0.1 nach localhost:
127.0.0.1 localhost vmhost
Es kam nun die Fehlermeldung
Error contacting apcupsd @ localhost:3551: No such process
Eine Durchführung div. Tests funktionierte aber:
sudo service apcupsd stop
sudo apctest
2017-12-24 00:18:33 apctest 3.14.12 (29 March 2014) debian
Checking configuration ...
sharenet.type = Network & ShareUPS Disabled
cable.type = USB Cable
mode.type = USB UPS Driver
Setting up the port ...
Doing prep_device() ...
You are using a USB cable type, so I'm entering USB test mode
Hello, this is the apcupsd Cable Test program.
This part of apctest is for testing USB UPSes.
Getting UPS capabilities...SUCCESS
Please select the function you want to perform.
1) Test kill UPS power
2) Perform self-test
3) Read last self-test result
4) View/Change battery date
5) View manufacturing date
6) View/Change alarm behavior
7) View/Change sensitivity
8) View/Change low transfer voltage
9) View/Change high transfer voltage
10) Perform battery calibration
11) Test alarm
12) View/Change self-test interval
Q) Quit
und auch der Dienst läuft
sudo service apcupsd status
apcupsd.service - LSB: Starts apcupsd daemon
Loaded: loaded (/etc/init.d/apcupsd; bad; vendor preset: enabled)
Active: active (running) since Son 2017-12-24 00:19:24 CET; 6s ago
Docs: man:systemd-sysv-generator(8)
Process: 4611 ExecStop=/etc/init.d/apcupsd stop (code=exited, status=0/SUCCESS)
Process: 5684 ExecStart=/etc/init.d/apcupsd start (code=exited, status=0/SUCCESS)
Tasks: 3
Memory: 236.0K
CPU: 31ms
CGroup: /system.slice/apcupsd.service
└─5689 /sbin/apcupsd
aber der Dienst lauschte anscheinend nicht auf dem Port, denn mit
sudo netstat -tulpen
wurde er nicht angeführt.
Nun ergänzte ich die /etc/apcupsd/apcupsd.conf um den Wert NISIP 0.0.0.0 auf:
## apcupsd.conf v1.1 ##
UPSCABLE usb
UPSTYPE usb
DEVICE
LOCKFILE /var/lock
UPSCLASS standalone
UPSMODE disable
NETSERVER on
NISIP 0.0.0.0
NISPORT 3551
Nach einem
sudo service apcupsd force-reload
funktionierte das Kommando apcaccess wieder.
Donnerstag, 12. Oktober 2017
Libre Office Fußzeile wird abgeschnitten
Das Problem ist, dass die Fußzeile, bei dem aus einer Excel-Datei geöffneten Dokument, abgeschnitten ist. Dabei half die Anpassung der Seitenränder nicht. Wenn ich ein neues Dokument erstellt habe, hatte ich mit der Fußzeile auch kein Problem.
Die Lösung ist, dass man unter Format->Seite...->Fußzeile den Haken bei "Höhe dynamisch anpassen" setzt.
Dieser Haken ist standardmäßig bei neuen ods-Dokumenten gesetzt, aber offensichtlich bei geöffneten Excel-Dokumenten nicht - da muss man den Haken dann setzen.
![]() |
| Abgeschnittene Fußzeile |
Die Lösung ist, dass man unter Format->Seite...->Fußzeile den Haken bei "Höhe dynamisch anpassen" setzt.
![]() |
| Korrekte Fußzeile |
Dieser Haken ist standardmäßig bei neuen ods-Dokumenten gesetzt, aber offensichtlich bei geöffneten Excel-Dokumenten nicht - da muss man den Haken dann setzen.
Abonnieren
Kommentare (Atom)

