Re: dhcpd.conf
Am Samstag, den 10. Juli hub Hans-Dietrich Kirmse folgendes in die Tasten:
Ich kommentiere mal ein wenig :-)
> option domain-name "rs-schesslitz.de";
Der DNS-Domaenenname, der den anfragen Clients mit auf den Weg gegeben
werden soll.
Der Rechner "denkt" nun er sei <Rechnername>.rs-schesslitz.de"
> option domain-name-servers 192.168.0.1;
Wen muss ich fragen, wenn ich einen DNS-Namen "www.google.de"
in eine IP aufloesen will?
> option netbios-name-servers 192.168.0.1;
Wer ist fuer die Windows Namenaufloesung (WINS) zustaendig?
(Dinge wie: Wer ist Domaenenserver, welche IP hat X usw)
> option subnet-mask 255.255.255.0;
Subnetzmaske fuer das IP-Netz (-> CIDR)
> # 14 Tage Zuteilungsdauer fuer eine IP-Nummer
> default-lease-time 1209600;
> # 10mal soviel als Maximum
> max-lease-time 12096000;
> # Bei DHCP 3.0 kommt dazu
> ddns-update-style none; # unklar
Bei DHCP 3 ist es moeglich, DDNS (Dynamische DNS-Update) zu machen,
sprich, ein anfragender Client wird sofort im DNS mit seinem Name
registriert. Dies will man im regelfall nicht, daher "none".
> subnet 192.168.0.0 netmask 255.255.255.0 {
> option routers 192.168.0.1;
> range dynamic-bootp 192.168.0.40 192.168.0.250;
> # zuerst die IP vom Terminalserver-1
> host ts_name {
> hardware ethernet 00:E0:18:DB:59:F2;
> fixed-address 192.168.0.254;
> }
Der Terminalserver mit der MAC 00:E0:18:DB:59:F2 bekommt immer die IP
192.168.0.254
> group { #GROUP: Terminalserver-Raum-1
> option root-path "192.168.0.254:/opt/ltsp/i386"; # ab hier unklar
> next-server 192.168.0.254;
Die Reihenfolge ist unguenstig.
1. next-Server
=> Auf welchen Server liegen die Bootimages, die ich mir gleich per
TFTP holen soll? (Kernel zum starten des ThinClients)
2. root-path
=> Auf welcher Kiste liegt das Root-Dateisystem fuer die ThinClients
und wo liegt das da auf der Platte rum.
Die Angabe ist als NFS-Pfad zu verstehen (normalerweise)
Hier: NFS-Server: 192.168.0.254
Pfad auf Platte /opt/ltsp/i386
Ab hier werden zwei prinzipielle Bootmethoden neuerer und aeltere
Netzwerkkarte unterschieden.
"Etherboot and PXE are two pieces of software that allow one to boot a
workstation over a network"
deutsch:
Etherboot und PXE sind zwei verschieden Stuecke Software, die es
erlauben, einen Rechner ueber das Netzwerk zu booten.
> if substring (option vendor-class-identifier,0 ,9) ="PXEClient" {
> filename "/lts/pxelinux.0"; }
Wenn die Karte per PXE (Pre-Execution Environment => Vor-Ausfuerhung
Umgebung (?)) booten will, bekommt sie ein dafuer passendes Bootimage,
> else if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
> filename "/lts/vmlinuz-2.4.22-ltsp-1"; }
falls die Karte aber mit dem alten "Etherboot"-System booten will,
bekommt sie einen dafuer passendes Image.
> also ab "option root-path" ist das für mich nicht so richtig fassbar.
Ich hoffe, ich konnte Dich ein wenig erleuchten :-)
> das nächste Problem ist, wenn man ein Programm dazu schreibt, dann
> sollte man natürlich auch mögliche Alternativen kennen, falls die denn
> gebraucht werden könnten. Wenn durch diese Variante aber alle
> Terminalsserverfälle erfaßt werden, dann würde das natürlich reichen -
> ich weiß es leider nicht.
Mir erschliesst sich immernoch nicht, *wozu* genau, Du hier ein Programm
scheieben willst.
Wenn ich die anderen Mails richtig verfolgt habe, willst Du einen
Automatismus bauen, der automagisch alle MAC-Adressen im Netz erkennt
und auf Knopfdruck in einen DHCP-Konfig giesst.
Wozu der Aufwand?
ThinClients braucht man normalerweise garnicht in die dhcpd.conf
einzutragen; anstoepseln und booten.
Eintragen muss man die Dinger erst dann, wenn sie eine spezielle
Konfiguration erforden, die sich von der "Masse" abhebt, beispielsweise
weil sie eine ISA-Netzwerkkarte habe, deren Treiber per DHCP-Option
uebergeben werden muss oder sonstwas.
Es mag auch sinnvoll sein, die ThinClient nach Raeumen zu gruppieren,
ich weiss allerdings nicht, ob dies auf DHCP-Basis einen Nutzen nach
sich zeihen wuerde. (ausser statischen IPs).
Ciao
Max
--
Follow the white penguin.
Reply to: