Softwareinventur mit Effekt auf OPSI-Backend

[TheAngryCube]

Moin moin,

hat sich über das Topic schonmal jemand Gedanken gemacht oder gibt vielleicht eine entsprechende Funktion bereits?


Hintergrund:
Ich will OPSi in einer vorhanden Umgebung ausrollen. Die Softwarepakete wurden erstellt. Jetzt möchte ich natürlich die neuen Clients in OPSI, die ja in der Regel schon einen Teil der Softwarepakete installiert haben, auf den enstprechenden Status setzen.

Grüße
Jan

[tobias]

interessante Idee die hier sicher schon viele hatten.

Fänd ich auch super. Wir rollen auch in bestehender Umgebung aus bzw. pushen den Client bei bedarf auf vorhandene Rechner. Da wäre das sehr interessant.


Ich stell mir das so vor:
SWaudit wird durchgeführt und man kann in der Liste dann die Software markieren und einem OPSI Paket zuweisen OPSI merkt es sich und setzt nach jedem weiteren SWaudit die entsprechenden Pakete automatisch auf installed.

[ueluekmen]

Hallo,

über dieses Thema haben wir auch schon oft Diskutiert, allerdings müsste man immer manuell eingreifen. Besser fänden wir ein automatisches Verfahren. Dafür muss es aber ein Mapping: Softwarepattern aus dem opsi-swaudit und productId geben. Wenn man dieses mapping hat, kann man auf dem Server ein kleines Skript bauen welches die swaudit Daten schnappt und entsprechende Stände in ProductStatis patched. Wir haben das für einen Kunden schon mal gemacht und es hat die Aufgaben des Kunden erledigt. Ich habe aber länger nichts mehr davon gehört, aber ich denke die Lösung liegt in dieser Richtung. Wenn man ein Einheitliches Verfahren hat, könnte man das Mapping zentral am Server ablegen und eventuell dem swaudit übergeben, der diese Aufgabe dann automatisch beim Scannen "mit" erledigt.

Folgende Fragen waren bei der letzten Disskussion noch offen:
1.) Software kann auch doppelt auftauchen (nicht genau identifiziertbar)
2.) Eine Software die "installiert" im System angezeigt wird, muss nicht funktionsfähig sein, es wird an der Stelle keine Qualitative Prüfung vorgenommen.
3.) Software-Versionsstände mit Berücksichtigen?

Vielleicht hat ja jemand eine Lösung und kann Sie im Wiki präsentieren, andererseits gilt unser Leitspruch: Für Geld tun wir "fast" alles

[TheAngryCube]

Ich denke gerade auf einer "zügig" zu realisiereden Lösung/Workaround rum.
Meine Gedanken bis jetzt:

1. Ich füge meinen eigenen Produkten eine Property mit dem Namen des RegistryKeys aus dem Uninstall-Tree hinzu. Das ist dann entweder ein Name oder der MSI-ProductCode und gleich dem Namen in der swaudit-Tabelle
2. Ich erstelle ein neues Produkt (zb swaudit_setInstalledStatus)
- Abhängikeit zu swaudit -> setup -> before . Damit würde swaudit einmal laufen
- Abfragen aller Products
Methode getProductIds_list -> DefStringList $IDs$
- Parsen durch $IDs$ mittels for-Schleife
Methode getProperties_hash %i% Damit bekomme ich alle Properties pro Produkt. Ich ziehe meinen RegistryKey-Namen heraus
- Holen des Client-Namens auf dem das Skript läuft mit %HostID%
- Abfragen der swaudit-Tabelle
Methode getSoftwareInformation_hash %HostID% -> DefStringList $Software$
- Parsen durch $Software$ mittels for-Schleife
WENN $Software$.windowsSoftwareID == %i%.RegistryKey DANN Methode setProductInstalledStatus = TRUE

Man könnte evtl auch noch die installierte Version mit der ProductVersion vergleichen und falls kleiner das Product auf Setup/Update setzen
Ich hoffe man kann es einigermaßen nachvollziehen. Was meint ihr dazu?

Grüße
Jan

[ueluekmen]

Als gedankenschubs...

Wir haben das "fast" so umgesetzt wie du es beschrieben hast.

Nur haben wir die Keys von der Registry direkt in das neue Produkt geschrieben und nicht in jedes einzelne Paket mit aufgenommen. Das Paket hat soweit ich mich erinnere auch nicht die Daten aus dem swaudit verwendet, sondern gleich die Registry befragt. Das Skript ist auch vom Kunden begonnen und von uns zum fliegen gebracht worden, da diese Versionen sehr Kundenspezifisch war/ist, macht es auch keinen Sinn dieses Skript zu veröffentlichen...

Aber vielleicht ist dein Skript so ein Kandidat.

PS.: Bedenke die Architektur.
PPS.: Aber eine allgemeingültige, konfigurierbare Lösung wäre schöner an der Stelle, aber man kann nicht alles haben.

[TheAngryCube]

Mir ging es bei meinem Vorgehen in erster Linie darum, es möglichst Update-Sicher zu machen. Deswegen wollte ich möglichst keinen Code von Euch anpacken.
Man hätte ja z.B. auch ein neues Feld in die OPSI/control einfügen, sprich opsi-newprod etwas anpassen können um den RegistryKey einzufügen. Oder auch neue Felder/Tabellen im MySQL-Backend erstellen können. Man weiß aber nie ob es nach einem Update noch läuft...

Grüße
Jan

[TheAngryCube]

So...mein Skript wächst und gedeiht. Ich bin jetzt aber auf das erste Problem gestoßen.

Auf meinem Testclient ist Adobe Acrobat 9 installiert. Diese legt unter [HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall] folgende Keys an:

{ac76ba86-1033-f400-7760-000000000004}
{ac76ba86-1033-f400-7760-000000000004}_930
{ac76ba86-1033-f400-7760-000000000004}{ac76ba86-1033-f400-7760-000000000004}

Der erste wäre der den ich brauche.
Interessanterweise kegelt swaudit gerade diesen beim Zurückschreiben ins Backend aus den Ergebnissen. In der LogDatei wird der Schlüssel gefunden, in die MySQL-Datenbank wird er jedoch nicht geschrieben. Ich vermute, dass ihr hier irgendeine Sicherung vor doppelter Software eingebaut habt. Nur leider haut er den falschen Eintrag weg. Soll er den 3. raushauen....

Irgendeine Idee?

[d.oertel]

Hi,

sende mir doch mal einen Export der drei Keys als .reg an d.oertel(at)uib.de

gruß
d.oertel

[TheAngryCube]

Gibt es schon etwas Neues?

Grüße
Jan

[d.oertel]

Hi,

der 'primary key' für einen Software Inventarisierungs Eintrag ist derzeit
name, version, subVersion, language, architecture
Wobei als 'name' der DisplayName genommen wird, so vorhanden.
Das führt dazu, dass Dein erster und dritter Eintrag aus Sicht von opsi identisch sind
und daher der dritte den ersten überschreibt.

Ich denke drüber nach ob diw windows_software_id noch in den primary key aufgenommen werden sollte. Dazu die Frage:
Abgesehen davon, dass der dritte Eintrag sowieso hässlich ist:
Was ist denn beim ersten besser als beim dritten ?

gruss
d.oertel