Zum Inhalt springen

Empfohlene Beiträge

Geschrieben (bearbeitet)

Guten Tag,

Am 20.September beginnt die Abgabefrist für meinen Projektantrag. Ich füge ihn hier ein, in der Hoffnung, etwas Kritik/Feedback und vielleicht die eine oder andere Anregung zu bekommen.

Vielen Dank im Voraus.

 

 

Projektbezeichnung

Installation des Linux-Client-Management-Systems in einer public cloud

 

Projektbeschreibung

Die manuelle Installation und Konfiguration von Linux-Client-Systemen ist zeitaufwendig und komplex. Die Installationstools der verschiedenen Distributionen unterscheiden sich mitunter enorm, von automatisierbaren Installern (Yast, Anaconda, Ubiquity) bis hin zu mehreren Installationsscripten die nacheinander manuell gestartet werden (ArchLinux, Slackware).

Um in Zukunft eine einheitliche Basis für neue Systeme zu gewährleisten und den Installationsprozess zu beschleunigen und zu vereinheitlichen erging der Auftrag, das von der XXXXXXXX ihren Kunden angebotene Linux-Client-Management-System (kurz LCM), basierend auf dem Client-Management-Tool The Foreman, auch für die eigene Infrastruktur zur Verfügung zu stellen.

Zum Projektumfang gehören das Zusammenstellen der Anforderungen an die bereitzustellenden Systeme im Bezug auf Sicherheit, Konfiguration, Einbindung in die bestehende IT-Infrastruktur, Wartbarkeit, Benutzerfreundlichkeit und Ergonomie, die Auswahl der am besten geeigneten Cloudumgebung hinsichtlich angebotener Features, Servicequalität und Wirtschaftlichkeit, sowie die Auswahl der benötigten Managementwerkzeuge und die cloud-basierte Implementierung des LCM.

Da die Entscheidung für eine Lösung in einer public-cloud bereits getroffen wurde um die lokale Netzwerkumgebung am Standort XXXX möglichst nicht zu belasten, muss sorgfältig geplant werden, wie das Client-Management-System in die bestehende Infrastruktur eingebunden werden soll, vor allem in Hinblick auf Verfügbarkeit und Datensicherheit.

Des Weiteren ist zu entscheiden, ob eigene Repositories bzw. Images eingerichtet oder die Onlinerepositories der jeweiligen Distribution verwendet werden sollen.

Die Qualitäts- und Sicherheitskonzepte der XXXXXXXX kommen dabei zur Anwendung.

 

Projektumfeld

Die XXXXXXXX ist ein Linux und Open Source Dienstleister mit etwa 150 Beschäftigten, die überwiegend im Homeoffice arbeiten. Zu den angebotenen Dienstleistungen gehören Consulting, Training, Managed Services, Cloud-Services und Administration on-site und remote. Dies erfolgt über insgesamt fünf Standorte, in XXXX, XXXXXX, XXXXXXX, XXXXX und XXXX.

Die Arbeit im Homeoffice stellt dabei besondere Anforderungen an die IT-Infrastruktur, die Hauptsächlich durch public und private Cloud-Technologien erbracht werden.

 

Ist-Analyse

Installation und Konfiguration eines Linuxclients dauern, je nach Einsatzzweck, 3 bis 20 Stunden. Dabei werden die Systeme individuell angepasst, was einen hohen Dokumentationsaufwand nach sich zieht.

Updates erfolgen ebenfalls manuell, werden derzeit nicht evaluiert und haben unter Umständen ein instabiles bis nicht mehr startendes System zur Folge.

Administrative Eingriffe sowie Änderungen an der Konfiguration müssen mittels VNC oder SSH durchgeführt werden und erfordern oftmals dennoch Eingriffe des lokalen Benutzers, da die Verbindung spätestens beim Neustart des Netzwerkes oder einem Reboot abreist.

 

Soll-Konzept

Durch den Einsatz des Client-Management-Systems sollen Installation, Konfiguration und Benutzermanagement zentralisiert, automatisiert und vereinheitlicht werden, um den Administrationsaufwand zu senken und somit Kapazitäten für die Verkürzung der Reaktionszeit im Support zu erhalten.

