Professionelle Absage an Debian.

23/11/2015 - 11:40 von Bjoern Meier | Report spam

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


<div dir="ltr">Hey,<div><br></div><div>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.</div><div><br></div><div>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. <br></div><div><br></div><div>Warum diese Entscheidung? Nun dazu möchte ich erst einmal formulieren wie Debian den Weg zu uns fand und wie sich das Ganze entwickelte. </div><div>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.</div><div>Dies fà¼hrte auch zu Diskussionen mit dem Vorstand, da ein restriktiveres System empfindlicher auf Störungen reagiert. Diskussionen alà  &quot;Warum machen wir das nicht auf Windows, da là¤uft das alles?&quot;. 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).</div><div><br></div><div>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.</div><div>Wir brauchten also eine bessere gepflegte Version von Samba. Sernet. Das Problem war also gelöst. </div><div><br></div><div>Auch das Samba das lokale Mapping mal vergisst haben wir gelöst in dem wir auf </div>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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Der letzte Tropfen:</div><div>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.</div><div>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.</div><div><br></div><div>Ich dachte mir: &quot;Ok, der File-Server ist jetzt à¼ber sehr, sehr lange Zeit &#39;historisch gewachsen&#39;. Legacy Problem!&quot;. 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.</div><div>Natà¼rlich weiàŸ ich, dass ich beim Mounten lieber die BLK-ID nehmen sollte anstatt die Deskriptoren. Aber: ich muss mir die Frage stellen:&quot;Ist ein System - welches auf solchen Deskriptoren basiert - zuverlà¤ssig, wenn diese Gewà¼rfelt werden?&quot; Nein ist es nicht. BTW: Das Problem hat man auch, wenn man dynamische MACs benutzt.<br></div><div>Der File-Server ist jetzt Windows 2012 R2.<br></div><div><br></div><div>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.</div><div>Wenn der Wartungsaufwand ein MaàŸ à¼bersteigt, nur um zuverlà¤ssig zu sein. Dann fà¤llt Debian raus.</div><div>Im àœbrigen wundert mich das. Ubuntu Server zeigt im Labor solche Sperenzien nicht.</div><div><br></div><div>TL;DR:</div><div>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.</div><div><br></div><div>Ich werde mindestens zwei Releases abwarten, ehe ich nochmal einen Versuch wagen werde. Es ist sonst einfach zu zeitaufwendig.</div><div><br></div><div>So long,</div><div>Björn</div></div>

 

Lesen sie die antworten

#1 Dirk Salva
23/11/2015 - 19:10 | Warnen spam
On Mon, Nov 23, 2015 at 10:14:05AM +0000, Bjoern Meier wrote:
leichter zu verwalten? Seien wir ehrlich: Linux war - auch im
administrativen Bereich - kein Vorbild an useability.



Das ist wohl Gewöhnungssache.


ciao, Dirk

Ähnliche fragen