Re: nis 3.8-0.1 on axp
On Tue, 24 Oct 2000, Miquel van Smoorenburg wrote:
> In article <Pine.LNX.4.21.0010231800580.11352-100000@higgsino.physik.uni-mainz.de>,
> Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> wrote:
> >Is anybody else experiencing problems after upgrading to the latest NIS
> >security patch? I did upgrade on a bunch of i386 machines and it worked
> >fine. On an Alpha machine, however, it works only in broadcast-mode!
>
> No idea. Someone NMUd it for me without my consent. I haven't
> tested it.
Eeeh, somebody NMUd it without your consent??? So what are we going to do
next? It seems like Debian is now recommending a security upgrade for
potato/alpha which is severely broken! What would you have done if there
wasn't any NMU yet? Backport the security patch, if that is feasible?
> >PS: Miquel, what is the point in having bind_wait() in /etc/init.d/nis
> > print 10 dots and then a 'timed out' without cleaning anything up
> > afterwards?
>
> What needs to be cleaned up?
I was refering to the ypbind process still being around...
> > If it has 'timed out', people don't expect ypbind to
> > be around any more, do they?
>
> I think they do, as Solaris does something similar I heard
...ok, never mind.
> > As it stands, the routine seems to
> > serve purely the cosmetic need of issuing a warning.
>
> Well, someone filed a bug against the NIS package..
>
> The idea is that in 99% of the cases, a NIS server will respond
> within seconds. If it doesn't respond in 10 seconds, the NIS server
> is probably down.
And we suppose it is coming up again RSN? Ok, makes some sense.
> The code was just added to be (reasonably) sure that there is
> a binding to a NIS server after /etc/init.d/nis has been run
Whatever "to be (reasonably) sure" means, since it needs manual reading of the
startup messages. I am still somewhat unhappy with it but I really woud not
bother.
Regards
-richy.
--
Richard Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
Reply to: