Re: Serverumzug und Debian
Jakob Lenfers schrieb:
Ack, das ist vollkommen richtig. Aber wir reden beide von einem
"guten Admin" und der hat dann IMHO sich zu informieren. Natürlich
weiß man nicht alles, aber man sollte fähig sein diese Informationen
zu finden.
Das ist natürlich wahr. Einige der wichtigsten Werkzeuge sind IMHO eine
stabile Netzanbindung und ein guter Browser. Und wenn Zeit ein Faktor
ist, bietet sich bisweilen an, nach fertigen Problemlösungen zu suchen
anstatt erst eine eigene zu stricken. Wozu das Rad mehrfach erfinden,
wenn vermutlich andere exakt dasselbe Problem längst gelöst haben?
Später kann man dann immer noch zu Übungszwecken eigene Ansätze
weiterverfolgen.
Patches, Updates, etc gibts bei Sarge (die Lösung die im
Ursprungsposting genannt wurde) auch nicht. Da ist man besser
dran, wenn man sich über Fehler in den gebackporteten Paketen
informiert und dann halt entsprechend reagiert.
D'accord; so würde ich es auch handhaben.
Ich schrieb doch "vorher testen". In welchem Maße hängt vom
Anwendungsgebiet ab, ich habe keine Ahnung was für Anforderungen ein
ISP-Verein hat.
Wenn er es ernst meint, hohe. In Bezug auf Redundanz und Verfügbarkeit,
z. B. Es wird wohl mehr oder minder darum gehen, anvertraute Sites am
Netz zu halten. An sich sollte es da keinen Unterschied zwischen einer
privaten Website und der eines Unternehmens geben, technisch gesehen.
Ich weiß nicht. Ich weiß wirklich nicht. Selbstüberschätzung von daran
Beteiligten hat schon so manches große Projekt zu Fall gebracht. Und die
obigen Worte klingen in meinen Ohren fatal nach "das mach ich mal eben".
Das soll vorallem so klingen wie "wir merken, dass die neue Software
(fast) nicht nötig ist".
Oh, okay. Naja, man überlegt sich immerhin gerne, ob der Aufwand nötig
ist, wenn er einem weh tut. :)
Auf diese Wortwahl ("mal eben schnell") reagiere ich inzwischen
allergisch, denn erfahrungsgemäß kosten Hauruckaktionen ähnlicher Art
insgesamt weitaus mehr Zeit, als sie im Vorfeld angeblich einsparen.
Das kann dann aber geplante Arbeit sein, nicht als wenn es dann in
Sarge Sicherheitslücken gibt, die nicht schnell geschlossen werden
oder man sein SuSE dist-updaten will.
Wobei man für Sarge auch Szenarios entwerfen könnte: Wie reagieren wir
auf bekanntwerdende Lücken? Wie stopfen wir sie? - Allerdings möchte
ich den Job dann nicht unbedingt ausüben müssen.
Nicht zuletzt: was ist, wenn selbst Unstable nicht ausreicht? Schon
mal versucht, die Upstream-Sourcen von PHP 5 als *.debs in Woody zu
integrieren, inklusive oci8, aktueller GD-lib und dem sonstigen
Geraffel? - Zeitvorgabe: 8 h mit Doku. Bitte HowTo an mich. :)
Das ist in der Tat viel Arbeit, aber wenn es nicht in unstable liegt,
wird es auch nicht in Sarge oder in SuSE 9 sein. Mit PHP hast Du Dir
natürlich ein böses Beispiel ausgesucht. :-)
Hehe. Zum Glück kann ich bisweilen sagen: "Das gibt's nicht, basta."
SuSE ist aber, meine ich, ein wenig weiter vorn dabei als unstable,
oder irre ich da? Mir wäre es oft lieber gewesen, sie würden ihre
Releases gründlicher testen, anstatt auf einem 3-Monats-Zyklus zu
beharren.
Nichts für ungut,
Hätte ich "no offense meant" hinzufügen sollen? War nicht als Flame
gemeint.
--
Viele Grüße, Kai
Reply to: