<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> 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 </body> </html>