Sparks Status
Recent News
Documentation page updated with permanent links to both sections.
Setting Up OpenDS 1.0.0 as a Naming Service for the OpenSolaris OS, Part 2 of 2: Advanced Configurations
The following is the second part of an excellent two part blog entry,
from the OpenDS team, detailing
the steps to setting up an OpenDS server on OpenSolaris.
http://developers.sun.com/identity/reference/techart/opends-namesvcs2.html
Setting Up OpenDS 1.0.0 as a Naming Service for the OpenSolaris OS, Part 1 of 2: Basic Steps
The following is an excellent blog entry from the OpenDS team detailing
the steps to setting up an OpenDS server on OpenSolaris.
http://developers.sun.com/identity/reference/techart/opends-namesvcs.html
We're looking forward to part 2!
Duckwater Standalone Enhancements in snv_93
The Duckwater (phase 0) standalone tools improvements, as well as a
number of improvements in connection management were delivered in snv_93.
Details on the Duckwater standalone changes can be found here:
http://www.opensolaris.org/os/project/duckwater/duckwater_phase0/
BigAdmin Solaris LDAP/Active Directory Document Now Available
The document
Using Kerberos to Authenticate a Solaris 10 OS LDAP Client With Microsoft Active Directory
is now available on BigAdmin at:
http://www.sun.com/bigadmin/features/articles/kerberos_s10.jsp
This document describes step by step, how to setup Active Directory, Kerberos
and per-user (self) authentication from Sparks, so that a Solaris machine can
run natively in an Active Directory Environment using Active Directory style
secure authentication (Kerberos).
The document is written from the point of view of a Solaris 10 deployment,
but it applies equally to Nevada as well.
This is a great paper to read.
Older News
Sparks phase 1 was delivered into snv_50 and s10u4
The first sparks delivery has been integrated into the 50th build
of Solaris Nevada.
It was also back ported and delivered into Solaris 10 update 4.
Sparks in it's current form is part of the current ON (OS/Net) Consolidation found here
Introduction
The Sparks project plans to make upward compatible changes to the name
service switch and to nscd(1M) in order to deliver new functionality including:
- Better caching in nscd(1M) and management of connections within the
updated framework. - Name service lookups that are access controlled at the naming service on a per-user basis. The updated the switch framework will add support for this style of lookups using SASL/GSS/Kerberos in a manner that is compatible with the authentication model used in MS Active Directory.
- A framework for the future addition of putXbyY interfaces.
This project also plans to fix many of the outstanding approachability bugs,
RFEs and known problems in the existing switch code including the hard coded
internal buffer length limitations, such as hosts and groups, the multithreading performance issues, etc.
Nsswitch Approachability Issues
The impetus for the sparks project stems from a review, about a year ago,
of the hundreds of outstanding bugs and RFE requests from customers that
have accumulated over the last 10-15 years, input we were receiving from
internal and customer deployments of LDAP naming services, the announcement
that we made to EOL NIS+ and an analysis of Active Directory features.
From this we assembled a list of high level approachability issues that include:
- Security - The switch is not secure by default, and not very secure in general.
- Caching - nscd caches a subset of {pw,gr,host,attr} only
- Scalable buffering - Internal fixed sized buffers cause scalability issues
- MT Scalability - The nsswitch is not MT hot and has fixed operational limits
- Write Capability - There is no write capability, password changing is ad-hoc
- Interoperability - We need to extend beyond basic “UNIX/Linux” interop
- Auto-configuration - is needed including DNS SRV and NWAM support
- Start addressing the RFEs - There are about 150 active RFEs... +bugs
We translated this into the following high level naming service requirements.
Naming services needs to:
- Respond to system changes w/o requiring reboot, and be able to work properly with smf, nwam, etc.
- Improve Security/Interoperability
- Use Kerberos {SASL/GSS}
- Enable secure User & Host credentialed authentication to DS
- Support Active Directory Schema {as applicable}
- Work on Approachability
- Fix/obsolete the {plethora of} divergent tools story {ypinit, nisinit, ldapclient versus one tool, ypmake, nisaddent, ldapaddnet versus one tool, etc.}
- Move towards obsoleting older APIs {IE embrace smf, move away from vi'ing nsswitch.conf}
- Fix or address all the RFEs and the bugs.
- Document the switch, and expose the APIs to 3rd parties.
Nsswitch As It Exists Today
The design of the name service switch, sometimes known as nsswitch or just "the switch", is based on early 90's technology
(It was the 18th ARC case {PSARC/1991/018} with nscd being added
in 1994 {PSARC/1994/391}.
It has had modifications to, but no significant retooling “of” since
that time. The initial design was geared towards single cpu, workstations
that people today would generally consider today as being low memory
configurations. Those systems with 16MB, 32MB, or a whopping 64MB RAM.
The nsswitch is not MT hot, or secure by todays standards.
The nsswitch is not smf, boot, install, user, administrator or configuration
friendly. There is very little internal or external documentation, the only public documentation being the various manual pages and administrator guide sections.
And finally, all the switch interfaces below the public getXbyY APIs, including all the backend interfaces have always been considered by Sun to be project private or at best consolidation private interfaces. This means that Sun has never guaranteed, although it has practiced, nsswitch backend compatbility between any release. And Sun has never guaranteed support for 3rd party or Open Source products written to these interfaces.
This OpenSolaris project plans to change all that.
The following is an overview diagram of the nsswitch, as it exists in Solaris 10 and earlier.
Every application that links with libc, and/or uses a getXbyY API
will have an instance of the switch activated. A small set of getXbyY
APIs make requests of NSCD, which uses it's instance of the switch
to fetch results, populate caches and then NSCD returns results.
The remaining getXbyY APIs are processed locally in each and every applications nsswitch policy engine. More on this later.
Nsswitch As Viewed by Sparks
The Key changes to the switch planned by the Sparks project are as follows:
- All XbyYs performed by centralized nscd switch
- Nscd switch is MT hot
- More robust caching and Caching of all DBs
- Managed Connections
- PutXbyY framework using a new, generic, app<->nscd door interface
- Holistic config, no more reboots, smf integrated
- Nscd manages per-user lookups (if enabled)
- Manages user/host principles uses forker & sub procs for actual per-user separation of work
- Supports nss_ad backend when delivered
The following is an overview diagram of "Sparks" nsswitch as we see the design at this point in time:
