On 01/25/2017 12:44 PM, Harald Dunkel wrote:
Hi Thierry,
On 01/24/17 17:56, thierry bordaz wrote:
On 01/24/2017 04:18 PM, Harald Dunkel wrote:
Would you suggest to disconnect ipabak from the network and ipa1,
cleanup the mess as far as possible, and then connect ipabak
to the network again
t
is advisable to remove the references to the no longer existing server
using clean ruv
Ludwig
On 04/01/2015 04:29 PM, Janelle wrote:
Hello again,
This is a more general question as I am new to "dirsrv" a bit. I have
read through a lot of the docs, including 389-ds, but with regards t
On 04/08/2015 12:04 PM, Martin Kosek wrote:
On 04/08/2015 11:52 AM, Alexander Frolushkin wrote:
Hello!
We used have a geo-replicated IPA with RHEL 7.0, and on one site ipa servers
was upgraded by mistake to RHEL 7.1 (ipa-server-4.1.0-18.el7_1.3.x86_64).
Now it is broken globally, in logs I see
hange 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 t
On 04/24/2015 09:26 AM, Dominik Korittki wrote:
Hello all,
I am running two ipa3.3.3 instances in a replication on Centos 7 servers.
Last day the rootpartition went full (where the dirsrv databases are
stored), because of a big changelog-db.
dirsrv managed to do a graceful shutdown. Luckily, t
On 04/26/2015 10:49 AM, Martin (Lists) wrote:
Hallo
after a reboot I get almost thousand of the following messages:
DSRetroclPlugin - delete_changerecord: could not delete change record
128755 (rc: 32)
this message comes from changeglog trimming and means that an entry,
which should be purged
On 04/29/2015 03:14 PM, thierry bordaz wrote:
On 04/29/2015 02:43 PM, Andy Thompson wrote:
-Original Message-
From: Martin Kosek [mailto:mko...@redhat.com]
Sent: Wednesday, April 29, 2015 8:31 AM
To: Andy Thompson;freeipa-users@redhat.com; Ludwig Krispenz; Thierry
Bordaz
Subject: Re
On 04/29/2015 03:17 PM, Martin (Lists) wrote:
Am 27.04.2015 um 09:45 schrieb Ludwig Krispenz:
On 04/26/2015 10:49 AM, Martin (Lists) wrote:
Hallo
after a reboot I get almost thousand of the following messages:
DSRetroclPlugin - delete_changerecord: could not delete change record
128755 (rc
On 04/29/2015 03:40 PM, Andy Thompson wrote:
-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Wednesday, April 29, 2015 9:22 AM
To: thierry bordaz
Cc: Andy Thompson; Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] deleting ipa user
On 04
jectClass
-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Wednesday, April 29, 2015 10:07 AM
To: Andy Thompson
Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] deleting ipa user
On 04/29/2015 03:40 PM, Andy Thompson wrote
did you run the searches as directory manager ?
On 04/29/2015 04:34 PM, Andy Thompson wrote:
-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Wednesday, April 29, 2015 10:28 AM
To: Andy Thompson
Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com
On 04/29/2015 04:49 PM, Andy Thompson wrote:
-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Wednesday, April 29, 2015 10:51 AM
To: Andy Thompson
Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] deleting ipa user
did
On 04/29/2015 05:08 PM, Andy Thompson wrote:
-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Wednesday, April 29, 2015 10:59 AM
To: Andy Thompson
Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] deleting ipa user
On
On 04/29/2015 05:35 PM, Andy Thompson wrote:
-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Wednesday, April 29, 2015 11:28 AM
To: Andy Thompson
Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] deleting ipa user
On 04
On 04/29/2015 05:51 PM, Martin (Lists) wrote:
Am 29.04.2015 um 15:43 schrieb Ludwig Krispenz:
On 04/29/2015 03:17 PM, Martin (Lists) wrote:
Am 27.04.2015 um 09:45 schrieb Ludwig Krispenz:
On 04/26/2015 10:49 AM, Martin (Lists) wrote:
Hallo
after a reboot I get almost thousand of the
advance
ipa-client-4.1.0-18.el7_1.3.x86_64
ipa-server-4.1.0-18.el7_1.3.x86_64
Ludwig or Thierry, do you know? The questions about RUV cleaning seems to be
recurring, I suspect there will be a pattern (bug) and not just configuration
issue.
we have seen this in a recent thread, and it is clear that the
let's keep the info on the list, more peple more ideas
Original Message
Subject:Re: [Freeipa-users] IPA RUV unable to decode
Date: Tue, 5 May 2015 18:32:15 +0200
From: Vaclav Adamec
To: Ludwig Krispenz
master:
ipa-replica-manage del -fc
ipa-replica-pr
Hi,
there seem to be different issues,
- I don't know what the ipactl status is looking for when it generates
the error message about no matching master,
but I don't think it is related to the retro changelog.
- the retro changelog errors for adding and deleting
-- the add failures are about a
regards,
Lukasz Jaworski 'Ender'
Wiadomość napisana przez Ludwig Krispenz w dniu 6 maj
2015, o godz. 10:52:
Hi,
there seem to be different issues,
- I don't know what the ipactl status is looking for when it generates the
error message about no matching master,
but I don't th
ne. On physical servers all works fine.
the messages indicate there could be many concurrent operations,
because individual ops are not fast enough, could your VM have
less/slower resources than the physical machines ?
Lukasz Jaworski 'Ender'
Wiadomość napisana przez Ludwig Krispenz w
On 05/07/2015 10:46 AM, Christoph Kaminski wrote:
> I am curious however. I have been running OpenLDAP configs with 20 or
> more servers in replication for over 5 years. In all that time, I think
> I have had replication issues 5 times. In the 6 months of working with
> FreeIPA, replication iss
On 05/07/2015 08:38 AM, Christoph Kaminski wrote:
> Just a guess, what is your deployment size?
> We have a two ipa domains, one have 3 servers (2 hw and 1 vm, no
> issues with dirsrv yet), another currently includes 16 vm servers,
> ant dirsrv hangs and crashes periodically...
>
we have 8 IPA
think this kind of RUV should never exist, strange enough we have a
hard time to reproduce it in the lab, but out in the real world they
seem to proliferate.
Any help to reproduce is greatly appreciated.
Ludwig
rob
--
Manage your subscription for the Freeipa-users mailing list:
http
On 05/13/2015 06:34 PM, Janelle wrote:
On 5/13/15 9:13 AM, Rich Megginson wrote:
On 05/13/2015 10:04 AM, Janelle wrote:
On 5/13/15 8:49 AM, Rich Megginson wrote:
On 05/13/2015 09:40 AM, Janelle wrote:
Recently I started seeing these crop up across my servers:
slapi_ldap_bind - Error: could
On 05/15/2015 02:45 PM, Janelle wrote:
On 5/15/15 3:30 AM, Ludwig Krispenz wrote:
On 05/13/2015 06:34 PM, Janelle wrote:
On 5/13/15 9:13 AM, Rich Megginson wrote:
On 05/13/2015 10:04 AM, Janelle wrote:
On 5/13/15 8:49 AM, Rich Megginson wrote:
On 05/13/2015 09:40 AM, Janelle wrote
obviously this is not acceptable.
Hello Janelle,
I am very sorry to hear about your troubles. Would you be still OK
with helping us (mostly Ludwig and Thierry) investigate what is the
root cause of the instability of the replication agreements? This is
obviously something that should not be ha
On 05/20/2015 02:57 AM, Janelle wrote:
On 5/19/15 12:04 AM, thierry bordaz wrote:
On 05/19/2015 03:42 AM, Janelle wrote:
On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I really wish the
product was more stable, it is so much potential and yet.
Servers running
On 05/20/2015 03:25 PM, Janelle wrote:
On 5/20/15 12:54 AM, Ludwig Krispenz wrote:
On 05/20/2015 02:57 AM, Janelle wrote:
On 5/19/15 12:04 AM, thierry bordaz wrote:
On 05/19/2015 03:42 AM, Janelle wrote:
On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I
ogging (nsslapd-errorlog-level: 128)
or returning one entry when each of the terms each returns a unique entry,
seems wrong.
It does return two entries when both are in the same subtree.
This one sounds strange, CCing Ludwig for reference.
###
### everything ok when using admin... two
could you try this:
https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html
it was successfully applied before
On 05/21/2015 06:58 AM, Alexander Frolushkin wrote:
Hello again.
Is it now clear how to deal with problem ipa-replica-manage list-ruv
showing
unable to decode: {repli
:*freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Ludwig Krispenz
*Sent:* Thursday, May 21, 2015 1:37 PM
*To:* freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] ruv problem
could you try this:
https://www.redhat.com/archives/freeipa-users/2015-May
we have a look at them ?
Ludwig
--
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
On 05/21/2015 02:20 PM, thierry bordaz wrote:
On 05/21/2015 01:36 PM, Janelle wrote:
And just like that - for no reason, they all reappeared:
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 23} 5545d61f00020017 5552f71800030017
unabl
On 05/21/2015 03:04 PM, Janelle wrote:
On 5/21/15 5:49 AM, Rich Megginson wrote:
On 05/21/2015 06:25 AM, Janelle wrote:
On 5/21/15 5:20 AM, thierry bordaz wrote:
Hello Janelle,
Those 3 RIDs were already present in Node dc2-ipa1, correct ? They
reappeared on others nodes as well ?
May be ds2
On 05/21/2015 03:28 PM, Janelle wrote:
I think I found the problem.
There was a lone replica running in another DC. It was installed as a
replica some time ago with all the others. Think of this -- the
original config had 5 servers, one of them was this server. Then the
other 4 servers were
On 05/21/2015 03:59 PM, Janelle wrote:
On 5/21/15 6:46 AM, Ludwig Krispenz wrote:
On 05/21/2015 03:28 PM, Janelle wrote:
I think I found the problem.
There was a lone replica running in another DC. It was installed as
a replica some time ago with all the others. Think of this -- the
+uid=janelle,
you can delete the nsuniqeid= entry to get rid of it.
There is a request to hide these nsuniqueid+uid entries from regular
searches, it will be in a next release of 389
Ludwig
~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.
On 06/16/2015 11:42 AM, Alexander Frolushkin wrote:
Hello.
Just to remind if somebody still not familiar with our IPA installation J
We currently have 18 IPA servers in domain, on 8 sites in different
regions across the Russia.
And now, our new problem.
Regularly we getting a nsds5ReplCon
der Frolushkin
Cell +79232508764
Work +79232507764
*From:*freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Ludwig Krispenz
*Sent:* Tuesday, June 16, 2015 3:52 PM
*To:* freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] replication conflicts
On 06/16/2015
On 06/16/2015 02:08 PM, Janelle wrote:
On Jun 16, 2015, at 01:56, thierry bordaz wrote:
On 06/16/2015 09:02 AM, Ludwig Krispenz wrote:
On 06/16/2015 05:07 AM, Janelle wrote:
On 6/15/15 1:12 PM, Rob Crittenden wrote:
Janelle wrote:
On 6/15/15 6:36 AM, Rob Crittenden wrote:
Usually means
hings. And believe me, the corrupted
ruvs haunt me as much as you
Ludwig
~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
here these entries were created.
Ludwig
On 06/17/2015 08:13 AM, Alexander Frolushkin wrote:
Hello.
Anotherexample. Today appeared on servers of different site.
Original LDIF:
# extended LDIF
#
# LDAPv3
# base Keytab,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru> with scope subtr
info on replica 26, when was it created, was
it disconnected for some time ??
Ludwig
On 06/17/2015 08:13 AM, Alexander Frolushkin wrote:
Hello.
Anotherexample. Today appeared on servers of different site.
Original LDIF:
# extended LDIF
#
# LDAPv3
# base Keytab,cn=permissions,cn=pbac
.
so on which servers does the "nsuniqueid" entry exist ?
can you check for 5580f321001a in the access log of replica 26,
then check the errro log around this time and eventually the replica
install log
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
*Fr
8764
Work +79232507764
*From:*thierry bordaz [mailto:tbor...@redhat.com]
*Sent:* Wednesday, June 17, 2015 3:15 PM
*To:* Alexander Frolushkin (SIB)
*Cc:* 'Ludwig Krispenz'; freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] replication conflicts
Hello Alexander,
How did you initialize
On 06/17/2015 11:52 AM, Ludwig Krispenz wrote:
On 06/17/2015 11:45 AM, thierry bordaz wrote:
On 06/17/2015 11:22 AM, Alexander Frolushkin wrote:
This was a usual "ipa-replica-install --setup-ca --setup-dns" and
after that ipa-adtrust-install.
No DEL found:
# grep "cn
*From:*thierry bordaz [mailto:tbor...@redhat.com]
*Sent:* Wednesday, June 17, 2015 4:10 PM
*To:* Alexander Frolushkin (SIB)
*Cc:* 'Ludwig Krispenz'; freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] replication conflicts
On 06/17/2015 11:56 AM, Alexander Frolushkin wrote:
Wi
ate this 4 hrs after the
replica installation.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
*From:*Ludwig Krispenz [mailto:lkris...@redhat.com]
*Sent:* Wednesday, June 17, 2015 4:35 PM
*To:* Alexander Frolushkin (SIB)
*Cc:* 'thierry bordaz'; freeipa-users@redh
Hi Christoph,
bad news. So to summarize, you have a procedure to cleanup your env, but
once you restart the master the ghosts are back.
I really want to find out where they are coming from, so If you have to
restart your server, could you please lookup these data, after the
server is stopped
On 06/19/2015 11:48 AM, Christoph Kaminski wrote:
freeipa-users-boun...@redhat.com schrieb am 19.06.2015 11:34:21:
> Von: Ludwig Krispenz
> An: freeipa-users@redhat.com
> Datum: 19.06.2015 11:35
> Betreff: Re: [Freeipa-users] WG: Re: Haunted servers?
> Gesendet von: fre
Hi,
On 06/19/2015 12:32 PM, Christoph Kaminski wrote:
> in the second search I don't see nsds50ruv attributes for dead
> entries, so the database ruv seems to be ok.
these are dead:
nscpentrywsi: nsDS5ReplicaBindDN:
krbprincipalname=ldap/ipa-2.mgmt.biotronik-h
omemonitoring.int@HSO,cn=service
ReplicaRoot=o=ipaca))" nsDS5ReplicaId
then you could search
ldapsearch -h -D "cn=Directory Manager" -W -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---
))"
to see what you have in the ruv and eventually clean them
On 06/19
nsUniqueId=---
> ffff))"
> to see what you have in the ruv and eventually clean them
> On 06/19/2015 01:48 PM, Christoph Kaminski wrote:
> Ludwig Krispenz schrieb am 19.06.2015 13:23:43:
>
> >
> > > the first search is for the rep
from information
in the changelog. they can then also propagate to other servers
Could something similar have happened in your environment ?
Ludwig
On 06/12/2015 07:38 AM, Christoph Kaminski wrote:
I've been too early pleased :/ After ipactl restart of our first
master (where we re-initia
enable changelog trimming.
Does anyone already use changlog trimming or is there a scenario where
you rely on all changes being available ?
Thanks for your feedback,
Ludwig
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go
On 07/03/2015 02:03 PM, Petr Spacek wrote:
On 3.7.2015 11:45, thierry bordaz wrote:
On 06/30/2015 03:54 PM, Ludwig Krispenz wrote:
Hi,
389-ds allows to configure the max size of the replication changelog either
by setting a maximum record number or a maximum age of changes.
freeIPA does not
On 07/03/2015 02:28 PM, Petr Spacek wrote:
On 3.7.2015 14:21, thierry bordaz wrote:
On 07/03/2015 02:03 PM, Petr Spacek wrote:
On 3.7.2015 11:45, thierry bordaz wrote:
On 06/30/2015 03:54 PM, Ludwig Krispenz wrote:
Hi,
389-ds allows to configure the max size of the replication changelog
can you get a pstack of the slapd process along with a top -H to find th
ethread with high cpu usage
Ludwig
On 07/13/2015 04:46 PM, Andrew E. Bruno wrote:
We have 3 freeipa-replicas. Centos 7.1.1503, ipa-server 4.1.0-18, and
389-ds 1.3.3.1-16.
Recently, the ns-slapd process on one of our
On 07/13/2015 05:05 PM, Andrew E. Bruno wrote:
On Mon, Jul 13, 2015 at 04:58:46PM +0200, Ludwig Krispenz wrote:
can you get a pstack of the slapd process along with a top -H to find th
ethread with high cpu usage
Attached is the full stacktrace of the running ns-slapd proccess. top -H
shows
On 07/13/2015 06:36 PM, Andrew E. Bruno wrote:
On Mon, Jul 13, 2015 at 05:29:13PM +0200, Ludwig Krispenz wrote:
On 07/13/2015 05:05 PM, Andrew E. Bruno wrote:
On Mon, Jul 13, 2015 at 04:58:46PM +0200, Ludwig Krispenz wrote:
can you get a pstack of the slapd process along with a top -H to
earch from
m14-24.ccr.buffalo.edu adn the server with the high cpu:
ldapsearch -o ldif-wrap=no -x -D ... -w -b "cn=config"
"objectclass=nsds5replica" nsds50ruv
On 07/14/2015 02:35 PM, Andrew E. Bruno wrote:
On Tue, Jul 14, 2015 at 01:41:57PM +0200, Ludwig Krispenz wrote:
On
On 07/14/2015 08:59 PM, Andrew E. Bruno wrote:
On Tue, Jul 14, 2015 at 04:52:10PM +0200, Ludwig Krispenz wrote:
hm, the stack traces show csn_str, which correspond to Jul,8th, Jul,4th, and
Jul,7th - so it looks like it is iterating the changelog over and over
again.
Th consumer side Is &qu
On 07/15/2015 04:10 PM, Andrew E. Bruno wrote:
On Wed, Jul 15, 2015 at 03:22:51PM +0200, Ludwig Krispenz wrote:
On 07/14/2015 08:59 PM, Andrew E. Bruno wrote:
On Tue, Jul 14, 2015 at 04:52:10PM +0200, Ludwig Krispenz wrote:
hm, the stack traces show csn_str, which correspond to Jul,8th, Jul
s latest
change and define a new offset
Regards,
Ludwig
On 07/15/2015 07:05 PM, Andrew E. Bruno wrote:
On Wed, Jul 15, 2015 at 04:58:23PM +0200, Ludwig Krispenz wrote:
On 07/15/2015 04:10 PM, Andrew E. Bruno wrote:
On Wed, Jul 15, 2015 at 03:22:51PM +0200, Ludwig Krispenz wrote:
On 07/14/2015
On 07/22/2015 06:40 PM, Alexander Bokovoy wrote:
On Wed, 22 Jul 2015, Alexandre Ellert wrote:
Le 22 juil. 2015 à 18:08, Alexander Bokovoy a
écrit :
On Wed, 22 Jul 2015, Alexandre Ellert wrote:
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
from both servers?
Server 1:
# fgrep -r 0.9.
On 07/23/2015 09:56 AM, Sumit Bose wrote:
On Thu, Jul 23, 2015 at 09:18:43AM +0200, Torsten Harenberg wrote:
Hi Sumit,
The principal looks strange, I would at least expect the fully-qualified
name of the ipa server here. What does the 'hostname' command return? It
[root@ipa slapd-PLEIADES-U
effective.
So you could also stop DS, edit /etc/dirsrv/slapd-/dse.ldif
search all *cache* attributes and replace the valu.
Ludwig
On 07/23/2015 10:21 AM, Marisa Sandhoff wrote:
Hi Sumit,
I'm not a 389ds expert but in my setup nsslapd-cachememsize is set to
10M and since I didn't do an
On 08/04/2015 05:40 PM, Rob Crittenden wrote:
Janelle wrote:
Hello again,
Just to keep your Tuesday fun, is this possible:
16 servers.
ipa-replica-manage list < shows all 16
1 of the servers broke a couple of weeks ago and was removed with
"clean-ruv" but STILL shows up in the replica l
Hi
On 08/04/2015 06:14 PM, Janelle wrote:
On 8/4/15 9:06 AM, Ludwig Krispenz wrote:
On 08/04/2015 05:40 PM, Rob Crittenden wrote:
Janelle wrote:
Hello again,
Just to keep your Tuesday fun, is this possible:
16 servers.
ipa-replica-manage list < shows all 16
1 of the servers brok
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
On 09/01/2015 04:39 PM, Andrew E. Bruno wrote:
A few months ago we had a replica failure where the system ran out of file
descriptors and the slapd database was corrupted:
https://www.redhat.com/archives/freeipa-users/2015-June/msg00389.html
We now monitor file descriptor counts on our replica
r 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, S
On 09/04/2015 04:37 PM, Christoph Kaminski wrote:
Hi
we have a lot of this messages in the error log of dirsrv... What can
be the problem and how can we fix it?
our (first) master (ipa-1.mgmt.biotronik-homemonitoring.int):
[04/Sep/2015:16:06:41 +0200] ipalockout_postop - [file ipa_lockout.c,
On 09/04/2015 04:49 PM, Christoph Kaminski wrote:
Hi All,
how can I delete a faulty user in IPA 4.1? The record in LDAP look
like this:
nsuniqueid=a69f868e-4b4411e5-99ef9ac3-776749aa+uid=zimt,cn=users,cn=accounts,dc=hso
this is a replication conflict entry, the user uid=zimt was added in
par
On 09/18/2015 12:24 AM, HECTOR LOPEZ wrote:
This is rhel 7.1 with ipa version 4.1.0
user-show shows the user. However, if the user contains
ipaNTSecurityIdentifier: attribute, user-del hangs with no response.
Meanwhile, the KDC and 389ds stop working. The only way to recover
functionality i
On 09/23/2015 05:05 PM, Michael Lasevich wrote:
Yes, I am talking about 389ds as is integrated in FreeIPA (would be
silly to post completely non-IPA questions to this list...).
I am running FreeIPA 4.1.4 on CentOS 7.1 and RC4 is enabled on port
636 no matter what I do.
I am running "CentOS Li
Hi,
can you try to get a core dump:
http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes
and open a ticket for 389 DS: https://fedorahosted.org/389/newticket
Ludwig
On 09/24/2015 09:08 AM, Nicola Canepa wrote:
Hello, I'm trying to setup a partial replica of the LDAP
On 06/28/2016 09:50 AM, Natxo Asenjo wrote:
On Tue, Jun 28, 2016 at 9:07 AM, Alexander Bokovoy
mailto:aboko...@redhat.com>> wrote:
On Tue, 28 Jun 2016, Natxo Asenjo wrote:
hi,
according to the RHDS documentation (
https://access.redhat.com/documentation/en-US/
On 06/28/2016 10:33 AM, Natxo Asenjo wrote:
hi Ludwig,
On Tue, Jun 28, 2016 at 10:03 AM, Ludwig Krispenz <mailto:lkris...@redhat.com>> wrote:
On 06/28/2016 09:50 AM, Natxo Asenjo wrote:
I'd like to have internally all sort of ldap access, but
externally onl
can you get a core file ?
http://www.port389.org/docs/389ds/FAQ/faq.html#debug_crashes
On 06/30/2016 11:28 AM, d...@mdfive.dz wrote:
Hi,
The Directory Services crashes several times a day. It's installed on
CentOS 7 VM :
Installed Packages
Name: ipa-server
Arch: x86_64
Versi
should look into it
Regards
On 2016-06-30 12:13, Ludwig Krispenz wrote:
can you get a core file ?
http://www.port389.org/docs/389ds/FAQ/faq.html#debug_crashes
On 06/30/2016 11:28 AM, d...@mdfive.dz wrote:
Hi,
The Directory Services crashes several times a day. It's installed
on CentOS
On 06/30/2016 02:45 PM, Ludwig Krispenz wrote:
On 06/30/2016 02:27 PM, d...@mdfive.dz wrote:
Hi,
Please find strace on a core file : http://pastebin.com/v9cUzau4
the crash is in an IPA plugin, ipa_pwd_extop,
to get a better stack you would have to install also the debuginfo for
ipa-server
\000\000\210\311\377+b\177\000\000\250\311\377+b\177", '\000'
, "\002\000\000\000 \305\363Tb\177\000\000\377\377\37
7\377\377\377\377\377\320\030\002\000b\177\000\000\000\000\000\000\000\000\000\000~a\003\000b\177",
'\000'
bind_target_entry = 0x0
On 2016
, Ludwig Krispenz wrote:
please keep the discussion on the mailing list
On 07/01/2016 01:17 PM, Omar AKHAM wrote:
Which package to install ? ipa-debuginfo?
yes
2 other crashes last night, with a different user bind this time :
rawdn = 0x7f620003a200
"uid=XXX,cn=users,cn=accounts,dc=XXX,
sword containing arbitrar octets.
Please open a ticket to get this worked on:
https://fedorahosted.org/freeipa/newticket
Ludwig
On 07/05/2016 12:07 AM, Omar AKHAM wrote:
Ok, here is a new core file : http://pastebin.com/2cJQymHd
Best regards
On 2016-07-04 09:39, Ludwig Krispenz wrote:
On 07/03/20
don't need to
reveal any real data, jsur which objectclasses and attributes the entry has
On 2016-07-05 10:51, Ludwig Krispenz wrote:
well, this does not have more information:
#0 0x7efe7167c4c0 in ipapwd_keyset_free () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table
On 07/12/2016 11:25 AM, Christophe TREFOIS wrote:
Hi,
I have 3 replicas running 4.1 and 3 replicas running 4.2.
One of the 4.2 replicas is the new master (CRL) and is at the moment
replicating against the old 4.1 cluster (we are in the process of
migrating).
Upon restart of the 4.2 master,
this will be sufficient.
Ludwig
On 08/12/2016 08:06 AM, Torsten Harenberg wrote:
Am 11.08.16 um 17:58 schrieb Rob Crittenden:
Torsten Harenberg wrote:
Hi,
we have three ipa servers
- ipa
- ipa2
- ipacentos7
We wanted to re-install ipa2 from scratch as this server gave us strange
issues in the
On 08/12/2016 04:10 PM, Louis Francoeur wrote:
Since the rpm update to
ipa-server-dns-4.2.0-15.0.1.el7.centos.18.x86_64 (running on Centos 7),
most of my replication started to failed with:
what do you mean by "most of", if some servers still work and others
don't is there something diffe
On 08/17/2016 08:54 PM, John Desantis wrote:
Hello all,
We've been re-using old host names and IP addresses for a new
deployment of nodes, and recently I've been seeing the messages pasted
below in the slapd-DC.DC.DC "error" log on our nodes.
[17/Aug/2016:10:30:30 -0400] - replica_generate_nex
On 08/18/2016 03:15 PM, John Desantis wrote:
Ludwig,
Thank you for your response!
This is a normal scenario, but you could check if the simultaneous updates
on 4 and 16 are intentional.
In regards to the simultaneous updates, the only items I have noted so far are:
* The time sync between
On 08/18/2016 05:28 PM, John Desantis wrote:
Ludwig,
unfortunately this is not enough to determine what is going on. The
intersting generated/used csn is only logged in the
corresponding RESULT message and these are only the replication connections,
it would be necessary to see the
original
me=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:26 -0400] conn=13
op=126758 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:29 -0400] conn=13
op=126801 MOD dn="idnsname=rc.usf.ed
looks like you are searching the nstombstone below "o=ipaca", but you
are cleaning ruvs in "dc=bpt,dc=rocks",
your attrlist_replace error refers to the bpt,rocks backend, so you
should search the tombstone entry ther, then determine which replicaIDs
to remove.
Ludwig
On
7;ve done that before a couple times and that seems to be what got me
into this mess...
Thank you for your help.
On 08/23/2016 01:37 AM, Ludwig Krispenz wrote:
looks like you are searching the nstombstone below "o=ipaca", but you
are cleaning ruvs in "dc=bpt,dc=rocks",
your att
On 08/24/2016 01:08 AM, Ian Harding wrote:
On 08/23/2016 03:14 AM, Ludwig Krispenz wrote:
On 08/23/2016 11:52 AM, Ian Harding wrote:
Ah. I see. I mixed those up but I see that those would have to be
consistent.
However, I have been trying to beat some invalid RUV to death for a long
time
The replication agreements to the "unsync" master says that update has
started, so it looks like replication connection is active.
You need to check the access and error logs of bot sides and check if
tehre is replication traffic
On 08/24/2016 06:33 PM, bahan w wrote:
Hey guys.
I performed it
I just noticed that you have many skipped entries, Sent/Skipped: 3 / 9045345
that could be an effect of fractional replication which reiterates the
same sequence of changes. This is fixed in recent releases, but looks
like your on RHEL 6.6
Ludwig
On 08/24/2016 06:33 PM, bahan w wrote:
Hey
On 08/25/2016 04:41 PM, bahan w wrote:
Hello everyone.
Could you explain to me about this field Sent/Skipped please ?
if replication is enabled all changes on a server are logged into the
changelog -changes coming from clients and internal changes (eg mmeberof
update, passwordpolocy updates,
Hi,
On 09/13/2016 07:37 PM, Rakesh Rajasekharan wrote:
Hi All,
Have finally made some progress with this.. after changing the
checkpoint interval to 180, my hangs have gone down now..
However, I faced a similar hang yesterday... users were not able to
login.. , though this time the ns-slapd
1 - 100 of 214 matches
Mail list logo
