Erste Projektidee: Patch-Management für Solaris

[lordy]

Hallo,

evtl. hat jemand meinen vorheringen Thread schon gelesen, ich möchte nächstes Jahr als Berufserfahrener meinen FiSi machen.

Anfang Januar werde ich von der IHK Frankfurt erfahren, ob Sie mich zulassen (davon gehe ich im Moment aus), allerdings endet die Abgabefrist für den Projektantrag schon am 31. Januar.

Deshalb habe ich "jetzt schon" angefangen, ein paar Ideen zu sammeln, was man als Projekt machen könnte. Mein Favorit ist dabei aktuell "Patch-Management für Solaris".

Grob zusammengefasst würde mein Projekt folgendes enthalten:

- Aufbau eines zentralen Patch-Repository (inkl. z.b. automatischem Download neuer Patches von Sun)

- Erfassen des aktuellen Status (welche Server haben welche Patches)

- Scripte schreiben zum Verteilen und Auslesen von Patch-Paketen

- Funktionalität zum "Bündeln" von Patches (Oracle setzt z.B. mehrere Patches vorraus, diese könnte man in ein Oracle-Version-X Cluster packen und so die Suche ersparen)

- Handling der verschiedenen Patches für verschiedene Solaris-Versionen

Was haltet Ihr ganz grundsätzlich von dieser Idee ?

Ach, noch eine Frage zum Ablauf: Muß mein Projekt dann zwingend in die "Produktion" gehen oder ist es ausreichend wenn ich sage, das ich das in unserem Labor aufgebaut habe, und die Implementation im gesamten Rechenzentrum geplant ist (würde bei 100+ Servern eh den Rahmen sprengen).

Über Antworten freue ich mich wie immer

Guten Rutsch wünscht,

Lordy

[charmanta]

GRUNDSÄTZLICH ist das zwar ein Praxisthema ( wenn auch nicht mehr lange, siehe Sol 10 und fortgeschrittene Administration ) ... aber als Abschlussthema für nen FiSi sehe ich dort mehrere Probleme. Du musst ein wenig programmieren bzw. scripten, evaluierst nichts und Du benötigst einen PA mit entsprechendem Spezialwissen. Ich würde eher dazu neigen, das Thema als Evaluation unterschiedlicher Managementoptionen zu bearbeiten. So (wenig drüber nachgedacht) Einsatz von RSC und einem lokalen Patchserver contra Updatepolitik von Sol 10 contra Erstellen eigener "Patchcluster bzw. Recommended Patches" contra kostenpflichtiger Software contra Softwaremanagement im Rahmen des Sun Service. Das alles beleuchten, entscheiden und begründen. Aber das Problem des Expertenwissens beim PA bleibt.

Guten Rutsch und noch ein paar mehr Posts zu Deiner Idee wünscht Charmanta

[Gast Robert M. Albrecht]

Hallo,

ich halte die Idee für ziemlich gut und habe sie selber (für Linux) auch schon vorgeschlagen http://www.pruefungsausschuss.de/ProjektThemen.shtml .

> Muß mein Projekt dann zwingend in die "Produktion" gehen

Nein, dann ist es halt eine Machbarkeitsstudie oder ein Prototyp. Das dürfte den Zeitrahmen wohl auch sprengen.

> evaluierst nichts

Warum ? Man kann sich doch kurz auf dem Markt umschauen und sehen, was es (auch nicht) gibt und was diese Lösungen kosten oder (nicht) können. Wenn man es selber machen möchte, scheint es keine bezahlbare oder brauchbare Lösung zu geben.

> und Du benötigst einen PA mit entsprechendem Spezialwissen

Das ist kein Problem, und wenn nicht daß es PAs vor Ort. Ich kann doch dem Prüfling kein Thema verbieten, weil ich das Thema nicht beherrsche. Wenn der Betrieb / Kunde das fordert, muss sich der PA danach richten.

Auf jeden Fall würde mich die Doku (auch vorher schon) interessieren, da ich das Thema (allgemein für Unix) persönlich spannend finde.

MfG

Robert M. Albrecht

[timmi-bonn]

> evaluierst nichts

Warum ? Man kann sich doch kurz auf dem Markt umschauen und sehen, was es (auch nicht) gibt und was diese Lösungen kosten oder (nicht) können. Wenn man es selber machen möchte, scheint es keine bezahlbare oder brauchbare Lösung zu geben.

Laaaangsam... Evaluieren heisst nicht, "kurz auf dem Markt umschauen und sehen, was es (...) gibt und was diese Lösungen kosten oder (...) können." Denn "wenn man es selber machen möchte, scheint es keine bezahlbare oder brauchbare Lösung zu geben" ist schlichtweg eine falsche Schlussfolgerung. Wäre dem so, dann würde keine vernünftige Firma (mehr) abwägen, ob kaufen nicht vielleicht doch günstiger wäre als selbst machen.

Du musst schon plausibel nachweisen, dass die von Dir gewählte Lösng günstiger ist, als die übrigen infrage kommenden. Das gilt auch für verschiedene Lösungsansätze, die Du selbst durchführst!

gruss, timmi

PS: Trage doch bitte mal deinen Wohnort (IHK) ins Profil ein.

[Gast Robert M. Albrecht]

Hallo,

> Du musst schon plausibel nachweisen, dass die von Dir gewählte Lösng

> günstiger ist, als die übrigen infrage kommenden.

Der Satelite-Server von Redhat (patcht Linux und Solaris) kostet 9000€ pro Jahr für die Software und 400€ bis 1000€ (ja nach Clients-OS) pro zu patchendem System pro Jahr dazu.

Macht bei 100 Unixen (ist in etwa das, was wir haben) 9000€+40.000€ also knapp 50.000€ pro Jahr für die Software, plus die Stunden zur Administration (live geraten 0,25 FTE/Vollzeitkraft = 20.000€).

Für 70.000€ Jahreskosten kann jemand eine Menge programmieren.

Fertig ist die Evaluation in Kurzform. Als Auslöser für ein Projekt reicht das.

Damit hat man seine Kosten/Nutzenanalyse schon quasi fertig; dann holt man sich noch ein Angebot von Redhat ein (um die Preise zu belegen) und macht einen eigenen Projektplan um seine Stunden zur Entwicklung/Betrieb abschätzen zu können. Geritzt. 1-2 Seiten Text und zwei Stunden Arbeit.

Zum Schluss kommt noch mal eine kurze Abschlussbetrachtung (1-2 Absätze), ob die Annahmen (geschätzter Entwicklungsaufwand etc.) von vorne auch so eingetreten sind.

Wenn es ein externer Kunde war, kommt noch die Rechnung in die Doku. Wenn es ein interner Kunde war, wird es irgendeine andere Form des Stundennachweises geben.

MfG

Robert M. Albrecht

http://www.pruefungsausschuss.de/

[timmi-bonn]

Der Satelite-Server von Redhat [...] Fertig ist die Evaluation in Kurzform.

Falscher Ansatz.

gruss, timmi