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 _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users