Hey,
ich hätte nie gedacht, dass ich dies jemals schreiben werde. Heute ist kein guter Tag. Schweren Herzens habe ich mich dazu entschlossen, in der Firma in der ich tätig bin, Debian nicht mehr einzusetzen.
Eine Bitte vorweg: wenn Ihr Lösungen zu den Problemen habe, die ich schildern werde. Gut. Müsst ihr mir nicht schreiben, denn darum geht es nicht mehr.
Warum diese Entscheidung? Nun dazu möchte ich erst einmal formulieren wie Debian den Weg zu uns fand und wie sich das Ganze entwickelte.
Debian setze ich als erstes als File-Server mit Samba ein. Samba setzt SMB wesentlich restriktiver um als es Microsoft tut (z. B. ignoriert Microsoft, wenn ein Paket einen anderen Verschlüsseluingsalgorithmus benutzt als vereinbart - Kompabilitätsgründe) auch unterschiedliche Uhrzeiten (wichtig für die Kerberos-Verschlüsselung) werden oftmals sehr gnädig behandelt.
Dies führte auch zu Diskussionen mit dem Vorstand, da ein restriktiveres System empfindlicher auf Störungen reagiert. Diskussionen alà "Warum machen wir das nicht auf Windows, da läuft das alles?". Für mich war das immer kein Problem zu argumentieren. Ich hatte meine Belege für die Sicherheit, außerdem war Samba weitaus flexibler als damals Windows Server 2003 (z.B. weitaus flexiblere Scripte, wenn jemand ein share benutzt oder virtuelle PDF-Drucker die unter Windows sonst 1000€ / Jahr kosten).
Samba unter Debian war allerdings schon immer nervig. Dreimal in verschiedenen Versionen hatte ich einen Bug, der dazu führt, dass der secure channel zusammenbricht und keine User mehr enumeriert werden konnten.
Wir brauchten also eine bessere gepflegte Version von Samba. Sernet. Das Problem war also gelöst.
Auch das Samba das lokale Mapping mal vergisst haben wir gelöst in dem wir auf
RFC2307 setzten. Meine Kollegen monierten zwar ständig, dass man jetzt immer noch Unix-Attribute im Active Directory verwalten muss. Dafür gab es dann Template-Benutzer.
Dann war das Problem mit Systemd, was ich dadurch lösen konnte, in dem, ich unseren Custom-Kernel (den ich benötige, da der FS auf Hyper-V läuft und damals die Treiber nicht in dem Release von Debian drin waren) ablöste.
Ok, ab hier könnte man meinen, das wäre eher ein Problem EINES Paketes und nicht das von Debian. Das sehe ich leider anders. Samba ist nicht nur bloß ein Paket, sondern das Paket das beide Welten (Linux und Windows) als middleware vereint. Ist somit ein, ich nenne es mal: Enterprise-Paket. Im Sinne von: für Firmen vitale Software.
Ohne dieses Paket schrumpft der Einsatz von Linux im Unternehmen spürbar. Selbst ein Proxy mit Kerberos (bzw. NTLM)-Authentifizierung wird ohne Winbind deutlich schwieriger.
Der letzte Tropfen:
Seit dem letzten Kernel-Update viel mir auf, dass die Device-Deskriptoren für die - per VHD zur Verfügung gestellten - Festplatten nicht mehr stimmten. LVM sagte sogar es seien doppelte Einträge vorhanden. Als ich nachsah, fiel mir meine Kinnlade bis zum Erdkern. Unsere Daten-Festplatte hatte 6 (!) Deskriptoren unter /dev. Nach jeden Neustart änderten sich diese auch. Irgendwann war ich dann bei /dev/sdz angekommen.
Meine Vermutung (mehr konnte ich bis Dato nicht heraus finden)? Unter /sys im VMbus (also der Treiber für Hyper-V) werden pro Host (wir haben Failover-cluster) verschiedene Dateien für die Festplatten angelegt. z.B. /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:00/vmbus_0_1/host2 Wie gesagt: Nur eine Vermutung. Beim Starten hakt dann auch wieder Systemd, weil es die Laufwerke nicht findet.
Ich dachte mir: "Ok, der File-Server ist jetzt über sehr, sehr lange Zeit 'historisch gewachsen'. Legacy Problem!". Kein Problem. Server ins Lab kopiert. System-Platte gelöscht. Installer gestartet und: ich sehe genau die selben Duplikate wie auch vorher. Also: SDB1 ist auch SDD1, SDF1 und so weiter. Da hatte ich keine Lust mehr. Ich wusste, dass ist nicht das Problem unseres File-Servers.
Natürlich weiß ich, dass ich beim Mounten lieber die BLK-ID nehmen sollte anstatt die Deskriptoren. Aber: ich muss mir die Frage stellen:"Ist ein System - welches auf solchen Deskriptoren basiert - zuverlässig, wenn diese Gewürfelt werden?" Nein ist es nicht. BTW: Das Problem hat man auch, wenn man dynamische MACs benutzt.
Der File-Server ist jetzt Windows 2012 R2.
Der eigentliche Grund für diese Entscheidung ist nicht, daass irgendetwas nicht funktioniert. So etwas hat man bei jedem System. Sondern, dass sich Debian den Vorteil von Linux mit Entscheidungen kaputt macht. Nämlich den Vorteil systemnah und damit stabil und zuverlässig zu sein. Systemd ist so eine Entscheidung, die alles andere als systemnah und stabil ist.
Wenn der Wartungsaufwand ein Maß übersteigt, nur um zuverlässig zu sein. Dann fällt Debian raus.
Im Übrigen wundert mich das. Ubuntu Server zeigt im Labor solche Sperenzien nicht.
TL;DR:
Debian fliegt ersteinmal raus Aufgrund von Entscheidungen, die das System - für uns - nicht mehr einschätzen lassen. Wenn dann auch noch Linux so umgestaltet wird, dass die Vorteile nicht mehr existieren (Systemd ist komischerweise sehr nah an den Windows Services), dann gibt es keinen Grund mehr für Linux. Denn dann stellt sich nur noch die Frage: was ist im Alltag leichter zu verwalten? Seien wir ehrlich: Linux war - auch im administrativen Bereich - kein Vorbild an useability. Außerdem ist Windows durch winrm und powershell erheblich komfortabler geworden.
Ich werde mindestens zwei Releases abwarten, ehe ich nochmal einen Versuch wagen werde. Es ist sonst einfach zu zeitaufwendig.
So long,
Björn