Keine Antwort vom Opsi Server

[Hallo_ihr_da]

Also USE_INETD ist auf True und unter Inet steht :

root 2809 1 0 Oct09 ? 00:00:00 /usr/sbin/inetd
root 11219 10857 0 11:47 pts/2 00:00:00 grep inet

[ueluekmen]

ok, gibt es einen tftp eintrag in der Datei:

/etc/inetd.conf

???

Wenn ja, wie sieht er aus? Vielleicht ist auch interessant, was der Client so ausgibt? Bekommt er den TFTP-Server mitgeteilt, versucht er zu connecten? Was steht in der /var/log/syslog? Werden tftp Einträge geloggt? Wird immer mit dem selben Modell getestet oder wurden auch mal verschiedene Clients probiert?

EDIT: Testen kann man einen TFTP übrigends ganz gut von einem Windows XP Rechner, in der cmd einfach mal folgendes ausführen:

Code: Alles auswählen

tftp 10.10.10.10 GET linux/pxelinux.0

Als Ergebnis sollte so etwas erscheinen:

Code: Alles auswählen

Übertragung erfolgreich: 15872 Bytes in 1 Sekunden, 15872 Bytes/s

Wenn das so ist, ist mit tftp auf opsi-Seite alles ok

[Hallo_ihr_da]

das steht drin:

# /etc/inetd.conf: see inetd(8) for further informations.
#
# Internet superserver configuration database
#
#
# Lines starting with "#:LABEL:" or "#<off>#" should not
# be changed unless you know what you are doing!
#
# If you want to disable an entry so it isn't touched during
# package updates just comment it out with a single '#' character.
#
# Packages should modify this file by using update-inetd(8)
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
#:INTERNAL: Internal services
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#time stream tcp nowait root internal

#:STANDARD: These are standard services.

#:BSD: Shell, login, exec and talk are BSD protocols.

#:MAIL: Mail, news and uucp services.

#:INFO: Info services

#:BOOT: TFTP service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /srv/tftp

#:RPC: RPC based services

#:HAM-RADIO: amateur-radio services

#:OTHER: Other services



und er versucht beim starten verbindung herzustellen lädt auch spuckt dann aber PXE time out aus!

[ueluekmen]

Ok, das sieht doch schon nach der richtigen Stelle aus, der Eintrag in der /etc/inetd.conf sollte so aussehen:

Code: Alles auswählen

tftp            dgram   udp     wait    nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5     --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=7  /tftpboot

Es sei denn du hast das Paket opsi-atftpd nicht installiert oder es ist bei der Installation etwas schief gegangen.

Wenn das Paket drauf ist, mach mal den Eintrag wie oben und schick dem inetd ein kill -HUP

[Hallo_ihr_da]

So ist kopier und gekillt

[Hallo_ihr_da]

Und tada es funkzt nicht!

[ueluekmen]

Ok,

ich glaube so kommen wir hier nicht weiter. Wenn opsi eingeführt werden soll, empfiehlt sich ein Einführungssupport oder Inhouse-Workshop.

Wenn opsi evaluiert werden soll, dann am besten einfach mal die vorkonfigurierte VM nehmen, am besten diese hier:

Code: Alles auswählen

https://download.uib.de/opsi4.0/testing/opsi402-2/opsi4.0.2-servervm.zip

Alles weitere geht von unserer Seite über den freien Support hinaus.

[thomas.besser]

Hallo,

Ja man kann ihn an pingen!

Noch ein Versuch von meiner Seite, da ich mal ein ähnliches Problem hatte. Ist der Rechner, bei dem TFTP ein Timeout bekommt, im selben Subnetz wie der OPSI-Server?

Gruß
Thomas

[Hallo_ihr_da]

Ja sind sie!

[thomas.besser]

Ok, tut mir leid, dann hast du ein anderes Problem.

Bei uns trat das auf, wenn der Rechner und der Server in unterschiedlichen Subnetzen liegt und mittels eines dhcp-relay die IP-Adressen verteilt. Dann schlägt teilweise ein Bug der PXE-Implementierung zu, der die IP des Relays als die des Gateways annimmt und nie zum TFTP-Server findet.

Gruß
Thomas