OpsiConfD Variablen

[Us3r]

Hallo zusammen,

wir versuchen gerade OPSI für unsere Firmeninterne Struktur zu evaluieren.
Aufgefallen ist uns die Struktur direkt im Rootverzeichnis.

drv, tmp, opsi.org, sowohl im Root als auch im %ProgramFiles (x86)%

Eines der Sorgendkinder ist C:\opsi.org

Der Dienst opsiclientd.exe will einfach die Variablen state_file und timeline_db nicht auslesen. Stattdessen wird immer in C:\opsi.org geschrieben.
Sind die Pfade hardcoded?

Gibt es Sources von opsiclientd.exe?

LG

[d.oertel]

Hi,

ja die Pfade sind hardcoded und wir sind hier bewusst vom Windows Style Guide abgewichen.
Da unter NT5 (unter NT6 ist es besser) die Pfade zu 'All users\Application data' je nach OS und Lokalisierung völlig unterschiedlich sind,
ist die für einen entsprechenden Support die Hölle.

Da es sich aber bei c:\opsi.org um variable Daten handelt, haben diese unter 'program files' nichts zu suchen.
D.h. c:\opsi.org wird nicht nur vom opsiclientd verwendet sondern auch von anderen Komponenten.

c:\drv kann man löschen wenn es einem stört, hier liegen nur die während der Installation verwendeten Treiber rum.
c:\tmp ist historisch und wandert im luafe der Zeit nach c:\opsi.org\tmp

Was ist denn das Problem das Ihr lösen wollt ?

gruss
d.oertel

[Us3r]

Hi und merci für den Post.

ja die Pfade sind hardcoded und wir sind hier bewusst vom Windows Style Guide abgewichen.

Ist ja auch völlig legitim. Allerdings würden wir die .opsi Packages per OS gestalten. %APPDATA% ist ja auch nicht in Augenreichweite der User.
unter %ProgramFiles (x86)%\opsi.org\opsi-client-agent\opsiclientd wäre ja auch der Rest der Applikation zu finden. Nur die timeline_db und state_file wären übrig, sonst schreiben bei uns keine utils in diesen Verzeichnissen. Für den OPSIclientD habe ich die Sources gefunden, scheitere aber bei ImportError: No module named opsiclientd (Jap, bei Python bin ich noch unerfahren)

Angenommen wir geben einem Hypochonder access zur Medizinischen Datenbank - Was bei sowas passiert kann man sich ausmalen.

Windows 7 C:\ (gewünscht):
- Benutzer
- Programme
- Programme (x86)
- Windows

Jeder zusätzliche Ordner und die Verwirrung und Ticketaufkommen steigt. Zudem wie im Post davor erwähnt es 2 Opsi Ordner gibt.

Wenn also die Variablen state_file und timeline_db existieren, diese laut log auch ausgelesen werden, warum jene dann nicht nutzen?
Warum C:\tmp nicht nach %TEMP% schreiben lassen?

Das Problem fing an mit ntfs_image_write und *_restore.
ntfs_image_write wurde modifiziert und schreibt zusätzlich noch eine .ini file. Hier ein Beispiel (wenns ein bisschen offtopic sein darf)

Code: Alles auswählen

[T530]
[1]
fs=ntfs
cylSize=19
number=1
secStart=2048
secSize=290816
device=/dev/sda1
size=156280320
cylStart=0
end=156280320
secEnd=292863
boot=True
start=0
cylEnd=18
type=7
[2]
fs=ntfs
cylSize=31113
number=2
secStart=292864
secSize=499824640
device=/dev/sda2
size=255913136640
cylStart=18
end=256061191680
secEnd=500117503
boot=False
start=148055040
cylEnd=31130
type=7

Mit keinen der Daten liess sich ein System wiederherstellen. Weder die Berechnung (etwas verwirrend, wie im Script vorhanden) mit 1000 oder (eher logisch) mit 1024 funktionierte nicht.
Nachwievor müssen wir dann aber auf den Systemen den opsi-client-agent installieren. Und dann haben wir wieder das gleiche Problem wie oben.

Für unsere Firma planen wir an 7 Standorten OPSI zu verwenden. Depotauswahl und Lizenzmanagement benötigen wir dann ebenfalls.

Kurz: Es sind einige Fragen bezüglich OPSI vorhanden und müssen unsererseits noch konsolidiert werden.

[ueluekmen]

Hi,

Kurz: Es sind einige Fragen bezüglich OPSI vorhanden und müssen unsererseits noch konsolidiert werden.

wir unterstützen gerne beim konsolidieren. Manchmal ist es hilfreich wenn man sich einfach etwas Consulting einkäuft. Kommt meistens billiger, als wenn man versucht alle Informationen selber zusammen zu tragen.

Warum C:\tmp nicht nach %TEMP% schreiben lassen?

Weil diese Ordner für jeden lesend und schreibend geöffnet sind. Das ist der hintergdanke bei gemeinsamen temporären Verzeichnissen, dass ist aber genau das, was opsi-User nicht haben wollen, da auch sensilble Daten unter anderem Passwörter (bei sehr hohen logleveln) mit reingeschrieben werden. Das Verzeichnis C:\opsi.org ist nur für Administratoren einsehbar.

soviel zu:

Angenommen wir geben einem Hypochonder access zur Medizinischen Datenbank

%ProgramFiles (x86)%\opsi.org\opsi-client-agent\opsiclientd

und C:\opsi.org haben einen weiteren unterschied, C:\opsi.org ist entbehrlich, wenn es nicht existiert, wird es neu angelegt, das programm-Verzeichnis logischerweise nicht.

Für unsere Firma planen wir an 7 Standorten OPSI zu verwenden

Auch hier unterstützen wir Sie gerne bei der Planung.

[Us3r]

Danke für die Antwort.

Das Verzeichnis C:\opsi.org ist nur für Administratoren einsehbar.

Womit wir schon bei unserem Problem wären.
Jeder User kriegt bei uns lokale Adminrechte. Wer sein System schrottet, kriegt ein Neues aufgesetzt. Insofern wäre das Logging hoch zu setzen passend mit "fatal" zu beschreiben.

Irgendwie eine Schleife, da Opsi die lokalen Adminrechte ablösen soll
Wenn C:\opsi.org immer neu erstellt wird, die Sec-Descriptors für Admins angepasst werden, was spricht dagegen den im %TEMP%\opsi.org zu erstellen mit den gleichen Security Einstellungen...

[d.oertel]

Hi,

wie schon erwähnt:

es gibt unterschiedliche Komponenten die nach c:\opsi.org schreiben:

• opsi-winst
• diverse opsi-Produkt-Pakete
• unterschiedliche Teile des opsiclientd

D.h. die Entscheidung opsi.org einzuführen war eine langfristig strategische.
Natürlich ist es theoretisch möglich dieses zentrale Verzeichnis zu verlegen.
Das ist aber viel Aufwand, den jemand bezahlen müsste.
Wobei ich das sowieso nur befürworten würde wenn man dabei NT5 auslässt.

gruss
d.oertel