Software Aktualisierung unter OSX Server 10.4

[nrs]

Hallo,

hat schon jemand Erfahrung mit dem Dienst für die "interne" Software aktualisierung gemacht, den os x server 10.4 jetzt bietet. Denn ich sitzt hier grad ziemlich ratlos vor meinem Server und weiss nicht wie ich das konfigurieren soll.

Oder hat jemand vielleicht einen guten Linkk zum Thema Server 10.4 mit How To's und solchen sachen ??

 

[HaM1]

Hallo,

selbiges hat mir auch schon den Kopf zerbrochen und er bricht immer noch ;-) , wobei ich schon einige Tipps bekommen habe.

Hast du an dem Client schon die Datei (Welche das ist, muss ich nachschauen, findet man aber auch detailliert beschrieben wenn man in Google sucht!!) editiert die die Softwareaktualisierung steuert?
In der Datei steht nämlich der zu verwendende Server und da muss natürlich der interne Server eingetragen werden, danach sollte es eigentlich laufen...
Bei mir tut er es nicht, allerdings hat/te das andere Gründe.

Gruss
HaM1

 

[EchoMac]

Hey Leute, also ich sitze auch schon seit 2 Tagen und zerbrich mir den Kopf wie das wohl funktionieren mag. Aufjendenfall hab ich den dreh noch NICHT raus. Wäre wirklich super wenn uns da jemand mit erfahrung weiterhelfen kann. Hat das noch nie jemand geschafft? Hat niemand einen guten Link? Ich würde es auch für meine Internen Clients benötigen, das mir grossen internet traffic sparen würde.

 

[MaxS]

Hey Leute, also ich sitze auch schon seit 2 Tagen und zerbrich mir den Kopf wie das wohl funktionieren mag. Ich würde es auch für meine Internen Clients benötigen, das mir grossen internet traffic sparen würde.

Oh je! 2 Tage schon!

Das ganze ist dick und breit in der Anleitung Deines Server beschrieben. Zum nachlesen: http://www.apple.com/server/documentation/ auf Seite 75 der Anleitung zu "System Imaging and Software Update Administration".

Ich hoffe das hilft

Viele Grüße, Maximilian

 

[ratti]

Hallo,

hat schon jemand Erfahrung mit dem Dienst für die "interne" Software aktualisierung gemacht, den os x server 10.4 jetzt bietet. Denn ich sitzt hier grad ziemlich ratlos vor meinem Server und weiss nicht wie ich das konfigurieren soll.

Oder hat jemand vielleicht einen guten Linkk zum Thema Server 10.4 mit How To's und solchen sachen ??

Das kommt mir bekannt vor. Daran habe ich mir auch fast die Zähne ausgebissen.

Anscheinend geht das offiziell und eigentlich nur mit Heimverzeichnissen auf dem Server, also Authentifikation gegen das Netz statt lokal... also mit anderen Worten: Eigentlich alles, was man nicht will. Das volle Programm. Weil man doch bloss für 20 Kollegen einen als "Gast" zu mountenden Fileserver freigeben will, ohne Schnickschnack.

So, wie Apple das implementiert hat, finde ich es einfach nur SCH....lecht.

Die Lösung deiner Probleme ist das hier:

Damit sagst du dem Mac, dass er vom lokalen Server updaten soll, ohne in igrendwelchen anderen Krempel eingebunden zu sein. Läuft bei uns seit längerer Zeit und richtig prima. Perfekt.

Gruß,
Jörg

 

[slowfranklin]

Die Lösung deiner Probleme ist das hier:

Damit sagst du dem Mac, dass er vom lokalen Server updaten soll, ohne in igrendwelchen anderen Krempel eingebunden zu sein.

Ach so - die Lösung für nicht vorhandenes rudimentäres Knowhow um einen unixoiden Server zu beglücken bist du, der immer fröhlich mit Download URLs um sich wirft, für Programme die Frontend für genau eine Zeile in der Shell sind?

Wie wärs denn mit:
`man defaults` zum warmwerden und dann ein fröhliches
`sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://$DEIN_SERVER:$PORT/` hinterher?

 

[ratti]

Ach so - die Lösung für nicht vorhandenes rudimentäres Knowhow um einen unixoiden Server zu beglücken bist du, der immer fröhlich mit Download URLs um sich wirft, für Programme die Frontend für genau eine Zeile in der Shell sind?

Sprüche. Wie wäre es mit inhaltlichen Aussagen?

Offensichtlich ist der "offizielle" Weg ja wohl, die Heimverzeichnisse vom Server zu holen (und somit obige Prefernce-Datei), und die Update-Einstellung dann auf dem Server im Einstellungs-Dialog per User durchzuführen. Jedenfalls hat der Server dafür ein buntes Dialogfensterchen, welches nur dann Sinn ergibt, derweil diese Einstellung auf dem Desktop in den Systemeinstellungen offensichtlich weggelassen wurde.

Wie wärs denn mit:
`man defaults` zum warmwerden und dann ein fröhliches
`sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://$DEIN_SERVER:$PORT/` hinterher?

...was exakt das gleiche ist, nur dass obige Freeware dir die bequeme Option gibt, das per User oder per System zu machen und die Originaleinstellung wiederherzustellen, und sudo ohne Adminprivileg nicht funktioniert?

Nix gegen Kommandozeile. Aber bitte nicht bloß zum Angeben.

Gruß,
Jörg

 

[MaxS]

Anscheinend geht das offiziell und eigentlich nur mit Heimverzeichnissen auf dem Server, also Authentifikation gegen das Netz statt lokal... also mit anderen Worten: Eigentlich alles, was man nicht will. Das volle Programm. Weil man doch bloss für 20 Kollegen einen als "Gast" zu mountenden Fileserver freigeben will, ohne Schnickschnack.

Hallo Jörg, das stimmt einfach.

Man muss nicht Benutzer mit Heimatzverzeichnissen einrichten um diese dann zu managen. Man kann auch nur Computer managen! (das ist der dritte Tab neben Benutzern und Gruppen im Arbeitsgruppenmanager). Auch dort kannst Du den Software Update Server eintragen. So musst Du Keine Benutzer am Server haben, kannst aber dennoch die Mac Clients im Netz mit Einstellungen versehen (eben auch den SUServer).

Mein Verweis auf die Doku, stellt darüber hinaus auch ganz klar von Apple dokumentiert dar, wie es ohne Client-Management vom Server aus überhaupt funktioniert. Für alle die es jetzt wieder nicht nachschlagen wollen, dort steht eben wortwörtlich:

Pointing Non-Managed Clients to a Software Update Server
Use the following command to point non-managed client computers to a particular Software Update server:

defaults write com.apple.SoftwareUpdate CatalogURL URL

Where URL is the URL of the Software Update server. For example:

http://su.domain_name.com:8088/

Diesen Einzeiler kann man bspw. mit Apple Remote Desktop mit einem Schlag auf alle Clients verteilen. Dein Tipp mit der App klappt natürlich auch, und macht exakt genau das gleiche.

Nur dass hier nicht der Eindruck entsteht, Apple baut da Scheisse, denn es funktioniert überall gleich, man muss nur die Anleitung lesen ...

viele Grüße, Maximilian

 

[slowfranklin]

Sprüche. Wie wäre es mit inhaltlichen Aussagen?

Gerne:

Offensichtlich ist der "offizielle" Weg ja wohl, die Heimverzeichnisse vom Server zu holen (und somit obige Prefernce-Datei), und die Update-Einstellung dann auf dem Server im Einstellungs-Dialog per User durchzuführen. Jedenfalls hat der Server dafür ein buntes Dialogfensterchen, welches nur dann Sinn ergibt, derweil diese Einstellung auf dem Desktop in den Systemeinstellungen offensichtlich weggelassen wurde.

Schmarrn: der offizielle Weg ist, das der Client einen etwaig vorhandenen .plist Eintrag auswertet. Das das u.U. GUImäßig erstmal nur für mcxClients einstellbar ist, ist nur eine Beschränkung des GUI und hat mit Heimverzeichnissen auf Server auch nix zu tun.

Und das Prinzip das Systemkonfigurations GUI nicht Feature zu überladen, halte ich für nicht verkehrt. Wer dann halt meint er müsste trotzdem kann das ja auch problemlos tun und sich bei der Gelegenheit ein bisserl den Grundlagen widmen.

...was exakt das gleiche ist, nur dass obige Freeware dir die bequeme Option gibt, das per User oder per System zu machen und die Originaleinstellung wiederherzustellen, und sudo ohne Adminprivileg nicht funktioniert?

Was aber leider größtenteils simple und grundlegende OS X Funktionalitäten vernebelt und einen auf der Leiter des wissenden Serveradmins exakt NULL Sprossen nach oben bringt.

