reading IP address given via DHCP

Dan Egli ddavidegli at gmail.com
Fri Sep 27 05:42:02 MDT 2013


On Wed, Sept. 25, 2013, at 8:22 PM, Levi Pearson wrote:



> There are ways to update most DNS servers without rebooting them. See

> http://en.wikipedia.org/wiki/Dynamic_DNS for some pointers.



I'm familiar with the ddns ability in dhcpd and named. In fact, at first I
was going to use them. But my understanding was that ddns doesn't update
the reverse pointers. I.e. it will insert a record into the DNS server that
box A is 192.168.0.15, but it won't insert the PTR to say that 192.168.0.15
is box A in the in-addr.arpa zone. That's why I use the scripted method I
devised. Now if the ddns method DOES update the reverse pointers, that's
different. And then there's the point where I'd ask how well DHCPd would be
at applying changes to forward FILE A and reverse file A vs. forward file B
and reverse file A. Remember that there's two networks, each with
independent address ranges. But the way it's setup so far is that although
the DNS would contain two zone files for the address pointers (i.e.
a.upper.rec and a.lower.rec) there is only one zone file for the
in-addr.arpa reverse pointers. I don't know how well ddns would work that
way.



> Well, technically ifconfig is rapidly moving towards deprecation in

> Linux, to be replaced by the more general `ip` tool. And I prefer a

> nice little awk script to grep/cut combinations. Whenever you need to

> munge a text file and sed it too weak but perl is extreme overkill,

> awk is where it's at. Much of perl's file-munging capabilities are

> shamelessly lifted from awk, so it shouldn't be terribly hard to pick

> up.



Not hard unless you're lost in perl and in awk. To me, personally, the old
adage about awk being 'awkward' is more than a little true. Maybe it would
be more elegant, but to someone like me who's used awk maybe twice in the
25+ years I've been on computers, that's REALLY pushing things. Maybe if I
had the time to sit down and learn awk's syntax or something, then it would
be easier. The problem is that the only way I've ever used awk in place of
cut was when the delimiter was a space. That wasn't so hard. But if the
field delimiter is anything else, such as a colon or a period, then while
I'm sure awk would be capable of doing it, I'd be completely lost as how to
implement it. I'd have as much luck implementing the whole thing in ADA
(which is to say, snowball's chance in hell). I will admit to curiosity
though. Perhaps you wouldn't mind sending me a couple examples of how you'd
use awk in this instance? Right now, between the various scripts I've
implemented, I use grep/cut to read the IP address of the adapter, read
it's MAC address (and convert that address into the subnet and the
individual address, i.e. 192.168.X.Y, separating X and Y), and to pull the
UID/GID assigned to a user by useradd to modify some database entries.
Grep/cut may not be the most elegant, but from what I can tell so far, it
works, and it's something I understand.



As to the ip tool, I've not heard of that. I'll have to take a look at it's
man page and see how well it could do the job. I take it that ip can show
the IP as well as the MAC information? That's one point where I ran into
hang-ups on the dhclient-scripts idea, was that from what I could tell by
reading the man page for dhclient-scripts, there's no environment variable
for the MAC address of the adapter, and for the setup I've designed, that's
a critical element as the PXE boot files are named after the MAC addresses
of each computer.



--- Dan


On Wed, Sep 25, 2013 at 8:22 PM, Levi Pearson <levipearson at gmail.com> wrote:

> On Wed, Sep 25, 2013 at 12:52 AM, Dan Egli <ddavidegli at gmail.com> wrote:
>
> > 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.
>
> There are ways to update most DNS servers without rebooting them. See
> http://en.wikipedia.org/wiki/Dynamic_DNS for some pointers.
>
> > 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__.
>
> Well, technically ifconfig is rapidly moving towards deprecation in
> Linux, to be replaced by the more general `ip` tool.  And I prefer a
> nice little awk script to grep/cut combinations.  Whenever you need to
> munge a text file and sed is too weak but perl is extreme overkill,
> awk is where it's at. Much of perl's file-munging capabilities are
> shamelessly lifted from awk, so it shouldn't be terribly hard to pick
> up.
>
> /*
> 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