My cluster has been successfully working for over a year with version 4.2 I have replica of two ipa nodes and winsync
Tried to upgrade (ipa-server-upgrade) and replica seems to be ruined after it. I can't even check its status
[root@idm0 ~]# ipa-replica-manage list --verbose Traceback (most recent call last): File "/usr/sbin/ipa-replica-manage", line 1615, in <module> main(options, args) File "/usr/sbin/ipa-replica-manage", line 1548, in main options.nolookup) File "/usr/sbin/ipa-replica-manage", line 197, in list_replicas config_string = ent.single_value['ipaConfigString'] File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 564, in __getitem__ value = self._entry[name] File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 442, in __getitem__ return self._get_nice(name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 409, in _get_nice name = self._get_attr_name(name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 405, in _get_attr_name name = self._names[name] File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 583, in __getitem__ return super(CIDict, self).__getitem__(key.lower()) KeyError: u'ipaconfigstring' Unexpected error: u'ipaconfigstring'
Please any advises how to restore replication and winsync after upgrade, this is quite critical.
skrawczenko--- via FreeIPA-users wrote:
My cluster has been successfully working for over a year with version 4.2 I have replica of two ipa nodes and winsync
Tried to upgrade (ipa-server-upgrade) and replica seems to be ruined after it. I can't even check its status
[root@idm0 ~]# ipa-replica-manage list --verbose Traceback (most recent call last): File "/usr/sbin/ipa-replica-manage", line 1615, in <module> main(options, args) File "/usr/sbin/ipa-replica-manage", line 1548, in main options.nolookup) File "/usr/sbin/ipa-replica-manage", line 197, in list_replicas config_string = ent.single_value['ipaConfigString'] File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 564, in __getitem__ value = self._entry[name] File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 442, in __getitem__ return self._get_nice(name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 409, in _get_nice name = self._get_attr_name(name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 405, in _get_attr_name name = self._names[name] File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 583, in __getitem__ return super(CIDict, self).__getitem__(key.lower()) KeyError: u'ipaconfigstring' Unexpected error: u'ipaconfigstring'
Please any advises how to restore replication and winsync after upgrade, this is quite critical.
This is unlikely to be broken replication, it seems to be an issue with the ipa-replica-manage tool.
Look at the entries in LDAP using something like (replace example and com with whatever your search base is):
$ kinit admin $ ldapsearch -Y GSSAPI -b cn=replicas,cn=ipa,cn=etc,dc=example,dc=com
In theory there should be only one entry: your winsync agreement. It should have an ipaConfigString value of: winsync:<ad_host_name>
If there are other entries we'll need to see them.
If it's just the ipaconfigstring missing it is straightforward to re-add it.
rob
Thank you, Rob
You're right, ipaconfigstring is missing, i've googled your instructions from the past how to re-add it. Any idea why it disappears?
Many thanks
i'm afraid also i'm unable to add the ipaconfigstring attribute into this dn
ldapmodify -x -D 'cn=directory manager' -W
dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> changetype: modify add: ipaconfigstring ipaconfigstring: winsync:<domain controller>
^D modifying entry "cn=<...>
no errors ipaconfigstring attribute does not appear after that however
doing something wrong?
skrawczenko--- via FreeIPA-users wrote:
i'm afraid also i'm unable to add the ipaconfigstring attribute into this dn
ldapmodify -x -D 'cn=directory manager' -W
dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> changetype: modify add: ipaconfigstring ipaconfigstring: winsync:<domain controller>
^D modifying entry "cn=<...>
no errors ipaconfigstring attribute does not appear after that however
doing something wrong?
How are you checking that it does not appear? Is ipa-replica-manage still breaking or something else?
rob
i'm checking with ldapsearch -Y GSSAPI -b cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>
and there's just
dn: ... cn: <domain controller> objectClass: ipaConfigObject objectClass: nsContainer objectClass: top
right after ldapmodify
[root@idm0 ~]# ipa-replica-manage list unexpected error: u'ipaconfigstring'
like something is not letting the attribute to be added or removes it immediately.
skrawczenko--- via FreeIPA-users wrote:
i'm checking with ldapsearch -Y GSSAPI -b cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>
and there's just
dn: ... cn: <domain controller> objectClass: ipaConfigObject objectClass: nsContainer objectClass: top
right after ldapmodify
[root@idm0 ~]# ipa-replica-manage list unexpected error: u'ipaconfigstring'
like something is not letting the attribute to be added or removes it immediately.
That is sure curious.
Thierry, do you know if the topology plugin would mess with this kind of entry?
rob
On 11/29/2017 10:53 PM, Rob Crittenden wrote:
skrawczenko--- via FreeIPA-users wrote:
i'm checking with ldapsearch -Y GSSAPI -b cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>
and there's just
dn: ... cn: <domain controller> objectClass: ipaConfigObject objectClass: nsContainer objectClass: top
right after ldapmodify
[root@idm0 ~]# ipa-replica-manage list unexpected error: u'ipaconfigstring'
like something is not letting the attribute to be added or removes it immediately.
That is sure curious.
Thierry, do you know if the topology plugin would mess with this kind of entry?
rob
Hi,
topology plugin should not interfere into the udpate of "cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>" It catches only updates to replica agreements (under cn=config), segments (cn=topology), hosts (cn=masters), domain level (cn=domain level).
About the successful update not taken into account. Do you have the portion of access logs/error logs where the update is done ? Would you retry
ldapsearch -D "cn=directory manager" -W -b "cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>" nscpentrywsi
best regards thierry
Gentlemen, i'm very worried about breaking the entire cluster with something irreversible. Not sure what caused the missed ipaconfigstring or probably this is not the root cause. The replica nodes and winsync are still operational but ipa-replica-manage drops an error about ipaconfigstring and i badly need to fix it.
now it becomes even more weird
[root@idm0]# ldapmodify -vvvv -x -D 'cn=directory manager' -W ldap_initialize( <DEFAULT> ) Enter LDAP Password: dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> changetype: modify add: ipaConfigString ipaConfigString: <domain controller>
add ipaConfigString: <domain controller> modifying entry "cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>" modify complete
Rechecking
[root@idm0]# ldapmodify -vvvv -x -D 'cn=directory manager' -W ldap_initialize( <DEFAULT> ) Enter LDAP Password: dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> changetype: modify add: ipaConfigString ipaConfigString: <domain controller>
add ipaConfigString: <domain controller> modifying entry "cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>" ldap_modify: Type or value exists (20)
Now
[root@idm0]# ldapsearch -Y GSSAPI -b cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> SASL/GSSAPI authentication started SASL username: ... SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>> with scope subtree # filter: (objectclass=*) # requesting: ALL #
... dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> cn: <domain controller> objectClass: ipaConfigObject objectClass: nsContainer objectClass: top
??? where is ipaConfigString???
# search result search: 4 result: 0 Success
# numResponses: 2 # numEntries: 1
and this attribute also:
[root@idm0]# ldapsearch -Y GSSAPI -b cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> ncpentrywsi SASL/GSSAPI authentication started SASL username: ... SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>> with scope subtree # filter: (objectclass=*) # requesting: ncpentrywsi #
...
dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>
# search result search: 4 result: 0 Success
# numResponses: 2 # numEntries: 1
It doesn't seem to be there as well....
I can see these searches in access and nothing suspicious in errors, the replication and updates from domain controller are being performed constantly Ready to provide any more details.
Great thanks.
you can see nscpentrywsi only as "cn=directory manager", and your mods for ipacnfigstring were also done as directory manager, but you search as another user. The attribute is probably there, but access control prevents to see it.
On 11/30/2017 11:02 AM, skrawczenko--- via FreeIPA-users wrote:
Gentlemen, i'm very worried about breaking the entire cluster with something irreversible. Not sure what caused the missed ipaconfigstring or probably this is not the root cause. The replica nodes and winsync are still operational but ipa-replica-manage drops an error about ipaconfigstring and i badly need to fix it.
now it becomes even more weird
[root@idm0]# ldapmodify -vvvv -x -D 'cn=directory manager' -W ldap_initialize( <DEFAULT> ) Enter LDAP Password: dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> changetype: modify add: ipaConfigString ipaConfigString: <domain controller>
add ipaConfigString:
<domain controller> modifying entry "cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>" modify complete
Rechecking
[root@idm0]# ldapmodify -vvvv -x -D 'cn=directory manager' -W ldap_initialize( <DEFAULT> ) Enter LDAP Password: dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> changetype: modify add: ipaConfigString ipaConfigString: <domain controller>
add ipaConfigString:
<domain controller> modifying entry "cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>" ldap_modify: Type or value exists (20)
Now
[root@idm0]# ldapsearch -Y GSSAPI -b cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> SASL/GSSAPI authentication started SASL username: ... SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>> with scope subtree # filter: (objectclass=*) # requesting: ALL #
... dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> cn: <domain controller> objectClass: ipaConfigObject objectClass: nsContainer objectClass: top
??? where is ipaConfigString???
# search result search: 4 result: 0 Success
# numResponses: 2 # numEntries: 1
and this attribute also:
[root@idm0]# ldapsearch -Y GSSAPI -b cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> ncpentrywsi SASL/GSSAPI authentication started SASL username: ... SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>> with scope subtree # filter: (objectclass=*) # requesting: ncpentrywsi #
...
dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>
# search result search: 4 result: 0 Success
# numResponses: 2 # numEntries: 1
It doesn't seem to be there as well....
I can see these searches in access and nothing suspicious in errors, the replication and updates from domain controller are being performed constantly Ready to provide any more details.
Great thanks. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
I wish you were right but
ldapsearch -D "cn=directory manager" -W -b cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> ncpentrywsi
dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>
# search result search: 2 result: 0 Success
Please any suggestion how to reinitialize synchronization with AD what will probably fix the issue
nscpentrywsi
On 12/01/2017 09:53 AM, skrawczenko--- via FreeIPA-users wrote:
I wish you were right but
ldapsearch -D "cn=directory manager" -W -b cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc> ncpentrywsi
dn: cn=<domain controller>,cn=replicas,cn=ipa,cn=etc,dc=<mydc>
# search result search: 2 result: 0 Success
Please any suggestion how to reinitialize synchronization with AD what will probably fix the issue _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Ludwig, that was correct and resolved the entire issue. Somehow, the user i've created for automation jobs is not permitted to access some parts of the directory. I'm grateful for your hint.
freeipa-users@lists.fedorahosted.org
-
Ludwig Krispenz -
Rob Crittenden -
skrawczenko＠gmail.com -
thierry bordaz