Alternative zu opsi

[binarbeiten]

Hallo,

ich hoffe ich habe die Frage in dieses Forum richtig eingeordnet.

Ich suche aktuell nach einer open-source Alternative für opsi. Opsi ist zu langsam bzw. zu eingestaubt, und wird von meinem Arbeitgeber gewünscht zu umgehen. Opsi haben wir lange genutzt sind, jedoch nicht überzeugt.
Die gewünschten Funktionen sind das starten und herunterfahren von mehreren PC aus der Ferne, so wie deren Zustand abzufragen.
Eine Inventurübersicht so wie Möglichkeit für eine Softwareverteilung wäre schön.

Ich habe danach schon gesucht, finde jedoch entweder keine echten Alternativen, oder keine open-source Versionen oder nichts für Windows und Linux.

Würde mich über Hilfe freuen - Danke

 

[madmax2010]

Was spricht gegen Puppet oder oder Ansible?

 

[binarbeiten]

Ansible ist nicht open-source, zumindest nicht wenn ich Papa Google frage.

 

[PHuV]

Hatte ich auch schon überlegt, wobei Ansible für Windows eher mäh, sprich ungenügend ist.

Beides ist nicht open-source, zumindest nicht wenn ich Papa Google frage

Natürlich ist das OS Software.
https://de.wikipedia.org/wiki/Ansible

Ansible ist ein Open-Source Automatisierungs-Werkzeug zur Orchestrierung und allgemeinen Konfiguration und Administration von Computern.

https://de.wikipedia.org/wiki/Puppet_(Software)

Puppet ist Open Source und prinzipiell plattformübergreifend

 

[madmax2010]

https://puppet.com/
https://www.ansible.com/

Beides ist nicht open-source, zumindest nicht wenn ich Papa Google frage

schau auf die Website.

Ok, wie genau hast du gegoogled, dass da kein Open source raus kam?

 

[konkretor]

@madmax2010
Naja die Enterprise Varianten sind halt nicht umsonst. Ich vermute es geht in diese Richtung.


Also das habe ich mal gelesen das hier Opsi etwas entgegen kommt.

https://ocsinventory-ng.org/?lang=en

Ich habe Jahrelang Opsi genutzt und ehrlich gesagt waren die Themen starten und stoppen oft beim Client zu suchen. Gerade wenn du keine Rechner von der Stange kaufst wie Dell/HP/Lenovo hast oft Probleme. Oft war auch das Netzwerk ein Problem da hier oft das Magic Paket vom Opsi Server "verschluckt" wurde.
Der TE hat ja nicht mal geschrieben welche Version er einsetzt.


Ansonsten kann ich dir Empfehlen deine Probleme hier mal anzusprechen gegen Geld.

https://www.uib.de/de/support-schulung/preislisten-support

Da gabs immer eine Lösung für meine Probleme.

Edit:

Wenn es nur um WOL geht kannst ja mal das als Alternative ausprobieren ob die Probleme dann weg sind.
https://oette.wordpress.com/wol2/

 

[binarbeiten]

Entschuldigt, habs über die Webseiten angeschaut, und ihr habt recht. Das unterstreicht am besten die Aussage, dass man nicht alles glauben soll was man im Internet findet :/

Puppet sieht schon vielversprechend aus, vielen Dank.

 

[Grugeschu]

Die Frage ist doch darf es auch closed Source sein im Deploymentbereich von Windows?

Was ist die Anforderung bei Linux?
RHEL SLES oder Ubu....ih git
Geht es um Verteilung von Software oder OS-Installation bei Linux?
OS Deployment bei Windows oder nur Softwareverteilung?

Wie viele Clients und welches Budget ungefähr.

 

[Skysnake]

Was willst/musst du denn genau machen?

Gibt ja auch so Sachen wie Cluster shell oder IPMI Abstraktionen um größere Gruppen von Systemen zu verwalten.

 

[Snakeeater]

Ich weiß nicht ob ich mich hiermal einklinken darf, wird sind in der neuen Firma ebenfalls auf der Suche nach einer Client Management Lösung. Und mir wurde aufgetragen mich mal in Ansible bzw. Puppet einzulesen. Nur bin ich nach anfänglicher Recherche noch nicht wirklich zu einem Schluss gekommen.

Unsere Anforderungen wären voderrangig:

• Verwaltung von Clients Windows (80%), MacOS (10%) und Linux (10%)
• Ausrollen von Betriebsystemen
• Konfiguration
• Deployen von Software/Updates aus der Ferne
• (Inventarierung ?)

Was ich bisher gelesen habe Sprach davon das die Einrichtung von Ansible sich einfacher gestaltet als Puppet. Je komplexe die IT-Struktur, desto schwieriger wird es aber wohl mit Ansible dem gerecht zu werden.

Mein Kollege ist der Meinung das Ansible ein Problem macht, da eine ständige SSH Verbindung notwendig ist damit der Ansible Server Zugriff auf die Clients hat (Push). Im Gegensatz zum Puppet Verfahren das mit lokalen Diensten/Clients den Server kontaktiert (Pull).

Aus meiner Perspektive macht das wenig Unterschied da die Anforderung spezielle Software nachzujustieren auf Homeoffice Geräten eine absolute Ausnahme darstellt. Vielleicht verstehe ich die Problematik aber auch nicht vollends.

Hat hier jemand Erfahrungen und kann mir Tipps geben wo ich mich sonst noch umschauen sollte (alternativ Software). Falls ich stattdessen einen eigenen Thread eröffnen sollte, kann ich das natürlich machen.

 

[LasseSamenström]

Unsere Anforderungen wären voderrangig:

• Verwaltung von Clients Windows (80%), MacOS (10%) und Linux (10%)
• Ausrollen von Betriebsystemen
• Konfiguration
• Deployen von Software/Updates aus der Ferne
• (Inventarierung ?)

Von wie vielen Clients ist überhaupt die Rede? Wie viele werden pro Tag/Monat deployed?

 

[Snakeeater]

30-40 bisher. Momentan so 3-4 pro Monat. Sollte sich aber bald deutlich legen. Geht hauptsächlich auch um die Konfiguration und das Deployen von Updates einheitlich auf allen Systemen.

 

[Nightmar17]

Ich lese mal mit, weil ich Opsi eigentlich bei uns einführen wollte.
Die anderen Tools habe ich mir mal angeguckt, aber tatsächlich sagt mir Opsi aktuell am meisten zu.
Damit will ich an sich nur Clients pflegen und 3-4 Programme die auf den Geräten sind überwachen und patchen. Mehr läuft auf den PCs sind.

Schade das es keine Windows Lösungen gibt, die auf einem Windows Server laufen und Windows + Linux (Ubuntu) managen können.

 

[Snakeeater]

Ich bin gerade im Prozess Ansible aufzusetzen, ist aber leider alles andere als einfach. Da der ursprüngliche Server, auf dem ich es installiert habe nicht im internen Netz liegt und unsere AD nicht von außen erreichbar ist.

Ich probier es jetzt über eine interne VM.

 

[ManU--]

Ich schließe mich hier einfach mal mit an.
Stehe vor dem selben "Problem".

Bin für meine Firma ebenfalls auf der Suche nach einer Lösung.

• Ticketsystem
• Inventarisierung
• OS Deployment
• Software Deployment
• (Software-Kiosk)
• Verwaltete Clients: ~120, ausschließlich Windows-Clients
• Bei der zu verteilenden Software dreht es sich um Standard-Software. Das meiste konnte ich in einer OPSI Testumgebung mit wenigen Mausklicks bereits erfolgreich testen.

Habe mir bereits Lösungen von Matrix 42 und Baramundi angesehen. Kosten natürlich...
Ich könnte auch damit leben 2 Lösungen einzuführen. Einmal für Ticketsystem + Inventarisierung z.B. GLPI o.ä. und fürs Deployment habe ich mir OPSI angesehen.

Fande OPSI auch sehr altmodisch vom "aussehen" und auch von der Bedienung. Auch ich fande es teilweise etwas träge. Jedoch hat es in meinen ersten Tests gut funktioniert und ich bin da auch schnell rein gekommen. Leider basiert OPSI ja komplett auf Java und installiert OpenJDK mit. Ist das nicht wieder ein Sicherheitsrisiko, oder sehe ich das falsch? Wie seht ihr das?

Puppet und Ansible sagen mir als überwiegend Windows-Administrator eher weniger. Gibt es da irgendwelche guten Tutorials von der Installation, bis hin zum ersten Deployment unter Windows? Sieht sehr Konsolen / Script-Lastig aus. Wäre generell nicht das Problem, wird aber vermutlich sehr Zeitintensiv werden.

Danke

 

[Skysnake]

Guckst du zum Beispiel hier https://www.redhat.com/de/technologies/management/ansible/automate-microsoft-windows-with-ansible

Ich würde es halt als Infrastructure as a Code bezeichnen. Das kannst du in ein Git packen und damit versionieren sowie die gemeinsame Arbeit transparenter gestalten usw usf.

Es ist halt anders als so ein typisches Windows Ansatz der oft auf GUIs setzt.

 

[dj-hotline]

Wir nutzen als Ticketsystem zammad. Das Funktioniert gut. Unsere Assets verwalten wir mit snipeit das ist aber vermutl. nicht ausreichend für den gewünschten Zweck.
Zum Deployment gibt es doch von Microsoft das MDT ist das Keine Option?

LG

 

[Art Vandelay]

Bei uns in der Firma ist man zuletzt von OPSI zu Baramundi gewechselt. Letzteres habe ich in meinem alten Job auch mal administriert, hat immer Spaß gemacht.