Vorgehensweise im Wiki¶

Für das Wiki von ubuntuusers bedeutet das Supportende von Precise Pangolin, dass Ubuntu 12.04 aus dem Wiki verschwinden wird. Bei der Bearbeitung der getestet-Boxen sollen nicht mehr unterstützte Versionen entfernt und die Artikel angepasst werden.

Des Weiteren werden alle Anwender gebeten, dass Wiki-Artikel, die nur mit dem EoL-Kandidaten (in diesem Falle 12.04) getestet wurden, bearbeitet oder dem Wikiteam gemeldet werden. Eine Übersicht der ungetesteten Artikel kann man auf Wiki/ungetestet einsehen.

Über das End of life gibt folgende Tabelle Aufschluss (siehe auch Ubuntu/Releases):

Unterstützungszeiträume
Codename	Versionsnummer	Releasedatum	Unterstützt bis
Zesty Zapus	17.04	13. April 2017	Januar 2018
Yakkety Yak	16.10	13. Oktober 2016	Juli 2017
Xenial Xerus	16.04 (LTS)	21. April 2016	April 2021
Trusty Tahr	14.04 (LTS)	17. April 2014	April 2019
Precise Pangolin	12.04 (LTS)	26. April 2012	April 2017

Upgrades¶

• Upgrade Precise auf Trusty

• Upgrade Trusty auf Xenial

Ubuntuversionen¶

• Steckbriefe der Ubuntuversionen

• Ubuntu/Releases

• Update: Ubuntu LTS - Long Term Support auf... - Ikhaya, 05/2016

• Warum LTS-Versionen die besseren sind – Ikhaya, 04/2014

• List of Ubuntu releases

Weitere Artikel zu den Servern¶

• Der Spendenaufruf

• Der erste Teil der neuen Server

• Die neuen Storage-Server

• Der Schalter wird umgelegt: Neue Server gehen in Betrieb

Vielen Dank an Into_the_Pit und encbladexp für den eingereichten Artikel!

Was ist ein Wiki-Snapshot?¶

Ein Wiki-Snapshot ist eine „Momentaufnahme“ des gesamten Wikis, der somit nur das Wiki zu einem bestimmten Zeitpunkt widerspiegelt. Änderungen, die nach dessen Erstellung vorgenommen werden, sind erst im nächsten Snapshot sichtbar. Auch wenn der Snapshot daher immer schnell veraltet, so hat das Desktop-Wiki einen großen Vorteil: Es lässt sich auch ohne Internetzugang benutzen.

Der jetzt veröffentlichte Snapshot hat einen Stand vom 25. März 2017. An dem Hinweis

oberhalb des Inhalts kann man erkennen, dass es sich um den Wikisnapshot handelt. In Zukunft sollen wieder kontinuierlicher neue Wiki-Snapshots erstellt werden.

Wo bekommt man den Snapshot?¶

Für den Fall, dass nur Wartungsarbeiten an Inyoka stattfinden, findet man unter https://staticwiki.ubuntuusers.de/ eine Onlineversion des Snapshots.

Alternativ kann man sich unter https://staticwiki.ubuntuusers.de/download/ ein Archiv mit dem Snapshot herunterladen. Dort stehen verschiedene Archivformate ohne und mit Bildern zur Verfügung.

Wie nutzt man den Snapshot?¶

Bei der Online-Version, braucht es – wie beim normalen Wiki auch – nur einen Browser.

Beim Download des Offline-Wiki muss das Archiv zuerst entpackt werden. Danach kann man das Offline-Wiki mithilfe eines Doppelklicks auf „index.html“ öffnen. Dazu ist wieder nur ein Browser nötig.

Wer den Snapshot durchsuchen möchte, findet im Wikiartikel Desktopsuchmaschinen einige Programme für diesen Zweck.

Checksums der Archive¶

Wer prüfen möchte, ob alles korrekt übertragen wurde, findet auf der Downloadseite oder direkt hier entsprechende SHA512-Hashes

6d2dde1ae011c1dc3c1dd4918e2b599da2dbf11e87080e233134c9760e537267cc3e00996440df8aba96d2cc08738d9536920076c183ba4dd345be98c110c707  ubuntuusers-wiki-images-20170325.7z
216f1c021546578bed0cb97ae40568ddff0f4573823ef54ab21d15a94f7d45148f02c0d1e899951730f300965efe9ae5dbb295c6e4db8c17a513d9ab9895a931  ubuntuusers-wiki-images-20170325.tar.xz
2440d11a3800e556f5ced4add3fb8860f955b485914e29bf64bc09ee5a6fb5e1c19fc6531bc581ae40745b1694ef39d84f322dd9f95820eb125ca100d75a1f9c  ubuntuusers-wiki-images-20170325.zip
b75aa82ec12f96bb06e30f4276daab425ad264ed6196be5051d11661494c61cade4f7eb24fdb0ed05244084a5c16130ed794583b543976e1823ee9ec081a749a  ubuntuusers-wiki-no-images-20170325.7z
5af2d091458c5396dd165f73d12d295a84a490d8272ba39ca206ab3aff227017f69e6b63f759e355c1341c2be700dc35b1e082cfc2df1709e9c806693f873be9  ubuntuusers-wiki-no-images-20170325.tar.xz
75bc815cbdf8331e02d8f703121947cbfd48a3eb6c9bb688bd6cca14950515d7b4b8264bf3b9ade98f899f794faad7ce693f9faef489f555a94a398ff51c4f86  ubuntuusers-wiki-no-images-20170325.zip

Umzug¶

Wir haben einen Sponsor gefunden, der zwar gerne anonym bleiben aber das Projekt stark unterstützen möchte. So können wir unseren offiziellen Sitz in die Schweiz verlegen, was rechtliche und, für den Verein, steuertechnische Vorteile bietet. Des weiteren erhoffen wir uns, dass Grossprojekte nun endlich termingerecht fertiggestellt werden.

Neuer Standort wird dementsprechend der Eigerplatz in Bern, nahe genug an der Politik, dass wir auch für die Verwendung von Free- und Open Source Software Lobbyarbeit betreiben können.

Änderungen¶

Eigerplatz Bern: hier entstehen unsere neuen Redaktionsräume. Foto: Karl-Heinz Fuchs, Freiburg, Schweiz

Natürlich zieht das auch einige Änderungen mit sich, einige kurz-, andere mittel bis längerfristig.

Als Erstes wird, wie viele sicher schon bemerkt haben, die Nutzeroberfläche entsprechend angepasst. Um uns in der Schweiz anzumelden, müssen wir beweisen, dass wir nicht nur die Landessprachen beherrschen, sondern auch in der Kultur integriert sind. Dementsprechend erfolgen folgende Änderungen:

• aus ubuntuusers.de wird ubuntuusers.ch, die alte Domäne wird im Verlaufe Q2 2017 umgeleitet, anschliessend in Q3 deaktiviert

• die Oberfläche erscheint in den Landessprachen. Gemäss Anteilen wird an 50% der Monatstage die Oberfläche auf Schweizerdeutsch, an 30% der Tagen in Französisch, an 15% in Italienisch und an 5% in Rumantsch erscheinen. Heute erfolgt die erste Umstellung auf Schweizerdeutsch, dabei wurde vorerst "Seeländer Berndeutsch" gewählt, weitere Dialekte folgen.

• Es gibt keine Nutzerkonten mehr, sondern nur noch Nummernkonten. Bis Ende Q2 2017 werden alle Nutzer von ubuntuusers.de zu einer eindeutigen, aber anonymen Nummer umbenannt. Spezielle Nummern, wie etwa 42 oder 23, sind Premium-Nummern, die man für einen Aufpreis erwerben kann.

• Aufgrund der Wahlen (siehe unten) ist es erforderlich, dass jede Person nur einen Account hat. Um dies zu überprüfen, brauchen wir von allen Nutzern bei Anmeldung ein Scan eines amtlichen Ausweises, z.B. Reisepass. Bestehende Nutzer haben eine Frist von 4 Monaten, um diese einzureichen, ansonsten wird der Account deaktiviert.

• Die Mitglieder des Teams werden neu demokratisch durch die Nutzerschaft gewählt. Erste Wahlen erfolgen nach Ablauf der Einreichefrist für Ausweise am 1. August 2017, der zugleich als neuer Forumsfeiertag bestimmt wird.

• Die Projektleitung wird abgeschafft und durch einen aus 7 Ministern (Support, Bildung, Kommunikation, Entwicklung, Technik, Personelles, Finanzen) bestehenden Portalrat ersetzt. Dieser wird durch das gewählte Team alle 4 Jahre bestimmt.

• Das Team "Moderatoren" wird aus Neutralitätsgründen abgeschafft, stattdessen können Nutzer Sanktionen vorschlagen. Ab 100 gesammelten Nutzerstimmen kommt es zu einer Abstimmung, welche Sanktionen (Verwarnung, temporäre Sperre, dauerhafte Ausschaffung) bestimmen kann.

• Einige Zeichen, wie etwa ß oder €, werden ab dem ersten Mai nicht mehr akzeptiert.

• Aus Gründen der beschränkten Zuwanderung gibt es monatliche Kontingente an ausländischen Nutzern, die sich bei ubuntuusers registrieren dürfen.

• Nutzern aus Österreich wird der Zugriff auf ubuntuusers.ch verwehrt.

