On Mon, April 4, 2011 04:58, 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. >
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 _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
