=== Migration ===

There are a number of well-known maps which a typical NIS deployment
includes, and for most of these, there's typically just one schema which
is used to represent that sort of information in the directory.

Map			Object Class
------------------	------------
passwd			posixAccount
group			posixGroup
netgroup		nisNetgroup
services		ipService
networks		ipNetwork
protocols		ipProtocol
hosts			ipHost

Shadow password information is also frequently kept in a directory, but
if a directory is capable of performing password policy enforcement at
the server, the shadow map's contents are best ignored when migrating.

Historically, directory administrators have piped the output of 'ypcat'
through scripts which split apart entries and produce boilerplate LDIF,
which is then imported into the directory.  The script is typically also
supplied a DN to be used when constructing the DNs for entries whose
LDIF it outputs.

Because IPA already has access to a directory, we can provide a smarter
tool which can do these things:
* automatically determine the right superior DN to use
* use exactly the right schema for an IPA server
It may even go so far as to add entries to the server directly.

There's one wrinkle here: automount maps.  Generally, an automount map
is stored as a set of entries beneath an entry which serves as a
container for the map, but the schema used for the container and the map
entries themselves can vary.

I checked with Jeff [1], and he tells me that Solaris automounter's
native LDAP support expects to see maps stored as "automountMap" entries
with the map name stored in the "automountMapName" attribute, with
entries in the map being of type "automount", with the map key stored in
the "automountKey" attribute and the value being stored in the
"automountInformation" attribute, corresponding to the schema detailed
in RFC2307bis.

The current generation of the Linux client supports this scheme as well
as two other legacy schemes, but the other two schemes are undesirable
because they use the "cn" attribute to hold the key, and this prevents
keys from being case-sensitive.  Case insensitivity is a big deployment
problem for our customers.

This is further complicated by care that the Linux client takes to avoid
disruptions.  Specifically, when not configured to expect that a
specific schema is in use, it will search for map information using each
of the three, using the first which returns results, and when doing so,
it attempts to use each legacy schema before attempting to use the
recommended one.

Given that, I think that we should only ever generate data which follows
the RFC2307bis schema, only support administering such data, and leave
the rest as a services and migration issue.

The migration of data from automount maps presents a second problem --
maps can be named arbitrarily, and when a domain contains automount maps
other than "auto.master", those maps can have any valid name.  But they
tend to have names which start with "auto." or "auto_", so a migration
tool would most likely process the well-known maps using per-map schema,
process maps which have names such as these as automount maps, and
process all other maps as generic NIS map entries.

The amount of review required suggests that this needs to be either a
manual process or a guided one.

[1] Inaccuracies are mine.