On Fri, 5 Jul 2002, George Georgalis wrote:
> On Thu, Jul 04, 2002 at 12:46:38PM -0700, Jeff Newmiller wrote:
> >On Thu, 4 Jul 2002, George Georgalis wrote:
> >
> >> I know they are okay, because I pretty much know what I'm doing. I'm
> >> new to LRP not Linux.
> >
> >Let's get something straight... you are asking for help, so you need to
> >behave like it. Whether you know what you are doing or not, you need to
> >be clear about which diagnostics you have performed, because if you were
>
> Sorry if my tone came across the wrong way :-} I simply meant I knew
> what they should be. I actually did check all those things, but
> apparently I cated resolv.conf from the wrong host, I don't usually make
> mistakes like that and I feel pretty dumb about it.
We all make mistakes... writing a message that logs the verification steps
we have taken is good both as a self-check to avoid looking silly later
and as a checklist for the reviewer to look for holes in. It is much more
effective than flurries of emails saying "did you check this"/"yes"/"how
about that"/"yes"/...
[...]
> >> 4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> >> link/ether 00:a0:cc:d9:21:e0 brd ff:ff:ff:ff:ff:ff
> >> inet 10.1.1.1/8 scope global eth1
> >> inet 10.0.0.1/8 scope global secondary eth1:1
> >> inet 10.0.0.2/8 scope global secondary eth1:2
> >> inet 10.0.0.3/8 scope global secondary eth1:3
> >> inet 10.0.0.4/8 scope global secondary eth1:4
[...]
> >Your abuse of eth1 is really bizarre. Why all the aliases? Why
> >10.1.1.1 at all? Even if there are valid reasons for all of this, you
> >should be aware that many assumptions are made in the configuration files
> >on the basic 192.168.0.254 ip address for the internal network. I think
> >there are several places in the dnscache and tinydns configurations that
> >will need to be fixed... can you show us what you have changed?
>
> The 10.0.0.0 network is for a DMZ, the ip aliases aren't necessary on
> this host. They are the remains of stock network configuration script
> I use. I've completely removed the stock shorewall and networking for
> networking.sh and iptables.sh scripts that I put in init.d. There will
> be aliases on the internet(s) interface(s) however, this will facilitate
> forwarding to hosts on the 10.0.0.0 DMZ. I'm not running a resolver on
> this box.
So... 10.1.1.1 doesn't belong here, right?
> >> >Finally, this sort of question belongs on leaf-user, NOT leaf-devel. I'be
> >> >moved it in my reply.
> >>
> >> Okay by me. I thought I had a development issue. My guess is I've
> >> stripped something that's required for name resolution. So I ask, what
> >> is used for host lookups (the udp/53 call) on lrp?
> >
> >The following is my understanding of how this works from using Bering RC2:
> >
> >Requests originating on the router are handled according to
> >/etc/resolv.conf. Bering comes configured with dnscache, and you will
> >need to add tinydns to the syslinux.cfg file to support local lan
> >lookups. Then following the lrcfg menus should lead you to all the
> >configuration files that need to be edited for dnscache and tinydns. You
> >will need to "svi tinydns restart" after altering tinydns' files.
> >
> >A lookup on the router goes something like:
> > a) checks /etc/nsswitch.conf to determine whether to check local files
> > and/or use dns protocol, and in what order. By default, files are
> > checked first, then dns protocol.
> > b) checks /etc/hosts, done if answer found
> > c) checks /etc/resolv.conf, queries nameservers as follows:
> > for each nameserver
> > done if nameserver recognizes literal name
> > if literal name is a hostname only, then
> > for each search network
> > done if nameserver recognizes literal name+search network
> > d) fail
>
> Thanks for the detailed account. It's the checks program I'm looking
> for. What checks? I don't have dig, host, nslookup, dnsqr or dnsq. Is
> there something in busybox that will do this? I don't see it.
I am describing the process that occurs within gethostbyname() when you
give a host name to a program like "ping", not a program called "checks".
If you want "dig" you need to add it to the router, as interactive lookups
are normally performed from a host machine. Note that "dig" goes straight
to the nameserver... it is specifically targeted at telling you what
nameservers think rather than giving you the most convenient answer, so
none of the alternate checks or search network stuff from above is
included.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
