Rolle rückwärts bei Ubuntu


Es ist fast genau 4 Jahre her, dass ich mich von Ubuntu – genauer von Kubuntu – zurückgezogen habe. Gründe dafür habe ich in einem Artikel beschrieben. Im wesentlichen ging es mir gegen den Strich, dass man einerseits im Bereich der Desktopmanager mit der Eigenentwicklung Unity eigene Wege ging und in diesem Zusammenhang auch eine eigene Display-Architektur entwickelte. Mit Maui-Linux und auch mit meinem aktuellen Betriebssystem KDE Neon landete ich zwar durch die Hintertür wieder bei Ubuntu, hatte allerdings deswegen ein ausgesprochen ungutes Gefühl.

Sicher nicht unbedingt wichtig für die große weite Welt, für mich allerdings mehr als eine Kleinigkeit. Schon war ich auf der Suche nach einer Alternative – wieder einmal. Insofern sind es gute Nachrichten, die ich am Wochenende las: Canonical, die Firma hinter Ubuntu, zieht die Reißleine und stellt die Entwicklung von Unity ein, kehrt wohl im kommenden Jahr zu Gnome als Standard-Desktop zurück und stampft auch die eigene Display Architektur „Mir“ ein. Die Rückkehr zu Wayland beendet einen Teil der Linux-Diaspora und führt die große Gruppe der Ubuntu-Nutzer zurück in das Lager der „normalen“ Linux-Distributionen.

Für mich der Moment wieder mit ruhigem Gewissen vor meinem Desktop zu sitzen und mich meiner Linux-Distribution zu erfreuen. Ein Blick zu Kubuntu wird dadurch ebenfalls wieder möglich ….

PaloAlto Firewall – Its a Bug, not a feature

Bereits seit 3 Jahren setzen wir auf PaloAlto bei den Firewalls in der Firma. Bisher war ich mit der Leistung, vor allem aber mit den umfangreichen Konfigurationsmöglichkeiten der bei uns eingesetzten Firewall PA-500 sehr zufrieden. Insbesondere die Möglichkeiten, die eine Anbindung von Remote-Clients per VPN und  zur LAN-LAN-Kopplung fanden und finden in unseren Umgebung breite Anwendung. Besonders hier stellt Palo Alto seine Fähigkeiten unter Beweis. Die Sicherheitsfeatures, neben SSL-VPN u.a. Antivirus, Anti-Malware und applikationsbasierte Zugriffssteuerung, arbeiten zuverlässig und effizient.

Der Zugriff per VPN erfolgt für Windows und iOS über einen separaten Client, der auf die Komponenten der Firewall zugreift. Auf der Firewall selbst werden die Sicherheitsfeatures für das VPN konfiguriert und hier gibt es alles was das Adminherz begehrt: SSL, TLS, verschiedene Protokolle von OpenVPN bis IPSec, Verzeichnisintegration (LDAP und AD), verschiedene Authentifizierungsmöglichkeiten usw. usf. Die Anbindung von Linux- und Android-Clienten stellt(e) ebenfalls kein Problem dar: auf meinen Linuxbüchsen nutze ich den Cisico-basierten Client (VPNC), auf den Androiden habe ich mit VPNCilla sehr gute Erfahrungen gemacht.

Die Anbindung funktionierte tadellos bis, ja bis Dezember letzten Jahres. Nach einem Update der PANOS genannten Firmware der Firewall war der Aufbau eines VPNs von den Clients aus nicht mehr möglich, die LAN-LAN-Kopplung hingegen werkelte weiter ohne Probleme vor sich hin. Für die Windows-Clients erledigte sich das Problem relativ schnell: eine neue Version der GlobalProtect genannten Clientsoftware wurde bereit gestellt und alles war wieder in Butter. Nur ich selbst – der ich mich immer noch ohne Windows in der digitalen Welt bewege – konnte ums Verrecken keine Verbindung mehr zu „meinem“ Netzwerk herstellen. Natürlich suchte ich die Ursache in der Konfiguration der Clients, aber es gelang mir nicht, den Fehler einzukreisen.

Gestern stiess ich nun auf den lapidaren Kommentar zu einem Artikel über die Anbindung von Android-Clients per IPSec an die PaloAlto:

If you upgrade from some lower version to 7.x there is a bug which can be fixed by removing the gateway config and configuring to again or by changing a keyword from „any“ to Any.

Also wer ein ähnliches Problem hat: es reicht tatsächlich, die Gatewaykonfiguration zu löschen und sie mit genau denselben Einstellungen neu zu erstellen (achtet darauf das eure Dokumentation aktuell ist 😉 ). Diese Einstellungen dann auf die Firewall übertragen, fertig! Der Zugriff sowohl vom Androiden als auch den Linuxrechnern ist wieder ohne Probleme möglich.

iThemes Security – Server hat keinen Speicher mehr

Es ist ja nicht das erste Mal, dass iThemes Security Schwierigkeiten auf meinem Server verursacht. Seit vergangenen Donnerstag erhielt ich regelmäßige Mails von meinem Server, dass für den Abschluß einer Operation nicht genügend Speicherplatz vorhanden sei. Da die Internetverbindung im Tiroler Urlaubsdomizil recht schmal war und ich wegen des Urlaubs auch keine rechte Lust hatte mich mit dem Problem zu beschäftigen, ignorierte ich die Meldungen erst einmal. Gestern dann Stufe 2 der Warnungen: mein Provider teilte mir mit, dass auf meinem vServer nur noch 5% Speicherkapazität vorhanden sei. Eine kurze Überprüfung ergab nichts. Mein WordPress ist nicht viel größer als 900 MB und der Server stellt mir immerhin 100 GB zur Verfügung.

Heute dann Stufe 3 des Szenarios – es war weder möglich die Administrationsseite von WordPress aufzurufen noch per Plesk auf die Einstellungen meines vServers zuzugreifen. Lediglich per FTP war der Zugriff noch möglich. Ich machte mich auf die Suche und wurde nach intensiver Suche schließlich fündig: das SQL-Backup von iThemes Security versuchte im Minutentakt Backups anzulegen und die Dateien hatten eine Größe zwischen 500 und 700 MB, seit Donnerstag waren so 90 GB zusammen gekommen. Das Löschen dieser Dateien zog sich ein wenig, aber bereits nachdem einige Dateien gelöscht waren, konnte ich wieder auf meine Administrationswerkzeuge nutzen …

Ich bin mir sicher, dass ich keine Backups per iThems Security eingestellt habe. Zur Sicherung der Daten setze ich Parallells Plesk ein, für mich als Backupstrategie vollkommen ausreichend. Was (oder wer?) das beschriebene Szenario in Gang gesetzt hat ist mir unklar. Auf jeden Fall habe ich die Backupoption in iThemes Security nunmehr deaktiviert und hoffe nunmehr meine Ruhe zu haben …