Wir verwenden seit geraumer Zeit Debian Stable als Serverbetriebssystem. Nach etlichen Schwierigkeiten mit den "debianisierten" Softwarepaketen und gnadenlos veralteten Versionen werden wir mittelfristig auf Arch Linux migrieren, welches wir nun seit über zwei Jahren erfolgreich im Digital Signage Bereich, auf unserem Büroserver und auf Workstations verwenden.
Ersteres. Es werden in regelmäßigen Abständen Snapshots vom aktuellen Stand mittels pacman -Syuw gemacht und auf Referenzgeräten getestet. Nach erfolgreicher Testphase werden dann die Snapshots auf den Produktivsystemen mittels pacman -Su eingespielt.
Das erfordert entweder ein "continuous testing" der Anwendungen (ob nicht doch was kaputt ist) oder "Mut zur Lücke" (?)
Aber das ist doch bei (fast) jedem Update so, dass man Testen muss. Dies unabhängig von der Distribution, auch ein 'kleiner' Sicherheitspatch kann einem die Datenbank stillegen... Ich persönlich teste Updates zuerst an weniger kritischen Systemen...
Der enorme Vorteil ist, dass man nicht alle Jahre wieder ein "grosses" Upgrade fahren muss (inkl. einem erheblichen Aufwand). Beim RollingRelease geschieht dies verteilt mit wie mit den "normalen" Updates. Einen Mehraufwand dieser "normalen" Updates sehe ich da nicht, weil wie oben geschrieben, auch die (Sicherheits-)Updates erfordern ein Wartungsfenster mit Backup & Testen. Weitere Vorteile sind, dass man z.B. bei Gentoo seine individuelle Mischung aus stable & unstable zusammenstellen kann. Wenn es fehlschlägt, dann man immer noch zur alten Version zurück. Da das Repository meist versch. Versionen eines Paketes anbietet. Auch ein Hardware/Architekturwechsel erfordert keine Neuinstallation...
Mit dem Testen alleine ist es bei Rolling Release nur nicht getan, da es hier explizit vorgesehen ist, dass sich das Verhalten der Software ändert. Man muss die Produktivumgebung also auch immer wieder anpassen, was Zeit erfordert. Dabei hat erst WannaCry die Tage gezeigt wie wichtig es ist, Sicherheitspatches zeitnah einzuspielen.
Von SourceMage-User am Mo, 22. Mai 2017 um 10:14 #
Hi, aber das Verhalten von software ändert sich ja bei einem Rolling Release nicht anders als bei anderrn Updatemodellen.
Natürlich sollte man vor dem Testen die ChangeLOGs lesen. Aber das Testen bleibt und hier ergibt sich kein mehraufwand zu nich RollingReleaseDistributionen. (zumal unter Linux der gute Admin vieles Automatisiert)
Zu deinem wannacry Argument, fullack. Hier glänzen gerade Gentoo u. Arch, SourceMage mit aktuellster software und auch sehr zeitnahen Updates.
Besonderer Vorteil bei Quelltext-Distri's: Man kann auch - je nach Schwachstelle - die entspdrechende Funktion komfortabel nich mit ein kompilieren
Von SourceMage-User am Mo, 22. Mai 2017 um 10:15 #
Hi, aber das Verhalten von software ändert sich ja bei einem Rolling Release nicht anders als bei anderrn Updatemodellen.
Natürlich sollte man vor dem Testen die ChangeLOGs lesen. Aber das Testen bleibt und hier ergibt sich kein mehraufwand zu nich RollingReleaseDistributionen. (zumal unter Linux der gute Admin vieles Automatisiert)
Zu deinem wannacry Argument, fullack. Hier glänzen gerade Gentoo u. Arch, SourceMage mit aktuellster software und auch sehr zeitnahen Updates.
Besonderer Vorteil bei Quelltext-Distri's: Man kann auch - je nach Schwachstelle - die entspdrechende Funktion komfortabel nich mit ein kompilieren
Von SourceMage-User am Mo, 22. Mai 2017 um 10:15 #
Hi, aber das Verhalten von software ändert sich ja bei einem Rolling Release nicht anders als bei anderrn Updatemodellen.
Natürlich sollte man vor dem Testen die ChangeLOGs lesen. Aber das Testen bleibt und hier ergibt sich kein mehraufwand zu nich RollingReleaseDistributionen. (zumal unter Linux der gute Admin vieles Automatisiert)
Zu deinem wannacry Argument, fullack. Hier glänzen gerade Gentoo u. Arch, SourceMage mit aktuellster software und auch sehr zeitnahen Updates.
Besonderer Vorteil bei Quelltext-Distri's: Man kann auch - je nach Schwachstelle - die entspdrechende Funktion komfortabel nich mit ein kompilieren
Hi, aber das Verhalten von software ändert sich ja bei einem Rolling Release nicht anders als bei anderrn Updatemodellen.
Natürlich sollte man vor dem Testen die ChangeLOGs lesen. Aber das Testen bleibt und hier ergibt sich kein mehraufwand zu nich RollingReleaseDistributionen. (zumal unter Linux der gute Admin vieles Automatisiert)
Zu deinem wannacry Argument, fullack. Hier glänzen gerade Gentoo u. Arch, SourceMage mit aktuellster software und auch sehr zeitnahen Updates.
Besonderer Vorteil bei Quelltext-Distri's: Man kann auch - je nach Schwachstelle - die entspdrechende Funktion komfortabel nich mit ein kompilieren
Hört sich plausibel an, aber in der Praxis lasse ich mittlerweile die Finger weg von Rolling Release Distros. Ich habe lange Zeit auf meinen Desktop OpenSuse Tumbleweed laufen gehabt. Wie oft ich mein System geschrottet habe, kann ich gar nicht mehr zählen. Mal ging die eine Software nicht, weil irgendwelche Pakete nicht mehr stimmig waren, mal hing ich beim Bootvorgang fest (meine Festplatte ist verschlüsselt).
Ich bin ein Freund von aktueller Anwendungssoftware, aber nicht zu Lasten der Stabilität. Mittlerweile habe ich eine ganz gute Lösung gefunden. Ich arbeite mit OpenSuse Leap und habe alle wichtigen Repos für meine Anwendungen eingebunden. Von KDE-Extra bis hin zu Editors und und.... Leap läuft jetzt sogar mit dem neusten Kernel 4.11 Mein System ist extrem stabil und ich habe trotzdem alle neuen Updates der wichtigsten Anwendungen, von LibreOffice, Calibre und Thunderbird. Der Unterbau bleibt gleich, bis auf die Anwendungen. Ich hatte bisher keinen einzigen Absturz oder ein kaputtes System gehabt.
Mich würden keine 10 Pferde mehr auf eine Rolling Release bringen! Da ist mir meine Lebenszeit zu wichtig, als dass ich jedes mal nach Lösungen für ein kaputt-upgedatetes System suchen muss. Das ist meine persönliche Meinung, mehr nicht
Ja, halte ich genauso. Alle Desktoprechner und die paar (Web)server laufen mit einer Stable-Version von openSUSE - mit 13.x war schon alles Bestens. die erste Leap hab ich mir nach Problemen auf dem Desktop (hauptsächlich Plasma5 geschuldet) auf den Servern gespart, aber 42.2 ist so stabil auf allen Kisten, das macht echt Spaß.
Auf einem einzelnen Server ist es kein wohl kein größeres Problem, etwas nicht-enterprise-artiges wie Arch Linux laufen zu lassen. Selbst wenn noch eine handvoll Workstations hinzukommen, kann man damit ohne Schwierigkeiten den Betrieb aufrecht halten.
Anders sieht es halt aus, wenn 1000+ Server damit laufen sollen. Da wird wohl eher SLES,Redhat,CentOS eingesetzt und selbst Debian ist da noch Außenseiter.
Es gibt auch für Arch sowie Gentoo Lösungen, ja es sind mehrere, die einem bei sowas helfen. Im Grunde läuft es aber bei allen darauf hinaus das man ein oder zwei Systeme als Vorlage benutzt und wenn diese zufriedenstellen laufen wird ein Abbild davon ausgerollt. Und wenn ein Abbild mal doch Probleme machen sollte bieten die besseren Lösungen einem auch die Möglichkeit zu einem älteren Abbild zurück zu kehren.
Bei meinen privaten Servern habe ich nur rolling release, hier kommt gentoo zum Einsatz. Wenn ich da was versaue ist das mein persönliches Problem. Die Server sind meistens so abgespeckt dass nur 1-2 Dienste (openSSH und z.B. ZNC) dadrauf laufen ansonsten nichts Anderes. Das läuft sehr gut.
Für andere Software die immer verfügbar sein muss kommt ein stabiles Linux drauf. Wenn ich die Server betreiben könnte (was aber nicht meine Aufgabe ist) dann wäre OpenBSD dadrauf, weil die Dienste die genutzt werden auf den Servern sehr spezieller Art sind. Hier aber weiterhin stable releases. Oft werden Pakete, wenn sie aktuell sein müssen, selbst gebaut, weiterhin aber stable releases Distributionen.
Der stabile Betrieb ist das Fundament.
So ist das.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Mai 2017 um 15:52.
Ich werde wohl demnächst einen einfachen Homeserver installieren und nach überlegen zwischen OpenSuSE und Debian, habe ich mich für OpenSuSE entschieden. Leap ist als Stable deklariert, wie Debian auch, besitzt aber die Möglichkeit durch SBS besser angepasst zu werden. Bei Debian ist man da weniger flexibel.
SUSE mach schon auf dem Desktop immer wieder merkwürdige Sachen. Das dann auf einem Server? Wenn meinetwegen die Festplattenüberwachung per Smartd schon nicht hin haut? Selbst wenn das nur meinen privaten Datenbestand betrifft, das wäre mir entschieden eine Nummer zu kitzlig.
Man sollte die Distribution schon etwas kennen. Zum Beispiel habe ich mit BtrFS, was SuSE Standard liefert, schlechte Erfahrungen gemacht. Ext4 und das System ist schneller und stabiler.
Desktop ist unter Linux sowieso ein heikles Thema, davon ist SuSE nicht ausgenommen. Mit Gnome habe ich keine Probleme gehabt.
Private Daten werden darauf auch nicht liegen. Der Server wird zum Entwickeln und Datenaustausch benutzt.
Wir sind Anwendungshoster und nutzen seit Jahren Ubuntu LTS und updaten auch alles was rein kommt ohne das großartig zu testen. Die Anwendungen sind überwacht und bis jetzt haben wir bis auf Kleinigkeiten auch nie Probleme gehabt. Wir hatten auch mal vor Debian zu nutzen, aber die Softwarestände sind einfach zu alt bei Veröffentlichung des jeweiligen Stable und die Langlebigkeit ist bis vor kurzen auch nicht gegeben gewesen. Jetzt wo Debian LTS anbietet, könnte man allerdings drüber nachdenken.
Mir persönlich gefällt das "Rolling Releases"-Model zwar ganz gut aber nicht selten sind proprietäre Programme (wie Beispielweise der Schrott von Abacus) so zickig das man letzten Endes schon froh sein kann kein veraltetes System nehmen zu müssen welches eventuell sogar nicht einmal mehr Support erhält.
Dazu kommt das nicht wenige Hersteller solcher Softwarepakete oft auch nur für Debian, Redhat, SuSE und manchmal auch Ubuntu Pakete bieten. Vor allem auf Gentoo, wo es für die Hersteller eigentlich ein leichtes wäre ein ebuild raus zu hauen, steht man nicht selten ohne Repository da.
Wir verwenden seit geraumer Zeit Debian Stable als Serverbetriebssystem.
Nach etlichen Schwierigkeiten mit den "debianisierten" Softwarepaketen und gnadenlos veralteten Versionen werden wir mittelfristig auf Arch Linux migrieren, welches wir nun seit über zwei Jahren erfolgreich im Digital Signage Bereich, auf unserem Büroserver und auf Workstations verwenden.
Und wie geht ihr in dem Kontext Rolling Release von Arch mit dem Testen der Funktionsfähigkeit der notwendigen Anwendungen die ihr im Betrieb habt um?
Das erfordert entweder ein "continuous testing" der Anwendungen (ob nicht doch was kaputt ist) oder "Mut zur Lücke" (?)
Es können ja bei Updates (die mehr sind als reine Sicherheitsupdates) auch mal Funktionen wegfallen oder die API ändert sich etc...
Ersteres. Es werden in regelmäßigen Abständen Snapshots vom aktuellen Stand mittels pacman -Syuw gemacht und auf Referenzgeräten getestet.
Nach erfolgreicher Testphase werden dann die Snapshots auf den Produktivsystemen mittels pacman -Su eingespielt.
Ich persönlich teste Updates zuerst an weniger kritischen Systemen...
Der enorme Vorteil ist, dass man nicht alle Jahre wieder ein "grosses" Upgrade fahren muss (inkl. einem erheblichen Aufwand). Beim RollingRelease geschieht dies verteilt mit wie mit den "normalen" Updates. Einen Mehraufwand dieser "normalen" Updates sehe ich da nicht, weil wie oben geschrieben, auch die (Sicherheits-)Updates erfordern ein Wartungsfenster mit Backup & Testen.
Weitere Vorteile sind, dass man z.B. bei Gentoo seine individuelle Mischung aus stable & unstable zusammenstellen kann. Wenn es fehlschlägt, dann man immer noch zur alten Version zurück. Da das Repository meist versch. Versionen eines Paketes anbietet. Auch ein Hardware/Architekturwechsel erfordert keine Neuinstallation...
Mit dem Testen alleine ist es bei Rolling Release nur nicht getan, da es hier explizit vorgesehen ist, dass sich das Verhalten der Software ändert. Man muss die Produktivumgebung also auch immer wieder anpassen, was Zeit erfordert. Dabei hat erst WannaCry die Tage gezeigt wie wichtig es ist, Sicherheitspatches zeitnah einzuspielen.
Hi,
aber das Verhalten von software ändert sich ja bei einem Rolling Release nicht anders als bei anderrn Updatemodellen.
Natürlich sollte man vor dem Testen die ChangeLOGs lesen. Aber das Testen bleibt und hier ergibt sich kein mehraufwand zu nich RollingReleaseDistributionen. (zumal unter Linux der gute Admin vieles Automatisiert)
Zu deinem wannacry Argument, fullack. Hier glänzen gerade Gentoo u. Arch, SourceMage mit aktuellster software und auch sehr zeitnahen Updates.
Besonderer Vorteil bei Quelltext-Distri's:
Man kann auch - je nach Schwachstelle - die entspdrechende Funktion komfortabel nich mit ein kompilieren
Hi,
aber das Verhalten von software ändert sich ja bei einem Rolling Release nicht anders als bei anderrn Updatemodellen.
Natürlich sollte man vor dem Testen die ChangeLOGs lesen. Aber das Testen bleibt und hier ergibt sich kein mehraufwand zu nich RollingReleaseDistributionen. (zumal unter Linux der gute Admin vieles Automatisiert)
Zu deinem wannacry Argument, fullack. Hier glänzen gerade Gentoo u. Arch, SourceMage mit aktuellster software und auch sehr zeitnahen Updates.
Besonderer Vorteil bei Quelltext-Distri's:
Man kann auch - je nach Schwachstelle - die entspdrechende Funktion komfortabel nich mit ein kompilieren
Hi,
aber das Verhalten von software ändert sich ja bei einem Rolling Release nicht anders als bei anderrn Updatemodellen.
Natürlich sollte man vor dem Testen die ChangeLOGs lesen. Aber das Testen bleibt und hier ergibt sich kein mehraufwand zu nich RollingReleaseDistributionen. (zumal unter Linux der gute Admin vieles Automatisiert)
Zu deinem wannacry Argument, fullack. Hier glänzen gerade Gentoo u. Arch, SourceMage mit aktuellster software und auch sehr zeitnahen Updates.
Besonderer Vorteil bei Quelltext-Distri's:
Man kann auch - je nach Schwachstelle - die entspdrechende Funktion komfortabel nich mit ein kompilieren
Hi,
aber das Verhalten von software ändert sich ja bei einem Rolling Release nicht anders als bei anderrn Updatemodellen.
Natürlich sollte man vor dem Testen die ChangeLOGs lesen. Aber das Testen bleibt und hier ergibt sich kein mehraufwand zu nich RollingReleaseDistributionen. (zumal unter Linux der gute Admin vieles Automatisiert)
Zu deinem wannacry Argument, fullack. Hier glänzen gerade Gentoo u. Arch, SourceMage mit aktuellster software und auch sehr zeitnahen Updates.
Besonderer Vorteil bei Quelltext-Distri's:
Man kann auch - je nach Schwachstelle - die entspdrechende Funktion komfortabel nich mit ein kompilieren
Hört sich plausibel an, aber in der Praxis lasse ich mittlerweile die Finger weg von Rolling Release Distros.
Ich habe lange Zeit auf meinen Desktop OpenSuse Tumbleweed laufen gehabt. Wie oft ich mein System geschrottet habe, kann ich gar nicht mehr zählen. Mal ging die eine Software nicht, weil irgendwelche Pakete nicht mehr stimmig waren, mal hing ich beim Bootvorgang fest (meine Festplatte ist verschlüsselt).
Ich bin ein Freund von aktueller Anwendungssoftware, aber nicht zu Lasten der Stabilität. Mittlerweile habe ich eine ganz gute Lösung gefunden. Ich arbeite mit OpenSuse Leap und habe alle wichtigen Repos für meine Anwendungen eingebunden. Von KDE-Extra bis hin zu Editors und und....
Leap läuft jetzt sogar mit dem neusten Kernel 4.11
Mein System ist extrem stabil und ich habe trotzdem alle neuen Updates der wichtigsten Anwendungen, von LibreOffice, Calibre und Thunderbird. Der Unterbau bleibt gleich, bis auf die Anwendungen. Ich hatte bisher keinen einzigen Absturz oder ein kaputtes System gehabt.
Mich würden keine 10 Pferde mehr auf eine Rolling Release bringen! Da ist mir meine Lebenszeit zu wichtig, als dass ich jedes mal nach Lösungen für ein kaputt-upgedatetes System suchen muss. Das ist meine persönliche Meinung, mehr nicht
Ja, halte ich genauso.
Alle Desktoprechner und die paar (Web)server laufen mit einer Stable-Version von openSUSE - mit 13.x war schon alles Bestens. die erste Leap hab ich mir nach Problemen auf dem Desktop (hauptsächlich Plasma5 geschuldet) auf den Servern gespart, aber 42.2 ist so stabil auf allen Kisten, das macht echt Spaß.
Auf einem einzelnen Server ist es kein wohl kein größeres Problem, etwas nicht-enterprise-artiges wie Arch Linux laufen zu lassen. Selbst wenn noch eine handvoll Workstations hinzukommen, kann man damit ohne Schwierigkeiten den Betrieb aufrecht halten.
Anders sieht es halt aus, wenn 1000+ Server damit laufen sollen. Da wird wohl eher SLES,Redhat,CentOS eingesetzt und selbst Debian ist da noch Außenseiter.
Es gibt auch für Arch sowie Gentoo Lösungen, ja es sind mehrere, die einem bei sowas helfen.
Im Grunde läuft es aber bei allen darauf hinaus das man ein oder zwei Systeme als Vorlage benutzt und wenn diese zufriedenstellen laufen wird ein Abbild davon ausgerollt. Und wenn ein Abbild mal doch Probleme machen sollte bieten die besseren Lösungen einem auch die Möglichkeit zu einem älteren Abbild zurück zu kehren.
Hi, kannst du bitte sagen, um welche "debianisierten" Pakte es genau geht?
Bei meinen privaten Servern habe ich nur rolling release, hier kommt gentoo zum Einsatz. Wenn ich da was versaue ist das mein persönliches Problem. Die Server sind meistens so abgespeckt dass nur 1-2 Dienste (openSSH und z.B. ZNC) dadrauf laufen ansonsten nichts Anderes. Das läuft sehr gut.
Für andere Software die immer verfügbar sein muss kommt ein stabiles Linux drauf.
Wenn ich die Server betreiben könnte (was aber nicht meine Aufgabe ist) dann wäre OpenBSD dadrauf, weil die Dienste die genutzt werden auf den Servern sehr spezieller Art sind. Hier aber weiterhin stable releases.
Oft werden Pakete, wenn sie aktuell sein müssen, selbst gebaut, weiterhin aber stable releases Distributionen.
Der stabile Betrieb ist das Fundament.
So ist das.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Mai 2017 um 15:52.Ich werde wohl demnächst einen einfachen Homeserver installieren und nach überlegen zwischen OpenSuSE und Debian, habe ich mich für OpenSuSE entschieden. Leap ist als Stable deklariert, wie Debian auch, besitzt aber die Möglichkeit durch SBS besser angepasst zu werden. Bei Debian ist man da weniger flexibel.
SUSE mach schon auf dem Desktop immer wieder merkwürdige Sachen. Das dann auf einem Server? Wenn meinetwegen die Festplattenüberwachung per Smartd schon nicht hin haut?
Selbst wenn das nur meinen privaten Datenbestand betrifft, das wäre mir entschieden eine Nummer zu kitzlig.
Man sollte die Distribution schon etwas kennen. Zum Beispiel habe ich mit BtrFS, was SuSE Standard liefert, schlechte Erfahrungen gemacht. Ext4 und das System ist schneller und stabiler.
Desktop ist unter Linux sowieso ein heikles Thema, davon ist SuSE nicht ausgenommen. Mit Gnome habe ich keine Probleme gehabt.
Private Daten werden darauf auch nicht liegen. Der Server wird zum Entwickeln und Datenaustausch benutzt.
Wir sind Anwendungshoster und nutzen seit Jahren Ubuntu LTS und updaten auch alles was rein kommt ohne das großartig zu testen. Die Anwendungen sind überwacht und bis jetzt haben wir bis auf Kleinigkeiten auch nie Probleme gehabt. Wir hatten auch mal vor Debian zu nutzen, aber die Softwarestände sind einfach zu alt bei Veröffentlichung des jeweiligen Stable und die Langlebigkeit ist bis vor kurzen auch nicht gegeben gewesen. Jetzt wo Debian LTS anbietet, könnte man allerdings drüber nachdenken.
Mir persönlich gefällt das "Rolling Releases"-Model zwar ganz gut aber nicht selten sind proprietäre Programme (wie Beispielweise der Schrott von Abacus) so zickig das man letzten Endes schon froh sein kann kein veraltetes System nehmen zu müssen welches eventuell sogar nicht einmal mehr Support erhält.
Dazu kommt das nicht wenige Hersteller solcher Softwarepakete oft auch nur für Debian, Redhat, SuSE und manchmal auch Ubuntu Pakete bieten. Vor allem auf Gentoo, wo es für die Hersteller eigentlich ein leichtes wäre ein ebuild raus zu hauen, steht man nicht selten ohne Repository da.