Re: bug reporting?
On Fri, Jan 14, 2005 at 11:56:31AM +0100, Giacomo Mulas wrote:
> On Fri, 14 Jan 2005, Kaare Hviid wrote:
>
> >1) Using a pure64 amd64 box (or alpha for that matter) as an NIS slave
> >with an i386 box as master _will_ work, albeit rpc.ypxfrd will complain.
>
> Yes, I actually came to this same conclusion, after some more work. What
> puzzles me is that _every_ time I start the nis server with the stock
> /etc/init.d/nis script, be it manually or at boot time, the maps are
> transferred anew! Perhaps, due to the fact that map files are not
> identical to the ones on the master server, the nis slave server thinks
> its maps are outdated and tries to refresh them every time it is started,
> every time falling back to the enumerate mechanism, and thus every time
> creating new files which are not identical to the ones on the master
> server...
If I'm not mistaken, this functionality was introduced in the sarge
NIS package. And if you think about it, it makes sense. The NIS slave
has no way of telling if its maps are outdated or not (all updates are
normally initiated from the master). Thus, if the slave server has
been down, you might be sitting with an old passwd database without
knowing about it - and you certainly want to avoid old passwds flying
around on the net if you want to remain sane.
If you've previously only used woody NIS servers, watch out! There
are syntactic changes in the /etc/ypserv.conf file. Thanks to the
excellent packaging of the Debian nis package, it should be an almost
painless upgrade though. (Yes, I really do think the Debian nis package
is extremely well maintained.)
> >2) Avoid mixing architecture, OS, distro, implementation and version of
> >NIS servers in a production environment unless you actually find
> >pleasure in voodoo and the black magic of NIS/YP. (I obviously do :-))
>
> Well, I do find some pleasure in a moderate use of voodoo and the black
> magic of NIS/YP myself, but I do not have a choice. I will replace old
> x86 computers in the cluster I administer with amd64 ones, gradually,
> which means that for some time I will have to live with a mixed
> environment. And I will have to do my best to ensure that 64bits machines
> are used near their full potential (hence a 64bit system) but still
> sacrificing as little functionality as possible (hence a full 32 bit
> system in a chroot cage as well). Oh, and it should be as transparent as
> possible to users, as well. I think I am going to need some psychiatric
> help in the near future...
IMHO, NIS doesn't make use of much resources - thus, dedicating an old
low-memory box with reliable hardware is my own personal policy
regarding slave NIS servers.
-ukh
Reply to: