Zunächst sollte einmal die korrekte Geschwindigkeit (remote) ermittelt werden. Dazu in einem ersten Schritt alle Downloads/Uploads (also auch Amazon Prime oder Amazon Music, Netflix und Co) beenden und unter https://www.breitbandmessung.de/ eine Messung starten. Einige Anbieter (wie z.B. die Telekom) bieten auch ein eigenes Portal (Telekom: http://kabelspeed.telekom-dienste.de/).
Diese Ergebnisse nun am besten in einer Word-Datei (als Screenshots) inkl. Angabe von Datum, Uhrzeit und Wetter (ja – wirklich … Wetter – d.h. Regen? Nebel? Sonne? ca. Temperatur) festhalten.
Zusätzlich sollte man auf seinem Router die Verbindungsgeschwindigkeit ermitteln und auch aufnehmen.
Meist gibt es diese Infos im DSL-Menü. Auf der Fritz!-Box z.B. unter Internet -> DSL-Information
Gründe für eine deutlich schlechte Verbindung:
Unsaubere Kontakte der Telefon-Anschluss-Dose (z.B. Schraub- anstelle Klemmanschlüsse) Kommt der Techniker, empfiehlt es sich generell den Tausch der Dose gegen eine mit Messwiderstand anzusprechen – so tut sich die Telekom mit etwaigen Störungen einfacher
Klemmstellen (oder noch schlimmer – vergessene Umschalter) zwischen Anschluss-Dose und Hausanschluss
Unsaubere Kontakte am Hausanschluss (Änderungen darf nur Telekom machen!)
Kalte Lötstelle oder schlechte Klemmung zw. Hausanschluss und Vermittlungsstelle (hier ist nicht jeder Techniker ausreichend motiviert – mit Hinweis auf eine schlechte Verbindung bei feuchtem Wetter klappt es aber meist doch)
In allen mir bekannten Fällen, klang es bei der Störungsannahme sehr dramatisch (“müssen wir wohl die Straße aufbuddeln”), letztlich hat aber schon der Besuch eines normalen Technikers mit viel Berufserfahrung eine deutliche Besserung (um den Faktor 3-4 im Download) gebracht. Die TOP3 waren dabei Anschlussdose, Hausanschluss und kalte Lötstelle/Klemmung.
So sehr wir an dieser Stelle sicher alle unsere Fritz!Box als eierlegende Wollmilchsau lieben, so sind wir uns denke ich bewusst, dass diese leider im Schul-Netz-Alltag nicht das geeignete Gerät ist (seit die Model-Funktion aus der Firmware entfernt wurde).
Als zuverlässiger Standard hat sich an dieser Stelle das draytek vigor 165 durchgesetzt. Es wird i.d.R. auch von den Netzanbietern “offiziell” (im Business-Umfeld) unterstützt.
Tipp: Egal ob vor einer pfSense/OPNsense oder einem kommerziellen Router – man sollte sicherstellen, dass man über diesen auch auf das vorgelagerte Modem zugreifen kann. So lässt sich nicht nur der entsprechende Status ablesen sondern auch komfortabel neue Firmware-Releases einspielen. Ich habe daher auf das PPPoE-Interface des Routers auch ein privates Subnetz gelegt, mit dem ich dann auf das Vigor 165 komme.
Nicht immer gelingt es, das CMS einer bestehender (Projekt-) Website zu aktualisieren. Oft steht auch der notwendige Aufwand, es mit einer aktuellen PHP-Version weiter zu betreiben in keinem Verhältnis.
Einige CMS bringen an dieser Seite eigene Tools mit oder empfehlen den konkreten Einsatz bestimmter Programme.
Wir haben letztlich zwei Wege getestet.
wget
Nach Anleitung und Erfahrungswerten im Internet, werden bei wget folgende Optionen empfohlen:
Je nach Alter der vorhandenen Mediawiki-Instanz, kann es sinnvoll sein, zunächst die Version 1.31.12 (in ein leeres Verzeichnis) zu entpacken und anschließend eine “saubere” neue Installation (in die bisherige) Datenbank vorzunehmen. Die LocalSettings.conf.php wird dabei neu erstellt und vorher die Datenbank migriert.
Im Anschluss können /images kopiert und die LocalSettings.conf.php angepasst (z.B. Setzen des Logos) werden.
Nach einer Sicherung (Datenbank und Verzeichnis) empfielt sich im Anschluss sich dann noch ein Update auf die neueste Version von Mediawiki.
Aus einem Schülerprojekt hatten wir eine Joomla-Instanz “geerbt”. Betrieben außerhalb des eigenen Verantwortungsbereiches. Aber wie so oft – ein damals wie heute unterstützeneswertes Projekt. Was also machen? Die Initiatoren mit dem Thema alleine lassen? Naja – man kann ja mal einen kurzen Blick riskieren.
Zugang verschaffen Gerade nach so langer Zeit ist ggf. der Zugang nicht mehr bekannt.
Alt, älter, ganz alt … Joomla und PHP-Kompatibilität In unserem Fall war Joomla “mittelalt”, jedoch alt genug um nicht mehr mit PHP5.6 oder neuer zu laufen.
Aber wie bekommt mein eine PHP5.4-Umgebung. Am einfachsten geht es natürlich schnell mit einer passenden virtuellen Maschine mit Debian (z.B. Wheezy) und PHP 5.4. Wer keine VM zur Verfügung hat, kann auch WAMP unter Windows installieren (https://sourceforge.net/projects/wampserver/ – benötigt wird hier die Version 2.2e. Nach dem Download muss in der PHP-Konfiguration jedoch noch zwingend openSSL aktiviert werden.
Die bisherige Joomla-Installation wird nun lokal im passenden Verzeichnis abgelegt und die gesicherte Datenbank (z.B. via phpmyadmin über http://localhost/phpmyadmin) eingespielt. In der configuration.php nun bitte zunächst Pfade und Datenbank-Zugangsdaten eintragen und etwaige Redirects durch Umbenennen der .htaccess deaktivieren. Mit http://localhost/administrator/index.php sollte nun die gewohnte Admin-Oberfläche wieder verfügbar sein.
Der erste Zugriff Unter System –> Systeminformation solle man sich nun zunächst einen ersten Überblick verschaffen und die Verzeichnisrechte überprüfen.
Das Update darf auf keinen Fall direkt auf die neueste Version erfolgen. Im vorliegenden Fall war die Version 3.1.5.
Die ersten zwei Updates Zunächst unter Erweiterungen -> Aktualisieren den Cache “Leeren” und nach “Aktualisierungen” suchen. Im vorliegenden Fall konnte nun über Aktualisieren bzw. Komponenten -> Joomla!-Aktualisierung ein Update auf 3.2.7 angestoßen werden.
Das Updaten auf die nächste Version (3.4.8) muss nun jedoch via Download erfolgen. Das Updatepaket wird dazu heruntergeladen (Link: https://downloads.joomla.org/cms/joomla3/3-4-8/) und nach C:\wamp\www\tmp\Joomla_3.4.8-Stable-Update_Package entpackt.
Über den Extension-Manager kann das Paket nun direkt aus dem Verzeichnis installiert werden:
Die aktuell installierte Version wird immer unten rechts angezeigt
Nun sollte die Joomla-Instanz zumindest mit PHP5.6 lauffähig sein. Wir haben sie daher an dieser Stelle zurück auf den Server kopiert (Dateien mit FileZilla, Datenbank via phpmyadmin).
SURY – das PHP-Wunder Auf dem produktiven Webserver haben wir mehrere PHP-Versionen im Einsatz. Neben der produktiven, haben wir stets eine PHP5.6 und diverse PHP7.x als CGI-Versionen verfügbar. So kann man auch in diesem Fall eine einfache “Migrations-Domain” migration.mein-projekt.de mit PHP5.6 bereitstellen.
Weiter mit dem Update Nachdem die Seite nun wieder live im Internet ist, sollte zunächst dringend das Passwort wieder geändert werden. Auch sollte der Webserver mittels HTTP-AUTH vor zu neugierigen Zugriffen geschützt werden, bis das Update abgeschlossen ist.
Ab Versionen >= 3.5 sollte PHP7 unterstützt werden. Bei unserer Migration scheiterten wir ab Version 3.6.5 jedoch bei der Verwendung von PHP-Versionen größer PHP7.0 (also mit PHP7.1/7.2/7.3 – während bereits vorhandene Instanzen jedoch mit PHP7.3 reibungslos funktionierten). Hier werden wir wohl noch etwas Nacharbeit investieren müssen, um auch die veraltete PHP7.0 deaktivieren zu können.
Ergänzung – abschließende Lösung? Alle PHP-Versionen benötigen die Pakete php7.1-mysql und php7.1-xml bzw. php7.2-mysql und php7.2-xml. Dann klappt es auch mit allen Versionen >PHP7.0.
Wer Debugging für Joomla anschalten möchte – dies geht in der configuration.php: Maximales Error-Reporting: public $error_reporting = ‘X’; Standard: public $error_reporting = ‘default’;
Ergänzung II – Fehler “using $this when not in object context” Der Fehler tritt erst ab >PHP7.1 auf und deutet häufig auf ein veraltetes Template hin. In unserem Fall ein selbst erstelltes mit ganz vielen “echo $this->template”.
Auch wenn das Debian-Team PHP auf einem vergleichsweise aktuellen Stand hält, kann es manchmal notwendig sein, noch aktuellere Versionen zu installieren. Dies geht relativ einfach via sury.org
Einfach eine readme.txt herunterladen, anschließend ausführen (dabei wird sury.org als Paketquelle ergänzt) und dann die gewünschten Pakete installieren: wget https://packages.sury.org/php/README.txt -O /root/sury.sh bash /root/sury.sh apt-get install libapache2-mod-php7.4
RRD-Files sind als Binärdateien plattformabhängig. Trotzdem kann man seine historischen Daten mit auf ein neues System nehmen (z.B. vom Raspberry PI auf eine VM).
In Remi Bergsmas hat die einzelnen Schritte in seinem Blog sehr ausführlich beschrieben (Link). Dabei werden die Daten zunächst in eine XML-Datei exportiert und im Anschluss auf dem Zielsystem auf dieser Basis neue (plattformspezifische) RRD-Files erzeugt.
Ein weiteres Tool ist an dieser Stelle Smokeping. Dieses sendet im Hintergrund fortlaufend Anfragen (z.B. ping, weitere Möglichkeiten sind aber auch gegeben) zu definierten Zielen und wertet diese grafisch aus. Der Betrieb auf einem Raspberry PI ist ohne Probleme zu realisieren.
Ausreißer können so einen ersten Ansatz zu weiteren Fehleranalyse liefern.
Beispielüberlegungen:
Wenn bereits das lokale Gateway Paketverluste hat, ist der Fehler eher im lokalen Netz zusuchen (Empfehlung: nicht nur Router sondern z.B. auch Fileserver oder NAS als Ziel eintragen; gerade ein Router kann bei einer hohen CPU-Last zu verzögerten Antworten führen)
Wenn heise.de, der Google DNS und die Uni Erlangen nicht erreichbar sind, ist eine Großstörung beim Anbieter oder (wesentlich wahrscheinlicher) ein Fehler auf dem Ausanschluss (z.B. FTH oder VDSL). Ein Gegencheck auf den DNS-Server des Providers kann hier erste Anhaltspunkte liefern.
Für viele Anwendungsfälle muss es nicht gleich eine teure Firewall von Sophos, LANCOM, Forcepoint, Checkpoint oder gar Cisco sein.
Bereits seit vielen Jahren prägen die beiden Projekte pfSense und OPNsense die IT-Landschaft. Letzteres ist dabei ein sogenannter Fork (d.h. eine “Ausgründung”) von PFSense. Auf den ersten Blick bietet OPNsense die modernere GUI. Eventuell kann es daher hilfreich sein, sich beide Systeme mal in einer virtuellen Umgebung (z.B. unter VirtualBox) anzuschauen und das für einen selbst optimale System so zu ermitteln.
Die Firewall kann anschließend auf einem alten HW-Server in Betrieb genommen werden oder stromsparend auf einem PC Engines APU.2E4 Board (Link zu einem Augsburger Reseller mit weiteren Infos zur Hardware). Als Datenträger empfiehlt sich dabei eine kleine mSATA-SSD – oder eine SSD aus einem defekten Notebook.
Im Netz gibt es unzählige Anleitungen zur Installation – hilfreich fanden wir die von Computing Competence.
Als VDSL-Modem haben sich die Geräte von Vigor zum Quasi-Standard durchgesetzt und werden auch bei Support-Calls mit dem Provider i.d.R. als “unterstützte Geräte” akzeptiert.
Update 31.10.2021 Inzwischen haben wir alle Firewall-Systeme in unserem Umfeld (3x auf Server-Hardware, 2x auf APU-Basis) auf OPNsense migriert. Das System bietet eine weitaus moderenere GUI und ist von den Features breiter aufgestellt.
