12
Never touch a running System?
ist den wirklich so?
Hallo *.*,
ich lese es in letzter Zeit immer wieder hier.. Never touch a running System! ...
Seht ihr das wirklich so?
Spätestens wenn ich an laufende Sicherheitsupdate denke, jagt mir der Spruch kalte Schauer über den Rücken.
gepannt auf Antworten
meinereiner
ich lese es in letzter Zeit immer wieder hier.. Never touch a running System! ...
Seht ihr das wirklich so?
Spätestens wenn ich an laufende Sicherheitsupdate denke, jagt mir der Spruch kalte Schauer über den Rücken.
gepannt auf Antworten
meinereiner
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 25769
Url: https://administrator.de/contentid/25769
Ausgedruckt am: 26.04.2024 um 23:04 Uhr
12 Kommentare
Neuester Kommentar
hi
tja meistens beziehe ich das auf selbst erstellte Konfigurationen, die eine festgelegte
Namensgebung, IP-Ranges, Domänennamen, IP von Servern.
solche Dinge sollte man vorher festzurren und diskutieren und absegnen, danach sind sie verbindlich dann verändern sich diese elemtaren Dinge nicht mehr.
SPs , Sicherheitsupdates oder ähnliches lande normalerweise im Labor auf den Servern und werden dort durchgestresst, dann in der Echtumgebung angewandt. dabei werden Herstelleraussagen natürlich berücksichtigt.
so ist der Slogan Never touch a running System manchmal enger oder weiter gesehen.
cu
willi
tja meistens beziehe ich das auf selbst erstellte Konfigurationen, die eine festgelegte
Namensgebung, IP-Ranges, Domänennamen, IP von Servern.
solche Dinge sollte man vorher festzurren und diskutieren und absegnen, danach sind sie verbindlich dann verändern sich diese elemtaren Dinge nicht mehr.
SPs , Sicherheitsupdates oder ähnliches lande normalerweise im Labor auf den Servern und werden dort durchgestresst, dann in der Echtumgebung angewandt. dabei werden Herstelleraussagen natürlich berücksichtigt.
so ist der Slogan Never touch a running System manchmal enger oder weiter gesehen.
cu
willi
Ich stimme Euch da vollkommen zu, klar hat (fast) jeder schon mal ein System zerschossen, indem er ein Update "zuviel" eingespielt hat - wenn die Struktur stimmt und ein richtiges Sicherungssystem existiert, ist das aber nur "das kleinere Problem",
Gruß
Atti.
Gruß
Atti.
Hi, hat das viel mit Updates zu tun? Ich denke da eher an Neu aufsetzen eines Servers oderso, bzw den Umstieg auf andere Umgebungen.
grüsse GI
grüsse GI
Das Zitat ist unvollständig und wahrscheinlich aus der Signatur eines neueren Mitglieds übernommen.
Da habe ich das sogar als "Never touch a runing system" (mit einem "n" bei "running") gelesen.
Im Original sind es drei Sätze.
Never change a running system.
Never run a changing system.
Change a never running system.
So wird ein Schuh draus.
Grüße
Biber
Da habe ich das sogar als "Never touch a runing system" (mit einem "n" bei "running") gelesen.
Im Original sind es drei Sätze.
Never change a running system.
Never run a changing system.
Change a never running system.
So wird ein Schuh draus.
Grüße
Biber
Das Zitat ist unvollständig und
Es ist aus einem Beitrag raus kopiert.
Aber es ging mir nicht um einen oder meherer User hier.
Es interessiert mich einfach wie das gesehen wird. Ich habe nämlich auch schon Leute gesprochen, die den Spruch auch in Bezug auf Patche sehen.
Das kommt darauf an. Wir hatten hier bis heute morgen ( 
) einen SBS2003-Server am Laufen. Unser Admin (bin sein Praktikant) hat letztes Jahr versucht das SP1 draufzumachen (bevor es das spezielle SP1 gab) und hat dann ein Wochenende und zig Anrufe bei MS zugebracht, das Ding wieder ans Laufen zu bekommen. Es wurden einige inoffizielle Patches eingespielt, damit das Teil wieder hochläuft und er hat es hingekriegt.
Nur seitdem hat er dann auf dieser Maschine wirklich nach dem Grundsatz gehandelt, es war kein SP1 und seit dem Vorfall kein einziger Patch mehr eingespielt worden, weil das Ding lief und so sollte es auch bleiben.
In den letzten Monaten hat sich dann alles recht schnell vergrößert, neue DCs sind dazugekommen, immer mehr Services wurden von der Maschine abgezogen. Nach einiger Zeit waren nur noch Exchange und Fileserver auf dem Rechner.
Heute morgen haben wir dann den vorletzten, aber schwersten Schritt vollzogen: Wir haben das Transition Pack installiert (natürlich Mirroring usw.) und das Ding soweit gepatcht, dass es noch zwei Wochen läuft, bevor die ganzen Mailboxen auch noch auf unserer neuen Exchange-Architektur umgezogen wurden.
Somit hat der Spruch manchmal wirklich seine Berechtigung als absolute Richtlinie
So, das war meine kleine Anekdote (musste ich jetzt mal loswerden nach 6 Stunden harter Umstellungsarbeit).
Allgemein:
Kritische Patches sollten eingespielt werden, aber inzwischen habe ich mir folgende Verhaltensweise angeeignet. Diese werden frühstens zwei Wochen nachdem sie auf dem WSUS auftauchen eingespielt und dann an einem einsamen Tag (Patch-Day) mit vorheriger Komplett-Sicherung und Abschottung des Servers. Ich sehe oft genug wierde rückgeholte Patches im WSUS und hatte damit auch schon einmal ein Problem, als ich einen Patch direkt nach Erscheinen eingespielt habe.
P.S.: Ich glaube, das war jetzt ein wenig ausführlich *g*
) einen SBS2003-Server am Laufen. Unser Admin (bin sein Praktikant) hat letztes Jahr versucht das SP1 draufzumachen (bevor es das spezielle SP1 gab) und hat dann ein Wochenende und zig Anrufe bei MS zugebracht, das Ding wieder ans Laufen zu bekommen. Es wurden einige inoffizielle Patches eingespielt, damit das Teil wieder hochläuft und er hat es hingekriegt.Nur seitdem hat er dann auf dieser Maschine wirklich nach dem Grundsatz gehandelt, es war kein SP1 und seit dem Vorfall kein einziger Patch mehr eingespielt worden, weil das Ding lief und so sollte es auch bleiben.
In den letzten Monaten hat sich dann alles recht schnell vergrößert, neue DCs sind dazugekommen, immer mehr Services wurden von der Maschine abgezogen. Nach einiger Zeit waren nur noch Exchange und Fileserver auf dem Rechner.
Heute morgen haben wir dann den vorletzten, aber schwersten Schritt vollzogen: Wir haben das Transition Pack installiert (natürlich Mirroring usw.) und das Ding soweit gepatcht, dass es noch zwei Wochen läuft, bevor die ganzen Mailboxen auch noch auf unserer neuen Exchange-Architektur umgezogen wurden.
Somit hat der Spruch manchmal wirklich seine Berechtigung als absolute Richtlinie
So, das war meine kleine Anekdote (musste ich jetzt mal loswerden nach 6 Stunden harter Umstellungsarbeit).
Allgemein:
Kritische Patches sollten eingespielt werden, aber inzwischen habe ich mir folgende Verhaltensweise angeeignet. Diese werden frühstens zwei Wochen nachdem sie auf dem WSUS auftauchen eingespielt und dann an einem einsamen Tag (Patch-Day) mit vorheriger Komplett-Sicherung und Abschottung des Servers. Ich sehe oft genug wierde rückgeholte Patches im WSUS und hatte damit auch schon einmal ein Problem, als ich einen Patch direkt nach Erscheinen eingespielt habe.
P.S.: Ich glaube, das war jetzt ein wenig ausführlich *g*
hi
auch nicht schlecht , schlichte sylologische Umformung !
ich las auch mal :
Never touch a ruing system!
cu
willi
auch nicht schlecht , schlichte sylologische Umformung !
ich las auch mal :
Never touch a ruing system!
cu
willi
hi
Umstieg auf andere Systeme sind m.E. die Ausnahme, da sie eine neue Umgebung darstellung mit neuen anderen Features, Technologien. Wenn die fertig ist , gilt meistens
wieder der Slogan.
cu
Umstieg auf andere Systeme sind m.E. die Ausnahme, da sie eine neue Umgebung darstellung mit neuen anderen Features, Technologien. Wenn die fertig ist , gilt meistens
wieder der Slogan.
cu
Ich kenne nur "Touch me" von Samantha Fox...
Es ist bei SPs und Security Patches ne ganz einfache Abwägung der Risiken. Wodurch kann das laufende zeitkritische Projekt oder allgemein die Arbeit heftiger gestört werden - durch einen Wurm, der ein nicht gestopftes kritisches Sicherheitsloch ausnützt, oder durch das Einspielen eines Sicherheitspatches, dass Inkompatibilitäten aufzeigt?
In der Regel spiele ich kritische SecurityPatches sehr schnell auf (1-2 Tage), nachdem ich es auf "unwichtigeren" Servern laufen hab lassen. SecurityPatches die bereits kompromitierte Löcher stopfen (wie z.B. WMF-Bug um diesen Jahreswechsel rum) unverzüglich.
Man muss halt abwägen, wie hoch die Wahrscheinlichkeit ist. Die Security Bulletins geben hier sehr viel Info darüber. Allein durch das Benutzerverhalten sind schon mal einige Security Löcher nicht so kritisch. Weiss man, dass niemand an einem bestimmten Server surft oder Mails liest, ist auch z.B: IE fixen auf nem Server nicht so dringend, dafür aber halt auf der Arbeitsstation. Analog andere applikationsbezogene Bugs. Umgekehrt sind Rechner, die Dienste ins Internet anbieten (Mail, Web, ...) sehr anfällig auf dienstbezogene Bugs.
In der Regel spiele ich kritische SecurityPatches sehr schnell auf (1-2 Tage), nachdem ich es auf "unwichtigeren" Servern laufen hab lassen. SecurityPatches die bereits kompromitierte Löcher stopfen (wie z.B. WMF-Bug um diesen Jahreswechsel rum) unverzüglich.
Man muss halt abwägen, wie hoch die Wahrscheinlichkeit ist. Die Security Bulletins geben hier sehr viel Info darüber. Allein durch das Benutzerverhalten sind schon mal einige Security Löcher nicht so kritisch. Weiss man, dass niemand an einem bestimmten Server surft oder Mails liest, ist auch z.B: IE fixen auf nem Server nicht so dringend, dafür aber halt auf der Arbeitsstation. Analog andere applikationsbezogene Bugs. Umgekehrt sind Rechner, die Dienste ins Internet anbieten (Mail, Web, ...) sehr anfällig auf dienstbezogene Bugs.
...vor mir steht ne Kaffee-Tasse auf der steht:
"Never touch a running Sysop"
...und das ist auch gut so!
"Never touch a running Sysop"
...und das ist auch gut so!
*System never changes running (das System verändert sich nicht beim joggen)
Running change never system (laufende Veränderungen haben kein system...Bush Englisch)
Change System never running (Wechsle das System wenn du zu wenig joggst)
Never run a touching system (Benutze nicht ein grapschendes System)*
Naja, es gibt manchmal schon komplexe Serverkonstellationen, bei denen man (bei unstrukturierter Arbeitsweise) nach heftigem Drehen an den Configs einen funktionierenden Zustand erreicht, und die Mühle macht was sie soll. Je länger die Fummel-Session gedauert hat, und je schlechter man die Fummel-Orgie dokumentiert hat, desto eher tendiert man wohl dazu den Spruch "Never touch a running System" gut zu finden.
Daher stehe ich voll auf Redundanz. Ein Server ist fertig und läuft? Super! Sofort clonen und auf eine zweite Maschine aufspielen, oder gar dritte. An einer der dreien kann man dann immernoch "touchen" wenn man eine neue Funktionalität testen will.
Running change never system (laufende Veränderungen haben kein system...Bush Englisch)
Change System never running (Wechsle das System wenn du zu wenig joggst)
Never run a touching system (Benutze nicht ein grapschendes System)*
Naja, es gibt manchmal schon komplexe Serverkonstellationen, bei denen man (bei unstrukturierter Arbeitsweise) nach heftigem Drehen an den Configs einen funktionierenden Zustand erreicht, und die Mühle macht was sie soll. Je länger die Fummel-Session gedauert hat, und je schlechter man die Fummel-Orgie dokumentiert hat, desto eher tendiert man wohl dazu den Spruch "Never touch a running System" gut zu finden.
Daher stehe ich voll auf Redundanz. Ein Server ist fertig und läuft? Super! Sofort clonen und auf eine zweite Maschine aufspielen, oder gar dritte. An einer der dreien kann man dann immernoch "touchen" wenn man eine neue Funktionalität testen will.
