Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – I

In diesem und den folgenden Beiträgen möchte ich die Installation eines Cyrus IMAP-Dienstes beschreiben, der unter Opensuse zum Laufen gebracht werden soll und dessen Anwender über ein LDAP-System authentifiziert werden. Themen der Artikel werden sein :

  1. Einfache Varianten der benötigten Konfigurationsdateien unter Berücksichtigung von SASL (genauer “saslauthd“) und STARTTLS.
  2. Eine bestimmte Authentifizierungsvariante über SASLAUTHD, PAM, SSSD, LDAP. Diese ist aus meiner Sicht in einem kleinen internen Netzwerk durchaus ausreichend.
  3. Test der Funktionstüchtigkeit des Authentifizierungsverfahrens.
  4. Starten des Servers und Einrichten einer Test-Mailbox.
  5. Prüfen der Funktionstüchtigkeit des IMAP-Servers per “telnet” und “imtest”.
  6. Anbindung Kmail.
  7. Webmin zur Mailbox-Verwaltung.

Einschränkung
Ich gehe in diesem Beitrag ausschließlich auf die Installation des IMAP-Dienstes auf einem Linux-Host ein. Dem Zusammenspiel mit dem MTA Postfix widme ich dagegen eine andere Artikelserie. Will man einen kompletten E-Mail-Server mit Fetchmail, Postfix, Cyrus IMAP aufbauen, lohnt es sich aus meiner Sicht aber, das Pferd von hinten aufzuzäumen:

Für Tests der gesamten Verarbeitungskette muss man letztlich in der Lage sein, E-Mails entgegen zu nehmen und abzulegen. Dafür ist ein bereits laufender IMAP-Server das richtige. Der Zugriff eines Mailclients wie Kmail auf den IMAP-Dienst ist schnell umgesetzt. Im übrigen lohnt sich der Einsatz einer “Stand Alone”-IMAP-Instanz auch für die Aufnahme von Mail aus einem Backup. Siehe hierzu den Artikel:
https://linux-blog.anracom.com/2011/11/28/cyrus-imap-auf-die-schnelle/

Getestet habe ich die gesamte Vorgehensweise auf einem System unter Opensuse 12.3. Ich gehe aber davon aus, dass die Konfiguration auch unter Opensuse 13.1 laufen würde.

Voraussetzungen: Hostkonfiguration mit SASL, PAM, SSSD und LDAP-Zugriff

Da LDAP ins Spiel kommen soll, muss der Host, auf dem der Cyrus IMAP-Dienst implementiert werden soll, eine Reihe von Voraussetzungen erfüllen. Ferner muss im Netzwerk natürlich ein LDAP-System vorhanden sein, auf den unser IMAP-Host zugreifen kann und darf. Ich kann weder die Einrichtung eines LDAP-Systems an dieser Stelle besprechen, noch die Bereitstellung aller oder spezieller Zugriffsvarianten von bestimmten Serverdiensten auf ein LDAP-System. Ich betrachte weiter unten vielmehr eine einfache, etwas spezielle Variante des LDAP-Zugriffs. Dabei werde ich bestimmte Dinge voraussetzen, die ich bereits früher in anderen Artikeln behandelt habe:

Cyrus IMAP kann (wie manche andere Dienste auch) auf das Authentifizierungs-Framework Cyrus SASL zurückgreifen. SASL wiederum kann eine ganze Reihe unterschiedlicher Backends einsetzen. In einem der letzten Beiträge in diesem Blog hatte ich bereits dargestellt, wie man eine Kette aus

SASLAUTHD => PAM => SSSD => LDAP

nutzen kann, um damit eine Authentifizierung vorzunehmen. Siehe hierzu den Blog-Artikel:
SASL mit PAM, SSSD, LDAP unter Opensuse

Die Ausführungen des genannten Beitrags werden hier vorausgesetzt. D.h., ich gehe davon aus,

  • dass es einen LDAP-Server im Netz gibt, der Standard-Information zu Usern beherbergt, die einen IMAP-Zugang erhalten sollen,
  • dass die Userinformationen
    auf dem LDAP-Server in einem von SuSE’s YaST eingerichteten Zweig des LDAP-Baums angelegt wurden,
  • dass SASL, PAM und SSSD wie im obigen Artikel besprochen auf unserem Host “mycyrus” eingerichtet sind,
  • dass Server-SSL-Zertifikate sowohl auf dem IMAP-Host wie auch auf dem LDAP-Host eingerichtet wurden und zwar jeweils nach dem Muster des SuSE “Common Server Certificates”.

Wie man unter Opensuse zu einem LDAP-Server gelangt und die Server-Zertifikate von einem CA-System auf die Server bringt, habe ich in früheren Artikeln beschrieben.
Opensuse 12.1 – LDAP I // Opensuse 12.1 – LDAP II // Opensuse 12.1 – LDAP III // Opensuse 12.1 – LDAP IV // Opensuse 12.1 – LDAP V

Host-, Server- und Testuser-Bezeichnungen in den Artikeln dieser Serie

Der Host, der den IMAP-Server beherbergen soll, heiße nachfolgend “mycyrus“. Der LDAP-Server heiße dagegen “ldap-serv“.
Auf dem LDAP-System sei ferner ein Eintrag für eine Test-Userin “tarja” angelegt worden (Password: TARJAPWD).

Benötigte CYRUS IMAP Pakete

Unter Opensuse installiert man sich per YaST oder Yum folgende Pakete aus den Standard- und Update-Repositories für sein Opensuse-System:

cyrus-imapd, cyrus-sasl, cyrus-sasl-plain, cyrus-sasl-saslauthd, perl-Cyrus-IMAP, perl-Cyrus-SIEVE-managesieve,
perl-Authen-SASL-Cyrus, perl-Authen-SASL

CYRUS IMAP Konfigurationsdateien

Meine Cyrus Konfigurationsdateien sehen wie folgt aus:

/etc/cyrus.conf:

# standard standalone server implementation
 
START {
# do not delete this entry!
recover cmd=”ctl_cyrusdb -r”
 
# this is only necessary if using idled for IMAP IDLE
idled cmd=”idled”
}
 
# UNIX sockets start with a slash and are put into /var/lib/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=”imapd” listen=”imap” prefork=0
imaps cmd=”imapd -s” listen=”imaps” prefork=0
pop3 cmd=”pop3d” listen=”pop3″ prefork=0
pop3s cmd=”pop3d -s” listen=”pop3s” prefork=0
sieve cmd=”timsieved” listen=”sieve” prefork=0
 
# at least one LMTP is required for delivery
# lmtp cmd=”lmtpd” listen=”lmtp” prefork=0
lmtpunix    cmd=”lmtpd” listen=”/var/lib/imap/socket/lmtp” prefork=0
 
# this is only necessary if using notifications
# notify cmd=”notifyd” listen=”/var/lib/imap/socket/notify” proto=”udp” prefork=1
}
 
EVENTS {
# this is required
checkpoint cmd=”ctl_cyrusdb -c” period=30
 
# this is only necessary if using duplicate delivery suppression
delprune cmd=”cyr_expire -E 3″ at=0400
 
# this is only necessary if caching TLS sessions
tlsprune cmd=”tls_prune” at=0400
 
# Uncomment the next entry, if you want to automatically remove
# old messages of EVERY user.
# This example calls ipurge every 60 minutes and ipurge will delete
# ALL
messages older then 30 days.
# enter ‘man 8 ipurge’ for more details
 
# cleanup cmd=”ipurge -d 30 -f” period=60
}

Details zu den Parametern findet man etwa hier: http://linux.die.net/man/5/cyrus.conf.
Diese Datei ist nach der Installation unter Opensuse fast schon genau so vorhanden wie oben dargestellt. Geändert habe ich, dass die Bereitstellung der IMAP und POP-Dienste auch auf verschlüsselten Ports (imaps: 993, pop3s: 995) erfolgen soll.

Wichtig ist die Vorbereitung der LMTP-Socket-Kommunikation innerhalb des Blockes SERVICES {} dann, wenn man später Postfix als MTA einsetzt will: Postfix kann seine Mails lokal auf demselben System (Socket !) per LMTP-Protokoll an den Cyrus-IMAP -Server und dessen Mailboxen übergeben. Beachte: Die LMTP-Socket-Bereitstellung wird durch die gestartete Cyrus IMAP-Instanz selbst vorgenommen. Es ist keine zusätzliche Paketinstallation erforderlich. (In der Postfix-Konfiguration muss dann allerdings auch genau auf den hier angegebenen Socket Bezug genommen werden.)

Wichtig für die Authentifizierung im Rahmen eines User-Zugriffs auf den IMAP-Dienst ist folgende Konfigurationsdatei für den IMAP-Dämon:


/etc/imapd.conf:

# Configuration
# ************
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
sievedir: /var/lib/sieve
 
servername: mycyrus
admins: cyrus
 
reject8bit: no
poptimeout: 10
timeout: 30
 
# DRAC
# ******
drachost: localhost
dracinterval: 0
 
# Quota und Autocreate
# ******************
quotawarn: 90
autocreatequota: 5242880
autocreateinboxfolders: Drafts|Sent|Trash|Junk|Spam
autosubscribeinboxfolders: Drafts|Sent|Trash|Junk|Spam
 
# LMTP
# ****
lmtp_overquota_perm_failure: no
lmtp_downcase_rcpt: yes
 
# SASL
# ****
allowplaintext: yes
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN LOGIN
 
# TLS (STARTTLS)
# *************
tls_key_file: /etc/ssl/servercerts/serverkey.pem
tls_cert_file: /etc/ssl/servercerts/servercert.pem
tls_ca_file: /etc/ssl/certs/YaST-CA.pem

Genauere Informationen zu den einzelnen Parametern findet man unter den man-Seiten:
http://linux.die.net/man/5/imapd.conf.
Oder hier: http://www.postfix-howto.de/v1/cyrus_conf.html
Ich gehe kurz auf einige der wichtigeren Einträge ein:

Drac deaktivieren
DRAC realisiert “pop/imap before smtp” unter Cyrus IMAP. Das wird hier nicht benötigt und durch “dracinterval: 0” deaktiviert.

Nutzung von SASL für die Authentifizierung
Cyrus IMAP nutzt das SASL-Framework zur Authentifizierung allein aufgrund der 3 Zeilen unter meiner Kommentarzeile “# SASL”. Dabei werden eingehende Klartext-Passwörter zugelassen.
Dass der “saslauthd”-Dämon PAM nutzen soll, wird durch saslauthd’s eigene Startup-Dateien auf dem Host geregelt. Beschrieben habe ich das in meinem oben zitierten Blog-Beitrag SASL mit PAM, SSSD, LDAP unter Opensuse . Dort findet man auch,

  • wie man PAM zur Nutzung von SSSD einstellen muss und
  • wie man SSSD konfigurieren muss, damit ein LDAP-Server als Auth-Backend über eine TLS-gesicherte Verbindung genutzt werden kann.

Bereitstellung von STARTTLS für den sicheren Zugang zum IMAP-Dienst
Um das potentielle Sicherheitsloch mit den Klartext-Passwörtern zu kompensieren, soll der Cyrus-Server TLS-Verschlüsselung für Clients anbieten (STARTTLS). Dies
geschieht über die Einträge unterhalb meiner “# TLS”-Kommentarzeile.

Wie gesagt: Die host-spezifischen TLS/SSL-Schlüssel-Dateien sind von einer zentralen YaST-CA erstellt worden. Die zugehörigen Dateien wurden exportiert und auf “mycyrus” als “Common Server Certificate” importiert. Dann landen die Schlüssel-Dateien mit den angegebenen Standard-Namen und passenden Rechten in den angegebenen Verzeichnissen.

Wichtig ist, die Datei “YaST-CA.pem” der eigenen CA für SSL/TLS gesicherte Verbindungen auch auf allen späteren IMAP-Clients im eigenen Netzwerk bereitzustellen – und dort unter dem jeweiligen Verzeichnis “/etc/ssl/certs” (Opensuse-spezifisches Standard-Verzeichnis). Diese Datei wird später auf den Clients für die Prüfung der Vertrauenswürdigkeit des Zertifikats benötigt. (Natürlich kann es sein, dass die öffentliche Zertifikatsdatei für die eigene oder eine externe CA einen anderen Dateinamen als YaST-CA.pem aufweist. Unter anderen Linux-Distributionen ist ggf. auch ein anderer Pfad zu wählen, an den dann die Einstellungen in der imapd.conf anzupassen sind.)

Modifizierte Anzeige des Posteingangs
Die Mailverzeichnisse des Cyrus IMAP-Servers sind hierarchisch aufgebaut. Unter “/var/spool/imap/user” werden wir später für unsere Testuserin “tarja” explizit Mail-Verzeichnisse anlegen. Das Verzeichnis für den Posteingang ist dabei im Filesystem identisch mit “/var/spool/imap/user/tarja”. IMAP-intern wird die Mailbox unter “user.tarja” verwaltet. Unter diesem Knoten werden dann typische weitere Subverzeichnisse für “Drafts”, “Spam”, “Sent” etc. angelegt. Mail Clients wie Kmail zeigen diese Hierarchie an Mailfoldern auch genauso an. Mich stört dabei regelmäßig die übergeordnete Rolle des Posteingangs. Um das (spezielle) Posteingangsverzeichnis auf der gleichen Ebene wie die eigentlich untergeordneten Ordner anzeigen zu lassen, nutzt man die Option

