Re: [Freeipa-users] NIS/local files to IPA migration
On 04/03/2011 10:58 PM, Simo Sorce wrote: On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) Sigbjorn Lie sigbj...@nixtra.com 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] NIS/local files to IPA migration
On 04/04/2011 10:34 AM, Sigbjorn Lie wrote: On Mon, April 4, 2011 04:58, Simo Sorce wrote: On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) Sigbjorn Lie sigbj...@nixtra.com 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? Because it is implied. They are filtered out unless you explicitly want to see them. We thought that by default we do not want to spam your group lists with those groups. 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? Yes, if this is not the case it is a bug. Please log one then. Rgds, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] NIS/local files to IPA migration
On 04/04/2011 09:00 PM, Dmitri Pal wrote: On 04/04/2011 10:34 AM, Sigbjorn Lie wrote: On Mon, April 4, 2011 04:58, Simo Sorce wrote: On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) Sigbjorn Liesigbj...@nixtra.com 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? Because it is implied. They are filtered out unless you explicitly want to see them. We thought that by default we do not want to spam your group lists with those groups. 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? Yes, if this is not the case it is a bug. Please log one then. Done. :) https://bugzilla.redhat.com/show_bug.cgi?id=693483 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] NIS/local files to IPA migration
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 Rgds, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
