Liebe Kollegen,
leider ist die Doku von Opsi und das Zusammenspiel mit Linbo etwas dürftig (oder schwer zu finden 
).
Wenn man in die linbo_cmd schaut, wird anscheindend versucht, die zum cloop gehörige Datei mit der Endung .opsi herunter zu laden. Kann mir jemand sagen, die der Inhalt der datei aussieht / aussehen soll, kann, … Nicht, dass ich hier fleißig an Workarounds bastle, die man damit erschlagen kann …
VG
Wolfgang
Hallo Wolfgang,
leider ist die Doku von Opsi und das Zusammenspiel mit Linbo etwas
dürftig (oder schwer zu finden).
da hast du recht …
Das liegt wohl daran, dass kaum jemand OPSI bei uns einsetzt: linbo ist
einfach zu gut
Ich hab aber trotzdem mal ein wenig für dich gesucht und diese Seite
gefunden: ich hoffe, das hilft:
LG
Holger
Hi, erstmal danke :slight_smile
Dann … klar, Linbo ist super - aber …
Ich hab jetzt im Verwaltungsnetz „erfolgreich“ Linuxmuster im Hintergrund laufen. Leider wollen die Leitungsebene und das Sekretariat ihr Firefox-Profil dauerhaft haben, weil ja z.B. Zertifikate für’ OWA installiert sind und sie keines der Kennwörter für ihre Lesezeichen mehr wissen
So weit, so nachvollziehbar. Hab dann im Image nen festen Pfad für das Profile eingetragen, der auf
H:\Einstellungen\firefox\profile verweist und alles war gut … genau einen Tag lang, denn dann kam ein
Update von Firefox. Auf Windows hat FF einen Hintergrunddienst, der irgendwann das Update einspielt. Den kann man angeblich abwürgen und das wird wohl auch mein nächster Schritt sein, denn …
Hat FF in Version 69 einmal Zugriff auf das Profile gehabt, weigert sich die 68, das Profile anzufassen.
Im Image ist aber die 68. Eine Commandline-Switch für einen Silent Upgrade hat FF aber nicht, so dass
auch ein Logon-Script nichts bringt. Ich will nun aber nicht bei jedem FF-Upgrade das komplette Image neu erstellen und ausrollen.
Jetzt versuche ich, dass Opsi nach dem Aufspielen des Images den neuen FF nachinstalliert, bevor der User ans System kommt. Das Paket-erstellen ist für FF nicht das Problem, sondern das „Install on reboot“ klappt bei mir nicht …
VG
Wolfgang
Hallo Wolfgang,
Update von Firefox. Auf Windows hat FF einen Hintergrunddienst, der
irgendwann das Update einspielt. Den kann man angeblich abwürgen und das
wird wohl auch mein nächster Schritt sein, denn …
Hat FF in Version 69 einmal Zugriff auf das Profile gehabt, weigert sich
die 68, das Profile anzufassen.
… das sit ungewöhnlich und habe ich in x Jahren Firefox mit profil im
Home nicht gehabt: und ide Firefoxverionen der user sind immer immens
auseinander gelaufen, weil die unter Win und lin auf das selbe Profil im
Home zugegriffen habe und ich den FF in Windows vielelicht einmal im
Jahr und den unter ubuntu einmal im Monat upgedatet hatte …
Also: ich würde das erst mal noch beobachten, bevor du dir mit OPSI
durchs Knie schießt.
Weitere Möglichkeit: autoupdates in FF abschalten und nurnoch updaten,
wenn du ein neus Image hast: dann haben alle den gleichen FF überall.
LG
Holger
Hi,
ja, ich hatte bisher auch keine Probleme und unter Linux eh nicht.
Aber es ist reproduzierbar. Die Original-Profile hab ich von den alten
Linux-Installationen geholt, Zugriff von Windows FF ging problemlos, doch dann kam
das Update von der 68.0.2 auf die 69.0 bzw 69.0.1 und da ht es dann geknallt.
Sobald ich (z.B. als global admin) das update vom FF gemacht habe, können
danach angemeldete Benutzer wieder arbeiten.
Bei Opsi geht es mit im Script im Wesentlichen um die Zeilen der inbo_cmd:
# request opsikey
localmode || rsync "$serverip"::linbo/"$ip.opsikey" /tmp/opsikey
viele Zeilen
rm -f /tmp/opsikey
# request opsi host ini update
localmode || rsync "$serverip"::linbo/"$image.opsi" /cache &> /dev/null || true
Es scheint sich bei xxx.cloop.opsi um irgendeine Form einer ini-Datei zu handeln,
die wahrscheinlich auch den Opsykey enthalten dürfte, weil der ja vorher aus dem
/tmp gelöscht wird. Linbo erwartet also auch eine Datei der Form IPADRESSE.opsi
in der der Opsikey des Clients steht … das funktioniert, wenn ich sie per Hand anlege.
Etwas irritiert hat mich, dass der rsync diese Datei auf dem Server löscht, nachdem er
sie geholt hat … ist eine etwas gefährliche Einstellung.
Diese IPADRESSE.opsi wird allerdings NICHT automatisch erstellt, wenn man in der devices.csv
den pxe-boot auf 2 setzt. Allerdings wird eine opsiconfd.pem erstellt, die es vorher nicht gab
und der Opsikey des Clients steht danach in der „Sammeldatei“ opsikeys …
Alles nicht ganz so wahnsinnig schlüssig und da geht das auf git auch nicht weiter ein …
VG
Wolfgang
Hi,
blablablubb.opsi einfach mal mit 7zip entpacken:
blablablubb.opsi enthält
blablablubb.opsi\CLIENT_DATA.cpio.gz
blablablubb.opsi\OPSI.cpio.gz
einfach immer weiter entpacken:
für die „Clientfiles“ im Ordner CLIENT_DATA
blablablubb.opsi\CLIENT_DATA.cpio.gz\CLIENT_DATA.cpio\
für die „Serverfiles“ im Ordner OPSI
blablablubb.opsi\OPSI.cpio.gz\OPSI.cpio\
Skripte liegen immer im CLIENT_DATA
Hi,
ich weiß nicht, ob wir von der gleichen Datei sprechen. Einerseits gibt es im Repo auf dem Opsi-Server die Opsi-Pakete. Die meinst wohl du.
ICH spreche davon, dass Linbo_cmd eine Datei win10_standard.cloop.opsi per rsync in den Cache des Clients kopiert. Das kann wohl kein Installationspaket sein …
VG
Wolfgang