In a message dated: Thu, 16 Mar 2000 10:00:01 EST
"Lussier, Kenneth" said:
>Well, the files will be going from one RH6.1 box to another RH6.1 box. I
>pretty much always use shadow and MD5 on every box I build, so I'm hoping
>that it works.
In that case you shouldn't have any proplems at all.
>I've never really used NIS, since by the time I got into all
>of this stuff, there were enough horror stories about it that I figured I
>might as well not even bother
Well, despite all the horror stories, and all the insecurity, as Rich pointed
out, it can make life quite convenient. I've used it for quite a long time at
every location I've worked at and for the most part, haven't had too many
problems.
There are a few of things that make NIS a lot better:
1. The ability for an NIS slave or master to deny a bind request.
Systems binding to a slave they shouldn't have been binding to has
cost me a lot of time hunting down bizarre problems.
Of course, had the slave been updated with the most recent versions of
the maps, then this really wouldn't have been an issue :) But still,
I'd prefer more control on who binds to what slaves, especially with
the advent of Linux/Unix laptops everywhere. All it takes to get the
passwd file now is less than 5 minutes on a LAN and ypbind -broadcast
request.
2. The ability for NIS to use shadow passwords.
This alone would greatly enhance the security of NIS.
3. The ability for NIS masters to keep track of when a slave doesn't
respond to a db push and/or the client to periodically update
itself.
I don't know how many times I've troubleshot problems that turned out
to be caused by the fact that the yp slave on a particular subnet
hadn't been updated in 6 months and no one ever knew about it.
(of course, SunOS4.1.1 as the ypslave OS might have had something to
do with it :)
--
Seeya,
Paul
----
Doing something stupid always costs less (up front)
than doing something intelligent.
A conclusion is simply the place where you got tired of thinking.
If you're not having fun, you're not doing it right!
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
