Guten Tag,
Eigenartige Bemerkung. Auch wenn du den Namen beim Quoten weggeschnitten hast, kannst du erkennen, dass ich mich (nur) auf Ulrich bezog. Was dir schon bekannt ist, kann ich nicht wissen und ist in diesem Zusammenhang unerheblich.
na, wer wird denn da gleich patzig werden? :-) Nimms locker, das macht das Leben s��er.
Statt das ich drauf eingehe, ob du verstanden hast was ich will oder nicht, erkl�r ich es mal vom Grund her: Es gibt bei uns einige Rechner,Ich verstehe dich nicht. Du willst ein Disaster-Recovery-Konzept mit nicht tagesaktueller vollst�ndiger Systemsicherung (wie auch immer), sondern ein zweistufiges Konzept: Grundinstallation + zus�tzliche Wiederherstellung des aktuellen Konfigurationsstandes, worunter auch die letzten Securityupdates fallen. Verstehe ich dich falsch?Nur, dass sich --get-selections wieder nur in eigenen Scripten einsetzen l�sst und wieder voraussetzt, dass man bereits mindestens ein Mini Debian System aufgesetzt hat, was ggf. schon mehr enth�lt, als man wirklich haben will.
die in relativ spezieller Konfiguration aufgesetzt werden, sowohl
in Hinsicht auf die Paketauswahl, als auch in Hinsicht auf die Software
und ggf. zus�tzlichen Elementen die dann letzten Endes irgendeine - ich nenn es mal - Solution ergeben. Nun gibt es nat�rlich grunds�tzlich die M�glichkeit ein Image der Platte zu ziehen, als Backup, nachdem das System aufgesetzt wurde. Nur was ist nun, wenn die Festplatte irgendwann
mal unerwartet die Gr�tsche macht und keine identische Festplatte auf
Lager ist, dass System aber hochverf�gbar sein muss, sprich m�glichst
innerhalb der n�chsten 20 Minuten wieder laufen soll (auch wenn das
in Hinsicht auf Security Updates, die in einem Installationsarchiv
nicht enthalten sein *k�nnen* nat�rlich nur bedingt realisierbar ist)?
Das Ziel, dass erreicht werden soll ist also ein Installationsarchiv
zu schaffen, dass sowohl relativ portabel ist (nat�rlich mit Einschr�nkungen! Ich kann ja kein Installationsarchiv f�r einen Server
bauen mit nem Pentium 2 Prozessor drin um es dann so exakt auf einer
UltraSparc einzusetzen) als auch vollst�ndig, als auch anpassbar,
wenn sich beispielsweise die IP des Rechners beim Neuaufsetzen �ndert,
wegen infrastruktureller �nderungen. Der andere Punkt ist: Beim
Neuaufsetzen, soll m�glichst wenig getan werden, insbesondere dann
wenn sich nichts �ndert, also am besten: Diskette einlegen, Netzwerkkabel einstecken und ab daf�r, Kaffee trinken gehen und
wenn ich wieder da bin, kann das System wieder produktiv sein.
Das was wir bisher einsetzen (ein selbstgebautes Script), lie�e sich nat�rlich weiterverwenden, wenn man davon absieht, dass es urspr�nglich
f�r SuSE Systeme gebaut wurde, die Packetmanageraufrufe also
rpm-spezifisch sind. Das Problem an der bisherigen L�sung ist jedoch,
dass es aufwendig ist, dass Installationsarchiv zu erstellen und
trotzdem noch verh�ltnism��ig Vorarbeit anf�llt wenn ein Rechner
neu aufgesetzt werden soll. Bei den SuSE Kisten war das eben
1. SuSE Minimalinstallation 2. Archiv auf das System laden
3. Script starten. Der Idealfall der erzielt werden soll, ist aber
dass Punkt 1 -3 in einen Schritt zusammengefasst werden sollen.
Meine Erw�gungen dahingehend sind es mittlerweile wirklich das alte System anzupassen, allerdings um eine bootf�hige Diskette zu erg�nzen, die das Minimalsystem vielleicht mit einem abgespeckten Base-System bootstrapt und dann das Script laufen l�sst. Dachte halt nur, dass es eventuell eine L�sung wie wir sie brauchen zumindest in den Grundz�gen bereits gibt.
Es gr�sst und w�nscht noch einen sch�nen Tag
Patrick -- IN MEDIAS RES -=Operations=-
tel. +49 (0) 2166 - 99 99 - 685 fax. +49 (0) 2166 - 99 99 - 850
email: [EMAIL PROTECTED] web: www.in-medias-res.com
--
Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
