Re: Upgrade from 2.4.44 to 2.4.45+
by Quanah Gibson-Mount
--On Monday, July 20, 2020 11:26 PM -0700 rammohan ganapavarapu
<rammohanganap(a)gmail.com> wrote:
> What is the upgrade process from 2.4.44 to 2.4.45 or above? Are there any
> breaking changes that I need to take care before and/or after upgrading?
a) You need to be upgrading to 2.4.50, 2.4.45 has a few CVEs.
b) If you use ppolicy, you will want to reload your database after
upgrading to 2.4.50 due to a database format change for the pwdChangedTime
attribute (I.e., slapcat your db, then slapadd it back in after you're done
with the upgrade).
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
3 years, 4 months
Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul
Hi Quanah
Thank you for the response.
If the consumer is several days behind and the accesslog does not have the
data then fresh reload from the provider will happen automatically?
Thanks
Rahul
On Tue, Jul 14, 2020 at 11:28 AM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
> --On Friday, July 10, 2020 11:04 AM -0400 kumar rahul
> <rahul2002mit(a)gmail.com> wrote:
>
>
> > 1) What is the recommended value for olcSpCheckpoint?
> > As per your blog value is olcSpCheckpoint: 20 10
>
> I prefer to have it checkpoint fairly frequently, which is why I chose
> those values.
>
> > 2) What is the recommended value of olcAccessLogPurge?
> > As per your blog value is olcAccessLogPurge: 01+00:00 00+04:00
>
> So this depends specifically on the environment in question. The more
> data
> retained, the further back a replica can "catch up" to the provider(s) by
> using delta-syncrepl. However, the more data retained, the larger the
> database will be. Whether or not one wants a replica to be able to "catch
> up" to a provider if it is several days behind vs reloading it with a
> fresh
> copy of the db from the provider is the real question.
>
> Regardless of the data retention period, I always suggest a frequent purge
> interval. This is because slapd essentially pauses while a purge is
> ongoing. For most environments, a 4 hour purge interval is not noticable.
> I've gone to as frequent as every 2 hours for extremely active sites.
>
> Regards,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 4 months
what does "mp->mp_pgno != pgno" indicate?
by James Anderson
good afternoon;
i understand from
https://www.openldap.org/lists/openldap-devel/201410/msg00004.html
that one should not expect this to happen, but we observed it today.
mdb.c:2427: Assertion 'mp->mp_pgno != pgno' failed in mdb_page_touch()
Stack trace (most recent call last):
…
#10 Source "../../lib/lmdbxx.h", line 597, in put<dydra::sha1, unsigned int> [0x7f29dcc68690]
#9 Source "../../lib/lmdbxx.h", line 569, in put [0x7f29dcc6856d]
#8 Source "/usr/local/include/lmdb++.h", line 779, in dbi_put [0x7f29dcc5ed42]
#7 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 8985, in mdb_put [0x7f29dcff1b8f]
#6 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 6615, in mdb_cursor_put [0x7f29dcfeef81]
#5 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 6473, in mdb_cursor_touch [0x7f29dcfebd05]
#4 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 5620, in mdb_page_search [0x7f29dcfea70f]
#3 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 2427, in mdb_page_touch [0x7f29dcfea241]
#2 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 1536, in mdb_assert_fail [0x7f29dcff3ac1]
#1 Source "/build/glibc-e6zv40/glibc-2.23/stdlib/abort.c", line 89, in abort [0x7f29daaec039]
#0 Source "../sysdeps/unix/sysv/linux/raise.c", line 54, in raise [0x7f29daaea438]
an attempt to copy with compression fails:
mdb_copy -c /srv/dydra/storage/strings.mdb/ /srv/dydra/backups/strings.bak/
mdb.c:5609: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling()
Aborted
an attempt to dump the problematic sub-database fails:
mdb_dump -s u32:sha1 /srv/dydra/storage/strings.mdb/ > strings-u32:sha1.txt
mdb.c:5685: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
Aborted
has there been any further insight since 2014 into causes?
is there an alternative to restoring the database from a backup?
best regards, from berlin,
3 years, 4 months
invalid credentials when userPassword hash in SSHA-512
by Jehan PROCACCIA
Hello
I realized that userPassword in my openldap directory cannot be validated when hashed in SSHA-512
ldapsearch binds fails (err 49) , shibboleth SSO binding against ldap userPassword also fails
I tried to check the cleartext password against the userPassword field with ApacheDirectoryStudio , here it works .
I changed the password (reseeting the same cleartext one) using SSHA-256 (again in ApacheDirectoryStudio interface) , then ldapsearch bind works !
Is there a problem with SSHA-512 hashed userPassword ? Maybe something one the client or server side must be set to use SSHA-512 ?
Thanks for your advices .
3 years, 4 months
Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul
Thank you Quanah. This helps a lot. Let me make the changes.
Thanks
Rahul
On Mon, Jul 6, 2020 at 5:34 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>
> --On Monday, July 6, 2020 6:21 PM -0400 kumar rahul
> <rahul2002mit(a)gmail.com> wrote:
>
> >
> >
> > Hi Quanah
> >
> >
> > I have some questions from update_config.ldif file
>
> Please don't attach screenshots of text. If you have questions, use text
> email.
>
> In general, however:
>
> One database is used as the main database for the system. Lets call this
> database A.
> One database is used to store the accesslog data (the change deltas). Lets
> call this database B.
> There may be other databases on the system (such as the monitor database).
> Lets call this database C.
>
> Both the syncprov and accesslog *overlays* must be configured on database
> A
> with the appropriate configuration options.
>
> The syncprov overlay must *also* be configured on database B with the
> appropriate (but different) configuration options to indicate it's an
> accesslog DB.
>
> In cn=config, every database has a weight that indicates the order in
> which
> it loads. So:
>
> olcDatabase={1}... is the first DB to get loaded by slapd (Ignoring {-1}
> and {0} which always exist, and are the frontend and config DBs
> respectively).
>
> olcDatabase={2}... would be the second DB to get loaded by slapd
>
> olcDatabase={3}... would be the third DB to get loaded by slapd
>
> Additionally, overlays have weights associated with them to indicate the
> order in which they get loaded. So:
>
> olcOverlay={1}...,olcDatabase={2}... means that this overlay is the first
> one that gets loaded for database #2.
>
> In the EXAMPLE I provided on my blog:
>
> olcDatabase={1} is the monitoring database (database C above)
>
> olcDatabase={2} is the ACCESSLOG database (database B above)
>
> olcDatabase={3} is the MAIN database (database A above)
>
> So which overlays need to apply to which databases depends ENTIRELY ON THE
> ORDER in which they are defined in *YOUR* configuration. You need to make
> adjustments accordingly.
>
> Regards,
> Quanah
>
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 4 months
Q: Added pwdMaxRecordedFailure in pwdPolicy schema
by Ulrich Windl
Hi!
It seems objectclass "pwdPolicy" (1.3.6.1.4.1.42.2.27.8.2.1) got attributetype
"pwdMaxRecordedFailure" (1.3.6.1.4.1.42.2.27.8.1.30) added recently.
Shouldn't the OID of the objectclass change then?
Anyway, how should I upüdate the schema using cn=config?
Regards,
Ulrich
P.S. You can find a similar question at serverfault.com
3 years, 4 months
Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul
Hi Quanah
Thank you for the response.
Can you please provide the details on slapcat and import steps?
Thanks
Rahul
On Wed, Jul 15, 2020 at 11:23 AM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
>
>
> --On Wednesday, July 15, 2020 10:39 AM -0400 kumar rahul
> <rahul2002mit(a)gmail.com> wrote:
>
> >
> >
> > Hi Quanah
> >
> >
> > Thank you for the response.
> >
> > If the consumer is several days behind and the accesslog does not have
> > the data then fresh reload from the provider will happen automatically?
>
> It will fall back to REFRESH mode which has various bugs and the resulting
> DB may be deficient. If you have a consumer that is that far behind, the
> only safe solution is to slapcat the provider and import on the consumer.
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 4 months
Ldap Entry - Invalid syntax (21)
by Koshlendra Singh
Dear Sir/Ma'am,
We are using Openldap for the user authentication, While I am trying to add
the new User entry using:
*ldapvi -D "cn=Manager,dc=punchh,dc=com" -w abxeS3Vxxx*
I am getting this -
*ldap_add: Invalid syntax (21)additional info: objectClass: value #0
invalid per syntax*
Here i am enclosing my ldap user entry
Please give your valuable suggestions to resolve this issue.
Thank you.
3 years, 4 months
