Legacy Configuration Files Support

Duckwater: Legacy Configuration Files Support

Contents

• 1   Introduction
• 2   Install/Update
  • 2.1   Import Needed Indication
  • 2.2   Import Algorithm
• 3   Normal System Operation

1   Introduction

One of the goals of project Duckwater is to move the name services related configuration to SMF.

It is obvious, that for backwards compatibility, we need to support "legacy" name service (NS) configuration files. Most notably, it is /etc/nsswitch.conf for name service switch, /etc/resolv.conf for DNS client, /.../ypservers for NIS client, /.../ldap_client_* for LDAP client and (TBD for NIS+ - Igor).

We will recognize two modes, in which new name service configuration subsystem will deal with legacy configuration files - Install/Update and Normal System Operation.

2   Install/Update

The first case is the time, when system was installed and or updated from previous (pre Duckwater) release. The update case is obvious - we update the system, which had only "legacy" NS configuration files and we have to import those into the repository. The install case we provide for backwards compatibility with install tools (e.g. sysidns(1M)), so they don't have to be modified before/in-sync with initial integration of Duckwater.

Where will the import happen? milestone/name-services is not good enough, because we need the import to happen before any of the back-end services start. Should we introduce new milestone - e.g. /milestone/name-services-config? - on which milestone/name-services will depend? YES - milestone/name-services-config seems good enough.

2.1   Import Needed Indication

The indication whether the system has already been "converted" to new configuration (in SMF) scheme will be boolean property called configuration_in_smf in /milestone/name-service-config (Any better idea?) which will have default value of false delivered by manifest file.

2.2   Import Algorithm

The algorithm will be pretty simple: once the import program finds out, that the system needs to be converted (please see configuration_in_smf above), it will:

* Find out the domain from /etc/defaultdomain

• Import the NS switch configuration from /etc/nsswitch.conf
• Get the list of back-ends needed from /etc/nsswitch.conf
• For each needed back-end, import the configuration files
• Associate all the imported back-end configuration with the imported NS switch configuration, thus forming the NS profile.

The imported profile name would be profile_DDMMYYYY. Users will be able to rename the profile later, if needed.

3   Normal System Operation

During normal operation of the system, we will generate the legacy configuration files at the NS profile "reconfiguration time" - i.e. at the time when the user switches from one profile to another - thus supporting in backward compatible manner all the software, which needs to read these configuration files.

We also need to support direct modification of the "legacy" configuration files by users or software external to Duckwater. We decided, that the best way to handle this situation is to depend on the indication from the user, that the configuration files have been modified and we should import them - i.e. we will by default depend on svcadm refresh milestone/name-services Or should it be milestone/name-service-config?

The behavior of the import program will depend on the property configuration_import_mode in /milestone/name-service-config.

If the value is compatible, the configuration files can be written to and as soon as nscd(1M) detects this (order of seconds), the files will be imported into the repository, overwriting the currently active profile. This option is there for backward compatibility and we strongly recommend *not to use it*.

If the value is refresh, the configuration files can be written to and are imported into the currently active profile overwriting the values currently in the profile as soon as user (or script, or program) issues svcadm refresh milestone/name-services (or calls libscf function smf_refresh_instance(3SCF)).

If the value is ignore-files the configuration files will be read-only interface - the modifications to files will be ignored and moreover the files will be overwritten later (at the "reconfiguration time" - see first paragraph.).