Munin – nach Opensuse Upgrade wieder herstellen

Ich nutze auf einem Opensuse Server Munin – u.a. auch zur Überwachung von LDAP und MySQL. Nach einem Upgrade des Systems von Opensuse 12.3 auf Opensuse 13.1 funktionierte Munin leider nicht mehr. Im Paketmanager wurde mir angezeigt, dass es keine installierten Pakete mehr gab. Offenbar wurden die beim Upgrade deinstalliert.

Ich musste Munin nachinstallieren und zwingend als nativen “systemd”-Service aktivieren (besser: “enablen”). Im Verzeichnis “/etc/init.d” wird man unter OS 13.1 keine Munin-Startup-Datei mehr finden. Man erhält Munin für OS13.1 über das Repository
http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.1

Dann die Pakete “munin” und “munin-node” per Yast2’s Software Management installieren. Der RPM Paket-Manager legt Sicherungskopien der Konfigurationsdateien

/etc/munin/munin.conf
/etc/munin/munin-node.conf
/etc/munin/plugin-conf.d/munin-node

an. Diese kann man nutzen, um die alten Konfigurationseinstellungen in die neuen Dateien zu übernehmen.

Danach

systemctl enable munin-node.service

Und schon läuft die Sache wieder. Die alten Daten bzw. Plots unter “/srv/wwww/htdocs/munin” und dort unter dem konfigurierten Munin-Tree sind nicht verloren, sondern werden weitergeführt. Auf aktualisierte Wochenplots muss man nach der Neuinstallation natürlich aber noch etwas warten ….

dd und YaST – unterschiedliche Speicherplatzangaben ?

Manchmal will man ganze Partitionen sichern. Bei mir trat eine solche Situation auf, als ich einen produktiven KVM- und LDAP-Host von Opensuse 12.3 auf OS 13.1 upgraden wollte. Das ist bei Opensuse leider immer ein Spiel mit dem Feuer. Von anderen Systemen weiß ich bereits, dass es dabei Probleme mit Apache2 geben wird und auch mit dem LDAP-System geben kann. Ferner ist das Upgrade von KVM mehr als kritisch. (Es funktioniert nämlich nicht, wenn man die Standard SuSE-Repositories nutzt. Dazu mehr in einem anderen Beitrag.) Viele Gründe, um die alte, bestens laufende Serverinstallation in keinem Fall verlieren zu wollen.

Ein Mittel, um Partitionen relativ schnell zu sichern, ist das blockweise Klonen der ganzen Partition mit dem Befehl “dd”. Siehe z.B.
http://wiki.ubuntuusers.de/dd
http://www.techrepublic.com/blog/linux-and-open-source/drive-and-partition-backups-with-dd/
https://wiki.archlinux.org/index.php/Disk_Cloning
http://konstantin.filtschew.de/blog/2007/07/22/partitionen-mit-dd-unter-linux-sichern-und-auch-mal-per-ssh-uber-das-netzwerk/

Natürlich muss man vor dem Backup checken, dass die Zielpartition mindestens die Größe der zu sichernden Partition hat. Meine zu sichernde Partition liegt auf einem mit GPT (hybrid) formatierten Platten-System als ext4-Partition “/dev/sda4” und weist lt. YaST2’s “Partitioner” eine Größe von

120,01 GB

auf. Auf dem Plattensystem für das Backup gibt es ebenfalls eine ext4-Partition “/dev/sdb2” mit exakt der gleichen Größe.

Mit

tune2fs -l /dev/sda4″ und
tune2fs -l /dev/sdb2

kann und sollte man zudem die Blöcke und die Blocksize vergleichen. Die Partitionen sollten beim Klonen natürlich nicht gemountet sein. Auf “/dev/sda2” meiner Server liegt immer ein funktionstüchtiges Mini-Opensuse, mit dem ich jederzeit solche Wartungsaufgaben durchführen kann. nach dem Booten dieses Systems kann man dann folgenden Befehl absetzen:

dd if=/dev/sda4 of=/dev/sdb2 bs=4M

Die “bs”-Option dient der Beschleunigung des ganzen Vorgangs. Siehe hierzu die “man”-Seiten zu “dd”. Diese Option hat keine Konsequenzen für die Blockgrenzen. Nach Abschluss des Kopiervorgangs meldet “dd” dann, dass

128,86 GB

geschrieben wurden. Wieso das denn ? Wieso wurde mehr geschrieben als lt. YaST2 vorhanden?

Hier kann man schon nervös werden. Denn die Partition “/dev/sb2” auf der Zielplatte wird von mehreren anderen Partitionen gefolgt. Wurde also durch den Kopiervorgang größerer Schaden angerichtet? Ein

fsck -f /dev/sdb2
fsck -f /dev/sdb3

zeigt aber, dass alles in Ordnung ist. Woher also die unterschiedlichen Größenangaben? Als nächstes sehe ich mir die Größen der Partitionen auf “/dev/sda” mit “parted” an:

xserv:~ # parted -l /dev/sda
Model: AMCC 9650SE-4LP DISK (scsi)
Disk /dev/sda: 4000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt_sync_mbr
 
Number Start End Size File system Name Flags
…..
4 238GB 367GB 129GB ext4 primary
…..
 
Model: AMCC 9650SE-4LP DISK (scsi)
Disk /dev/sdb: 4000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt_sync_mbr
 
Number Start
End Size File system Name Flags
…..
2 138GB 267GB 129GB ext4 primary
…..

Aha, “parted” sagt was anderes als YaST ! Ok, dann nochmal Daten mit “tune2fs -l” abgefragt und nachgerechnet:

tune2fs -l /dev/sda4
tune2fs 1.42.8 (20-Jun-2013)
Filesystem volume name:
Last mounted on: /root
Filesystem UUID: 265ea396-f23a-45f2-b3a2-eea7d417db18
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 7872512
Block count: 31459328
Reserved block count: 1572966
Free blocks: 25875909
Free inodes: 7547984
First block: 0
Block size: 4096
……

Block count * Block Size = 31459328 * 4096 = 128 857 407 488

Aha, “parted” hat also recht ! Was zeigt also YaST an ? Evtl. GiB? Siehe zum Unterschied zwischen GB und GiB
http://en.wikipedia.org/wiki/Gigabyte
Zitat:

“For example, a memory capacity of 1073741824bytes is conveniently expressed as 1 GiB rather than as 1.074 GB. The former specification is, however, almost always quoted as 1 GB when applied to internal memory.”

Also mal nachgerechnet:

128857407488 / 1073741824 = 120,0078125

YaST gibt die Speichergröße von Partitionen in GiB an, “parted” und “dd” dagegen in echten GB.
Erkenntnis: Wenn man verschiedene Linux-Tools nutzt, erhält man ggf. unterschiedliche Angaben zur Größe von Speicherplatz.
Also nicht verwirren lassen ! “dd” arbeitet schon so wie erwartet !

Bye, bye Open-Xchange

Habe vor kurzem ein laufendes Opensuse 12.3-System auf Opensuse 13.1 upgegradet. Das ging bis auf einige Schwierigkeiten mit der neuen Apache 2.4 Version relativ problemfrei – nur ein lokaler Open-Xchange 6.22 Server hat das nicht überlebt. Na ja, ganz stimmt das so nicht – eigentlich überlebte nur das vom Server bereitgestellte Web-Interface nicht. Aus welchen Gründen auch immer – das für OX6 reservierte Verzeichnis im Bereich “/srv/www/htdocs” war nach dem Update und einem Neustart von OX6 von allen relevanten Dateien befreit, obwohl die Verzeichnisstruktur erhalten geblieben war.

Ich konnte den ursprünglichen Zustand aus Backups zwar wieder restaurieren. Da das Problem mit Open-Xchange und Opensuse-Upgrades aber nicht zum ersten Mal aufetreten, freunde ich mich gerade mit dem Gedanken an, ganz auf diese Groupware-Lösung zu verzichten. Das hat neben der Anfälligkeit gegenüber System-Updates noch mehrere andere Gründe:

Grund 1: Keine Lizenz-Variante für SLES unter 25 User
Ich habe nicht vergessen, wie uneinsichtig sich OX bzgl. eines Upgrades von einer 5-User-Lösung unter SLES beim Wechsel von OX 5 auf OX 6 zeigte. Damals bekam ich klar Bescheid, dass ich entweder auf einen UC-Server umsteigen oder eben eine 25 User-Lizenz erwerben müsse. Dabei war mir der Umstieg auf eine 5-User-Lizenz von einer ursprünglichen 25 User umfassenden SLOX-Lösung von OX selbst empfohlen worden. OK, die Botschaft kam an – OX wollte ab den ersten Erfolgen mit 1&1 offenbar nur noch hinreichend große Kunden haben und entsprechend Geld verdienen. Das auch kleine Unternehmen einen SLES oder RHEL einsetzen, war den Strategen in den USA wohl egal. Als Konsequenz habe ich mit der Community-Version von OX6 dann sehr gut ein paar Jahre unter Opensuse und ohne jede Lizenzgebühr gelebt. Jetzt ist auch damit Schluss.

