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

[Dmitri Pal]

On 04/03/2011 10:58 PM, Simo Sorce wrote:
> 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.
>
Opened ticket: https://fedorahosted.org/freeipa/ticket/1154

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/