Re: [Freeipa-users] Cant locate CSN after yum update

[Christophe TREFOIS]

Dear Ludwig,

Thank you for the explanations. Now I understand.

Strangely then, the problem csn was on the replica that we had to reinitialize. 
How could such a csn disappear?

Thanks again for the help. Much appreciated.
Sent from my iPhone

> On 19 May 2017, at 08:47, Ludwig Krispenz  wrote:
> 
> 
>> On 05/18/2017 05:35 PM, Christophe TREFOIS wrote:
>> Dear Ludwig,
>> 
>> Thanks for your help in IRC to guide me in running the right commands.
>> 
>> Here is the output, toto1 and toto2 are CA master, and toto3 and toto4 are 
>> non CA master. The problematic replica was toto3, and after re-init, we 
>> haven’t seen any errors in the log anymore.
>> 
>> https://paste.fedoraproject.org/paste/j8c30CZPyh8rPymjbKSvZF5M1UNdIGYhyRLivL9gydE=
>> 
>> I also ran ipa-replica-manage on all replicas to all replicas, so total of 
>> 16 command, and found all of them reported “incremental update succeeded”.
>> 
>> As discussed, I’m not sure what I’m looking at with the RUV stuff above, and 
>> any explanation for a newcomer to ldap / ds / freeipa would be greatly 
>> appreciated.
> ok, here is a quick explanation of the csn/ruv stuff. 
> 
> each change applied on a server gets a CSN (change sequence number), it 
> basically consists of a timestamp and an identifier of the replica where it 
> was originally applied, so in 59095fe1000b0012 there is a time stamp: 
> 59095fe1 and a replicaid: 0012 == 18, the rest of the csn isused to serialize 
> csns within the one second resolution of a timestamp.
> a change is applied to the main database and written to the changelog, with 
> the csn as key.
> 
> now each replica keeps track of the latest csn it has seen for each 
> replicaID, so you get a vector of max csns, this is called RUV (replica 
> update vector).
> In a replication session, the supplier compares its own ruv with the ruv of 
> the consumer and so decides if it has changes which the consumer has not yet 
> seen.
> based on the consumer ruv it determines the start csn to send updates.
> 
> 
>> 
>> Thanks a lot for your help!
>> 
>> Kind regards,
>> Christophe aka Trefex
>> 
>>> On 18 May 2017, at 17:04, Christophe TREFOIS  
>>> wrote:
>>> 
>>> Hi Ludwig,
>>> 
>>> Since we were scared, we did a full re-init of that specific replica from 
>>> the CA master, and it looks like the issue is not appearing anymore.
>>> 
>>> Is this sufficient, or should we still investigate ?
>>> 
>>> Thanks for your help!
>>> Christophe
>>> -- 
>>> 
>>> Dr Christophe Trefois, Dipl.-Ing.  
>>> Technical Specialist / Post-Doc
>>> 
>>> UNIVERSITÉ DU LUXEMBOURG
>>> 
>>> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
>>> Campus Belval | House of Biomedicine  
>>> 6, avenue du Swing 
>>> L-4367 Belvaux  
>>> T: +352 46 66 44 6124 
>>> F: +352 46 66 44 6949  
>>> http://www.uni.lu/lcsb
>>> 
>>> 
>>> 
>>> 
>>> 
>>> This message is confidential and may contain privileged information. 
>>> It is intended for the named recipient only. 
>>> If you receive it in error please notify me and permanently delete the 
>>> original message and any copies. 
>>> 
>>>   
>>> 
 On 18 May 2017, at 16:11, Ludwig Krispenz  wrote:
 
 hi,
 
 there was a change that in the case of a missing csn ds would not silently 
 use a "close" one and continue, but log an error, backoff and retry - 
 after updates on other masters the staring csn coudl change and 
 replication continue.
 
 Now, in your case the csn reported missing: 59095fe1000b0012
 has a time stamp from May,3rd, so it could very well be correct that this 
 csn is no longer found in the changelog.
 
 To continue analysis, could you provide the replicaids of all your current 
 replicas, and which is the replicaid of the sever logging the change and 
 the ruvs of the replicas from all servers.
 ldapsearch   -D "cn=directory manager"  -b cn=config 
 "objectclass=nsds5replica" nsds50ruv
 
 Regards,
 Ludwig
 
> On 05/18/2017 03:09 PM, Christophe TREFOIS wrote:
> Hi all,
> 
> Did a yum update on one of my replicas, non CA master, and upgrade was 
> successful (ipupgrade.log) said so. 
> 
> 
> Hwoever, now every few seconds I get the following message. 
> https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=
> 
> Does anybody know how to proceed and if this is important?
> ipa-replica-manage says, backing off, retrying later, so not sure if 
> replication happens successfully or not and what to do ??
> 
> Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in diamond 
> replication.
> 
> Remaining replicas were upgraded today as well, and don’t seem to 
> complain. Only 1 of them complains.
> 
> 389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
> 389-ds-base-1.3.5.10-20.el7_3.x86_64
> 
> 
> [root@lums3 ~]# 

Re: [Freeipa-users] Cant locate CSN after yum update

[Ludwig Krispenz]

On 05/18/2017 05:35 PM, Christophe TREFOIS wrote:

Dear Ludwig,

Thanks for your help in IRC to guide me in running the right commands.

Here is the output, toto1 and toto2 are CA master, and toto3 and toto4 
are non CA master. The problematic replica was toto3, and after 
re-init, we haven’t seen any errors in the log anymore.


https://paste.fedoraproject.org/paste/j8c30CZPyh8rPymjbKSvZF5M1UNdIGYhyRLivL9gydE=

I also ran ipa-replica-manage on all replicas to all replicas, so 
total of 16 command, and found all of them reported “incremental 
update succeeded”.


As discussed, I’m not sure what I’m looking at with the RUV stuff 
above, and any explanation for a newcomer to ldap / ds / freeipa would 
be greatly appreciated.

ok, here is a quick explanation of the csn/ruv stuff.

each change applied on a server gets a CSN (change sequence number), it 
basically consists of a timestamp and an identifier of the replica where 
it was originally applied, so in 59095fe1000b0012 there is a time 
stamp: 59095fe1 and a replicaid: 0012 == 18, the rest of the csn isused 
to serialize csns within the one second resolution of a timestamp.
a change is applied to the main database and written to the changelog, 
with the csn as key.


now each replica keeps track of the latest csn it has seen for each 
replicaID, so you get a vector of max csns, this is called RUV (replica 
update vector).
In a replication session, the supplier compares its own ruv with the ruv 
of the consumer and so decides if it has changes which the consumer has 
not yet seen.

based on the consumer ruv it determines the start csn to send updates.




Thanks a lot for your help!

Kind regards,
Christophe aka Trefex

On 18 May 2017, at 17:04, Christophe TREFOIS 
> wrote:


Hi Ludwig,

Since we were scared, we did a full re-init of that specific replica 
from the CA master, and it looks like the issue is not appearing anymore.


Is this sufficient, or should we still investigate ?

Thanks for your help!
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T:+352 46 66 44 6124
F:+352 46 66 44 6949
http://www.uni.lu/lcsb

Facebook Twitter 
Google Plus 
Linkedin 
skype




This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete 
the original message and any copies.




On 18 May 2017, at 16:11, Ludwig Krispenz > wrote:


hi,

there was a change that in the case of a missing csn ds would not 
silently use a "close" one and continue, but log an error, backoff 
and retry - after updates on other masters the staring csn coudl 
change and replication continue.


Now, in your case the csn reported missing: 59095fe1000b0012
has a time stamp from May,3rd, so it could very well be correct that 
this csn is no longer found in the changelog.


To continue analysis, could you provide the replicaids of all your 
current replicas, and which is the replicaid of the sever logging 
the change and the ruvs of the replicas from all servers.
ldapsearch   -D "cn=directory manager"  -b cn=config 
"objectclass=nsds5replica" nsds50ruv


Regards,
Ludwig

On 05/18/2017 03:09 PM, Christophe TREFOIS wrote:

Hi all,

Did a yum update on one of my replicas, non CA master, and upgrade 
was successful (ipupgrade.log) said so.



Hwoever, now every few seconds I get the following message. 
https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=


Does anybody know how to proceed and if this is important?
ipa-replica-manage says, backing off, retrying later, so not sure 
if replication happens successfully or not and what to do ??


Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in 
diamond replication.


Remaining replicas were upgraded today as well, and don’t seem to 
complain. Only 1 of them complains.


389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
389-ds-base-1.3.5.10-20.el7_3.x86_64


[root@lums3 ~]# rpm -qa | grep ipa
libipa_hbac-1.14.0-43.el7_3.14.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.4.0-14.el7.centos.7.noarch
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
python2-ipalib-4.4.0-14.el7.centos.7.noarch
sssd-ipa-1.14.0-43.el7_3.14.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
ipa-server-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-common-4.4.0-14.el7.centos.7.noarch
python-libipa_hbac-1.14.0-43.el7_3.14.x86_64

