/etc/services bringt dir da garnichts...da stehen nur drin welche Ports für welche Dienste verwendet werden sollten. Portscanner wie etwa nmap verwenden das um dir zum Port auch noch ne Anwendung anzeigen zu können.
Damit inetd den Kram startet muss es in /etc/inetd.conf stehen!Danach könnte dir die Prozesstabelle bzw ein Portscan Aufschluss geben ob der tftpd läuft...
lg Sebastian Andreas Tille wrote:
Hallo nochmal,
ich wärme den alten Thread noch mal auf. Nachdem es sehr viele Tipps gab, die
weit weg vom eigentlichen Thema führen, noch einmal die aktuelle Situation: Die
RealTec-Karte wurde gegen eine funktionierende Karte (VIA) ersetzt und der
Tjener zeigt keine merkwürdigkeiten hinsichtlich der Verwendung der Karten mehr.
Allerdings denkt mein Laptop als "Test-Client" nicht im geringsten daran, per
PXE zu booten. Er sucht immer vergeblich nach einem DHCP-Server. Ich habe
nun auch mal nachträglich einen bootp installiert, der ja zumindest
laut Beschreibung
DHCP und TFPT können sollte und ich habe vor x Jahren auch schon mal einen
Rechner mit Hilfe von bootp hochgezogen. Merkwürdig ist, daß in keinem Logfile
irgendwas zu finden ist. Sowohl tftp als auch bootp sollten per inetd gestartet
werden (sind in /etc/services eingetragen).
Muß man noch irgendwas beachten. Wie kann man debuggen, warum die
Anfrage meines Laptops nicht koorekt beantwortet wird?
Viele Grüße
Andreas.
---------- Weitergeleitete Nachricht ----------
Von: Andreas Tille<tillea@gmail.com>
Datum: 26. Mai 2008 21:08
Betreff: tftp läuft nicht
An: user@skolelinux.de
Cc: "J. kuna"<JKuna@gerhart-hauptmann-gymnasium.de>
Hi,
Kurzvorstellung: Ich bin seit 10 Jahren Debian-Entwickler, habe aber
noch nie was in Schulen gemacht. Jetzt habe ich Hilfe bei der
Installation von SkoleLinux in einer Schule angeboten, kenne mich
aber eigentlich gar nicht damit aus, was in der Schule gebraucht wird
und welche Aufgaben mit SkoleLinux tatsächlich abgedeckt werden
können. Ich bin sowohl auf "strategische" als auch technische
Probleme gestoßen.
Strategisch heißt: In der Schule existiert ein Arktur-Server, der durch
den Lehrer, mit dem ich Zusammenarbeite auch nicht angetastet
werden darf / kann / soll. Damit soll der SkoleLinux also nur einen
Teil seiner "Fähigkeiten" ausspielen. Ist der Tjener für eine Zusammenarbeit
mit dem Arktur ausgelegt und wenn ja, was muß man beachten?
Die Clients sollen
- per NetBoot starten (die Netzkarten sind erstmal nicht netboot-fähig, aber
ich denke mal, daß man das mit
http://home.arcor.de/mschierlm/bootdisk/
umgehen kann, richtig / alternativ?)
- Nutzerverwaltung von Arktur holen
- Fileserver von Arktur
- Internet (Arktur hat Proxy Server)
Ist das ein vernünftiger Ansatz, um einer Reihe älterer PCs Leben
einzuhauchen?
Technisch hatte ich wiederum folgendes Problem. Der Tjenner wurde
mit 3.0r1 aufgesetzt (erstmal ohne Netzwerkverbindung - was eine
schlechte Idee ist, aber es bestanden Bedenken, daß es irgendwelche
Konflikte mit dem Arktur geben könnte.
Anschließend habe ich festgestellt, daß gar kein tftp Server läuft.
Keine Ahnung, ob der über inetd gestartet wird. Wenn das der Fall ist,
dann liegt's wohl an einem anderen ausgesprochen merkwürdigen
Problem, daß wir die Kiste nicht zu was vernünftigem bewegen konnten:
Der Server enthält zwei Netzkarten (die interne meldet sich bei
lspci nur mit Ethernet controller: Unknown device 1969:2048 (rev a0);
Subsystem: ASUSTeK Computer Inc. Unknown device 8233): Eine Realtek,
die sauber funktioniert und eine Intel Karte, die ich per manuellem
"modprobe e1000" auch zur Zusammenarbeit bewegen kann. Das
erstaunliche: Sobald die RealTek-Karte (die offensichtlich über
das Modul 8139too angesprochen wird) initialisiert ist, laufen über
diese Karte beide Devices (eth0 und eth1) unter unterschiedlichen IP
Adressen, sprich, wenn ich nur ein Kabel in die Realtek Karte stecke
(und die Intel-Karte nicht eingestöpselt ist) erreiche ich mit einem
ping beide IP-Adressen, steckt man das Kabel in die Intel-Karte und
läßt die Buchse der Realtec leer, erreicht man mit einem ping keine
der IP-Adressen. Wird das 8139too explizit entladen ist die Intel-Karte
über eine IP erreichbar, lädt man 8139too neu und restartet den
Netzwerkdienst, sind wieder beide IP-Adressen bei der Realtec, die
sich wieder eth0 und eth1 krallt. Ich habe nicht die geringste Erklärung
für diesen Zustand und denke, daß wir bevor das geklärt ist gar nicht
weiter debuggen müssen.
Hat jemand Ideen zu den verschiedenen Problemfeldern?
Viele Grüße
Andreas.
--
http://fam-tille.de
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature