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

[Sigbjorn Lie]

On 04/04/2011 09:00 PM, Dmitri Pal wrote:
> 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.
>


Done. :)

https://bugzilla.redhat.com/show_bug.cgi?id=693483