forum.opsi.org

Hallo,

gibt es einen "OPSI-korrekten" Weg, zentrale Skripte und Einstellungen zu verwalten? Ich habe z.B. eine Funktion, welches die Version eines Files abruft. Im Moment ist sie als Unterprogramm "sub_GetFileVersion" in jedem einzelnen Installationsskript definiert. Das fuehrt ueber kurz oder lange zu Wartungsproblemen (z.B. sobald man einen besseren Mechanismus implementieren moechte). Ich haette diese Funktion gerne in einem zentralen (d.h. fuer alle Installationsskripte zugaenglichen) Ort, von wo man es mit "sub MeineFunktion.sub" laden kann.

Ich have etwas herumprobiert und es ist z.B. moeglich, das File in /opt/pcbin/install/MeineFunktionen/GetFileVersion.sub" unterzubringen und es danach mit "sub "%SCRIPTPATH%\..\MeineFunktionen\GetFileVersion.sub" zu laden. Nur ist diese Variante unschoen "an OPSI vorbei" implementiert. Gibt es einen "offiziellen" Weg, so etwas zu implementieren?

Gruss
frank

Sehr interessante Idee. Ich glaube nicht, dass es eine solche Funktion in OPSI/WINST schon gibt.
Wäre aber sehr interessant wiederkehrende Aufgaben in Subroutinen auszulagern und diese Zentral im WINST zur Verfügung zu stellen.

Deine Variante funktioniert sicherlich aber wie du schon sagtest nur ein Workaround, denke ich an VPN/WAN würde diese Variante nicht funktionieren weil andere Ordner außer der Paketordner werden ja nicht gecached.

Hi,

nein eine offizielle Lösung gibt es dafür noch nicht, auch wenn ich über die Problematik auch schon nachgedacht habe.

Meine erste Idee wäre es ein opsi-Produkt 'opsi-winst-library' (mit hoher Priorität) zu machen,
über das die ausgelagerten Scripte z.B. nach 'C:\opsi.org\library' kopiert werden.

Dies hätte folgende Vorteile:
- ein solches Paket kann gut weitergegeben werden.
- ein solches Paket könnte auch von der Community im svn gepflegt werden.
- ein solches Paket würde auch über die WAN-Erweiterung funktionieren.
- die Bibliotheken würden lokal liegen, was sicherer ist und z.B. auch mit Scripten im Kontext eines lokalen admin funktioniert.

Wenn es hier (und bei uns in der Entwicklersitzung) hierzu eine Einvernehmliche Lösung gibt,
können wir auch drüber nachdenken ob ein solches Paket ähnlich wie der opsi-winst automatisch upgedatet wird.

gruss
d.oertel

d.oertel hat geschrieben:Hi,

nein eine offizielle Lösung gibt es dafür noch nicht, auch wenn ich über die Problematik auch schon nachgedacht habe.

Meine erste Idee wäre es ein opsi-Produkt 'opsi-winst-library' (mit hoher Priorität) zu machen,
über das die ausgelagerten Scripte z.B. nach 'C:\opsi.org\library' kopiert werden.

Dies hätte folgende Vorteile:
- ein solches Paket kann gut weitergegeben werden.
- ein solches Paket könnte auch von der Community im svn gepflegt werden.
- ein solches Paket würde auch über die WAN-Erweiterung funktionieren.
- die Bibliotheken würden lokal liegen, was sicherer ist und z.B. auch mit Scripten im Kontext eines lokalen admin funktioniert.

Wenn es hier (und bei uns in der Entwicklersitzung) hierzu eine Einvernehmliche Lösung gibt,
können wir auch drüber nachdenken ob ein solches Paket ähnlich wie der opsi-winst automatisch upgedatet wird.

gruss
d.oertel

Das waere eine Moeglichkeit. Wichtig ist aber, dass man das Paket mit eigenen Skripten erweitern koennte. Ich weiss nicht, ob das mit Paketen gut geht, die direkt von OPSI/UIB kommen? Abgesehen davon, dass sie mit jedem Update wieder ueberschrieben wuerden. Pflegen im svn ist OK, aber es gibt Sachen, die definitiv nur fuer die eigene Umgebung passen und die man nicht weitergehen kann oder will. Der Pfad zu dieser Library waere dann sinnvollerweise ueber eine Konstante anzusprechen (%OPSILIBRARYPATH% o.ae.).

Man koennte sich als alternative Variante ueberlegen, ob man Pakete als "global" markieren kann, was zur Folge haette, dasss sie bei Verwendung der WAN-Erweiterung lokal zwischengespeichert wuerden. In Kombination mit einer neuen OPSI Funktion GetPackagePath($PAKETNAME$), haette man so eine sehr flexible Loesung.

Fuer die WAN-Erweiterung - die ich selber nicht kenne - koennte man evtl. als zugegebermassen unschoene Zwischenloesung fuer alle Pakete eine Abhaengigkeit von einem "Library-Paket" definieren, so dass es auch lokal gecacht wird, und sie dann ueber den relativen Pfad %SCRIPTPATH%\..\ ansprechen.

Gruss
frank