Re: [Freeipa-users] ipa-client on aws (amazon linux)

2015-09-02 Thread Lukas Slebodnik 
On (02/09/15 11:22), Prashant Bapat wrote:
>Hi,
>
>Running a freeipa-client on Amazon Linux is a huge challenge. This is
>because the client depends on SSSD which in turn uses Samba libraries which
>Amazon Linux does not support.
sssd >= 1.11 can be compiled without samba libraries.
But result is missing ad and ipa provider.
So you would need to manually configure sssd with ldap provider against
FreeIPA.

>I tried this sometime back and gave up.
>Instead we went with pam-nss-ldap route which works great with compat ldap
>schema. Run the "ipa-advise" command for more details.
>
>I'm running the pam-nss-ldap client on 2000+ servers in AWS with Amazon
>Linux.
>
ipa-client install has option "--no-sssd"
-S, --no-sssd   Do not configure the client to use SSSD for
authentication

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] FreeIPA Sudo Error: Resource temporarily unavailable

2015-09-02 Thread Lukas Slebodnik 
On (01/09/15 18:18), Yogesh Sharma wrote:
>Hi,
>
>This is fixed. On digging more found that my resolv.conf was updated and it
>was not able to find the domain. Fixing the resolv.conf with right
>nameserver, fixed the issue.
>
I know it was solved but you would not miss important debug
message with lover debug level.

>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
>>> Issuing request for [0x40bc10:3:vg4...@klikpay.int]
>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_account_msg]
>>> (0x0400): Creating request for [klikpay.int][3][1][name=vg4381]
>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
>>> (0x0400): Entering request [0x40bc10:3:vg4...@klikpay.int]
>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_check_user_dp_callback]
>>> (0x0020): Unable to get information from Data Provider
>>> Error: 1, 11, Offline
sssd was in offine mode because it was not able to connect to IPA server.

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] ipa-client on aws (amazon linux)

2015-09-02 Thread Prashant Bapat 
Lukas,

ipa-client-install is part of the freeipa-client rpm. On Amazon Linux this
rpm cannot be installed. This is the basic issue.

Thanks.

On 2 September 2015 at 12:43, Lukas Slebodnik  wrote:

> On (02/09/15 11:22), Prashant Bapat wrote:
> >Hi,
> >
> >Running a freeipa-client on Amazon Linux is a huge challenge. This is
> >because the client depends on SSSD which in turn uses Samba libraries
> which
> >Amazon Linux does not support.
> sssd >= 1.11 can be compiled without samba libraries.
> But result is missing ad and ipa provider.
> So you would need to manually configure sssd with ldap provider against
> FreeIPA.
>
> >I tried this sometime back and gave up.
> >Instead we went with pam-nss-ldap route which works great with compat ldap
> >schema. Run the "ipa-advise" command for more details.
> >
> >I'm running the pam-nss-ldap client on 2000+ servers in AWS with Amazon
> >Linux.
> >
> ipa-client install has option "--no-sssd"
> -S, --no-sssd   Do not configure the client to use SSSD for
> authentication
>
> 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] ipa-client on aws (amazon linux)

2015-09-02 Thread Lukas Slebodnik 
On (02/09/15 12:58), Prashant Bapat wrote:
>Lukas,
>
>ipa-client-install is part of the freeipa-client rpm. On Amazon Linux this
>rpm cannot be installed. This is the basic issue.
>
Indeed.
there is a strict requires for sssd

Requires: sssd >= 1.12.3  #from fedora spec file

Using ipa-advise might be more comfortable way rather then
patch spec file or create modified rpms.

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] ipa-client on aws (amazon linux)

2015-09-02 Thread Prashant Bapat 
Hi,

Running a freeipa-client on Amazon Linux is a huge challenge. This is
because the client depends on SSSD which in turn uses Samba libraries which
Amazon Linux does not support. I tried this sometime back and gave up.
Instead we went with pam-nss-ldap route which works great with compat ldap
schema. Run the "ipa-advise" command for more details.

I'm running the pam-nss-ldap client on 2000+ servers in AWS with Amazon
Linux.

HTH.
--Prashant



On 2 September 2015 at 02:25, Gustavo Mateus 
wrote:

> Hi,
>
> Does anyone have an updated list of packages or installation steps to get
> the ipa-client properly installed on an Amazon Linux (2015.03.1 to be more
> precise).
>
> I plan to use Red Hat as my ipa-server but the clients need to be Amazon
> Linux.
>
> Thanks,
>
> Gustavo
>
> --
> 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] User AD can not Login Client Linux

2015-09-02 Thread Lukas Slebodnik 
On (28/08/15 08:44), Lukas Slebodnik wrote:
>On (23/08/15 17:53), alireza baghery wrote:
>>Hi i install Centos 7.1 (IDM Server)
>>and integrate with Windows SERVER 2008 R2 Trust
>>USER AD can not Login on client (OLE 6.6) but User create idm can login
>>
>>name IDM SERVER= ipasrv.l.infotechpsp.net
>>domain Windows = infotechpsp.net
>>
>>i execute [ kinit abagh...@infotechpsp.net] on IDM Server
>>and klist and show keytab abagheri
>>but execute kvno abag...@infotechpsp.net
>>get ERROR kvno Server not found in kerberos database
>>please help me and thank you
>>
>>KLIST
>>
>>
>>Valid starting ExpiresService principal
>>08/23/15 17:09:53  08/24/15 03:11:34  krbtgt/infotechpsp@infotechpsp.net
>>renew until 08/24/15 17:09:53
>>
>>=
>>
>>Tail LOG /var/log/sssd/ssd_l.infotechpsp.net debug_level = 6
>>=
>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>>[(objectclass=*)][].
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>>set
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sdap_kinit_send]
>>(0x0400): Attempting kinit (default, host/ussd7.l.infotechpsp.net,
>>L.INFOTECHPSP.NET, 86400)
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [resolve_srv_send]
>>(0x0200): The status of SRV lookup is resolved
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[be_resolve_server_process] (0x0200): Found address for server
>>ipasrv.l.infotechpsp.net: [10.30.160.19] TTL 1200
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[write_pipe_handler] (0x0400): All data has been sent!
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[read_pipe_handler] (0x0400): EOF received, client finished
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/
>>ccache_L.INFOTECHPSP.NET], expired on [1440420165]
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_cli_auth_step] (0x0100): expire timeout is 900
>>(Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sasl_bind_send]
>>(0x0100): Executing sasl bind mech: GSSAPI, user: host/
>>ussd7.l.infotechpsp.net
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[child_sig_handler] (0x0100): child [13370] finished successfully.
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[fo_set_port_status] (0x0100): Marking port 389 of server '
>>ipasrv.l.infotechpsp.net' as 'working'
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[set_server_common_status] (0x0100): Marking server '
>>ipasrv.l.infotechpsp.net' as 'working'
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>>[objectclass=ipaNTTrustedDomain][cn=trusts,dc=l,dc=infotechpsp,dc=net].
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [be_run_online_cb]
>>(0x0080): Going online. Running callbacks.
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>>set
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>>[objectclass=ipaIDRange][cn=ranges,cn=etc,dc=l,dc=infotechpsp,dc=net].
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>>set
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>>[objectclass=ipaNTDomainAttrs][cn=ad,cn=etc,dc=l,dc=infotechpsp,dc=net].
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
>>set
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[get_subdomains_callback] (0x0400): Backend returned: (0, 0, )
>>[Success]
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[be_get_account_info] (0x0100): Got request for [4097][1][name=abagheri]
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[ipa_s2n_exop_send] (0x0400): Executing extended operation
>>(Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]]
>>[ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Operations
>>error(1), (null)
>There seems to be a problem on server side.
>It's is a very likely bug in sssd on FreeIPA server.
>
>Some AD related fixes are included in latest update in el7.1
>(1.12.2-58.el7_1.14)
>
>If it does not help please try to upgrade to the

Re: [Freeipa-users] ipa-client on aws (amazon linux)

2015-09-02 Thread Gustavo Mateus 
I think I'll go with ipa-advise for now since my main goal is to move away
from openldap and allow AD users to ssh into my linux boxes.
And eventually, when AWS decides to finally include ipa-client in amazon
linux, I move to that approach.




On Wed, Sep 2, 2015 at 12:36 AM, Lukas Slebodnik 
wrote:

> On (02/09/15 12:58), Prashant Bapat wrote:
> >Lukas,
> >
> >ipa-client-install is part of the freeipa-client rpm. On Amazon Linux this
> >rpm cannot be installed. This is the basic issue.
> >
> Indeed.
> there is a strict requires for sssd
>
> Requires: sssd >= 1.12.3  #from fedora spec file
>
> Using ipa-advise might be more comfortable way rather then
> patch spec file or create modified rpms.
>
> 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
>
-- 
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] ipa automountlocation-tofiles

