[description of the issue] The freeIPA GUI shows me a message in red below the Base ID of a generated Active Directory domain range saying
Maximum value is 2147483647
The base ID I find there is 2147483648. Is this something to worry about? I haven't found sufficient information about this message in Google. The ID range seems to be generated. Here is a list:
# ipa idrange-find ---------------- 3 ranges matched ---------------- Range name: EXAMPLE.COM_id_range First Posix ID of the range: 379400000 Number of IDs in the range: 200000 Range type: local domain range Range name: EXAMPLE.COM_posix First Posix ID of the range: 1000 Number of IDs in the range: 99000 Range type: local domain range Range name: EXAMPLE.COM_subid_range First Posix ID of the range: 2147483648 Number of IDs in the range: 2147352576 First RID of the corresponding RID range: 2147283648 Domain SID of the trusted domain: S-1-5-21-738065-838566-194929194 Range type: Active Directory domain range ---------------------------- Number of entries returned 3 ----------------------------
[root@ipa1 ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server package freeipa-server is not installed package freeipa-client is not installed ipa-server-4.6.8-5.el7.centos.14.x86_64 ipa-client-4.6.8-5.el7.centos.14.x86_64 389-ds-base-1.3.11.1-1.el7_9.x86_64 pki-ca-10.5.18-27.el7_9.noarch krb5-server-1.15.1-55.el7_9.x86_64
This is FreeIPA of CentOS7. I'd love to upgrade to Rocky 8 and a more recent FreeIPA version, but I ran against a wall of problems with these ID ranges. Esp. I have no interest in an AD trust relationship. FreeIPA made this up on its own. This should be improved to ease migration.
Your value for ids exceeds the supported range of ids. The Linux Kernel uses 32 bit integers to represent uid and gids. 2147483647 is 2^31 - 1, the largest positive value that can be represented by a signed 32 bit integer number.
2147483647
2^31 - 1
I got that, but the point is I never created EXAMPLE.COM_subid_range. AFAICT thats an artifact from the attempt to migrate to a newer FreeIPA version on Rocky 8. Maybe it existed even before. Anyway, I didn't create this construct.
Hi,
I think this entry is expected and is related to subids, see https://freeipa.readthedocs.io/en/latest/designs/subordinate-ids.html for details.
If I understand it correctly there is no need to remove it and it should not cause issues with the upgrade.
bye, Sumit
The upgrade fails with "Too many ID ranges". AFAICS the upgrade procedure works only for n <= 2. You can imagine that a third ID range created by FreeIPA on its own for an AD trust relationship I didn't ask for is not very welcome.
Reading through https://freeipa.readthedocs.io/en/latest/designs/subordinate-ids.html I am confused. If the subID range is as expected, why does ipa complain about it in the GUI? And why am I not allowed to manually set the RID base for the local domain ranges?
the subid feature was not backported to 7.9, but it changed the definition of the baseid.
In ipa-4-6, the baseid is defined as an Int ( https://pagure.io/freeipa/blob/ipa-4-6/f/ipaserver/plugins/idrange.py#_220-= 223 ): Int('ipabaseid',
cli_name=3D'base_id',
label=3D_("First Posix ID of the range"),
), and by default the max value is MAXINT=3D2147483647L ( https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#1086-1098): class Int(Number): https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1087 """ https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1088 A parameter for integer values (stored in the int type). https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1089 """ https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1090 https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1091 type =3D int https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1092 allowed_types =3D six.integer_types https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1093 type_error =3D ('must be an integer') https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1094 https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1095 kwargs =3D Param.kwargs + ( https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1096 ('minvalue', six.integer_types, int(MININT)), https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1097 ('maxvalue', six.integer_types, int(MAXINT)), https://pagure.io/freeipa/blob/ipa-4-6/f/ipalib/parameters.py#_1098 )
int
On versions which support subid feature, baseid is still defined as an Int= * but with a maxvalue set to Int.MAX_UINT32=3D4294967295* ( https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_223-= 228 ): Int('ipabaseid', <https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_224=
cli_name=3D'base_id', <https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_225= label=3D_("First Posix ID of the range"), <https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_226= minvalue=3D1, <https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_227= maxvalue=3DInt.MAX_UINT32 <https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_228= ),
cli_name=3D'base_id', <https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_225=
label=3D_("First Posix ID of the range"), <https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_226=
minvalue=3D1, <https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_227=
maxvalue=3DInt.MAX_UINT32 <https://pagure.io/freeipa/blob/ipa-4-9/f/ipaserver/plugins/idrange.py#_228=
),
That's why the webui complains on 7.9 but does not on 8.x. This warning can be ignored.
Now about the replica installation that fails: you need to define a baserid and secondary baserid for your existing idranges using ldapmodify: ldapmodify -D cn=3Ddirectory\ manager -w password dn: cn=3DEXAMPLE.COM_posix,cn=3Dranges,cn=3Detc,dc=3Dexample,dc=3Dcom changetype: modify add: ipabaserid ipabaserid: 1000 - add: ipasecondarybaserid ipasecondarybaserid: 100000
dn: cn=3DEXAMPLE.COM_id_range,cn=3Dranges,cn=3Detc,dc=3Dexample,dc=3Dcom changetype: modify add: ipabaserid ipabaserid: 379400000 - add: ipasecondarybaserid ipasecondarybaserid: 379600000
Once they are set, re-try the replication installation and it should not complain any more. When there is only 1 local id range defined, the replica is smart enough to pick a baserid and secondary baserid on its own but if there are multiple local id ranges it aborts and lets the admin pick the right values.
Hope this helps, flo
On Tue, Jul 4, 2023 at 8:18=E2=80=AFAM Harald Dunkel pagure@pagure.io wro= te:
harri added a new comment to an issue you are following: Reading through https://freeipa.readthedocs.io/en/latest/designs/subordinate-ids.html I am confused. If the subID range is as expected, why does ipa complain abo= ut it in the GUI? To reply, visit the link below or just reply to this email https://pagure.io/freeipa/issue/9408
harri added a new comment to an issue you are following: Reading through https://freeipa.readthedocs.io/en/latest/designs/subordinate-ids.html I am confused. If the subID range is as expected, why does ipa complain abo= ut it in the GUI?
Reading through https://freeipa.readthedocs.io/en/latest/designs/subordinate-ids.html I am confused. If the subID range is as expected, why does ipa complain abo= ut it in the GUI?
To reply, visit the link below or just reply to this email https://pagure.io/freeipa/issue/9408
Hi flo, thank you for the detailed answer. I will try the workaround you suggested and ignore the warning in the GUI.
AFAICT it worked. Setting both base RID and secondary base RID for all idranges before running ipa-replica-install was the missing step.
Metadata Update from @harri: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)