Wunschliste für Opsi

[geos_one]

Hallo Opsi Devs,

1. opsi-product-updater
es wäre ien coole erweiterung wenn das tool auch ne z.b. readme.opsi vom repository runterladet und anzeigt. dadurch könnte der repo Bereitsteller kurze infos zum repo geben.

2. opsiconfd mit pre.d und post.d
jep sowas gibt es schon als einfache script anstarten und stopen in der opsiconfd.conf
diese idee ist ob wir nicht ein verzeichniss auch aufnehmen könnten pre.d post.d wo ein opsi paket dan ein script in pre.d und post.d ablegen kann. das dan von opsi vor und nach den action scripts ausgeführt wird.
gutes bsp. dafür sind antivieren software, desktop suche mit netzwerk support, .....

3. opsi packs mit gpg signatur
Jep dieser featerrequest ist schon älter.
dies ist auch eine erweitetung des opsi-product-updater damit er auch ein gpg file mit läd vom server und mit gpg keys die am system inatlliert sind verifiziert um die echtheit des packs zu bestätigen.
damit der Admin sicher sein kann das pack ist im zustand wie es sich der Paket Bauer vorgestellt hat.

mfg
Mario

[ueluekmen]

Hallo Mario.

erst mal danke für deine Vorschläge.

1. opsi-product-updater
es wäre ien coole erweiterung wenn das tool auch ne z.b. readme.opsi vom repository runterladet und anzeigt. dadurch könnte der repo Bereitsteller kurze infos zum repo geben.

Das solltest du noch mal genauer beschreiben. Wie stellst du dir so eine Repo-Datei vor? Was soll da drinstehen? Ist damit sowas ähnliches gemeint wie die repo-Dateien von Suse? Oder was ganz anderes?

2. opsiconfd mit pre.d und post.d
jep sowas gibt es schon als einfache script anstarten und stopen in der opsiconfd.conf
diese idee ist ob wir nicht ein verzeichniss auch aufnehmen könnten pre.d post.d wo ein opsi paket dan ein script in pre.d und post.d ablegen kann. das dan von opsi vor und nach den action scripts ausgeführt wird.
gutes bsp. dafür sind antivieren software, desktop suche mit netzwerk support, .....

Hiermit meinst du wahrscheinlich die opsiclientd.conf. Natürlich ist das kein Problem so etwas noch ein zu bauen, die Frage ist, ob sich der Aufwand lohnt. Man könnte ja auch alles über ein Skript machen. Viele opsi-Anwender verwenden den Mechanismus je nach Rechner auch anders. Zum Beispiel wird bei dem einen Rechner der Virenscanner deaktiviert und danach wieder aktiviert, bei einem anderen Rechner wird ein anderer Dienst gestoppt und danach gestartet, bei einem WTS-Server wird der WTS-Server in den install-mode gesetzt und später wieder in den execute-mode.... etc....

Wie unterscheidet man in so einem Fall? Dieses Verzeichnisse kann es ja nur einmal geben, ansonsten wird die Pflege auf seiten des Administrator unheimlich kompliziert.

3. opsi packs mit gpg signatur
Jep dieser featerrequest ist schon älter.
dies ist auch eine erweitetung des opsi-product-updater damit er auch ein gpg file mit läd vom server und mit gpg keys die am system inatlliert sind verifiziert um die echtheit des packs zu bestätigen.
damit der Admin sicher sein kann das pack ist im zustand wie es sich der Paket Bauer vorgestellt hat.

Die Paket-Signierung schwebt uns auch vor. Das wollen wir in einer der nächsten größeren opsi-Versionen auch angehen. Das Problem an der Stelle ist, dass die Pakete beim bauen signiert werden müssen. Das bedeutet, dass die Paketierung auch zum Teil komplizierter wird. Das ist der Hauptgrund, warum wir bis jetzt davon Abstand gehalten haben, denn die Paketierung mit opsi muss eher noch einfacher gemacht werden, als schwieriger. Wenn du dazu konkrete Vorstellung hast, wie so etwas ablaufen sollte, kannst du uns deinen Wunsch entweder hier oder über info(at)uib.de zukommen lassen. Dann wird das als Featurerequest im System abgelegt, aber in der Regel ohne bezahlten Auftrag niedrig priorisiert bearbeitet.

Ich hoffe das hilft dir erstmal weiter.

Grüße
e. ueluekmen

[geos_one]

1. die idee ist halt eine std txt file das im jeweiligen vez des reops liegt wo man ganz simple was reinschribt.

hier mal ein mokup wo das readme.opsi txt file in jedem unterortner aufgerufen wird:

Code: Alles auswählen

