Joao Roscoe wrote:
> Ok, I really mixed things up. I'm sorry (and I'm also very sorry for
> the *huge* delay in answering to this thread).
There was quite a long delay in that message! But what is a year
among friends? :-)
> I meant that **ypbind** fails to bind to ypserver.
A critical difference. Thanks for clarifying that.
> And yes, the NIS domain servers are specified in yp.conf by their
> fully qualified names, and those names are hardcoded in /etc/hosts
> file.
Seems reasonable. I still use the broadcast protocol instead. But
what you are doing is supposed to work okay and I can only assume that
it does.
> Also, /etc/nsswitch.conf has hosts line as below:
>
> hosts: files nis mdns4_minimal [NOTFOUND=return] dns mdns4
The contents there tell me that you have one of the zero-conf packages
installed, libnss-mdns IIRC or possibly avahi, and that inserts those
mdns entries into that file. I have had inconsistent behavior in that
configuration. Some systems behave fine with the mdns configuration.
But others have really odd and problematic DNS lookup behavior. I
haven't concluded to root cause other than to say that if libnss-mdns
is removed (or the nsswitch.conf file modified / cleaned) then the
problems stop. And so when I run into the problem the easy solution
is to remove libnss-mdns or clean nsswitch.conf to make the problem
stop.
In either case, I use the following configuration line for hosts in
/etc/nsswitch.conf.
hosts: files dns
You might try it that way and test your error case again.
> So, the ypbind should get the correct IPs for the servers immediately.
> But what I see, in practice is: most times, the machine(s) gose up
> properly. Other times, I see a timeout notice at boot
> ("...backgrounded"), and the system comes up unable to mount the
> remote users' "home" directories. When that happens, normally
> rebooting several times doesn't solve enything.
I would try the simplified nsswitch.conf hosts line configuration and
see if it improves things for you.
> Restarting nis and autofs, in this order *does* solve the issue.
If forcing the start order in a different works then that sounds like
some incorrectly specified dependency in the /etc/init.d/* scripts.
> PS. This is the second time I send this message, In the first time, I
> got an weird automatic
> response, something about "Case 80324" (googled for that, it's
> somehing about a bug in php4 package).
> Hope that was not me doing something really wrong. Double-checked the
> "To" address content, just in case.
We all got your first message. The problem you saw was not with the
mailing list. The problem is that for unknown reasons bad people
sometimes subscribe the mailing list to addresses that go to automated
bug trackers or forward to RT accounts or generate vacation replies or
all manor of bad behavior. Why? I don't know. Why does anyone do
bad things?
When they do these things then every message that anyone sends to the
mailing list generates a backscatter spam from that bad place. As
soon as these are noticed the listmasters remove the offending
address. If you can debug these quickly then it helps the listmaster
to report them. But because it is so annoying before too long someone
will have debugged it and gotten the offenders removed from the
mailing list.
Bob
Attachment:
signature.asc
Description: Digital signature