[Freeipa-interest] Re: [Freeipa-devel] NIS migration and IPA

[Andrew Bartlett]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/freeipa-interest/attachments/20071128/c67c5673/attachment.sig>