2015-09-02 Thread Rob Crittenden 

Marc Wiatrowski wrote:

Hello,

In trying to script some changes for automount locations.  I've noticed
'ipa automountlocation-tofiles' doesn't seem to return everything.  As
an example:

$ ipa automountlocation-tofiles office | grep abg

returns nothing for abg.  Yes, I have run this without the grep and
looked, piped everything to a file and looked. Still nothing for abg and
no errors I can see.  There are several maps out of about 150 that don't
show up with automountlocation-tofiles.

However through the web gui they're there and they're there by
specifically looking for them. Also works with the clients and autofs.

$ ipa automountkey-show office auto.workers --all --key abg
   dn:
description=abg,automountmapname=auto.workers,cn=office,cn=automount,dc=iglass,dc=net
   Key: abg
   Mount information: server1:/path1/workers/&
   description: abg
   objectclass: automount, top

Its been easy enough to manually change the few the that don't get
caught by the dump, but been wondering... Any one have an idea?

ipa-admintools-3.0.0-47.el6.centos.x86_64
ipa-server-3.0.0-47.el6.centos.x86_64


Does auto.workers show at all?

Are the ones that don't show consistent? Are they related in any way?

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] sudo (sssd) hangs due to ipa install/uninstall scripts

2015-09-02 Thread Prasun Gera 
FYI, I think the culprit (at least one of) is ipa-client-automount
--uninstall. This removes sss entirely from nssswitch, not just from the
automount section.

On Tue, Sep 1, 2015 at 11:56 AM, Prasun Gera  wrote:

> So I've again spent a couple of hours debugging a very similar issue.
> Client install would seemingly pass, but with "Unable to find 'admin' user
> with 'getent passwd admin@domain'!" at the end. And nobody would be able
> to authenticate. The reason was that /etc/nsswitch.conf wasn't updated. sss
> wasn't added to it.  Wading through his thread
> https://www.redhat.com/archives/freeipa-users/2015-March/msg00538.html
> provided some hints. I have no idea why it did that, but as I have
> experienced before, modifying critical system files this way from python
> scripts which don't have proper transnactional support is very dangerous. I
> suspect that this has something to do with a prior failed install or
> uninstall attempt which left it in an inconsistent state. Is it possible to
> move from this backup-modify-restore approach to critical files to
> something more robust which has transnational guarantees ?
>
> On Sat, Jun 27, 2015 at 6:26 AM, Dmitri Pal  wrote:
>
>> On 06/24/2015 04:31 AM, Jakub Hrozek wrote:
>>
>>> On Wed, Jun 24, 2015 at 01:24:37AM -0700, Prasun Gera wrote:
>>>
 Thanks. It's good to know that it is fixed upstream. For discussion
 though,
 are any enhancements planned for dealing with installation/removal of
 ipa ?