Updates sollen zukünftig überprüft und erst nach Freigabe erfolgen und administrative Eingriffe, z. B. nach Änderungen an der Netzwerkinfrastruktur sollen automatisiert werden.

Diese Dienste müssen sowohl an den Standorten als auch im Homeoffice zur Verfügung stehen, was besondere Anforderungen an die IT-Sicherheit stellt.

 

Projektphasen

1. Ermittlung Ist-Zustand (2h)

1.1 Feststellen der aktuell verwendeten Software der Clientsysteme (1h/2h)

1.2 Erfassen der aktuellen Konfiguration der Clientsysteme (1h/2h)

 

2. Erstellung Soll-Konzept (2h)

 

3. Projektvorbereitung (3h)

3.1 Ermitteln der Anforderungen an den Server (1h/3h)

3.2 Auswahl eines geeigneten Cloud-Providers auf Basis einer Nutzwertanalyse (2h/3h)

3.3 Auswahl des Szenarios für die Systemarchitektur: (2h)

3.3.1 Art der VPN-Verbindung (0,5h/2h)

3.3.2 Prüfen der Notwendigkeit eines LCM-Proxy (0,5h/2h)

3.3.3 Auswahl der Provisionierungsmethode (0,5h/2h)

3.3.4 Prüfen, ob eigene Repositories erstellt werden müssen (0,5h/2h)

3.4 Ermitteln der zu provisionierenden Linux-Distributionen anhand einer Nutzwertanalyse (3h)

3.4.1 Erstellen eines Software Kataloges für die Clientsysteme (1h/3h)

3.4.2 Ermitteln der Grundkonfiguration für die Clientsysteme (2h/3h)

3.5 Erstellen eines Testkonzeptes (2h)

3.6 Übergeben der gesammelten Informationen an das LCM-Team (1h)

 

4. Projektdurchführung (11-13h)

4.1 Vorbereiten des Servers und Grundkonfiguration (3h)

4.2 Implementierung des LCM (4h)

4.3 entweder: Erstellen eigener Repositories (3h)

oder: Einbinden der Online-Repositories der verwendeten Distributionen (1h)

4.4 Durchführen der Tests nach dem Testkonzept aus Punkt 3.5 (3h)

4.5 Überprüfung und Härtung des Servers durch das LCM-Team

 

5. Abschließende Tests nach dem Sicherheitskonzept der XXXXXX durch das LCM-Team

 

6. Projektabschluß (10h)

6.1 Erstellen der Projektdokumentation (9h)

6.2 Soll- und Ist-Vergleich (1h)

6.3 Projektübergabe (2h)

 

Dokumentation:

Pflichtenheft

Projektdokumentation

Benutzerhandbuch

Tabellen zur Nutzwert-/ Wirtschaftlichkeitsanalyse

Abschließender Soll- und Ist-Vergleich

 

 

Bearbeitet von mapr
Geschrieben
vor 57 Minuten schrieb myself999:

Zum Projektumfang gehören das Zusammenstellen der Anforderungen an die bereitzustellenden Systeme im Bezug auf Sicherheit, Konfiguration, Einbindung in die bestehende IT-Infrastruktur, Wartbarkeit, Benutzerfreundlichkeit und Ergonomie, die Auswahl der am besten geeigneten Cloudumgebung hinsichtlich angebotener Features, Servicequalität und Wirtschaftlichkeit, sowie die Auswahl der benötigten Managementwerkzeuge und die cloud-basierte Implementierung des LCM.

Datenschutz als Kriterium ist nicht drin. Bitte aufnehmen und hinreichend (!) beleuchten oder Finger weg von Public Cloud!

Wenn euer (e)DSB hier "Verantwortlich" ist reicht diese Aussage aber nicht aus! Du wirst zu 99% dazu befragt und das Gespräch darüber kann, je nach PA, sehr tiefgründig werden.

@charmanta kann dir da deutlich mehr hinweise geben als ich es könnte. Anders gesagt: Aufgrund diese Themas werden dir viele dazu abraten. Wenn du keine Angst vor diesem Thema hast - nur zu! Ansonsten ist es inhaltlich(-technisch) sehr spannend.

Ich persönlich würde es genehmigen. Nur mit den Zeiten musst du schauen. Siehe weiter unten.

vor 59 Minuten schrieb myself999:

basierend auf dem Client-Management-Tool The Foreman,

The Foreman steht feste, aber durch die Cloud-Infrastrutkurentscheidung hast du ja eine Betrachtung inbegriffen.

vor einer Stunde schrieb myself999:

(1h/2h)

Das soll das 1h/2h bedeuten? Entweder-/oder?

Bei der Auswahlgeschichte lieber mehr als zu wenig.

Kriterien, insbesondere der angesprochene Datenschutz (welcher noch nicht benannt wurde),
insoweit aufnehmen das diese auch betrachtet werden.

Aus der späteren Dokumentation sollte im Definitionsteil (SOLL-Konzept) die Kriterien definiert werden:

vor einer Stunde schrieb myself999:

2. Erstellung Soll-Konzept (2h)

Da sind 2h sehr knapp. Dieser Kriterienkatalog ist wichtig und definiert hier deine Abnahmekriterien.
Hierrein gehören neben den Orgasachen (Kostenrahmen, Zeitrahmen, Datenschutz....) auch die Definition von Tests technischer Natur. Wer hier, ohne eine Lösung vorher ausgewählt zu haben, schon klar hat was getestet werden muss hat (bei uns) schon die halbe Miete weil wir herauslesen das jemand eben nicht nur testet was seine Lösung kann sondern Lösungsunabhängig die Funktionalität(en) überprüft.

  • mapr änderte den Titel in Projektantrag: Installation des Linux-Client-Management-Systems in einer public cloud
Geschrieben
Am 6.9.2023 um 14:58 schrieb myself999:

erging der Auftrag, das von der XXXXXXXX ihren Kunden angebotene Linux-Client-Management-System (kurz LCM), basierend auf dem Client-Management-Tool The Foreman, auch für die eigene Infrastruktur zur Verfügung zu stellen.

Wo bleibt denn Deine Entscheidung wenn Foreman vorgegeben ist ?

Du wählst nur noch Cloud und Methode aus, aber nicht die Lösung selbst ?

Das Datenschutzthema kommt noch on top, ist aber sekundär. Mit fehlt die Entscheidung

Geschrieben
vor einer Stunde schrieb charmanta:

Du wählst nur noch Cloud und Methode aus, aber nicht die Lösung selbst ?

[....]Mit fehlt die Entscheidung

Mir persönlich reicht die Cloud-/Infrastrukturentscheidung da sie ja sehr "schwerwiegend" für Folgeprojekte sein wird. Man wird ja dann für andere Server nicht einen anderen Cloudanbieter wählen.... ;)

Vielleicht bekommen wir ja noch eine dritte Meinung. @skylake , @JMilanese, @Maniska?

Geschrieben

Ja, schwierig das Ganze.

Ich schwanke noch etwas, eb die Entscheidung Cloud/Infrastruktur ausreichend ist. Ausmeiner Sicht gerade so genehmigungsfähig, aber man kann ja aufbessern :-):

Nimm Datenschutz mit rein (der Punkt fehlte mir auch, ist aber zwingend wegen Cloud und Co.) und betrachte trotzdem noch Alternativen zu Foreman mit Vor- und Nachteilen. Es sit ja nicht Dein fehler, wenn Deine Analyse etwas anders ergibt, was der Kunde/ das Umfeld dann anders entscheidet. Oder Foreman ist wirklich das beste Tool :-)

Geschrieben
vor 5 Minuten schrieb JMilanese:

Ich schwanke noch etwas, eb die Entscheidung Cloud/Infrastruktur ausreichend ist. Ausmeiner Sicht gerade so genehmigungsfähig, aber man kann ja aufbessern 🙂

Ich weiß nicht, ich tendiere eher zu "wenn nur der Cloudanbieter noch zur Debatte steht reicht mir das nicht".

Warum die Entscheidung "OnPrem vs. Cloud" nicht innerhalb des Projektes treffen/begründen? Deine Aufgabe ist ja, die für diesen Kunden technisch beste Alternative zu finden.

vor 5 Minuten schrieb JMilanese:

Nimm Datenschutz mit rein (der Punkt fehlte mir auch, ist aber zwingend wegen Cloud und Co.) und betrachte trotzdem noch Alternativen zu Foreman mit Vor- und Nachteilen. Es sit ja nicht Dein fehler, wenn Deine Analyse etwas anders ergibt, was der Kunde/ das Umfeld dann anders entscheidet. Oder Foreman ist wirklich das beste Tool 🙂

Wenn Lösungsansatz A technisch gesehen - für sich alleine gestellt - besser ist, Lösungsansatz B technisch am Besten passt, der Kunde aber "Kraft Krawatte" - weil ihm die Farbe von C besser gefällt - sich für Lösung C entscheidet, dann ist das so. Du musst aber A, B und C vergleichen und Evaluieren.

 

Dadurch dass sowohl Technologie (Cloud) als auch Software (Foreman) vorgegeben sind ist der Antrag in der vorliegenden Form für mich nicht genehmigungsfähig. Das wäre aber durch ein bisschen umformulieren zu ändern, das Thema selbst gibt es auf jeden Fall her.

Geschrieben

Vielen Dank für das Feedback.

Ja, der Datenschutz muss mit rein. Ich denke werds drauf ankommen lassen und mich entsprechend fürs Fachgespräch drauf vorbereiten.

Alternativen zum Foreman gibts da nicht so viele, zumindest nicht Free & OpenSource. Entscheidungen gibts an anderer Stelle, z.B. Provisionierung über DHCP-Boot oder PXE-Boot, Auswahl der passenden Architektur - Layer 2 VPN vs. Layer 3 VPN, mit oder ohne Foreman-Proxy im lokalen Netz und dann die Entscheidung für den Cloud-Provider. Und passende Linuxdistros (2 oder 3 verschiedene zur Auswahl) müssen ebenfalls ausgewählt werden. Ich könnte das versuchen besser herauszuarbeiten, wäre das evtl. eine Möglichkeit? Eine weitere Entscheidung wäre noch das Konfig-Management-Tool, Puppet vs. Salt vs. Ansible, das könnte ich noch mit reinnehmen, Foreman ist ja "nur" der Überbau dazu.

 

Am 6.9.2023 um 16:04 schrieb ickevondepinguin:

Das soll das 1h/2h bedeuten? Entweder-/oder?

Die Angaben (1h/2h) beziehen sich jeweils auf den Oberpunkt, also zu lesen als "1 von 2 Stunden". Ich werds ändern.

 

 

Am 6.9.2023 um 16:04 schrieb ickevondepinguin:

Da sind 2h sehr knapp. Dieser Kriterienkatalog ist wichtig und definiert hier deine Abnahmekriterien.
Hierrein gehören neben den Orgasachen (Kostenrahmen, Zeitrahmen, Datenschutz....) auch die Definition von Tests technischer Natur. Wer hier, ohne eine Lösung vorher ausgewählt zu haben, schon klar hat was getestet werden muss hat (bei uns) schon die halbe Miete weil wir herauslesen das jemand eben nicht nur testet was seine Lösung kann sondern Lösungsunabhängig die Funktionalität(en) überprüft.

Die Erstellung des Testkonzeptes habe ich als Punkt 3.5 mit 2 Stunden unter Projektvorbereitung, das Soll-Konzept als Punkt 2. Ich verstehe ihren Einwand, ich werde das Testkonzept direkt unters Soll-Konzept schieben, als eigenen Punkt VOR der Projektvorbereitung.

 

Würden diese Änderungen ausreichen? Ansonsten werde ich halt doch Alternativen vergleichen, wird dann so wie JMilanese geschrieben hat:

vor einer Stunde schrieb JMilanese:

Ja, schwierig das Ganze.

Ich schwanke noch etwas, eb die Entscheidung Cloud/Infrastruktur ausreichend ist. Ausmeiner Sicht gerade so genehmigungsfähig, aber man kann ja aufbessern :-):

