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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
