Re: [Freeipa-users] understanding RUVs?

2015-04-21 Thread Martin Kosek
On 04/21/2015 01:26 AM, Janelle wrote:
 Hello,
 
 When I was working with OpenLDAP, and AD - and did not deal with RUVs the 
 way
 I am with 389-ds and IPA.
 
 I am trying to understand what is normal for values. If I am looking at this
 (and seem to have no replication problems):
 
 ipa-replica-manage list-ruv
 
 ipa001.example.com:389: 13
 ipa002.example.com:389: 12
 ipa003.example.com:389: 11
 ipa004.example.com:389: 10
 ipa005.example.com:389: 7
 ipa006.example.com:389: 6
 ipa007.example.com:389: 5
 ipa008.example.com:389: 3
 ipa009.example.com:389: 16
 ipa00a.example.com:389: 17
 ipa00b.example.com:389: 15
 ipa00c.example.com:389: 14
 ipa00d.example.com:389: 9
 ipa00e.example.com:389: 8
 ipa00f.example.com:389: 4
 
 I guess I was wondering, should I be seeing all the same values or should they
 all be unique based on being replicated and the order they were added?

They should be unique, that's for sure. There is some info on them in Red Hat
DS docs:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv

I am just not sure if they are replicated or per-server. But given they live in
SUFFIX, I assume they are. The list above looks OK to me, so it should not
cause the replication problems.

But I am rather CCing Thierry to advise here.

 Or is
 it telling me something else? Sorry, I guess I am still trying to wrap my head
 around replication metadata.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


[Freeipa-users] Also attempting to integrate Solaris 10 clients with freeipa

2015-04-21 Thread Roderick Johnstone

Hi

I also need to integrate Solaris 10 clients with freeipa servers.

I've been round many resources, eg freeipa wiki, Fedora and Red Hat 
manuals, various bug trackers and the freeipa-users mailing list.


It looks to me as if this:
https://www.redhat.com/archives/freeipa-users/2013-January/msg00030.html

might be the best guide available, although I'm not sure what changes I 
might need to make because I'm actually on Solaris 10 rather than 11.


Can anyone advise please?

There is a comment in the above post:
Make sure that the automount maps in ipaserver is named auto_* and NOT 
auto.* so they are compatible with Solaris name standards.


My automount maps are already called eg auto.master, auto.home on my ipa 
server and I'm sure I've seen a post somewhere suggesting an 
attributeMap can fix this issue, but I can't find it now, so maybe I am 
mistaken.


Am I on the right track? Is anyone familiar with that fix.

Thanks

Roderick Johnstone

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] Stuck getting sudo working with Ubuntu client

2015-04-21 Thread Lukas Slebodnik
On (20/04/15 17:54), Andrew Sacamano wrote:
Thanks again, Lukas!

I was wondering if the overlaps of names was a problem, so I redid parts of
my IPA setup to rename them - thanks for pointing out the ticket!

Also, your suggestion to use ldap_group_object_class = ipaUserGroup worked
- which saves me the trouble of tracking that down in six months when my
IPA domain grows and the performance issues associated with enumerate begin
to manifest.

Many thanks - you are extraordinarily helpful. My colleagues and I are
quite grateful for all your advice!

You are welcome,
I'm glad I could help.

You can file a ticket to backport patch for ticket #2471 in your distribution.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] HBAC and SUDO rules for legacy clients

2015-04-21 Thread Srdjan Dutina
Yes, it does. Thank you.

On Mon, Apr 20, 2015 at 6:08 PM Srdjan Dutina sdut...@gmail.com wrote:

 Sorry for misunderstanding.

 I understand HBAC rules will not work for Centos 5. I just wanted to make
 sure disabling allow all rule and adding new HBAC rules won't interfere
 with AD users logging on Centos 5.

 On Mon, Apr 20, 2015 at 5:03 PM Alexander Bokovoy aboko...@redhat.com
 wrote:

 On Mon, 20 Apr 2015, Srdjan Dutina wrote:
 Just found in
 http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf the next
 sentence: If you have HBAC's allow_all rule disabled, you will need to
 allow system-auth service on the FreeIPA  master, so that authentication
 of
 the AD users can be performed.
 Is this true for FreeIPA 4.1.0 also and how could I do this?
 Either you are reading it wrong or I don't get where you want to apply
 HBAC rules because this is for IPA masters, not legacy clients per se.
 Yes, you nede to create HBAC service named 'system-auth' and grant
 access to it to AD users on IPA masters, but all it will allow you is to
 authenticate AD users via compat tree.

 If your RHEL5 SSSD clients attempt to run own HBAC rule checks, AD users
 cannot be checked by those rules.



 --
 / Alexander Bokovoy


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] understanding RUVs?

