PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Server-Linux: Langzeitunterstützung? Welchen?



kernel
18.04.14, 15:16
Hi Leute,

stehe davor, mir zuhause einen Mini-Server zu basteln, der hauptsächlich LAMP machen soll, aber auch XMPP-Server, CalDAV-Server, ggf. VPN, verschiedene Webfrontends (Webmail, Webcalendar, Bookmarksync, Fotogallerie, ...) + ein paar selbstgestrickte Sachen und eventuell noch anderes Zeug.

Tendenziell tendiere ich zu Debian-basierten Distris, bin da aber nicht zwangsläufig festgelegt.

Nun bin ich daran interessiert, dass der möglichst lange läuft, ohne dass ich ein Major Upgrade machen muss. Gemeint ist damit, dass ich nicht jedes halbe Jahr / Jahr ein Upgrade auf die nächste Version durchziehen muss, nur um dann zu hoffen, dass hinterher noch alles funktioniert. Rolling-Release-Dinger kamen irgendwie dadurch nicht in Frage. So dachte ich bisher jedenfalls.

Also richtete ich mein Augenmerk eher auf stabilere Distris, bzw. welche mit Langzeitunterstützung. Z.B. Ubuntu LTS, CentOS, Debian, ...
Nun bekam ich aber mit, dass viele davon gar nicht so lang ausgelegt sind. Debian ist meistens 1 Jahr nach nächster Version noch mit Updates dabei, macht also ca. 3 Jahre insgesamt pro Version. CentOS ist wohl so mit 4-5 Jahren dabei, Ubuntu mit 5, ... und dann kommt irgendwie nichts. OpenSuSE mit dem Evergreen sporadisch, sonst nur 18 Monate. Andere Distris teilweise nur 1 Jahr oder halt bis zur nächsten Version oder oder oder... halt kurz. Es kann ja nun aber nicht sein, dass ich nur die Wahl zwischen Ubuntu und CentOS habe, wenn der Zeitraum lang sein soll, oder?

Da ich keinen Supportvertrag brauche (RHEL, SLES, ...) habe ich da angefangen mich zu fragen, wie Firmen das denn so machen, die sich selbst supporten. Von einigen habe ich mitbekommen, dass sie Ubuntu einsetzen, CentOS, Debian... aber auch sowas wie Mageia, OpenSuSE ohne Evergreen, etc.

Ergo: Das muss dann ja auch irgendwie OHNE Langzeitsupport gehen...?! WIE machen die das? Wie kann ich beispielsweise Mageia auf dem Server einsetzen ohne dass ich mit den kurzen Zyklen Probleme bekomme?

Kann mir das einer erklären? Upgraden die Leute jedes halbe Jahr / Jahr und hoffen dann, dass alles läuft und fangen im Notfall an zu reparieren? Oder basteln die sich einfach einen neuen Server und ziehen dann alles rüber und wechseln damit das Produktivsystem erst ab, wenn das neue wirklich gut läuft?

Ich wäre sehr dankbar, wenn mir da jemand die Erleuchtung bringen kann. Ich habe da echt mal Klärungsbedarf.

ThorstenHirsch
18.04.14, 15:42
Doch. Die wenigsten Distris haben die Kapazitäten, ältere Versionen lange zu unterstützen. Debian mit 2 bzw. 3 Jahren reicht den meisten. Und die Firmen, die 5 Jahre haben wollen, kaufen meist RHEL (RedHat) oder SLES (Suse/Novell).

Mehr als 5 Jahre gibt's nicht. Die Firmen supporten sich da auch nicht selbst - welche Firma soll sich das denn erlauben können? Höchstens ein Dutzend weltweit. Alle anderen machen das einzig vernünftige: upgraden.

atomical
18.04.14, 17:57
scheinbar doch - und die 5 Jahre gehen gerade wieder von vorne los ...

http://www.heise.de/newsticker/meldung/Ubuntu-14-04-LTS-Linux-mit-fuenf-Jahren-Update-Garantie-2173149.html

marce
18.04.14, 18:10
CentOS6 wird bis 2020 supportet - aktuell liegt CentOS / RHEL bei AFAIK 10 Jahre pro Release. Das sollte reichen - vorher stirbt meist die Hardware drunter und in dem Zuge kann man dann meist eh problemlos auf das nächste Release wechseln.

Solange Du Dich nur an die Distributionseigenen Paketquellen hältst kannst Du auch gut mit Debian leben - das Upgrade auf das nächste Release geht solange nicht am System herumgebastelt wurde eigentlich problemlos.

Wenn man weiß was man tut kommt man auch mit Systemen wie Gentoo und Arch problemlos über die Runden. Der Aufwand ist ein wenig höher, aber grundlegend spricht - für den Einsatz im Privatbereich eigentlich auch nichts dagegen.

kernel
18.04.14, 18:47
Die Firmen supporten sich da auch nicht selbst

Vielleicht gibt es da ein Missverständnis:
Was ich meinte waren Firmen, die selber ihre Server installieren und warten, etc. Ich hatte das immer so verstanden, dass man bei RHEL auf Red Hat-Techniker für sowas zurückgreift. Aufsetzen, migrieren, Problemlösung am Server direkt, ... Vielleicht habe ich das aber auch falsch verstanden und man muss das alles immer noch selbst machen, aber man hat Zugriff auf Phone- und Mail-Support und das war's.

Was davon ist es?

ThorstenHirsch
18.04.14, 19:14
Wenn du RHEL oder SLES kaufst, musst du immer noch die Server selber installieren. Du erwirbst nur den Support zu den Systemen, damit dir bzw. deinem Admin bei Problemen geholfen wird. Aber du erhältst keinen Admin dazu.

edit: ...wobei du heute "in der Cloud" auch weiterführende Angebote bekommst, PaaS, IaaS, SaaS und was es alles gibt. Red Hat hat da bestimmt auch was im Angebot.

kernel
18.04.14, 19:21
CentOS6 wird bis 2020 supportet
Stimmt, ich hab's gerade nochmal angeschaut. Sehr gut.


Solange Du Dich nur an die Distributionseigenen Paketquellen hältst [...]
Ich habe nicht vor, Fremdquellen hinzuzufügen, es sei denn, etwas ist partout nicht erhältlich, z.B. Openfire.

Also, wenn ich das richtig verstehe, dann gibt es - erfahrungsgemäß? - bei einem reinen Server, also headless, keine grafische Ausgabe, etc. i.d.R. keine Probleme, wenn man die Quellen von dem entsprechenden Projekt verwendet, keinen eigenen Kernel kompiliert, etc.? Was genau ist mit "herumgebastelt" gemeint?

Zu Debian habe ich noch was in der Wikipedia gefunden:

Erstmals wird es für Version Squeeze einen Long-Term-Support geben, der für die Architekturen i386 und amd64 noch bis Februar 2016 Sicherheitsupdates bereitstellen wird, wenn der normale Support am 31. May 2014 beendet sein wird.
Das Ding kam 2011 raus, also dürften das dann jetzt auch 5 Jahre sein.

kernel
18.04.14, 19:32
Eine Frage zur Konfiguration hätte ich noch, wenn das in diesem Thread ok ist...

Ich kenn mich -autodidaktisch- mit Linux bisher soweit aus, dass ich bisher immer klarkam. Das war aber auf dem Desktop und auf dem Server war es ein wenig Bash-Programmierung und rudimentäres Arbeiten mit den GNU-Tools, mal eine Konfig hier angepasst, mal eine andere da, ...

Vor diesem Hintergrund ist sowas wie YAST von SuSE ja ganz nett, weil es einem einen Haufen Konfigurationsarbeit abnimmt. Andere Distris haben ja auch noch andere Konfigtools. Ubuntu hilft bei der Installation mit vordefinierten Paketen (z.B. LAMP), Debian inzwischen auch, OpenSuSE hat halt yast, Mageia die draktools, ...

Aus eurer Erfahrung heraus: Welches dieser Tools (oder anderer, z.B. Web frontends wie Webmin, etc.), und damit auch zum Teil Wahl der Distribution, ist zur Administrierung eines Servers mit den oben angegebenen Einsatzgebieten gut geeignet, auch in Hinsicht von Erleichterungen bei der Konfiguration? Webinterfaces wären insgesamt auch eine nette Sache. Wie gesagt, auf der Bash bin ich auch unterwegs; eine Idee hinter dem Heimserver-Projekt ist auch, dass ich mich Stück für Stück dem Administrieren auf der Kommandozeile nähern kann. Nur halt nicht alles gleich von Anfang an. OpenFire bringt sein eigenes Konfig-Tool per Webfrontend mit.

Was könnt ihr empfehlen? Danke schonmal!

marce
18.04.14, 19:40
empfehlen? SSH.

Grafische Tools sind - nett. Wenn es aber um's lernen geht führt nichts an der direkten Arbeit an den Konfigurationdateien vorbei - alles weitere bringt meist alles mögliche, nur nicht den Lernerfolg.

Zudem ist das, was Du mit dem Ding vorhast ja "keine Rocket-Science" sondern eher Standard - und dafür braucht man meist nicht sooo viel an Tools (Du hast ja nicht vor, jeden Tag 200 Mail-Accounts und 150 Web-Spaces zu erstellen - sondern die Kiste wird 2x aufgesetzt und läuft dann). Auch bietet jedes Admin-Tool die Chance, nach einem Update ggf. mit der neuen Version nicht klarzukommen oder die Sonderwünsche, die man ggf. doch mal hat nicht abbilden zu können.

... zudem gibt es noch viele weitere Argumente gegen Admin-Tools, für den Anfang belasse ich es aber mal damit...

Ach ja - das gilt nicht für Appliances mit eingeschränktem Funktionsumfang - da kann man sowas gerne nehmen (ist ja meist auch direkt dabei, s. z.B. FreeNAS oder QNAP) - aber da ist man mit seinem Funktionsumfang eben auch auf das beschränkt, was das Ding von sich aus bietet.



keinen eigenen Kernel kompiliert, etc.? Was genau ist mit "herumgebastelt" gemeint?
eben genau sowas - zusätzliche Paketquellen, die einem dann nicht auflösbare Abhängigkeiten im Rahmen des Updates reinbringen, am System Teile austauschen, vorgebene Pfade und Konfigurations"methoden" / -strategien abändern - halt all das, was einem so einfällt.

Wenn Du das unterlässt kannst Du Probleme beim Upgrade eigentlich nur dann bekommen, wenn sich z.B. in einer Version einer Anwendung grundlegend was geändert hat - z.B. bei PostGreSQL, wenn sich das "mitgebundlelte" PostGIS ändert und damit nicht mehr Kompatibel ist - das sind meist aber Einzel- und Sonderfälle.

kernel
18.04.14, 20:06
Hallo Marce, danke für den Input.

Via SSH "Linux lernen" ist halt nur ein Teil der Geschichte. Da mache ich auch auf meinem NAS ab und zu ein paar Dinge. Es geht mir halt auch drum, dass die Kiste läuft und ihren Dienst tut und ich nicht zuviel aus Versehen kaputt machen kann.

Eine Frage noch zum Thema Fremdquellen:


zusätzliche Paketquellen, die einem dann nicht auflösbare Abhängigkeiten im Rahmen des Updates reinbringen, am System Teile austauschen, vorgebene Pfade und Konfigurations"methoden" / -strategien abändern - halt all das, was einem so einfällt.

Beispiel Openfire: Muss ich als DEB oder RPM runterladen und installieren. Es möchte Java installiert haben. Habe ich auch schonmal gemacht. Wäre die einzige Abhängigkeit und soweit ich das gesehen habe, ändert die Software auch nix Gravierendes am System. Ein von dir geschildertes Problem könnte dann doch eigentlich "nur" auftauchen, wenn sich bei einem Upgrade die Java-Version ändert und ich das Paket vom Openfire nicht aktualisiere, oder?

Der Rest der geplanten Software müsste soweit mit Apache, MySQL und PHP klarkommen, bzw. in den Paketquellen sein.