Nix gegen Kommandozeile. Aber bitte nicht bloß zum Angeben.

s.o.

Gruß

Ralph

 

[ratti]

der offizielle Weg ist, das der Client einen etwaig vorhandenen .plist Eintrag auswertet. Das das u.U. GUImäßig erstmal nur für mcxClients einstellbar ist, ist nur eine Beschränkung des GUI und hat mit Heimverzeichnissen auf Server auch nix zu tun.

Und das Prinzip das Systemkonfigurations GUI nicht Feature zu überladen, halte ich für nicht verkehrt. Wer dann halt meint er müsste trotzdem kann das ja auch problemlos tun und sich bei der Gelegenheit ein bisserl den Grundlagen widmen.

Naja - ansichtssache. So ganz durchdacht scheint mir das alles nicht, was man schon daran sieht, dass es erst ab 10.4 implementiert ist. Das hätte man alles schöner machen können.

Statt des derzeitigen Mechanismus, der stündlich jeden Kram von Apple spiegelt, inklusive MASSEN an Kram für Hard/Software, die wir überhaupt nicht besitzen, hätte man sowas prima über einen Proxy regeln können. Ein Client triggert das ziehen des Updates, alle weiteren bekommen es vom lokalen Server, und unnötige Pakete werden so gar nicht erst getriggert. Ältere Mac OS wären dann automatisch ebenfalls in den Genuss des lokalen Updates gekommen, und Server wie z.B. adobe.com könnte man gleich dazu eintragen.
Leider verwendet Apple ein Lastverteilungssystem (Ich glaube, es war Akamai), und so ist mit einem Squid nix zu wollen. Ich habe es jedenfalls nicht gebacken bekommen.

Was aber leider größtenteils simple und grundlegende OS X Funktionalitäten vernebelt und einen auf der Leiter des wissenden Serveradmins exakt NULL Sprossen nach oben bringt.

Nein. Widerspruch.
Man muss wissen, was man da tut, was es auslöst, was es bedeutet.

Ob ich dann meine configdatei per vi, patch oder write bearbeite, oder ob ich mir das Häkchen setze, ob ich das lokal oder per ssh oder ARD oder vnc mache, ist dann egal. Das es dabei "k3wl" aussieht, bringt mich nicht weiter.

Irgendjemand hat mal über Gentoo Linux gesagt: "Watching shit scroll doesn't make you an unix geek.". Richtig. Ich muss den shit auch verstehen. Und wenn ich ihn verstanden habe, kann ich mir auch vorkompilierte Pakete per grafischem Paketmanager einspielen, weil ich begriffen habe, das 3% mehr Speed für optimierte Binaries völlig egal sind.

Ich mache viel und gern im Terminal rum, aber wenn ich mit einem Kreuzchen genau das machen kann, was ich will, dann mache ich das auch gern.

Gruß,
Jörg

 

[slowfranklin]

Nein. Widerspruch.
Man muss wissen, was man da tut, was es auslöst, was es bedeutet.

Ob ich dann meine configdatei per vi, patch oder write bearbeite, oder ob ich mir das Häkchen setze, ob ich das lokal oder per ssh oder ARD oder vnc mache, ist dann egal. Das es dabei "k3wl" aussieht, bringt mich nicht weiter.

Das passt jetzt aber nicht zu dem was du ursprünglich als "Hilfe" gepostet hast. Derjenige dem du das GUI an den Kopf geworfen hast, weiss ja eben nicht was er da tut.

Ralph

 

[MaxS]

Statt des derzeitigen Mechanismus, der stündlich jeden Kram von Apple spiegelt, inklusive MASSEN an Kram für Hard/Software, die wir überhaupt nicht besitzen, hätte man sowas prima über einen Proxy regeln können. Ein Client triggert das ziehen des Updates, alle weiteren bekommen es vom lokalen Server, und unnötige Pakete werden so gar nicht erst getriggert. Ältere Mac OS wären dann automatisch ebenfalls in den Genuss des lokalen Updates gekommen, und Server wie z.B. adobe.com könnte man gleich dazu eintragen.
Leider verwendet Apple ein Lastverteilungssystem (Ich glaube, es war Akamai), und so ist mit einem Squid nix zu wollen. Ich habe es jedenfalls nicht gebacken bekommen.

Willkommen in der Profiwelt der sicheren Verteilungssysteme.

