reading IP address given via DHCP
mike at dev-zero.net
Wed Sep 25 10:28:53 MDT 2013
On 09/25/2013 12:52 AM, Dan Egli wrote:
> That's an interesting approach. I've never even heard of tcpclient before,
> so that's a new one. I take it $TCPLOCALIP would be the IP address of the
> default route? I.e. eth0's address? Any way to obtain the card's MAC
> address with that?
> Still, baring any research into the dhclient hooks, I think ifconfig's
> output is the most reliable way for me to obtain the info I need.
> Especially as I'd be looking for the MAC address in this instance too.
> Here's basically what I'm after (and yes, it's kind of convoluted. But the
> guy I was explaining this network setup wants to be supremely lazy
> regarding updating the config files for dhcpd and the named zone files):
> Given an office consisting of two buildings, given a server GW, which has
> three network adapters: eth0 = gateway to the world, eth1 = local
> workstations (same building as GW resides in), eth2 = workstations in the
> other building. Given that except for GW, no machine would have a hard disk
> drive or solid state drive.
> What he wants (and what I've been scripting for him) is so that when a new
> machine that has never booted onto that network connects for the first time
> (this is only for PXE booting. If a machine has it's hard drive then this
> doesn't work), it boots into a tiny NFS root who's only purpose is to
> record IP and MAC info, then obtain a hostname from the user. At this point
> it writes all this to the server and flags the server (semaphor file in
> this case, rather than sockets). Then a program on the server would take
> this information, record a new DHCP reservation for that MAC, and record
> the machine's IP in the local DNS program, and restarts both, at which
> point it deletes the semaphor file. Once the file is deleted, the script on
> the new workstation sees it, and reboots itself. Once this reboot begins it
> grabs a DIFFERENT nfs root (via a /tftpboot/pxelinux.conf/<MAC> file
> instead of reading /tftpboot/pxelinux.conf/default), and boots into the
> nfsroot for that computer. The reason he wants to do it this way is because
> he wants a separate NFS root for computers in office 1 vs in office 2, and
> for them to be on a separate subnet. This way, he doesn't have to update
> configuration files (like I said, lazy) when machines are added to the
> network. The network updates itself.
it sounds like you have already built most of this so this suggestion
might not be of much value. have you looked at using ipxe  for this?
it can be used with pxe to do all kinds of cool things like booting from
http, iscsi, fcoe, or others and has a limited scripting ability. ipxe
could do a workflow like this:
* system pxe boots which loads ipxe
* ipxe makes a http to a webserver providing its own mac and ip addresses
* the webserver does a lookup of the mac address and create dns/dhcp
entries if they aren't known
* the webserver then returns a configuration script for ipxe to load
the kernel and ramdisk with the proper kernel cmdline options
* ipxe loads the kernel and ramdisk and continues the boot process
this seems like it would be a bit of a cleaner way to implement this
whole process. the ipxe scripting provides variables for easy access to
the ip and mac addresses and some user input and menu functionality.
i've been working on a side project that works almost like this but the
web service will be twiddling bits on iscsi targets to change what iscsi
lun a systems boots from dynamically. ipxe is some cool stuff but it
would be a large design change from what you're working on.
> So, I wrote up a setup that does exactly that. I was just wondering if
> parsing ifconfig and grepping for the MAC and IP in there was the best way
> to obtain the information (I really dislike playing around with grep/cut
> combinations when I can avoid it) or if there was a better way. But if
> grepping ifconfig is that common, then I guess it works for me. It DOES
> work (as far as I can tell, I haven't had a chance to actually test it
> yet), but it just seems kind of ugly/convoluted to me. Oh well. What the
> boss/client wants, the boss/client gets, as long as it's not TOO
> unreasonable. :) Gotta love working with federal government employees.
> Anyway, thanks for the tips all!
> --- Dan
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
More information about the PLUG