Wie verteilt ihr Softwareupdates netzwerkweit?

ratti

Aktives Mitglied
Thread Starter
Dabei seit
09.05.2004
Beiträge
1.521
Reaktionspunkte
56
Hallo,

Ich habe 25 Clients, zwei Server (10.4 und 10.5, letzterer mit Softwareupdate-Dienst) und möchte gerne netzwerkweit die Apple-Updates an die 10.5er-Clients verteilen. AppleRemoteDesktop Admin ist vorhanden.

Natürlich könnte ich per ARD-Admin einen Unix-Befehl an alle schicken:
Code:
softwareupdate -i -a
Dann sind aber die Kisten reihenweise im Eimer, weil die Pakete sofort ins laufende System eingespielt werden, was bei Systemupdates natürlich recht schnell crashed. Beispielsweise bei iTunes-Updates blockiert es, falls iTunes offen ist. Das ist alles total unsauber. Den fälligen Neustart ungefragt lostreten geht natürlich auch gar nicht.

Im Vergleich dazu kann man in der GUI einfach alle Pakete installieren und den Neustart verweigern. Erst, wenn der Neustart später mal durchgeführt wird, werden die Pakete im shutdown wirklich eingespielt.

Es kann doch nicht sein, dass ich im Jahr 2008 keine Systemupdates zentral an meine User verteilen kann? Übersehe ich was ganz zentrales, oder ist Mac OS nicht firmentauglich?

Gruß,
Jörg
 
Nutzt du keinen Verzeichnisdienst?

Ich glaube hier ist Microsoft mit Active Directory, WSUS, ... fast unschlagbar. Diese Aussage habe ich schon von Linux-Freaks gehört. Die sind später vom Linux-Freak zum Windows-Fan mutiert!
Bei Apple habe ich mich schon immer gefragt, wie das alles geht. Kenne den Mac aber nur als Desktop-Rechner.

In der i'x meine ich zu erinnern hatte der Autor in Leopard Server (AFAIR) auch manches vermisst.
 
schau dir doch mal RADMIND an. Nicht unaufwändig, gibt dir aber die Möglichkeit auch einen kompletten "rollback" machen zu können ...

Grüße
rickontherun
 
Nutzt du keinen Verzeichnisdienst?

Ich glaube hier ist Microsoft mit Active Directory, WSUS, ... fast unschlagbar.

Nein, kein Verzeichnisdienst. Hier laufen ständig Leute mit Laptops rein und raus, bringen private Rechner mit,… …ist halt ein kreativ-Unternehmen. Alle Systeme sind rein lokal und mounten sich einen Fileserver. Es ist gewünscht und praktiziert, dass sich jeder seinen Rechner so hinfummeln darf wie er will und Software drauftun, wie er Lust hat.

Dazu kommt, dass der Apple-Server ausschliesslich Softwareupdates und AFP macht, alles andere läuft über Linux. Die Unternehmensstruktur ist dezentral, teilweise ausserhalb Deutschlands, teilweise wird mit niedriger Bandbreite von Zuhause über vpn gearbeitet.

Andererseits sind es aber bloß 25 Rechner. Sprich: Rentiert alles nicht. Bringt mehr Arbeit als Vorteile.

Ich sehe aber auch nicht, wie ein Verzeichnisdienst mein Problem lösen würde? Und ich frage mich, warum sowas profanes wie Softwareupdates so eine Keule wie Verzeichnisdienste nach sich ziehen sollte? Das muss doch simpler gehen

Gruß,
Jörg
 
Hallo,

Ich habe 25 Clients, zwei Server (10.4 und 10.5, letzterer mit Softwareupdate-Dienst) und möchte gerne netzwerkweit die Apple-Updates an die 10.5er-Clients verteilen. AppleRemoteDesktop Admin ist vorhanden.

Natürlich könnte ich per ARD-Admin einen Unix-Befehl an alle schicken:
Code:
softwareupdate -i -a
Dann sind aber die Kisten reihenweise im Eimer, weil die Pakete sofort ins laufende System eingespielt werden, was bei Systemupdates natürlich recht schnell crashed. Beispielsweise bei iTunes-Updates blockiert es, falls iTunes offen ist. Das ist alles total unsauber. Den fälligen Neustart ungefragt lostreten geht natürlich auch gar nicht.

Hallo Jörg, irgendwie habe ich noch nicht verstanden, was das Problem ist. Du schreibst, Du hast einen Software Update Server eingerichtet. Dieser funktioniert genau so wie der Apple Software Update Server, nur dass er lokal liegt, die Updates tauchen also entweder beim booten, bei einer manuellen Suche oder nach z.B. dem Erwachen aus dem Ruhezustand auf. Voraussetzung dafür ist, dass der Softwareupdateserver im ArbeitsgruppenManager für die Arbeitsgruppe angegeben ist und die Rechner das Serververzeichnis (siehe Verzeichnisdienste) nutzen.

Thomas.
 
Ich sehe aber auch nicht, wie ein Verzeichnisdienst mein Problem lösen würde? Und ich frage mich, warum sowas profanes wie Softwareupdates so eine Keule wie Verzeichnisdienste nach sich ziehen sollte? Das muss doch simpler gehen

Es gibt nur zwei Wege, wie die Clients von Deinem Update Server erfahren: entweder über die Verzeichnisdienste oder er wird manuell konfiguriert mit dem hier z.B. https://www.macupdate.com/app/mac/24285/set-software-update-server
 
schau dir doch mal RADMIND an. Nicht unaufwändig, gibt dir aber die Möglichkeit auch einen kompletten "rollback" machen zu können ...

Danke, das kannte ich schon vom Hörensagen. Das ist für uns nicht sinnvoll, denn hier sieht fast jeder Rechner anders aus. Die Buchhaltung hat keine Creative Suite, die „Reisenden“ haben EyeTV, der Empfang hat Formulardruckprogramme, und jeder User installiert sich, was er haben möchte.

Das Aufspielen von 3rd-Party-Software löse ich mit eigenen Scripten, die Software paketiere ich selbst. Das geht alles prima.

Ich suche nur noch eine Lösung für alles was über den Apple-Updater kommt.

Gruß,
Jörg
 
Hallo Jörg, irgendwie habe ich noch nicht verstanden, was das Problem ist. Du schreibst, Du hast einen Software Update Server eingerichtet. Dieser funktioniert genau so wie der Apple Software Update Server, nur dass er lokal liegt, die Updates tauchen also entweder beim booten, bei einer manuellen Suche oder nach z.B. dem Erwachen aus dem Ruhezustand auf. Voraussetzung dafür ist, dass der Softwareupdateserver im ArbeitsgruppenManager für die Arbeitsgruppe angegeben ist und die Rechner das Serververzeichnis (siehe Verzeichnisdienste) nutzen.

Thomas.

Hallo, ich erkläre das mal.

Zunächst: Der interne Softwareupdate-Server läuft seit Jahren prima. Darum geht es nicht. Es geht darum, 25 Rechner zentral und sauber upzudaten, ohne die User zu nerven.


Wenn ich Softwareupdates einspiele, dann gilt zunächst mal, dass die User das nicht selbst dürfen. Beispielsweise legt 10.5.5 Rechner mit zwei Monitoren lahm, deswegen ist das einspielen von Updates Admin-Sache. Nicht die des Users. Die wissen das nicht.

Jetzt könnte ich von Platz zu Platz gehen und dort überall Apfel-Softwareupdate->Ja->Ja->Kennwort eingeben. Erstens wird man dabei matsch in der Birne, zweitens dauert das viel zu lange, und drittens stört man die Leute an den Rechnern. Die sollen arbeiten, nicht dem Balken zugucken. ;-)

Also muss das zentral laufen.
Wenn alle Rechner an sind, kannst du per ARD und einem einzigen Terminalkommando die Updates einspielen. Und jetzt kommt das Problem: Im Gegensatz zum grafischen Updater spielt der Terminal-Updater die Pakete SOFORT ins System ein, statt auf den nächsten Neustart zu warten. Wenn also jemand am Rechner arbeitet, wird ihm „unter´m Hintern weg“ und im Betrieb System 10.5.4 durch 10.5.5 ersetzt. Während Programme offen sind! Das geht danach natürlich keine 10 Minuten mehr gut, der unter 10.5.4 gebootete Rechner läuft mit eingeprügeltem 10.5.5 weiter. Deswegen ist ja normalerweise ein Neustart fällig. Würde ich den per Terminal im Hintergrund auslösen, würde sich der arbeitende Anwender schön bei mir bedanken…

Es muss also eine Methode geben, mit der sich die Systeme so verhalten, wie es auch der grafische Updater unter Leo macht: Erstmal werden die Pakete bloß runtergeladen. Der angeforderte Neustart darf gefahrlos verweigert werden.
Erst, wenn der Anwender (Feierabend) von sich aus herunterfährt, werden die vorhandenen Pakete *wirklich* eingespielt (dass ist dieser komische Bildschirm mit dem Sternchenhintergrund), und das System fährt sauber runter und tags drauf wieder sauber hoch.