zeus lib64 # opsi-product-updater -ivv
Zsync command found: /usr/bin/zsync
Failed to read opsi modules file '/etc/opsi/modules': [Errno 2] No such file or directory: u'/etc/opsi/modules'
Disabling mysql backend and license management module: no customer in modules file
Reading config file '/etc/opsi/opsi-product-updater.conf'
Getting installed products
Getting info for local packages in '/var/lib/opsi/repository'
Getting package infos from repository 'http://download.uib.de'
###################### 4.0/stable #########################
This Repo contaions the actual Opsi 4.0.3 
....
###############################################
Getting package infos from repository 'http://opsi.disconnected-by-peer.at'
################### public/release ###############
The where some big changes to the tree layout .......
###############################################
........

also ohne pause und so
auch eine erweiterung des opis-update-packages --showreadmefirst oder so oder --downlaodreadmefirst

2. genau es sollte nur eine einfache variante sein z.b. c:\Programme\Opsi.org\...\pre.d post.d sein wo ein paket einfach was reinlegen kann z.b. .bat .cmd .EXE .ins das vor den installation jedes und nach der installationen aufgerufen wird. (.ins ist halt ein opsi script)
wie erwähnt das antiviren pack legt eine bat rein in pre.d z.b. immunet.bat mit inahlt net stop immunetprotect (und ein vergleichbares für das reaktieviren danach in post.d) also die verwschidensten packs legen dann dort wenn es nötig ist file rein gute bsp sind hat die erwähnten antivieren progs die die installs verlangsamen.

3. das ist klar das das nur niedrige priorittät hat
ich werd also mal meine build scripts um gpg signierung erweitern zum test des systems. (detach-sig http://www.gnupg.org/gph/en/manual/x135.html)
also die opsi files bleiben so wie sie sind es gibt halt ein neues file im reop pkgname.opsi.gpg
das einzige tool das verändert werden müsste ist der opsi-product-updater damit er das file downlaoded und via gpg dan das opsi file verifiziert mit den keys die beim opsiconfd user importiert wurden.
das ist halt meine idee für das einfach system um halt mal zu überprüfen das alles ok ist mit den packs.

deine variante ist halt die ausbau variante wo das apck selbst verschlüsselt ist und nur jemand der den key hat das apck entschlüsslen kann.

[geos_one]

Eine weitere nützliche Erwieterung ist die Möglichkeit im OPSI/control einen neuen [Documentation] Tag einzuführen wo der package Erstelle Einige aspekte des packs erklären kann
logischerweise sollte das dann auch im configed angezeigt werden (knopf für Doku und neues popup fenster)

[pandel]

@geos_one
Aber dafür gibt es doch bereits die Felder DESCRIPTION, ADVICE und ich kann mich auch noch im Changelog beschreibungsseitig austoben. Reicht das nicht? Gut, das Changelog wird im configed nicht angezeigt, aber dafür die beiden anderen... Was willste denn da bspw. alles zusätzlich dokumentieren?

[n.wenselowski]

Hallo Mario,

ich habe für das README-Feature und für das Verifizieren der Signaturen entsprechende Tickets im internen Bugtracker erstellt.

Bei pre.d/post.d stellen sich mir aber noch ein paar Fragen:
Die Scripte in pre.d werden vor jeder Installation ausgeführt, ohne irgendeine bestimmte Reihenfolge.
Und die in post.d dann wiederum danach, oder?
Muss ich immer ein post.d haben, wenn ich ein pre.d habe?
Was soll passieren, wenn der Rechner während einer Installation neu gestartet wird? Wird dann nach der Installation noch das post.d ausgeführt?


Gruß

Niko

[geos_one]

Also das pre.d post.d sollte jedesmal auch bei einem neustart ausgeführt werde
jep die scripte werden einfach alphabeitsch ausgeführt. 0-9 a-z
es muss nicth zu jedem pre auch eien post sein (hab zwar kein bsp dafür jetzt)

hauptsächlich kommen in den ortner pre und post halt scripte die den install von software in irgendeiner wise blokieren oder verlangsamen wie antivirus software ...

[geos_one]

@geos_one
Aber dafür gibt es doch bereits die Felder DESCRIPTION, ADVICE und ich kann mich auch noch im Changelog beschreibungsseitig austoben. Reicht das nicht? Gut, das Changelog wird im configed nicht angezeigt, aber dafür die beiden anderen... Was willste denn da bspw. alles zusätzlich dokumentieren?

jap das ist halt mal ne minimal doku aber mir geht es um eine etwas größere Doku zum paket.

z.b.
mein tightvnc.server pack spiegelt jede tightvnc option als property wieder.
das ist schon mal ok der user erkennt anhand der proeprtie namen was sache ist.
aber das pack hat eine spezial ertweiterung für opsi, also bei der ersten intsallation werden passwörter gesetzt für alle 3 möglichen passwörter und in opsi hinterlegt.
und sowas würde ich gerne in einer etwas besseren Beschreibung des Packs unterbringen. z.b OPSI/control documentation: readme.txt
die dan über eine button im configd zu erreichen ist.

meistens ist alles selbsterklärend aber wenn man mehr als einmal die gleiche frage beanwortet dann nerft das (ich glaube ihr wisst wovon ich spreche).

ist halt eine kleines feature request.