Meet the Gang   1   2   3   4   5   6   7   8   9   10   11   12

setting nameservers from the command line

From Faber Fedor

Answered By Ben Okopnik, John Karns, Chris Gianakopoulos, Jay R. Ashworth

Here's an interesting problem that I've yet to find a solution for:

A friend of mine has Live Slackware Linux on a CD: he can boot off of the CD and have a functioning Linux box. Of course, the entire filesystem is read-only.

[John K] Interesting - I just happened to have been reading the following HowTo a couple of hours ago, and it mentioned something related:

BTW, the SuSE 7.3 live CD writes a file to the FAT partition (approx 80 MB, IIRC) on the hard disk, and keeps config data there. One can edit files (don't know what restrictions there are in that regard), and it "remembers" the changes the next boot.

If he had a functioning DHCP server, he would then manually configure the NIC and run the DHCP client daemon, dhcpcd. Of course, the DHCP server would provide the ip address of a name server.

But he doesn't have a functioning DHCP server. Since he can't edit /etc/resolv.conf (read-only filesystem, rememeber?) how does he set his nameserver?

I check the man pages and found that he can set his resolver options and search domain with enviroment variables, but nothing was said of how to change/set the nameserver IP(s). I went looking for a program called 'resolv.*' but I couldn't find where the resolver actually resides.

I suggested he mount /etc/ to a ramdisk, but there should be a more elegant way to do it.

Suggestions?

[Ben] Grab the source and stare at it for a bit. Either there is a command-line option for it, or you should be able to hack it in fairly easily.

Great Minds Think Alike! That's what I did after posting my message. Here's what I found out:

You're not going to be able to do it, at least not from "the command line". AFAICT, there is no "resolver program" per se; all name resolution is done by calling glibc functions (gethostbyname in my case).

[Ben] Oh... of course. I actually knew that, but had filed it in a dusty corner of the brain, and the file cabinet slides rusted and froze in place.

The code in question lies in glibc-<version>/resolv/res_init.c around line 230 in my version. The authors allow for setting resolv.conf's "domain" and "search" options from enviromant variables (LOCALDOMAIN and RES_OPTIONS, respectively) but they don't allow any such thing for nameservers. Adding the code to read nameservers information from enviroment variables do that doesn't seem difficult. Learning how to compile and debug system libraries under linux, OTOH...

[Ben] Ask Chris. He's the one that keeps reading that "writing drivers and whatever under Unix" book.

[Jay] Written, if it's the one I think you mean, by one of my correspondents, Jon Corbet from LWN, along with some European gent whose name eludes me for the moment.

[Chris] Here I go jumping in the middle of a conversation after I disappear for a week. I'm always reading those books by W. Richard Stevens. These days, the book is "Unix Network Programming", the 1990 edition. The newer editions are in the queue, where he discusses network programming in his first volume and IPC (including threads) in his second volume. What's cool about the first volume of the new edition of "Unix Network Programming" is that he talks about Linux, too.

Another interesting thing I found out: the path and name of /etc/resolv.conf is hard coded, in both the Red Hat version and the GNU version!

[Jay] Not surprising.

I assume you're talking about the hardcoding of /etc/resolv.conf and not the lack of reading the nameserver(s) from the enviroment.

Note that making that part of glibc environment dependent makes possible certain Trojan-style holes that are much more difficult to cause otherwise;

So why does that not apply to LOCALDOMAIN and RES_OPTIONS? I could force you to search my domain (nefarious.com) by planting a trojan that sets LOCALDOMAIN. And, if I read the man pages correctly, I can set RES_OPTIONS="ndots:0" and force you to search my domain.

[Jay] ...It doesn't, actually.

[Jay] [re: Trojans] caution is indicated (and I could almost guarantee a formal patch would be rejected by the maintainers).

I'm jazzed enough about this that I want to search down the maintainers and quiz them about this. Perhaps this weekend...

[Jay] Be interesting to hear.

This page edited and maintained by the Editors of Linux Gazette Copyright © 2002
Published in issue 76 of Linux Gazette March 2002

HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

Meet the Gang   1   2   3   4   5   6   7   8   9   10   11   12