freeipa

#9349 Sequence processing failures for group_add using server context
Closed: fixed by frenaud. Opened by twoerner.

Closed: fixed
Reopen Issue

Issue

Issues have been found for group_add sequence processing with server context with the work on https://github.com/freeipa/ansible-freeipa/pull/1001

1) Using group_add in sequence processing to create several groups where one is external, all groups have objectclass ipaexternalgroup, even if external is set to False for the group_add command.
2) After creating a nonposix group, all following group_add calls to add posix groups calls are failing with missing attribute "gidNumber" required by object class "posixGroup"

Reproducer 1 (external)

from ipalib import api, errors
api.bootstrap_with_global_options(context='server')
api.finalize()
if api.env.in_server:
    api.Backend.ldap2.connect()
else:
    api.Backend.rpcclient.connect()
print("Remove 'testgroup1'")
try:
    api.Command["group_del"]("testgroup1")
except errors.NotFound:
    pass
print("Remove 'testgroup2'")
try:
    api.Command["group_del"]("testgroup2")
except errors.NotFound:
    pass
print("Create 'testgroup1' with external=True")
api.Command["group_add"]("testgroup1", external=True)
print("Create 'testgroup2' with external=False")
api.Command["group_add"]("testgroup2", external=False)
result1 = api.Command["group_show"]("testgroup1", all=True)["result"]
print("'testgroup1' userclass: %s" % repr(result1["objectclass"]))
result2 = api.Command["group_show"]("testgroup2", all=True)["result"]
print("'testgroup2' userclass: %s" % repr(result2["objectclass"]))

Reproducer 2 (nonposix)

from ipalib import api, errors
api.bootstrap_with_global_options(context='server')
api.finalize()
if api.env.in_server:
    api.Backend.ldap2.connect()
else:
    api.Backend.rpcclient.connect()
print("Remove 'testgroup1'")
try:
    api.Command["group_del"]("testgroup1")
except errors.NotFound:
    pass
print("Remove 'testgroup2'")
try:
    api.Command["group_del"]("testgroup2")
except errors.NotFound:
    pass
print("Remove 'testgroup3'")
try:
    api.Command["group_del"]("testgroup3")
except errors.NotFound:
    pass
print("Create 'testgroup1' with nonposix=False")
api.Command["group_add"]("testgroup1", nonposix=False)
try:
    print("Create 'testgroup2' with nonposix=True")
    api.Command["group_add"]("testgroup2", nonposix=True)
except Exception as e:
    print(str(e))
try:
    print("Create 'testgroup3' with external=True")
    api.Command["group_add"]("testgroup3", external=True)
except Exception as e:
    print(str(e))

Actual behavior

1) With reproducer 1 all groups are external.

$ python3 external_test.py 
Remove 'testgroup1'
Remove 'testgroup2'
Create 'testgroup1' with external=True
Create 'testgroup2' with external=False
'testgroup1' userclass: ['top', 'groupofnames', 'nestedgroup', 'ipausergroup', 'ipaobject', 'ipaexternalgroup']
'testgroup2' userclass: ['top', 'groupofnames', 'nestedgroup', 'ipausergroup', 'ipaobject', 'ipaexternalgroup', 'posixgroup', 'ipantgroupattrs']

2) Reproducer 2 fails to create posix groups after nonposix group has been created.

$ python3 nonposix_test.py 
Remove 'testgroup1'
Remove 'testgroup2'
Remove 'testgroup3'
Create 'testgroup1' with nonposix=False
Create 'testgroup2' with nonposix=True
missing attribute "gidNumber" required by object class "posixGroup"
Create 'testgroup3' with external=True
missing attribute "gidNumber" required by object class "posixGroup"

2) Reproducer 2 fails to create posix groups after nonposix group has been created.

Expected behavior

No issues.

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
freeipa-server-4.9.9-1.fc36.x86_64
freeipa-client-4.9.9-1.fc36.x86_64
package ipa-server is not installed
package ipa-client is not installed
389-ds-base-2.1.1-2.fc36.x86_64
package pki-ca is not installed
krb5-server-1.19.2-6.fc36.x86_64

Addititional Information

The reproducers are passing using client context.

I think "batch" in this context means calling API commands in sequence. It does not use the batch command. I wonder if the title and description should remove references to batch.

I think "batch" in this context means calling API commands in sequence. It does not use the batch command. I wonder if the title and description should remove references to batch.

I have updated the issue.

PR https://github.com/freeipa/freeipa/pull/6741

ansible-freeipa ipagroup module would need to fail with something like "Your IPA version is lacking a fix to be able to process external or nonposix mixed group handling" if the fix is it currently simply runs into a back trace in the middle of applying the changes.
Therefore I would like to ask for a way to detect that the fix is applied. Version numbers are not good as we can not depend on them for back ports.

Metadata Update from @antorres:
- Issue assigned to antorres

Metadata Update from @antorres:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=2180914

master:

  • 05279ef447fbd3b59d47db51824e410728913064 ipaserver: deepcopy objectclasses list from IPA config

ipa-4-6:

  • 6c9edcf2b1a830b06100f988503388b5022c16cf ipaserver: deepcopy objectclasses list from IPA config

ipa-4-10:

  • b1b7cbc08d96e125ce21113ba1793a592d0ba35a ipaserver: deepcopy objectclasses list from IPA config

ipa-4-9:

  • 62fe608390c41115edf4e356a6cff2ab1a6d0daf ipaserver: deepcopy objectclasses list from IPA config

Metadata Update from @frenaud:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

master:

  • dc8590ef66d2b081ad4949ac5be6c3716d813b1c ipatests: Test for sequence processing failures with server context

ipa-4-9:

  • 6e5c6b1a138c3ead57cb42483f45f364894342e3 ipatests: Test for sequence processing failures with server context

ipa-4-10:

  • 304fd550613e83d120c72f0dad89f6a89d31231c ipatests: Test for sequence processing failures with server context
Metadata
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.