I have updated the NIS-TO-IPA scripts with the suggestions for private group workarounds from Rob, and the license updated to GPL v3 as suggested by Dmitri.

Download link is still the same: http://www.nixtra.com/ipa/NIS-TO-IPA-current.php


A -noprivategroup option is very much welcome. Shall I open a request in bugzilla?


Rgds,
Siggi


On 03/28/2011 04:56 PM, Dmitri Pal wrote:
On 03/28/2011 10:50 AM, Rob Crittenden wrote:
Sigbjorn Lie wrote:
Fantastic! Thanks. I will update my scripts.

Is there any downside to doing this?
One thing I should warn you of though that we've run into from time to
time. Some of our LDAP operations are done as post-operations, that is
they execute after the data has been returned to the client. Managed
Entries (private groups) is one of these. I can definitely see the
case where you try to detach a managed group that hasn't quite
finished being created yet. I'd probably put a 1 or 2 second sleep
after the user creation to be sure, even if it does slow things
considerably.

We're working with the 389-ds devs on this. There is the tradeoff of
speed vs correctness (users don't like watching a blinking prompt).
Some of these post-ops could take a while.
I think we should seriously consider a -noprivategroup option


rob



Rgds,
Siggi




On Mon, March 28, 2011 16:02, Rob Crittenden wrote:
Sigbjorn Lie wrote:

Thanks.


I also noticed that a group with the same GID number as the users
UID number is automatically
created when creating the user account, this is a problem for
existing environments who's
already used the same ID number for a group.

I see that even after doing a user-mod, changing the GID of the
account, the private
(invisible)
group still exists.

I'm missing an option to choose if I want to create or not create a
private group for the user.

There currently isn't an option for that. You can delete a managed
group
this way:

$ ipa user-add --first=Tim --last=Test ttest


You now have a group ttest too, lets delete it.


$ ipa group-detach ttest
$ ipa group-del ttest


The first command detaches it from the user (this is not reversible)
and
the second removes it altogether.

rob


Rgds,
Siggi







On Sat, March 26, 2011 18:21, Dmitri Pal wrote:

On 03/25/2011 03:13 PM, Sigbjorn Lie wrote:


Hi,



Using --gidnumber when adding a new user with "ipa user-add" does
not
seem to have any effect. A gid number with the same value as what
I specify in with the
--uid
parameter is chosen.

I presume this is not the way user-add is intended to work?


We will take a look.
https://fedorahosted.org/freeipa/ticket/1127



Looks like a bug so I filed a ticket.





# ipa user-add mysql14 --first=MySQL --last=Server
--homedir=/var/lib/mysql --shell=/bin/false --uid=110
--gidnumber=3004
--------------------
Added user "mysql14"
--------------------
User login: mysql14
First name: MySQL
Last name: Server
Full name: MySQL Server
Display name: MySQL Server
Initials: MS
Home directory: /var/lib/mysql
GECOS field: mysql14
Login shell: /bin/false
Kerberos principal: mysq...@ix.nixtra.com
UID: 110
GID: 110





Regards,
Siggi



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




_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users




_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to