So long NIS+, it was fun
By user12625760 on Dec 07, 2009
With the push of this feature into Solaris:
6874309 Remove NIS+ from Solaris
PSARC/2009/530 Removal of NIS+
a bit of Solaris history is made. The namespace that was to replace NIS (YP) has been survived by the system it was to replace.
NIS+ was the default name service in Solaris 2.0 and it was a long while before Sun relented and shipped a NIS (YP) server for the release. As a support engineer however NIS+ was interesting and was reasonably secure.
The flaws however limited it's adoption:
Servers could not be in the domain they served. This was eventually fixed however I find it amazing that we have the same situtation now with LDAP where native LDAP clients can't be served by themselves.
It was hard. The technical difficulties of getting NIS+ name spaces to work since they both used secure RPC and were used by secure RPC gave it a reputation for being hard to set up and unreliable. The reliability however has been resolved such that there were many large scale deployments that ran successfully.
The use of secure RPC made short running programs very expensive if they used NIS+1. So scripts that did NIS+ were slow.
NIS+ allowed me to learn many things:
I wrote a NIS+2html gate way that allowed you to navigate an entire NIS+ namespace from a browser (the browser was mosaic) using cgi.
An interposing library that allowed you to see all the NIS+ calls being made.
A TCL library giving direct access to the NIS+ library calls. This allowed very fast scripting since only one secure RPC session has to be generated.
Unfortunately none of them made it out from Sun as this was long before we became more open.
However it's future looked sealed when it's EOF was announced in Solaris 9 but a surprise reprieve allowed it to live in Solaris 10. It looks like the same will not be true for OpenSolaris. If you are still using NIS+ then you need to be finalizing your plans to move to LDAP!
It seems my baby is unlikely to make it to 21.
So long NIS+. It was fun.
1Each process would have to generate a secure RPC session key and negotiate a secure connection with the server. If the process then only made a single call to the server this session key would then be thrown away.