Diskussion:Softwareverteilung

Hallo,

bei diesem komplexen Thema brauche ich Hilfe! Verlinkung, Formatierung, Inhalte... Ich möchte den Artikel neutral gestalten: keine Festlegung auf ein Betriebssystem. Keine Festlegung auf eine Produkt. Es ist aber durchaus sinnvoll auf gängige System (Windows, Linux, SMS, RPM) hinzuweisen. In Linux bin ich nicht so tief drin - daher würde ich mich über Input freuen. Aber bitte neutral bleiben

Hi, Danke für die viele Mühe mit dem Artikel, doch fürchte ich, dass er völlig einseitig und in langen Strecken am Thema vorbei ist: MSI - spezifisches sollte in den Artikel Microsoft Windows Installer, genau so wie Linux-spezifische Sachen bereits in den Artikeln RPM (Dateiformat), Yellowdog Updater, Modified, Advanced Packaging Tool, ... untergebracht sind. Hinzu kommt, dass weder Snapshots noch Images noch Silent Setups noch Setups speziell zu Windows gehören. Und das Snapshots das bevorzugte Mittel der Wahl sein sollen, halte ich für strittig - so was sollte ebenfalls alles in einen Artikel, der MSI beleuchtet, und in dem Rahmen eh einen Blick auf die Installationswege bei Windows wirft. Ich will nur ungerne den MSI Teil auslagern, weil mir da einiges an Kenntnissen fehlt - danach steige ich aber gerne mit ein. Übrigens kann man auch das ein oder andere zum Stichwort von Paketmanagement nach genau dort hin auslagern. --Liquidat 02:24, 7. Jan 2005 (CET)

Diskussion aus dem Review (Mai)

Wurde auf der Reviewhauptseite eingetragen. -- Dishayloo [ +] 00:24, 12. Mai 2005 (CEST)

Nun gut, dort auf der Diskussionsseite stehen ja schon einige Ansätze bereit: der Artikel ist völlig einseitig und sollte eigentlich zerlegt werden, um den Anteil über Windows-spzifische Arten auszulagern. Aber wie ich schon dort schrieb, die Auslagerung sollte eventuell mal jemand vornehmen, der mehr Ahnung davon hat. Wird auf jedem Fall viel Arbeit :) --Liquidat 02:53, 12. Mai 2005 (CEST)

Ich würde auch sagen das erst einmal ein Blick in die Diskussionsseite sinnvoll wäre und der Eintrag raus kann. --Saperaud [@] 04:41, 12. Mai 2005 (CEST)

Vorschlag: Windows Installationstechniken muss raus in eigene Artikel. Praxistipps haben auch nicht so richtig was in Wikipedia zu suchen. --hreisterp

Du hast meine volle Zustimmung! :)

Bist du in der Thematik fit genug, das zu machen? Wo könnte ich helfen? --Liquidat 13:58, 25. Jun 2005 (CEST)

Zustimmung. Wikipedia ist keine Howto-Sammlung Umschreiben oder wenn sich niemand findet auch löschen. --Gruß, Helge 14:36, 15. Sep 2005 (CEST)

Linux, MacOS, Unix, BSD ...

Ich finde der Artikel ist sehr windowslastig. Entweder den Absatz "Windows Installationstechniken" löschen oder entsprechene Absätze für andere Betriebssysteme einfügen.

Themenvermengung

Hallo,

was mir auffällt ist, das hier einige Bereiche vermengt werden, die eigentlich nichts miteinander zu tun haben. Auf der einen Seite stehen die Tools zur Softwareverteilung und auf der anderen Seite die Installtionsverfahren. Softwareverteilung steht im eigentlichen Sinne für "Verteilung eines Softwarepaketes über Router, CD oder sonstige Wege auf den Client. Die Softwareverteilung meldet dann auch an zentraler Stelle den Erfolg oder Misserfolg der eigentlichen Installation.

Die Installation des Softwarepaketes selber, wird ebenfalls noch durch die Verteilungssoftware eingeleitet. Hierfür sind dann meist sogenannte Agenten (Dienste) zuständig, die dafür sorgen, das auch wenn ein Benutzer angemeldet ist, der keine Administrativen rechte Besitzt, eine Installtion durchgeführt wird.

IN dem Softwarepaket wiederum, befinden sich dann endlich Dinge, wie z.B. ein MSI oder eine InstallShield-Installation und natürlich das Skript, in welchem steht, welche Befehle vom Agenten ausgeführt werden sollen.

Problem dabei ist, das der Ausdruck "Softwarepaket" SEHR Allgemein ist. Man kann darunter auch die Original-CD von Nero sehen. Und je nach Einblick in die Materie verzerren sich dadurch die Details.

Beispiel: Softwareverteilung: SMS, Netinstall, Empirum Installer: MSI, InstallShield, INNOSetup, Nullsoft

Anmerkung: Ein "Softwarepaket" für eine Softwareverteilung besteht meist aus den Sourcen (also z.B. dem MSI), sowie aus dem Skript. Das Skript ist das, was von dem lokelen Agenten (Dienst) gestartet wird. In ihm steht "führe das MSI mit folgenden Schaltern aus (z.B. "/qn")". Diese beiden Dinge werden meist irgendwie verpackt (z.B. ZIP oder verteilungseigene Technologie) und dann als "Softwarepaket" bezeichnet. Daher auch der Satz: "Kannst du mir mal das paket zuweisen..."

CU Albert Meyn

PS: Sry. mein erster Auftritt bei Wikipedia. Denke ich habe gegen die übliche Netikette und die Rechtschreibnovelle verstoßen, aber der Kommentar lag mir am Herzen. ;-)

Links auf konkrete Systeme

Hi. Dass die externen Links entfernt wurden, finde ich gut. Jedoch waren dabei interne Links mit entfernt worden, was ich weniger gut finde. Vorschlag, um ein erneutes Ausufern der Liste zu vermeiden: Wir akzeptieren nur Links auf solche Systeme, die eigene Artikel in der Wikipedia haben. Einverstanden? --jpp ?! 13:53, 24. Apr 2006 (CEST)

Ich weiß, dass ich auch interne Links entfernt habe, aber hier musste erstmal Frühjahrsputz gemacht werden, nicht böse ok? ;-) Im Prinzip ja, aber auch hier halte ich eine vollständige Auflistung nicht für nötig, die Artikel sollten nur alle in der Kategorie:Unbeaufsichtigte Installation eingeordnet sind, damit sie zu finden sind. --Raymond 13:59, 24. Apr 2006 (CEST)

Ich bin ja gar nicht böse. Ich hatte eher befürchtet, dass du böse wirst, wenn ich die internen Links wieder rein nehme. ;-) Kategorien sind auch eine feine Sache, aber einige Beispiele im Artikel sind m. E. ganz sinnvoll. Wenn die Liste zu sehr anwächst, müssen wir halt nochmal kürzen. --jpp ?! 17:03, 24. Apr 2006 (CEST)

Ich kenne leider die History dieses Artikels nicht. Allerdings bin ich wahrscheinlich nicht der einzige, der bei der Recherche nach einem Softwaretool auf diese Seite gestoßen ist und hier nur kommerzielle Tools gefunden hat. Seltsam, an anderer Stelle hatte ich mal einen kleinen Hinweis auf ein kommerzielles Tool verlinkt und schon wurde mir das als Schleichwerbung ausgelegt ;-)

Hier der Link zu einer Seite der englischsprachigen Wikipedia: Comparison of open source configuration management software Ein paar Programme, falls noch jemand auf der Suche ist: OCSinventory, OPSI, "Smart Software Synchronisation", WPKG - alle zu finden unter [1] --wwwprofi 17:16, 02. Jun 2010 (CEST)

Unter Windows kann Installation von Anwendungen auf technisch verschiedene Weise erfolgen. Dabei hat jedes Verfahren Vor- und Nachteile, die der Admin im Einzelfall gegeneinander abwägen muss. Dabei spielt es auch eine Rolle, welche Installationsverfahren überhaupt von dem Deployment-System unterstützt werden. Und auch hier ist die Qualität keinesfalls immer die gleiche. Im Detail werden vier Gruppen unterschieden:

---

Ausgelagert

Microsoft Installer Paket (MSI)

"Des Admins Liebling". Eine Installation die vom Hersteller der Software bereits als MSI-Paket ausgeliefert wird, macht dem Admin die wenigste Arbeit und kann auch am einfachsten wieder deinstalliert werden. Eine Homogenität unter den Clients ist nicht erforderlich.

Über Transformation Files (MST) kann die Installation komfortabel an die eigenen Bedürfnisse angepasst werden. Die MSI Installation ist sehr robust, da sie ein Transaktionssteuerung implementiert, d.h. alle Änderungen am System werden erst dann wirksam, wenn ALLE Schritte des Setup erfolgreich waren (COMMIT). Schlägt ein Schritt fehl, wird das System wieder in den Originalzustand vor Beginn der Installation versetzt (ROLLBACK). MSI sollte auf jeden Fall die bevorzugte Methode sein. Im Allgemeinen kann Software die mit MSI Technologie installiert wurde auch wieder deinstalliert werden.

Die MSI Technologie ist die aktuelle Standard-Technologie die Microsoft selbst empfiehlt. MSI-Pakete können theoretisch direkt unter Verwendung des Active Directory an einzelne Rechner, Organisationseinheiten oder eine Domäne verteilt werden. Je nach Umfang der Software und Anzahl der Clients kann dies aber katastrophale Auswirkungen auf die Netzwerkbelastung haben und sollte daher eher nicht durchgeführt werden. Bei kleineren Umgebungen ist dieses Verfahren aber durchaus praktikabel.

Bei MSI Paketen sollte beachtet werden, dass viele existierende Pakete sich nicht an die vorgegebenen Standards halten. Dadurch entstehen gelegentlich auch Schwierigkeiten bei der Verteilung dieser Pakete, die unabhängig vom Verteilmechanismus auf eine "schlechte" Erstellung der Pakete zurückzuführen ist. Dies bewirkt, dass der an sich gute MSI Standard bislang noch nicht die angestrebte Effizienzsteigerung nach sich gezogen hat.

Snapshot

Wenn der Hersteller kein MSI liefert, kann man durch "Repackaging" versuchen selbst ein bestmögliches Paket zu erstellen. Das Snapshot-Verfahren wird von den verschiedenen Herstellern unterschiedlich gut beherrscht. Hier ist eine gewisse grundsätzliche Homogenität unter den Ziel-Clients sinnvoll. Ein wesentlicher Vorteil des Verfahrens ist, dass die heute verfügbaren Tools es erlauben mit geringem Aufwand nahezu jedes Setup zu automatisieren. Als Ergebnis wird oft ein MSI-Paket erstellt. Gravierender Nachteil dieses Verfahrens ist, dass es auf der Konfiguration des Clients beruht, auf dem der Snapshot ausgeführt wird. Die gesamte Intelligenz, die im Installationsprogramm des Herstellers mitgeliefert wird, geht verloren. Daher ist das Snapshot-Verfahren ein typisches 80:20-Verfahren. Mit geringem Aufwand kann man eine Lösung für 80% der Installation erreichen. Man sollte sich aber darauf einstellen bei einem nicht zu vernachlässigenden Anteil von Clients auf Probleme zu stoßen.

Ein weiteres prinzipielles Problem ergibt sich daraus, dass man nicht mehr das Originalverfahren des Herstellers verwendet. Damit kann sich dieser im Zweifelsfall (Support, Schaden) rechtlich aus der Verantwortung zurückziehen. Daher ist das Snapshot-Verfahren eher mit Vorsicht zu genießen - eigentlich ist es die Aufgabe des Herstellers ein Setup zu liefern, dass den Bedürfnissen des Kunden gerecht wird (s. MSI). In der Regel liefert aber auch der Hersteller des SnapShot Produktes den entsprechenden Support, sodass Anwender auf der sicheren Seite sind.

Verfügt der Snapshot Editor - und entsprechend der Client - über anpassbare integrierte Regeln, so wird das 80:20 Verfahren durchbrochen (Anwender berichten hier von einer 100%igen Zuverlässigkeit in heterogenen Umgebungen). Verfügt das Snapshot Verfahren weiterhin über einen Conflict Checker, so können im Vorfeld Konflikte erkannt und behoben werden (bevor eine Software ausgerollt wird). Eine optimale Ergänzung dazu sind optimierte und verschlüsselte Übertragungen, Rollback und Check Point Restart.

Images

Verschiedene Hersteller bieten die Möglichkeit, fertige Festplattenimages auf die Clients zu verteilen. Einzelne Hersteller (OMA-Technologies) bieten sogar die Möglichkeit, Images nachträglich zu modifizieren. Dieses Verfahren erfordert die größtmögliche Client-Homogenität. Images eignen sich nur zur kompletten Installation des Systems. Mit Images kann keine zusätzliche Software auf ein bereits installiertes System gebracht werden. Der wesentliche Vorteil von Images liegt in der sehr schnellen Installation.

Bei Ausführen eines Setups werden immer und immer wieder die gleichen Prüfungen durchgeführt. Das System wird u.U. mehrfach gebootet und je nach Performanz der CPU und Speicherausstattung dauert das Auspacken der Installationsquellen u.U. recht lang. Bei einem Image werden einfach alle Dateien nur ein einziges Mal kopiert.

Nachteil von Images ist, dass sie nur eine Lösung für die einmalige Installation bieten. Um eine bestehende Client-Landschaft dauerhaft zu betreiben, sind sie naturgemäß nicht geeignet.

Die Verwendung von Images empfiehlt sich immer dann, wenn man schnell eine große Anzahl von gleichen Rechnern initial installieren will. Insbesondere die Hersteller von Comsumer-Rechnern verwenden Images.

Original-Setup-Installation ("silent")

Wenn das Setup die Möglichkeit bietet, "silent" abzulaufen, kann man mit fast allen Deployment-Systemen auch einfach das Original-Setup verteilen und mit den entsprechenden Kommandozeilenparametern aufrufen.

Leider muss man in der Praxis immer wieder feststellen, dass der Begriff "silent" unterschiedlich verstanden wird. Für eine Softwareverteilung bedeutet silent: NIEMALS ein Popup Fenster, das auf die Eingabe eines Benutzers wartet.

Unrühmliches Beispiel für Hersteller, die sich an diese eigentlich einfache Vorgabe nur unzureichend halten, ist Microsoft. Neben einem Dschungel an Kommandozeilenparametern kommt es immer wieder vor, dass trotz richtig gesetzter Parameter Meldungsfenster angezeigt werden.

Daher ist die MSI-Technologie klar zu bevorzugen - leider liefert auch Microsoft selbst viele Installationsprogramme noch nicht als MSI-Paket aus.

Früher war es gang und gäbe, für die Setupprogramme, die keine silent-Installation bieten, ein zusätzliches Programm zu schreiben, das dann Maus- und Tastatur-Ereignisse sendet. Diese "Krücken" sind heute nicht mehr akzeptabel und sollten nur im Notfall angewendet werden.

"Original-Setup-Installation"

Von den Installationspaketen, die der Admin selbst erstellen kann, bietet dieses Verfahren die höchste Kompatibilität, da das Original-Setup, welches der Hersteller einer Software getestet hat, verwendet wird. Auch stellt es die geringsten Anforderungen an die Homogenität der Clients.

--Hansjörg Reister 10:57, 15. Jul 2006 (CEST)

Java Web Start

• Java Web Start ermöglicht den Download von Java-Anwendungen und deren automatische Installation und Aktualisierung bei Bedarf. Im Gegensatz zu den meisten anderen genannten Systemen wird es nicht von zentraler Stelle gesteuert, sondern dezentral vom Client aus angestoßen.

Ist kein SW Verteilsystem sondern eine Installationstechnik.

--Hansjörg Reister

Ich denke, gerade deshalb sollte es erwähnt werden. Weil es eine echte Alternative darstellt, denn mit Java Web Start lassen sich – für Java-Anwendungen – die gleichen Ziele erreichen, wie mit Softwareverteilungssystemen im engeren Sinn. Es lässt sich, soweit ich mich entsinne, auch so konfigurieren, dass die DAUs keinen Unsinn anstellen können. Vielleicht in einem Abschnitt „Alternativen“? --jpp ?! 13:14, 18. Okt. 2006 (CEST)

Ich habe letztes Jahr an der Uni Augsburg eine sehr gute Seminararbeit zu diesem Thema geschrieben. Hab sie mal als Literaturquelle angegeben. Dort habe ich breit und lang alle Facetten des Software Deployments erklärt. Auch sind einige nette Schematische Grafiken dabei, die ich hier auch gerne zur Verfügung stellen würde. Leider bin ich im Moment etwas knapp in der Zeit (hab wieder mal Prüfungen). Auch die verschiedenen Verfahren (Imaging/Cloning etc.) wurden ausführlich erklärt.

--Florian Mücke 11:19, 30. Jan 2007 (CEST)

• Im Gegensatz zu den anderen genannten Systemen wird es jedoch nicht von zentraler Stelle gesteuert, sondern dezentral vom Client aus angestoßen.

Öhm, die anderen arbeiten auch nicht anders. Es ist grundsätzlich der Client, der die Suche nach neuer verfügbarer Software anstößt. Er meldet sich beim Server (z.B: AD) und fordert die aktuelle Soll-Liste an und vergleicht sie mit seiner Ist-Liste. Stimmen sie nicht überein führt der Client die Aktion(en) aus (i.d.R. Start von Installationsprogrammen, die auf dem Server liegen), die zur Erreichung des Soll-Zustandes führen. Trotzdem sehe ich Java Web Start eher als eine Automatische Aktualisierungsfunktion aus anderem Kontext: Es ist der Programmierer, nicht der Administrator, der die neue Version auf seinem Server zur Verfügung stellt - was auch viele andere Programme schon machen bzw. zumindest versuchen (denn ohne Adminrechte gehts meist schief). Lofote 11:28, 5. Mai 2007 (CEST)

Es gibt auch Softwareverteilungssysteme (z. B. ASDIS), die vom Server aus die Verteilung anstoßen. Der vor dem Rechner sitzende Benutzer wird dann allenfalls um Erlaubnis gefragt oder aufgefordert seine aktiven Anwendungen zu beenden. Die Verteilung vom zentralen Softwareverteilungsserver auf mehrere Anwendungsserver funktioniert üblicherweise ganz ohne Interaktion. --jpp ?! 14:36, 6. Mai 2007 (CEST)

Beispiele für Softwareverteilungssysteme für mobile Geräte (Mobile Device Management)

Hallo. Mich interessiert als IT'ler das Thema auch brennend. Ich habe mal die bekannten Lösungen hinzugefügt, mit denen man mobile Geräte (Smartphones und sowas) verwalten kann. Das Thema wird immer brisanter, nachdem in Firmen (auch bei uns) diese Geräte immer mehr zum Einsatz kommen und wir in der IT mit der Betreuung (zu Fuß) kaum hinterherkommen. -- Schreibmalwieder 19:34, 20. Nov. 2008 (CET)

Unterschiede englischer Artikel vs. deutscher Artikel

Ich musste gerade festestellen, dass der Inhalt des deutschen Artikels (en:Software_deployment) sich stark von dem Inhalt des englischen Unterscheidet. Während sich der deutsche Artikel hauptsächlich mit der Installation von (Endbenutzer-)Software auf einer Hardware beschäftigt, beschäftigt sich der englische Artikel eher mit der Einführung eines Enterprise-Systems welches ein anderes Enterprise-System ablöst.

Die Installation eines Endbenutzersystems erfordert meistens "nur" das Anklicken der install.exe (Ok, ich gebe zu, dass es unter Linux oder dem Mac etwas anderst funktioniert, aber es ist ähnlich simpel)

Bei einer grösseren Unternehmenssoftware ist es aber selten, dass alleine das Ablegen der Binaries genügt. Oftmals ist die Installation der Software sehr individuell, so dass einzelne Installationsschritte manuell durchgeführt werden müssen, da sie oftmals unterschiedliche Rollen (DB-Admin, Netz-Admin, Admin für die Desktopsysteme der Anwender, Admin für das Betriebsystem des Servers usw) benötigt werden. Ich denke, dieses sollte im Artikel noch berücksigtigt werden. --JensBaitinger 09:41, 11. Dez. 2008 (CET)

Clientlastig

Der Artikel ist Client-lastig. Wünschenswert ist die Beschreibung des Deployment in einem Server-Framework, beispielsweise Webserver, Applikationsserver, Datenbankserver, Diensteserver, Verzeichnisserver usw.

--Mussklprozz 16:57, 30. Apr. 2009 (CEST)

Begrifflichkeit und Handhabung

So viel ich weiss, heisst "Verteilung" auf Englisch nicht eher "distribution"? Ist die Softwareverteilung nicht vielleicht Teil der "Software Bereitstellung" ("Softwarebereitstellung" ... wirklich schon so gebräuchlich, dass man es zusammenschreiben kann? -> Softwareverteilung, Software Verteilung?), welches vielleicht eher die Übersetzung für "software deployment" sein könnte? "Softwareverteilung" = "software distribution", "software deployment" = "Software Bereitstellung"? -> Auch wenn vielleicht von den en Artikeln her auch nicht ganz so? Könnte man dann so nicht besser strukturieren, und die Information(en) dazu einfacher aufführen? Software Bereitstellung ist z.B. vielleicht Software Einlieferung, 'Paketierung', und dann aber auch die eigentliche Verteilung wohl inkl. Installation ( -> "Software Verteilung"?) usw. Es wäre dann doch wirklich nicht praktisch, dass faktisch im Artikel, wie er im Moment ist, die eigentliche (Software) "Verteilung" Teil der "Softwareverteilung" ist.

Ich finde in der Wikipedia z.B. nichts über "Stagen" (oder müsste ich da nach einem deutsche(re)n Begriff Suchen?), welches für das neu Aufsetzen eines Systems - inkl. aller Anwendungssoftware, nicht nur das Betriebssystem - benutzt werden kann, egal ob für Client oder Server. Auch wenn man das vielleicht sogar für inkl. das Aufstellen der Hardware am Arbeitsplatz verwenden kann, kenne ich es wohl nicht auch dafür -> für das eher Rollout. In einem Artikel Software Bereitstellung könnte "Stagen" doch dann problemlos Aufnahme finden, nicht? In diesem Softwareverteilung, weiss ich nicht, ob das auch so problemlos reinpasst. --Alien4 16:15, 7. Jan. 2011 (CET)

Deployment sind eigentlich nur ein Zwischenschritt um eine Software für eine Installation auszuliefern. Nämlich die Erstellung der Konfiguration von umgebungsspezifischen Parameter der Zielumgebung(en), sowie das zusammenführen (packen) mit den Binaries und statischem Content zu einem Deployment(-paket). Die Lieferung der binaries (Kompilation) und statischem Kontent erfolgt möglicherweise von dritten z.B. von einem Softwarelieferant, also wieder eine andere Rolle wie die des deployers. Im Anschluss folgt natürlich immer eine Installation (Rollout), das ist ja der Sinn und Zweck eines deployments aber die Installation ist nicht Teil des deployments und wird zumindest in größeren Firmen meistens auch von anderen Rollen implementiert (lokaler Administrator). In kleineren Firmen werden deployment und Installation meistens von den gleichen personen durchgeführt, vielleicht wird desshalb oft Installation mit Deployment verwechselt. -- Chrocus 10:45, 11. Apr. 2011 (CEST)

Ich denke, so könnte Software Bereitstellung (in einer grösseren Organisation z.B.) vielleicht aussehen:

--Alien4 16:44, 24. Jun. 2011 (CEST)