@all: Hier (http://www.knetfeder.de/linux/index.php?id=161http://) gibt es übrigens eine Gegenüberstellung zur Langzeitunterstützung von Ende Januar 2014, die mir gerade unterkam. Wenn es jemanden interessiert.

ThorstenHirsch
18.04.14, 20:16
Vielen Dank für den Link, kernel. Dass CentOS 10 Jahre lang Support hat, habe ich auch erst hier in diesem Thread erfahren. Ich hab' mal noch nach den alten Unixen geschaut...

- AIX: die neuen 6er und 7er Versionen haben noch kein Ende angegeben, bei der 5er sind's zwischen 5 und 8 Jahren (http://www-01.ibm.com/software/support/aix/lifecycle/index.html)
- Solaris, das ist der Spitzenreiter: 16 Jahre für Solaris 10; bei Solaris 11 ist Oracle etwas runter gegangen auf 14 Jahre (siehe Wikipedia)

Schade nur, dass es mit OpenSolaris vorbei ist. Zu den Nachfolgern (Nexenta, OpenIndiana) konnte ich nicht so viel zum Thema Langzeitsupport finden.

marce
18.04.14, 20:16
_wenn_ es die einzige Abhängigkeit ist bekommst Du damit kein Problem. Im anderen Fall - und solange das kein reines Java-Produkt ist (kenne OpenFire nicht und hab's mir auch nicht ergoogled) hat man meist trotzdem noch irgendwas, was ein Problem werden kann - nicht muss.

Was LTS angeht muss man noch unterscheiden, wofür man das Ding einsetzen will. Für Server ergeben sich da halt komplett andere Ansprüche als bei Desktop-Einsatz, wobei das auch wieder anders aussieht, ob es nun privat oder kommerziell sein soll...

Relevant ist dann auch noch, ob und wie ein Upgrade über Versionsgrenzen unterstützt wird und wie komplex der Vorgang ist - bei Debian z.B. ist der im Groben nicht komplizierter als das Einspielen der normalen Updates und je nach verwendeter Software kann man so eine Installation auch problemlos über die nächste Jahrhundergrenze zerren.

Zudem würde ich noch schauen, wie sich denn die Distribution so im Laufe ihres Lebens geschlagen hat - daß man Debian recht problemlos upgraden kann weiß man seit der Entdeckung Amerikas, wie das mit Ubuntu aussieht mittelt sich im Laufe der Zeit noch heraus, Ubuntu LTS darf sich da erst noch bewähren (da gehen die konkreten Erfahrungen eher gegen "hat man noch nicht sooo oft gemacht"), OpenSuse führte das Feature ebenso gerade erst ein, CentOS / RHEL unterstützt es von sich aus nicht (damit stellt sich das Problem also gar nicht), Gentoo und Arch bauen auf dem Weg in die Zufkunft gerne mal das System komplett um und sorgen so für Spaß, ...

kernel
18.04.14, 20:22
Ok, das hilft mir sehr weiter! Vielen Dank für alle Infos! Ab hier müsste ich dann weiterkommen. :-)

Huhn Hur Tu
21.04.14, 00:27
Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian

hafgan
21.04.14, 11:38
Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian Debian

Warum?
Gerade vor dem Hintergrund der Supportzyklen: Wo liegt der Vorteil gegenüber z.B. Ubuntu LTS (5 Jahre statt 3).

marce
21.04.14, 15:23
Naja, bei Debian ist man inzwischen relativ sicher in dem Bereich angekommen, "wo es einfach funktioniert" - *buntu hat doch immer noch den einen oder andere Bock geschossen...

Im großen und ganzen sind wir aber wohl nun nach den Fakten in dem Bereich angekommen, wo nun nacheinander mehr oder weniger dezent der eine oder ander seine Lieblingsdistribution posten wird.

TheDarkRose
21.04.14, 15:32
Btw. Debian Squeeze wurde gerade zur ner LTS gemacht ^^ http://www.heise.de/open/meldung/Verlaengerter-Support-fuer-Debian-6-2173688.html

Huhn Hur Tu
21.04.14, 19:41
Debian, ist meinem Geschmack nach sehr gut fuer Server geeignet, *buntu ist mit an vielen Stellen zu verspielt, fuenf Jahr Support hin oder her.

CentOS, Sientific, Oracle, ... also Red Hat scheint ok zu sein, aber sobald man etwas haben will was nicht im Standart Repository ist, hat man den Vorteil "Enterprise" verloren oder muss kraeftig zahlen.

SLES, naja mit Suse ist irgendwie das selbe, hatte ich schon, hat mir vom handling nicht gefallen.

Um wieder auf Debian zu kommen, das ist ein System das sich fuer mein Gefuehl sehr rund anfuehlt, einfach anpassbar ist und ein fuer mich wichtiger Faktor, nicht von einer Firma abhaengig ist.

Gruss Stefan

hafgan
21.04.14, 23:16
Debian, ist meinem Geschmack nach sehr gut fuer Server geeignet, *buntu ist mit an vielen Stellen zu verspielt, fuenf Jahr Support hin oder her.

CentOS, Sientific, Oracle, ... also Red Hat scheint ok zu sein, aber sobald man etwas haben will was nicht im Standart Repository ist, hat man den Vorteil "Enterprise" verloren oder muss kraeftig zahlen.

SLES, naja mit Suse ist irgendwie das selbe, hatte ich schon, hat mir vom handling nicht gefallen.

Um wieder auf Debian zu kommen, das ist ein System das sich fuer mein Gefuehl sehr rund anfuehlt, einfach anpassbar ist und ein fuer mich wichtiger Faktor, nicht von einer Firma abhaengig ist.

Gruss Stefan

Also nimms mir jetzt bitte nicht übel, aber: "Geschmack, Gefühl, verspielt, gefallen, ..."
Gibts neben den Kosten von Red Hat auch noch andere Fakten? Oder ist es doch nur eine Bauchentscheidung.

Ich hake nur deswegen nach, weil ich immer wieder lese, wie toll Debian für Server ist. Aber so richtig leuchtet mir der Punkt gegenüber Ubuntu LTS noch immer nicht ein ... Außer, dass es nach Deinem Gefühl besser ist... ;)

