Crash with SEGV after compacting
by Niklas Schmatloch
Hi
My organisation is using a replicated 389-dirsrv. Lately, it has been crashing
each time after compacting.
It is replicable on our instances by lowering the compactdb-interval to
trigger the compacting:
dsconf -D "cn=Directory Manager" ldap://127.0.0.1 -w 'PASSWORD_HERE' backend config set --compactdb-interval 300
This is the log:
[03/Aug/2022:16:06:38.552781605 +0200] - NOTICE - checkpoint_threadmain - Compacting DB start: userRoot
[03/Aug/2022:16:06:38.752592692 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 8 pages freed
[03/Aug/2022:16:06:44.172233009 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 888 pages freed
[03/Aug/2022:16:06:44.179315345 +0200] - NOTICE - checkpoint_threadmain - Compacting DB start: changelog
[03/Aug/2022:16:13:18.020881527 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact changelog - 458 pages freed
dirsrv(a)auth-alpha.service: Main process exited, code=killed, status=11/SEGV
dirsrv(a)auth-alpha.service: Failed with result 'signal'.
dirsrv(a)auth-alpha.service: Consumed 2d 6h 22min 1.122s CPU time.
The first steps are done very quickly, but the step before the 458 pages of the
retro-changelog are freed, takes several minutes. In this time the dirsrv writes
more than 10 G and reads more than 7 G (according to iotop).
After this line is printed the dirsrv crashes within seconds.
What I also noticed is, that even though it said it freed a lot of pages the
retro-changelog does not seem to change in size.
The file `/var/lib/dirsrv/slapd-auth-alpha/db/changelog/id2entry.db` is 7.2 G
before and after the compacting.
Debian 11.4
389-ds-base/stable,now 1.4.4.11-2 amd64
Does someone have an idea how to debug / fix this?
Thanks
2 months, 2 weeks
Procedure to change the AD used to sync users
by Mihai Carabas
Hello,
We are planning to decommision our current PDC AD (Windows 2012R2). This AD
is also used to sync users from our 389ds instance to this AD. What would
be the correct procedure to update the WinSync agreement? Just update the
hostname and run a full sync?
Thank you,
Mihai Carabas
1 year
389 server logging format
by tdarby＠arizona.edu
Is there a way to customize the access and errors logging formats? In particular, it would be nice to use a more standard timestamp format. If not, is there some Python code available for parsing the logs?
1 year, 1 month
NOTICE - Rust will be mandatory starting in 389-ds-base-2.2
by Mark Reynolds
Hello,
For many years now we have been offering Rust plugins, and for those
that build the server themselves it was possible to disable Rust if it
was not wanted. This is no longer going to be an option starting in the
next release of 389-ds-base-2.2 (On Fedora 37). We are upgrading the
default password storage schema to the Rust password storage scheme
PBKDF2_SHA256 for its improved security and performance over the C/NSS
version (PBKDF2-SHA256). We are also going to be incorporating Rust into
core parts of the server. So leaving Rust optional is no longer going
to be an option.
Sorry for the inconvenience this will impose on people not wanting to
build with Rust, but this is the direction we are moving in with the 389
project.
Feel free to ask any questions or voice concerns over this change, and
we will do our best to address them.
Sincerely,
--
Directory Server Development Team
1 year, 1 month
Re: [EXT]Re: Re: DNA Plugin creating duplicates
by Thierry Bordaz
Hi Todd,
Thanks for your explanations, it make sense.
To make it work, was it enough to add to the definitions
(uidNumber/gidNumber) (usr/share/dirsrv/schema/*) 'ORDERING
integerOrderingMatch'.
Or did you have to add 'nsMatchingRule: integerOrderingMatch' to the
index entry and reindex ?
best regards
thierry
On 8/17/22 5:47 PM, Merritt, Todd R - (tmerritt) wrote:
> Hi Theirry,
>
> It looks like that internal search was failing due to not having the
> appropriate matching rules in place. Once I added the indices it
> started to behave correctly. I guess it's probably a bug that it does
> not indicate that the search failed and/or continues to allocate the
> value without really knowing if it's a duplicate or not.
>
> Thanks,
> Todd
> ------------------------------------------------------------------------
> *From:* Thierry Bordaz <tbordaz(a)redhat.com>
> *Sent:* Wednesday, August 17, 2022 8:30 AM
> *To:* General discussion list for the 389 Directory server project.
> <389-users(a)lists.fedoraproject.org>; Merritt, Todd R - (tmerritt)
> <tmerritt(a)arizona.edu>
> *Subject:* [EXT]Re: [389-users] Re: DNA Plugin creating duplicates
>
> *External Email*
>
> Hi,
>
>
> sorry to be late on that thread. DNA should prevent duplicate values
> via internal searches before allocating. If configured ranges from
> server are separated, DNA should not allocate duplicate. Is it
> possible that a direct update could set the attribute managed by DNA ?
>
>
> regards
> Thierry
>
> On 8/11/22 9:59 PM, Merritt, Todd R - (tmerritt) wrote:
>> Yep, I just tested it out for haha's on my test directory instance
>> after skimming the plugin source and seeing that it actually does
>> does a range search using >=, <=. Sure enough that seems to have
>> resolved it. It did work properly in the current configuration once
>> upon a time so either my directory grew enough that the range search
>> started to time out without the index or the range search was
>> introduced in an update at some point. Thanks for the pointer!
>>
>> Todd
>> ------------------------------------------------------------------------
>> *From:* Patrick M Landry <patrick.landry(a)louisiana.edu>
>> <mailto:patrick.landry@louisiana.edu>
>> *Sent:* Thursday, August 11, 2022 12:55 PM
>> *To:* General discussion list for the 389 Directory server project.
>> <389-users(a)lists.fedoraproject.org>
>> <mailto:389-users@lists.fedoraproject.org>
>> *Subject:* [EXT][389-users] Re: DNA Plugin creating duplicates
>>
>> *External Email*
>>
>> Sorry, I just double checked and I *do* have
>> the integerOrderingMatch Matching Rule configured for uidNumber and
>> gidNumber. I have no idea if that would make a difference for you or not.
>>
>> --
>> Patrick Landry
>> Special Projects Engineer
>> University Computing Support Services
>> University of Louisiana at Lafayette
>> P.O. Box 43621
>> Lafayette, LA 70504
>> (337) 482-6402
>> patrick.landry(a)louisiana.edu <mailto:patrick.landry@louisiana.edu>
>> –––––––––––––––––––––––––
>> Université des Acadiens
>>
>> ------------------------------------------------------------------------
>> *From:* Merritt, Todd R - (tmerritt) <tmerritt(a)arizona.edu>
>> <mailto:tmerritt@arizona.edu>
>> *Sent:* Thursday, August 11, 2022 2:26 PM
>> *To:* General discussion list for the 389 Directory server project.
>> <389-users(a)lists.fedoraproject.org>
>> <mailto:389-users@lists.fedoraproject.org>
>> *Subject:* [389-users] Re: DNA Plugin creating duplicates
>> CAUTION: This email originated from outside of UL Lafayette. Do not
>> click links or open attachments unless you recognize the sender and
>> know the content is safe.
>>
>> Thanks, that's a good thought. It looks like I do have the index set
>> up though.
>>
>> dn: cn=uidnumber,cn=index,cn=userroot,cn=ldbm
>> database,cn=plugins,cn=config
>> cn: uidnumber
>> nsIndexType: eq
>> nsSystemIndex: False
>> objectClass: top
>> objectClass: nsIndex
>>
>> Does the index also need to support nsMatchingRule:
>> integerOrderingMatch for inequality searching?
>>
>> Todd
>> ------------------------------------------------------------------------
>> *From:* Patrick M Landry <patrick.landry(a)louisiana.edu>
>> <mailto:patrick.landry@louisiana.edu>
>> *Sent:* Thursday, August 11, 2022 12:16 PM
>> *To:* General discussion list for the 389 Directory server project.
>> <389-users(a)lists.fedoraproject.org>
>> <mailto:389-users@lists.fedoraproject.org>
>> *Subject:* [EXT][389-users] Re: DNA Plugin creating duplicates
>>
>> *External Email*
>>
>> It has been a long time since I set this up and I am running an older
>> version of the server but I did find this in my notes:
>>
>> Before assigning a number to a new entry theDNAplugin searches
>> the directory to ensure that the number is not already being
>> used. For this reason indexes had to be created for all of the
>> attributes which theDNAplugin can assign values to.
>>
>>
>> Perhaps that is it?
>> --
>> Patrick Landry
>> Special Projects Engineer
>> University Computing Support Services
>> University of Louisiana at Lafayette
>> P.O. Box 43621
>> Lafayette, LA 70504
>> (337) 482-6402
>> patrick.landry(a)louisiana.edu <mailto:patrick.landry@louisiana.edu>
>> –––––––––––––––––––––––––
>> Université des Acadiens
>>
>> ------------------------------------------------------------------------
>> *From:* Merritt, Todd R - (tmerritt) <tmerritt(a)arizona.edu>
>> <mailto:tmerritt@arizona.edu>
>> *Sent:* Thursday, August 11, 2022 12:51 PM
>> *To:* 389-users(a)lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>> <389-users(a)lists.fedoraproject.org>
>> <mailto:389-users@lists.fedoraproject.org>
>> *Subject:* [389-users] DNA Plugin creating duplicates
>> CAUTION: This email originated from outside of UL Lafayette. Do not
>> click links or open attachments unless you recognize the sender and
>> know the content is safe.
>>
>> Hi,
>>
>> I'm running 389ds 2.0.15 on a two node cluster in a multi master
>> mode. I'm using the DNA plugin to generate unique uid numbers for new
>> accounts. Each directory instance is assigned a unique range of uid
>> numbers. It works in so far as it assigns a uid number when it gets
>> the magic token but whatever is supposed to be verifying that the uid
>> number is not already assigned is not working. I've cranked the error
>> log level up, but I don't get anything in the logs that is helpful in
>> determining why that validation is not working correctly.
>>
>> # ansible-managed-uidnumber-generation, Distributed Numeric
>> Assignment Plugin,
>> plugins, config
>> dn: cn=ansible-managed-uidnumber-generation,cn=Distributed Numeric
>> Assignment
>> Plugin,cn=plugins,cn=config
>> objectClass: top
>> objectClass: dnaPluginConfig
>> cn: ansible-managed-uidnumber-generation
>> dnaType: uidNumber
>> dnaNextValue: 62009
>> dnaMaxValue: 131000
>> dnaMagicRegen: generate
>> dnaFilter: (objectclass=posixAccount)
>> dnaScope: ou=Accounts,dc=example,dc=edu
>> dnaSharedCfgDN: ou=ranges,ou=Accounts,dc=example,dc=edu
>>
>> I'm stumped. Anyone have any direction on how to debug this further?
>>
>> Thanks!
>> Todd
>>
>> _______________________________________________
>> 389-users mailing list --389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org>
>> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines>
>> List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fe... <https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...>
>> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue <https://pagure.io/fedora-infrastructure/new_issue>
1 year, 1 month
Re: DNA Plugin creating duplicates
by Thierry Bordaz
Hi,
sorry to be late on that thread. DNA should prevent duplicate values via
internal searches before allocating. If configured ranges from server
are separated, DNA should not allocate duplicate. Is it possible that a
direct update could set the attribute managed by DNA ?
regards
Thierry
On 8/11/22 9:59 PM, Merritt, Todd R - (tmerritt) wrote:
> Yep, I just tested it out for haha's on my test directory instance
> after skimming the plugin source and seeing that it actually does does
> a range search using >=, <=. Sure enough that seems to have resolved
> it. It did work properly in the current configuration once upon a time
> so either my directory grew enough that the range search started to
> time out without the index or the range search was introduced in an
> update at some point. Thanks for the pointer!
>
> Todd
> ------------------------------------------------------------------------
> *From:* Patrick M Landry <patrick.landry(a)louisiana.edu>
> *Sent:* Thursday, August 11, 2022 12:55 PM
> *To:* General discussion list for the 389 Directory server project.
> <389-users(a)lists.fedoraproject.org>
> *Subject:* [EXT][389-users] Re: DNA Plugin creating duplicates
>
> *External Email*
>
> Sorry, I just double checked and I *do* have the integerOrderingMatch
> Matching Rule configured for uidNumber and gidNumber. I have no idea
> if that would make a difference for you or not.
>
> --
> Patrick Landry
> Special Projects Engineer
> University Computing Support Services
> University of Louisiana at Lafayette
> P.O. Box 43621
> Lafayette, LA 70504
> (337) 482-6402
> patrick.landry(a)louisiana.edu
> –––––––––––––––––––––––––
> Université des Acadiens
>
> ------------------------------------------------------------------------
> *From:* Merritt, Todd R - (tmerritt) <tmerritt(a)arizona.edu>
> *Sent:* Thursday, August 11, 2022 2:26 PM
> *To:* General discussion list for the 389 Directory server project.
> <389-users(a)lists.fedoraproject.org>
> *Subject:* [389-users] Re: DNA Plugin creating duplicates
> CAUTION: This email originated from outside of UL Lafayette. Do not
> click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> Thanks, that's a good thought. It looks like I do have the index set
> up though.
>
> dn: cn=uidnumber,cn=index,cn=userroot,cn=ldbm
> database,cn=plugins,cn=config
> cn: uidnumber
> nsIndexType: eq
> nsSystemIndex: False
> objectClass: top
> objectClass: nsIndex
>
> Does the index also need to support nsMatchingRule:
> integerOrderingMatch for inequality searching?
>
> Todd
> ------------------------------------------------------------------------
> *From:* Patrick M Landry <patrick.landry(a)louisiana.edu>
> *Sent:* Thursday, August 11, 2022 12:16 PM
> *To:* General discussion list for the 389 Directory server project.
> <389-users(a)lists.fedoraproject.org>
> *Subject:* [EXT][389-users] Re: DNA Plugin creating duplicates
>
> *External Email*
>
> It has been a long time since I set this up and I am running an older
> version of the server but I did find this in my notes:
>
> Before assigning a number to a new entry theDNAplugin searches the
> directory to ensure that the number is not already being used. For
> this reason indexes had to be created for all of the attributes
> which theDNAplugin can assign values to.
>
>
> Perhaps that is it?
> --
> Patrick Landry
> Special Projects Engineer
> University Computing Support Services
> University of Louisiana at Lafayette
> P.O. Box 43621
> Lafayette, LA 70504
> (337) 482-6402
> patrick.landry(a)louisiana.edu
> –––––––––––––––––––––––––
> Université des Acadiens
>
> ------------------------------------------------------------------------
> *From:* Merritt, Todd R - (tmerritt) <tmerritt(a)arizona.edu>
> *Sent:* Thursday, August 11, 2022 12:51 PM
> *To:* 389-users(a)lists.fedoraproject.org
> <389-users(a)lists.fedoraproject.org>
> *Subject:* [389-users] DNA Plugin creating duplicates
> CAUTION: This email originated from outside of UL Lafayette. Do not
> click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> Hi,
>
> I'm running 389ds 2.0.15 on a two node cluster in a multi master mode.
> I'm using the DNA plugin to generate unique uid numbers for new
> accounts. Each directory instance is assigned a unique range of uid
> numbers. It works in so far as it assigns a uid number when it gets
> the magic token but whatever is supposed to be verifying that the uid
> number is not already assigned is not working. I've cranked the error
> log level up, but I don't get anything in the logs that is helpful in
> determining why that validation is not working correctly.
>
> # ansible-managed-uidnumber-generation, Distributed Numeric Assignment
> Plugin,
> plugins, config
> dn: cn=ansible-managed-uidnumber-generation,cn=Distributed Numeric
> Assignment
> Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: dnaPluginConfig
> cn: ansible-managed-uidnumber-generation
> dnaType: uidNumber
> dnaNextValue: 62009
> dnaMaxValue: 131000
> dnaMagicRegen: generate
> dnaFilter: (objectclass=posixAccount)
> dnaScope: ou=Accounts,dc=example,dc=edu
> dnaSharedCfgDN: ou=ranges,ou=Accounts,dc=example,dc=edu
>
> I'm stumped. Anyone have any direction on how to debug this further?
>
> Thanks!
> Todd
>
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
1 year, 1 month
Re: 389-ds-base/cockpit-389-ds on EL9
by Mark Reynolds
On 8/14/22 11:10 AM, Daniel Bird wrote:
>
> *>>*I will report back any issues as I test.
>
> So far, no major issues. I’ve set up a supplier replica from our
> CentOS 7 service running 1.3.10 from EPEL 7 and all seems well. It did
> require a tweak to some legacy schema files that are still hanging
> round from when we used the “Sun Directory Server” way back in the
> day, that has been the case ever since we moved from the Sun DS server
> and upgraded to 389. At some point I’ll clean up and remove the old
> data from the directory that references them.
>
> I also had a small issue setting the SSL cert via cockpit, where it
> would keep reverting to the self-signed “Server-Cert” .
>
What exactly were you trying to do? Were you trying to change the
server certificate name to a different one?
Thanks,
Mark
> On reflection, it could have been because I was trying to use an
> expired cert, rather than the current one, but it didn’t say there was
> a problem. I set it manually via dse.ldif in the end.
>
> Many thanks
>
> Dan
>
>
> _______________________________________________
> 389-users mailing list --389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fe...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
--
Directory Server Development Team
1 year, 1 month
Re: 389-ds-base/cockpit-389-ds on EL9
by Daniel Bird
>>I will report back any issues as I test.
So far, no major issues. I’ve set up a supplier replica from our CentOS 7 service running 1.3.10 from EPEL 7 and all seems well. It did require a tweak to some legacy schema files that are still hanging round from when we used the “Sun Directory Server” way back in the day, that has been the case ever since we moved from the Sun DS server and upgraded to 389. At some point I’ll clean up and remove the old data from the directory that references them.
I also had a small issue setting the SSL cert via cockpit, where it would keep reverting to the self-signed “Server-Cert” . On reflection, it could have been because I was trying to use an expired cert, rather than the current one, but it didn’t say there was a problem. I set it manually via dse.ldif in the end.
Many thanks
Dan
1 year, 1 month
