So long NIS+, it was fun

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.

Comments:

Chris,

Don't worry, there are plans to find a home for the oldest NIS+ namespace and keep it going for as long as we possibly can :-)

Posted by Jason Banham on December 07, 2009 at 04:51 AM GMT #

What was the driver for the removal of NIS+?

Can the code be forked & improved?

Posted by DavidHalko on December 07, 2009 at 08:45 AM GMT #

Given that almost no one apart from Sun had implemented NIS+ and LDAP does provide a solution that is in most ways acceptable as a replacement NIS+ had no future. Removing it reduces the burden on the Support and Sustaining organisations.

Given that the code is out there one could fork it but with the best will in the world I don't really think it would make sense.

Posted by Chris Gerhard on December 07, 2009 at 09:31 AM GMT #

Wow, its been a long strange journey. Back in 1990 when Bob Lyon told me he wanted me to "replace YP with something secure" I wasn't sure even where to start, but through the weird RSA debacle, the Directory Wars, the sudden demand by AT&T to license it, and the failure to put it in SunOS 4.1, NIS+ was one of my most educational endeavours. It never would have happened without Rosanna Lee's exquiste coding skills or Kamal Anand's dedication, and the birthing pains were hard, but when it got adopted by the swiss banking system I knew that it some future. Thanks for the nice epitaph Chris.
--Chuck

Posted by Chuck McManis on December 07, 2009 at 02:01 PM GMT #

As Jason says the Guy Fawkes NIS+ domain will be joining some neat Sun 21st century technology really soon. It will be hosted on a ldom on a T5240. There is the small matter of getting it there but I confident a bit of nismkdir,nisrmdir etc will see it move it without too much effort.. If it gives us grief we will know where to get help...

Posted by Paul Humphreys on December 08, 2009 at 11:51 AM GMT #

NIS is like the Law, NIS+ is like the advanced version of the Law. Sun, I think implemented it as a last resort, because they weren't getting anywhere with a developer. It's not usually somehting you want to implement, but you can only work so long with a prima donna developer, before you rip out your hair. A developer who doesn't deliver work on time and with accuracy, eventrually is let go and sometimes they ended up handed over to the Law.

My sister was a developer, at one time, and she thought she was the best and only in the world, but she thought that the Law was pure fiction.

Sooner or later, that might be what happens to Chris, here? :) As he seems to have the same behavior patterns as my sister? :)

Completely someone unworkable. Eventually, she learned someone doesn't have to deal with your idiotisms and when NIS and NIS+ were implemented in 1998-1999, her career as a Solaris developer ended. Now, she works as an insurance clerk. She still every once and a while acts if nothing ever happened, and she has an episode, because she has long-term, permanent brain damage from her past methamphetamine use/abuse. She doesn't take the medications she is prescribed, and she's generally impossible to deal with. I feal sorry for her current boss, who has to deal with her. Our mother has to deal with every so often. But, it's still her daughter. I'm lucky I don't have to deal with her, anymore.

Posted by guest on December 11, 2009 at 01:38 PM GMT #

An LDAP server CAN be served by itself. It is only a matter of starting the services in the right order so that the LDAP daemon gets bootstrapped before the native client. Not rocket science but definitely a bummer that it isn't the case by default, I'll agree to that.

Posted by arnaud on December 19, 2009 at 08:11 AM GMT #

Post a Comment:
Comments are closed for this entry.
About

This is the old blog of Chris Gerhard. It has mostly moved to http://chrisgerhard.wordpress.com

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today