[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dhcpd.conf



Hallo,

Maximilian Wilhelm schrieb:
> 
  :
> 
> Bei Skolelinux sind z.B. bereits Hostnamen fest an IPs gebunden:
>  ltspserverXY
>  dhcpXYZ
>  staticXY
>  printerAB
>  usw...
> 
> Hier wuerde DDNS wenig Sinn machen.

auch das verstehe ich nicht. Nehmen wir den "ltspserverXY", der bekommt
vom dhcpd diesen Namen (fest) zugewiesen und damit erfolgt auch vom
dhcpd auch der eintrag im DDNS. meines Erachtens auch nur einmal.
sollten "neue" Rechner von dhcpd IPs aus dem "dynamic"-Pool erhalten,
dann weiß ich allerdings nicht, wie dann das DDNS arbeitet. vielleicht
wird dann gar kein name im DDNS eingetragen, aber ein problem ergibt
sich doch m.E. damit nicht. sicher würde ich auch kein DDNS unter
dieser Konstellation einsetzen, aber die Argumentation verstehe ich 
trotzdem nicht. Es müßte auch problemlos mit DDNS gehen.

 
> Interessant koennte DDNS dann werden, wenn Du Deinen Rechner "richtige"
> Namen gebeen willst, und dies nur ueber einen DHCP-Eintrag abhandeln
> willst.

natürlich will ich richtige Namen vergeben. ich habe in meiner Schule das
kabinett 2. Demzufolge heißen meine Rechner kab2ap01 ... kab2ap15.
Das sind bei mir richtige Namen. So ganz habe ich das noch nicht gerafft 
mit dem DDNS.

  :

> > 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?)
> 
> Schau mal im Syslog nach, da muesste er sich mit Version melden

okay - danke

 
> > > Wozu der Aufwand?

  :

> > 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).

der Originallink:      http://www.netcontrol32.de/

  :

> > Und so weit ich weiß braucht auch die Bildschirmdunkelschaltung für
> > Linuxterminals von Dieter Kroemer feste IPs.
> 
> Das wird mit TCs vermutlich nicht klappen :)

das läßt sich einfach herausfinden ;-)


  :
 
> Bei ThinClients bringen Dir feste IPs IMO fuerchterlich wenig, da alle
> Programme auf dem Terminal-Server laufen und der TC nur noch die
> Ausgaben anzeigt.

stimmt. Dann wäre für mich folgendes interessant:

man nehme 2 Terminals die auf den gleichen Terminalserver zugreifen.
beide bearbeiten irgendwelche Dateien und speichern die ab. Nehmen wir
jetzt einfach mal einen Samba-Server, weil ich mich da besser auskenne.
wir nehmen weiter an, die Schüler haben beide einen Gastaccount und beide
speichern auf dem Verschiebelaufwerk.
erkennt man in dem Logfile irgendwie, an welchen Terminal derjenige saß,
von dem diese Datei abgespeichert wurde? 

 
> > > 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.
> 
> Teilnetze waeren hier zu kompliziert, dann schon eher einfach mehrere
> TerminalServer aufsetzen.

darum geht es nicht. Das Script hat zu skalieren - es sei den es sprechen
gewichtige Gründe dagegen.

 
> Mir erschliesst sich aber immernoch nicht, wie Du das alles
> automatisieren willst, da hier sehr viel Benutzeingriff noetig ist,
> das liegt einfach in der Natur der Sache.

das sehe ich überhaupt nicht so. und aus Erfahrung, die 48 MAC-Adressen
im ganzen Schulhaus einzusammeln (von Windows-clients) und auf dem 
Linux-Server einzutragen fand ich nicht sonderlich berauschend.

der jetztige zustand bei mir ist, einmal die leases-Datei löschen,
nach zwei Tagen (wenn jeder rechner einmal gelaufen ist) von der Konsole
einmal dieses Script starten und ich hatte feste IPs.

Wenn ich noch die IPs gruppiert haben wollte, dann muß ich bei jedem
Rechner die letzte Gruppe korrigieren. Das dauerte kaum 2 Minuten.
Beim nächsten Booten der Rechner hatte die diese IP.

allerdings habe ich nichts an den Rechnernamen geändert, denn das sind
die, die die Kollegen ihren Rechnern beim Einrichten verpaßt haben.
jedenfalls ist der Aufwand deutlich geringer und ein Fehler beim
eintragen der MAC-Adressen ist praktisch ausgeschlossen.

So wie ich meine wenigen Versuche mit Linux-clients (nur Knoppix)
verstehe, ist es da nicht anders. allerdings habe ich immernoch
sehr große verständnisprobleme mit den Ablauf bei den Terminals.



> Wenn Du alle MACs sammelst per broadcast-ping und arp -a oder sowas,
> und die dann alle in die dhcpd.conf haemmerst, hast Du dadurch noch
> nichts gewonnen, da Du dann nicht weisst, welcher Rechner welche MAC/IP
> hat. 

wie schon gesagt. bei Linux-clients und bei windows-clients mußte ich
bis jetzt immer einen Rechnernamen angeben. der erschien automatisch
auch in der leases-Datei und damit wurde der in die dhcpd.conf eingetragen.
ich sehe das problem mit der Zuordnung bei Linux- und Windows-Clients nicht
wohl aber bei Terminals. 




                                  /"\
Mit freundlichen Grüßen           \ / ASCII ribbon campaign
Hans-Dietrich                      X  against HTML mail 
                                  / \ and postings


Reply to: