forum.opsi.org

Hallo,

Wir planen einen OPSI-Rollout an 4 Standorten, da sind zwei prinzipielle Fragen aufgetaucht:

Da wir an den Remote-Standorten keine Möglichkeit haben, Linux-Server einzusetzen aber jeweils zwei Windows-Server (ein DC und ein DFS-Server) war die Idee, das Depot-Share auf das DFS-Volume zu legen und die Clients holen sich die Installationspakete jeweils vom "lokalen" Share... Sollte prinzipiell möglich sein, oder?

Der zweite Punkt betrifft das Betriebssystem-Rollout, genauer gesagt den Punkt wo der Client das miniroot vom TFTP abholt.
Für uns wäre es perfekt, wenn die Clients zwar die pxelinux.0 und so weiter direkt vom OPSI-Server aus am zentralen Standort holen, aber das miniroot vom lokalen Standort-Server via HTTP, WebDAV oder CIFS nachgeladen wird.
Wurde so etwas schon einmal versucht? Habt ihr ideen wie man das realisieren könnte?

Danke & lg
Florian

Hi,

Da wir an den Remote-Standorten keine Möglichkeit haben, Linux-Server einzusetzen aber jeweils zwei Windows-Server (ein DC und ein DFS-Server) war die Idee, das Depot-Share auf das DFS-Volume zu legen und die Clients holen sich die Installationspakete jeweils vom "lokalen" Share... Sollte prinzipiell möglich sein, oder?

Ja - ist möglich aber gebastel Abseits des Standards. D.h. ich muss dem configserver im Backend depotserver Einträge erzeugen und binn für die synchronistation der Produkte auf die 'Depots' und die Information im Backend, dass die Pakete auf den Depots sind selbst verantwortlich.

Der zweite Punkt betrifft das Betriebssystem-Rollout, genauer gesagt den Punkt wo der Client das miniroot vom TFTP abholt.
Für uns wäre es perfekt, wenn die Clients zwar die pxelinux.0 und so weiter direkt vom OPSI-Server aus am zentralen Standort holen, aber das miniroot vom lokalen Standort-Server via HTTP, WebDAV oder CIFS nachgeladen wird.

Haben wir noch nicht. Ich weiss aber von Kunden die derzeit mit opsi und ipxe experimentieren oder arbeiten. Damit könnte das möglich sein.

Wenn beides umgesetzt werden soll, würde ich das nicht ohne Supportvertrag tun.

gruss
d.oertel

d.oertel hat geschrieben: Ja - ist möglich aber gebastel Abseits des Standards. D.h. ich muss dem configserver im Backend depotserver Einträge erzeugen und binn für die synchronistation der Produkte auf die 'Depots' und die Information im Backend, dass die Pakete auf den Depots sind selbst verantwortlich.

D.h. ich hätte dann aber im Backend am Configserver nur ein einziges Depot eingetragen, weil der Client anhand der Zuordnung zur Active Directory Site sowieso bei Zugriff auf z.B. \\contoso.local\dfsroot\opsidepot auf den Site-lokalen DFS-Server zugreift oder habe ich da irgendwo einen Denkfehler?
Dass sich ein DFS-Replikationsissue auf OPSI negativ auswirken wird ist uns bewusst, aber wir haben schon jetzt massiv Daten am DFS liegen und monitoren daher die DFS-Replikation sowieso schon im Detail.
Wir würden uns so einiges an Wartungsaufwand ersparen und die OPSI-Struktur wäre überschaubarer...

d.oertel hat geschrieben:Haben wir noch nicht. Ich weiss aber von Kunden die derzeit mit opsi und ipxe experimentieren oder arbeiten. Damit könnte das möglich sein.

Danke für den Tipp, iPXE sieht vielversprechend aus, zumindest sollte es damit möglich sein, die initrd via http nachzuladen.
Wenn das menufile für iPXE (wie hier: http://boot.ipxe.org/demo/boot.php) sogar ein PHP-Script sein darf dann schwebt mir schon eine coole Lösung vor, die ich aber noch testen muss...

d.oertel hat geschrieben:Wenn beides umgesetzt werden soll, würde ich das nicht ohne Supportvertrag tun.

Logisch

Danke für die schnelle und hilfreiche Antwort

Für alle die das nachbauen wollen ein wichtiger Hinweis, der mir viel Zeit erspart hätte:

* Der DFS-Namespace darf nur ein Stand-alone Namespace sein, da mount.cifs unter linux nicht richtig mit Domain-based namespaces umgehen kann!

Die dezentrale Boot-Lösung mit iPXE funktioniert in den ersten Tests wirklich gut.
Für das Hosting der Boot-Images verwende ich derzeit nginx unter Windows Server 2008R2 weil mir IIS dafür zu ressourcenlastig ist.

Sobald ich die ersten VM-Testclients am Remotestandort installiert habe werde ich mich ans dokumentieren machen und ein kleines HOWTO basteln

seteqsystems hat geschrieben:Für alle die das nachbauen wollen ein wichtiger Hinweis, der mir viel Zeit erspart hätte:

* Der DFS-Namespace darf nur ein Stand-alone Namespace sein, da mount.cifs unter linux nicht richtig mit Domain-based namespaces umgehen kann!

Die dezentrale Boot-Lösung mit iPXE funktioniert in den ersten Tests wirklich gut.
Für das Hosting der Boot-Images verwende ich derzeit nginx unter Windows Server 2008R2 weil mir IIS dafür zu ressourcenlastig ist.

Sobald ich die ersten VM-Testclients am Remotestandort installiert habe werde ich mich ans dokumentieren machen und ein kleines HOWTO basteln

klingt vielversprechend!
Nicht ganz verstanden habe ich, was Sie mit einem "Stand alone Namespace" meinen? Einen DFS Root außerhalb der Domäne?

Zur Klärung der Verwirrung:

Ein Domain-based Namespace wird in der Form \\domain.tld\dfsfoldername angelegt.
Da hat der CIFS-Client unter Linux genau dann Probleme, wenn nicht jeder Domaincontroller gleichzeitig DFS-Server ist, was bei größeren Umgebungen eher der Fall sein wird.

Daher habe ich einen Stand-alone-Namespace angelegt, der dann in der Form \\servername\dfsfoldername auf einem Domain-Memberserver gehostet wird.
Das Redirect auf den Site-lokalen DFS-Server beherrscht der CIFS-Client dann problemlos

EDIT: Die Art von Namespace kann man nur beim erstmaligen Anlegen des Namespaces unter Windows Server 2008R2 wählen...

Das Projekt liegt die kommenden zwei Wochen etwas auf Eis, da ich gestern Nachwuchs bekommen habe

seteqsystems hat geschrieben: Das Projekt liegt die kommenden zwei Wochen etwas auf Eis, da ich gestern Nachwuchs bekommen habe

Meinen herzlichen Glückwunsch! Und immer daran denken:

• Man bekommt alles durch ein Lächeln zurück!
• Schlafen kann man noch, wenn man tot ist.
• Sei stets freundlich zu Deinen Kids, denn sie suchen Dein Altersheim aus!