Re: slapd-watcher -i X refreshing unexpectedly...?
Quanah Gibson-Mount wrote: > > > --On Wednesday, September 13, 2023 1:54 PM +0200 cYuSeDfZfb cYuSeDfZfb > wrote: > >> It feels like perhaps there is something wrong in the way the -i X option >> is implemented. > > Please file a report at https://bugs.openldap.org/ No, don't. The tool works correctly. > > --Quanah > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapd-watcher -i X refreshing unexpectedly...?
cYuSeDfZfb cYuSeDfZfb wrote:
> Hi,
>
> We noticed that, when using "slapd-watcher -i X" option to refresh display
> every X seconds, lagging replication statuses are often not cleared, when in
> fact
> replication as already recovered.
>
> In our MMR environment, we often see this for longer periods of time in
> slapd-watcher output :
>
> contextCSN: 20230913104435.605937Z#00#0dd#00 actv@2023-09-13
> 10:44:35, idle@2023-09-13 10:44:37
>
> But when running like this:
> do
> timeout --foreground 1 $SLAPDWATCHER -b $BASE -D $LDAPBINDDN -w $ADMINPW
> "${SERVERURIS[@]}" -s ${SERVERIDS[*]}
> done
>
> the lagging replication lines change back to "idle, sync'd" immediately after
> replication has recovered.
>
> It feels like perhaps there is something wrong in the way the -i X option is
> implemented.
There are no bugs in the slapd-watcher tool. But you must list the server URIs
in ascending order of serverID, and
make sure you provide the list of serverIDs in the matching order. If the list
of SIDs is out of order it won't be
able to compare the CSNs to the correct master.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapd-watcher -i X refreshing unexpectedly...?
--On Wednesday, September 13, 2023 1:54 PM +0200 cYuSeDfZfb cYuSeDfZfb wrote: It feels like perhaps there is something wrong in the way the -i X option is implemented. Please file a report at https://bugs.openldap.org/ --Quanah
Re: assert error + core dump slapd v 2.6.6
--On Wednesday, September 13, 2023 6:19 PM +0200 Frédéric Goudal wrote: Hello, Openldap version 2.6.6 compiled on ubuntu 22.4 LTS For test purpose I'm trying to add an object with objectClass top+person at the root of my openldap (which is not empty), The dn is cn=toto,dc=my,dc=domain When I do something on this object, the slapd server crash, but when restarted the operation has been done. It seems that it is the accelog database that is causing a problem You should file an issue report at https://bugs.openldap.org --Quanah
assert error + core dump slapd v 2.6.6
Hello,
Openldap version 2.6.6 compiled on ubuntu 22.4 LTS
For test purpose I’m trying to add an object with objectClass top+person at the
root of my openldap (which is not empty),
The dn is cn=toto,dc=my,dc=domain
When I do something on this object, the slapd server crash, but when restarted
the operation has been done. It seems that it is the accelog database that is
causing a problem
The error is :
501d0f3.15b397b4 0x7f929fc44700 <= index_entry_add( 5,
"reqStart=20230913151043.00Z,cn=accesslog" ) success
6501d0f3.15b410ee 0x7f929fc44700 => mdb_entry_encode(0x0005):
reqStart=20230913151043.00Z,cn=accesslog
6501d0f3.15b4564d 0x7f929fc44700 <= mdb_entry_encode(0x0005):
reqStart=20230913151043.00Z,cn=accesslog
6501d0f3.15e04a0b 0x7f929fc44700 mdb_add: added id=0005
dn="reqStart=20230913151043.00Z,cn=accesslog"
6501d0f3.15e0bab7 0x7f929fc44700 send_ldap_result: conn=1000 op=12 p=3
6501d0f3.15e0f6a9 0x7f929fc44700 send_ldap_result: err=0 matched="" text=""
6501d0f3.15e1603a 0x7f929fc44700 slap_graduate_commit_csn: removing
0x7f92901234d0 20230913151043.360508Z#00#057#00
6501d0f3.15e1c5a6 0x7f929fc44700 accesslog_response: adding minCSN
20230913151043.360508Z#00#057#00
6501d0f3.15e20736 0x7f929fc44700 accesslog_response: adding a new
csn=20230913151043.360508Z#00#057#00 into minCSN
6501d0f3.15e3a20c 0x7f929fc44700 mdb_modify: cn=accesslog
6501d0f3.15e40781 0x7f929fc44700 mdb_dn2entry("cn=accesslog")
6501d0f3.15e45a2d 0x7f929fc44700 => mdb_dn2id("cn=accesslog")
6501d0f3.15e50b53 0x7f929fc44700 <= mdb_dn2id: got id=0x1
6501d0f3.15e57cc9 0x7f929fc44700 => mdb_entry_decode:
6501d0f3.15e5bb28 0x7f929fc44700 <= mdb_entry_decode
6501d0f3.15e5f9b4 0x7f929fc44700 mdb_modify_internal: 0x0001: cn=accesslog
6501d0f3.15e63487 0x7f929fc44700 <= acl_access_allowed: granted to database root
6501d0f3.15e6881d 0x7f929fc44700 mdb_modify_internal: add minCSN
slapd: attr.c:481: attr_merge: Assertion `( nvals == NULL && (*a)->a_nvals ==
(*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals
== NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) )' failed.
Aborted (core dumped)
Is it a bug ?
f.g.
—
Frédéric Goudal
Ingénieur Système, DSI Bordeaux-INP
+33 556 84 23 11
slapd-watcher -i X refreshing unexpectedly...?
Hi,
We noticed that, when using "slapd-watcher -i X" option to refresh display
every X seconds, lagging replication statuses are often not cleared, when
in fact replication as already recovered.
In our MMR environment, we often see this for longer periods of time in
slapd-watcher output :
contextCSN: 20230913104435.605937Z#00#0dd#00 actv@2023-09-13
10:44:35, idle@2023-09-13 10:44:37
But when running like this:
do
timeout --foreground 1 $SLAPDWATCHER -b $BASE -D $LDAPBINDDN -w
$ADMINPW "${SERVERURIS[@]}" -s ${SERVERIDS[*]}
done
the lagging replication lines change back to "idle, sync'd" immediately
after replication has recovered.
It feels like perhaps there is something wrong in the way the -i X option
is implemented.
For the rest: great tool to have!
Re: regular yum symas-openldap-servers update breaks permissions on /var/symas/openldap-data
On Tue, Sep 12, 2023 at 04:44:15PM +0200, cYuSeDfZfb cYuSeDfZfb wrote: > Hi, > > We're seeing this quite consistently. > > Before updating: > [root@ldaps01 log]# ls -l > /var/symas/ drwx--. 3 ldap ldap 50 Aug 28 16:28 openldap-data > > After updating: > [root@ldaps01 log]# ls -l > /var/symas/ drwx--. 3 root root 50 Aug 28 16:28 openldap-data > > And afterwards symas-openldap-server (running as ldap:ldap) no longer > starts, since permission denied on /var/symas/openldap-data. > > Reverting the permissions back to ldap:ldap solves it. But...WHY is this > happening. > > Are we somehow encouraged to run openldap as root..? > > Why would a post-install script reset permissions on > /var/symas/openldap-data? Hi, openldap-data is owned by the package and as such you'll have to tell rpm somehow (a trigger, ...) that you don't want it to mess with it. AFAIK there's work ongoing to make the directory 711 which should sort things for you. That's unless you're putting the databases directly into /var/symas/openldap-data, we advise you create a subdirectory per DB, e.g. /var/symas/openldap-data/dc=example,dc=com or /var/symas/openldap-data/cn=accesslog. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