2015-04-21 Thread thierry bordaz

On 04/21/2015 09:11 AM, Martin Kosek wrote:

On 04/21/2015 01:26 AM, Janelle wrote:

Hello,

When I was working with OpenLDAP, and AD - and did not deal with RUVs the way
I am with 389-ds and IPA.

I am trying to understand what is normal for values. If I am looking at this
(and seem to have no replication problems):

ipa-replica-manage list-ruv

ipa001.example.com:389: 13
ipa002.example.com:389: 12
ipa003.example.com:389: 11
ipa004.example.com:389: 10
ipa005.example.com:389: 7
ipa006.example.com:389: 6
ipa007.example.com:389: 5
ipa008.example.com:389: 3
ipa009.example.com:389: 16
ipa00a.example.com:389: 17
ipa00b.example.com:389: 15
ipa00c.example.com:389: 14
ipa00d.example.com:389: 9
ipa00e.example.com:389: 8
ipa00f.example.com:389: 4

I guess I was wondering, should I be seeing all the same values or should they
all be unique based on being replicated and the order they were added?

They should be unique, that's for sure. There is some info on them in Red Hat
DS docs:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv

I am just not sure if they are replicated or per-server. But given they live in
SUFFIX, I assume they are. The list above looks OK to me, so it should not
cause the replication problems.


Hello,

Yes this RUV is normal.

The RUV is a special 389-ds entry that is per server. This entry allows 
replication protocol (run by the replica agreements)

to detect what updates are missing and then send the missing ones.

The command list-ruv displays a subset of the attribute values of that 
entry. It displays url and the replicaId.
A normal RUV in a replication topology contains unique replicaId and a 
url must be listed only once.



thanks
thierry


But I am rather CCing Thierry to advise here.


Or is
it telling me something else? Sorry, I guess I am still trying to wrap my head
around replication metadata.


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] understanding RUVs?

2015-04-21 Thread Ludwig Krispenz


On 04/21/2015 01:26 AM, Janelle wrote:

Hello,

When I was working with OpenLDAP, and AD - and did not deal with 
RUVs the way I am with 389-ds and IPA.


I am trying to understand what is normal for values. If I am looking 
at this (and seem to have no replication problems):


ipa-replica-manage list-ruv

ipa001.example.com:389: 13
ipa002.example.com:389: 12
ipa003.example.com:389: 11
ipa004.example.com:389: 10
ipa005.example.com:389: 7
ipa006.example.com:389: 6
ipa007.example.com:389: 5
ipa008.example.com:389: 3
ipa009.example.com:389: 16
ipa00a.example.com:389: 17
ipa00b.example.com:389: 15
ipa00c.example.com:389: 14
ipa00d.example.com:389: 9
ipa00e.example.com:389: 8
ipa00f.example.com:389: 4

I guess I was wondering, should I be seeing all the same values or 
should they all be unique based on being replicated and the order 
they were added?  Or is it telling me something else? Sorry, I guess I 
am still trying to wrap my head around replication metadata.
the output of list-ruv lists the replicaids and the corresponding 
servers the replica knows about. It should be unique and exactly match 
the servers (with their replicaid) deployed in your topology.
If there are more ruvs, you probably have removed a server and should 
clean the ruv, if you have less than replication from the missing 
replica in the list did not get propagated to this server.


But the output of list-ruv only shows part of the RUV, the real ruv 
looks like this:


 ldapsearch -LLL -o ldif-wrap=no -h localhost  -p 30522 -x -D 
cn=directory manager -w .  -b cn=config 
objectclass=nsds5replica nsds50ruv

dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsds50ruv: {replicageneration} 51dc3bac0064
nsds50ruv: {replica 100 ldap://localhost:30522} 5506ce510064 
55254d910064
nsds50ruv: {replica 200 ldap://localhost:4945} 5506cf8e00c8 
5506cf8e00c8


The most important part is the last field, eg 55254d910064 it is 
the csn of the last change this server has seen for replicaid 100 
(0x64). In a replication session the ruvs of the supplier and consumer 
are compared to detect if the supplier has changes the consumer has not 
yet seen.

So the ruvs have to be managed per server.

Ludwig





Thank you
~J



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] Common Name for the ipa-cacert-manage command

2015-04-21 Thread Rob Crittenden
William Graboyes wrote:
 Hi List,
 
 I am having yet another issue, when I run the following command:
 ipa-cacert-manage renew --external-ca
 
 It does output the CSR, however the CN is not a valid name
 (Certificate Authority).  Is it possible to change the output of this
 command to use an external CA that requires a proper common name to be
 in the CSR?
 
 What I am trying to do is change from the internal self signed certs
 to an external CA signing system.


What isn't valid about the name?

This would make the IPA CA a subordinate of the external CA. Is that
what you want?

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] group membership listing?

2015-04-21 Thread Rob Crittenden
Janelle wrote:
 Hello - and happy day before Earth Day,
 
 Perhaps this is an easy one and related to replication, BUT:
 
 $ id some-user-name
 
 If I run that on every IPA master, should the listing not be identical?
 In other words, the listing of the uid, gid and groups, should show up
 in exactly the same order?
 
 uid=12345(some-user) gid=101(agroup) groups=101(agroup), 102(another),
 103(another2)
 
 What if one replica listed it as:
 
 uid=12345(some-user) gid=101(agroup) groups=101(agroup), 103(another2),
 102(another)
 
 But all the others listed as the first line? Is that indication of a
 problem?

It may be related to the fact that LDAP doesn't guarantee order and no
sorting is done. It is probably not a big deal as long as all the data
is there.

The SSSD guys may have an opinion on it too.

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


[Freeipa-users] Common Name for the ipa-cacert-manage command

2015-04-21 Thread William Graboyes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi List,

I am having yet another issue, when I run the following command:
ipa-cacert-manage renew --external-ca

It does output the CSR, however the CN is not a valid name
(Certificate Authority).  Is it possible to change the output of this
command to use an external CA that requires a proper common name to be
in the CSR?

What I am trying to do is change from the internal self signed certs
to an external CA signing system.

Thanks,
Bill
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVNsERAAoJEJFMz73A1+zr1MQP/3PEctODz82OFkd9ObkqrbPf
qOzXBXrSFvwuikWfLggSNt+rUgSqtoQ6MJb52Bn0GkezP0nREvUiuuBitCxD+7m+
M4Uar3G40sT9VZpSD1pPH7dhXSANdfy2lHSrZwCIGPzgC7rYKL8ZmGqE/TEstq77
25k6R+wQ5HCtt451NCQu7PtN2w4xgY1cl7TIlXuSUCHtp5PjmsvuW1nNIGkvhUXi
Hu/SjbDXqS5f4anUtSJPTC6AE/V3PV7Uvgg4uQen/p5AJ7rPzgQHPujO/yiWKLS2
YELC7ukfZoP6IhjzZqHT2fN5s0SXdeRkXUWbVtmAT1hbnLwS56xwtTkgHSKhzA6u
xAYQl4Iq5MhX9IFLawjCu2VJrkvgUNikL/8C062zZDnCCciihMTikjb04V9ib3hU
q9R4TfGZQDWsOUIg+fw6UCQLL8Kpzq3zHTR95CVx2CW8x2DdRnnzj9/5ZS+OuB3C
RF/5L25VYUiwGMyOpY97jyHJmo/MVMwofciY1jxKZ2ZxGUpxBA3NXIatojMUz7mU
ZjxINqO7ZwY+JwEF8bX1JsloybHppDIYANLdFBb2A14DlczjEyI/Lnbi93PU89JO
7QyucbzDkL3e5eYBGewAPsyXWKa1lPM8CO4WkRJ+/2YMKmJcONNjG3l6za1CsbDl
8eHv7wb0ulvi3dyvsBSj
=7dQX
-END PGP SIGNATURE-

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


[Freeipa-users] Problems with users from AD trusted domain after update to IPA 4.1

2015-04-21 Thread Alexander Frolushkin
Hello.
Not sure it happened after update, but now we are on 4.1 and on some servers we 
have only AD groups if it is primary for user, and have no IPA groups with AD 
external group in members.
Fro example, on the IPA server we have
# id afrolush...@ad.com
uid=236658172(afrolush...@ad.com) gid=236658172(afrolush...@ad.com) 
groups=236658172(afrolush...@ad.com),236658193(sib-dwh-sa-adm...@ad.com),810800020(sib-dwh-sa-admins),236667642(rhidm-sa-adm...@ad.com)mailto:afrolush...@ad.com),236658193(sib-dwh-sa-adm...@ad.com),810800020(sib-dwh-sa-admins),236667642(rhidm-sa-adm...@ad.com)
here group 236658193(sib-dwh-sa-adm...@ad.commailto:sib-dwh-sa-adm...@ad.com) 
have a IPA group 810800020(sib-dwh-sa-admins), and it is not primary for user.
Group, primary for this user - 
236667642(rhidm-sa-adm...@ad.commailto:rhidm-sa-adm...@ad.com) also have IPA 
group, but it is not displayed in id command.
On some other servers (IPA clients) it displays ONLY AD groups:
# id afrolush...@megafon.ru
uid=236658172(afrolush...@ad.com) gid=236658172(afrolush...@ad.com) 
groups=236658172(afrolush...@ad.com),236667642(rhidm-sa-adm...@ad.com),236658193(sib-dwh-sa-adm...@ad.com)mailto:afrolush...@ad.com),236667642(rhidm-sa-adm...@ad.com),236658193(sib-dwh-sa-adm...@ad.com)

This is a big problem for us, because on that servers we cannot use HBAC  
sudo, also we don't think primary AD group is a exception and cannot be used in 
IPA authorization.



WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764




?? ?  ? ? ? ??? ?? ???, 
??? ??? ??. ? ? ? ???  
??, ??? ?? ?   ???  ???-, ? 
?.  ?? ?? ??? ? ?, ?? ?, ?, 
??? ??? ??? ?? ? ??? ??? ? ? ? 
?.  ??  ??? ? , ??, ??? 
 ??? ??  ? ??? ??  ??  ? ? 
? ? ??? ? ? ??.

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. The 
contents may not be disclosed or used by anyone other than the addressee. If 
you are not the intended recipient(s), any use, disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. If you have received this communication in 
error please notify us immediately by responding to this email and then delete 
the e-mail and all attachments and any copies thereof.

(c)20mf50
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Problems with users from AD trusted domain after update to IPA 4.1

2015-04-21 Thread Alexander Bokovoy

On Wed, 22 Apr 2015, Alexander Frolushkin wrote:

Hello.
Not sure it happened after update, but now we are on 4.1 and on some
servers we have only AD groups if it is primary for user, and have no
IPA groups with AD external group in members.  Fro example, on the IPA
server we have
# id afrolush...@ad.com
uid=236658172(afrolush...@ad.com) gid=236658172(afrolush...@ad.com)
groups=236658172(afrolush...@ad.com),236658193(sib-dwh-sa-adm...@ad.com),810800020(sib-dwh-sa-admins),236667642(rhidm-sa-adm...@ad.com)mailto:afrolush...@ad.com),236658193(sib-dwh-sa-adm...@ad.com),810800020(sib-dwh-sa-admins),236667642(rhidm-sa-adm...@ad.com)
here group
236658193(sib-dwh-sa-adm...@ad.commailto:sib-dwh-sa-adm...@ad.com)
have a IPA group 810800020(sib-dwh-sa-admins), and it is not primary
for user.  Group, primary for this user -
236667642(rhidm-sa-adm...@ad.commailto:rhidm-sa-adm...@ad.com) also
have IPA group, but it is not displayed in id command.
On some other servers (IPA clients) it displays ONLY AD groups:
# id afrolush...@megafon.ru
uid=236658172(afrolush...@ad.com) gid=236658172(afrolush...@ad.com)
groups=236658172(afrolush...@ad.com),236667642(rhidm-sa-adm...@ad.com),236658193(sib-dwh-sa-adm...@ad.com)mailto:afrolush...@ad.com),236667642(rhidm-sa-adm...@ad.com),236658193(sib-dwh-sa-adm...@ad.com)

This is a big problem for us, because on that servers we cannot use
HBAC  sudo, also we don't think primary AD group is a exception and
cannot be used in IPA authorization.

If it is a big problem, make sure you are gathering all the logs and
deployment information first to pin point what exactly you are running.

See https://fedorahosted.org/sssd/wiki/Troubleshooting for general SSSD
troubleshooting.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] group membership listing?

2015-04-21 Thread Alexander Bokovoy

On Tue, 21 Apr 2015, Rob Crittenden wrote:

Janelle wrote:

Hello - and happy day before Earth Day,

Perhaps this is an easy one and related to replication, BUT:

$ id some-user-name