altnamespace: yes

Quota und Autocreate-Optionen
Der aufmerksame Leser mag sich über die automatische Quota-Zuteilung von 5GB an neue User wundern. (Der numerische Wert von “autocreatequota” bezieht sich auf die Einheit KB). Würde er die User kennen, die sich auf meinem System tummeln werden, würde er sich nicht mehr wundern. Aber hier muss jeder selber wissen, was er sich und seinen Usern zugestehen will.
Zu den Autocreate-Optionen für die automatische Anlage neuer Verzeichnisse bei Posteingang für User, für die bislang noch keine Mailbox angelegt wurde, und zu den erforderlichen Voraussetzungen für die automatische Anlage muss ich auf die Literatur verweisen.

Ein paar Checks und Vorbereiten des “cyrus”-Users

Wir prüfen vorab, dass folgende Services ordnungsgemäß gestartet sind und fehlerfrei laufen:

  • systemctl status saslauthd.service
  • systemctl status sssd.service

Beide Services sollten für den automatischen Start durch systemd auf dem IMAP-Server bereits “enabled” sein oder spätestens jetzt werden.

Ferner testen wir, wie im früheren Beitrag beschrieben, dass “saslauthd” im Kern funktioniert.

mycyrus:/etc/init.d # testsaslauthd -u tarja -p TARJAPWD
0: OK “Success.”
mycyrus:/etc/init.d #

Ferner prüfen wir, ob ein Login auf dem System “mycyrus” für “tarja” möglich ist – z.B. über ssh von einem Remote-System; SSH muss dafür auf “mycyrus” aktiviert sein. Der Login ist möglich, wenn man auf “mycyrus” alles so eingerichtet hat, wie ich das im oben zitierten Artikel SASL mit PAM, SSSD, LDAP unter Opensuse vorgegeben hatte:

user@tux:~> ssh -X tarja@mycyrus
Password:
Last login: Wed Mar 12 18:21:16 2014 from tux.anraconx.de
nHave a lot of fun…
tarja@mycyrus:~>

Passwort und TLS-Gruppe für den User “cyrus” setzen
Der User “cyrus” wurde zwar bei der IMAP-Installation automatisch als Mitglied der Gruppe “mail” angelegt. Aber wir sollten nun sein Passwort mit einem Tool unserer Wahl (z.B. YaST oder usermod) setzen. Der Platzhalter für das “cyrus”-Passwort ist nachfolgend CYRUSPWD.

Zudem: Sowohl dieser User “cyrus” als später auch der User “postfix” benötigen für TLS den lesenden Zugang zum privaten SSL-Key. Ich will diese User aber natürlich nicht der root-Gruppe zuordnen. Mein Lösungsansatz ist, eine Gruppe “tls” einzurichten, der auf dem IMAP-Server nur die User “cyrus” und “postfix” angehören. Ich setze dann die Rechte wie folgenden Zeilen entnehmbar:

mycyrus:/etc/ssl/servercerts # ls -l
total 8
-rw-r–r– 1 root root 1809 Jan 18 15:03 servercert.pem
-rw-r—– 1 root tls 1704 Jan 18 15:03 serverkey.pem

Damit genug für den ersten Artikel dieser Serie. Was haben wir bis jetzt erreicht? Wir haben bislang nur Konfigurationsdateien vorbereitet und gecheckt, dass für eine Testuserin eine saslauthd-basierte Authentifizierung über einen LDAP-Server funktioniert. Leider kann sich unsere Testuserin auf dem geplanten IMAP-Server-Host auch einloggen. Wollen wir das? Klare Antwort: Nein ! Im nächsten Beitrag
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – II
müssen wir daher die Grundeinstellungen des Authentifizierungsverfahrens zuerst noch etwas modifizieren.

Samba-Problem unter Opensuse 13.1

Nachdem ich auf einer weiteren Maschine, die ich auf OS 13.1 upgegradet habe, erneut ein Problem mit Samba erhalten habe, folgende Hinweise:

Befund: “systemd” versucht, SMB zu starten, scheitert aber. SMB läuft nicht. “systemctl status smb.service” zeigt Fehler an.

Ursache:Ein Problem mit SuSE’s Apparmor-Profilen. (Mal wieder … )

Lösung 1:
Drastisch und nicht auf Dauer zu empfehlen:
Deaktivieren von AppArmor über “YaST2 => AppArmor-Konfiguration”.
Dort im nächsten YaST2-Dialog: Zeile “Einstellungen” ist markiert => Button “Starten” => Haken bei der Checkbox “AppArmor aktivieren” entfernen => Button “Fertig”.
Danach “systemctl restart smb.service”.

Lösung 2:
ZwischenzeitlicheLösung, wenn es schnell gehen muss:
Umsetzen des smbd-Profilmodus über “YaST2 => AppArmor-Konfiguration”.
Dort im Dialog-Fenster “Einstellungen” => Button “Starten” => “Profilmodi festlegen” => Button “Konfigurieren” => die Zeile mit “usr.sbin.smbd” markieren => Button “Modus umschalten”. Der Modus wird dann auf “complain” gesetzt. Abschließen mit Buton “Fertig”.
Danach “systemctl restart smb.service”.

Lösung 3:
Zu empfehlende dauerhafte Lösung:
Fehlerbeseitigung durch Laden neuer upgedateter Profile von SuSE.
Über “Yast2 => Software installieren und löschen” das Paket “apparmor-profiles” deinstallieren. Deinstallation komplett durchführen!
Danach das aktuelle Update des Paketes “apparmor-profiles” Version “2.8.2-4.13.1-noarch” reinstallieren.
Danach “systemctl restart smb.service”. SMB sollte jetzt starten. Die Meldung “0] ../source3/smbd/server.c:1278(main)”, die unter “systemctl status smb.service” erscheint, ignorieren.
Dann SMB-Freigabe-Verzeichnisse mit dem Tool seiner Wahl wie gewohnt definieren.
Danach Zugriffe von allen anderen Systemen, die die Samba-Freigaben nutzen müssen, ausführen. In meinem Fall von verschiedenen anderen Opensuse-Systemen und von VMware Win 7 Installationen.
Im Anschluss als root das Kommando “logprof” ausführen und wo sinnvoll die offenen Punkte mit “(A) Allow” beantworten. Am Schluss des Dialogs “(S)ave Changes”.
Dann “systemctl restart apparmor.service” und “systemctl restart smb.service”.

Danach sollte SMB auch bei aktiviertem AppArmor wieder anstandslos laufen und von “systemd” auch bei einem Systemneustart ohne Fehler hochgefahren werden.

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 ….

KVM – Problem nach Upgrade Opensuse 12.3 auf 13.1

Habe vor ein paar Tagen einen KVM-Host von Opensuse 12.3 auf Opensuse 13.1 upgegradet. Wie immer habe ich gleich auch noch ein Update aller relevanten System-RPMs auf den aktuellen Stand gemäß Opensuses Standard-Repositories vorgenommen. Danach gingen KVM, virt-manager und Konsorten nicht mehr. Fehler über Fehler …. im besonderen endet der Start von virt-manager mit Fehlern. Auch der testweise Versuch, neue virtuelle Maschinen anzulegen, endet mit Fehlermeldungen. “systemd” zeigt nach dem Start des Service “libvirtd” Fehler der Art

libvirtError: unknown OS type hvm

an.

Ich habe dann die kvm-Pakete, libvirt-Pakete etc. deinstalliert und die erneute Installation über die YaST2-Module “Install Hypervisor and Tools” vornehmen lassen. Erneut ergab sich ein negatives Resultat. Offenbar testet z.Z. bei SuSE niemand die KVM-Funktionsfähigkeit unter OS 13.1!

Als nächstes habe ich dann versucht, die von YaST2 installierten Pakete über das Repository
http://download.opensuse.org/repositories/Virtualization/openSUSE_13.1/
upzudaten. Erneut ein Fehlschlag!

Bevor man nun in Verzweiflung gerät:

Nach einigem Probieren habe ich eine Variante gefunden, die aktuell funktioniert. Der Clue ist, dass man statt des Paketes “kvm” besser “qemu-kvm” installieren sollte. Dann läuft alles wieder wie geschmiert. Man kann sich dann auch mit dem aktuellen Layout von “virt-manager” anfreunden. Die Liste der von mir installierte Pakete aus dem oben genannten Repository sieht aktuell wie folgt aus:

kvm

Man beachte, wie gesagt, dass das Paket “kvm”, das Opensuse standardmäßig vorsieht, durch “qemeu-kvm” ersetzt ist.

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 !