forum.opsi.org

Hallo alle Opsi-Fanatiker,

bei der Installation und anschließenden Nutzung des Opsi 4 sind mir ein paar Dinge aufgefallen, die so hier scheinbar noch nicht dokumentiert/berichtet wurden und bei denen ich gern wüsste, ob ich dabei ein Einzelfall bin, oder ob noch jemand die Erfahrung machen konnte.

Zuerst zum Opsi-Server: Der Server ist ein Debian Lenny System, das von einer Netinstall-CD (frisch bei Debian heruntergeladen) aus in einer VirtualBox VM installiert wurde. Bei der Installation wurde nur das Grundsystem und Gnome als Oberfläche ausgewählt. Nach Vergabe des Rechnernamens, apt-get update, Einrichten des UBI Repos und Durchführen der restlichen Schritte gem. Handbuch sah erst einaml alles gut aus. Das Backend lies sich normal starten, ich konnte Clients erstellen und im tftpboot-Verzeichnis wurden auch die Boot-Config des Client erstellt. Da fiel mir das erste mal auf, dass opsi-setup --set-rights <Pfad> jedes Mal die "Other" jeglicher Rechte beraubt.

-rw-rw---- 1 opsiconfd pcpatch 15710 8. Sep 12:58 pxelinux.0
drwxrws--- 2 opsiconfd pcpatch 4096 20. Sep 10:04 pxelinux.cfg

Entsprechend fand der Client (ebenfalls eine VirtualBox VM) keinerlei Bootdateien und stellte seine Arbeit ein. Nachdem die Rechte händisch mit chmod berichtigt wurden lief alles problemlos. Das Verhalten mit dem --set-rights lässt sich reproduzieren und tritt auch innerhalb des Windows7 (winpe) Verzeichnisses auf.

Das viel schlimmere Problem trat bisher bei der Integration einer bereits existierenden Windows XP Maschine auf. Ich versuchte die im Handbuch beschriebene Variante: mit Opsi-Netzlaufwerk verbinden und im Verzeichnis opsi_client_agent die service_setup.cmd starten. Nach der Authentifizierung am Opsi schlug die Installation jedes Mal fehl, weil "<Rechnername. >" kein gültiger FQDN ist. Die Windows-Kiste ist nur Mitglied in einer Arbeitsgruppe (also kein Domänenmitglied) und hat daher natürlich kein FQDN. Also kurzerhand in Systemeigenschaften->Computername->Ändern->weitere->primäres DNS-Suffix eingetragen und erneut getestet. Leider verlief die Installation mit dem selben Fehler. Das Leerzeichen hinter dem Rechnernamen brachte mich dann auf die Spur: in der Datei opsi-client-agent/files/opsi/setup.ins in Zeile 448 wird mittels if($INST_DnsDomainName$ = "") geprüft, ob der Client einen DNS-Namen liefert und wenn nicht, der Domainname des Opsi gesetzt. Mein Client liefert leider kein "", sondern ein " " zurück (statt eines leerens Strings gibt der Client ein Leerzeichen zurück). Mit geändertem if-Statement läuft die service_setup.cmd problemlos.

Nun steht der erste Rollout eines Windows 7 Client an. Ich bin gespannt...

Viel Grüße

Daniel

binom hat geschrieben: Da fiel mir das erste mal auf, dass opsi-setup --set-rights <Pfad> jedes Mal die "Other" jeglicher Rechte beraubt.

-rw-rw---- 1 opsiconfd pcpatch 15710 8. Sep 12:58 pxelinux.0
drwxrws--- 2 opsiconfd pcpatch 4096 20. Sep 10:04 pxelinux.cfg

Das kann ich leider nicht reproduzieren: Sind die aktuellsten Pakete installiert?

binom hat geschrieben: ... und tritt auch innerhalb des Windows7 (winpe) Verzeichnisses auf.

Das wiederum ist gewollt.

binom hat geschrieben: Das viel schlimmere Problem trat bisher bei der Integration einer bereits existierenden Windows XP Maschine auf. Ich versuchte die im Handbuch beschriebene Variante: mit Opsi-Netzlaufwerk verbinden und im Verzeichnis opsi_client_agent die service_setup.cmd starten. Nach der Authentifizierung am Opsi schlug die Installation jedes Mal fehl, weil "<Rechnername. >" kein gültiger FQDN ist. Die Windows-Kiste ist nur Mitglied in einer Arbeitsgruppe (also kein Domänenmitglied) und hat daher natürlich kein FQDN. Also kurzerhand in Systemeigenschaften->Computername->Ändern->weitere->primäres DNS-Suffix eingetragen und erneut getestet. Leider verlief die Installation mit dem selben Fehler. Das Leerzeichen hinter dem Rechnernamen brachte mich dann auf die Spur: in der Datei opsi-client-agent/files/opsi/setup.ins in Zeile 448 wird mittels if($INST_DnsDomainName$ = "") geprüft, ob der Client einen DNS-Namen liefert und wenn nicht, der Domainname des Opsi gesetzt. Mein Client liefert leider kein "", sondern ein " " zurück (statt eines leerens Strings gibt der Client ein Leerzeichen zurück). Mit geändertem if-Statement läuft die service_setup.cmd problemlos.

