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

[Dmitri Pal]

On 04/04/2011 10:34 AM, Sigbjorn Lie wrote:
> On Mon, April 4, 2011 04:58, 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.
>>
> I see your point from a security point of view. So for new installations I agree this would be the
> way to go.
>
> Why can't I see the user private group listed as a group? 

Because it is implied. They are filtered out unless you explicitly want
to see them.
We thought that by default we do not want to spam your group lists with
those groups.


> Also I'm allowed to create a new public
> group with the same GID as the user's private group without a warning. I should be getting a
> warning and a force option?


Yes, if this is not the case it is a bug. Please log one then.

>
> Rgds,
> Siggi
>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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