Requirements

Duckwater requirements

Duckwater requirements

Contents

• 1   Framework for simplified name services management
  • 1.1   Unifying view of name services management
  • 1.2   Name services profiles
  • 1.3   Profile configuration
  • 1.4   Profile activation
  • 1.5   Exported interfaces
  • 1.6   Administration tool
  • 1.7   Configuration tool
  • 1.8   DNS and NIS clients changes
  • 1.9   Direct editing of legacy configuration files
  • 1.10   Management interface to nscd(1M)
  • 1.11   Active Directory interoperability management interface
  • 1.12   Extensibility
• 2   LDAP client improvements
  • 2.1   Server discovery
  • 2.2   Auto-configuration
  • 2.3   Security
  • 2.4   Exposure to LDAP terminology in user interface
  • 2.5   Serviceability / supportability

1   Framework for simplified name services management

1.1   Unifying view of name services management

The solution must provide unified interface (API and tools) to name services (NS) management. It must also allow for existence of multiple NS configurations in the system . These configurations must be easy to create/modify and it must be easy to activate/deactivate a selected NS configuration. The solution should fully supersede the current NS back-end client configuration and administration tools (i.e. ypinit(1M) -c, ldapclient(1M) etc.).

Question

The solution should fully leverage SMF for name services monitoring and configuration transitioning.

1.2   Name services profiles

The solution must provide means for organizing NS configuration into name services profiles. The profile must define the overall NS configuration of the system; i.e. it must capture the NS switch information (/etc/nsswitch.conf), domain name, and the profile-specific back-end configuration of all the NS back-ends active in the profile. Profiles must be the primary source of the NS configuration information in the system. It must be possible to specify numerous (hundreds, tens in practice probably) profiles.

It must be possible to create profile configuration for the following back-ends: files, DNS, NIS, LDAP, AD.

Profiles should be stored in a central profile repository.

Note

It is expected that profiles will be implemented using SMF services/instances. IE, the SMF will be used as the profile repository.

Question

What about secret data, such as LDAP client proxy credentials?

Note

AD back-end will be delivered within the Winchester project.

Question

Do we want to allow profiles for 'files'? Or, will files be special? If we allow profile: for what files then? Even /etc/passwd :-) ?

Question

Would it be useful to allow some kind of profile relationship (maybe inheritance)?

Question

Should Kerberos configuration be part of the profile (e.g. should default realm be part of the profile)? Should default PAM policy? How does this fit into a name service tool?

Question

Any special requirements for printers?

1.3   Profile configuration

The framework must have easy to use yet powerful way of configuring all name service related subsystems. The solution must provide facilities for accomplishing the following tasks:

• Creation/modification/deletion of NS profiles (including back-end configurations)
• Configuration validation (back-end specific)
• Import/export from/to external representation
• Import/export from/to legacy configuration files
• Saving preliminary configurations (but not used if invalid)
• "Assisted" configuration (tool if used in interactive mode should react on user's input and provide him/her with reasonable alternatives
• Cloning of profiles

1.4   Profile activation

The fundamental functionality the solution must provide is profile activation/deactivation. Upon new profile activation, the solution must correctly shutdown all the currently active back-ends, reconfigure the system in line with the newly requested profile, and start all the necessary back-ends accordingly.

This operation must have minimal impact on the system. The solution must carefully handle the processing window from the first back-end of the old profile shutdown till the successful start of the last back-end of the new profile.

At most one profile can be active at any given time (current/running profile vs. a saved profile).

Question

What should happen if activation fails? We restart the previous profile? It depends ... in some cases keeping the old one active does not make sense. In other cases though, trying to preserve the previous *functional* settings is good thing.

1.5   Exported interfaces

Administration interface will be available to external tools so they can either trigger switch to a different profile (like NWAM will), refresh currently enabled profile or modify particular (even currently enabled) profile.

Configuration interface will also be available to external consumers (like dhcpagent(1M)). It will be possible to change configuration of either enabled or currently disabled profile. It will also be possible to create a new profile.

1.6   Administration tool

Duckwater must deliver a administration tool. This tool will be the main Solaris name services administration tool and the primary consumer of the administration facilities offered by the subsystem.

The tool must provide command line interface. A GUI version of the tool should also be provided.

The tool must allow to activate and deactivate profiles, send notification that currently enabled profile has been changed, and finally the administration tool should allow to manage nscd(1M).

Note

A GUI version of the tool would probably be a plugin into the Visual Panels tool.

1.7   Configuration tool

Duckwater must deliver a configuration tool. This tool will be the principal Solaris name services configuration utility.

The tool must support command line interface suitable for both interactive work and batch/script processing. A GUI version of the tool should also be provided.

The tool will allow to create/delete/modify profiles, validate profiles (the interactive version will ensure profile validity/consistence on-the-fly), test (dry run) configuration setup, import/export to external representation and legacy configuration files.

The tool be modular -- the UI part should be cleanly separated from the back-end specific functionality. It must be easily extensible to support (possible) new NS back-ends.

Note

Significant part of Duckwater project "added value" lies on this tool - namely, it will be the one to help users configure the LDAP back-end name service on their systems.

Note

The configuration tool UI will probably be modeled after the SMF svccfg(1M) tool.

Note

A GUI version of the tool would probably be a plugin into the Visual Panels tool.

Question

Are there other GUI possibilities/requirements?

1.8   DNS and NIS clients changes

For non-LDAP (DNS, NIS) back-ends, the solution must only provide enough functionality to enable unifying the configuration and administration into the single framework with the LDAP back-end.

1. The back-end daemons & tools must remain unchanged
2. Allow for storing configuration data in the same repository as for LDAP
3. Import/Export from/to legacy configuration files

Note

  To maintain backward compatibility and to avoid having to change existing non-LDAP back-ends, legacy configuration files will be generated dynamically upon profile transition from the primary configuration stored in the repository.

1.9   Direct editing of legacy configuration files

Newly created tools will be the primary means for changing NS configuration. However, the solution must allow for direct modification of the NS configuration files. An explicit refresh request is required to make these changes effective.

Note

Automatic detection of file changes is seen as problematic -- possibly triggering changes on an inconsistent configuration.

1.10   Management interface to nscd(1M)

The solution must provide a management interface to the Name services caching daemon (nscd(1M)).

Namely, the following functionality must be provided:

• refresh the running configuration
• pause/un-pause to allow for reconfigure window
• get statistics
• flush cache

Note

Expand for Sparks needs.

1.11   Active Directory interoperability management interface

The solution must provide interface for

• AD domain joining
• ID mapping configuration/management

Note

Expand for Reno/Winchester needs.

1.12   Extensibility

The solution must be easily extensible by a new back-end. This must be reflected in the overall structure of the solution - back-end specific functionality must be clearly separated in modules.

Note

Do we need to provide any hooks (e.g. before a back-end started)?

2   LDAP client improvements

The following sections expand on the LDAP back-end specific requirements. The required features are going to be implemented in the framework's Configuration tool and/or in the LDAP back-end code itself.

Note

Duckwater covers the client side of LDAP NS configuration and administration. The server side (e.g. the responsibilities of idsconfig(1M)) will be dealt with in a separate project.

Note

Validation/configuration checking are thought to be part of the generic framework and the unified configuration tool.

2.1   Server discovery

The solution must support LDAP server discovery using DNS SRV.

Note

Adding support for DHCP LDAP URL option should also be considered.

2.2   Auto-configuration

It must be possible to configure LDAP NS with minimal user interaction.

The solution must

1. be able to auto-detect LDAP environment it is working in

1. use sensible defaults whenever possible

Question

What schemas (besides RFC2307bis) should we be able to auto-detect & support?

2.3   Security

The solution must leverage the GSSAPI/Kerberos authentication option introduced by the Sparks project.

The solution must follow the 'secure by default' principle (in both the configuration and the operation phase).

2.4   Exposure to LDAP terminology in user interface

The user interface of the solution must be usable without detailed knowledge of LDAP terminology.

2.5   Serviceability / supportability

The solution must improve on overall serviceability of the LDAP NS client; namely by improving on error/problem reporting.