Re: dhcpd.conf
Hallo,
herzlichen Dank für diese Erklärung.
Maximilian Wilhelm schrieb:
>
> Am Samstag, den 10. Juli hub Hans-Dietrich Kirmse folgendes in die Tasten:
>
> Ich kommentiere mal ein wenig :-)
:
> > # 10mal soviel als Maximum
> > max-lease-time 12096000;
bis dahin war's mir klar, aber in Hinblick Gestaltung der Webseite war/ist
das für mich gar nicht verkehrt gewesen.
>
> > # 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".
DDNS würde doch m.E. bedeuten, dass gewährleistet würde, dass der vergebene
Namen und die IP zu den Einträge im DNS passen. Das ist ja sonst nicht so.
Mir ist nicht klar, warum man das im Regelfall nicht will. (wohlgemerkt in
einem Intranet - wir haben ja ein Schulnetz!)
Die Konsequenz mit "none" wäre meines Erachtens, dass das Script beim
Ändern der dhcpd.conf sinnvollerweise auch gleich noch die Einträge im
DNS ändert. Oder sehe ich da was falsch? (das macht mein altes Script
übrigens nicht)
>
> > 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
ich gehe weiter davon aus, dass die group-option erst ab dhcp-3
existiert. (hat jetzt nichts mit dem Script zu tun: wie kann man
eigentlich die Version eines dhcp-Server herausbekommen?)
>
> > option root-path "192.168.0.254:/opt/ltsp/i386"; # ab hier unklar
>
> > next-server 192.168.0.254;
>
> Die Reihenfolge ist unguenstig.
soll ich das so auffassen, dass zuerst "next-server ..." und dann
"option root-path ..." kommen sollte?
:
>
> > 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 :-)
Ich verstehe das außerdem so, dass man mit dieser Art der Angabe (also diese
beiden Fälle) alle Fälle für die ThinClients im Griff hat - ist das richtig?
Nur noch zur Sicherheit: angenommen, man möchte nicht mit Terminals, sondern
mit echten (plattenlosen) Linux-Clients arbeiten, dann müßte das doch genauso
gehen?
>
> > 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.
fast. Es reicht natürlich nur die MAC-Adressen von den Rechnern zu ermitteln,
die man für die Vergabe der festen IPs auch eintragen will. Welches Verfahren
oder ob mehrere (vielleicht sogar kombiniert) angeboten werden, möchte ich
lieber extra diskutieren.
> Wozu der Aufwand?
hm. es wurde durch eine Mail eines Teilnehmers dieser Liste geschrieben, das
er die MAC-Adressen in die dhcpd.conf eingetragen hat. Wenn es noch mehrere
Leute betrifft, dürfte es als Nachweis der Sinnhaftigkeit m.E. genügen ;-)
jetzt konkret aus meiner Sicht, wann diese Vergabe der festen IPs Sinn
machen könnte:
1. Das (kommerzielle) Programm Master-Eye verlangt feste IP-Adressen. Dieses
dient zum Beispiel dazu, die Schülerbildschirme auf den Lehrerrechner zu
holen und umgekehrt, den Lehrerbildschirm auf die Schülerbildschirme
einzublenden. Ebenso kann es natürlich auch Bildschirmdunkelschaltung u.a.m.
Letzteres kann auch das kostenlos Programm von Michael Vistein (Schulnetz-Liste).
Und so weit ich weiß braucht auch die Bildschirmdunkelschaltung für
Linuxterminals von Dieter Kroemer feste IPs.
2. In einigen Schulen mit Windows-Clients läuft zur Kontrolle der korrekten
Anmeldungen das Tool von Rene van Bevern "smbstatus2html". (Kurt Gramlich
kennt RvB). Das kann auch so eingerichtet werden, das man das raumweise macht,
denn warum soll ein Lehrer die Aufsicht über Schüler übernehmen, die gar nicht
in seinen Raums sind. Das geht natürlich nur mit einer festen Zuordnung
Rechner - Raum => feste IPs.
3. Wenn man nur mit einem großen Netzsegment arbeitet und man möchte den
Internetzugang raumweise freischalten bzw. sperren, dann braucht man auch
feste IPs.
4. das setzt sich fort, wenn man bei der Kontrolle der besuchten Seiten
alle Rechner ausgeblendet haben will, die nicht zu diesen Raum gehören.
5. Nicht zwingend aber schön ist es für den Admin, wenn er bei einer größeren
Anzahl von Medienecken die IPs dieser Rechner entsprechend der Räume
gruppiert. Logfiles lesen sich da m.E. angenehmer.
> ThinClients braucht man normalerweise garnicht in die dhcpd.conf
> einzutragen; anstoepseln und booten.
ist schon klar. Auch die Windows-Clients laufen ohne feste IPs, aber auch
dort werden diese genutzt. Es geht nicht darum das diese ThinClients laufen,
sondern es geht (meist) um bestimmte Programme, die auf feste IPs angewiesen
sind. s.o.
> 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.
das wäre ein weiterer Grund.
> Es mag auch sinnvoll sein, die ThinClient nach Raeumen zu gruppieren,
> ich weiss allerdings nicht, ob dies auf DHCP-Basis einen Nutzen nach
> sich ziehen wuerde. (ausser statischen IPs).
natürlich macht das Gruppieren dann Sinn, wenn es große Schulnetze
sind und die Rechner von mehreren Leuten betreut werden (ist schon eine
Frage der Skalierbarkeit) und eben für die Programme, die raumbezogen
arbeiten. Ich weiß zwar, das man das auch mit Teilnetzen lösen kann,
aber meist kann man den Programmentwicklern nicht vorschreiben, wie es
zu gehen hat, sondern diese bieten eben manchmal auch eine Zuordnung
"Raum - IP" an.
für weitere Antworten (s.o.) im Voraus meinen Dank
/"\
Mit freundlichen Grüßen \ / ASCII ribbon campaign
Hans-Dietrich X against HTML mail
/ \ and postings
Reply to: