Nach mehreren Updates von Gitlab bzw. der Linux-Distribution fiel auf. dass bei Issues/Tickets zwar weiterhin Uploads (unabhängig von Typen) möglich waren und diese auch abgelegt wurden – ein Abrufen war jedoch nicht möglich.
Nach dem anschließenden Upload, sollte der Filecounter entsprechend angestiegen sein. Dies war im vorliegenden Fall gegeben.
Schritt 2 – Betrachtung der Architektur Als Webserver kommt auf dem System apache2 zum Einsatz – primär um auch weitere Sites auszuliefern. Es handelt sich dabei um ein „Multi-Domain-Setup“. Es steht dabei nur eine IP zur Verfügung. Apache2 ist daher als Reverse-Proxy konfiguriert und liefert entsprechend die GIT-UI aus. Der GIT-interne NGINX ist dabei deaktiviert. Bewertung: Zahlreiche Beiträge weisen darauf hin, dass man trotz apache2 nicht auf den zwischengeschalteten NGINX verzichten sollte.
Schritt 3 – Umsetzung der Optimierungen Als Webserver kommt auf dem System apache2 zum Einsatz – primär um auch weitere Sites auszuliefern. Es handelt sich dabei um ein „Multi-Domain-Setup“. Es steht dabei nur eine IP zur Verfügung.
Anpassungen im Detail:
lokaler NGINX (aus gitlab-Package) auf localhost:8081
Reaktivierung NGINX (inkl. Deaktivierung sendfile) /etc/gitlab/gitlab.rb ############################################################ # Externe URL (die URL, die Benutzer aufrufen) ############################################################ external_url 'https://gitlab.mydomain.org' ############################################################ # GitLab interner Nginx ############################################################ nginx['enable'] = true # Alle nginx-Listener (Frontend + interne Ports) nur lokal binden nginx['listen_addresses'] = ['127.0.0.1'] # Frontend-Port für Apache-Proxy nginx['listen_port'] = 8081 nginx['listen_https'] = false
Nach einem gitlab-ctl reconfigure gitlab-ctl restart kann man die Umsetzung kontrollieren:
Schützen weiterer NGINX-Ports mittels lokaler Firewall (ufw) Wie im Screenshot zu sehen, lässt sich der Port tcp/8060 nicht einschränken. Um auf diesen den unberechtigten Zugriff zu verhindern, kommt daher UFW zu Einsatz. Vor der Einrichtung der lokalen Firewall sollte dringend verifiziert werden, dass es noch einen weiteren Zugriffsweg (z.B. über das Web-Interface des Cloud-Server-Anbieters) gibt. Anschließend kann UFW installiert und konfiguriert werden:
Installation und setzen der Default-Einstellungen (inkl. Erlauben des SSH-Zugriffs): demo-adm@demo2:~# sudo apt-get install ufw Reading package lists... Done Building dependency tree... Done Reading state information... Done demo-adm@demo2:~# sudo ufw default allow outgoing Default outgoing policy changed to 'allow' (be sure to update your rules accordingly) demo-adm@demo2:~# sudo ufw default allow incoming Default incoming policy changed to 'allow' (be sure to update your rules accordingly) demo-adm@demo2:~# sudo ufw allow ssh Rules updated Rules updated (v6)
Blockieren des Zugriffs auf tcp/8060: demo-adm@demo2:~# sudo ufw deny 8060 Rules updated Rules updated (v6)
Aktivieren: demo-adm@demo2:~# sudo ufw enable Command may disrupt existing ssh connections. Proceed with operation (y|n)? y Firewall is active and enabled on system startup@admin-phf
Kontrolle:
Konfiguration von Apache2 als Reverse-Proxy Als letzten Schritt gilt es nun, den Apache zu konfigurieren bzw. die Konfiguration auf das Zusammenspiel mit NGINX zu optimieren.
/etc/apache2/sites.available/gitlab.conf
<VirtualHost *:443>
ServerName gitlab.mydomain.org
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/gitlab.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/gitlab.example.com/privkey.pem
# Proxy Einstellungen
ProxyPreserveHost On
ProxyRequests Off
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Ssl "on"
# Apache-Optimierungen für GitLab
EnableSendfile Off
EnableMMAP Off
LimitRequestBody 0
# ProxyPass zum internen GitLab-nginx
ProxyPass / http://127.0.0.1:8081/ nocanon retry=0 timeout=300
ProxyPassReverse / http://127.0.0.1:8081/
# WebSocket-Unterstützung (ActionCable)
RewriteEngine On
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.*) ws://127.0.0.1:8081/$1 [P,L]
# Logging
ErrorLog ${APACHE_LOG_DIR}/gitlab_error.log
CustomLog ${APACHE_LOG_DIR}/gitlab_access.log combined
</VirtualHost>
Anschließend noch relevante Module aktivieren, die Site aktivieren und Apache2 neu starten.
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 genutzter Anschluss-Dose und Hausanschluss – dies kann auch eine (eigentlich unzulässige) Reihenschaltung mehrerer Anschluss-Dosen sein. Dieses Konstrukt findet man v.a. in schlüsselfertig sanierten oder gebauten Gebäuden – erschwerend dann noch meist ohne Dokumentation.
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 bzw. unbekannte weitere Anschlussdose in Reihe, 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.
