reading IP address given via DHCP

Mike Lovell 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 [1] 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.

[1] http://ipxe.org/

> 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.
> __NOT__.
>
>
>
> 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 mailing list