On Mon, 2007-11-26 at 11:18 -0500, Karl Wirth wrote: > Hello, > > A few of us discussed how, with freeIPA, to make NIS migration as easy > as possible for organizations. Here are the ideas we came up with: > > Problem Statement from Organizations' Perspective: For compliance, > organizations need to have one userid for their users and that userid > must have a strong password policy. Today, many organizations have > multiple NIS domains and often a user will have different (and > potentially conflicting) userids in the different domains. The same > problem is true for user groups, machines, and machine groups. NIS > is EOLd by Sun and is also not seen as compliant given the strength > and method of its password encryption. Organizations generally are > looking to reconcile their uids and guids and move to an LDAP server. > Hopefully, IPA can be a good solution for them. > > Problem statement from IPA perspective. If someone just tries to > deploy IPA into a heavy NIS environment, it may get adoption in some > new areas of deployment, but it will be hampered in adoption by the > fact that it is difficult for organizations to migrate off of NIS onto > IPA. Therefore, whatever we can do to ease the pain of migration will > help. > > Pain of Migration: What has to happen to accomplish a migration? > The following are not necessarily in order: > (i). Data has to be dumped from different NIS domains and moved into > IPA. If it is dumped slowly over time then some kind of data > synchronization is necessary. > (ii). Clients need to point at IPA not NIS. > (iii). NIS data has to be reconciled/mapped so the user has only one > userid > (iv). User must end up using just one password with their one userid > (v). Legacy clients that can only talk NIS need to continue being > supported > Note. All of this happens on production often mission critical > servers so the migration has to be slow, sure, and not big bang or > risky in any way. > > Requirement regardless of approach: We need to satisfy (v) above by > having a NIS server front end IPA > > Option A. Synch > - Using some kind of migration tool, organization maps data in a NIS > domain to the IPA userID > - Organization dumps a NIS domain and moves data into a tree in IPA's > Directory and sets up mapping from that tree to the IPA userID > - IPA has a synch capability that keeps that NIS domain and IPA's data > in synch This should be handled in the NIS makefiles, that generate the tables. They should be modified to run a script that re-syncs the relevent users. > - Slowly organization points clients from the NIS domain to hit IPA > via LDAP instead of the NIS server via NIS. > - Slowly organization removes data from the tree in IPA and just uses > the authoritative IPA userid > - Repeat for next NIS domain > - Pros: Slow migration. Leaves NIS server up while IPA is being > tried out. Gives quick fall back if something goes wrong. > - Cons: Data synchronization > > Option B. Virtual > - Using some kind of migration tool, organization maps data in a NIS > domain to the IPA userID > - IPA has a virtual directory capability that enables it to query the > existing NIS domain > - Slowly organization points clients from the NIS domain to hit IPA > via LDAP instead of the NIS server via NIS. IPA is proxying their > LDAP request out to the NIS server and proxying the response back. > - Once all the clients are migrated, organization dumps NIS data and > puts it into tree of IPA LDAP. > - Slowly organization removes data from the tree in IPA and just uses > the authoritative IPA userid > - Repeat for next NIS domain > - Pros: No synchronization > - Cons: The night the NIS server is taken down, there is risk as the > NIS server must be taken down and the data migrated in one step. I don't see how you can safely, sanely back an LDAP server onto NIS. The virutal option that can work is where the LDAP server provides a NIS table - either via a lame export on a script (to the tables that the organisations previous NIS servers already use), or with a NIS gateway onto LDAP. (Be it what PADL provides as proprietary software, or as Free Software). I think dumping out to the old NIS servers is the safe option. It can be demonstrated with sort and diff on the resulting files that the one-off migration has worked, and then we can just sync for the time until clients migrate to LDAP. Running a gateway increases the software and configurations we have to support, but may be the only option for (very) legacy clients. (This was a bigger problem in 2000 than it is now). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
Description: This is a digitally signed message part