forum.opsi.org

Hallo liebe OPSI Freunde,

prinzipiell würde ich gern viel mehr Scripte in das OPSI-Wiki einbringen. Die Einträge die bereits hinterlegt sind, sind aber teilweise sehr veraltet, siehe Firefox.
Deshalb würde ich gern etwas vorschlagen. 90% der Daten für die einzelnen Installer Dateien sind gleich.
Wenn man diese in eine separate Datei verpackt und diese dann per einfügt, könnte man sich, denk ich viel Arbeit ersparen und dennoch Anpassungen vornehmen. Das soll nur mal eine Diskussionsgrundlage sein. Das gleiche kann man übrigens auch für den Uninstaller nehmen.
Der Installer für den AcrobatReader könnte dann wie folgt aussehen. In dem Beispiel habe ich auch noch den Exitcode als eigene Datei abgelegt, da dieser ja eigentlich universal ist.
Ich weiß, dass es bei vielen Dingen Anpassungen geben muss aber diese könnte man ja separat dokumentieren. Ich finde z.B. bei den meisten existierenden Installern die Überprüfung auf genug Plattenplatz relativ sinnfrei, da der Computer bei weniger als 40 MB Speicherplatz sehr ernste Probleme mit seinem Rechner hat. Aber auch diese Überprüfung könnte man auslagern.
Ich komme aus der Programmierschiene deshalb versuche ich auch hier so etwas wie "Funktionen" aus zu lagern. Ich weiß nicht ob das mit OPSI so geht und ob es Sinn macht, aber in jedem Installler 90% des Codes einfach zu kopieren erscheint mir auch nicht einleuchtend.
Mein Vorschlag wäre, dass wir diese zentrale Dateien im Wiki ablegen und diesen dann von den einzelnen Installern darauf verweisen.

tja, das wird ja sicherlich jeder von den "Scriptern" schon ein wenig machen.
Andere (und auch ich) legen sich von dir angesprochene Funktionen und Teilscripts
unter einem festen Pfad ab. Es scheint sich ja dafür eingebürgert zu haben.

Erst seit WINST 4.11.3 sind "include_append / include_insert" verfügbar, die diese Vorgehensweise erleichtern. Logischerweise sind ältere Scripts aus dem Scriptarchiv wiki/userspace:script_templates noch recht monolithisch.

Derartige Bestandteile einer Library werden ja teilweise unter
wiki/userspace:opsiscript_library veröffentlicht, ich würde einige aus dem normalen Scriptarchiv z.B. check_NNNN-exitcode.ins dort eher vermuten.

Aber WINST selbst ist ja vom Ansatz her eine interpretierte Scriptsprache, daher sind Funktionsdeklarationen, Kapselung von Variablen usw. sicherlich noch ein weiter Weg.

Ja wir machen das ebenfalls so.

Allerdings ist es für das Wiki irgendwie sinnfrei wenn jeder anfängt seine libraries einzubinden und sie dann zusätzlich nochmal dokumentiert.
Am Ende haben wir mehrere libs die alle die gleiche Funktion bieten.

Was Winst meiner Meinung nach tatsächlich fehlt ist eine ausgebaute stdlib die solche Funktionen standardisiert. Das muss aber optimaler Weise auf ebene der DSL passieren.
In letzter Zeit wurde ja hier viel Arbeit in String-Funktionen investiert.
Wenn Winst nativ Metafunktionen hätte wie:

checkDiskSpace("C",20)
checkExitCode("msi")
checkExitCode("innosetup")

Bräuchten wir wenig selbst gebaute libs was es wiederum erleichtern würde Scripte ins Internet zu werfen ohne eine ausschweifende Erklärung was die Abhängigkeiten sind.
Dinge die jeder selbst brauchen wird und jeder irgendwie anders abbilden wird gehören in eine stdlib.

Das wäre eigentlich so ein Projekt für die Community eine stdlib zu pflegen. In dem Fall könnte das dann auch komplett in Winst geschrieben sein.
Hier würde dann allerdings in Winst die Möglichkeit fehlen Funktionen zu definieren die mit Argumenten arbeiten. Außerdem müsste UIB ab einem gewissen Reifegrad die stdlib standardmäßig mit Winst ausliefern sonst hat das ganze Projekt keinen Sinn.

Außerdem gibt es dann noch eine l10n Problematik.

@UIB gibt es eigentlich Pläne für einen Winst2 ( rein der Interpreter ) ?

Hi,

zur Frage nach der Weiterentwicklung des opsi-winst / opsi-script:

Die Weiterentwicklung soll in drei Zweigen parallel stattfinden:

4.11.4: Das ist der aktuelle stable Zweig hier kommen nur Bugfixes und kleine Änderungen

4.11.5:

• Erweiterungen für Linux
• Größere Änderungen ohne grundsätzlich Umbaumaßnahmen
• Methoden für das Händling von JSON Objekten insbesondere in Hinblick auf die Verwendung von opsi 4 (Objekt bezogene) opsi webservice Methoden
• Analog neue Methoden zum Umgang mit XML

4.11.6:

• Unterstützung von Funktionen mit Rückgabewert, Parametern, lokalen Variablen und was sonst noch so gebraucht wird um Funktions libraries zu schreiben.
• Konfigurationsdatei für die Festlegung von Defaults (z.B. Debuglevel). Dabei soll diese Konfigurationsdatei anlagog der Konfiguration des opsiclientd zentral vom Server per configs/Hostparameter steuerbar sein.
• Syntaxcheck Funktion
• Case Anweisung

Nein - ich kann im Moment noch nicht sagen wann welche Version fertig wird

@dkoch: Was meinst Du mit "rein der Interpreter"

gruß
d.oertel

d.oertel hat geschrieben: Die Weiterentwicklung soll in drei Zweigen parallel stattfinden:
4.11.4: Das ist der aktuelle stable Zweig hier kommen nur Bugfixes und kleine Änderungen
4.11.5:
4.11.6:

wow, das finde ich schon ziehmlich ambitioniert ... zumal ja WINST nicht der einzige Code im gesamten Projekt OPSI ist.
vielleicht ist ja in einem der Zweige auch noch Platz für eine CASE-Struktur

Hi,

ich habe die CASE Anweisung jetzt mal bei 4.11.6 eingetragen.
Wenn sich herausstellt das die implementierung wenig aufwendig ist dann wird es vielleicht auch 4.11.5.

Ja - wir sind ambitioniert !

gruß

d.oertel