[K12OSN] Two subnets

Sat Jan 13 21:05:59 UTC 2007

You're right; the new nameservice zone is indeed not needed and in fact
will never even be used.  I personally prefer /etc/hosts over
centralized DNS for this, since it's really only used for LTSP client
lookup purposes.  The advantages to /etc/hosts in this case are as
follows. 

1.)  You could have multiple 192.168.0.x and 192.168.1.x lookup tables
(remember, everything's NAT'ed, and thus kept private).  Yes, that means
you can re-use this same /etc/hosts file on multiple LTSP servers
without running into hostname/IP address conflicts across your network. 
LTSP servers already do this by default for 192.168.0.x.  Sure, you
could do the same thing with BIND running on each LTSP server, but it's
a little bit more work to set up.  Centralized DNS, to my knowledge,
doesn't let you re-use hostname/address information at all (does it?).

2.)  Say you do go w/ centralized DNS, since either you choose to use
different subnets for each LTSP server's client segment, or you have
only one LTSP server.  If that centralized DNS for some reason does take
a dump, the LTSP clients will have problems, but with either /etc/hosts
or locally-running BIND present, they'll still be just peachy.  They may
not be able to hit Google or www.h4x0rz.com, but people can still get on
and access their local files.

--TP
_______________________________
Do you GNU!?
Microsoft Free since 2003 <http://www.gnu.org/>--the ultimate antivirus
protection!

Michael Blinn wrote:
> Terrell:
>    Brilliant! Your response was informative and conclusive. Thank you
> very, very much.
>    I've also created another nameservice zone for the 192.168.1.0/24
> subnet.(though I'm not sure this is necessary, considering the hosts
> file).
>
> Again, thank you very much.
>   Michael Blinn
>
> Terrell Prudé Jr. wrote:
>> This is how I used to do x86, PPC, and UltraSPARC clients off of one
>> server.  It's certainly doable, but there are several things that you
>> get to modify:
>>
>> /etc/dhcpd.conf
>> /etc/hosts
>> Some stuff under /opt/ltsp/
>>
>> For /etc/dhcpd.conf, just copy 'n' paste your existing 192.168.0.0/24
>> scope, thus creating two scopes.  Wherever you see 192.168.0, replace
>> it with 192.168.1.  dhcpd is smart enough to know to hand out
>> 192.168.1.0/24 addresses only on the interface in that subnet (I'm
>> assuming you'll use 192.168.1.254 for your server's new NIC).  Also,
>> make sure that you have a "next-server" setting in each of your DHCP
>> scopes that points to the appropriate NIC (192.168.0.254 for the
>> original scope, and 192.168.1.254 for the second, new scope).  That's
>> how your clients will know where to TFTP-boot from.
>>
>> For /etc/hosts, you get to essentially replicate everything in there,
>> in a way that you avoid name/address resolution conflicts.  You know
>> all those entries that look like this?
>>
>> 192.168.0.9     ws009.ltsp      ws009
>>
>> Well, you'll need to make 254 more entries to account for the clients
>> on the new (192.168.1.x) NIC.  But you can't have two "ws009.ltsp"
>> entries pointing to different addresses?  What do do?
>>
>> My solution was to tweak the names so that my /etc/hosts has entries
>> like this:
>>
>> 192.168.0.009     ws0009.ltsp      ws0009
>>
>> 192.168.1.009     ws1009.ltsp      ws1009
>>
>> 192.168.2.009     ws2009.ltsp      ws2009
>>
>> In my case, I simply added a digit to the hostname, specifically, the
>> third octet of the IP address.  A simple little script will generate
>> this for you:
>>
>> ****** CUT HERE ******
>> rm mynewetchosts.txt
>> for octet3 in `seq 0 2`
>> do
>>   for octet4 in `seq -w 1 254`
>>   do
>>     echo '192.168.'$a.$b'   ws'$a$b'.ltsp   ws'$a$b >> mynewetchosts.txt
>>   done
>> done
>> ****** CUT HERE ******
>>
>> Then, after backing up your original /etc/hosts (/etc/hosts.bak,
>> perhaps?), just copy this mynewetchosts.txt over to /etc/hosts.
>>
>> Finally, we deal with /opt/ltsp/.  In my case, since my clients are
>> different CPU architectures, I needed /opt/ltsp/i386 (comes with
>> K12LTSP), /opt/ltsp/ppc, and /opt/ltsp/sparc.  Each of these
>> subdirectories served a different subnet.  Well, since all of your
>> clients are x86, then you get to have more than one "i386" directory
>> tree.  Why?  Yes, the binaries are the same, but you need to tell
>> your clients which IP address to talk to.  Just copy your entire
>> /opt/ltsp/i386 directory over to, say, /opt/ltsp/i386-1.  Head on
>> into this new /opt/ltsp/i386-1, and tweak lts.conf such that wherever
>> you see "192.168.0", you replace it with "192.168.1".  There should
>> be only a couple of spots, and, IIRC, the critical one is the
>> "SERVER" variable.
>>
>> Note that, in your second DHCP scope in /etc/dhcpd.conf, you will
>> need to tweak "option root-path" to point to /opt/ltsp/i386-1.  In my
>> /etc/dhcpd, I've got three scopes, one pointing to /opt/ltsp/i386,
>> one pointing to /opt/ltsp/ppc, and one pointing to /opt/ltsp/sparc. 
>> The reason you have to do that is because this is the directory that
>> your LTSP clients use to do the pivot-root.  In your case, each of
>> your /opt/ltsp/i386 and /opt/ltsp/i386-1 will be pointing to a
>> different IP address (NIC) on your LTSP server.
>>
>> Once you're done, you should be able to turn up your second NIC,
>> bounce dhcpd, and have clients netbooting on your other subnet.
>>
>> HTH,
>>
>> --TP
>> _______________________________
>> Do you GNU!?
>> Microsoft Free since 2003 <http://www.gnu.org/>--the ultimate
>> antivirus protection!
>>
>>
>> Michael Blinn wrote:
>>>  I have ~50 clients I'd like to split into two subnets, each on
>>> their own separate switches going into a separate gig NIC on the
>>> server. Out of the box, k12ltsp 5.0.0 likes to run on 192.168.0.0/24
>>> right? What do I need to change in order to have a working LTSP
>>> configuration (complete with dhcp, tftp etc) on 192.168.1.0/24 in
>>> addition to the 192.168.0.0/24 ?
>>>
>>> If I can safely set both GB NICs on the same subnet, but separate
>>> switches, please let me know, however my initial thought is that the
>>> broadcasts will slow the system down by transversing switches via
>>> the server's NICs.
>>>
>>> -Michael Blinn
>>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> K12OSN mailing list
>> K12OSN at redhat.com
>> https://www.redhat.com/mailman/listinfo/k12osn
>> For more info see <http://www.k12os.org>
>
> -- 
>
> If this is my day of harvest, in what fields have I sowed the seed,
> and in what unremembered seasons?
> - Kahlil Gibran
>
>
> CONFIDENTIALITY NOTICE: This message, and any attachments that may
> accompany it, contain information that is intended for the use of the
> individual or entity to which it is addressed and may contain
> information that is privileged, confidential, or otherwise exempt from
> disclosure under applicable law. If the recipient of this message is
> not the intended recipient, any disclosure, copying, or other use of
> this communication or any of the information, which it contains is
> unauthorized and prohibited. If you have received this message in
> error, please notify the original sender by return mail and delete
> this message, along with any attachments, from your computer. Thank you.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/k12osn/attachments/20070113/6e1623eb/attachment.htm>