6 Nov
2018
6 Nov
'18
1:32 a.m.
On 11/05/2018 09:12 AM, Arthur Krewat wrote:
It was possible, unless you used a network filter on
the server, to just
ypbind to the server, and then you could ypcat all the maps. Not to
mention that without specifying a server, it was a broadcast. So any YP
server on the subnet would answer.
Duly noted. Thank you for the explanation.
NIS+ was encrypted over the network, and needed a
public key mechanism
to authenticate clients. One of which was the server itself. With it's
hierarchical architecture, it had a lot of flexibility.
The encryption would thwart snooping. But it doesn't sound like that
would prevent a properly authenticated client from ypcating too much
information.
I really never understood why people didn't like
NIS+. It took an extra
step or two to do certain things, but once scripted it was a fairly
secure way of handling authentication and directory services.
I've heard a lot of people say they don't like something when they had
something else that did what they needed / wanted (at the time) that
required less work. Occam's Razor / Parsimony....
I added new maps to it to do custom .cshrc/.profile
scripts using
subsections in /usr/local/profile, and a few other customizations. Add
it's compatibility mode for NIS/YP, and you could use it to serve not
only Sun clients.
Nice.
Operationally, it really was just NIS/YP but with a
lot of whiz-bang
features. In a deployment of a few hundred mechanical and electrical
engineers, with about 50 actual workstations and servers I never had a
problem with it. Permissions and other features were actually quite useful.
ACK
However, I must say, I kept the NIS/YP way of using
flat files to
regenerate the NIS+ maps each time they were edited. So I guess I
cheated a little.
Work smarter, not harder.
--
Grant. . . .
unix || die