Gruß
hafgan

marce
22.04.14, 06:24
Wer wirkliches Enterprise-OS mit LTS haben will ist sowohl mit Debian als auch mit Ubuntu auf der falschen Schiene - der kommt (bei den Linuxen) an RHEL oder SLES nicht vorbei.

Den Vorteil von LTS verliert man dort auch nicht, wenn man fremde Paketquellen einbaut. Solange es vernünftige sind - aber das gilt überall (oder haben z.B. die "Fremdquellenmeister unter den Debianern" das nette AFAIR Bildschirmhintergrundfeature alle verdrängt?).

Grundlegend würde ich sogar sagen - durch die sehr offene Art von Debian ist es sogar als Server eher ungeeignet - wer sagt mir denn, daß das von mir gebrauchte Paket X beim nächsten Release noch mit enthalten ist und nicht einfach durch die Freiheitspolicy rausgewürfelt wird, nur weil irgendjemand der Meinug ist, Lizenz A+ ist im Gegensatz zu Lizenz A nicht mehr mit dem Distributionsgewissen vereinbar? Wäre ja auch noch nie vorgekommen :-)

Das mit "steht keine Firma dahinter" - kann auch nach hinten losgehen - im schlimmsten Fall steht die Distribution nämlich in wichtigen Teilen ohne Maintainer da. Oder die Serveradmins verweigern dem Update-Manage-Team den Zugriff auf die Server um Sicherheitspatches hochzuladen.

Huhn Hur Tu
22.04.14, 11:54
Also nimms mir jetzt bitte nicht übel, aber: "Geschmack, Gefühl, verspielt, gefallen, ..."
Gibts neben den Kosten von Red Hat auch noch andere Fakten? Oder ist es doch nur eine Bauchentscheidung.

Ich hake nur deswegen nach, weil ich immer wieder lese, wie toll Debian für Server ist. Aber so richtig leuchtet mir der Punkt gegenüber Ubuntu LTS noch immer nicht ein ... Außer, dass es nach Deinem Gefühl besser ist... ;)

Gruß
hafgan


Ok ein wenig genauer,

SLES und RHEL supporten genau die Pakete die man gekauft hat, wenn du etwas anderes einspielst, wird das eben nicht suported, oder man zahlt hier einen gewaltigen Aufpreis, bzw. man ist auf Fedora Niveau. Dafuer besticht RHEL mit der sher guten Dokumentation, kein Wunder wenn man sich in den Paketen einschraenkt.

Ubuntu hat, zugegeben auf der Gui, sehr viel experimentiert was nicht fuer einen professionellen Einsatz steht, entweder Canonical Stil oder nicht.

Debian wird bei mir im Unternehmen sehr stark in einer modifizierten Variante, Userverwaltung und andere Kleinigkeiten, und wir fahren sehr gut damit. Debians Lizenzpolitik hat hier bisher keine Spuren hinterlassen.

marce
22.04.14, 12:02
Dafür supporten viele Drittanbieter SLES oder RHEL als qualifizierten, zertifizierten Unterbau.

Ich würde von RedHat oder Novell auch gar nicht erwarten, daß sie Drittsoftware supporten - warum denn auch? Dafür ist der Hersteller der Software zuständig.

Wenn es wirklich um Support geht bist Du damit meist besser beraten - euer modifiziertes Debian supported garantiert niemand außer euch selbst.

