Private in-house domain

[Tech Writer]

Paul,

My initial goal was to end hours of frustration, and just get it working. 
However, now that I've got the concepts a little more clear in my mind, I've 
taken your advice, and used the /etc/sysconfig/network-scripts/ifcfg-eth0 
and ifcfg-eth0:0 files.  If anyone else is interested in seeing my current 
configuration, I've updated the files in: http://www.handspun.com/review/

Peg


----- Original Message ----- 
From: "Paul Lussier" <p.lussier at comcast.net>
To: "Tech Writer" <TechWtr at handspun.com>
Cc: <gnhlug-discuss at mail.gnhlug.org>
Sent: Wednesday, May 16, 2007 8:53 AM
Subject: Re: Private in-house domain


> "Tech Writer" <TechWtr at handspun.com> writes:
>
>> Andrew and Stephen,
>>
>> Thanks for the tips!  Your combined suggestions seemed to do the trick. 
>> I
>> edited my rc.local file and added the lines:
>>
>>     echo "Set up IP alias interfaces"
>>     /sbin/ifconfig eth0:0 192.168.1.30
>>     echo "Set up routes"
>>     /sbin/route add -host 127.0.0.0 dev eth0
>>     /sbin/route add -host 192.168.1.1 dev eth0
>>     /sbin/route add default gw 192.168.1.1
>>
>> Now eth0 has the IP address 10.25.1.10 that I assigned, and also has an
>> alias of the IP address 192.168.1.30 that my Linksys wants to talk to. 
>> The
>> routing table uses the IP address of my Linksys router, and I can now
>> successfully get nslookup responses outside my private mini-domain and my
>> web browser can see the rest of the world, too.
>
> Hi Peg,
>
> Though this "works", I think it's taking the wrong approach.  What
> you've done is hacked a file to set something up through brute-force
> as a work-around to the correct way of configuring the network for
> this host.
>
> Granted, this is your home environment, and therefore the "normal
> rules" of "proper network management" may not apply.  However, by not
> applying and following said "normal rules" you've cirumvented your
> learning experience and now only understand how to use this
> brute-force method.  This is both inelegant and ulitmately
> unmaintainable.  Additionally, it's non-trasferrable to the "real
> world" (maybe that doesn't matter, I don't know).
>
> RH, CentOS, etc. all have a "proper" means of configuring the network.
> Hacking the rc.local script isn't the way to do it.
>
> If what you're really after is a single NIC on multiple networks, then
> configure a proper ifcfg-<interface> file for the NIC alias.  This
> file will take all the standard key=value pairs of a normal interface
> and properly set up the routing tables for you.
>
> Googling for 'CentOS ifcfg interface aliases' resulted in 915 hits for
> this combination, the 2nd return on the very first page is the exact
> documentation you need to set up an alias ifcfg file for CentOS.
>
> Using the correct configuration files to set this up also has a number
> of advantages vs. the hack to rc.local:
>
> - if you ever add another physical NIC to the system in question,
>   it's a matter of simply renaming a file vs. remembering where this
>   configuration is, then hacking the file to reflect the correct
>   interfaces and routes.
>
> - if you want to temporarily turn off the 10.x network, it's a matter
>   of ifdown'ing the interface, which will also take care of removing
>   all the routes for you.  ifup'ing the interface will re-configure
>   them for you.  As it is, you can set things up, but tear them down.
>
> - The lines above, though they work, don't look correct to
>   me. (i.e. there is no host 127.0.0.0, that's a network, and
>   probably should be using a -net option.) Properly written config
>   files set things up correctly and remove human error and the
>   guessing that goes with being unsure.
>
> -- 
> Seeya,
> Paul
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/