Gruß,
Jörg
 
Es muss also eine Methode geben, mit der sich die Systeme so verhalten, wie es auch der grafische Updater unter Leo macht: Erstmal werden die Pakete bloß runtergeladen. Der angeforderte Neustart darf gefahrlos verweigert werden.
Erst, wenn der Anwender (Feierabend) von sich aus herunterfährt, werden die vorhandenen Pakete *wirklich* eingespielt (dass ist dieser komische Bildschirm mit dem Sternchenhintergrund), und das System fährt sauber runter und tags drauf wieder sauber hoch.

Gruß,
Jörg

Danke erst mal für Deine Erklärung. Warum nimmst Du in der Softwareaktualisierung nicht den Haken "Kopierte Updates automatisch aktivieren" raus und erlaubst den Usern, Updates selbst einzuspielen? Dann kannst Du die Updates, die Du den Usern zur Verfügung stellen willst, selbst auswählen. Über neue Updates wirst Du selbst per Email informiert.

Gruss,
Thomas.
 
Danke erst mal für Deine Erklärung. Warum nimmst Du in der Softwareaktualisierung nicht den Haken "Kopierte Updates automatisch aktivieren" raus und erlaubst den Usern, Updates selbst einzuspielen? Dann kannst Du die Updates, die Du den Usern zur Verfügung stellen willst, selbst auswählen. Über neue Updates wirst Du selbst per Email informiert.


Anwender scripten? ;-)

Im Ernst:

Erstens würden sie´s nicht machen. Wir haben ja alle keine Zeit… wer morgens an seinem Arbeitsplatz auftaucht, hat bereits Pläne. Wer abends geht, der hat genug getan.

Zweitens, wenn 25 Leute je eine Viertelstunde Updates einspielen, kostet das den Betrieb einen Arbeitstag. Also Geld. Sag mir nicht, es sei kein Viertelstunde - es ist eine Viertelstunde( „Ja klicken“, Kaffee holen, wiederkommen, AGBs klicken, rauchen, wiederkommen, „Neustart“ klicken, Schnacken gehen, wiederkommen… Realistisches Benchmark ;) )

Drittens: Interner Servicegedanke. Designer sollen Designen, Buchhalter sollen… was die so machen…, und der Admin soll administrieren.

Viertens: Logik. Ich mache die Applikationsupdates. Ich mache die Systempflege. Ich sehe auch die Systemupdates als meinen Job an.

Fünftens: Nochmal die Zeit. Auf dem Apple-Softwareupdateserver schlägt sehr viel Zeug ein, teilweise getrennt nach Plattform und OS-Version, nach Teil- und Combo-Updates, und für „obskure“ Produkte, die hier keiner nutzt. Ich habe keine Lust, da drin rumzuschalten und -walten.

Sechstens: Sicherheit. Die Anwender dürfen gerne selbst Software installieren, das ist hier gewünscht. Keinesfalls aber möchte ich ihnen beibringen, irgendwelche aufpoppenden „Updates“ einfach blind zu akzeptieren. Daher sind alle Auto-Updater hier generell deaktiviert.

Siebentens: Nach deiner Methode würden Updates bei allen auftauchen. Oder bei keinem. Ich als Tester habe aber eine Sonderstellung. Das ist ein kleines Problem, aber es läppert sich. Ich mache ja auch noch was anderes und bekomme nicht jedes Update mit.

Achtens: Das Problem ist vergleichsweise trivial. Ein Software müsste beim Shutdown den Rechner sperren und bereits vorhandene Systemroutinen aufrufen. Es wäre ein kleines Wunder, wenn das nicht schon jemand gebaut hätte. Ich als „Scripter“ bin da aber am Ende meiner Kunst.

To be continued… :)

Gruß,
Jörg
 
Nur eine Idee (ungeprüft):
Mit dem Softwareupdate via CLI lässt sich ja festlegen dass das Update nur geladen aber nicht installiert wird. Dass kann man also den Usern auch im laufenden Betrieb "unterjubeln". Müsste nun noch ein Logout Hook implementiert werden, der prüft ob Updates (den Ordner kann man ja feststellen) vorhanden sind und diese dann installiert. Wermutstropfen ist (wenn ich mich recht erinnere) dass unter Leopard nur der Logout auch die Logout Hooks triggert. Frühere Versionen triggerten den Logout Hook auch mit Shutdown und Reboot.

Ist zwar keine Lösung, aber...

Grüße,
Flo
 
Nur eine Idee (ungeprüft):
Mit dem Softwareupdate via CLI lässt sich ja festlegen dass das Update nur geladen aber nicht installiert wird. Dass kann man also den Usern auch im laufenden Betrieb "unterjubeln". Müsste nun noch ein Logout Hook implementiert werden, der prüft ob Updates (den Ordner kann man ja feststellen) vorhanden sind und diese dann installiert. Wermutstropfen ist (wenn ich mich recht erinnere) dass unter Leopard nur der Logout auch die Logout Hooks triggert. Frühere Versionen triggerten den Logout Hook auch mit Shutdown und Reboot.

Ist zwar keine Lösung, aber...

Grüße,
Flo

…ah! Endlich versteht man mich! ;-)

Genau sowas in der Art hatte ich eben gewünscht. Ich persönlich würde einen Hook vorziehen, der beim Start aktiv wird und ggf. nochmal einen Reboot auslöst, aber im Prinzip ist es ja das gleiche.

Jetzt wundert mich halt bloß, dass es bei 10% Marktanteil so eine Allerweltsfunktion nicht bereits geben soll. Im Prinzip sollte doch jeder Mac-Admin, der kein Netboot macht, genau darüber stolpern.

Übrigens, so ganz automagisch kommt man nicht davon: Firmwareupdates bedürfen immer manueller Eingriffe („Halten sie beim Start die Dingsbums-Taste gedrückt, bisses piept…“). Aber das ist ja eher selten.

Wie macht ihr das?
Rennt ihr auch noch in der Bude rum und macht das manuell?

Gruß,
Jörg
 
...Genau sowas in der Art hatte ich eben gewünscht. Ich persönlich würde einen Hook vorziehen, der beim Start aktiv wird und ggf. nochmal einen Reboot auslöst, aber im Prinzip ist es ja das gleiche...

LoginHook ist ohnehin leichter zu realisieren.
Siehe auch: http://support.apple.com/kb/HT2420
Findet sich noch einiges mehr dazu im Netz.

Jetzt wundert mich halt bloß, dass es bei 10% Marktanteil so eine Allerweltsfunktion nicht bereits geben soll. Im Prinzip sollte doch jeder Mac-Admin, der kein Netboot macht, genau darüber stolpern.

Übrigens, so ganz automagisch kommt man nicht davon: Firmwareupdates bedürfen immer manueller Eingriffe („Halten sie beim Start die Dingsbums-Taste gedrückt, bisses piept…“). Aber das ist ja eher selten.

Wie macht ihr das?
Rennt ihr auch noch in der Bude rum und macht das manuell?...

Mich hat im Laufe der Jahre das Gefühl beschlichen dass es entweder (mehr oder minder) keine Administration gibt und jeder macht was er will, oder die Umgebung total strikt ist, und die User nie mit Updates oder ähnlichem konfrontiert werden.

So Zwischendinger wie das worüber wir hier reden, werden nach meiner Erfahrung erst so langsam mehr.

Grüße,
Flo
 
  • Gefällt mir
Reaktionen: ratti
LoginHook ist ohnehin leichter zu realisieren.
Siehe auch: http://support.apple.com/kb/HT2420
Findet sich noch einiges mehr dazu im Netz.

Danke. Technisch gesehen wohl der richtige Weg, ich gucke mir mal an, inwieweit es damit möglich ist, dem User Feedback zu geben. Der darf ja den Rechner nicht (in der Annahme eines Absturzes) einfach mal hart neustarten…


Mich hat im Laufe der Jahre das Gefühl beschlichen dass es entweder (mehr oder minder) keine Administration gibt und jeder macht was er will, oder die Umgebung total strikt ist, und die User nie mit Updates oder ähnlichem konfrontiert werden.

So Zwischendinger wie das worüber wir hier reden, werden nach meiner Erfahrung erst so langsam mehr.

Ja, sehe ich auch so. Wobei ich mich frage, wie das läuft.

Danke!

Gruß, Jörg
 
Genau wegen den fehlenden Verwaltungsmöglichkeiten und der schlechten Netzwerkperformance gibt es jetzt bei uns anstatt neuer Mac Pros Windows Rechner für unsere Grafiker. Die haben zwar ziemlich gejammert, aber Apple ist einfach nicht mehr tragbar.
 
Danke. Technisch gesehen wohl der richtige Weg, ich gucke mir mal an, inwieweit es damit möglich ist, dem User Feedback zu geben. Der darf ja den Rechner nicht (in der Annahme eines Absturzes) einfach mal hart neustarten…

Lass was hören. Ist ein interessantes Thema.

Genau wegen den fehlenden Verwaltungsmöglichkeiten und der schlechten Netzwerkperformance gibt es jetzt bei uns anstatt neuer Mac Pros Windows Rechner...

