Wow David! Thanks for the tutorial! You might want to consider replacing your keyboard soon! Grin!

David Johnston wrote:
On Wed, 2004-10-27 at 11:09, Lanman wrote:

The hosts file can be set as the first location to probe for relevant host info. Typically having a comprehensive hosts file will allow you to search for a PC by hostname faster (YMMV) since the hosts file is the first reference that your PC will look at before going to Internal or External DNS. Also, if your DNS server is under heavy use for other services running on that server, it will reduce network traffic a bit if the hosts file is up-to-date.


True.  Consider, though, that the terminals don't have a full resolver
and only use the /etc/hosts file.  Pete's setup still works because most
of the time, the terminals don't need to know the IP addresses or names
of other terminals.  Putting everything into /opt/ltsp/i386/etc/hosts
won't hurt, but *most of the time* it doesn't get you anything, either
;-)


I wasn't saying that his setup wouldn't work, BTW. I was saying that he might want to consider that the hosts file can be used for a variety of things. DNS resolving is one thing, but being able to find specific terminals would be very handy for the administrator if he wants to run forced logout or scheduled events for specific terminals. If the IP's or names of the individual hosts change, that will make it more difficult, and if it's a large network, almost impossible.


The most obvious way to prevent this, is to define a specific address for each terminal in DHCP (by associating the MAC address and hostname of a client), and in order to make it easier on the administrator, by adding the IP's and hostnames to the hosts file.

Adding the dns info that Pete has done IMHO, is a good idea as well, and I'll probably use his idea for my various LTSP networks, especially since I've been using something similar for conventional "Fat Networks" for about the last 12 years. So I have to agree with you.


As for LTSP, the hosts file should allow you to write script files using the host names instead of IP addresses which should help in diagnosing errors in those scripts.


Can you give an example?

Off the top of my head, these scripts or processes use IP addresses and allow you to substitute the hostname for the IP if the hosts file is accurate.


1) http://www.ltsp.org/contrib/netprint

2) http://www.ltsp.org/contrib/LTSP_FLOPPY.txt

I'm sure that other scripts can use the same things as well. For an administrator who likes to keep things simple, substituting the hostname for an IP would probably help.


If you try starting your terminals one at a time, you should see that the highest IP is leased out to the terminal that requests an IP first.
I've never seen a DHCP server that does it the other way around, but if it can be done, then I'm all for it.


Mine seems to hand them out in numerical order (.1, then .2).

In all my years, I've never seen a DHCP server that hands out addresses in numerical order using the basic config. That includes DHCP servers on routers, managed network devices, etc.. If on the other hand some customizing done to the defacto config, then it would make perfect sense, especially where the MAC address of a client NIC is being assigned an address, such as I've done in LTSP. From the looks of your script file below, it would seem that you've done something similar too.
In a case like that, it makes perfect sense that the IP numbers would be handed out in a completely different order.



That said, I prefer to use static IP addresses, like this:

In dhcpd.conf, I put entries like this:
host ws1 { hardware ethernet aa:bb:cc:dd:ee:01; fixed-address ws1; }
host ws203 { hardware ethernet aa:bb:cc:dd:ee:ff; fixed-address ws203; }

In DNS, I put entries like this:
ws1    A 192.168.0.1
...
ws203 A 192.168.1.203

and this:
1     IN PTR ws1.fqdn.com.
...
203  IN PTR ws203.fqdn.com.

I set up the DNS entries with a script at install time, since they all
look the same.  I also set up the DHCP entries at install time, but
they're commented out, like this:

subnet 192.168.0.0 netmask 255.255.255.0
{
 range 192.168.0.240 192.168.0.250;
 allow unknown-clients;
 use-host-decl-names       on;
 get-lease-hostnames       off;

# Etherboot hosts
group {
filename "/lts/vmlinuz-2.4.26-ltsp-2";
option root-path "192.168.0.254:/opt/ltsp/i386"; host ws1 { hardware ethernet aa:bb:cc:dd:ee:ff; fixed-address ws1; }
host ws2 { hardware ethernet aa:bb:cc:dd:ee:8d; fixed-address ws2; } # host ws4 { hardware ethernet REPLACE-ME; fixed-address ws3; }
# ######## that line is repeated for ws2 through ws240
}


# PXE hosts get the PXE linux loader:
group {
filename "/lts/2.4.26-ltsp-2/pxelinux.0"; option root-path "192.168.0.254:/opt/ltsp/i386"; host ws3 { hardware ethernet aa:bb:cc:dd:ee:e1; fixed-address ws3;
}
}


New terminals get an address in the range 192.168.0.240 - .250. Note
that they *don't* get a root-path, so they won't actually boot. arpwatch will inform us when a new workstation connects, and we can
cut-n-paste the MAC address into a wsX line, uncomment it, restart
dhcpd, and reboot the new terminal. Once that's done, the terminal will
get the root-path and will boot. I've heard mention of a script that
will automate this, but I haven't used it.


You may need to tinker with this to get it working for you.


If it can work in a reversed manner, that would certainly simplify things with the hosts file.


Actually, it's much simpler if wsXX is at 192.168.0.XX.

Nice idea David. Your file allows for some interesting ideas. I'm going to have to take a closer look at this. Any other scripts you're not *sharing* by any chance? Any possibility of running my coffee-maker for instance? Grin!


Thanks for the insight. I've been doing things a bit differently, but it's always good to see someone else's perspective. Methinks that World Domination just got one step closer! LOL!

--
Lanman
Registered Linux User #190712


------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net

Reply via email to