Re: [Freeipa-users] Fedora 40: new warning in ipa-healthckeck
by Rob Crittenden
Cross-posting this on the 389-users list.
rob
Jochen Kellner via FreeIPA-users wrote:
>
> Hi,
>
> I've upgraded my freeipa server to Fedora 40 (the system was installed
> several releases ago). After the upgrade I get the following new warning
> from ipa-healthcheck:
>
> {
> "source": "ipahealthcheck.ds.backends",
> "check": "BackendsCheck",
> "result": "WARNING",
> "uuid": "875db8e3-029c-46f7-87e5-bf9a216d9637",
> "when": "20240426184431Z",
> "duration": "0.031642",
> "kw": {
> "key": "DSBLE0005",
> "items": [
> "nsslapd-dbcachesize",
> "nsslapd-db-logdirectory",
> "nsslapd-db-transaction-wait",
> "nsslapd-db-checkpoint-interval",
> "nsslapd-db-compactdb-interval",
> "nsslapd-db-compactdb-time",
> "nsslapd-db-transaction-batch-val",
> "nsslapd-db-transaction-batch-min-wait",
> "nsslapd-db-transaction-batch-max-wait",
> "nsslapd-db-logbuf-size",
> "nsslapd-db-page-size",
> "nsslapd-db-locks",
> "nsslapd-db-locks-monitoring-enabled",
> "nsslapd-db-locks-monitoring-threshold",
> "nsslapd-db-locks-monitoring-pause",
> "nsslapd-db-private-import-mem",
> "nsslapd-db-deadlock-policy"
> ],
> "msg": "Found configuration attributes that are not applicable for the configured backend type."
> }
> },
>
> According to
> https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html the
> bdb backend is deprecated. The system was installed with
> 389-ds-base < 1.4.4.9-1.fc33.x86_64 (I see the upgrade to that version
> in /var/log/dnf.rpm.log*. Since 3.0 new installations should use LMBD as
> the backend. Is that true for new installations?
>
> What is the desired action that I should take?
>
> I can remove the options from the dirsrv configuration. Should I?
>
> Shall I switch to lmdb manually? Or is that something that
> ipa-server-upgrade should be doing?
>
> Otherwise I can suppress the message in ipa-healthcheck for now. But I
> guess I should fix my installation before the deprecated support really
> gets dropped... Is deploying a new replica and decommisioning the old
> server we the preferred action?
>
> Jochen
>
2 weeks, 5 days
One way supplier replication is failing on newly installed instance
by tdarby＠arizona.edu
I'm trying to get one-way replication going between a very old (1.3.7.8) server and a newly built (2.5.0 B2024.017.0000) server.
- The initial one-way full replication works.
- Incremental updates from the old to the new work for a time and then start failing with these messages logged on the old server:
[18/Apr/2024:16:10:19.456632850 +0000] - WARN - NSMMReplicationPlugin - send_updates - agmt="cn=eds2prod-eds-ldap-63421-agreement" (eds-ldap-63421:389): Failed to send update operation to consumer (uniqueid 32245001-51c111ea-b1489889-5bf7d8fd, CSN 6620dbb5000400150000): Can't contact LDAP server. Will retry later.
[18/Apr/2024:16:10:19.458134915 +0000] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=eds2prod-eds-ldap-63421-agreement" (eds-ldap-63421:389): Unable to send endReplication extended operation (Can't contact LDAP server)
[18/Apr/2024:16:10:22.471856842 +0000] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=eds2prod-eds-ldap-63421-agreement" (eds-ldap-63421:389): Replication bind with SIMPLE auth resumed
[18/Apr/2024:16:20:22.661249153 +0000] - WARN - NSMMReplicationPlugin - repl5_inc_update_from_op_result - agmt="cn=eds2prod-eds-ldap-63421-agreement" (eds-ldap-63421:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later.
- That set of errors repeats approximately every 2 hours. I'm assuming this has caused replication to halt and it will not resume until it gets passed whatever the issue is.
I was hoping that I could somehow get past this 2 hour retry by disabling and re-enabling the agreement but that seems to have no effect.
Any thoughts on how to attack this?
- Tim
3 weeks, 2 days
Permission of log files
by Julian Kippels
Hi,
I am looking for a way to configure the default permission of the log
files in /var/log/dirsrv/<instance>/*
All the files there belong to dirsrv:dirsrv with the permission of 0600.
I would like to have the default permission to be 0644 so that my
external log-monitoring can access the files.
Julian
1 month
389 DS 2.3.6 on RHEL 9 replication between 2.3.6 and 1.3.9 389DS
by Nazarenko, Alexander
Hello colleagues,
We plan to move our LDAP service from 389DS 1.3.9 on RHEL7 to 389 DS 2.3.6 on RHEL 9 platform.
Question: is it possible to attach a 389 DS 2.3.6 consumer to 389DS 1.3.9 supplier for seamless transition, and get the data replicated in real time?
My first attempt produced an error about different database versions.
Maybe it is not supposed to work?
Thank you,
- Alex
1 month, 1 week