If I run that on every IPA master, should the listing not be identical?
In other words, the listing of the uid, gid and groups, should show up
in exactly the same order?

uid=12345(some-user) gid=101(agroup) groups=101(agroup), 102(another),
103(another2)

What if one replica listed it as:

uid=12345(some-user) gid=101(agroup) groups=101(agroup), 103(another2),
102(another)

But all the others listed as the first line? Is that indication of a
problem?


It may be related to the fact that LDAP doesn't guarantee order and no
sorting is done. It is probably not a big deal as long as all the data
is there.

Not even LDAP but POSIX in general does not give you an ordered
guarantee for groups you are member of. There is a primary group always
and the rest of groups are 'supplementary', without any ordering.


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] Slow user logon with IPA

2015-04-21 Thread Mateusz Malek



On 14.04.2015 at 21:30, Rich Megginson wrote:

On 04/14/2015 12:35 PM, thierry bordaz wrote:

On 04/10/2015 08:13 AM, Mateusz Malek wrote:
I'm about to migrate my OpenLDAP-based environment to FreeIPA, 
however
I've hit some weird performance problems. When I'm using IPA, it 
takes
about 5-7 (or even more) seconds to get shell prompt after 
entering user

password (...)
When such long requests happened, you may take several pstack of the 
389-ds process. Ideally you can timestamp the pstack output so that 
it is easier to correlate with DS access logs.
Providing pstacks+access/errors logs would really help to know if 
there is a bottleneck.


See also http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs

You'll need to do debuginfo-install ipa-server slapi-nis



I've tried looking into captured information, but I think that there's 
nothing suspicious. With selinux_provider patched speed is pretty good - 
FreeIPA has more to do during user logon than our existing setup had 
(obtaining Kerberos ticket and processing HBAC rules is definitely more 
complex than single lookup with pam_ldap/nss_ldap) and I'll probably 
blame those longer LDAP search times (that happen from time to time) on 
our datastore performance.


Thank you all, again.

Best regards
Mateusz Małek

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Slow user logon with IPA

2015-04-21 Thread Mateusz Malek



On 15.04.2015 at 15:08, Lukas Slebodnik wrote:

On 04/10/2015 08:13 AM, Mateusz Malek wrote:

I'm about to migrate my OpenLDAP-based environment to FreeIPA, however
I've hit some weird performance problems. When I'm using IPA, it takes
about 5-7 (or even more) seconds to get shell prompt after entering user
password (...)

Packages for fedora 21,22 are built.
You just need to wait utill they are available in updates testing
or you can download packages from koji.

https://admin.fedoraproject.org/updates/sssd-1.12.4-4.fc22
https://admin.fedoraproject.org/updates/sssd-1.12.4-3.fc21

Please test and provide karma.


Well, it took me a long time, but I can confirm that with these packages 
logon times seem fine. Thank you all for quick help!


Now I'm only waiting for updated packages to apper in CentOS/RHEL 
repositories; in my test environment I'm perfectly fine with backporting 
them on my own.


Best regards
Mateusz Małek

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] web interface for FREEIPA runtime error

2015-04-21 Thread Petr Vobornik

On 04/21/2015 06:09 AM, Rob Crittenden wrote:

Chamambo Martin wrote:

Sometimes when I access the web URL where FreeIPA is installed for
general administration ,I encounter this error below.



Runtime error

Web UI got in unrecoverable state during metadata phase



I can only restore access after I have restarted the server ,is there a
service I can restart or something that can prevent it from happening


I'd check /var/log/httpd/error_log for more information when you see
this problem. It may have more details.

rob



The service which you can try to restart is httpd.

Does the UI procude any other error notification. E.g. an error dialog 
with some message.


If you open a browser developer tools/console tab. Do you see there any 
errors?


Does it work if you hard-reload the web page (usually ctrl+F5).
--
Petr Vobornik

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


[Freeipa-users] group membership listing?

2015-04-21 Thread Janelle

Hello - and happy day before Earth Day,

Perhaps this is an easy one and related to replication, BUT:

$ id some-user-name

If I run that on every IPA master, should the listing not be identical?
In other words, the listing of the uid, gid and groups, should show up 
in exactly the same order?


uid=12345(some-user) gid=101(agroup) groups=101(agroup), 102(another), 
103(another2)


What if one replica listed it as:

uid=12345(some-user) gid=101(agroup) groups=101(agroup), 103(another2), 
102(another)


But all the others listed as the first line? Is that indication of a 
problem?


Janelle

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project