Re: [Freeipa-users] Cant locate CSN after yum update

[Christophe TREFOIS]

Dear Ludwig,

Thanks for your help in IRC to guide me in running the right commands.

Here is the output, toto1 and toto2 are CA master, and toto3 and toto4 are non 
CA master. The problematic replica was toto3, and after re-init, we haven’t 
seen any errors in the log anymore.

https://paste.fedoraproject.org/paste/j8c30CZPyh8rPymjbKSvZF5M1UNdIGYhyRLivL9gydE=

I also ran ipa-replica-manage on all replicas to all replicas, so total of 16 
command, and found all of them reported “incremental update succeeded”.

As discussed, I’m not sure what I’m looking at with the RUV stuff above, and 
any explanation for a newcomer to ldap / ds / freeipa would be greatly 
appreciated.

Thanks a lot for your help!

Kind regards,
Christophe aka Trefex

On 18 May 2017, at 17:04, Christophe TREFOIS 
> wrote:

Hi Ludwig,

Since we were scared, we did a full re-init of that specific replica from the 
CA master, and it looks like the issue is not appearing anymore.

Is this sufficient, or should we still investigate ?

Thanks for your help!
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype] 




This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.




On 18 May 2017, at 16:11, Ludwig Krispenz 
> wrote:

hi,

there was a change that in the case of a missing csn ds would not silently use 
a "close" one and continue, but log an error, backoff and retry - after updates 
on other masters the staring csn coudl change and replication continue.

Now, in your case the csn reported missing: 59095fe1000b0012
has a time stamp from May,3rd, so it could very well be correct that this csn 
is no longer found in the changelog.

To continue analysis, could you provide the replicaids of all your current 
replicas, and which is the replicaid of the sever logging the change and the 
ruvs of the replicas from all servers.
ldapsearch   -D "cn=directory manager"  -b cn=config 
"objectclass=nsds5replica" nsds50ruv

Regards,
Ludwig

On 05/18/2017 03:09 PM, Christophe TREFOIS wrote:
Hi all,

Did a yum update on one of my replicas, non CA master, and upgrade was 
successful (ipupgrade.log) said so.


Hwoever, now every few seconds I get the following message. 
https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=

Does anybody know how to proceed and if this is important?
ipa-replica-manage says, backing off, retrying later, so not sure if 
replication happens successfully or not and what to do ??

Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in diamond 
replication.

Remaining replicas were upgraded today as well, and don’t seem to complain. 
Only 1 of them complains.

389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
389-ds-base-1.3.5.10-20.el7_3.x86_64


[root@lums3 ~]# rpm -qa | grep ipa
libipa_hbac-1.14.0-43.el7_3.14.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.4.0-14.el7.centos.7.noarch
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
python2-ipalib-4.4.0-14.el7.centos.7.noarch
sssd-ipa-1.14.0-43.el7_3.14.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
ipa-server-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-common-4.4.0-14.el7.centos.7.noarch
python-libipa_hbac-1.14.0-43.el7_3.14.x86_64
ipa-server-4.4.0-14.el7.centos.7.x86_64

Thanks a lot for any pointers,
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype]



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.








--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 

Re: [Freeipa-users] Cant locate CSN after yum update

[Christophe TREFOIS]

Hi Ludwig,

Since we were scared, we did a full re-init of that specific replica from the 
CA master, and it looks like the issue is not appearing anymore.

Is this sufficient, or should we still investigate ?

Thanks for your help!
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype] 



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.




On 18 May 2017, at 16:11, Ludwig Krispenz 
> wrote:

hi,

there was a change that in the case of a missing csn ds would not silently use 
a "close" one and continue, but log an error, backoff and retry - after updates 
on other masters the staring csn coudl change and replication continue.

Now, in your case the csn reported missing: 59095fe1000b0012
has a time stamp from May,3rd, so it could very well be correct that this csn 
is no longer found in the changelog.

To continue analysis, could you provide the replicaids of all your current 
replicas, and which is the replicaid of the sever logging the change and the 
ruvs of the replicas from all servers.
ldapsearch   -D "cn=directory manager"  -b cn=config 
"objectclass=nsds5replica" nsds50ruv

Regards,
Ludwig

On 05/18/2017 03:09 PM, Christophe TREFOIS wrote:
Hi all,

Did a yum update on one of my replicas, non CA master, and upgrade was 
successful (ipupgrade.log) said so.


Hwoever, now every few seconds I get the following message. 
https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=

Does anybody know how to proceed and if this is important?
ipa-replica-manage says, backing off, retrying later, so not sure if 
replication happens successfully or not and what to do ??

Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in diamond 
replication.

Remaining replicas were upgraded today as well, and don’t seem to complain. 
Only 1 of them complains.

389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
389-ds-base-1.3.5.10-20.el7_3.x86_64


[root@lums3 ~]# rpm -qa | grep ipa
libipa_hbac-1.14.0-43.el7_3.14.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.4.0-14.el7.centos.7.noarch
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
python2-ipalib-4.4.0-14.el7.centos.7.noarch
sssd-ipa-1.14.0-43.el7_3.14.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
ipa-server-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-common-4.4.0-14.el7.centos.7.noarch
python-libipa_hbac-1.14.0-43.el7_3.14.x86_64
ipa-server-4.4.0-14.el7.centos.7.x86_64

Thanks a lot for any pointers,
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype]



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.








--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

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

-- 
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] Cant locate CSN after yum update

[Ludwig Krispenz]

hi,

there was a change that in the case of a missing csn ds would not 
silently use a "close" one and continue, but log an error, backoff and 
retry - after updates on other masters the staring csn coudl change and 
replication continue.


Now, in your case the csn reported missing: 59095fe1000b0012
has a time stamp from May,3rd, so it could very well be correct that 
this csn is no longer found in the changelog.


To continue analysis, could you provide the replicaids of all your 
current replicas, and which is the replicaid of the sever logging the 
change and the ruvs of the replicas from all servers.
ldapsearch   -D "cn=directory manager"  -b cn=config 
"objectclass=nsds5replica" nsds50ruv


Regards,
Ludwig

On 05/18/2017 03:09 PM, Christophe TREFOIS wrote:

Hi all,

Did a yum update on one of my replicas, non CA master, and upgrade was 
successful (ipupgrade.log) said so.



Hwoever, now every few seconds I get the following message. 
https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=


Does anybody know how to proceed and if this is important?
ipa-replica-manage says, backing off, retrying later, so not sure if 
replication happens successfully or not and what to do ??


Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in 
diamond replication.


Remaining replicas were upgraded today as well, and don't seem to 
complain. Only 1 of them complains.


389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
389-ds-base-1.3.5.10-20.el7_3.x86_64


[root@lums3 ~]# rpm -qa | grep ipa
libipa_hbac-1.14.0-43.el7_3.14.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.4.0-14.el7.centos.7.noarch
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
python2-ipalib-4.4.0-14.el7.centos.7.noarch
sssd-ipa-1.14.0-43.el7_3.14.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
ipa-server-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-common-4.4.0-14.el7.centos.7.noarch
python-libipa_hbac-1.14.0-43.el7_3.14.x86_64
ipa-server-4.4.0-14.el7.centos.7.x86_64

Thanks a lot for any pointers,
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T:+352 46 66 44 6124
F:+352 46 66 44 6949
http://www.uni.lu/lcsb

Facebook Twitter 
Google Plus 
Linkedin 
skype



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the 
original message and any copies.








--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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] Cant locate CSN after yum update

[Christophe TREFOIS]

Hi all,

Did a yum update on one of my replicas, non CA master, and upgrade was 
successful (ipupgrade.log) said so.


Hwoever, now every few seconds I get the following message. 
https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=

Does anybody know how to proceed and if this is important?
ipa-replica-manage says, backing off, retrying later, so not sure if 
replication happens successfully or not and what to do ??

Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in diamond 
replication.

Remaining replicas were upgraded today as well, and don’t seem to complain. 
Only 1 of them complains.

389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
389-ds-base-1.3.5.10-20.el7_3.x86_64


[root@lums3 ~]# rpm -qa | grep ipa
libipa_hbac-1.14.0-43.el7_3.14.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.4.0-14.el7.centos.7.noarch
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
python2-ipalib-4.4.0-14.el7.centos.7.noarch
sssd-ipa-1.14.0-43.el7_3.14.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
ipa-server-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-common-4.4.0-14.el7.centos.7.noarch
python-libipa_hbac-1.14.0-43.el7_3.14.x86_64
ipa-server-4.4.0-14.el7.centos.7.x86_64

Thanks a lot for any pointers,
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype] 



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.




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