On su, 01 loka 2017, dbischof--- via FreeIPA-users wrote:

Dear list,

I ran into a replication and id-range issue recently and need a hint. I upgraded from FreeIPA 3.0 to 4.x a couple of months ago, everything ran fine. Configuration is

o201: 4.5 master server poolsrv: 4.5 replica server

Then, i noticed that new accounts got UIDs starting after around 1100 (instead of after 150600000 as it used to be) and data changes (new passwords, etc.) weren't propagated from replica to master (it works the other way round, though). I'm unsure, if these two problems are related to each other.

Logs on the replica server showed:

---

Oct 1 12:51:25 poolsrv ns-slapd: [01/Oct/2017:12:51:25.971742707 +0200] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=meToo201.example.org" (o201:389): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized. Oct 1 12:51:28 poolsrv ns-slapd: [01/Oct/2017:12:51:28.997226017 +0200] - ERR - agmt="cn=meToo201.example.org" (o201:389) - clcache_load_buffer - Can't locate CSN 59ce5686000200070000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. Oct 1 12:51:29 poolsrv ns-slapd: [01/Oct/2017:12:51:29.029970733 +0200] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=meToo201.example.org" (o201:389): CSN 59ce5686000200070000 not found, we aren't as up to date, or we purged Oct 1 12:51:29 poolsrv ns-slapd: [01/Oct/2017:12:51:29.050568545 +0200] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=meToo201.example.org" (o201:389): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized.

---

I did a

---

ipa-replica-manage re-initialize --from o201.example.org

on the replica server and the errors in the logs went away - the problems (both) didn't, unfortunately.

The logs now show

---

Oct 1 18:45:44 poolsrv ns-slapd: [01/Oct/2017:18:45:44.794912092 +0200] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1103] into an unused SID. Oct 1 18:45:44 poolsrv ns-slapd: [01/Oct/2017:18:45:44.851503923 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 149]: Cannot add SID to new entry.

Oct 1 18:46:53 o201 ns-slapd: [01/Oct/2017:18:46:53.360717035 +0200] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1106] into an unused SID. Oct 1 18:46:53 o201 ns-slapd: [01/Oct/2017:18:46:53.361100457 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 149]: Cannot add SID to new entry.

---

Further information:

---

root@o201:~# ipa idrange-find

1 range matched

Range name: EXAMPLE.ORG_id_range First Posix ID of the range: 150600000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range

---

Number of entries returned 1

root@o201:~# ipa-replica-manage dnarange-show o201.example.org: 1108-5000 poolsrv.example.org: 1105-5000

---

The latter looks broken. The above output is identical on both the master and the replica server. "ipactl status" shows all services running on both servers.

Looks like you need to restore dnarange on both masters according to the idrange you have. You also need to add an idrange to cover those new users in 1100-5000 dnarange or change UIDs/GIDs for those users to be in the original idrange.

sidgen plugin complains because you have no idrange to cover 1100-5000 and as result it is unable to map those UID/GID to SID.