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 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.
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