Könntest Du das (für Interessierte) etwas präzisieren bitte?

Grüße,
Flo
 
Danke. Technisch gesehen wohl der richtige Weg, ich gucke mir mal an, inwieweit es damit möglich ist, dem User Feedback zu geben. Der darf ja den Rechner nicht (in der Annahme eines Absturzes) einfach mal hart neustarten…

So, ´n Abend die Damen, ;-)

…und genau da bin ich hängengeblieben.

Ich habe mir einen feinen LoginHook gebaut, der Pakete aus einem Ordner installiert. Supi! Aaaaber: Währenddessen sieht man einfach nur den blauen Bildschirm. Ausgaben per „echo“ landen lediglich im syslog, und was ich dazu im Internet gefunden habe bietet mir auch nix anderes.

Heisst: Der User starrt während eines Systemupdates auf einen „toten“ Rechner und wird selbstredend spätestens nach 2 Minuten hart neustarten. Mittendrin. Byebye, System.

Geht so nicht.

Ich habe dann stattdessen mit dem launchd probiert, Agents zu starten. Leider auch da keine Resultate!

Es muss doch irgendwie möglich sein, dass der Rechner beim Start ein Script startet und dem User ausgibt, er möge bitte mal warten!? Was ist das denn für ein besch…eidenes Bootkonzept?

Für´s erste würde es ja vollkommen reichen, wenn einfach Terminal.app starten täte und man „Finger wech! Warten!“ rausschreiben könnte…

Wahrscheinlich plant Apple den iTurnschuh. Für den modebewussten SysAdmin, der ganztägig im Unternehmen herumläuft und auf „Software updaten“ klickt…

Gruß,
Jörg

P.S.: Autostartende Applikationen gehen natürlich auch nicht. Erstens braucht man Rootrechte, und zweitens würden da schon wieder die ganzen Sachen laufen, die der User autostartend hat (Mail, iTunes) - also nein. Rechtlos und zu spät. %-/
 
...Ich habe mir einen feinen LoginHook gebaut, der Pakete aus einem Ordner installiert...

Hm...und wenn Du es doch mal mit einem LogoutHook probierst?
Also z.B. lässt sich ja auch pmset scripten, so dass Du also theoretisch eine beliebige Startzeit definieren kannst. Müsste sich doch dann z.B. so einrichten lassen dass der Rechner zu einer Zeit startet an der der Nutzer sicher nicht dran arbeitet, dann die Updates installiert werden, und die Kiste sich wieder runterfährt.

Also z.B. liest das Script aus dem LogoutHook die aktuelle Systemzeit aus, addiert Zeit x und setzt das als Startzeitpunkt (in der Annahme dass der User nach dem Ausschalten nicht so schnell wiederkommt). Möglicherweise kann man ja evtl. beim abarbeiten des LogoutHooks sogar noch Dialoge ausgeben und sogar Eingaben entgegennehmen?

Wieder mal nur so Ideen...

Grüße,
Flo
 
Hm...und wenn Du es doch mal mit einem LogoutHook probierst?
Also z.B. lässt sich ja auch pmset scripten, so dass Du also theoretisch eine beliebige Startzeit definieren kannst. Müsste sich doch dann z.B. so einrichten lassen dass der Rechner zu einer Zeit startet an der der Nutzer sicher nicht dran arbeitet, dann die Updates installiert werden, und die Kiste sich wieder runterfährt.

Naja, es gibt zwei Gründe, die mich davon abhalten.

Der erste:
Wermutstropfen ist (wenn ich mich recht erinnere) dass unter Leopard nur der Logout auch die Logout Hooks triggert. Frühere Versionen triggerten den Logout Hook auch mit Shutdown und Reboot.

und der zweite:
Wenn der LoginHook ausgeführt wird, bevor das grafische Subsystem komplett läuft (Fundstellen im Internet weisen darauf hin, dass z.B. keine Apple-Script befehle funktionieren und keine Fenster geöffnet werden können)…
…dann wäre es sehr, sehr unwahrscheinlich, dass die LogoutHooks nicht genau spiegelverkehrt funktionieren, sprich: Nach dem Abschuss der entsprechenden Komponenten.

Krause Situation… :-/

Gruß,
Jörg
 
Wir pflegen unsere Macs mit LanDesk. Sind ca. 200 Maschinen. Klappt soweit ganz gut, auch wenn es mit den Windows-Maschinen besser funktioniert. Da reden wir von ca. 4000 Clients.

LanDesk ist gut, aber teuer.
 
Zurück
Oben Unten