[Freeipa-users] NIS/local files to IPA migration

[Simo Sorce]

On Mon, 28 Mar 2011 15:43:18 +0200 (CEST)
"Sigbjorn Lie" <sigbjorn at nixtra.com> wrote:

> On Mon, March 28, 2011 15:24, Dmitri Pal wrote:
> > On 03/28/2011 09:01 AM, Sigbjorn Lie wrote:
> >
> >> On Mon, March 28, 2011 14:31, Dmitri Pal wrote:
> >>
> >>> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote:
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>>
> >>>>
> >>>> I have written some scripts for migration from NIS/local files
> >>>> to IPA. They will import the passwd, group, netgroup, and hosts
> >>>> maps.
> >>>>
> >>>>
> >>>>
> >>>> This is the first version, be aware of bugs. :)
> >>>>
> >>>>
> >>>>
> >>>> Please read the README file before using.
> >>>>
> >>>>
> >>>>
> >>>> You can download them from here if you are interested:
> >>>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php
> >>>>
> >>>>
> >>> Thank you for the contribution!
> >>> I see that it is under GPL v2. Would you mind relicensing it
> >>> under GPL v3? http://www.gnu.org/licenses/gpl-3.0.html
> >>>
> >>>
> >>>
> >>> Would you be interested in these scripts being incorporated into
> >>> the project source? Rob, can you please take a look into this?
> >>> Should we consider rewriting them in Python and incorporating
> >>> into the main tool set or leave and use as is?
> >>>
> >>>
> >>>
> >> Sure I can relicense to GPL v3. All I care about is the scripts
> >> staying open and free to use. :)
> >>
> >>
> >> You can include as a part of IPA if you would like. I was planning
> >> to re-write them all into perl, as my initial efforts to write
> >> them in bash for maximum portability didn't work out, and the
> >> netgroup and hosts import scripts ended up written in perl.
> >>
> >> I cannot help re-writing to python, I don't know the language.
> >>
> >>
> >
> > Ok, thank you!
> >
> >
> > Can you elaborate a bit about the constraints you have regarding
> > migration. As far as I understand you have users and groups with
> > colliding gids and you have to resolve things manually to make
> > things exactly as they were and IPA as is does not allow you to do
> > so as it always creates a privite group with the same GID.
> >
> > I have a stupid question: what is the implication of actually not
> > doing things exactly as they were but rather embracing the IPA
> > model of the unified UID/GID namespace? Is the reason that there
> > are some applications scattered in the enterprise that might have
> > gids configured explicitly in the configuration files (like SUDO
> > for example) and updating those would be a challenge or there is
> > something else?
> >
> 
> That question is not stupid. However...:)
> 
> Migrating group id's is possible, but quite a job. We just moved a
> few users's uid's as they had been in the enterprise for very many
> years, and had a dangerously low UID's. Searching trough the file
> servers for files belonging to these few users using a "find -exec
> chown ..."  took 3 days. Migrating GID's would also take a very long
> time.
> 
> Secondly, any files restored from backup would have the wrong
> uid/gid. Several of our clients have a rentention time of 10 years
> for backups. That's quite some time to keep a mapping table over
> new/old uids/gids.
> 
> Third, we would need to map our applications to see if any of them
> store or use the GID.
> 
> As you can see, migrating to IPA just became a much more time
> consuming and higher risk project than it could be.
> 
> Is there a reason for why the approach with a private group per user
> is forcibly chosen?

As a default it gives us the maximum compatibility with other directory
services (like AD). Plus when we did freeipa v1 we got a lot of push
back when we choose a single group (ipausers) to be the primary group
due to traditional umask use for users.

So we decided to make it a default and let admins that really do not
want it to remove the groups.
I guess we could add a switch somewhere to turn off UPG groups creation
completely, if you think that is something really important you may
want to open an RFE, although I am not sure when we will have cycles to
get to implement such a switch for the moment.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York