Prüfmethoden für Updates

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1269574)

Darum nimmt man oft einen Dienst.

Na toll... wenn Jede Software auf meinem Rechner einen Dienst für Updates starten würde wäre mein Rechner schon ausgelastet. :stupid:

Ne Spass bei Seite... Aber wenn eine Software XY immer einen Dienst installieren würde... No go...

Mavarik

[himitsu]

Joar, drum wäre es schon schön, wenn sich mehrere Programme einen gemeinsamen Updater teilen würden.

Aber Firefox/Thunderbird nutzen einen "gemeinsamen" Service, welcher standardmäßig inaktiv ist und so keinerlei Resourcen verbraucht (außer auf der Festplatte) und der sich nach dem Update auch wieder beendet.
> Mozilla Maintenance Service > Starttyp = manuell > wird bei Bedarf vom Firefox gestartet, nachdem das Update gefunden und runtergeladen wurde

Im Gegensatz dazu z.B. der schrottige Acrobat-Updater (OK, nach einer Woche Laufzeit 00:00:00 CPU und knapp 4 MB RAM, aber wenn das jeder so macht, dann läppert es sich dennoch)
> Adobe Acrobat Update Service > Starttyp = Automatisch > immer durchgehend aktiv

Der Adobe-Flash-Updater ist aber auch standardmäßig aus. :gruebel:

Der Windows Update Service liegt dabei schon bei 'ner 1/4 Stunde und belegt 50 MB.
Bei 10 solchen Updatern wäre das ja nur ein halbes GB und fast 3 Stunden verschwendete Rechenzeit = 22 Minuten pro Tag.

Und so selten wie ich OpenOffice verwende, hab ich erstmal deren mistigen Beschleinigungsdienst entfernt (so wie auch von anderen Programmen), welcher deren Dateien schön im Cache hält und so andere Dinge runterwirft, nur um dann schneller starten zu können.

[QuickAndDirty]

Es ist in gewissen Szenarien sinnvoll im Update/Setup die Hashs aller ausgelieferten Dateien mitzuführen und vor dem Update zu prüfen.
Auf diese Weise kann man z.B. feststellen ob ausgelieferte Dateien verändert wurden. Evtl. hat es die Anwender ja viel Mühe gekostet diese anzupassen.

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1269628)

Aber wenn eine Software XY immer einen Dienst installieren würde... No go...

Was passiert, wenn der Benutzer selbst die Updates starten oder bestätigen muss sieht man ja oft auf PCs, die Virenbefall haben... ich zumindest. Uralter Firefox, bei dem es schon reicht auf eine befallene Seite zu gehen, usw.
Deshalb kann das ja optional sein, aber standardmäßig ist das besser als ohne.

[himitsu]

Bei Programman die man oft nutzt, die ständig neuen Gefahren ausgesetzt sind und die man standardmäig sowieso immer aktuell halten sollte, ist ein AutoUpdater schon sinvoll.
(der sich auch abschalten lässt, für die, welche unbedingt nicht wollen)
> das UAC stört nicht ständig
> und die ohne nötige Rechte ... da muß immer jemand Anderes das machen
> ohne UAC müsste man ständig manuell nachsehn

[Dejan Vu]

Wie immer kommt es auf den Einzelfall an:
a) Kommerzielle Software, die auf anonymen Rechnern mit diversen Rechteszenarien läuft?
b) LOB-Software im Betrieb in einem homogenen Sicherheitskontext?
c) Individualsoftware bei wenigen Kunden?

An einen Update-Service würde ich bei b) und c) nicht mal denken (d.h. ausschließen aber auch nicht).
Selbst bei a) würde ich persönlich von einem Dienst abraten, einfach weil ich die Rechner der Kunden mit Zusatzprogrammen nicht zumüllen will. Natürlich haben die ihre Berechtigung und es ist nur dieses sehr subjektive Argument, welches mich zum 'Gegner' von Updateservices macht.

[TheMiller]

Hallo und danke für die vielen Antworten. Konnte leider nicht eher antworten - was das Wochenende im Urlaub.

Einen Update-Service werde ich nicht programmieren/installieren. Update-Dienste halte ich nur bei Programmen sinnvoll, die weit verbreitet und beliebte Angriffsziele sind, z.B.: Flash, Java, Browser etc.

Ich habe mich entschieden, die Updates über einen Installer auszurollen. Bei Programmstart wird die aktuell installierte Version über eine Datei ausgelesen, mit dem Server verglichen und das dazugehörige Update heruntergeladen. Die Installationsdatei wird geöffnet und erledigt die notwendige Logik. Der Updater ist also - wie vorgeschlagen - "dumm". Um Manipulationen zu verhindern, wird das jeweilige Programm die Hashes in zufälligem Intervall vergleichen. Dabei soll dies keine Umsetzung eines Kopierschutzes sein.

Im Vergleich zu meiner bisherigen Lösung sollte diese nun viel leichter zu verwalten sein. Zwar war die Prüfung pro Datei eine funktionierende Lösung, aber wirklich umständlich zu benutzen.

Demnach wird es demnächst so von statten gehen:

1. Programmiererzeugnisse und Abhängigkeiten in den Release-Ordner verschieben (wenn nicht bereits getan)
2. Rollout erzeugen (zB: via InnoSetup)
3. via Oberfläche eine update.ini erzeugen und automatisch veröffentlichen lassen
4. Benutzer startet sein Programm
5. Updater vergleicht remote-Versionskennung (aus updates.ini) mit lokaler Versionskennung aus Datei/DB. (Versionskennung könnte Build-nr, timestamp etc. sein)
6. Wenn sich diese unterscheiden, läd der Updater das Rollout herunter (Datei entimmt er der updates.ini)
7. Nach dem Download wird das Rollout mittels Hash verifiziert.
8. Das Rollout wird installiert bzw. Daten werden entpackt (je nachdem ob portable oder fest installiert)
9. Programm wird wieder gestartet.

Habe ich etwas wichtiges vergessen oder nicht bedacht? Das müsste doch eigentlich so in Ordnung und dennoch recht flexibel sein, oder?

Danke!

[Dejan Vu]

Gibts da nix Fertiges? Wenn nicht, wäre das nicht mal ne Idee?

[TheMiller]

Ich habe schon mal was fertiges gesehen, aber ich glaube, das kostet Geld. Ich programmiere das mal soweit fertig, wenn Interesse besteht kann ich es ja vllt. teilen.

[generic]

Zitat:

Zitat von Dejan Vu (Beitrag 1269805)

Gibts da nix Fertiges? Wenn nicht, wäre das nicht mal ne Idee?

Einen universellen Updater gab es mal von InstallShield. Der konnte auch mehrere Programme mit Updates versorgen.
http://consumer.installshield.com/work_um.asp

Das Windows Update lässt sich auch übrigens erweitern, allerdings kann ich nicht sagen ob das wirklich für eigne Updates taugen wird (ohne Domäne).