Hallo NG,
ich habe unter Lenny ein LTSP System aufgesetzt welches mit einem 192.168.1.0 Netz
(alle Rechner im gleichen Netz an einem Switch) einwandfrei funktioniert.
Dabei ist ein Rechner der "Chooser", soll heißen alle Terminals verbinden sich zuerst mit ihn, ziehen sich über PXE,
tftp und NFS die benötigten Daten und verbinden sich dann auf einen anderen LTSP-Server. Wie gesagt, der Testaufbau
funktioniert einwandfrei.
Das ganze soll aber produktiv in einem "richtigen" Netz stehen. Jede Arbeitsgruppe hat ein eigenes Sub-Net und die LTSP-Server
stehen in einem anderen Netz. Des Weiteren ist keiner der LTSP Server der DHCP Server! Und jetzt kommt das Problem:
Ich habe alles soweit für das neue Netz konfiguriert, die Clients laden sich über tftp den kernel und die initrd und führen sie
auch aus. Irgendwann ist dann ipconfig dran und startet eine DHCP Anfrage, die auch den DHCP Server erreicht, der auch darauf
antwortet. Diese Antwort befriedigt aber die LTSP-Clients in irgend einer Form nicht. Nach einem Timeout erfolgt folgende Meldung:
Can't open /tmp/net-eth0.conf.
Ich habe schon alle möglichen Parameter versucht:
ip=dhcp
pci=noacpi
<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>, nfsopts=tcp.
usw...
Gebe ich eine feste IP-Adresse mit -- was natürlich Schwachsinn ist -- ist alles gut.
Ich habe dann testweise einen Client in das gleiche Netz gehangen wie die LTSP-Server und auf diesem dhcp3-relay installiert.
Die Antwort, die vom relay kommt, wird von den Clients akzeptiert und alles läuft prima. Da aber später die Clients in anderen Netzen stehen werden und erst "am Router vorbei" müssen, ist dies keine Lösung. Auf der Suche nach dem Problem bin ich
auf ip-spoofing gestoßen. Dies ist aber auf den Cisco-Routern deaktiviert. Ich habe einen testing LTSP Client installiert, der ebenfalls ein Timeout bekommt. Des Weiteren hab ich noch einen karmic-LTSP-Client installiert und obwohl der nicht mit ipconfig arbeitet, funktioniert das
auch nicht.
Hat jemand eine Idee, wo das Problem liegen könnte? Benötigt ipconfig eine spezielle Informationen oder gibt der DHCP vielleicht
zu viele Informationen? Kann/muss man ein flag setzen? Bin langsam ratlos
LTSP + Cisco + ipconfig
- zielscheibe
- Beiträge: 4
- Registriert: 04.05.2010 09:31:25
LTSP + Cisco + ipconfig
---
Wenn Null besonders groß ist, ist es fast so viel, wie ein bisschen Eins
Wenn Null besonders groß ist, ist es fast so viel, wie ein bisschen Eins
- zielscheibe
- Beiträge: 4
- Registriert: 04.05.2010 09:31:25
Re: LTSP + Cisco + ipconfig
Habe nach diversen Versuchen nun endlich eine Lösung gefunden
Hier mal eine kurze, stichwortartige Zusammenfassung:
Als erstes die initrd entpacken
Das Paket "udhcpc" installieren und Dateien für die initrd kopieren.
Folgendes Skript (default.script) erstellen und nach etc/udhcpc/ kopieren. Der Code für dieses default.script stammt aus
der initrd der systemrescuecd-x86-1.0.4
In der script/functions ersetzen aller "ipconfig ${DEVICE}" durch "udhcpc -i ${DEVICE}"
und alle Zugriffe auf die Datei /tmp/net* auskommentieren
Danach die Initrd wieder "zusammenbauen" und die richtige Stelle kopieren
~
Hier mal eine kurze, stichwortartige Zusammenfassung:
Als erstes die initrd entpacken
Code: Alles auswählen
cat initrd.img | gzip -d | cpio -i
Code: Alles auswählen
cp /sbin/udhcpc bin/
Folgendes Skript (default.script) erstellen und nach etc/udhcpc/ kopieren. Der Code für dieses default.script stammt aus
der initrd der systemrescuecd-x86-1.0.4
Code: Alles auswählen
#!/bin/sh
case ${1} in
renew|bound)
[ -n "$broadcast" ] && BROADCAST="broadcast $broadcast"
[ -n "$subnet" ] && NETMASK="netmask $subnet"
[ -n "$rootpath" ] && echo "$rootpath" > /rootpath
[ -n "$siaddr" ] && echo "siaddr=$siaddr" > /etc/tftp-siaddr
busybox ifconfig $interface $ip $BROADCAST $NETMASK
# ---- handle the default route
if [ -n "$router" ]
then
if [ "$router" != "$(route -n | grep '^0.0.0.0' | grep $interface | awk '{ print $2 }')" ]
then
while route del default gw 0.0.0.0 dev $interface 2>&-
do
echo "removing old default route"
done
for i in $router
do
route add default gw $i dev $interface
echo "set new default route: $i"
done
fi
fi
# ---- handle the DNS
rm -f /etc/resolv.conf 2>/dev/null
[ -n "$domain" ] && echo domain $domain >> /etc/resolv.conf
for curdns in $dns
do
echo nameserver $curdns >> /etc/resolv.conf
done
;;
deconfig)
busybox ifconfig $interface 0.0.0.0
;;
esac
In der script/functions ersetzen aller "ipconfig ${DEVICE}" durch "udhcpc -i ${DEVICE}"
und alle Zugriffe auf die Datei /tmp/net* auskommentieren
Danach die Initrd wieder "zusammenbauen" und die richtige Stelle kopieren
Code: Alles auswählen
find . | cpio -o -H newc -O initrd.img
---
Wenn Null besonders groß ist, ist es fast so viel, wie ein bisschen Eins
Wenn Null besonders groß ist, ist es fast so viel, wie ein bisschen Eins
Re: LTSP + Cisco + ipconfig
Ah genau habe ich grad dieses problem auch. Danke für die Lösung und werden mal in den nächsten Tagen testen.
Hast du Ubuntu Client (Karmic) auch mal rebooten können? Es bleibt bei mir immer wegen NBD-Server hängen, da ja die Konnektion unterbrochen wurde, bevor der Rechner runterfährt.
Hast du Ubuntu Client (Karmic) auch mal rebooten können? Es bleibt bei mir immer wegen NBD-Server hängen, da ja die Konnektion unterbrochen wurde, bevor der Rechner runterfährt.
- zielscheibe
- Beiträge: 4
- Registriert: 04.05.2010 09:31:25
Re: LTSP + Cisco + ipconfig
Das ist das noch erleben darf! Ich dachte, ich wäre der einzige Mensch mit dem Problem
Ich muss an der Lösung aber noch etwas feilen. Im Moment funktioniert die Lösung nur, wenn sich der Client
und Server im gleichen Subnet befinden. Wenn aber der Client in einem anderen Subnet ist,
setzt udhcpc zwar die Route richtig, aber der Client bleibt hängen. Ich vermute mal,
dass der Client irgendwann im Bootprozess noch mal auf die /tmp/net-ethX zugreifen möchte
um sich weitere Daten zu erhalten...
Ich muss an der Lösung aber noch etwas feilen. Im Moment funktioniert die Lösung nur, wenn sich der Client
und Server im gleichen Subnet befinden. Wenn aber der Client in einem anderen Subnet ist,
setzt udhcpc zwar die Route richtig, aber der Client bleibt hängen. Ich vermute mal,
dass der Client irgendwann im Bootprozess noch mal auf die /tmp/net-ethX zugreifen möchte
um sich weitere Daten zu erhalten...
---
Wenn Null besonders groß ist, ist es fast so viel, wie ein bisschen Eins
Wenn Null besonders groß ist, ist es fast so viel, wie ein bisschen Eins