Ich fürchte aber, so langsam haben wir den Fokus des TE komplett verlassen.

cane
22.04.14, 12:17
Wer wirkliches Enterprise-OS mit LTS haben will ist sowohl mit Debian als auch mit Ubuntu auf der falschen Schiene - der kommt (bei den Linuxen) an RHEL oder SLES nicht vorbei.

Ich sehe das differenzierter:

Die meisten Kunden mit sehr guter eigener IT investieren ihr Geld in Personal statt Lizenzen und setzen rein auf Debian oder CentOS. Typischerweise zum Beispiel die Webhoster, Cloud Anbieter, ISVs, ... die eh alle Kompetenzen inhouse haben müssen.

Ein klassischer deutscher Enterprise Laden kauft zumindest für die Applikationen Support ein, oft auch für den ganzen Stack inklusive OS.

mfg
cane

marce
22.04.14, 12:24
Klar, man kann disktuieren wo welcher Level von Enterprise anfängt - viele Appliances haben ein Debian oder BSD als Unterbau - aber da bekomme ich den Support ja nicht von Debian oder BSD sondern vom Hersteller des Gesamtprodukt.

Ich habe auch nichts gegen die Systeme als Server-OS (im Gegenteil) - aber es ist nun mal so, daß das, was man normalerweise bei Enterprise haben will eben z.B. von Debian nicht geboten wird - qualifizierte Patches, lange Lebensdauer mit unveränderter API, Zertifizierung seitens Drittanbietern, ... - man muss eben wissen, auf was man sich einlässt und wo eben die Grenzen des jeweiligen LTS-Systems bzw. der Distribution liegen.

Huhn Hur Tu
23.04.14, 20:30
Hi Leute,

stehe davor, mir zuhause einen Mini-Server zu basteln, der hauptsächlich LAMP machen soll, aber auch XMPP-Server, CalDAV-Server, ggf. VPN, verschiedene Webfrontends (Webmail, Webcalendar, Bookmarksync, Fotogallerie, ...) + ein paar selbstgestrickte Sachen und eventuell noch anderes Zeug.

Tendenziell tendiere ich zu Debian-basierten Distris, bin da aber nicht zwangsläufig festgelegt.

Nun bin ich daran interessiert, dass der möglichst lange läuft, ohne dass ich ein Major Upgrade machen muss. Gemeint ist damit, dass ich nicht jedes halbe Jahr / Jahr ein Upgrade auf die nächste Version durchziehen muss, nur um dann zu hoffen, dass hinterher noch alles funktioniert. Rolling-Release-Dinger kamen irgendwie dadurch nicht in Frage. So dachte ich bisher jedenfalls.

Also richtete ich mein Augenmerk eher auf stabilere Distris, bzw. welche mit Langzeitunterstützung. Z.B. Ubuntu LTS, CentOS, Debian, ...
Nun bekam ich aber mit, dass viele davon gar nicht so lang ausgelegt sind. Debian ist meistens 1 Jahr nach nächster Version noch mit Updates dabei, macht also ca. 3 Jahre insgesamt pro Version. CentOS ist wohl so mit 4-5 Jahren dabei, Ubuntu mit 5, ... und dann kommt irgendwie nichts. OpenSuSE mit dem Evergreen sporadisch, sonst nur 18 Monate. Andere Distris teilweise nur 1 Jahr oder halt bis zur nächsten Version oder oder oder... halt kurz. Es kann ja nun aber nicht sein, dass ich nur die Wahl zwischen Ubuntu und CentOS habe, wenn der Zeitraum lang sein soll, oder?

Da ich keinen Supportvertrag brauche (RHEL, SLES, ...) habe ich da angefangen mich zu fragen, wie Firmen das denn so machen, die sich selbst supporten. Von einigen habe ich mitbekommen, dass sie Ubuntu einsetzen, CentOS, Debian... aber auch sowas wie Mageia, OpenSuSE ohne Evergreen, etc.

Ergo: Das muss dann ja auch irgendwie OHNE Langzeitsupport gehen...?! WIE machen die das? Wie kann ich beispielsweise Mageia auf dem Server einsetzen ohne dass ich mit den kurzen Zyklen Probleme bekomme?

Kann mir das einer erklären? Upgraden die Leute jedes halbe Jahr / Jahr und hoffen dann, dass alles läuft und fangen im Notfall an zu reparieren? Oder basteln die sich einfach einen neuen Server und ziehen dann alles rüber und wechseln damit das Produktivsystem erst ab, wenn das neue wirklich gut läuft?

Ich wäre sehr dankbar, wenn mir da jemand die Erleuchtung bringen kann. Ich habe da echt mal Klärungsbedarf.

Ich denke wir haben hier den Fokus um einige Dimensionen verloren


mir zuhause einen Mini-Server zu bastelnwobei ich diesen Fokusverlust anhand der Qualitaet der Beitraege ueberhaupt nicht bereue.

Fuer den Threadersteller kommt ein SLES oder RHEL schon aus der Aufgabbenstellung kaum in Frage, die zu erwartenden Lizenzkosten sind einfach zu hoch was CentOS, Ubuntu Server LTS oder Debian zum OS der Wahl macht.

Soviel zum Orginalthread, nun weiter im Enterprisetalk:

marce, meinem Vorposter kann ich voll und ganz beipflichten, dass bei mir im Unternehmen (ISP/Hosting/...) die Personaldecke etwas grosszuegiger fuer die Anpassung von Debian gestrickt ist, als das in einem kleineren, oder auch groesseren, mittelstaendischen Unternehmen der Normalfall ist.

Ich bin ein Verfechter von, wir machen selbst oder holen uns das bei einem freien Systemhaus auf lizenzkostenfreier Basis, was initial mehr kostet, aber in der Zukunft die Kosten der Abhaengigkeit zu einem Anbieter reduziert.
Wer zu Beginn damit rechnet, bzw. die upgradezyklen auf drei Jahre auch einhaelt, hat eine "deutlich" groessere Flexibilitaet, und damit ein groeseres Know How als diejenigen die Systeme bis zum Ende der Welt laufen lassen wollen.

Soviel von meinem Senf

nopes
23.04.14, 20:58
Zum Thema LTS und Debian stehe ich definitiv auf einen anderen Standpunkt als marce. Immerhin kann man noch heute alles bis hin zu Debian 1.1 laden, mehr LTS geht nicht ;). Klar werden die nicht mehr gepflegt, oft ist aber die reine Verfügbarkeit wichtig und da ist Debian schon eine Bank.

Hmm naja, spielt aber eigentlich eh keine so große Rolle mehr, (bei Enterprise) ist doch eh das meiste virtuell geworden, was irgendwie alles vereinfacht. Wenn nicht alles virtuell ist, dann ist für die Ausnahmen idR auch genug Kohle da und eh alles total "verkommerzt".

Wichtiger finde ich eigentlich die Versionspflege der installierten Pakete. Ein Beispiel, was ich so erlebt habe:
Ein Laden hat mehrere Server gemietet, alle laufen mit openSuSE, wurden aber nicht gleichzeitig bereitgestellt (ist halt so gewachsen). Ein absoluter Wahnsinn, was da für ein Versionschaos geherrscht hat. Einheitlichen Paketquellen, im leben nicht. Das hat natürlich regelmäßig zu unangenehmen Situationen geführt - Beispielsweise beim nachrüsten von zope.
Nun muss man sagen, das openSuSE damals kein echtes dist upgrade konnte, die Situation lies sich nicht wirklich verbessern, der Admin-Aufwand war wirklich enorm. Naja dann liefen die Verträge aus und das Modell entsprechend angepasst, also keine einzelne Server mehr, sondern was auf ESX basis gepachtet - mal davon ab, dass das ähnlich philosophisch ist, war die Entscheidung gut...
Wie auch immer, es wurde dann überlegt, welche Distribution verwendet werden soll. Dabei blieben folgende Dinge hängen, von Haus aus bietet Debian die meisten Pakete, hat bewährte Update- und vor allem Upgrade-Funktionen. Aber Menge hin Menge her, die meisten Pakete waren und sind einfach zu alt, was da ein großes Problem war, da Features von neueren Versionen fehlten. Die Entscheidung viel daher auf ein Ubuntu LTS Server. Das ist aber inzwischen auch wieder eine gute Weile her, damals ging das mit den Upgrades bei openSuSE erst los, daher wurde geschwenkt zumal durch die Historie vertrauen ins alte OS verloren ging, obwohl da der ein oder andere senior Admin nicht glücklich war. Inzwischen sind aber alle glücklich und zufrieden und aktuell ist es noch gut wartbar (dem hören und sagen nach) - was glaube ich aber weniger am OS, als mehr an der Aufteilung durch VMs liegt.

Und ganz ehrlich, wieso müssen denn die Pakete immer aus dem Internet kommen, kann man die nicht lokal vorhalten, klar kann man und dann ist LTS irgendwie ohnehin nicht so das Problem...

marce
23.04.14, 21:02
Es ist eben ein komplexes Gebiet - in manchen Bereichen will man die Abhängigkeit von einem Anbieter ja sozusagen haben - eben weil ich dann einen belastbaren und qualifizierten Support erhalte - den ich bei entsprechenden Incidents dann aber auch komplett "in's Boot" holen kann.

In anderen Bereichen reicht es mir, einen stabilen Unterbau zu haben, auf den ich dann in Eigenregie die von mir gewünschte Umgebung in dem von mir gewünschten Umfang aufsetze.

LTS bzw. Support genieße ich in beiden Fällen - und je nach Umgebung ist eben auch das L mehr oder weniger relevant.


edit:zum Thema LTS + Debian - ja klar kann ich auch heute noch ein Debian 1.1 bis auf ein aktuelles hochziehen - doch das ist eben nicht LTS. Im Zuge dieser Updates ändern sich Versionen, APIs, Konfigurationen - und teilweise so massiv, daß nach einem Update eben nicht mehr alles "einfach so" läuft.

... wenn man dann noch die paar Sonderfeatures der Debian-Updates aus den letzten Jahren mit dazu nimmt - oh je :-) - da wurden einfach mal div. Treiber aus dem Kernel entfernt, vergessen, Software komplett entfernt, ... - eben das alles macht Debian, trotz der problemlosen Updatebarkeit eben nicht zu einer LTS- oder Enterprise-Distribution.

LTS + Enterprise bedeutet für mich, daß ich mich eben auf die API verlassen kann. Ich veröffnetlich eine Software für ein OS und kann sicher sein, daß egal wann das Ding im Laufe seiner Lebenszeit darauf installiert wird - es funktioniert.

nopes
23.04.14, 21:19
edit:zum Thema LTS + Debian - ja klar kann ich auch heute noch ein Debian 1.1 bis auf ein aktuelles hochziehenOder das fehlende Paket nach installieren und auf 1.1 bleiben, das ist für mich LTS ;)

Aber hast recht, ein komplexes Gebiet

cane
23.04.14, 21:44
Vielleicht für den ein oder anderen interessant, die technischen Teams aller großen Webhoster / Provider werden sich nicht fundamental irren:

Der Trend geht seit etwa fünf Jahren im Bereich Webhosting / Cloud Provider / technisch fitte Kunden von Debian in Richtung Ubuntu und CentOS. Debian hat seine Monopolstellung verloren, hat aber immer noch einen massiven Anteil.

mfg
cane

kernel
13.05.14, 19:31
Hi Leute,

war ne Weile ziemlich beschäftigt und im Urlaub, etc.

Ehrlich gesagt fand ich die "Ausschweifungen" des Themas jetzt doch sehr erfrischend und interessant. Danke dafür! Ich bin für Horizonterweiterungen immer recht dankbar.

Inzwischen hab ich's auch endlich mal geschafft den Server zu bestellen und seit heute liegt er hier und wird nächstes Wochenende zusammengebastelt.

Also habe ich mich auch nochmal mit dem OS-Thema beschäftigt, überall noch was dazu gelesen und habe sämtliche Faktoren (in meinem Fokus) gegeneinander aufgewogen. Zur Wahl standen OpenSUSE, CentOS, Ubuntu und Debian.

Geworden ist es jetzt Ubuntu LTS 14.04.

Hat mit vielen harten und weichen Faktoren zu tun, unter anderem Support-Zeitraum, kein Buch mit sieben Siegeln, viel freier Support, Zwischenreleases, gute Paketauswahl, inzwischen offenbar gute Stabilität und so weiter. Es wäre zwar bei SuSE mit Yast einfacher zu konfigurieren gewesen, aber ich will ja auch was lernen. Trotz Ausprobierens von verschiedensten Distris + Informierens bin ich irgendwie immer wieder hier gelandet. Da muss ich mir ja das Leben nicht unnötig schwer machen und dagegen ankämpfen. Mal sehen was sich so ergibt und ob das ne runde Sache ist.

Auf jeden Fall danke an alle, die hier im Thread geschrieben haben! :-)