`ipactl restart` fails with `Unknown error when retrieving list of services from LDAP: not enough values to unpack (expected 2, got 1)`
by Andrea Stacchiotti
Hello everyone,
freshly installed ipa server on Oracle Linux 9, via the ansible role at https://github.com/freeipa/ansible-freeipa/blob/master/roles/ipaserver/RE...
The installation goes apparently well, but if I try restarting the service I get the error in the subject, which prevents dirsrv from starting, a debug log is at the end.
This is apparently a known issue, as https://access.redhat.com/solutions/5268961 exists to address it, but I don't have a subscription and I found no other results on the internet.
It seems to be an issue finding services, but `ipa service-find` finds HTTP and ldap as expected.
Can someone help? Thanks
------------
[root@ipa-innovation opc]# ipactl start -d
ipa: DEBUG: importing all plugin modules in ipaserver.plugins...
ipa: DEBUG: importing plugin module ipaserver.plugins.aci
[...]
Starting Directory Service
ipa: DEBUG: Starting external process
ipa: DEBUG: args=['/bin/systemctl', 'start', 'dirsrv(a)PRIVATE-ACUS-EU.service']
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: Starting external process
ipa: DEBUG: args=['/bin/systemctl', 'is-active', 'dirsrv(a)PRIVATE-ACUS-EU.service']
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=active
ipa: DEBUG: stderr=
ipa: DEBUG: wait_for_open_ports: localhost [389] timeout 120
ipa: DEBUG: waiting for port: 389
ipa: DEBUG: SUCCESS: port: 389
ipa: DEBUG: Start of dirsrv(a)PRIVATE-ACUS-EU.service complete
ipa: DEBUG: Starting external process
ipa: DEBUG: args=['/bin/systemctl', 'is-active', 'dirsrv(a)PRIVATE-ACUS-EU.service']
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=active
ipa: DEBUG: stderr=
Failed to read data from service file: Unknown error when retrieving list of services from LDAP: not enough values to unpack (expected 2, got 1)
Shutting down
ipa: DEBUG: Starting external process
ipa: DEBUG: args=['/bin/systemctl', 'stop', 'dirsrv(a)PRIVATE-ACUS-EU.service']
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: Stop of dirsrv(a)PRIVATE-ACUS-EU.service complete
ipa: DEBUG: File "/usr/lib/python3.9/site-packages/ipaserver/install/installutils.py", line 781, in run_script
return_value = main_function()
File "/usr/lib/python3.9/site-packages/ipaserver/install/ipactl.py", line 735, in main
ipa_start(options)
File "/usr/lib/python3.9/site-packages/ipaserver/install/ipactl.py", line 398, in ipa_start
raise IpactlError(rval=e.rval)
ipa: DEBUG: The ipactl command failed, exception: IpactlError:
1 month, 2 weeks
ssh public keys list not updated on the freeipa client
by iulian roman
Hello,
On a FreeIPA setup with AD trust I tried to centralize the ssh public keys of the users in FreeIPA and use the sss_ssh_authorizedkeys in client ssh config in order to retrieve the keys on the clients. I noticed that when the public key of a user is updated or an extra public key is added on the FreeIPA server it does not get refreshed on the client. Removing the cache (sss_cache -E and restart of sssd daemon) did not help. The only thing which helped was to remove the files in /var/lib/sss/db , but that is not feasible to run for hundreds/thounsands of clients whenever some key is updated.
I would like to ask how the pub keys are refreshed/cached/stored and if there is any caching parameter which can be configured to periodically update the cache on the clients or if there is any other method which can make the setup more reliable ?
Best regards,
iulian
1 month, 2 weeks
Is it possible to migrate otp-token from freeipa server to another ipa-server?
by Heo Paul
There are 2 freeipa servers and the servers are not connected.
In the condition, I need to migrate otp-token data from one to another.
But when I tried to use migrate-ds tool to migrate otp-token but I failed.
Is there any way to migrate otp-token?
Plus, how to get the otp-secret for users?
"otptoken-show --all" command does not show the secret of otp-token.
1 month, 2 weeks
high ns-slapd cpu usage after upgrade
by risto hartikainen
Hello people
Could I have advice how to debug why slapd on ipa server is constantly using 15-30% cpu.. this behaviour started on ca master after successful migration from rhel7 to latest rhel 8.9.
There were no problems during migration, there were only 2 ipa nodes to upgrade. Immediately after upgrade everything was fine but after 24 hours ipa server that is also ca master, started using cpu more way more than second ipa server. All ipa related operations and commands are slow but work. Error log for dirsrv is clean. I used crontab to run ipa-backup during night and that is only operation that has happened after migration.
I dont have deeper knowledge about ipa nor ldap so I thought that perhaps fresh replica from second ipa server could help, it didnt. I used ipa-replica-manage re-initialize from other node, no errors with that one but didnt do any good.
After this I tried ipa-replica-manage list-ruv but I am not sure how to interpret result:
[root@ipa user]# ipa-replica-manage list-ruv
Directory Manager password:
Replica Update Vectors:
primary.ipa.server:389: 30
secondary.ipa.server:389: 28
primary.ipa.server:389: 26
Certificate Server Replica Update Vectors:
primary.ipa.server:389: 31
secondary.ipa.server:389: 29
primary.ipa.server:389: 24
primary.ipa.server:389: 23
primary.ipa.server:389: 22
primary.ipa.server:389: 21
primary.ipa.server:389: 18
primary.ipa.server:389: 17
primary.ipa.server:389: 16
[root@ipa user]#
This ipa service setup is old and has had many migrations over the time, starting from rhel6. Does this output mean there are duplicate & obsolete replication agreements? Could this be the reason why slapd is using so much cpu?
Any help is appreciated!
Risto
1 month, 2 weeks
freeipa.py plugin for AWX dynamic inventory not available
by slek kus
Hi, is there a possibility to have the below plugin avialable in Ansible Galaxy FreeIPA collection?
https://github.com/ansible/ansible/blob/stable-2.9/contrib/inventory/free...
Trying to use dynamic inventory by using the plugin. but this is not being included/downloaded with the collection.
I create a dynamic inventory (sourced from project, a git where I have the following folder and file):
inventories/clients_and_controllers.yml, where the contents of the .yml is a single line:
```
plugin: freeipa
```
The collections used are:
```
collections:
- name: freeipa.ansible_freeipa
- name: community.general
```
The error message trying to sync the resource for the dynamic inventory is:
[WARNING]: * Failed to parse
/runner/project/inventories/clients_and_controllers.yml with auto plugin:
inventory config ‘/runner/project/inventories/clients_and_controllers.yml
’
specifies unknown plugin ‘freeipa.py’
Kind regards!
1 month, 2 weeks
Kerberos/IdM and NFS ACLs
by Bo Lind
Hi
I'm trying very hard to find resources for how to set up ACLs on NFS with IdM provided identities.
Things work fine with local users and groups, but the translation service (idmapd?) is causing me trouble.
For reference, I'm running Rocky Linux 8.9 (equivalent to RHEL 8.9).
1 month, 2 weeks
Questions regarding AD Forest integration
by Amos
Our production IPA servers are currently at
ipa-server-4.9.12-11.module+el8.9.0+20824+f2605038.x86_64. (Planning is
underway to migrate to new RHEL 9.3 servers.) We have a 1-way trust
established with AD. All active users are in AD with the POSIX attributes
defined. Overall, this has worked well. However, lately we have been seeing
more incidents where IPA periodically marks the domains in the AD forest as
Disabled, and then accounts cannot get resolved. Not all AD groups have
gidNumber defined, but those groups that are used in the IPA environment
do. I have noticed that some users in these POSIX AD groups do not have the
POSIX attributes. I have a couple broader questions I've never really been
entirely certain about and would like clarification if possible.
1. Is IPA "OK" with some AD groups not having gidNumber defined? It's my
understanding that IPA will just ignore these groups, but I just wanted to
confirm that. I ask because I see in the IPA logs, it is continually
complaining about some AD groups that happen to not have a gidNumber, and I
thought IPA would just ignore these.
2. If an AD group does have gidNumber defined, how well will IPA handle any
group members without POSIX attributes? Will IPA just ignore these users,
or will it be a more serious problem?
3. What's the best way to determine why IPA marks an AD domain as
"Disabled"? We see this frequently happen. Often it will shortly afterward
flip back to "Active", but sometimes that takes much longer. Obviously, if
they are disabled too long, then AD accounts cannot be resolved if they are
no longer in the SSSD cache.
4. Does "Domain resolution order" need to contain *all* the domains in the
AD forest, or only those domains with actual user accounts? I ask because I
see IPA trying all the discovered domains and I know for a fact that those
users/groups are not in those domains.
Thanks,
Amos
1 month, 3 weeks
unable to convert attribute 'cacertificate:binary'
by Antoine Gatineau
Hello,
When enrolling a opensuse tumbleweed client, ipa-client-install fails to
get the cacertificate from ldap with error:
2024-04-30T11:23:16Z DEBUG Initializing principal adminprincipal using
password
2024-04-30T11:23:16Z DEBUG Starting external process
2024-04-30T11:23:16Z DEBUG args=['/usr/bin/kinit', 'adminuser', '-c',
'/tmp/krbcc2swf0edk/ccache']
2024-04-30T11:23:16Z DEBUG Process finished, return code=0
2024-04-30T11:23:16Z DEBUG stdout=Password for adminuser:
2024-04-30T11:23:16Z DEBUG stderr=
2024-04-30T11:23:16Z DEBUG trying to retrieve CA cert via LDAP from
ipa-server-01.empire.lan
2024-04-30T11:23:16Z DEBUG retrieving schema for SchemaCache
url=ldap://ipa-server-01.empire.lan:389
conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f020cb3f490>
2024-04-30T11:23:17Z ERROR unable to convert the attribute
'cacertificate;binary' value
b'0\x82\x04\x.........ETC........................................' to
type <class 'cryptography.x509.base.Certificate'>
2024-04-30T11:23:17Z DEBUG get_ca_certs_from_ldap() error: %i format: a
real number is required, not dict
2024-04-30T11:23:17Z DEBUG %i format: a real number is required, not dict
2024-04-30T11:23:17Z ERROR Cannot obtain CA certificate
'ldap://ipa-server-01.empire.lan' doesn't have a certificate.
2024-04-30T11:23:17Z ERROR Installation failed. Rolling back changes.
ipa server is 4.11.0 (centos stream 9 latest)
ipa client is 4.11.1 (opensuse tumbleweed) from this source:
https://build.opensuse.org/package/show/security%3Aidm/freeipa
With debian 12 and ipa-client 4.9.11 the enrollment succeeds.
With centos stream 9 and ipa-client 4.11.0 the enrollment succeeds.
Is there a limitation with clients newer than the server?
What can I check to fix this issue?
Thank you
1 month, 3 weeks
Login failed due to an unknown reason
by Damola Azeez
Hello All,
I attempted to login to the freeipa Gui to administer a user and i found out i wasn't able to login with any of the freeipa users. checking further, i saw that the certificate expired and didn't renew.
Apache error shows
[Thu May 02 15:10:01.823493 2024] [wsgi:error] [pid 4772:tid 140528850261760] [remote 192.168.101.177:49818] ipapython.ipautil.CalledProcessError: CalledProcessError(Command ['/usr/bin/kinit', '-n', '-c', '/run/ipa/ccaches/armor_4772', '-X', 'X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt', '-X', 'X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem'] returned non-zero exit status 1: 'kinit: Preauthentication failed while getting initial credentials\\n')
while the certmonger status shows
Error obtaining initial credentials: Preauthentication failed.
Error setting up ccache for "host" service on client using default keytab: Preauthentication failed
some other errors I'm seeing are
ipa: INFO: Connection to https://x.x.x/ipa/json failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)
My setup is oracle linux 8.5 with Freeipa version 4.9.6, API_VERSION: 2.245
1 month, 3 weeks
LDAP conflicts after yum update on Almalinux 8.9
by Lee Csk
After performing a usual Yum update's on multiple IPA servers (not at the same time, one server reportedly started hanging), we started observing "LDAP Conflicts" in multiple IPA replication servers:
az2-replica.noc.net
| LDAP Conflicts | 9 | FAIL |
mi2-replica.noc.net:
| LDAP Conflicts | 9 | FAIL |
mi1-replica.noc.net:
| LDAP Conflicts | 9 | FAIL |
az1-replica.noc.net:
| LDAP Conflicts | 10 | FAIL |
sg1-replicate.noc.net:
| LDAP Conflicts | 3 | FAIL |
sg2-replica.noc.net
| LDAP Conflicts | 3 | FAIL |
The "Replication status" while reports OK, we observe also flapping at times between OK and FAIL too.
We have tried to follow on one of the replication servers: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
- by removing the orphan entry, however the replication broke completely on it (ipa service couldn't start back up), requiring a full re-install of that specific replica.
]$ sudo -u admin /home/admin/.local/bin/cipa -H localhost |grep "LDAP Conflicts"
| LDAP Conflicts | 0 | OK |
$ dsconf -D "cn=Directory Manager" ldap://$(hostname) repl-conflict list-glue "dc=noc,dc=net"
Enter password for cn=Directory Manager on ldap://az1-replica.noc.net:
dn: cn=sg1-replica.noc.net,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
cn: sg1-replica.noc.net
ipaLocation: idnsname=singapore,cn=locations,cn=etc,dc=noc,dc=net
ipaMaxDomainLevel: 1
ipaMinDomainLevel: 1
ipaReplTopoManagedSuffix: dc=noc,dc=net
nsds5replconflict: deletedEntryHasChildren
objectClass: top
objectClass: nsContainer
objectClass: ipaReplTopoManagedServer
objectClass: ipaConfigObject
objectClass: ipaSupportedDomainLevelConfig
objectClass: ipalocationmember
objectClass: extensibleobject
objectClass: glue
$ ldapsearch -H ldaps://$(hostname) -W -D 'cn=Directory Manager' '(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))' nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=noc,dc=net> (default) with scope subtree
# filter: (&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))
# requesting: nsds5ReplConflict
#
# sg1-replica.noc.net + 039c4293-257f11ed-a255f732-cfd01100, masters, ipa, etc, noc.net
dn: cn=sg1-replica.noc.net+nsuniqueid=039c4293-257f11ed-a255f732-cfd01100,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
nsds5ReplConflict: namingConflict (ADD) cn=sg1-replica.noc.net,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
# HTTP/mi1-replica.noc.net(a)noc.NET + 0264df8b-fca611ee-a3cba8b9-8a6b8039,services, accounts, noc.net
dn: krbprincipalname=HTTP/mi1-replica.noc.net@NOC.NET+nsuniqueid=0264df8b-fca611ee-a3cba8b9-8a6b8039,cn=services,cn=accounts,dc=noc,dc=net
nsds5ReplConflict: namingConflict (ADD) krbprincipalname=http/mi1-ipaca.noc.net(a)noc.net,cn=services,cn=accounts,dc=noc,dc=net
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
OR:
az1-replica.noc.net:/$ ldapsearch -H ldap://$(hostname) -D "cn=Directory Manager" -W -b "dc=noc,dc=net" "(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))" \* nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=noc,dc=net> with scope subtree
# filter: (&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))
# requesting: * nsds5ReplConflict
#
# sg1-replica.noc.net + 039c4293-257f11ed-a255f732-cfd01100, masters, ipa,
etc, noc.net
dn: cn=sg1-replica.noc.net+nsuniqueid=039c4293-257f11ed-a255f732-cfd01100
,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
ipaLocation: idnsname=singapore,cn=locations,cn=etc,dc=noc,dc=net
objectClass: top
objectClass: nsContainer
objectClass: ipaReplTopoManagedServer
objectClass: ipaConfigObject
objectClass: ipaSupportedDomainLevelConfig
objectClass: ldapsubentry
objectClass: ipalocationmember
cn: sg1-replica.noc.net
ipaReplTopoManagedSuffix: dc=noc,dc=net
ipaMinDomainLevel: 1
ipaMaxDomainLevel: 1
nsds5ReplConflict: namingConflict (ADD) cn=sg1-replica.noc.net,cn=masters
,cn=ipa,cn=etc,dc=noc,dc=net
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
We expect: | LDAP Conflicts | 0 | OK |
Running versions:
ipa-server-4.9.12-14.module_el8.9.0+3785+2238a12a.alma.1.x86_64
ipa-client-4.9.12-14.module_el8.9.0+3785+2238a12a.alma.1.x86_64
389-ds-base-1.4.3.37-2.module_el8.9.0+3710+3183c30a.alma.1.x86_64
krb5-server-1.18.2-26.el8_9.x86_64
The yum update happened from:
ipa-server-4.9.12-11.module_el8.9.0+3715+e4197dc9.alma.1.x86_64
to:
ipa-server-4.9.12-14.module_el8.9.0+3785+2238a12a.alma.1.x86_64
Please advise, how its best to resolve these "LDAP Conflicts".
How to remove, or retain if its the case?
Thanks,
Lee
1 month, 3 weeks
