FREEIPA AND NO DNA RANGE
Ok, so let’s say you have an initial IPA master and one more more additional masters (aka replicas). You’ve always done all administration on the first one and it is now temporarily or permanently gone, but it’s gone, and you really need to add that new CEO’s unix account.
If you try to add a new user you might get a nasty error like this:
1 |
ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. |
When a master is created it isn’t automatically assigned a DNA range for POSIX IDs. A range is requested from the master it was created from when a range is needed. It gets half the remaining range on the master it talks to.
This means that the current master can’t contact another one to get a DNA range, so you can’t add any new users.
You can find the master it is trying to talk to here:
1 |
$ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com |
In all likelihood it is pointing to the master that is down.
So how do you fix it?
If you have another master with a DNA range assigned then you can change the value of dnaHostname in the above entry to point to that master. The downside is that you run the risk of losing a huge chunk of unused IDs.
How do I do it without losing a ton of values? That’s quite a loaded question as it depends greatly on your environment. What you want to avoid, at almost all costs is to end up with an overlapping DNA configuration such that two masters are issuing UIDs from the same namespace, or to configure it such that it is re-assigning values.
You can find the initial namespace with:
1 2 3 4 5 6 7 8 9 10 11 12 |
$ ipa idrange-find --------------- 1 range matched --------------- Range name: EXAMPLE.COM_id_range First Posix ID of the range: 1689600000 Number of IDs in the range: 200000 Range type: local domain range ---------------------------- Number of entries returned 1 ---------------------------- |
Or by looking at /var/log/ipaserver-install.log on the initial master.
DNA would have tried to give you half its remaining range if the master had been up so for safety you could try that, assuming it doesn’t overlap any other masters. You’ll need to check their DNA configurations to be sure.
If you are running IPA 3.3+ then ipa-replica-manage can help you configure DNA properly. See dnarange-show and dnarange-set. Don’t be confused by dnanextrange-*, that is more for preserving ranges when a master is deleted.
For now I’m doing this the manual way which will work on any version.
Run this on each master:
1 |
$ ldapsearch -x -D 'cn=Directory Manager' -W -b 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' |
If the dnaNextValue is 1101 and the dnaMaxValue is 1100 then no range has yet been assigned.
WARNING: You cannot currently use the ipa idrange-add command to add a new range for POSIX uids. Through IPA 4.1 there is no connection between DNA and the ID range. The ID range shown with the idrange command is a convenience only.
Once you’re sure you have a viable range you can update the non-working master with whatever range you’ve come up with:
1 2 3 4 5 6 7 8 9 10 11 12 |
$ ldapmodify -x -D 'cn=Directory Manager' -W Enter LDAP Password: dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: modify replace: dnaNextValue dnaNextValue: 1689700000 - replace: dnaMaxValue dnaMaxValue: 1689799999 ^D modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" |
Now you can add a new user successfully:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ ipa user-add --first=tim --last=user tuser1 ------------------- Added user "tuser1" ------------------- User login: tuser1 First name: tim Last name: user Full name: tim user Display name: tim user Initials: tu Home directory: /home/tuser1 GECOS: tim user Login shell: /bin/sh Kerberos principal: tuser1@EXAMPLE.COM Email address: tuser1@example.com UID: 1689700000 GID: 1689700000 Password: False Member of groups: ipausers Kerberos keys available: False |
0 Comments