Alle Softwarepaket von Apple werden signiert übertragen. Daher ist ein einfacher Proxy wie Squid nicht in der Lage diesen Inhalt zu cachen, da die Signaturen der Softwarepakete nicht mehr stimmen würden.

Ich hoffe das hilft etwas zu verstehen warum das so gemacht wird. Macht Microsoft übrigens auch nicht anders wenn man deren Updateserver verwendet.

Die Alternative wäre der Linux-way, bei dem einfach überall Pakete verteilt werden und man über eine einfache MD5 Prüfsumme überprüft, ob das Paket passt oder nicht. Nachteil: keiner kann wirklich sicher sein, dass Paket und Prüfsumme wirklich von dem Server sind, von dem Du es geladen hast! Das mag bei einfachen Paketen keine Rolle spielen (wer will schon den Verteilungsserver für bspw. TaylorUUCP hacken um ein gefälschtes Einzelpaket in Umlauf zu bringen) aber bei hochfrequentierten Sites (und Apple ist definitiv dazu zu zählen) wäre es eine Superidee für Hacker, mal eben die Seite umzuleiten, ein Update reinzustellen mit modifizierter MD5 das dann ganz andere Sachen auf Deinem Server macht als Du vorhattest ;-)

Eine extra Mechanismus zu implementieren, der checkt, welche Updates jetzt wirklich in den Cache gehen sollen und welche nicht, macht im Verhältnis zur Einsparung bezogen auf die Bandbreite überhaupt keinen Sinn mehr. Wir leben ja auch nicht mehr im letzten Jahrtausend als es noch hauptsächlich Modems gab ....

Runterladen und einzeln Verteilen geht natürlich auch weiterhin ;-)

Kannst jetzt gerne nochmal erklären was da nicht "ganz durchdacht" worden sein soll. Deine vorgeschlagene Alternativmethode empfinde ich aber definitiv nicht als besser.

viele Grüße, Maximilian.

 

[ratti]

Das passt jetzt aber nicht zu dem was du ursprünglich als "Hilfe" gepostet hast. Derjenige dem du das GUI an den Kopf geworfen hast, weiss ja eben nicht was er da tut.

Muss er ja auch gar nicht. Warum sollte er auch? Der Anspruch, man müsse irgendwie auf einer "Adminleiter" nach "oben" steigen, wurde von dir formuliert, nicht von mir. Ich habe lediglich widersprochen, dass ein Terminalbefehl nicht per se toller ist als ein Häkchen.

Gruß,
Jörg

 

[ratti]

Willkommen in der Profiwelt der sicheren Verteilungssysteme.

Alle Softwarepaket von Apple werden signiert übertragen. Daher ist ein einfacher Proxy wie Squid nicht in der Lage diesen Inhalt zu cachen, da die Signaturen der Softwarepakete nicht mehr stimmen würden.

Ich hoffe das hilft etwas zu verstehen warum das so gemacht wird. Macht Microsoft übrigens auch nicht anders wenn man deren Updateserver verwendet.

Die Alternative wäre der Linux-way, bei dem einfach überall Pakete verteilt werden und man über eine einfache MD5 Prüfsumme überprüft, ob das Paket passt oder nicht. Nachteil: keiner kann wirklich sicher sein, dass Paket und Prüfsumme wirklich von dem Server sind, von dem Du es geladen hast! Das mag bei einfachen Paketen keine Rolle spielen (wer will schon den Verteilungsserver für bspw. TaylorUUCP hacken um ein gefälschtes Einzelpaket in Umlauf zu bringen) aber bei hochfrequentierten Sites (und Apple ist definitiv dazu zu zählen) wäre es eine Superidee für Hacker, mal eben die Seite umzuleiten, ein Update reinzustellen mit modifizierter MD5 das dann ganz andere Sachen auf Deinem Server macht als Du vorhattest ;-)

Eine extra Mechanismus zu implementieren, der checkt, welche Updates jetzt wirklich in den Cache gehen sollen und welche nicht, macht im Verhältnis zur Einsparung bezogen auf die Bandbreite überhaupt keinen Sinn mehr. Wir leben ja auch nicht mehr im letzten Jahrtausend als es noch hauptsächlich Modems gab ....

Runterladen und einzeln Verteilen geht natürlich auch weiterhin ;-)

Kannst jetzt gerne nochmal erklären was da nicht "ganz durchdacht" worden sein soll. Deine vorgeschlagene Alternativmethode empfinde ich aber definitiv nicht als besser.

viele Grüße, Maximilian.

Moment. Zunächst mal sind z.B. *.deb Pakete auch signiert. Nein, ich meine nicht MD5, das dient lediglich zur Plausibilitätsprüfung, sondern eine gnupg-Signatur.

Zweitens wird ein Paket durch einen Proxy nicht verändert. Als Gegenbeispiel: Du kannst dir ja Updates auch per Browser herunterladen, da kämmen sie dann bei einem Zweitversuch auch aus dem Cache. Eine Signatur wird durch den Download nicht verändert.

Übrigens ist ja anscheinend auch der lokale Softwareserver eine ganz normale http-Verbindung.

Das man nur "mal eben" die Apple-Site hacken müsste, um gefakte Pakete einzustellen... naja, jetzt muss man eben "mal eben" akamai hacken oder "mal eben" einen Key klauen. Sowas ist eben nicht "mal eben". Was ich aber wirklich relevant finde: Die schwächste Stelle bei der Softwareverteilung ist garantiert das Intranet. In der Regel brauchst du in einem kleinen Unternehmen bloss einen eigenen DHCPd starten, und das Netz gehört dir.

Als "durchdacht" empfinde ich deb/apt.
- Beliebige Quellen
- Trotzdem Schutz vor veränderten Paketen durch Signatur
- Ein grosses Sammelsurium von Tools
- Zugang nicht nur zum Client, sondern auch zum Server
- Basierend auf gängigen Technologien: http, ftp, rsync, file,...
- Dadurch praktisch von selbst Unterstützung von Proxies etc.

...und wenn du willst, kannst du dir das eben doch alles so konfigurieren, dass es nur über sichere Kanäle läuft oder nur dem Distributor vertraut.

Gruß,
Jörg

 

[rookie]

lädt der server eigentlich jedes verfügbare update herunter, oder schaut der was sich im netzwerk für clients tummeln, und passt das ein wenig den bedürfnissen an?
sprich: wird irgend ein final cut pro update oder ein logic update auch heruntergeladen, obwohl wir diese programme garnicht haben...

 

[Flo87]

Hallo,

lädt der server eigentlich jedes verfügbare update herunter, oder schaut der was sich im netzwerk für clients tummeln, und passt das ein wenig den bedürfnissen an?
sprich: wird irgend ein final cut pro update oder ein logic update auch heruntergeladen, obwohl wir diese programme garnicht haben...

ja, dem ist (leider) so. Wurde weiter oben auch schon angesprochen, ist im Grunde nicht so geschickt gelöst, da dadurch der Initial-Traffic zum Aufbauen eines Archivs sehr hoch ist...

Gruß, Flo

 

[ratti]

ja, dem ist (leider) so. Wurde weiter oben auch schon angesprochen, ist im Grunde nicht so geschickt gelöst, da dadurch der Initial-Traffic zum Aufbauen eines Archivs sehr hoch ist...

„Hoch“ ist gar kein Ausdruck.

# du -csh /usr/share/swupd/
4.4G

Die Verrückten…

Gruß,
Jörg

 

[MaxS]

„Hoch“ ist gar kein Ausdruck.

# du -csh /usr/share/swupd/
4.4G

Die Verrückten…

Nanana,

Würde eher sagen: RTFM. Wer liest hat mehr vom Leben:

• Du musst nicht jedes Update auch gleich spiegeln! Dafür gibt es eine kleine Option, die genau das verhindert. Der Softwarekatalog nackt belegt knapp 30MB.
• Nur die gespiegelten Updates belegen demnach auch Platz!
• Vielleicht solltest Du mal alte Updates deaktivieren?

4.4G ist ja nix. Plattenplatz kostet doch nichts mehr, meine Zeit schon. Man lebt halt bequem, deshalb spiegelt man einfach alles. Die Alternative ist eine manuelle Pflege und Überprüfung der zu spiegelnden Daten.

Wenn bei uns die 150 Macs das aktuelle Update mit 140MB runterladen sind das 20.5GB. Traffic gespart: knapp 15GB. Und das bei nur einem Update! (und ich hab auch keine 4.4GB sondern 3, und da ist schon alter Kram mit dabei)

Ich weiss nicht was Ihr habt. Für das kleine Netzwerk zu Haus lohnt es sich vielleicht nicht, trotzdem bin ich froh, dass es diese Funktion überhaupt gibt.

