nonamed, /etc/hosts, /etc/resolv.conf - Minix

This is a discussion on nonamed, /etc/hosts, /etc/resolv.conf - Minix ; This is more an observation and commentary: I don't run a local DNS server and didn't want to waste the memory on nonamed, so I specify /etc/resolv.conf to the DNS proxy on the ADSL router, and configure /etc/hosts with the ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: nonamed, /etc/hosts, /etc/resolv.conf

  1. nonamed, /etc/hosts, /etc/resolv.conf

    This is more an observation and commentary:

    I don't run a local DNS server and didn't want to waste the memory on
    nonamed, so I specify /etc/resolv.conf to the DNS proxy on the ADSL
    router, and configure /etc/hosts with the IPs of my other local machines.

    However, I've just read the fine print in the "man host"s and subsequent
    "man named" that I can't use BOTH /etc/hosts and /etc/resolv.conf
    together as I would on a typical *nix machine.

    Instead I have to break with convention and use nonamed and overload how
    /etc/hosts is used. I suppose there is a question here as to why this way?

    Also while I suppose Minix is log way off from being used as alternative
    lean server in data centres, one common action breaks when you overload
    /etc/hosts. Namely you cannot simply set up a cron job to scp an
    /etc/hosts file from another non-Minix machine in your network and use
    it without first massaging it to insert any additional entries required
    to make nonamed work. While this may be trivial to script, it breaks
    with what a sys.admin. already knows about *nix machines, adding yet
    another exception to remember.

    --
    Anthony C Howe Skype: SirWumpus SnertSoft
    +33 6 11 89 73 78 AIM: SirWumpus Sendmail Milter Solutions
    http://www.snert.com/ ICQ: 7116561 http://www.snertsoft.com/

  2. Re: nonamed, /etc/hosts, /etc/resolv.conf

    In article ,
    Anthony Howe wrote:
    >Instead I have to break with convention and use nonamed and overload how
    >/etc/hosts is used. I suppose there is a question here as to why this way?


    I guess the basic idea is that network is properly administrated. Which
    means that things are supposed to be in DNS, not in random /etc/host files.

    >Also while I suppose Minix is log way off from being used as alternative
    >lean server in data centres, one common action breaks when you overload
    >/etc/hosts. Namely you cannot simply set up a cron job to scp an
    >/etc/hosts file from another non-Minix machine in your network and use
    >it without first massaging it to insert any additional entries required
    >to make nonamed work. While this may be trivial to script, it breaks
    >with what a sys.admin. already knows about *nix machines, adding yet
    >another exception to remember.


    I don't think there is anything that prevents you from hacking nonamed to
    deal with /etc/hosts in a way that is compatible with other systems.


    --
    That was it. Done. The faulty Monk was turned out into the desert where it
    could believe what it liked, including the idea that it had been hard done
    by. It was allowed to keep its horse, since horses were so cheap to make.
    -- Douglas Adams in Dirk Gently's Holistic Detective Agency

  3. Re: nonamed, /etc/hosts, /etc/resolv.conf

    In article ,
    Anthony Howe wrote:
    >
    >Instead I have to break with convention and use nonamed and overload how
    >/etc/hosts is used. I suppose there is a question here as to why this way?


    Once I taught nonamed to read /etc/hosts, it seemed a waste to the same
    code within all DNS using binaries, so I took it out of the library.
    What I like about the current setup is that all name lookups go through
    the same path, so what a command like 'host' sees is what all programs
    see.

    As for other UNIX-like systems. Have a look at /etc/nsswitch.conf. The
    Solaris systems here at the VU are set up to ignore /etc/hosts as soon
    as DNS is up. Not exactly "convention" either. Oh, and you have that
    nice 'nscd' daemon for those "Why didn't restarting the name daemon do
    anything?" moments.

    (Nscd = name service cache daemon. Caches passwd info too...)

    I guess the mistake we make is not that we break convention, but that we
    don't break it hard enough. Everything seems the same, but isn't.
    --
    Kees J. Bot, Systems Programmer, Sciences dept., Vrije Universiteit Amsterdam

  4. Re: nonamed, /etc/hosts, /etc/resolv.conf

    Kees J Bot wrote:
    > I guess the mistake we make is not that we break convention, but that we
    > don't break it hard enough. Everything seems the same, but isn't.


    I guess that is the crux. If you're going to do it different, go all the
    way so that people will recognise this as a different approach to a
    problem and that they should ignore what they think they know, read the
    man page, and get used to it. Mac OS X also shares similar problems. To
    paraphrase McCoy "Its Unix Jim, but not as we know it."


    --
    Anthony C Howe Skype: SirWumpus SnertSoft
    +33 6 11 89 73 78 AIM: SirWumpus Sendmail Milter Solutions
    http://www.snert.com/ ICQ: 7116561 http://www.snertsoft.com/

  5. Re: nonamed, /etc/hosts, /etc/resolv.conf

    In article ,
    Anthony Howe wrote:
    >Kees J Bot wrote:
    >> I guess the mistake we make is not that we break convention, but that we
    >> don't break it hard enough. Everything seems the same, but isn't.

    >
    >I guess that is the crux. If you're going to do it different, go all the
    >way ...


    Yes, but the problem with these things is that it's done step by step
    and each step doesn't seem to make it different. When nonamed was
    taught to read /etc/hosts, the library also still did, so nothing
    really changed. Later when the /etc/hosts code was cut from the
    library because it wasn't very useful anymore that too didn't seem like
    a big change. At that point /etc/hosts should have been renamed to
    /etc/nonamed.conf or something, but that seemed like an unnecessary
    change to a finished program that was using /etc/hosts already.

    Had I known about it beforehand then I would have taught nonamed to read
    something way more functional than the /etc/hosts format.
    --
    Kees J. Bot, Systems Programmer, Sciences dept., Vrije Universiteit Amsterdam

+ Reply to Thread