[Freeipa-devel] NIS migration and IPA

Karl Wirth kwirth at redhat.com
Mon Nov 26 16:18:25 UTC 2007


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
- 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. 

Are the above two options correct?
Which is better for organizations?
Are there other options that I missed?

Regards,
Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20071126/02bec79b/attachment.htm>


More information about the Freeipa-devel mailing list