[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