On 04/03/2011 10:58 PM, Simo Sorce wrote: > On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) > "Sigbjorn Lie" <[email protected]> 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/ _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
