Re: Professionelle Absage an Debian.
Hallo,
nun, bei jedem Upgrade sollte man schon nachschauen was so neu hinzugekommen
bzw. abgeändert wurde. Bei stretch z.B. wurden die ethX in enp2sX umbenannt
was dazu führt das einige Programme nicht mehr funktionieren. Wie willst du
aber mit Altlasten ohne Neuentwicklungen ein besseres System bekommen?
Was hat hat dich überhaupt dazu gebracht dein System Upzugraden? Wenn dein
System lauft und du keine neue Systemfeatures brauchst, lass es doch in ruhe.
Es gibt es genügend Techniken dazu wie Virtualisierung, Docker etc.
Wer macht schon heutzutage ein Upgrade im Produktion ohne es vorher auf einem
Testsystem ausprobiert zu haben?
Ich finde deine Meinung sehr subjektiv und unbegründet.
Gruss
Vlad
On Monday 23 November 2015 10:14:05 Bjoern Meier wrote:
> 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
Reply to: