forum.opsi.org

Hallo allerseits,

folgendes Problem:
Der Client läuft beim Boot in einen Timeout. Ich habe mittlerweile 10000 Seiten durchforstet bisher ohne Erfolg.
http://www.bootix.com/support/problems_ ... meout.html
Diese Seite beschreibt das Problem am besten.
Der OPSI Server ist auf einer VM installiert und pingbar. TFTP ist hier installiert.
Es gibt keine DHCP Installation innerhalb des OPSI-Servers.
Der DHCP Dienst ist auf einer anderen Maschine installiert, deswegen habe ich diesen Parameter in der dhcpd.conf hinzugefügt:

next-server IP-adresse-opsi-server;
filename "/tftpboot/linux/pxelinux.0";

Dieser Eintrag verweisst ja auf den OPSI-Server.

viewtopic.php?f=7&t=4714
das meiste aus diesem Thread habe ich auch schon versucht. Das einzige was nicht funktioniert hat, war die tcpdump Geschichte, welche "nichts auswirft"

tcpdump port tftp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

Gibt es einen TFTP Dienst den man starten muss?

VG
ein verzweifelter Admin

der TFTP server von OPSI sollte automatisch laufen.
Befinden sich OPSI Server und Client im selben Netz?
Ich habe schon erlebt das bei vLAN Nutzung eventuell ACLs auf den switchen bestimmte Ports (unter anderem TFTP) blockiert haben.

Du könntest also mal auf einem Client mit einem TFTP-Client Programm versuchen auf den TFTP server zuzugreifen.

Also wir haben jetzt nen workaround gebastelt. Der OPSI Server ist in einem privaten netz. Der PXE Boot funktioniert Jetzt soweit, das er das Bootimage lädt. Jetzt zeigt der Client mir in einer blauen Maske eine "unvollständige Konfiguration" an...Das einzige Feld was noch fehlt ist "Hostname". Dabei ist unser Nameserver in der DHCP Config eingetragen. Das "Holen" des Hostnames sollte kein Problem darstellen.

das ist bei uns auch so - bin mir nicht sicher ob das nicht byDesign so ist.
Müsste UIB mehr zu sagen können

Hallo,

im Bootimage-Log des Clients sollte zu sehen sein, welche Informationen er übermittelt bekommt - Stichwort cmdline.
Ist dort der Hostname des Clients zu finden?


Gruß

Niko

Hallo nochmal,

hat alles tadellos funktioniert mit dem privaten Netz. PXE Boot funktioniert jetzt auch.Allerdings alles im privaten Netz... Im Arbeitsplatznetz stellt das Problem aber die Firewall dar. Port 69 UDP ist freigegeben. Das ist laut google.de der TFTP Port.
Da steht aber auch das der restliche Verkehr über einen Random port <1023 geregelt wird. Ich kann ja nun schlecht 60000 Ports in der Firewall öffnen...
Gibt es eine Möglichkeit einen Port "fest" festzulegen?

Hi,

das hat zwar jetzt nichts mit opsi zu tun, aber Firewalls arbeiten anders als du jetzt vielleicht vermutest. Normalerweise ist das so, dass du in die Richtung, in die normalerweise geblockt wird nur den Source-Port angibst. Dann wird einfach ausgedrückt ein Port aus dem High-Range-Bereich für die weitere Kommunikation reserviert und genutzt. Davon bekommst du im Regelfall aber nur was mit, wenn du deine Logs checkst. Die Frage ist hier, in welche Richtung blockt eure Firewall? Es gibt auch configs die in beide Richtungen blocken, dass ist ein bisschen schwieriger zu konfigurieren. Aber du wirst wahrscheinlich nicht drumherum kommen, mal einen tcpdump oder wireshark laufen zu lassen und das Problem näher zu analysieren. Den Loglevel von allen beteiligten hoch zu setzen, wäre an der Stelle auch nicht schlecht.

Port ist in beide Richtungen geöffnet. In den Log Files steht ACCEPT Rule X Client -> Server. Kein Reject oder Deny seitens Server IP oder Client IP.
Was ich wohl noch gefunden habe sind die Befehle "ip_conntrack_tftp" und "ip_nat_tftp" Was diese so genau machen weiss ich noch nicht...

Also die beiden Befehle haben das Problem anscheinend gelöst (wie? keine Ahnung)
kann aufjedenfall /closed