fail2ban nach Plesk-Upgrade auf 17.x startet nicht

Ach Linux. Plesk ist ein Tool zu Verwaltung von WebServer. Man kann auch alles in der Console machen, aber die Hoster heutzutage packen das auf ihre Server drauf, damit sie weniger Arbeit haben und der Mietkunde sich _grundsätzlich_ selbst helfen kann.

Auf meinem Server hier läuft das auch, es war allerdings in einer älteren Version vorhanden. In der Version konnte ich ums zerplatzen die kostenlosen ServerZertifikate von Lets encrypt partout nicht einbinden, erwiesene persönliche Unfähigkeit. Es gibt ein Plugin für Plesk was die Sache sehr einfach gestaltet, doch dazu muss man ein Upgrade ausführen. Das ist ja letztlich dann auch gelungen. Mit den Zertifikaten beschäftige ich mich noch.

Sonntags gehe ich gerne durch die Logs meiner Büchsen sofern unterhalb der Woche nichts war und schaue mich so um. Dabei fällt mir auf, dass fail2ban auf dem WebServer in der Prozessliste nicht auftaucht, obwohl auch im neuen Plesk das Tool installiert und aktiv markiert ist. Ein manueller Neustart von fail2ban fällt auf die Nase. Über “sudo /etc/init.d/service fail2ban stop” (auch wenn er nicht da ist, es ist Gewohnheit etwas zu beenden bevor man es entfernt) => apt-get remove fail2ban” => “sudo apt-get purge fail2ban” das störrische Tool entfernt und es mit “sudo apt-get install fail2ban” wieder deinstalliert. Am Ende “sudo /etc/init.d/ service fail2ban start” wirft eine Fehlermeldung an der Console aus und erzeugt eine Fehlermail von Plesk:

/etc/cron.daily/logrotate:
Traceback (most recent call last):
 File "/usr/bin/fail2ban-client", line 472, in <module>
   if client.start(sys.argv):
 File "/usr/bin/fail2ban-client", line 442, in start
   return self.__processCommand(args)
 File "/usr/bin/fail2ban-client", line 281, in __processCommand
   return self.__processCmd([cmd])
 File "/usr/bin/fail2ban-client", line 185, in __processCmd
   client.close()
 File "/usr/lib/python2.7/dist-packages/fail2ban/client/csocket.py", line 55, in close
   self.__csock.sendall(CSPROTO.CLOSE + CSPROTO.END)
 File "/usr/lib/python2.7/socket.py", line 224, in meth
   return getattr(self._sock,name)(*args)
socket.error: [Errno 32] Broken pipe

Aha, jetzt schickt das faule Ding eine Mail den Fehler, die ganze Zeit vorher schaut es gemütlich zu. Tante Google findet nach etwas Mühe einen Plesk-Forums-Thread mit exact dieser Fehlermeldung. 

Was ist zu tun:

  • per SSH auf den Server
  • su root (ohne root-Zugriff geht es nicht)
  • dann diese Zeilen in die Konsole kopieren:

    apt-get purge fail2ban plesk-fail2ban-configurator
    
    mkdir -p /root/addons/plesk
    cd /root/addons/plesk
    wget http://autoinstall.plesk.com/PSA_17.5.3/dist-deb-Ubuntu-14.04-x86_64/opt/fail2ban/fail2ban_0.9.6-ubuntu14.04.17031415_all.deb
    wget http://autoinstall.plesk.com/PSA_17.5.3/dist-deb-Ubuntu-14.04-x86_64/opt/fail2ban/plesk-fail2ban-configurator_17.5.3-ubuntu14.04.build1705170314.14_all.deb
    
    dpkg -i fail2ban_0.9.6-ubuntu14.04.17031415_all.deb plesk-fail2ban-configurator_17.5.3-ubuntu14.04.build1705170314.14_all.deb
  • Wenn das alles durch ist:
    rm -rf /root/addons/plesk 
    
    und
    
    /sbin/iptables -F
  • Ein Neustart des Servers muss sein, ohne den läuft die Änderung nicht: 
    reboot -n
  • Wenn der Server wieder da ist, zur Sicherheit
    sudo /etc/init.d/service fail2ban stop

    und

    sudo /etc/init.d/service fail2ban start
  • Dann ist auch in Plesk der Dienst wieder da und sorgt für Sicherheit auf der Console.

Keine 2 Minuten später waren schon wieder die ersten IP-Adressen im jail:

Loading Likes...

bad gateway

HTTPS ist in Mode, es wird gefördert, gelobt, von Google belohnt und schon alleine deswegen sollte man es als Webseitenbetreiber mittlerweile anbieten, selbst wenn keine Daten zur Eingabe bzw. Datenaustausch dazu nötig sind. Ich hatte in 2014 schon eine HTTPS Verbindung auf thatblog eingerichtet, doch wegen des selbst erstellten Zertifikates und weil dessen Validitätsprüfung durch die Browser dabei auf die Nase fällt, es dann doch lieber als optionale Verbindung zurück gestuft. Wer will schon mit komischen Meldungen konfrontiert werden, wenn man nur lesen oder mal eben schauen will.

Mit Let’s Encrypt gibt es mittlerweile einen kostenlose anerkannten Service der auch valide öffentliche Serverzertifikate ausstellt. Doch das geht auf meinem Server hier nicht, weil meine Verwaltungssoftware Plesk dafür zu alt ist. Ich schraube und bastel ja gerne auf oder an Servern, aber es gibt Sachen da lasse auch ich die Finger von, darunter zählt u.a. remote Treiber zu kompilieren, Datenbankmigrationen von Typ 1 nach Typ 2 und Plesk-Upgrades. Der Support vom Hoster mach mir aber Mut, schickt mir sogar den Link zum Upgrader, die Lizenz bleibt auch gültig, also worauf warten Sie. *gulp

Also gut, er hat ja auch Recht, aber erst Backup von der Kiste ziehen, man weiß na nie. Dann beherzt heute mittag auf der Konsole etwas mulmig das Upgrade abgeschubst, diverse Installationsfragen beantwortet und es mal machen lassen. Finger weg. Und dann 

 

Das plesk_upgrade_log zeigt unverständlichen Müll und die Console macht um die Sache noch zu vervollständigen : 

Das ist ja mal wieder typisch. Die Console war ja noch da, also den Server mal neu gestartet, ‘Bad Gateway’ blieb aber. Die diversen Logfiles habe ich nicht verstanden, also wieder schlimme Sachen ergoogelt. Die Webseiten waren da und vollständig erreichbar, nur Plesk war und blieb down. Ich hab es aber vorerst sein lassen und machte im Büro mit der Absicht weiter, den Rest später von zu Hause aus zu machen. Und jetzt komme ich nach Hause, will mich dran setzen und Plesk ist wieder da. Einfach so.

Drama Queen ey.

Loading Likes...

es fühlt sich gut an

Was? Die Absicht wieder mehr BlogContent zu erzeugen? Irgendwie schon. Raus aus der Comfort-Zone oder wie der HipsterShout da wohl lautet und wieder mehr produzieren. Doch, das fühlt sich bis jetzt gut an. Wie sich das in einer Arbeitswoche umsetzen lässt, wird sich zeigen. 

Nebenbei ist mir dann aufgefallen, dass die BackupStrategie von mir auf thatblog eher lax gehandhabt wird. Ein täglichen DUMP der mySQL-Datenbank kommt per Mail an ein externes Postfach. Das reicht aber eigentlich nicht. Da ich dateimäßig scheinbar echt nichts wegwerfe, habe ich ein wirklich altes PERL-Script in meinem Archiv gefunden, das mit einem CRON-Job alle Dateien von thatblog jeden Sonntag um 3 Uhr in eine Datei zippt und via FTP zu meinem NAS hier nach Hause schiebt. Dabei  habe ich gleich gelernt wie ich das QNAP-NAS via DynDNS und FTP von außen erreichbar machen kann. Wollte ich schon lange mal machen. Dann noch etwas Sicherheit, dass die Kiste von außen nicht von x-beliebigen IPs gescannt werden kann und fertig.

Loading Likes...