Apache 2 on Michael’s Domain

1000 Mal zu langsam

Thu, 01 Dec 2016 00:00:00 +0000

Die Universität Helsinki hat Teile ihrer IT-Infrastruktur an Microsoft ausgelagert. Auch wenn Outsourcing kurzfristig kostengünstiger ist als die lokale Bereitstellung gleichwertiger Dienste, ist die Nettoauswirkung aufgrund des Verlusts von Arbeitsplätzen, Know-how und Unabhängigkeit wahrscheinlich negativ. Um dieses selbstzerstörerische Verhalten zu erklären, bedarf es keiner Verschwörungstheorie, sondern lediglich schlechter Entscheidungskriterien, die langfristige und externalisierte Kosten außer Acht lassen. In seinem Bestreben, ein Upgrade auf neuere Windows-Versionen durchzusetzen, beendete Microsoft am 8. April 2014 den erweiterten Support für Windows XP, und die Universität kam dieser Aufforderung nach, indem sie XP-Rechnern den Netzwerkzugang verwehrte. Als Begründung wurde angeführt, dass XP zu einem Sicherheitsrisiko geworden sei. Gleichzeitig entfielen auf Windows XP immer noch etwa 20 % aller Windows-Installationen weltweit ( https://www.statista.com/statistics/218089/global-market-share-of-windows-7/ ). Selbst im Oktober 2015 liefen noch weit über 100 Millionen Computer unter Windows XP ( https://en.wikipedia.org/wiki/Usage_share_of_operating_systems und https://www.statista.com/statistics/218089/global-market-share-of-windows-7/ ), ohne dass dies katastrophale Folgen hatte. Das Auslaufen von Windows XP stellte ein Problem dar, da vier unserer Geräte, die wir für die Forschung benötigen, nach wie vor mit Windows XP laufen. Und es gibt keine Möglichkeit, das Betriebssystem zu aktualisieren, ohne die Geräte aufzurüsten (was Tausende oder Zehntausende Euro kosten würde und daher angesichts der derzeit angespannten finanziellen Lage der Universität weitgehend unmöglich ist). Und natürlich ist die Software, die zum Betrieb der Geräte benötigt wird, nicht mit Windows 7 kompatibel. Infolgedessen können wir diese Geräte weder fernsteuern noch automatische Backups durchführen. Selbst das Übertragen der Daten zur Analyse auf einen anderen Computer erfordert das Adidas-Netzwerk . Ich hatte den IT-Support bereits lange vor Ablauf des erweiterten Supports für Windows XP kontaktiert und darum gebeten, eine Lösung zu finden. Anscheinend gab es verschiedene Lösungsmöglichkeiten, und der IT-Support begann auch mit deren Umsetzung, doch aufgrund von Personalfluktuationen musste das Projekt mehrmals „neu gestartet“ werden, und verschiedene Support-Mitarbeiter hatten unterschiedliche Meinungen dazu, wie dieses Problem gelöst werden sollte. Mit der großen „Fire-and-Hire“-Aktion an der Universität brach das gesamte Projekt erneut zusammen. In diesem Herbst habe ich unsere Anforderungen erneut mit den IT-Mitarbeitern besprochen, bisher jedoch keine konkrete Hilfe erhalten. An diesem Dienstag wollte ich endlich wissen, wie schwierig es wirklich ist, einen Windows-XP-Rechner so an das Netzwerk anzuschließen, dass die Sicherheit nicht beeinträchtigt wird, aber Dateiverteilung, Datensicherung und Fernsteuerung möglich sind. Ich ging zum Müllplatz des Instituts, wo defekte Elektronikgeräte gesammelt werden, und nahm drei alte 10/100-Netzwerkkarten sowie ein paar Ethernet-Kabel mit. Eine Karte und ein Kabel funktionierten noch; ich steckte die Netzwerkkarte in einen Computer mit Ubuntu 16.04 und verband diesen über ein Ethernet-Kabel mit einem der XP-Rechner. Nachdem ich der Netzwerkkarte manuell eine IP-Adresse zugewiesen und Samba auf dem Ubuntu-Rechner installiert hatte, konnte ich die Samba-Freigabe auf dem Windows-XP-Rechner als Laufwerk einbinden. Anschließend habe ich die Samba-Freigabe einfach über eine Webseite zugänglich gemacht. Das Ganze dauerte etwa eine Stunde. Da ich kein IT-Profi bin, habe ich vielleicht noch drei weitere Stunden damit verbracht, zu recherchieren, wie das geht (Samba-Einrichtung, Apache-Einrichtung, Konfiguration einer zweiten Netzwerkkarte, was unter Ubuntu nicht automatisch erfolgt). Diese Konfiguration erfüllt alle unsere Anforderungen, hat nichts gekostet und wurde innerhalb eines Tages umgesetzt. Eine Beschreibung der technischen Details folgt, sobald ich dazu komme, meine Vorgehensweise zu dokumentieren. Agilität ist vielleicht das, was am meisten fehlt, wenn ich mir viele der IT-Projekte unserer Universität anschaue. Ich denke dabei insbesondere an die Umstellung auf Drupal als Content-Management-System für die Webseiten der Universität. Leider nutzt unsere Fakultät nach wie vor Dreamweaver zur Erstellung ihres Webauftritts, was zur Folge hat, dass viele Webseiten nie aktualisiert werden.

Let's Encrypt hat meine Protokolldateien dupliziert

Wed, 19 Oct 2016 00:00:00 +0000

Bis Anfang 2016 habe ich keine Protokolldateien für meinen Webserver geführt. Zu diesem Zeitpunkt musste ich die Zugriffe auf bestimmte Dateien nachverfolgen (ich begann, awstats zu nutzen, vor allem, weil ich damit vertraut war, da ich es schon vor Jahren verwendet hatte, als meine Website noch auf einem Red-Hat-Server lief). Im März 2016 habe ich glücklicherweise begonnen, Let’s Encrypt zu nutzen. Zuvor hatte ich einen anderen „kostenlosen“ Dienst verwendet, der kürzlich in große Schwierigkeiten geraten war, da er offenbar keine Kontrolle über seine eigene Sicherheit hatte. Als ich mir die Logdateien meines Apache-Servers (unter Ubuntu 14.04) ansah, fiel mir auf, dass Apache doppelt protokollierte (sowohl in die Logdatei des jeweiligen virtuellen Hosts als auch in eine gemeinsame Logdatei). Mir wurde klar, dass Let’s Encrypt in der Konfigurationsdatei jedes virtuellen Hosts eine „Import“-Anweisung vorsieht, die auf die Datei /etc/letsencrypt/options-ssl-apache.conf verweist. Und diese Datei legt wiederum gemeinsame access.log- und error.log-Dateien für alle virtuellen Hosts im Verzeichnis /var/log/apache2/ fest. Ich habe die fünf Zeilen, die mit dieser Protokollierung zusammenhängen, auskommentiert, woraufhin die doppelte Protokollierung aufhörte (ursprünglich hatte ich angenommen, dass diese Let’s Encrypt-Anweisung nur für die anfängliche Let’s Encrypt-Einrichtung zur Zertifikatserstellung verwendet wurde).

Apache2 über YaST2 konfigurieren und starten

Wed, 04 Apr 2007 00:00:00 +0000

Yast ist natürlich genauso wenig benutzerfreundlich, was Fehlermeldungen angeht, wie jedes andere Linux-Programm auch. Ich habe versucht, Apache2 über Yast2 zu starten, und im Konfigurationsassistenten gab es nur drei Felder auszufüllen: Servername, E-Mail-Adresse des Administrators und Listening-Port. Als Servernamen habe ich „Suse Linux“ eingegeben. Als Yast2 die Konfiguration vornehmen wollte, lautete die Fehlermeldung: Fehler: Apache2-Dienst kann nicht angepasst werden Cool. Hätte ich Apache manuell gestartet (sudo /etc/init.d/apache2 start), wäre mir unter den Fehlermeldungen die folgende Zeile aufgefallen: httpd2 (prefork) wird gestartet. Syntaxfehler in Zeile 11 von /etc/apache2/sysconfig.d/global.conf: ServerName erwartet ein Argument: den Hostnamen und den Port des Servers Offensichtlich wurde „Suse Linux“ als zwei Argumente interpretiert. Also kehrte ich zur grafischen Benutzeroberfläche zurück und änderte den Wert in „Suse_Linux“ – diesmal funktionierte es.