Grüessech Schwyz¶

Wir sind uns sicher, dass nur eine kurze Eingewöhnungszeit notwendig ist und wir alle von diesen Änderungen profitieren werden.

Und damit schliessen wir den letzten auf Hochdeutsch verfassten Artikel auf ubuntuusers, sägä viu mou merci a au üsi Nutzerinnä und Nutzer, wünschä no ä hiubä Tag u ä guäti Züglätä i diä schöni Schwyz!

Update: Erklärung zum Aprilscherz¶

Wie die meisten sicher schon selbst gemerkt haben werden: Es war 1. April, dem Team war langweilig und einige kamen schon vor einigen Wochen auf die Idee, ubuntuusers.de in die Schweiz ziehen zu lassen. Wir hoffen, dass niemand durch die Aktion zu sehr gestört wurde. Die Rückmeldungen waren zum sehr großen Teil positiv. Gleichzeitig noch ein Dankeschön an alle Beteiligten, die den Scherz ermöglicht haben.

Und zum Schluss ein „fun fact“ für Später: Die Domain ubuntuusers.ch gehört dem ubuntu Deutschland e.V. wirklich.

Wien, 2017-01-14, 14:36 CET¶

Um erstmal einen Eindruck zu bekommen, wie sich das Update über 2 Versionen verhält, wurde zunächst der Standort Wien aktualisiert. Hier liegen für den Betrieb von Ubuntu-EU unkritische Systeme und bieten somit eine gute Testumgebung.

Wie sich herausstellte, war das auch keine schlechte Idee, denn die ersten Probleme ließen nicht lange auf sich warten. Da auf den Servern keine udev-Regel vorhandenen war, wurde das Netzwerk Interface beim Upgrade auf Xenial still und heimlich von eth0 in ens192 umbenannt. Somit war der Zugriff von außen nicht mehr möglich, da unsere iptables Regeln weiter mit dem alten Namen arbeiteten.

Nachträglich nochmal ein großes Dankeschön an unseren Hoster Anexia in Wien, der uns an einem Samstag mit sehr kurzen Reaktionszeiten positiv überrascht hatte. Nachdem der Fehler lokalisiert und behoben wurde, lief das Upgrade bei den folgenden Services ohne weitere Schwierigkeiten durch.

Der Abschluss der Arbeiten in Wien erfolgte am gleichen Tag um ca. 18 Uhr.

Köln, 2017-01-22, 13:37 CET¶

Als nächstes stand Köln auf der TODO-Liste des Serverteams. Hier sind vor allem die Dienste für unsere Partner-Communities und die vom Verein gehosteten Seiten zu finden.

Die Aktualisierungen gingen hier auch wesentlich unspektakulärer von statten, da die Server kaum von der Standardinstallation abwichen. Kleinere Anpassungen wie zum Beispiel bei den Virtualhosts der Apachen oder den VMs der KVM-Hosts waren schnell erledigt. Auch die Dienste unserer Partner-Communities hatten kaum größere Probleme. Dennoch blieb das Serverteam bei einzelnen VMs auf 14.04, da noch nötige Anpassungen wegen PHP7 erfolgen müssen.

Als letztes war dann unser Datenbank- und Storage-Server für NFS dran. Und es kam, wie es kommen musste. Murphy hatte mit srv10 etwas besonderes geplant. Das Upgrade lief normal an, PostgreSQL sollte aktualisiert werden und – nunja – der restliche Tag wurde dann mit einem Restore von srv10 und etlichen Flüchen gen Himmel bestritten. Hintergrund war hier, dass neuere PostgreSQL-Versionen – genau wie bei MySQL – bestimmte Settings aus früheren Versionen nicht mehr unterstützen. Deshalb wurde beim Neustart des Dienstes, welches das post-installation Script durchführte, das komplette dist-upgrade abgebrochen. Da zu diesem Zeitpunkt bereits für das System kritische Libraries aktualisiert waren, haben wir auf ein aufwändiges Fixen verzichtet und den Server direkt mit Ubuntu Xenial neu installiert. Das Neueinrichten des Servers konnte durch unsere Automatisierung per ansible deutlich beschleunigt werden, die fehlerhaften Einstellungen für PostgreSQL und MySQL wurden so auch identifiziert und korrigiert.

Durch die Neuinstallation von srv10 waren die Arbeiten erst am späten Abend von 2017-01-24 gegen 21 Uhr abgeschlossen. Insgesamt verteilten sich die Arbeiten über 3 Tage. Zu beachten ist, dass Köln die meisten Systeme hostet.

Nürnberg, 2017-02-22, 10:00 CET¶