Grund 2: Verschwindender Support für die Community Edition
Wie wenig die Community Edition noch Bedeutung hat, kann man auch dem Inhalt und Aufbau der aktuellen OX-Website entnehmen. Eine spezielle Seite für die CE gibt es nicht mehr. Die Anzahl der CE-Forenbeiträge pro Zeiteinheit wird auch immer dünner. Am schlimmsten ist aber der aus meiner Sicht katastrophale Zustand der OX-Repositories für Opensuse. Dafür scheint sich wirklich niemand mehr zu interessieren.

Grund 3: Ausrichtung auf soziale Medien und weiter zunehmende Kommerzialisierung
Mir passt die zum Programm erhobene Ausrichtung von OX ≥ V7 auf die sogenannten “sozialen” Medien nicht. Das hat aus meiner Sicht in einer Firmen-Groupware schon aus Sicherheitsgründen wenig bis gar nichts zu suchen. Nicht alles, was populär ist und dem Kommerz – speziell von SaaS-Anbietern – dient, ist auch gut.

Grund 4: Unübersichtliches Backend
Technisch wirkt auch das Java/OSGI-Backend-Konstrukt zunehmend zu komplex bis unübersichtlich, um damit weiter in einer nicht kommerziellen Server-Umgebung herumzudoktern. Ich verstehe, dass man hochgradig skalierbare Lösungen für den Einsatz in großen Unternehmen und speziell für SaaS benötigt. Aber irgendwie wirkt der Einsatz einer vollen Java-Architektur wie ein Overkill für die Ansprüche kleiner, mittelständischer Firmen an eine Groupware.

Grund 5: Einarbeitungszeit
Die Zeit, die man typischerweise in eine funktionierende Installation unter Opensuse 12.3 für die 7-er Version des Open-Xchange-Servers stecken muss, ist nach meinem Gefühl genauso groß wie die, sich in Alternativen einzuarbeiten.

Grund 6: Fehlende Replikationsmöglichkeiten
Meine erste eingesetzte Groupware war Lotus Notes 5/6 unter Linux. Ein Riesenvorteil von Lotus war die Server-Replikationsfähigkeit. Etwas Entsprechendes habe ich bei Open-Xchange immer vermisst.

Vor kurzem ist Opensuse 13.1 erschienen. Diese soll einen deutlich längeren Support erhalten als andere Opensuse-Versionen. Ein Umstieg auf eine neue opensource-basierte
Groupware-Lösung, die unter OS 13.1 funktioniert, erscheint mir daher als ein vernünftiger Schritt.

Was werde ich an OX vermissen ? Vielleicht Info-Store, vielleicht auch das gut organisierte Web-Interface …. aber bzgl. der Organization und Versionierung von wichtigen Dokumenten setzen wir seit ca. einem Jahr mit gutem Erfolg SVN und ein Wiki ein. Und als Groupware-Interface haben wir meist Kontact und nicht das Web-Interface benutzt ….. Und Ajax können auch andere Groupware-Hersteller ….

Vermissen werde ich vielleicht auch die kritischen Kommentare vom aktuellen OX CEO Rafael Laguna zur zunehmenden Kontrolle des Internets – durch staatliche Institutionen, aber nicht zuletzt auch durch und mit Hilfe der zugehörigen großen Monopol-Firmen des Internets ….. Wie schreibt er so schön:

“Before you blame the government for the filthy roads, clean your own yard! ”

Stimmt ! Aber warum sollte ausgerechnet eine Firma, die ihre Entwicklungskapazitäten zunehmend genau an den Vorgaben der kritisierten Giganten ausgerichtet hat und vor allem große und landesweit bis länderübergreifende SaaS-Partner umwirbt, besonders glaubwürdig dafür sein, die Rechte und Interessen der am meisten betroffenen normalen Nutzer und kleiner Firmen zu vertreten ?