I would like to know the best practice for patching FreeIPA-Server
packages. We generally have daily patching enabled in our servers. Will it
be a good idea to do automatic patching of FreeIPA-Server packages?
If we want to restrict the FreeIPA-Server packages from automatomatic
upgrade and rather keep it for manual upgrade, what are the packages we
should hold back with a version restriction? And how frequently should we
do the manual upgrade? If the FreeIPA-client packages are upgraded
regularly by daily patching(yum-cron or unattended upgrade) will there be
any problem with authentication, if the FreeIPA-Servers are behind version
We have two FreeIPA environments, one with CentOS7 and another with
CentOS8. And we have FreeIPA clients mostly with Ubuntu(18 and 20) and
CentOS (7 and 8).
Any help and guidance is appreciated.
After installing a new replica and running
/usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data
I'm getting this error
keyctl_search: Required key not available
Enter password for Internal Key Storage Token:
Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc473262a90>: Failed to establish a new connection: [Errno 113] No route to host',))
"status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: iparep3.ghs.nl Port: 443"
First, it is asking for a password, and I have no clue for what. I've
tried the admin password and the Directory Manager password. It
makes no difference.
Second, it tries to connect to a replica that was removed several months
ago. Both ipa-replica-manage list and ipa-csreplica-manage show the
correct list of masters that we currently have.
Where does ipa-healthcheck get the information from to query the removed
BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The first two give
this healthcheck error, the centos7 master does not.
I try to make the above combination to work in my environment , and already spent several weeks + open a few threads with different sort of issues. So far, I can say that it works only with workarounds , restarts, clear caches, etc , which is not the setup I can move in production with.
I try to provide the latest update of the setup and the issues I am currently facing:
RedHat Idm with AD trust configured (non-posix)
Default Trust View configured which overrides the UID and GID of the AD users
The UID and GID do exist in Active Directory (the user and group have the same name) , although the group name is in different OU - I do not know if this is an issue or not
On the client, some of the users are resolved, some not. If I manually run getent group <username> before running the id command, it does resolve the group and user. Without running getent group command, sometimes it resolves, sometimes not.
I checked the logs on the client and server and the errors I noticed when running id <username> are:
on the client:
[ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such object(32), (null)
on the server:
[nss] [nss_protocol_fill_initgr] (0x0080): Unable to find primary gid : No such file or directory
It seems to be related to the magical primary GID which seems to be the source of all my issues, but I. have no idea how to fix it (the GID exist in AD and it is defined in the Default Trust View). I am considering even changing settings in AD, but I do not know what should I change.
I tried to define as well all the AD groups (for which I do group override in Default Trust View) in IPA as posix groups with that specific GID . In that situation for some users the lookup failed first time but after the negative cache expired or sssd is restarted the lookup for the user and group works properly (situation was quite similar with the one in the thread https://firstname.lastname@example.org... ).
For AD users which do not have attributes overwritten everything works properly.
After upgrading FreeIPA from F31 to F32, on startup I now see a lot of these errors from certmonger, ns-slapd, java, etc.
May 08 17:57:28 certmonger: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock
May 08 17:57:30 ns-slapd: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock
May 08 17:57:33 dogtag-ipa-renew-agent-submit: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock
May 08 17:57:42 java: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock
The server seems to come up without issue, but can you point me in the right direction to resolve these errors?
I've installed a fresh F32 freeipa-server (on a test domain) and I don't see these errors.
Anthony - https://messinet.com
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
I tried for some time to understand how the cache invalidation works on the clients, and I have to admit that I am even more confused that when I started, therefore I would like to ask if there is someone who can either explain or point me to the relevant documentation.
I'll describe bellow the situation I am currently facing:
- RedHat Idm with AD trust configured (non-posix)
- override the UID of AD users in Idm
- on the clients run the id <username> ; the correct (overwritten ) UID and an auto-generated GID is displayed
- overwrite the GID as well on Idm
- on the clients still the old auto-generated GID is displayed (after sss_cache -E and restart of sssd) when I run id <username>
- remove everything in /var/lib/sss/db , restart sssd and run id <username> - no user found
- getent group <username> - new overwritten GID is displayed
- id <username> displays the correct UID and GID
For the users who are not in cache, restarting sssd seems to be enough (although I did not test if thoroughly).
My question is :
What do I have to do on the client in order to have the latest information from the Idm Override ? Apparently sss_cache -E and restart ssssd is not enough .
Do we always need to remove everything in /var/lib/sss/db in order to have the latest information from the server ?
Recently I discovered that the nameservers of two out the three IPA
masters (replicas) are
not responding with up-to-date information.
Our setup has three masters. Each is configured as nameserver. Most of
the time I use
one as the main master when I modify DNS entries. We also have a DHCP
sends updates to that "main" master.
What I now discovered is that updates are not available when clients use
On all three masters the DNS record is present when I use local
ldapsearch . But with dig
the record is only present on one master.
If I restart the nameserver it then has all records available.
What would be the best method to find out what is wrong?
BTW. There are two things that changed recently. I mention this in case
it rings a bell.
1. one master was re-installed with CentOS 8 Stream. An other CentOS8
master was added
a few weeks ago.
2. our nameservers don't have connection to the Internet any more. So,
root servers cannot
 by local ldapsearch I mean doing a command like this:
ldapsearch -H ldapi://%2fvar%2frun%2f...
We have three masters. One is CentOS 7, the other two are CentOS 8 Stream.
I'm seeing many plugins on the CentOS 7 in cn=plugins,cn=config (about 388
But on the CentOS 8 systems there are very few plugins (about 30 entries).
Is that normal?
BTW. I struggling with nameservers not being updated (see thread:
"dns of two out of three masters not up to date"). I'm not making any
progress with that.
I have a small question, about a new password reseted.
I have into policy password:
Min availability 1 days and max 90 days
That means, if I reset a password, the temporary is available 24h ?
Can you confirm?
FreeIPA : 4.6.5
Bien à vous
Mr Karim Bourenane
+32 493 86 63 54