Zum Abschluss wurde der Standort Nürnberg aktualisiert. Angefangen wurde hier bei den redundanten Systemen, so dass direkte Auswirkungen für unsere Anwender ersteinmal ausblieben. Nachdem die sekundären Systeme wie zum Beispiel der MySQL-Slave, unser sekundärer Loadbalancer oder der zweite Application Server aktualisiert waren, gab es auch eine längere Downtime für die primären Systeme.

Während dieser Downtime wurde der MySQL-Master, der primäre Loadbalancer und das Storage ebenso aktualisiert wie der letzte noch verbliebene Application Server. Das Update verlief hier deutlich angenehmer, da wir durch die anderen Standorte und die zuvor aktualisierten Backup/Zweitsysteme ausreichend Erfahrung mit identischer Hardware und Services sammeln konnten. Am längsten hat der Restore unserer MySQL Datenbank sowie die Neueinrichtung der Replikation gedauert. Das vollständige Konfigurieren einer neuen MySQL-Instanz dauert übrigens nur noch ca. 1 Minute und 30 Sekunden, was an unserer weit voran getriebene Automatisierung liegt. Der Restore der entsprechenden Datenbanken kann aber durchaus 45 Minuten oder länger dauern.

Wie in einem Ikhaya Artikel bereits erwähnt, haben wir die Upgrades dieser Systeme an zwei aufeinander folgenden Tagen durchgeführt.

systemd¶

Seit Ubuntu 16.04 hat auch systemd in die Ubuntuwelt Einzug gehalten. Wir haben bei der Migration auch direkt das früher verwendete supervisord durch neu geschriebene systemd Units ersetzt. Gleichzeitig war es erforderlich, vorhandene Unit Files anzupassen, so dass Dienste zwangsweise in der für uns richtigen Reihenfolge gestartet werden.

Apache¶

Bei Apache wurden unsere Server durch das Upgrade von precise nach trusty von Apache 2.2 auf Apache 2.4 aktualisiert. Hierdurch waren einige Anpassungen an der Syntax unserer virtual Hosts erforderlich.

Gleichzeitig sind wir über einen Bug in dem zuvor verwendeten libapache2-mod-itk gestolpert. Denn dieser wollte partout nicht mehr mit unserem über NFS verteilten Document Root arbeiten. Als Kompensation läuft Apache nun vollständig als User der entsprechenden Community. Das wurde erst durch die zuvor eingeführte Virtualisierung und Trennung der Communities auf verschiedene Hosts ermöglicht.

Wer mehr zur Infrastruktur von ubuntuusers.de und den Communities von Ubuntu-EU lesen möchte, sei auf einen etwas älteren Ikhaya-Artikel hingewiesen.

Python / node.js¶

Sobald Python oder node.js Anwendungen im Einsatz sind, sollten hiervon die entsprechenden Cache-Verzeichnisse gelöscht werden. Nur so ist sichergestellt, dass die Abhängigkeiten dieser Anwendungen auch stets gegen die neuen Versionen ihrer Bibliotheken gelinkt sind.

libvirt¶

Bei libvirt war in der früheren Version innerhalb der Host Definitionen der Typ virtueller Maschinen anders. Hier war ein händischer Eingriff erforderlich, um den Typ auf einen in den neueren Versionen vorhanden wie pc-i440fx-xenial zu ändern. Erst danach konnten die virtuellen Maschinen wieder gestartet werden.

MySQL / PostgreSQL¶

Wie zuvor erwähnt, ist zu beachten, ob die verwendeten Datenbankeinstellungen mit der jeweils neuen Version der Datenbankserver noch kompatibel sind. Im Zweifel kann es von Vorteil sein, vor dem Upgrade ein ohnehin sinnvolles Backup zu erstellen und die Datenbankserver zu deinstallieren. Bei PostgreSQL ist dies ohnehin der empfohlene Weg; für MySQL kann es zumindest nicht schaden.

Als Besonderheit bei MySQL sei noch erwähnt, dass ein frisch formatiertes ext4-Dateisystem auf einer eigenen Partition für /var/lib/mysql einen lost+found Ordner enthält. Dieser sorgt zuverlässig zum Abbruch der MySQL Installation, da das Skript zur Initialisierung der Datenbanken nicht durchläuft. Es ist ratsam, bei einem vergleichbaren Setup diesen zuvor zu löschen und nach der Installation wieder anzulegen. Als Alternative kann natürlich auch XFS oder ein anderes geeignetes Dateisystem verwendet werden. Wir haben uns aber für ext entschieden, da dies zum einen sehr robust ist. Zum anderen kann es auch offline wieder verkleinert werden.

Wahlen der Teamleitungen¶

Nachdem im Januar schon die Projektleitung und einige Teamleitungen gewählt wurden, folgen nun die übrigen Teamleitungen: