Installation einer zusäztlichen PHP-Version in ISPConfig 3.1.12

Ich habe schon einige Versionen laufen und habe mich dafür entschieden, die jeweilige Version immer updzudaten und nicht immer bis ins letzte zu gehen. Z.b. bei PHP 7.0 habe ich aktuell 7.0.24 auf meinem Ubuntu Server 14.04.5 installiert - die Verzeichnisse heißen aber 7.0.0 um nicht immer alles neu anlegen zu müssen und trotzdem relativ einfach Updates einspielen zu können, aktuell soll 7.0.30 eingespielt werden.

Dazu sucht man sich erst mal den Download unter http://de2.php.net/downloads.php

Jetzt stoppen wird den Webserver: sudo service apache2 stop
Jetzt wechseln wir in das Verzeichnis /opt/php-7.0.0 und laden uns das aktuelle .tar.bz2 herunter, in dem Fall: http://at2.php.net/distributions/php-7.0.30.tar.bz2
nun entpacken: sudo tar jxf php-7.0.30.tar.bz2
jetzt wechseln wir in das Verzeichnis und verschieben den Inhalt in den Ordner darüber (von /opt/php-7.0.0/php-7.0.30 in /opt/php-7.0.0):
cd /opt/php-7.0.0/php-7.0.30
sudo mv * ../
den leeren Ordner lassen wir als Hinweis zur Version bestehen.

nun kompilieren wir die PHP-Version wiefolgt:
sudo ./configure --prefix=/opt/php-7.0.0 --with-pdo-pgsql --with-zlib-dir --with-freetype-dir --enable-mbstring --with-libxml-dir=/usr --enable-soap --enable-calendar --with-curl --with-mcrypt --with-zlib --with-gd --with-pgsql --disable-rpath --enable-inline-optimization --with-bz2 --with-zlib --enable-sockets --enable-sysvsem --enable-sysvshm --enable-pcntl --enable-mbregex --enable-exif --enable-bcmath --with-mhash --enable-zip --with-pcre-regex --with-pdo-mysql --with-mysqli --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-jpeg-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --with-openssl --with-fpm-user=www-data --with-fpm-group=www-data --with-libdir=/lib/x86_64-linux-gnu --enable-ftp --with-imap --with-imap-ssl --with-kerberos --with-gettext --with-xmlrpc --with-xsl --enable-opcache --enable-fpm

sudo make

sudo make install

nun kopieren wir die alten Konfigurationen zurück:
cd /opt/php-7.0.0
sudo cp ../php-7.0.24-old/lib/php.ini ./lib/
sudo cp ../php-7.0.24-old/etc/php-fpm.conf ./etc/
sudo cp ../php-7.0.24-old/etc/php-fpm.d/www.conf ./etc/php-fpm.d/



Anleitung Quellen:
https://www.howtoforge.com/tutorial/how-to-install-php-7-on-debian/
https://www.howtoforge.com/tutorial/how-to-install-php-5-6-on-ubuntu-16-04/

ISPConfig 3.1.12 Problem mit Erstellung von LE (Let's Encrypt) Zertifikaten

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 :)

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/ :

1. Herunterladen der Treiber für RTL8111/RTL8168 von der Realtek-Website.
2. 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.
3.  Wechseln in das Verzeichnis z.B. cd Downloads/r8168-8.045.08
4. Ausführen der Installation per sudo ./autorun.sh
5. Fertig!

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

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.