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

[Sigbjorn Lie]

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?



Rgds,
Siggi