Viele Grüße, Maximilian.

 

[ratti]

Würde eher sagen: RTFM. Wer liest hat mehr vom Leben:

• Du musst nicht jedes Update auch gleich spiegeln! Dafür gibt es eine kleine Option, die genau das verhindert. Der Softwarekatalog nackt belegt knapp 30MB.

• 
  
  Nix RTFM.
  Das ist schon klar, aber die Funktion ist nutzlos, wenn man manuell hinterherhühnern muss, was gespiegelt wird und was nicht.
  
  Sinnvoll wäre eine Automatisierung mit Vorfilterung nach Plattform (ppc/i (hier nur ppc)), Hardware (keine XServes im Haus) und Kategorie (Keine Videschnittsoftware etc im Hause...)
  
  
  

  4.4G ist ja nix. Plattenplatz kostet doch nichts mehr, meine Zeit schon. Man lebt halt bequem, deshalb spiegelt man einfach alles. Die Alternative ist eine manuelle Pflege und Überprüfung der zu spiegelnden Daten.

  Hier dassselbe. Das RAID hat 2,5 TB, da tut die Systemlast beim Updaten eines Clients schon mehr weh als der Plattenplatz.
  
  Mich nervt einfach generell, das dieser ganze Workflow so unpraktisch und unflexibel hingwepfuscht ist, obwohl bessere Lösungen in freier Software schon viel länger existieren - eine kleine GUI, und das wärs gewesen. Stattdessen dieses Ding, und dann sogar nur als Server-Feature.
  
  Wie man das besser macht, habe ich weiter oben schon beschrieben.
  man apt.
  
  
  
  Gruß,
  Jörg

 

[MaxS]

Sinnvoll wäre eine Automatisierung mit Vorfilterung nach Plattform (ppc/i (hier nur ppc)), Hardware (keine XServes im Haus) und Kategorie (Keine Videschnittsoftware etc im Hause...)
Mich nervt einfach generell, das dieser ganze Workflow so unpraktisch und unflexibel hingwepfuscht ist, obwohl bessere Lösungen in freier Software schon viel länger existieren - eine kleine GUI, und das wärs gewesen. Stattdessen dieses Ding, und dann sogar nur als Server-Feature.

Sorry, aber Dich nervt es, dass Du keine superfeinen Einstellungsmöglichkeiten hast nur um 1GB Download / Jahr zu sparen???
Dich nervt es, dass das ein Serverfeature ist, obwohl es im Client überhaupt keinen Sinn machen würde?

Sorry, aber ich kann Deine Argumente echt nicht nachvollziehen. Auf der einen Seite sagst Du, dass der Workflow zu schlecht ist, weil er zu viel Daten runterlädt, auf der anderen Seite gibst Du zu, dass das bei einem 2.5T RAID überhaupt keine Rolle spielt. Was nun?!

Klar kann man alles irgendwie noch ausgefeilter und irgendwo besser machen. Es muss halt im Verhältnis bleiben.

Was würde es mir bringen, den Workflow nach Deinen Angaben zu "verbessern" ??? Ich sag's Dir: Mehr Arbeit! Und zwar für MICH!! Nur um der Firma vielleicht 1-2GB Download pro Jahr zu sparen? Geht's noch?!

Wie gesagt, mir ist es lieber so. Warum sich mit tausend Einstellungen rumschlagen, das ist doch gerade die Apple Philosophie.

Bei Deinem Vorschlag muss man permanent darüber informiert werden, welche neue Hardware beschafft wurde, welche Software, etc. und schon muss man wieder überprüfen ob der Filter nach Hardware und Software überhaupt noch passt.

Alleine diesen Thread zu führen kostet mehr Zeit als ein Update im Software Update Server zu spiegeln.

Nein, lieber so wie es ist.

viele Grüße, Maximilian.

P.S.: daneben steht es natürlich jedem frei seinen eigenen Filter über den Software-Update Katalog zu bauen. Das Download-Verzeichnis ist nur ein XML File das auch extern editiert werden kann. So kann man bspw. im ServerAdmin alle Downloads deaktiviert lassen und Dein Skript prüft dann nach Deinen Kriterien und aktiviert selbst die Einträge im Katalog, fertig.
Wenn Du meinst, das lohnt sich, wirst Du als UNIX-Geek das sicherlich in höchstens 1 Tag erledigt haben.