>>> Not sure, but please file bugs as you see them.
>>>
>>> Yes, please be more specific . The bugs that were mentioned by Jakub are
>> making its way into downstream. If there are any other issues you are
>> concerned about please let us know.
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Director of Engineering for IdM portfolio
>> Red Hat, Inc.
>>
>>
>> --
>> 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

[Freeipa-users] Ugrading IPA to dogtag? CA?

2015-09-02 Thread Steven Jones 
It seems I built IPA with self signed certs so I need to upgrade?  is this 
possible? and if so how on existing servers?  



regards

Steven 

-- 
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] ipa automountlocation-tofiles

2015-09-02 Thread Marc Wiatrowski 
On Wed, Sep 2, 2015 at 3:46 PM, Rob Crittenden  wrote:

> Marc Wiatrowski wrote:
>
>> Hello,
>>
>> In trying to script some changes for automount locations.  I've noticed
>> 'ipa automountlocation-tofiles' doesn't seem to return everything.  As
>> an example:
>>
>> $ ipa automountlocation-tofiles office | grep abg
>>
>> returns nothing for abg.  Yes, I have run this without the grep and
>> looked, piped everything to a file and looked. Still nothing for abg and
>> no errors I can see.  There are several maps out of about 150 that don't
>> show up with automountlocation-tofiles.
>>
>> However through the web gui they're there and they're there by
>> specifically looking for them. Also works with the clients and autofs.
>>
>> $ ipa automountkey-show office auto.workers --all --key abg
>>dn:
>>
>> description=abg,automountmapname=auto.workers,cn=office,cn=automount,dc=iglass,dc=net
>>Key: abg
>>Mount information: server1:/path1/workers/&
>>description: abg
>>objectclass: automount, top
>>
>> Its been easy enough to manually change the few the that don't get
>> caught by the dump, but been wondering... Any one have an idea?
>>
>> ipa-admintools-3.0.0-47.el6.centos.x86_64
>> ipa-server-3.0.0-47.el6.centos.x86_64
>>
>
> Does auto.workers show at all?
>
> Are the ones that don't show consistent? Are they related in any way?
>
> rob


Thanks, rob

Yes auto.workers shows and lists out about 150 entries.  I was trying to
keep it cleaner and not inadvertently reveal something confidential by not
showing the whole dump.

Not to say there isn't, but I don't see anything making them related, key
or map.

I'll throw in there are 3 ipa servers.  Each show the same results.
-- 
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] ipa automountlocation-tofiles

2015-09-02 Thread Marc Wiatrowski 
Hello,

In trying to script some changes for automount locations.  I've noticed
'ipa automountlocation-tofiles' doesn't seem to return everything.  As an
example:

$ ipa automountlocation-tofiles office | grep abg

returns nothing for abg.  Yes, I have run this without the grep and looked,
piped everything to a file and looked. Still nothing for abg and no errors
I can see.  There are several maps out of about 150 that don't show up
with automountlocation-tofiles.

However through the web gui they're there and they're there by specifically
looking for them. Also works with the clients and autofs.

$ ipa automountkey-show office auto.workers --all --key abg
  dn:
description=abg,automountmapname=auto.workers,cn=office,cn=automount,dc=iglass,dc=net
  Key: abg
  Mount information: server1:/path1/workers/&
  description: abg
  objectclass: automount, top

Its been easy enough to manually change the few the that don't get caught
by the dump, but been wondering... Any one have an idea?

ipa-admintools-3.0.0-47.el6.centos.x86_64
ipa-server-3.0.0-47.el6.centos.x86_64

Thanks,
Marc
-- 
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] stubborn old replicas

2015-09-02 Thread Ludwig Krispenz 

Hi Janelle,
On 09/01/2015 06:17 PM, Janelle wrote:

On 8/28/15 8:17 AM, Vaclav Adamec wrote:
You could try this (RH recommended way). It works for me better than 
cleanallruv.pl  as this sometimes leads to 
ldap freeze)


unable to decode: {replica 30} 5548fa20001e 
5548fa20001e unable to decode: {replica 26} 
5548a9a8001a 5548a9a8001a


for all of them, on-by-one:

ldapmodify -x -D "cn=directory manager" -w XXX dn: 
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config 
changetype: modify replace: nsds5task nsds5task: CLEANRUV30  + 



On Fri, Aug 28, 2015 at 4:55 PM, Guillermo Fuentes 
 wrote:


Hi Janelle,

Using the cleanallruv.pl  tool was the
only way I was able to get ride of the "unable to decode:
{replica x}" entries.

This is how I used it, cleaning a replica ID at a time:
# For replica id: 40
cleanallruv.pl  -v -D "cn=directory
manager" -w - -b 'dc=example,dc=com' -r 40

Note that the "-w -" will make the tool prompt you for the
directory manager password.

Hope this helps,
Guillermo


On Thu, Aug 27, 2015 at 10:27 AM, Janelle
 wrote:

On 8/27/15 1:05 AM, thierry bordaz wrote:

On 08/27/2015 09:41 AM, Ludwig Krispenz wrote:


On 08/27/2015 09:08 AM, Martin Kosek wrote:

On 08/26/2015 05:31 PM, Simo Sorce wrote:

On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:

Hello all,

My biggest problem is losing replicas and then trying to
delete the
entries and rebuild them. Here is a perfect example, I
simply can't get
rid of these  (see below). I have tried (of course after
the ORIGINAL
"ipa-replica-manage del hostname --force --clean":

ipa-replica-manage clean-ruv 25

ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25

And yet nothing works. Any suggestions? This is perhaps
the most
frustrating part about maintaining IPA.

~J

unable to decode: {replica 12} 5588dc2e000c
559f3de60004000c
unable to decode: {replica 14} 5587aa8d000e
5587aa8d0003000e
unable to decode: {replica 16} 5588f58f0010
55bb7b0800050010
unable to decode: {replica 25} 55a4887b0019
55a4924200040019
unable to decode: {replica 29} 55d199a50001001d
55d199a50001001d
unable to decode: {replica 3} 5587c5c30003
55b8a04900010003
unable to decode: {replica 5} 55cc82ab041d0005
55cc82ab041d0005

Have you tried restarting DS before trying to clean the
ruv ?

I run in a similar problem in a test install recently,
and I got better
results that way. The bug is known to the DS people and
they are working
to get out patches that fix the root issue.

Simo.

CCing DS folks. Wasn't there a recent DS fix that was
supposed to improve the
RUV situation?

Looking at 389 DS Trac, I see some interesting RUV fixes
in 1.3.4.x releases:


https://fedorahosted.org/389/query?summary=~RUV=closed=milestone=id=summary=status=owner=type=priority=milestone




I see that 389-ds-base-1.3.4.3 is already in Fedora 22+,
does the RUV issue
happen there?

it should not, and I think Thierry verified the fix.
The problem we resolved and which we think is the core of
the corrupted RUV was that the cleanallruv task did only
purge the RUV, but dit not purge the changelog. If
cleanallruv was run and the server had a disorderly
shutdown (crash or abort when shutdown was hanging) then at
restart the changelog RUV was rebuilt from the data in the
changelog and if it contained a csn from cleaned RIDs this
was added to the RUV (but the reference to the server was
lost and so the url part is missing from this RUV.
The fix now does remove all references to the cleaned RID
from the changelog and the problem should not reoccur with
RIDs cleaned with the fix, of course th echangelog can
still can contain references to RIDs cleaned before the fix
- and if no changelog trimming is configured this is what
will happen. So, even after the fix old RUVs could pop up
and have to be (finally) cleaned.

The other source is that these corrupted rivs can be