Ein FQDN hat nichts mit einer Windows-Domäne zu tun.
Ein FQDN ist vielmehr der volle DNS!-Hostname, wie z.B. http://www.uib.de (uib.de ist hierbei auch keine Windows-Domäne).
Wird ein DHCP-Server verwendet?
Ein Linux- oder ein Windows-DHCP-Server?
woher kommt die DNS-Domain " "?

Gruß,
Jan Schneider

Hallo Herr Schneider,

vielen Dank für den Hinweis mit dem apt-get dist-upgrade. Das scheint das Problem mit dem opsi-setup --set-rights erfolgreich behoben zu haben. Ich werde es weiter beobachten.

Der Windows-Client ist eine VirtualBox VM Windows XP Professional mit SP3 und den aktuellsten Updates von Microsoft. Dieser Rechner ist Mitglied in einer Arbeitsgruppe "Workgroup". In dem Netzsegment gibt es momentan nur den Opsi-Server, ein paar Test-Clients und diesen Windows Rechner (kein DNS-Server vorhanden). Der Opsi ist auch gleichzeitig der DHCP-Server für dieses Netzsegment und hat in der dhcpd.conf die option domain mit dem Wert "install.net" (der Opsi ist opsi-server.install.net) aktiviert (wobei ich es auch ohne die option domain versuchte; ohne Erfolg). Besagter Windows-Client bekommt vom Opsi seine IP zugewiesen. Wenn es nun darum geht dem Client seinen eigenen FQDN ohne Einsatz eines DNS-Servers mitzuteilen, kommen lokal ja nur die Konfigurationsmöglichkeiten:
- primäres DNS-Suffix im Bereich Computername->ändern->weitere
- DNS-Suffixe anhängen im Bereich Erweiterte TCP-IP-Einstellungen->DNS
- oder die windows\system32\drivers\ets\hosts in Frage.

Egal, welche Konfigurationsmöglichkeit ich am Client teste, meldet die service_setup.conf immer, dass der FQDN nicht passt (mit dem unerklärlichen Leerzeichen als Domänenname). Wobei ein ping vom Client auf seine, vom DHCP-Server bezogene IP immer den vollen DNS-Hostnamen (FQDN) auflöst (ich bin mir sehr wohl der Unterschiede Netbios, Windows-Domäne und DNS bewusst).

Wo nimmt denn das Installationsscript die Information über den DNSDomainNamen her? Wird die Variable $INST_DnsDomainName$ durch auslesen der WMI gefüllt?

Fragen über Fragen...

Ciao Daniel

Hi,

bei der Installation des opsi-servers wird man nach dem DNS-Domain Namen gefragt (VM) bzw. ist im Handbuch beschrieben was die Namensauflösungstechnischen Voraussetzungen sind. Ohne das der opsi-server sich korrekt vorwärts wie rückwärts auflösen kann keine funktionierende opsi Installation.

Der DNS-Namen landet dann auch (!) in der
/opt/pcbin/install/opsi-client-agent/files/opsi/cfg/config.ini

Aber nochmal - wenn die Namensauflösung für den FQDN des Servers bei beginn der Installation nicht in Ordnung war, fängt man besser wieder von vorne an.

gruss
d.oertel

Hallo noch mal zu meinem leidigen Thema.

Die Namensauflösung des Opsi funktioniert tadellos. Der Server ist aus seinem Subnetz problemlos erreichbar. Auch in der /opt/pcbin/install/opsi-client-agent/files/opsi/cfg/config.ini steht "dnsdomain = install.net" (ohne Anführungszeichen). Wie gesagt, es funktioniert alles, mit Ausnahme dieses einen Clients. Das Problem lässt sich auch auf den Client eingrenzen. Ich vermute den Fehler in diesem Fall in der /opt/pcbin/install/opsi-client-agent/files/opsi/setup.ins in dem Bereich Zeile 446 und 447:

Set $INST_ResultList$ = getOutStreamFromSection("DosInAnIcon_getDnsByWmic")
Set $INST_DnsDomainName$ = TakeString(1,splitString(TakeString(0,$INST_ResultList$),"="))

Hier scheint ein Leerzeichen zurück geliefert zu werden. Kann man das DosInAnIcon_getDnsByWmic auch manuell in der Eingabeaufforderung ausführen?
Am Ende reicht es ja (und so funktioniert es bisher zumindest bei allen nicht Domänenmitgliedern), das if-Statement:

if ($INST_DnsDomainName$ = " ")

mit Leerzeichen zu lassen oder halt durch if ($INST_DnsDomainName$ = " " or $INST_DnsDomainName$ = "") zu ersetzen.
Mir geht es primär darum zu erfahren, ob ich der Einzige mit diesem Problem bin.

Schönen Abend noch

Daniel