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

[Sigbjorn Lie]

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? 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?


Rgds,
Siggi