Nimm Datenschutz mit rein (der Punkt fehlte mir auch, ist aber zwingend wegen Cloud und Co.) und betrachte trotzdem noch Alternativen zu Foreman mit Vor- und Nachteilen. Es sit ja nicht Dein fehler, wenn Deine Analyse etwas anders ergibt, was der Kunde/ das Umfeld dann anders entscheidet. Oder Foreman ist wirklich das beste Tool 🙂

 

Geschrieben
vor 2 Minuten schrieb myself999:

Alternativen zum Foreman gibts da nicht so viele, zumindest nicht Free & OpenSource.

Alternativen gibt es immer, auch kostenpflichtige wären interessant für einen Vergleich. Kosten ist ja nicht das einzige, sondern auch Kosten-/Nutzen. Da können kostenpflichtige Produkte durchaus schon besser sein als OpenSource-Produkte.

Geschrieben
vor 6 Minuten schrieb myself999:

Alternativen zum Foreman gibts da nicht so viele, zumindest nicht Free & OpenSource.

Nur weil es kein Geld kostet ist nicht zwangsläufig günstiger als Bezahlsoftware.

Support and Maintenance ist ein Punkt, Reaktionszeiten des Supports, Schließen von Sicherheitslücken...

Alleine schon die Tatsache dass man im Fehlerfall einen Ansprechpartner hat der innerhalb festgelegter Zeiten helfen kommt und auch das KnowHow dazu hat vs "Chef steht mir im Nacken während ich Infos selber zusammen googlen muss"...

Die Rechnung "was kostet der Support und wie lange darf System XX ausfallen bis die Kosten für den Ausfall die Kosten für den Supportvertrag übersteigen" darf man nie unterschätzen.

 

Hier auch gerne den Punkt "wenn ein offen im Internet stehender Service angreifbar ist, welchen Schaden kann das verursachen". Einerseits wenn eure Installationen dann kompromittiert sein könnten (Zeitaufwand für alles einsammeln und neu machen), andererseits auch der Reputationsverlust durch einen IT-Sicherheitsvorfall.

Geschrieben

Ja dann...

Wenn ich das Alles so lasse wie es ist und eine Gegenüberstellung von versch. Client-Management / Lifecycle-Management-Lösungen mit reinnehme sprengt es den zeitlichen Rahmen, mit Recherche usw. würde ich da min. 5h veranschlagen.

Ich könnte aber aus der Not eine Tugend machen und anstatt in der public-cloud auf dem VM-Host im Firmennetz installieren. Dadurch würde ich Zeit sparen und bin das Thema Datenschutz zumindest auf meiner Seite im Projekt los.

Abspecken könnte ich auch noch auf der Client-Seite, ich vergleiche keine Distributionen sondern entscheide einfach für eine Distro aus dem Debian-, eine aus dem Red Hat-Universum und OpenSuse. Zum Beispiel Ubuntu, Fedora und Leap.

Diese Änderungen nehmen zwar viel vom Reiz des Projekts, aber damit fahre ich vermutlich besser und sicherer.

Was meinen Sie dazu?

PS: Eine Schutzbedarfsanalyse kommt mit rein. Die fällt dann natürlich auch anders aus.

Geschrieben
Am 9.9.2023 um 15:36 schrieb myself999:

Ja dann...

Wenn ich das Alles so lasse wie es ist und eine Gegenüberstellung von versch. Client-Management / Lifecycle-Management-Lösungen mit reinnehme sprengt es den zeitlichen Rahmen, mit Recherche usw. würde ich da min. 5h veranschlagen.

Ich könnte aber aus der Not eine Tugend machen und anstatt in der public-cloud auf dem VM-Host im Firmennetz installieren. Dadurch würde ich Zeit sparen und bin das Thema Datenschutz zumindest auf meiner Seite im Projekt los.

Noch weniger Recherche und Alternativen-Vergleich und noch mehr gesetzte Parameter und Entscheidungen machen das projekt aus Prüfungssicht nicht unbedigt besser.

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...