=== 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.byname,passwd.byuid posixAccount group.byname,group.bygid posixGroup netgroup,netgroup.byhost,netgroup.byuser [1] nisNetgroup services.byname,services.byservicename ipService networks.byaddr,networks.byname ipNetwork protocols.byname,protocols.bynumber ipProtocol hosts.byname,hosts.byaddr ipHost rpc.byname,rpc.bynumber oncRpc ethers.byname,ethers.byaddr ieee802Device netid (none) [2] publickey.byname (none) [3] mail.aliases (none) [3] timezone.byname (none) [3] locale.byname (none) [3] netmasks.byaddr ipNetwork(?) [1] netgroup.byhost and netgroup.byuser appear to be unused by glibc [2] usually computed when tables are built; there is no specific counterpart object class in a directory [3] there is no specific counterpart object class in rfc2307, but nisObject could be used 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. As far as IPA is concerned, we already have access to a directory and we already know its schema, so 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.