[389-devel] Please review 4877 entryuuid fixup
https://github.com/389ds/389-ds-base/pull/4878 -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Please review: 4820 cfi
https://github.com/389ds/389-ds-base/pull/4821 -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Please Review: 4817 crypt pw bypass
https://github.com/389ds/389-ds-base/pull/4819 -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Please Review EntryUUID CLI
https://github.com/389ds/389-ds-base/pull/4776 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Re: please review: Issue 4653 - refactor ldbm backend to allow replacement of BDB - phase 3e - dbscan #4709
Hi Jeff, This is a public mailing list - if you no longer wish to receive these mail, you should unsubscribe: "To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org " > On 2 Apr 2021, at 22:13, Jeff Gentry wrote: > > Reviewed what?? I don’t know who you are . > > Jeff Gentry > jgen...@bamawise.com > 205-365-7762 > >> On Apr 2, 2021, at 6:38 AM, Pierre Rogier wrote: >> >> >> FYI: William already reviewed it but would like a second opinion. >> >> https://github.com/389ds/389-ds-base/pull/4709 >> -- >> -- >> >> 389 Directory Server Development Team >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Re: Please have look at One-Time Password password policy
> On 25 Mar 2021, at 17:49, thierry bordaz wrote: > > > > On 3/25/21 3:20 AM, William Brown wrote: >> >>> On 25 Mar 2021, at 12:00, Mark Reynolds wrote: >>> >>> >>> On 3/24/21 8:32 PM, William Brown wrote: >>>>>>> I think maybe it could be easy to visualise it. >>>>>>> >>>>>>> >>>>>>> We have time going from past to future like: >>>>>>> >>>>>>> >>>>>>> past -> future >>>>>>> >>>>>>> >>>>>>> So we want a window of: >>>>>>> >>>>>>> * When can the OTP start to be used? >>>>>>> * When is the OTP no longer able to be used? >>>>>>> >>>>>>> So my thinking is: >>>>>>> >>>>>>> past -> future >>>>>>>^ ^ ^ >>>>>>>| | | >>>>>>>otp created| | >>>>>>>otp valid from | >>>>>>> otp expire at >>>>>>> >>>>>>> >>>>>>> So I would say otp valid from and the otp expire should be *absolute* >>>>>>> date times in UTC. >>>>>>> >>>>>> Hi William >>>>>> >>>>>> Good idea of that graphic. I am sorry to be so slow to understand but >>>>>> still things are not clear. >>>>>> There are the attributes of the password policy and the operational >>>>>> attribute of the user account. >>>>>> >>>>>> I think you meant and I agree with you that operational attributes (in >>>>>> the user account) should be absolute date. >>>>>> What is not clear to me is how to compute those operational attributes >>>>>> from the password policy. >>>>>> I see three options: >>>>>> • password policy contains absolute time (e.g. passwordOTPValidFromUTC) >>>>>> => account.validFrom = policyValidFromUTC >>>>>> • password policy contains a delay after OTP create/reset (e.g. >>>>>> passwordOTPValidFromDelay) => account.validFrom = Now + >>>>>> policyValidFromDelay >>>>>> • password policy contains both and if both are set we should give the >>>>>> priority to one or the other >>>>>> If a password policy is a stable entry, then they should not contain >>>>>> absolute time. If we imagine password policy created on purpose to do a >>>>>> bunch of registration, then that is okay if they contain absolute time. >>>>>> >>>>>> Do you think we should support password policy with absolute time ? >>>>>> >>>>> No we should not store actual times in the config. These time values >>>>> need to live in the entry itself, just like passwordExpirationtime. >>>>> Perhaps this is a good candidate to handle through the CLI (maybe even a >>>>> new task that uses a filter, base, etc)? >>>> I'm a bit confused about this answer but: >>> Theirry thought you wanted to set: >>> >>> >>> dn: cn=config >>> passwordOTPStartTime: 2021034578489754Z >>> >>> >>> But I was saying it should be in the entry, not cn=config, like how we use >>> passwordExpirationtime: >>> >>> >>> uid=mark,dc=example,dc=com >>> passwordOTPStartTime: 2021034578489754Z >> Yep, this is exactly what I meant :) >> >>> >>> Mark >>> >>>> I think there are no "operational" attributes here. These should all be >>>> absolute dates, set on the entry. No calculation or whatever needed. > > Thanks Mark, William for the clarification. > Actually OTP is an extension of the current password policy. So there are new > attribute in the password policy entry and new (operational) attributes in > the account entry. > > I understand and agree that attributes (in the account entry) that represent > a window of validity will be absolute time. > > For example we will
[389-devel] Re: Please have look at One-Time Password password policy
> On 25 Mar 2021, at 12:00, Mark Reynolds wrote: > > > On 3/24/21 8:32 PM, William Brown wrote: >>>>> I think maybe it could be easy to visualise it. >>>>> >>>>> >>>>> We have time going from past to future like: >>>>> >>>>> >>>>> past -> future >>>>> >>>>> >>>>> So we want a window of: >>>>> >>>>> * When can the OTP start to be used? >>>>> * When is the OTP no longer able to be used? >>>>> >>>>> So my thinking is: >>>>> >>>>> past -> future >>>>>^ ^ ^ >>>>>| | | >>>>>otp created| | >>>>>otp valid from | >>>>> otp expire at >>>>> >>>>> >>>>> So I would say otp valid from and the otp expire should be *absolute* >>>>> date times in UTC. >>>>> >>>> Hi William >>>> >>>> Good idea of that graphic. I am sorry to be so slow to understand but >>>> still things are not clear. >>>> There are the attributes of the password policy and the operational >>>> attribute of the user account. >>>> >>>> I think you meant and I agree with you that operational attributes (in the >>>> user account) should be absolute date. >>>> What is not clear to me is how to compute those operational attributes >>>> from the password policy. >>>> I see three options: >>>>• password policy contains absolute time (e.g. passwordOTPValidFromUTC) >>>> => account.validFrom = policyValidFromUTC >>>>• password policy contains a delay after OTP create/reset (e.g. >>>> passwordOTPValidFromDelay) => account.validFrom = Now + >>>> policyValidFromDelay >>>>• password policy contains both and if both are set we should give the >>>> priority to one or the other >>>> If a password policy is a stable entry, then they should not contain >>>> absolute time. If we imagine password policy created on purpose to do a >>>> bunch of registration, then that is okay if they contain absolute time. >>>> >>>> Do you think we should support password policy with absolute time ? >>>> >>> No we should not store actual times in the config. These time values need >>> to live in the entry itself, just like passwordExpirationtime. Perhaps this >>> is a good candidate to handle through the CLI (maybe even a new task that >>> uses a filter, base, etc)? >> I'm a bit confused about this answer but: > > Theirry thought you wanted to set: > > > dn: cn=config > passwordOTPStartTime: 2021034578489754Z > > > But I was saying it should be in the entry, not cn=config, like how we use > passwordExpirationtime: > > > uid=mark,dc=example,dc=com > passwordOTPStartTime: 2021034578489754Z Yep, this is exactly what I meant :) > > > Mark > >> >> I think there are no "operational" attributes here. These should all be >> absolute dates, set on the entry. No calculation or whatever needed. >> >> There is no policy at all. Basicly you just have a mechanic that sets on the >> account that this password is only valid in these time windows, and can only >> be used a maximum number of times. >> >> >> >>> Mark >>> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs, Australia >> > -- > > 389 Directory Server Development Team — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Re: Please have look at One-Time Password password policy
>>> I think maybe it could be easy to visualise it. >>> >>> >>> We have time going from past to future like: >>> >>> >>> past -> future >>> >>> >>> So we want a window of: >>> >>> * When can the OTP start to be used? >>> * When is the OTP no longer able to be used? >>> >>> So my thinking is: >>> >>> past -> future >>>^ ^ ^ >>>| | | >>>otp created| | >>>otp valid from | >>> otp expire at >>> >>> >>> So I would say otp valid from and the otp expire should be *absolute* date >>> times in UTC. >>> >> Hi William >> >> Good idea of that graphic. I am sorry to be so slow to understand but still >> things are not clear. >> There are the attributes of the password policy and the operational >> attribute of the user account. >> >> I think you meant and I agree with you that operational attributes (in the >> user account) should be absolute date. >> What is not clear to me is how to compute those operational attributes from >> the password policy. >> I see three options: >> • password policy contains absolute time (e.g. passwordOTPValidFromUTC) >> => account.validFrom = policyValidFromUTC >> • password policy contains a delay after OTP create/reset (e.g. >> passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay >> • password policy contains both and if both are set we should give the >> priority to one or the other >> If a password policy is a stable entry, then they should not contain >> absolute time. If we imagine password policy created on purpose to do a >> bunch of registration, then that is okay if they contain absolute time. >> >> Do you think we should support password policy with absolute time ? >> > No we should not store actual times in the config. These time values need to > live in the entry itself, just like passwordExpirationtime. Perhaps this is > a good candidate to handle through the CLI (maybe even a new task that uses a > filter, base, etc)? I'm a bit confused about this answer but: I think there are no "operational" attributes here. These should all be absolute dates, set on the entry. No calculation or whatever needed. There is no policy at all. Basicly you just have a mechanic that sets on the account that this password is only valid in these time windows, and can only be used a maximum number of times. > > Mark > — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Re: Please have look at One-Time Password password policy
> On 24 Mar 2021, at 02:12, thierry bordaz wrote:
>
> Hi William
>
> Thanks for you review. Some answers are inlined in the mail below.
>
> On 3/23/21 12:33 AM, William Brown wrote:
>> Hey there,
>>
>> I think that you also need:
>>
>>
>> pwdOTPValidFromTime
>>
>> This way an admin can pre-configure all the OTP's and they only "become
>> valid from" that time frame. IE think university enrollment. You can
>> configure all the OTP's a month before, and they become valid at a specific
>> datetime.
>
> That is a very nice idea. Note to be OTP the 'userpassword' of the account
> must be reset by an admin and the account inheriting password policy with OTP
> settings.
> Assuming 'pwdOTPValidFromTime' is the account operational attribute holding a
> precise time. How should it be computed ? Directly from a precise time set in
> the password policy or computed from a ' 'passwordOTPValidationDelay' (number
> of seconds after OTP reset time) or something else ?
I think maybe it could be easy to visualise it.
We have time going from past to future like:
past -> future
So we want a window of:
* When can the OTP start to be used?
* When is the OTP no longer able to be used?
So my thinking is:
past -> future
^ ^ ^
| | |
otp created| |
otp valid from |
otp expire at
So I would say otp valid from and the otp expire should be *absolute* date
times in UTC.
And then within that otp valid from - expire at time window, we have the "max
use" field of how many times it can be used.
Does that help?
>>
>> I think you should make it consistent with passwordOTPExpDelay to
>> pwdOTPExpDelay. Better, OTP means "one time password" so why is it "password
>> one time password". Just make the attributes "OTPExpDelay" or whatever.
>> Alternately make it pwdOT (password one time).
> ATM password policy ('passwordPolicy') only contains 'password*' attributes
> this is why I would prefer to keep 'passwordOTP*' (e.g. passwordOTPMaxUse,
> passwordOTPExpirationDelay, passwordOTPValidFromTime').
> I agree that 'passwordOTP' looks weird ("password one time password") but the
> first 'password' is the way the password policy attribute are prefixed.
Ahh I think I missed that this is using the userPassword and combined with
passwordPolicy. That makes sense now.
Still better to keep it consistent - all pwd or all password. I think you
mix/match these
>
> Then the account operational attributes updated via password policy. There
> is a mix.
> 6 out of 10 start with 'password' (like 'passwordExpirationTime')
> 2 out of 10 start with 'pwd' (like 'pwdReset')
> The two remaining are 'retryCountResetTime' and 'accountUnlockTime'.
> I choose the 'pwdOTP' prefix because the feature is somehow related to
> 'pwdReset' and also I preferred a different prefix than the password policy.
>>
>> I think passwordOTPExpDelay can be remove if you have ValidFromTime instead.
>
> Why ? Registration should be done after Now+ValidFromTime and before
> Now+passwordOTPExpDelay.
> So the two are useful.
I'd see above :)
>
>>
>>
>> The OC should be named onetimepasswordPolicy instead.
> Do you suggest we have two password policies OC: passwordPolicy and
> OnTimePasswordPolicy.
> OTP relying on 'passwordMustChange' then OnTimePasswordPolicy should allow
> 'passwordMustChange'
Ignore this comment - I think I missed about the passwordPolicy bit :)
>>
>>
>> Hope that helps!
>
> Absolutely it helps a lot. Thanks !
>
> thierry
>>
>>
>>> On 22 Mar 2021, at 21:30, thierry bordaz wrote:
>>>
>>> Hi,
>>>
>>> I wrote a small design [1] about OTP password policy that I would like to
>>> start implementing.
>>> Comments are welcome
>>>
>>> [1] https://www.port389.org/docs/389ds/design/otp-password-policy.html
>>>
>>> best regards
>>> thierry
>>> ___
>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-devel-le...@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.fedora
[389-devel] Re: Please have look at One-Time Password password policy
Hey there, I think that you also need: pwdOTPValidFromTime This way an admin can pre-configure all the OTP's and they only "become valid from" that time frame. IE think university enrollment. You can configure all the OTP's a month before, and they become valid at a specific datetime. I think you should make it consistent with passwordOTPExpDelay to pwdOTPExpDelay. Better, OTP means "one time password" so why is it "password one time password". Just make the attributes "OTPExpDelay" or whatever. Alternately make it pwdOT (password one time). I think passwordOTPExpDelay can be remove if you have ValidFromTime instead. The OC should be named onetimepasswordPolicy instead. Hope that helps! > On 22 Mar 2021, at 21:30, thierry bordaz wrote: > > Hi, > > I wrote a small design [1] about OTP password policy that I would like to > start implementing. > Comments are welcome > > [1] https://www.port389.org/docs/389ds/design/otp-password-policy.html > > best regards > thierry > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Re: 389 DS nightly 2021-03-14 - 95% PASS
You can unsubscribe by following the links at the bottom of these emails. > On 14 Mar 2021, at 20:47, JMM wrote: > > Stop > > Sent from my iPhone > >> On Mar 13, 2021, at 10:29 PM, vashi...@redhat.com wrote: >> >> https://fedorapeople.org/groups/389ds/ci/nightly/2021/03/14/report-389-ds-base-2.0.3-20210314gitd5fdea905.fc33.x86_64.html >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Please review - restart instance after migration from openldap
https://github.com/389ds/389-ds-base/pull/4660 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Re: failed to build rpms
Should we update the contributing/build docs to reflect these steps? > On 24 Feb 2021, at 07:10, Mark Reynolds wrote: > > You have to skip the npm audit check "SKIP_AUDIT_CI=1" for now, and the rust > stuff is a pain and it is hardcoded to be enabled. You always have to update > and download the latest Rust dependencies: > > SKIP_AUDIT_CI=1 make -f rpm.mk update-cargo-dependencies > download-cargo-dependencies rpms > > HTH, > > Mark > > On 2/23/21 1:40 PM, Ludwig Krispenz wrote: >> Hi, >> >> since a long time I was trying to build rpms and failed, here are the issues >> I run into: >> >> 1] problem with npm/audit >> >> I followed the suggestions here: >> https://www.port389.org/docs/389ds/contributing.html (pushd/npm fix/popd), >> but this didn't help, only commenting out audit-ci in >> src/cockpit/389-console/node_modules.mk got me over this >> >> 2] rust >> >> 2.1] >> >> rpm build failed with: >> >> error: failed to get `concread` as a dependency of package `librslapd v0.1.0 >> (/home/elkris/DEV/gh/two/389-ds-base/rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/src/librslapd)` >> >> Caused by: >> failed to load source for dependency `concread` >> >> Caused by: >> Unable to update registry `https://github.com/rust-lang/crates.io-index` >> >> Caused by: >> failed to update replaced source registry >> `https://github.com/rust-lang/crates.io-index` >> >> Caused by: >> failed to read root of directory source: >> /home/elkris/DEV/gh/two/389-ds-base/rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/vendor >> >> Caused by: >> No such file or directory (os error 2) >> make[1]: *** [Makefile:12715: >> .../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/release/librslapd.a] >> Error 101 >> >> >> , >> >> It was right that there wasno rs/rslapd/release/librslapd.a file, not even >> the directory rs existed. After configuring --enable-rust the directory was >> created and populated. >> >> Q1: why does it try to pack rust stuff if it is not enabled ? >> >> 2.2] Now the directory was there, but I still did get the same error. A >> closer look showed that it was looking for >> .../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/release/librslapd.a >> ,but what existed was >> .../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/debug/librslapd.a. >> Note "debug" -- "release". configure was run with --enable-debug >> >> Q2: Is there somewhere a hardcoded/default assumpion of "release" ? in the >> cargo spec? >> >> Thanks for any suggestions >> >> >> Regards, >> >> Ludwig >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure > > -- > > 389 Directory Server Development Team > _______ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Please review: 4591 openldap to ds
https://github.com/389ds/389-ds-base/pull/4607 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review - build fails when xcrypt not found
https://github.com/389ds/389-ds-base/pull/4589 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Deref plugin entries == NULL #4525
> On 14 Jan 2021, at 21:32, Pierre Rogier wrote: > > Hi William, > > > It's a scenario we will need to fix via your BE work because of the MVCC > > transaction model that > > LMDB will force us to adopt :) > > As I see things in the early phases the lmdb read txn will probably only be > managed at the db plugin level rather than at backend level. That means that > we will have the same inconsistency risk than today (i.e as if using bdb and > the implicit txn). > The txn model redesign you are speaking about should only occur in one of the > last phases (once bdb does no more coexists with lmdb). > It must be done because it could provide a serious performance boost for read > operations (IMHO, In most cases we could avoid to duplicate the db data) > But we should not do it while bdb is still around because of the risk of lock > issue and excessive retries. Yep, agreed. It will be needed for a large read performance boost, but just to prevent exactly this kind of issue. We should be able to move to a model where everything is always within a transaction. We could introduce it earlier and have the read txns be a no-op for bdb and continue using the implied transactions that we currently have, but also perhaps there is then no benefit to doing this earlier :) > > Note I put a phasing section in > https://directory.fedoraproject.org/docs/389ds/design/backend-redesign-phase3.html#phasing > explaining that. But I guess I should move it within Ludwig's document that > englobs it. > > Pierre > > On Thu, Jan 14, 2021 at 12:01 AM William Brown wrote: > > > > On 13 Jan 2021, at 21:24, Pierre Rogier wrote: > > > > Thank you Willian, > > So far your scenario (entry found when reading base entry but no more > > existing when computing the candidates) is the only one that matches the > > symptoms. > > It's a scenario we will need to fix via your BE work because of the MVCC > transaction model that LMDB will force us to adopt :) > > > And that triggered a thought: > > We cannot do anything for SUBTREE and ONE_LEVEL searches > > because the fact that the base entry id is not in the candidate may be > > normal > > but IMHO we should improve the BASE search case. > > In this case the candidate list is directly set to the base entry id > > ==> if the candidate entry (in ldbm_back_next_search_entry) is not found > > and the scope is BASE then we should return a LDAP_NO_SUCH_ENTRY error .. > > I suspect that Mark has seen this email and submitted a PR to resolve this > exact case :) > > > > > >Pierre > > > > > > On Wed, Jan 13, 2021 at 1:45 AM William Brown wrote: > > Hey there, > > > > https://github.com/389ds/389-ds-base/pull/4525/files > > > > I had a look and I can see a few possible contributing factors, but without > > a core and the exact state I can't be sure if this is correct. It's all > > just hypothetical from reading the code. > > > > > > The crash is in deref_do_deref_attr() which is called as part of > > deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by > > "./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb, > > SLAPI_PLUGIN_PRE_ENTRY_FN);" > > > > > > I think what's important here is that the search is conducted in > > ./ldap/servers/slapd/opshared.c:818 rc = (*be->be_search)(pb); Is *not* > > in a transaction. That means that while the single search in be_search() is > > consistent due to an implied transaction, the subsequent search in > > deref_pre_entry() is likely conducted in a seperate transaction. This > > allows for other operations to potentially interleave and cause changes - > > modrdn or delete would certainly be candidates to cause a DN to be remove > > between these two points. It would be extremely hard to reproduce as a race > > condition of course. > > > > > > A question you asked is why don't we get a "no such entry" error or > > similar? I think that this is because build_candidate_list in ldbm_search.c > > doesn't actually create an error if the base_candidates list is empty, > > because an IDL is allocated with a value of 0 (no matching entries). this > > allows the search to proceed, and there are no errors, and the result set > > is set to NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in > > this process, but without looking further into it, my suspicion is that > > entries of size 0 WONT return an error condition to internal_search_pb, so > > it's valid for
[389-devel] Re: Deref plugin entries == NULL #4525
> On 13 Jan 2021, at 21:24, Pierre Rogier wrote: > > Thank you Willian, > So far your scenario (entry found when reading base entry but no more > existing when computing the candidates) is the only one that matches the > symptoms. It's a scenario we will need to fix via your BE work because of the MVCC transaction model that LMDB will force us to adopt :) > And that triggered a thought: > We cannot do anything for SUBTREE and ONE_LEVEL searches > because the fact that the base entry id is not in the candidate may be > normal > but IMHO we should improve the BASE search case. > In this case the candidate list is directly set to the base entry id > ==> if the candidate entry (in ldbm_back_next_search_entry) is not found and > the scope is BASE then we should return a LDAP_NO_SUCH_ENTRY error .. I suspect that Mark has seen this email and submitted a PR to resolve this exact case :) > >Pierre > > > On Wed, Jan 13, 2021 at 1:45 AM William Brown wrote: > Hey there, > > https://github.com/389ds/389-ds-base/pull/4525/files > > I had a look and I can see a few possible contributing factors, but without a > core and the exact state I can't be sure if this is correct. It's all just > hypothetical from reading the code. > > > The crash is in deref_do_deref_attr() which is called as part of > deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by > "./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb, > SLAPI_PLUGIN_PRE_ENTRY_FN);" > > > I think what's important here is that the search is conducted in > ./ldap/servers/slapd/opshared.c:818 rc = (*be->be_search)(pb); Is *not* in > a transaction. That means that while the single search in be_search() is > consistent due to an implied transaction, the subsequent search in > deref_pre_entry() is likely conducted in a seperate transaction. This allows > for other operations to potentially interleave and cause changes - modrdn or > delete would certainly be candidates to cause a DN to be remove between these > two points. It would be extremely hard to reproduce as a race condition of > course. > > > A question you asked is why don't we get a "no such entry" error or similar? > I think that this is because build_candidate_list in ldbm_search.c doesn't > actually create an error if the base_candidates list is empty, because an IDL > is allocated with a value of 0 (no matching entries). this allows the search > to proceed, and there are no errors, and the result set is set to NULL with > size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in this process, but > without looking further into it, my suspicion is that entries of size 0 WONT > return an error condition to internal_search_pb, so it's valid for this to be > empty. > > Anyway, again, this is just reading the code for 20 minutes, and is not a > complete in depth investigation, but maybe it's some ideas about what > happened? > > Hope it helps :) > > > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs, Australia > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > > > -- > -- > > 389 Directory Server Development Team > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review 4539 exception in oldap to ds migration
https://github.com/389ds/389-ds-base/pull/4540 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Deref plugin entries == NULL #4525
Hey there, https://github.com/389ds/389-ds-base/pull/4525/files I had a look and I can see a few possible contributing factors, but without a core and the exact state I can't be sure if this is correct. It's all just hypothetical from reading the code. The crash is in deref_do_deref_attr() which is called as part of deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by "./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb, SLAPI_PLUGIN_PRE_ENTRY_FN);" I think what's important here is that the search is conducted in ./ldap/servers/slapd/opshared.c:818 rc = (*be->be_search)(pb); Is *not* in a transaction. That means that while the single search in be_search() is consistent due to an implied transaction, the subsequent search in deref_pre_entry() is likely conducted in a seperate transaction. This allows for other operations to potentially interleave and cause changes - modrdn or delete would certainly be candidates to cause a DN to be remove between these two points. It would be extremely hard to reproduce as a race condition of course. A question you asked is why don't we get a "no such entry" error or similar? I think that this is because build_candidate_list in ldbm_search.c doesn't actually create an error if the base_candidates list is empty, because an IDL is allocated with a value of 0 (no matching entries). this allows the search to proceed, and there are no errors, and the result set is set to NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in this process, but without looking further into it, my suspicion is that entries of size 0 WONT return an error condition to internal_search_pb, so it's valid for this to be empty. Anyway, again, this is just reading the code for 20 minutes, and is not a complete in depth investigation, but maybe it's some ideas about what happened? Hope it helps :) — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review 4520 bounds check on ct->fd population
https://github.com/389ds/389-ds-base/pull/4520 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review: 4517 systemd pin warning cleanup
https://github.com/389ds/389-ds-base/pull/4518 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] please review; 4502
https://github.com/389ds/389-ds-base/pull/4502 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] pls review: calloc of zero
https://github.com/389ds/389-ds-base/pull/4496 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review 4474 cleanup rust linking
https://github.com/389ds/389-ds-base/pull/4474 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review 4472
https://github.com/389ds/389-ds-base/pull/4472 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review 4463 allow lib389 to use system tls reqcert policy
https://github.com/389ds/389-ds-base/pull/4463 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review: openldap pbkdf2 password hashers
https://github.com/389ds/389-ds-base/pull/4457 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review 4454 build caching
https://github.com/389ds/389-ds-base/pull/4455 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Question on cloning and replication . . .
> On 11 Nov 2020, at 12:17, Matthew Harmsen wrote: > > Everyone, > > I received the following from a community member who is using Dogtag and 389: > > I have 2 questions and 1 note. > > Note: > Here is an interesting thing that I noticed during CA cloning: > When CA to be cloned has secure connection DS enabled, cloning process fails. > None of docs: > • https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_Clone > • > https://github.com/dogtagpki/pki/blob/DOGTAG_10_6_BRANCH/docs/installation/Installing_CA_Clone.md > • > https://github.com/dogtagpki/pki/blob/master/docs/installation/ca/Installing_CA_Clone.md > is covering this issue. > Solution here is to use > pki_clone_replication_master_port=389 > pki_clone_replication_clone_port=389 > pki_clone_replication_security=None > https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/server/etc/default.cfg#L255 > > > Question 1 (sorry, bit long): > When CA is cloned both DS servers have nsslapd-referral attribute set in dn: > cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config entries > so DS on vm-users4.hostname.com > would have > dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsslapd-referral: ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA > and DS on vm-users3.hostname.com > dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsslapd-referral: ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA > I wonder what is the meaning of nsslapd-referral attribute? It's so that while the server is "offline" and receiving data, it can redirect clients to other nodes in the topology. > > The reason I'm asking is that I was thinking that for replication over SSL > maybe nsslapd-referral should be modified > from ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA > to ldaps://vm-users4.hostname.com:636/o%3Dpki-tomcat-CA > but when I did this nsslapd-referral attribute was reverted to original value > by DS automatically, > so I'm trying to make sure if nsslapd-referral attribute should be left > unchanged during enabling of SSL to DS replication? > > Just in case here is a sample of all changes on both DS (hopefully, I didn't > miss anything to have properly configured replication over SSL): > vm-users4.hostname.com: > > dn: cn=config > nsslapd-security: on > > dn: cn=RSA,cn=encryption,cn=config > nsSSLPersonalitySSL: slapd-vm-users4 > nsSSLToken: internal (software) > nsSSLActivation: on > > dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsslapd-referral: ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA > > dn: > cn=cloneAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping > tree,cn=config > nsDS5ReplicaPort: 636 > nsDS5ReplicaTransportInfo: SSL > > > vm-users3.hostname.com: > > dn: cn=config > nsslapd-security: on > > dn: cn=RSA,cn=encryption,cn=config > nsSSLPersonalitySSL: slapd-vm-users3 > nsSSLToken: internal (software) > nsSSLActivation: on > > dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsslapd-referral: ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA > > dn: > cn=masterAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping > tree,cn=config > nsDS5ReplicaPort: 636 > nsDS5ReplicaTransportInfo: SSL I'm not sure here, it could be a bug as we should redirect to TLS ports if possible, but I guess it also depends on how the client connects too . Generally a lot of clients don't follow referrals *anyway* so the whole this is a bit moot. > > > Question 2: > DS has so called "SSF Restrictions" > (https://directory.fedoraproject.org/docs/389ds/howto/howto-use-ssf-restrictions.html} > which may be configured by setting nsslapd-minssf attribute in cn=config > entry. > Default value of nsslapd-minssf attribute is 0. W > Minimum SSF configuration setting can be used to define the minimum level of > encryption that is required. > > Do you know what this means? > Should I be concerned? SSF restrictions are a bit of a joke. You probably should leave them alone. They are intended to force connections to require encryption, but they don't actually provide meaningful security improvements since the info disclosures happen *before* the ssf check can kick in due to bind being the first op in any connection. https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html?highlight=minssf A better option if you are security conscious is to set the nsslapd-port to 0 and only use the LDAPS/TLS port (startTLS has similar issues to minssf, and also adds extra latency and should be avoided.). > > By th
[389-devel] Please review 4428 sigsegv in chaining.
https://github.com/389ds/389-ds-base/pull/4434 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review: remove http client plugin
https://github.com/389ds/389-ds-base/pull/4409 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Review Reminder: PRs
https://github.com/389ds/389-ds-base/pulls Hey all, There are quite a few reviews outstanding for a variety of contributors, so it would be great to have these reviewed and making some progress :) Thanks, — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review: openldap password hash import tests
https://github.com/389ds/389-ds-base/pull/4408 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Review Reminders
https://github.com/389ds/389-ds-base/pull/4344 https://github.com/389ds/389-ds-base/pull/4375 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Review Reminder : entryuuid
https://github.com/389ds/389-ds-base/pull/4344 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Mapping tree rework
lues *must* be correct, we just need to guarantee the sorting order and tree assembly. Thanks for the ideas Mark :) > > As of today I'm not comfortable with the current CI tests to ack this patch, > but if we can ramp it up and cover more scenarios it would be a step in the > right direction. This is all just my humble opinion, we are all still just > talking :-) > > Mark > > > — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Mapping tree rework
> On 16 Oct 2020, at 17:48, Pierre Rogier wrote: > > Hi William, > I agree with your architecture points and that is why I said my proposal is a > less appealing trade off. > > My real concern is your last point: > we just do not know and IMHO we are unable to predict what (or if) config > will cause problems, and I am afraid we will only discover it when people > start to complain. > So I still think that the benefit/risk ratio is bad) > I think this wasn't my point. The thing is *any* change will have that "unknown" risk. Our job is to qualify and identify as many of those risks as we can, to remove them as unknowns. Think about the work recently to merge the changelog to the main db, or BDB to LMDB work, even changing from perl to python for installation. These are all significantly larger changes, which would be "much riskier" but all of them have been managed effectively by the team communicating, coordinating, analysing, designing and testing changes. So I really don't accept this "unknown" risk argument. I have laid out a design that explores the configuration, how it works today and how the values are currently trusted, and a process to manage and understand this change in a way to minimise the risk. There are associated tests, and it passes with address sanitiser, and other test cases for mapping trees, replication and others. If we just say "unknown risk" at every change we make we'd never progress. We may as well packup and go home, the project is completed. So I still stand by my design and the PR I have submitted in this case, and if there are concerns about esoteric configurations, then we should identify and understand them too beyond the testing I have already provided. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review: MT suffix building
https://github.com/389ds/389-ds-base/pull/4375 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Roadmap for rust as a requirement in the project
Hi everyone, I'm once again here to bring up my favourite topic, of rust-in-ds. Slow and steady progress has been made, and it would be good to update the situation here. Completed Items are: >> - william -> fix the intentional name leak in the rust slapi plugin >> interface to use lazy_static. Today this triggers LSAN which breaks basic >> test suites. >> - william -> revive and make on upgrade configs better (see above), >> potentially break it out from the v4 plugin patch. Todo Soon: >> - everyone -> test that you can build and run tests with --enable-rust >> --disable-asan in your development environment so that we can work out and >> issues that may exist for us as developers. > I meant to try this again to confirm, but it worked for me a few weeks ago on > Fedora. The build took a lot longer :-( but it worked ;-) >> - william -> clean up libsds linking and some of the related elements >> - william + mark -> check that our respective major distros/releases can >> build with --enable-rust in release rpms > As long as "make -f rpm.mk dist-bz2" does all the cargo building it should > work fine on Fedora and RHEL. Todo a bit later >> - william + viktor -> check that we can pass with --enable-rust and >> --enable-asan, especially in CI >> - anyone interested -> update wiki contributing guide to include rust as a >> requirement >> - (optional) anyone interested (but not william) -> add a section to the >> wiki on using rust in development >> - team -> agree we are happy, and make configure.ac have --enable-rust by >> default >> - team -> after a few weeks / months, remove the ifdefs, duplicate C >> versions of Rust features, and enable/disable features from configure.ac I'm hoping that if we start to look at some of these items sooner, we could think about this for 1.4.4 (?). At the moment the major item for all of us would be to test that we can build in our development environments with rust, as that's a pretty major thing we need to pass for us to continue :) Thanks! — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Mapping tree rework
This has come up because there is a set of customer cases where they have configured it incorrectly, due to bugs in lib389. The issues in lib389 arise from a lack of validation/constraint in the checking of the nsslapd-parent-suffix value in the server, allowing the client to create invalid configurations. So today, our own tools can easily, and trivially cause this situation. One thought is to either document this issue or to fix lib389 - but neither of the actions really fix the underlying problem, which is that our server accepts an invalid configuration silently. So the best thing for us to do is to make it impossible for the server to get it wrong, which means we fix lib389 *and* any other admin tooling/scripts in a single pass. Which is what led to the interest in changing something that has been "working" for a long time :) > On 14 Oct 2020, at 19:47, Ludwig Krispenz wrote: > > Hi, > > you are right that it is possible to configure suffix hierarchies which are > broken, but in my experience this wasn't an issue. people using sub suffixes > did get it right. > > So is there really a need to change something that is working for a long time > ? > > > Regards, > > Ludwig > > > On 14.10.20 08:12, William Brown wrote: >> https://github.com/mreynolds389/389wiki/pull/48 >> >> This is a draft design, and probably of interest to thierry whom I discussed >> this with last night :) >> >> Thanks! >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs, Australia >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Mapping tree rework
https://github.com/mreynolds389/389wiki/pull/48 This is a draft design, and probably of interest to thierry whom I discussed this with last night :) Thanks! — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review : 4372 bindmech not correctly validated in chaining db
https://github.com/389ds/389-ds-base/pull/4374 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review: Template --advanced flag
https://github.com/389ds/389-ds-base/pull/4362 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review: No timeout for CLI imports
https://github.com/389ds/389-ds-base/pull/4359 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review: one line, type error in tlscacertdir check
https://github.com/389ds/389-ds-base/pull/4358 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review: Small usability changes to sssd config generator
https://github.com/389ds/389-ds-base/pull/4354 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review: Clearer warnings if tls cacertdir is not valid in ds* commands
https://github.com/389ds/389-ds-base/pull/4353 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review: Improve warnings re plugin enable
https://github.com/389ds/389-ds-base/pull/4352 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review 4344 entryuuid with syncrepl
https://github.com/389ds/389-ds-base/pull/4344 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Review Reminder: entryuuid fixup correction
https://github.com/389ds/389-ds-base/pull/4328 Reminder to review this please :) — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review: #4328 entryuuid fixup
https://github.com/389ds/389-ds-base/pull/4328 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: 389-ds Migration to GitHub - [2020-09-12 - 2020-09-13]
> On 9 Sep 2020, at 04:21, Simon Pichugin wrote: > > Hi team, > for the last couple of weeks, I was working on the migration tool that will > allow us to switch 389-ds project to GitHub. > > It will be done through the weekend 2020-09-12 - 2020-09-13. > > I was testing it on a custom repo for some time but, please, review the code, > if you would like to: > https://github.com/droideck/patogith/ > > I will open the example 389-ds-base [migrated] repo tomorrow when my final > run will finish. Great, please post a link when done, I'd be happy to look through it. > > I've managed to disable Github notifications but there are two more things > that should be taken into the account: > > 1. Pagure notifications - as Viktor has suggested, probably, we can ask > Pierre-Yves Chibon to do this for us at Friday. > > 2. Bugzilla notifications. It may be that it's not possible to disable it for > everyone involved. In that case, it will be one time thing that will spam you > with 3000 emails. :) But I hope not. I love emails! In general though, great work here Simon. This is a really huge task, so thanks for undertaking it. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review 51260 sync repl possible data corruption
https://pagure.io/389-ds-base/issue/51260 https://pagure.io/389-ds-base/pull-request/51261 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Odd behaviour in import
> On 28 Aug 2020, at 19:23, Ludwig Krispenz wrote: > > > On 27.08.20 04:01, William Brown wrote: >> Hey there, >> >> I'm seeing some odd behaviour in an import test. I'm seeing that a large >> number of entries won't import unless the directory is restarted before the >> import task is performed. >> >> The error appears to be: >> >> [25/Aug/2020:14:14:58.973490600 +1000] - WARN - import_foreman - import >> userRoot: Skipping entry "cn=group0,ou=Groups,dc=example,dc=com" which has >> no parent, ending at line 154 of file >> "/opt/dirsrv/var/lib/dirsrv/slapd-standalone1/ldif/4f8afb8d-ec97-4246-94a2-ec343c0eacb4.ldif" >> ... >> [25/Aug/2020:14:14:59.307477400 +1000] - INFO - bdb_import_main - import >> userRoot: Import complete. Processed 14 entries (10 were skipped) in 1 >> seconds. (14.00 entries/sec) >> >> >> This is where a newly created backend *with* example entries, then has it's >> entire content overwriten during an import. Anything that is underneath the >> ou=* entries is not imported, but the ou= and dc=are fine. >> >> I'm wondering if this is something related to the fact we are replacing the >> ou= entries with different ids/nsunique ids. IE >> >> id 3 >> rdn: ou=groups >> objectClass: top >> objectClass: organizationalunit >> ou: groups >> aci: (targetattr="cn || member || gidNumber || nsUniqueId || >> description || ob >> jectClass")(targetfilter="(objectClass=groupOfNames)")(version 3.0; >> acl "Enab >> le anyone group read"; allow (read, search, >> compare)(userdn="ldap:///anyone;) >> ;) >> aci: >> (targetattr="member")(targetfilter="(objectClass=groupOfNames)")(version >> 3.0; acl "Enable group_modify to alter members"; allow >> (write)(groupdn="ldap: >> ///cn=group_modify,ou=permissions,dc=example,dc=com");) >> aci: (targetattr="cn || member || gidNumber || description || >> objectClass")(ta >> rgetfilter="(objectClass=groupOfNames)")(version 3.0; acl "Enable >> group_admin >>to manage groups"; allow (write, add, >> delete)(groupdn="ldap:///cn=group_admi >> n,ou=permissions,dc=example,dc=com");) >> creatorsName: cn=directory manager >> modifiersName: cn=directory manager >> createTimestamp: 20200827015033Z >> modifyTimestamp: 20200827015033Z >> nsUniqueId: b0fce42b-e80711ea-8141c872-2df18128 >> parentid: 1 >> entryid: 3 >> numSubordinates: 1 >> >> Becomes: >> >> id 4 >> rdn: ou=Groups >> createTimestamp: 20200224023755Z >> creatorsName: cn=Manager,dc=example,dc=com >> entryUUID: 67cc2212-eafa-1039-8830-152569770969 >> modifiersName: cn=Manager,dc=example,dc=com >> modifyTimestamp: 20200224023755Z >> objectClass: organizationalUnit >> objectClass: top >> ou: Groups >> nsUniqueId: 87b64988-e68911ea-a943c898-6d74ab17 >> parentid: 1 >> entryid: 4 >> >> >> Given that these id's are changing I'm wondering if this is somehow breaking >> our import ordering? Any ideas on where I should start to investigate this? > shouldn't the nsuniqueid be preserved ? Otherwise you could not use import to > initilaize a replica. The use case that's happening is that after a backend is setup with sample entries, then you try to restore from a backup or ldif of different origin. So the nsunique and entryid's both could and probably will change in this case. >> >> Thanks! >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] please review fixes to 51177
https://pagure.io/389-ds-base/pull-request/51250 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Odd behaviour in import
Hey there, I'm seeing some odd behaviour in an import test. I'm seeing that a large number of entries won't import unless the directory is restarted before the import task is performed. The error appears to be: [25/Aug/2020:14:14:58.973490600 +1000] - WARN - import_foreman - import userRoot: Skipping entry "cn=group0,ou=Groups,dc=example,dc=com" which has no parent, ending at line 154 of file "/opt/dirsrv/var/lib/dirsrv/slapd-standalone1/ldif/4f8afb8d-ec97-4246-94a2-ec343c0eacb4.ldif" ... [25/Aug/2020:14:14:59.307477400 +1000] - INFO - bdb_import_main - import userRoot: Import complete. Processed 14 entries (10 were skipped) in 1 seconds. (14.00 entries/sec) This is where a newly created backend *with* example entries, then has it's entire content overwriten during an import. Anything that is underneath the ou=* entries is not imported, but the ou= and dc=are fine. I'm wondering if this is something related to the fact we are replacing the ou= entries with different ids/nsunique ids. IE id 3 rdn: ou=groups objectClass: top objectClass: organizationalunit ou: groups aci: (targetattr="cn || member || gidNumber || nsUniqueId || description || ob jectClass")(targetfilter="(objectClass=groupOfNames)")(version 3.0; acl "Enab le anyone group read"; allow (read, search, compare)(userdn="ldap:///anyone;) ;) aci: (targetattr="member")(targetfilter="(objectClass=groupOfNames)")(version 3.0; acl "Enable group_modify to alter members"; allow (write)(groupdn="ldap: ///cn=group_modify,ou=permissions,dc=example,dc=com");) aci: (targetattr="cn || member || gidNumber || description || objectClass")(ta rgetfilter="(objectClass=groupOfNames)")(version 3.0; acl "Enable group_admin to manage groups"; allow (write, add, delete)(groupdn="ldap:///cn=group_admi n,ou=permissions,dc=example,dc=com");) creatorsName: cn=directory manager modifiersName: cn=directory manager createTimestamp: 20200827015033Z modifyTimestamp: 20200827015033Z nsUniqueId: b0fce42b-e80711ea-8141c872-2df18128 parentid: 1 entryid: 3 numSubordinates: 1 Becomes: id 4 rdn: ou=Groups createTimestamp: 20200224023755Z creatorsName: cn=Manager,dc=example,dc=com entryUUID: 67cc2212-eafa-1039-8830-152569770969 modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20200224023755Z objectClass: organizationalUnit objectClass: top ou: Groups nsUniqueId: 87b64988-e68911ea-a943c898-6d74ab17 parentid: 1 entryid: 4 Given that these id's are changing I'm wondering if this is somehow breaking our import ordering? Any ideas on where I should start to investigate this? Thanks! — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review: fix container healthcheck
https://pagure.io/389-ds-base/pull-request/51248 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review - remove intentional string leak in rust
https://pagure.io/389-ds-base/pull-request/51193 https://pagure.io/389-ds-base/issue/51175 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: 389-devel] Advice on a problem (syncrepl + entryuuid)
that not using virtual attributes is a better option here, both in less development time, but also less complexity and less edge cases that could lead to surprises. > And yes, derive nsUniqueId from entryUuid on an Add. Yes, that's what I'm thinking right now. This discussion and time away from the problem has certainly helped me to consider that it's the best way to advance and get a consistent outcome. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Advice on a problem (syncrepl + entryuuid) (William Brown)
> On 23 Jun 2020, at 20:35, Howard Chu wrote: > >> Date: Mon, 22 Jun 2020 15:43:30 +1000 >> From: William Brown >> Subject: [389-devel] Advice on a problem (syncrepl + entryuuid) >> To: "389 Directory server developer discussion." >> <389-devel@lists.fedoraproject.org> >> Message-ID: >> Content-Type: text/plain; charset=utf-8 >> >> Hi all, >> >> I've been a bit stuck on this problem, and I was hoping for some advice or >> thoughts. >> >> So, part of the migration from openldap, and in general, is that we support >> entryuuid. That's all fine. I made a decision to allow entryuuid to diverge >> from nsuniqueid, as entryuuid is often a primary key in many databases. So >> we should be able to bring in entryuuids' that already exist. >> >> This creates a dilema in syncrepl though. Syncrepl currently uses the >> nsuniqueid in place of the entryuuid for sync. It does not appear to be >> straight forward to change this to use entryuuid if it exists - when we send >> a delete, that comes from the retro changelog, and it stores a delete as a >> delete with the nsuniqueid. That also means the entry that held the nsunique >> in question may no longer exist so we cant reference what the entryuuid was. >> >> So this leads me to a problem of "how to solve it". >> >> I still think allowing entryuuid to diverge from nsuniqueid is the right >> call. It opens more scenarioes up to us for migration. > > Just fyi, when replicating from 389DS to OpenLDAP, we directly map nsUniqueId > to entryUuid. They're > both UUIDs and both serve the same purpose on their respective servers, so > why is there > any reason to allow proliferation of other IDs? Ahh I believe that you may be referring to the sundsee syncrepl consumer mode from your 2.5 or git master perhaps? Sadly, this is not the target of my work - if it was, life would be much easier, and this would not be a problem. In this case, we have a customer who wants to create read-only openldap consumers which are able to get data from 389-ds, but they are on version 2.4.41 of openldap which does not appear to perform this mapping from my reading of the code (but i've had some mistakes reading code lately, so perhaps I'm wrong). Their goal is to move from openldap to 389-ds due to support reasons. So this means entryuuid which has been a stable ID for a long time in their fleet is something we need to support - and many external applications do read entryuuid as a primary key to identify objects in the directory, despite the fact it should be an internal replication-only element IMO (vmware and nextcloud come to mind immediately). nsuniqueid (annoyingly) is not the same format as entryuuid, so we can't just ask them to change to reading nsunique (even if the bytes were the same). Every day we get to live with the decisions of the past, and we have the joy of working through and around them. So I think as much as your suggestion is probably correct technically, it doesn't apply in this situation. :( I am considering that the "solution" in this case though, is that when we see an entryuuid on an import/add, we derive nsuniqueid from that, so that entryuuid / nsunique are equivalents in the respective directories, and we can then re-synthesise the entryuuid from nsunique on the syncrepl. We still need to store entryuuid however, because client applications will be expecting it to remain consistent and present during an openldap to 389 migration. Thanks, > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Roadmap for rust as a requirement in the project
> On 16 Jun 2020, at 09:37, Mark Reynolds wrote: > > > On 6/11/20 8:15 PM, William Brown wrote: >> Hi all, >> >> Background: https://pagure.io/389-ds-base/issue/51140 >> >> >> Ludwig and Mark both raised some good points here. First is that features >> today (EntryUUID, LDAPSsoToken) are both locked behind another language. >> Rightly so, they shouldn't be hidden here forever. As well, Mark wants to >> ask what it would take to enable by default. >> >> ** Why did I use the fedse.c to load a plugin entry? >> >> Because we don't (fully) support startup migrations yet. Mark has privately >> reminded me that he has reviewed >> https://pagure.io/389-ds-base/pull-request/49579 and that I should revive >> it. This v4 plugin adds a stateful assertion of entries allowing better >> migrations beyond what fedse.c's bootstrap can achieve. IE we can create an >> entry if it does not exist, and modify it partially if an admin has changed >> it (ie we can tweak defaults but without affecing say pluginEnabled). There >> was an issue viktor raised about pbkdf2 where it could not be disabled, and >> this would resolve it. Most likely, I will break the on startup migrations >> out from the v4 plugin patch set, and make it it's own change, and move some >> of the content from fedse.c and friends into this. >> >> ** TODO list to get rust enabled by default. >> >> I think there is still a bit of work to do to enable by default, but I think >> we are pretty close. Roughly ordered, this is the list of things that has to >> happen to let us enable rust by default. >> >> - everyone -> test that you can build and run tests with --enable-rust >> --disable-asan in your development environment so that we can work out and >> issues that may exist for us as developers. > I meant to try this again to confirm, but it worked for me a few weeks ago on > Fedora. The build took a lot longer :-( but it worked ;-) It'll get quicker with some of the cleanups I want to do, but release builds with rust will be a lot slower due to the fact they can perform more aggressive optimisation because of the stronger type rules AND they can also do stuff like LTO where we don't in 389 atm. https://gcc.gnu.org/wiki/LinkTimeOptimization >> - william -> fix the intentional name leak in the rust slapi plugin >> interface to use lazy_static. Today this triggers LSAN which breaks basic >> test suites. >> - william -> clean up libsds linking and some of the related elements >> - william -> revive and make on upgrade configs better (see above), >> potentially break it out from the v4 plugin patch. >> - william + mark -> check that our respective major distros/releases can >> build with --enable-rust in release rpms > As long as "make -f rpm.mk dist-bz2" does all the cargo building it should > work fine on Fedora and RHEL. Sure, we'll need to test that at some point to be sure. I know it already works in SUSE :) >> - william + viktor -> check that we can pass with --enable-rust and >> --enable-asan, especially in CI >> - anyone interested -> update wiki contributing guide to include rust as a >> requirement >> - (optional) anyone interested (but not william) -> add a section to the >> wiki on using rust in development >> - team -> agree we are happy, and make configure.ac have --enable-rust by >> default >> - team -> after a few weeks / months, remove the ifdefs, duplicate C >> versions of Rust features, and enable/disable features from configure.ac >> >> >> Does this seem reasonable to everyone? I really want to make sure we do this >> right as a team, and we are all happy with it (I don't want a repeat of >> nunc-stans ;) ). If we agree on this, I will open some tickets up, add the >> relevant blocks/ordering and assign out the work. > > Thanks for getting this discussion started! I think we already have most of > this in place to use rust by default today, but we need to do some more > testing, etc. For sure! Also worth noting that don't have to be the one to do all the "william" items, if other people want to step up they can. I need to tidy up this syncrepl stuff and finish up openldap migration stuff, but I think the rust tools will be a valuable part of that openldap migration so I will do it sooner than later :) > > Thanks, > > Mark > >> >> Thank you all! >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> __
[389-devel] Advice on a problem (syncrepl + entryuuid)
Hi all, I've been a bit stuck on this problem, and I was hoping for some advice or thoughts. So, part of the migration from openldap, and in general, is that we support entryuuid. That's all fine. I made a decision to allow entryuuid to diverge from nsuniqueid, as entryuuid is often a primary key in many databases. So we should be able to bring in entryuuids' that already exist. This creates a dilema in syncrepl though. Syncrepl currently uses the nsuniqueid in place of the entryuuid for sync. It does not appear to be straight forward to change this to use entryuuid if it exists - when we send a delete, that comes from the retro changelog, and it stores a delete as a delete with the nsuniqueid. That also means the entry that held the nsunique in question may no longer exist so we cant reference what the entryuuid was. So this leads me to a problem of "how to solve it". I still think allowing entryuuid to diverge from nsuniqueid is the right call. It opens more scenarioes up to us for migration. So some options: * EntryUUID has to be consistent to nsuniqueid, and when we see a create with an entryUuid, we assign the nsunique from the entryuuid we have rather than generating it. If there is no entryuuid, we generate it from the nsuniqueid. * Extend the retrochangelog to store the entryuuid as well as the nsunique for deletes/mods/adds. * Have syncrepl "strip" entryuuid, so that the inconsistent attribute is never sent to clients (but this means that entryuuid between 389 -> syncrepl client diverges, which could have other consequences). * Rather than send the set of deletes, we can send a list of 'what uuids are still present' that implies all others are removed. It's less efficient on the wire, but it works around the problem. (More risk of breaking IPA parts though). * Disallow entryuuid and syncrepl plugins at the same time - you have one or the other (probably good for IPA tbh). * Other thoughts? I'm honestly not sure whats the best choice - they are all tradeoffs in some way or another, with their own risks. So I'd appreciate your advice here. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review 50544 syncrepl fixes
https://pagure.io/389-ds-base/pull-request/51163 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review sle15.2 install error
https://pagure.io/389-ds-base/pull-request/51162 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review 51160 delete ou fails
https://pagure.io/389-ds-base/pull-request/51160 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Roadmap for rust as a requirement in the project
Hi all, Background: https://pagure.io/389-ds-base/issue/51140 Ludwig and Mark both raised some good points here. First is that features today (EntryUUID, LDAPSsoToken) are both locked behind another language. Rightly so, they shouldn't be hidden here forever. As well, Mark wants to ask what it would take to enable by default. ** Why did I use the fedse.c to load a plugin entry? Because we don't (fully) support startup migrations yet. Mark has privately reminded me that he has reviewed https://pagure.io/389-ds-base/pull-request/49579 and that I should revive it. This v4 plugin adds a stateful assertion of entries allowing better migrations beyond what fedse.c's bootstrap can achieve. IE we can create an entry if it does not exist, and modify it partially if an admin has changed it (ie we can tweak defaults but without affecing say pluginEnabled). There was an issue viktor raised about pbkdf2 where it could not be disabled, and this would resolve it. Most likely, I will break the on startup migrations out from the v4 plugin patch set, and make it it's own change, and move some of the content from fedse.c and friends into this. ** TODO list to get rust enabled by default. I think there is still a bit of work to do to enable by default, but I think we are pretty close. Roughly ordered, this is the list of things that has to happen to let us enable rust by default. - everyone -> test that you can build and run tests with --enable-rust --disable-asan in your development environment so that we can work out and issues that may exist for us as developers. - william -> fix the intentional name leak in the rust slapi plugin interface to use lazy_static. Today this triggers LSAN which breaks basic test suites. - william -> clean up libsds linking and some of the related elements - william -> revive and make on upgrade configs better (see above), potentially break it out from the v4 plugin patch. - william + mark -> check that our respective major distros/releases can build with --enable-rust in release rpms - william + viktor -> check that we can pass with --enable-rust and --enable-asan, especially in CI - anyone interested -> update wiki contributing guide to include rust as a requirement - (optional) anyone interested (but not william) -> add a section to the wiki on using rust in development - team -> agree we are happy, and make configure.ac have --enable-rust by default - team -> after a few weeks / months, remove the ifdefs, duplicate C versions of Rust features, and enable/disable features from configure.ac Does this seem reasonable to everyone? I really want to make sure we do this right as a team, and we are all happy with it (I don't want a repeat of nunc-stans ;) ). If we agree on this, I will open some tickets up, add the relevant blocks/ordering and assign out the work. Thank you all! — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Docker updated
https://hub.docker.com/repository/docker/389ds/dirsrv This update resolves the restart issues we were seeing sometimes, so I think this is getting closer to "general use" :) Thanks everyone! — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Add rfc2079 labled uri schema
https://pagure.io/389-ds-base/pull-request/51130 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Review Reminder
Hi, I have the following PR's that have been open and I'd appreciate if you could review them: https://pagure.io/389-ds-base/pull-request/50970 https://pagure.io/389-ds-base/pull-request/51073 https://pagure.io/389-ds-base/pull-request/51090 https://pagure.io/389-ds-base/pull-request/51126 Thanks! — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review samba ldif status
https://pagure.io/389-ds-base/pull-request/51126 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review 51090 (rfc2307compat)
Lets try again shall we? https://pagure.io/389-ds-base/pull-request/51090 https://pagure.io/389-ds-base/issue/50933 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: tests take minutes to start
> On 13 May 2020, at 20:20, Viktor Ashirov wrote: > > On Wed, May 13, 2020 at 12:05 PM William Brown wrote: >> >> It's due to the way that docker for mac works, the IO pipe to the container >> is via the CPU path, so anything that needs a grep like this will take a >> long time. > OK, that's why I asked about 'other OS' :) The 'other' OS is good, you should join me ... I did consider porting 389-ds to run natively though > Have you tried mounting volumes via nfsmount [1]? I have, and I really don't want to run NFS on this machine is really what it came to. Normally it's not a problem. > In the meantime, I'm working on integrating pre-commit [2] and various > linters/checkers for lib389. I think we can add another hook that will > generate markers for pytest.ini. That might help :) In the mean time if it annoys me a lot, I can always just push branches to my test server and run there. Just was wondering if it was known or expected as a change. :) > > [1] > https://www.jeffgeerling.com/blog/2020/revisiting-docker-macs-performance-nfs-volumes > [2] https://pre-commit.com/ >> >>> On 13 May 2020, at 17:15, Viktor Ashirov wrote: >>> >>> On Wed, May 13, 2020 at 9:13 AM William Brown wrote: >>>> >>>> >>>> >>>>> On 13 May 2020, at 17:01, Viktor Ashirov wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Wed, May 13, 2020 at 8:31 AM William Brown wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I noticed today that my tests now take minutes to start executing. It >>>>>> looks like it's spinning on: >>>>>> >>>>>> dirsrv 84605 12.8 0.1 16672 7704 pts/0S+ 16:25 0:08 grep >>>>>> -rh ^@pytest.mark.\(ds\|bz\)[0-9]\+ >>>>>> >>>>>> Do we know anything about this? Did we add something in a fixture or >>>>>> something to grep for tests? That kind of pattern does look like our >>>>>> bz/ds here, so I suspect it comes from us. >>>>> It is this change: >>>>> https://pagure.io/389-ds-base/c/6a7a154159583c09fcbba0578eaf576d577ccb11?branch=master >>>>> But for me on Fedora it doesn't take minutes: >>>>> $ time grep -rh ^@pytest.mark.\(ds\|bz\)[0-9]\+ >>>>> >>>>> real 0m0.144s >>>>> user 0m0.093s >>>>> sys 0m0.050s >>>>> >>>>> How are you running your tests? Is it on OpenSUSE or some other OS? >>>> >>>> It's a known IO performance issue inside of docker. >>> Do you mount a volume with git/tests inside of the container or it's >>> in the container FS itself? >>>> >>>>> Thanks. >>>>>> >>>>>> >>>>>> >>>>>> — >>>>>> Sincerely, >>>>>> >>>>>> William Brown >>>>>> >>>>>> Senior Software Engineer, 389 Directory Server >>>>>> SUSE Labs >>>>>> ___ >>>>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >>>>>> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org >>>>> >>>>> >>>>> >>>>> -- >>>>> Viktor >>>>> ___ >>>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >>>>> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org >>>> >>>> — >>>> Sincerely, >>>> >>>> William Brown >>>> >>>> Senior Software Engineer, 389 Directory Server >>>> SUS
[389-devel] Re: tests take minutes to start
It's due to the way that docker for mac works, the IO pipe to the container is via the CPU path, so anything that needs a grep like this will take a long time. > On 13 May 2020, at 17:15, Viktor Ashirov wrote: > > On Wed, May 13, 2020 at 9:13 AM William Brown wrote: >> >> >> >>> On 13 May 2020, at 17:01, Viktor Ashirov wrote: >>> >>> Hi, >>> >>> On Wed, May 13, 2020 at 8:31 AM William Brown wrote: >>>> >>>> Hi all, >>>> >>>> I noticed today that my tests now take minutes to start executing. It >>>> looks like it's spinning on: >>>> >>>> dirsrv 84605 12.8 0.1 16672 7704 pts/0S+ 16:25 0:08 grep -rh >>>> ^@pytest.mark.\(ds\|bz\)[0-9]\+ >>>> >>>> Do we know anything about this? Did we add something in a fixture or >>>> something to grep for tests? That kind of pattern does look like our bz/ds >>>> here, so I suspect it comes from us. >>> It is this change: >>> https://pagure.io/389-ds-base/c/6a7a154159583c09fcbba0578eaf576d577ccb11?branch=master >>> But for me on Fedora it doesn't take minutes: >>> $ time grep -rh ^@pytest.mark.\(ds\|bz\)[0-9]\+ >>> >>> real 0m0.144s >>> user 0m0.093s >>> sys 0m0.050s >>> >>> How are you running your tests? Is it on OpenSUSE or some other OS? >> >> It's a known IO performance issue inside of docker. > Do you mount a volume with git/tests inside of the container or it's > in the container FS itself? >> >>> Thanks. >>>> >>>> >>>> >>>> — >>>> Sincerely, >>>> >>>> William Brown >>>> >>>> Senior Software Engineer, 389 Directory Server >>>> SUSE Labs >>>> ___ >>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >>>> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org >>> >>> >>> >>> -- >>> Viktor >>> ___ >>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >>> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > > > > -- > Viktor > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: tests take minutes to start
> On 13 May 2020, at 17:01, Viktor Ashirov wrote: > > Hi, > > On Wed, May 13, 2020 at 8:31 AM William Brown wrote: >> >> Hi all, >> >> I noticed today that my tests now take minutes to start executing. It looks >> like it's spinning on: >> >> dirsrv 84605 12.8 0.1 16672 7704 pts/0S+ 16:25 0:08 grep -rh >> ^@pytest.mark.\(ds\|bz\)[0-9]\+ >> >> Do we know anything about this? Did we add something in a fixture or >> something to grep for tests? That kind of pattern does look like our bz/ds >> here, so I suspect it comes from us. > It is this change: > https://pagure.io/389-ds-base/c/6a7a154159583c09fcbba0578eaf576d577ccb11?branch=master > But for me on Fedora it doesn't take minutes: > $ time grep -rh ^@pytest.mark.\(ds\|bz\)[0-9]\+ > > real 0m0.144s > user 0m0.093s > sys 0m0.050s > > How are you running your tests? Is it on OpenSUSE or some other OS? It's a known IO performance issue inside of docker. > Thanks. >> >> >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > > > > -- > Viktor > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] tests take minutes to start
Hi all, I noticed today that my tests now take minutes to start executing. It looks like it's spinning on: dirsrv 84605 12.8 0.1 16672 7704 pts/0S+ 16:25 0:08 grep -rh ^@pytest.mark.\(ds\|bz\)[0-9]\+ Do we know anything about this? Did we add something in a fixture or something to grep for tests? That kind of pattern does look like our bz/ds here, so I suspect it comes from us. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review 51084 containers
https://pagure.io/389-ds-base/pull-request/51084 resolves: https://pagure.io/389-ds-base/issue/51079 https://pagure.io/389-ds-base/issue/51080 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Slapi Entry duplication observation
40, > attrs=0x0, ret_entry=0x7fc8825faa68, component_identity=0x7fc8ac6985e0) > at ../389-ds-base/ldap/servers/slapd/plugin_internal_op.c:873 > #2 0x7fc8ac4ca221 in mep_pre_op (pb=0x7fc880bff000, modop=4) at > ../389-ds-base/ldap/servers/plugins/mep/mep.c:2169 > #3 0x7fc8ac4ca64f in mep_mod_pre_op (pb=0x7fc880bff000) at > ../389-ds-base/ldap/servers/plugins/mep/mep.c:2303 > #4 0x7fc8b061ed1c in plugin_call_func (list=0x7fc8ac6c3e00, > operation=461, pb=0x7fc880bff000, call_one=0) at > ../389-ds-base/ldap/servers/slapd/plugin.c:2030 > #5 0x7fc8b061eb85 in plugin_call_list (list=0x7fc8aef6fe00, > operation=461, pb=0x7fc880bff000) at > ../389-ds-base/ldap/servers/slapd/plugin.c:1973 > #6 0x7fc8b061b912 in plugin_call_plugins (pb=0x7fc880bff000, > whichfunction=461) at ../389-ds-base/ldap/servers/slapd/plugin.c:442 > #7 0x7fc8ac53b87c in ldbm_back_modify (pb=0x7fc880bff000) at > ../389-ds-base/ldap/servers/slapd/back-ldbm/ldbm_modify.c:687 > #8 0x7fc8b0604eba in op_shared_modify (pb=0x7fc880bff000, pw_change=0, > old_pw=0x0) at ../389-ds-base/ldap/servers/slapd/modify.c:1021 > #9 0x7fc8b06033bb in do_modify (pb=0x7fc880bff000) at > ../389-ds-base/ldap/servers/slapd/modify.c:380 > #10 0x00418c63 in connection_dispatch_operation (conn=0x7fc8a7acfa50, > op=0x7fc8ac85a000, pb=0x7fc880bff000) > at ../389-ds-base/ldap/servers/slapd/connection.c:624 > #11 0x0041ad49 in connection_threadmain () at > ../389-ds-base/ldap/servers/slapd/connection.c:1753 > #12 0x7fc8b00eeb34 in _pt_root () from target:/lib64/libnspr4.so > #13 0x7fc8b00834e2 in start_thread () from target:/lib64/libpthread.so.0 > #14 0x7fc8afea26a3 in clone () from target:/lib64/libc.so.6 > > > #0 slapi_entry_dup (e=0x7fc880c68180) at > ../389-ds-base/ldap/servers/slapd/entry.c:1997 > #1 0x7fc8ac53bfb6 in ldbm_back_modify (pb=0x7fc880bff000) at > ../389-ds-base/ldap/servers/slapd/back-ldbm/ldbm_modify.c:844 > #2 0x7fc8b0604eba in op_shared_modify (pb=0x7fc880bff000, pw_change=0, > old_pw=0x0) at ../389-ds-base/ldap/servers/slapd/modify.c:1021 > #3 0x7fc8b06033bb in do_modify (pb=0x7fc880bff000) at > ../389-ds-base/ldap/servers/slapd/modify.c:380 > #4 0x00418c63 in connection_dispatch_operation (conn=0x7fc8a7acfa50, > op=0x7fc8ac85a000, pb=0x7fc880bff000) > at ../389-ds-base/ldap/servers/slapd/connection.c:624 > #5 0x0041ad49 in connection_threadmain () at > ../389-ds-base/ldap/servers/slapd/connection.c:1753 > #6 0x7fc8b00eeb34 in _pt_root () from target:/lib64/libnspr4.so > #7 0x7fc8b00834e2 in start_thread () from target:/lib64/libpthread.so.0 > #8 0x7fc8afea26a3 in clone () from target:/lib64/libc.so.6 > > > -- > > 389 Directory Server Development Team > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please Review: 51072 improve autotune
https://pagure.io/389-ds-base/pull-request/51073 https://pagure.io/389-ds-base/issue/51072 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Is there going to be a console for RHEL/CentOS 8?
Does the backend exist? dsconf backend suffix list > On 5 May 2020, at 08:39, Jorge F. Hernandez wrote: > > Well, I did try this: > > dsidm -b "dc=example,dc=com" -D "cn=Directory Manager" initialise > Enter password for cn=Directory Manager on ldap://localhost:389: > > Bur after putting the password, I get this: > > Error: No such object > > I also get the same error when I try to create a new user using dsidm and > dsctl status shows as running, I even deleted the instance and try > to recreate it using cockpit and I checked to include sample data in it, but > nothing shows up. > > Any other ideas? > > Thanks. > > > === > Jorge F. Hernandez > > > On Mon, May 4, 2020 at 5:59 PM William Brown wrote: > > > > On 5 May 2020, at 05:46, Jorge F. Hernandez wrote: > > > > Thank you for that, another question, now that I can see my 389 Directory > > Server, all I see id my base DN, dc=example,dc=com but nothing else, it > > shows empty, no OUs, no nothing, how can I populate it with the default > > schema of a Directory Server (Users, Computers, etc.) > > If you have a blank backend, you can populate it with sample entries with > "dsidm initialise". Have a look at this quickstart for the > dsrc setup > > http://www.port389.org/docs/389ds/howto/quickstart.html > > Hope that helps, > > > > > > > > > > Jorge F. Hernandez > > > > -Original Message- > > From: William Brown > > Sent: Sunday, May 3, 2020 6:54 PM > > To: 389 Directory server developer discussion. > > <389-devel@lists.fedoraproject.org> > > Subject: [389-devel] Re: Is there going to be a console for RHEL/CentOS 8? > > > > > > > >> On 4 May 2020, at 04:08, Jorge F. Hernandez wrote: > >> > >> Hello, > >> > >> I just installed 389 to a CentOS 8 using the instructions from your > >> website (yum module), but I cannot find an admin/management tool for it, > >> before there used to be a console or an admin web site, but I don’t see it > >> anymore, any ideas if this is going to be available in the future? > >> > >> I can see the 389 Directory Server in the cockpit, but there is no way to > >> add/edit users/groups on it. > > > > We've been talking about adding a seperate web based tool for this, but > > currently it's early stages. For now you'll have to use apache directory > > studio, the dsidm command line, or another ldap editor. Sorry about that :( > > > > > >> > >> Thanks, > >> > >> > >> > >> Jorge F. Hernandez > >> > >> ___ > >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org To > >> unsubscribe send an email to 389-devel-le...@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-devel@lists.fedorapr > >> oject.org > > > > — > > Sincerely, > > > > William Brown > > > > Senior Software Engineer, 389 Directory Server SUSE Labs > > ___ > > 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe > > send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > > ___ > > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > ___ > 389-devel mailing list -- 389-devel@lists.fedorap
[389-devel] Re: Is there going to be a console for RHEL/CentOS 8?
> On 5 May 2020, at 05:46, Jorge F. Hernandez wrote: > > Thank you for that, another question, now that I can see my 389 Directory > Server, all I see id my base DN, dc=example,dc=com but nothing else, it shows > empty, no OUs, no nothing, how can I populate it with the default schema of a > Directory Server (Users, Computers, etc.) If you have a blank backend, you can populate it with sample entries with "dsidm initialise". Have a look at this quickstart for the dsrc setup http://www.port389.org/docs/389ds/howto/quickstart.html Hope that helps, > > > > Jorge F. Hernandez > > -----Original Message- > From: William Brown > Sent: Sunday, May 3, 2020 6:54 PM > To: 389 Directory server developer discussion. > <389-devel@lists.fedoraproject.org> > Subject: [389-devel] Re: Is there going to be a console for RHEL/CentOS 8? > > > >> On 4 May 2020, at 04:08, Jorge F. Hernandez wrote: >> >> Hello, >> >> I just installed 389 to a CentOS 8 using the instructions from your website >> (yum module), but I cannot find an admin/management tool for it, before >> there used to be a console or an admin web site, but I don’t see it anymore, >> any ideas if this is going to be available in the future? >> >> I can see the 389 Directory Server in the cockpit, but there is no way to >> add/edit users/groups on it. > > We've been talking about adding a seperate web based tool for this, but > currently it's early stages. For now you'll have to use apache directory > studio, the dsidm command line, or another ldap editor. Sorry about that :( > > >> >> Thanks, >> >> >> >> Jorge F. Hernandez >> >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org To >> unsubscribe send an email to 389-devel-le...@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-devel@lists.fedorapr >> oject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server SUSE Labs > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe > send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Is there going to be a console for RHEL/CentOS 8?
> On 4 May 2020, at 04:08, Jorge F. Hernandez wrote: > > Hello, > > I just installed 389 to a CentOS 8 using the instructions from your website > (yum module), but I cannot find an admin/management tool for it, before there > used to be a console or an admin web site, but I don’t see it anymore, any > ideas if this is going to be available in the future? > > I can see the 389 Directory Server in the cockpit, but there is no way to > add/edit users/groups on it. We've been talking about adding a seperate web based tool for this, but currently it's early stages. For now you'll have to use apache directory studio, the dsidm command line, or another ldap editor. Sorry about that :( > > Thanks, > > > > Jorge F. Hernandez > > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Github / Gitter (Chat service)
> On 27 Apr 2020, at 19:18, Matus Honek wrote: > > On Sat, Apr 25, 2020 at 7:57 AM William Brown wrote: >> >> Hi all, >> >> In the past I have previously "name squatted" 389ds on github, which has >> meant that I'm able to reserve 389ds on gitter - gitter is a web based chat, >> similar to irc, but "cool" with all the kids these days (which really, I >> shouldn't throw shade, I'm a kid still ...) >> >> Anyway, I have setup a channel here: >> >> https://gitter.im/389ds/community >> >> It could be useful to us, and I'm wondering if it's something we would want >> to adopt more over IRC? >> >> Thoughts? > > I was a bit sceptical (another RAM/CPU eater tab) but found out it has > an IRC bridge (https://irc.gitter.im/) and also you can set up email > notifications. Yeah, it's pretty nice actually. :) > But first, I think we should set up a live sync to > https://github.com/389ds/389-ds-base repo since it is confusing to > find an empty repo on the official github 389ds account. > Yep, that's a good idea. I'll look into how to mirror that content. >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > > > > -- > Matúš Honěk > Software Engineer > Red Hat Czech > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Github / Gitter (Chat service)
Hi all, In the past I have previously "name squatted" 389ds on github, which has meant that I'm able to reserve 389ds on gitter - gitter is a web based chat, similar to irc, but "cool" with all the kids these days (which really, I shouldn't throw shade, I'm a kid still ...) Anyway, I have setup a channel here: https://gitter.im/389ds/community It could be useful to us, and I'm wondering if it's something we would want to adopt more over IRC? Thoughts? — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review - 137 entry uuid plugin
https://pagure.io/389-ds-base/pull-request/50970 This is a reasonably large change, but I look forward to your comments and review! — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review: 51014 - slapi-pal buffer size warning
https://pagure.io/389-ds-base/issue/51014 https://pagure.io/389-ds-base/pull-request/51015 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review; 51008 dbhome in containers
https://pagure.io/389-ds-base/pull-request/51010 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Please have a look at rewriters design
> On 1 Apr 2020, at 18:36, thierry bordaz wrote: > > Hello, > > I agree that the term generic is not appropriate. I should change it > (design/PR) if it still exist somewhere. > > https://pagure.io/389-ds-base/pull-request/50981 is said to extend the > usability of existing interfaces and I think it is what it does. > People needing to map/rewrite/transform (whatever the word) an > attribute/value know what they want to obtain but usually do not care about > the burden of writing/deploying a new plugin. > > In my mind only the rewriter is complex and knows when/how it applies > (attribute, scope, crafting values, authentication...) so I wanted to keep > the interface very simple: just load your rewriter and let core server call > it. William raised that it could contain helper function, for example going > through a filter and call rewriter function for each filter components. I am > looking at that at the moment. > I think that a rewriter may also appreciate some configuration area, for > example if a rewriter is generic and apply some transformation rules specific > to a rewriter instance. > > I agree that it needs to be documented and plugin guide is a good place. I > would like to use the design to describe the interfaces. Can we put a design doc on the wiki first, to allow faster editing/review, and then migrate to the plugin guide later? IIRC the plugin guide hasn't been updated in a long time, so I think the wiki may be better here > > best regards > thierry > > On 4/1/20 9:24 AM, Ludwig Krispenz wrote: >> Ok, so Thierry's solution is useful to make using rewriters simpler, but I >> really want to have its use and interface documented somewhere outside the >> code, PR, or design doc on the 389ds wiki - it needs to go to the official >> doc eg plugin guide. >> >> Regards, >> Ludwig >> >> On 04/01/2020 01:02 AM, William Brown wrote: >>> >>>> On 1 Apr 2020, at 01:04, Ludwig Krispenz wrote: >>>> >>>> Hi, >>>> >>>> I was away and am late in the discussion, maybe too late. >>>> >>> Not too late, it's not released in production yet ;). There are two PR's >>> that have been discussed here: >>> >>> https://pagure.io/389-ds-base/pull-request/50988 >>> >>> https://pagure.io/389-ds-base/pull-request/50981 >>> >>>> In my understanding what you mean by "generic" is that for a new rewriter >>>> you do not need a plugin, but to provide some rewrite functions and >>>> specify them in a rewriters config entry. But there is still the need to >>>> write rewriter functions, compile and deploy them, and instead of plugins >>>> you now have a new interface of "filterRewriter" and "returendAttrRewriter >>>> functions - so far not documented anywhere. >>>> >>>> Under generic rewriter I would understand an approach where you do not >>>> need to provide own functions, but have a rewriter plugin, which does >>>> rewriting based on rules in rewrite config entries, eg in which subtree, >>>> for which entries (filter to select), how to map a saerch filter, how to >>>> rename attrs on return, >>> I had the same feeling too, to have these statically in libslapd, and much >>> simpler than resolving symbols and dlopen. However, it's looking more like >>> it will be a plugin style, but without using the current slapi plugin >>> architecture - just a symload at start up. The reason for this that thierry >>> explained is that freeipa plans to link to samba or sssd as part of one of >>> the rewriter classes, and we don't want that to become a dependency of >>> 389-ds. >>> >>> I have argued in the past for a "lib-ipa" that has the needed shared logic >>> between various pieces of the project, but honestly, I forgot if that ever >>> happened. I think these days sssd is libipa in a lot of ways ... >>> >>> Anyway, that's why Thierry want's to have a symload in this case :) >>> >>>> Best regards, >>>> Ludwig >>>> >>>> >>>> On 03/19/2020 01:09 AM, William Brown wrote: >>>>>> On 19 Mar 2020, at 04:08, thierry bordaz wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 3/18/20 1:51 AM, William Brown wrote: >>>>>>>> On 18 Mar 2020, at 04:08, thierry bordaz wrote: >>>>>>>> >>>>>>&g
[389-devel] Re: Please have a look at rewriters design
> On 1 Apr 2020, at 01:04, Ludwig Krispenz wrote: > > Hi, > > I was away and am late in the discussion, maybe too late. > Not too late, it's not released in production yet ;). There are two PR's that have been discussed here: https://pagure.io/389-ds-base/pull-request/50988 https://pagure.io/389-ds-base/pull-request/50981 > In my understanding what you mean by "generic" is that for a new rewriter you > do not need a plugin, but to provide some rewrite functions and specify them > in a rewriters config entry. But there is still the need to write rewriter > functions, compile and deploy them, and instead of plugins you now have a > new interface of "filterRewriter" and "returendAttrRewriter functions - so > far not documented anywhere. > > Under generic rewriter I would understand an approach where you do not need > to provide own functions, but have a rewriter plugin, which does rewriting > based on rules in rewrite config entries, eg in which subtree, for which > entries (filter to select), how to map a saerch filter, how to rename attrs > on return, I had the same feeling too, to have these statically in libslapd, and much simpler than resolving symbols and dlopen. However, it's looking more like it will be a plugin style, but without using the current slapi plugin architecture - just a symload at start up. The reason for this that thierry explained is that freeipa plans to link to samba or sssd as part of one of the rewriter classes, and we don't want that to become a dependency of 389-ds. I have argued in the past for a "lib-ipa" that has the needed shared logic between various pieces of the project, but honestly, I forgot if that ever happened. I think these days sssd is libipa in a lot of ways ... Anyway, that's why Thierry want's to have a symload in this case :) > > Best regards, > Ludwig > > > On 03/19/2020 01:09 AM, William Brown wrote: >> >>> On 19 Mar 2020, at 04:08, thierry bordaz wrote: >>> >>> >>> >>> On 3/18/20 1:51 AM, William Brown wrote: >>>>> On 18 Mar 2020, at 04:08, thierry bordaz wrote: >>>>> >>>>> Hi William, >>>>> >>>>> I updated the design according to our offline exchange >>>> Thanks Thierry, I appreciate the conversation and the updates to the >>>> document: it made clear there were extra details up in your brain but not >>>> in words yet :) it's always hard to remember all the details as we write >>>> things, so thanks for the discussion. Like you said, it's always good to >>>> have a team who is really invested and cares about the work we do! >>>> >>>> >>>> Your design for the core server version looks much better! Thank you. I >>>> still think there are some missing points. The reason to have a libpath >>>> rather than inbuild is to avoid a potential linking to sssd/samba. I think >>>> also that the problem space of the global catalog here needs to be looked >>>> at too. This feature is not in isolation, it's really a part of that. >>> Okay, I will work on a new PR making core server able to retrieve/registers >>> rewriters. >>> >>> I think the "need" to improve the usability of rewriters is not specific to >>> global catalog. Global Catalog is just an opportunity to implement it. I >>> think parts of slapi-nis, integration of vsphere, GC (and likely others) >>> are also use case for rewriters. They were implemented in different ways >>> because rewriters were not easy to use or simply not known. >> Yes, that's perfectly reasonable, and shouldn't stop your idea from being >> created - what's concerning me is that without a full picture you don't know >> how far to take these rewriters or what direction, or what might be needed. >> >>>> This means we have a whole set of deployment cases to look at. >>>> >>>> So the deployment will look like: >>>> >>>> IPA DS --> IPA GC >>>> >>>> >>>> So an ipaAccount from the IPA DS instance will be "copied and transformed" >>>> into the IPA GC. This process is as yet undefined (it sounds like it may >>>> be offline or something else ...). We are simply not dealing with one >>>> instance now, but an out-of-band replication and transformation process. >>>> It's unclear whether the data transform is during this loading process, or >>>> in the IPA GC somehow. >>>> >>>> From what I understand, it sounds li
[389-devel] Please review 50989
https://pagure.io/389-ds-base/issue/50989 https://pagure.io/389-ds-base/pull-request/50990 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Adding new syntaxes
> On 23 Mar 2020, at 12:52, William Brown wrote: > > > >> On 21 Mar 2020, at 01:37, thierry bordaz wrote: >> >> Hi William, >> >> I only have a vague knowledge of syntaxes/MR. >> >> Each syntax is a plugin. Its init function registers for a given set of OIDs >> the matching rules (compare, order, substring) than handle that syntax >> (calls slapi_matchingrule_register). >> There is a special collation plugin that does the same for supported >> language. >> So a entryUUID syntax should define its matching rules callbacks and >> register them for supported OID. >> >> The MR are called during filter evaluation, both at candidate list built and >> at filter match. >> On write path, they are called to generate the index keys. >> >> I think there is a slight difference between syntaxes plugins and collation >> plugin in the way they are selected to apply for a given attribute. >> syntaxes provide the set of supported OIDs while for collation you need to >> call the index to know if it supports the OID. >> >> All of this are general ideas around syntax/MR and I think they are quite >> correct. > > AHhhh, some of these things have helped me make sense of some of the plugin > handle names and such. Thank you! I might put in a work-in-progress PR later > of my work on entryuuid. :) > > Thanks Thierry! As a follow up, thanks for the advice - I can now register a stub syntax plugin into the server (in rust) :D So I'll be doing more to get this working in the coming days. Thanks again for your advice! > > > >> >> best regards >> thierry >> >> >> On 3/20/20 4:37 AM, William Brown wrote: >>> Hi there, >>> >>> I'm looking to add the syntaxes to handle entryUUID properly, because they >>> have a different format to nsUniqueId. Thinking that I need to look at the >>> plugins under ldap/servers/plugins/syntaxes/, but it would be good to have >>> some extra insight about the plugin hooks. Should I look at the old plugin >>> guide? Or is there some extra info I can get from somewhere? >>> >>> Thanks! >>> >>> — >>> Sincerely, >>> >>> William Brown >>> >>> Senior Software Engineer, 389 Directory Server >>> SUSE Labs >>> ___ >>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >>> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org >> > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review - bsd source to default source warning
https://pagure.io/389-ds-base/pull-request/50979 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Adding new syntaxes
> On 21 Mar 2020, at 01:37, thierry bordaz wrote: > > Hi William, > > I only have a vague knowledge of syntaxes/MR. > > Each syntax is a plugin. Its init function registers for a given set of OIDs > the matching rules (compare, order, substring) than handle that syntax (calls > slapi_matchingrule_register). > There is a special collation plugin that does the same for supported language. > So a entryUUID syntax should define its matching rules callbacks and register > them for supported OID. > > The MR are called during filter evaluation, both at candidate list built and > at filter match. > On write path, they are called to generate the index keys. > > I think there is a slight difference between syntaxes plugins and collation > plugin in the way they are selected to apply for a given attribute. > syntaxes provide the set of supported OIDs while for collation you need to > call the index to know if it supports the OID. > > All of this are general ideas around syntax/MR and I think they are quite > correct. AHhhh, some of these things have helped me make sense of some of the plugin handle names and such. Thank you! I might put in a work-in-progress PR later of my work on entryuuid. :) Thanks Thierry! > > best regards > thierry > > > On 3/20/20 4:37 AM, William Brown wrote: >> Hi there, >> >> I'm looking to add the syntaxes to handle entryUUID properly, because they >> have a different format to nsUniqueId. Thinking that I need to look at the >> plugins under ldap/servers/plugins/syntaxes/, but it would be good to have >> some extra insight about the plugin hooks. Should I look at the old plugin >> guide? Or is there some extra info I can get from somewhere? >> >> Thanks! >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org > — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Adding new syntaxes
Hi there, I'm looking to add the syntaxes to handle entryUUID properly, because they have a different format to nsUniqueId. Thinking that I need to look at the plugins under ldap/servers/plugins/syntaxes/, but it would be good to have some extra insight about the plugin hooks. Should I look at the old plugin guide? Or is there some extra info I can get from somewhere? Thanks! — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Please have a look at rewriters design
> On 19 Mar 2020, at 04:08, thierry bordaz wrote: > > > > On 3/18/20 1:51 AM, William Brown wrote: >> >>> On 18 Mar 2020, at 04:08, thierry bordaz wrote: >>> >>> Hi William, >>> >>> I updated the design according to our offline exchange >> Thanks Thierry, I appreciate the conversation and the updates to the >> document: it made clear there were extra details up in your brain but not in >> words yet :) it's always hard to remember all the details as we write >> things, so thanks for the discussion. Like you said, it's always good to >> have a team who is really invested and cares about the work we do! >> >> >> Your design for the core server version looks much better! Thank you. I >> still think there are some missing points. The reason to have a libpath >> rather than inbuild is to avoid a potential linking to sssd/samba. I think >> also that the problem space of the global catalog here needs to be looked at >> too. This feature is not in isolation, it's really a part of that. > Okay, I will work on a new PR making core server able to retrieve/registers > rewriters. > > I think the "need" to improve the usability of rewriters is not specific to > global catalog. Global Catalog is just an opportunity to implement it. I > think parts of slapi-nis, integration of vsphere, GC (and likely others) are > also use case for rewriters. They were implemented in different ways because > rewriters were not easy to use or simply not known. Yes, that's perfectly reasonable, and shouldn't stop your idea from being created - what's concerning me is that without a full picture you don't know how far to take these rewriters or what direction, or what might be needed. >> >> This means we have a whole set of deployment cases to look at. >> >> So the deployment will look like: >> >> IPA DS --> IPA GC >> >> >> So an ipaAccount from the IPA DS instance will be "copied and transformed" >> into the IPA GC. This process is as yet undefined (it sounds like it may be >> offline or something else ...). We are simply not dealing with one instance >> now, but an out-of-band replication and transformation process. It's unclear >> whether the data transform is during this loading process, or in the IPA GC >> somehow. >> >> From what I understand, it sounds like a method to take an ipaAccount and >> transform it to an AD GC account stub. Then inside of that IPA GC there are >> some virtual attributes you wish to add like objectSid binary vs string >> representations, objectCategory, maybe others. >> >> So from our discussion, we have currently focused on "how do we transform >> entries within a single directory server". But that's not the problem here. >> We are saying: >> >> "We take an entry from IPA DS, transform it to an IPA GC stub entry, and >> then apply a set of further "in memory" transformations" > > One of the biggest issue with GC is schema. IPA DS and IPA GC have not > compatible schema. They can not be in the same replication topology. > So provisioning of IPA GC requires transformations rules to present an other > "view" of IPA DS data. Those transformations will be on the write path (i.e. > stored in DB/indexed). This transformation work is almost done and is > completely independent of 389-ds. > All of this is "write" path: provisioning (online or offline) and > transformation. > > The problem for IPA GC is now on the "read" path. AD clients are use to smart > shortcuts/control that are supported by IPA GC. > This is the IPA GC instance that will register the rewriters to act as GC > does. Yep, I'm aware :) > > >> >> If that's the process, why not do all the transforms as required in the DS >> -> GC load process? You raised a critically key point - we have a concern >> about the write path as the transform point due to IO or time to do the >> transform, but it sounds like you have to do this anyway as an element of >> the DS -> GC process. > > Some of the transformation rules, on the write path, are quite complex. > Looking at slapi-nis config entries gives an idea what is needed. In addition > to those transformations, DS to GC online provisioning is not simple at all. > Relying on sync-repl, you then need to transform a received entry into an > update. At the moment it is an offline provisioning via transformation and > import (much simpler). > > To be honest I am afraid that the transform rules will result in rewriting > sl
[389-devel] Re: Please have a look at rewriters design
ike slapi-nis (which is everyones favourite plugin ...) I really think that right now, if the FreeIPA team wants to commit to providing GC support, they need to present a more robust and fully scoped design, that really encompasses the scale and complexity of this feature. Without them providing us clear, communicated designs, we are not able to actually provide well engineered solutions to the problems at hand and we risk another tech debt explosion. Thanks, > > regards > thierry > > On 3/17/20 11:12 AM, thierry bordaz wrote: >> >> >> On 3/17/20 2:42 AM, William Brown wrote: >>> >>>> On 17 Mar 2020, at 02:49, thierry bordaz wrote: >>>> >>>> Hi, >>>> >>>> As a follow up of the PR https://pagure.io/389-ds-base/pull-request/50939, >>>> I wrote down a small design about rewriters (filter/computed_attr) >>>> plugin: http://www.port389.org/docs/389ds/design/search_rewriters.html >>>> >>>> Comments are welcome >>> Probably the most dangerous thing to say in all of history? >> Well decisions are dangerous. Sharing your wise comments reduce the risk of >> bad decisions ;) >> So be sure I sincerely appreciate your feedback. >>> >>> Like, your design is very smart, but that cleverness and flexibility >>> carries many risks. The problem at hand is rewriting ad attributes - not to >>> make a framework. I still say focus on that problem alone rather than >>> trying to solve a generic class of problems. >>> >>> Anyway, I still don't think this is the right avenue. There are two major >>> reasons for this: >>> >>> First, is the attempt to make a "generic framework" to solve a "specific >>> problem". We should not have a generic rewrite framework, when all we need >>> is a specific, focused, module just for doing known and well tested >>> attribute transformations. >>> >>> Code like COS or MEP may be generic, and it solves many cases but the >>> surface area is huge, it's hard to test, and it's hard to reason about. >>> >>> We do not have a need for allowing generic, and arbitrary rewriters to >>> exist, especially not when you have to "compile in" the rewriters anyway! >> >> Rewriting attributes is not a problem it is what LDAP clients do need. But I >> agree rewriting attributes is not that easy. >> >> Clearly we have been hitting a regular demand to rewrite attributes and >> attributes values. Many plugins (cos, mep, addn, roles, views, slapi-nis, >> filter/attribute rewriters and now AD attributes, vsphere integration) have >> been related to rewrite attributes/values. This has always been a big need. >> Many parts of those plugins are similar (finding pattern, scope, craft >> values..) but implemented in a slightly different way. Those plugins are >> generic and already let the client select, through config, the specific >> transformation they need. This design does not introduce a new generic >> plugin but just simplify the use of already supported interfaces. >> >> IMHO those interfaces are clever as they are flexible and opened. They do >> not force rewriters to use strict and limited abilities of plugins (like >> cos, mep,..) and let them be as complex as they need to match their needs. >> >>> >>> This should be simply, an "ad rewrite" plugin, where all it does is that >>> one thing - rewrite the attributes as required for AD emulation for IPA. >>> This is far easier to deploy, test and reason about. Ideally, the >>> configuration is simply "the plugin is enabled or disabled". >>> >>> >>> Second, is the idea of this being a "search rewriter". I don't think this >>> is a good idea. The search path should be simple, it's our hot path. We >>> have many things that have to interact like indexes etc. Look at virtual >>> attribute indexing and such and the work needed for COS to have these used? >>> >>> This plugin should be on the write path, transforming when a change occurs. >>> This means the code is much simpler, easier to test, and we need no >>> modifications to our read paths. Things like MEP and replication will "just >>> work" as will indexing and much more. >> >> I disagree here. Many time the write path is just not possible. Because of >> schema or historical reason, the entries already exist and will not be >> updated. The customer just want to see them i
[389-devel] Re: Please have a look at rewriters design
> On 17 Mar 2020, at 02:49, thierry bordaz wrote: > > Hi, > > As a follow up of the PR https://pagure.io/389-ds-base/pull-request/50939, > I wrote down a small design about rewriters (filter/computed_attr) plugin: > http://www.port389.org/docs/389ds/design/search_rewriters.html > > Comments are welcome Probably the most dangerous thing to say in all of history? Like, your design is very smart, but that cleverness and flexibility carries many risks. The problem at hand is rewriting ad attributes - not to make a framework. I still say focus on that problem alone rather than trying to solve a generic class of problems. Anyway, I still don't think this is the right avenue. There are two major reasons for this: First, is the attempt to make a "generic framework" to solve a "specific problem". We should not have a generic rewrite framework, when all we need is a specific, focused, module just for doing known and well tested attribute transformations. Code like COS or MEP may be generic, and it solves many cases but the surface area is huge, it's hard to test, and it's hard to reason about. We do not have a need for allowing generic, and arbitrary rewriters to exist, especially not when you have to "compile in" the rewriters anyway! This should be simply, an "ad rewrite" plugin, where all it does is that one thing - rewrite the attributes as required for AD emulation for IPA. This is far easier to deploy, test and reason about. Ideally, the configuration is simply "the plugin is enabled or disabled". Second, is the idea of this being a "search rewriter". I don't think this is a good idea. The search path should be simple, it's our hot path. We have many things that have to interact like indexes etc. Look at virtual attribute indexing and such and the work needed for COS to have these used? This plugin should be on the write path, transforming when a change occurs. This means the code is much simpler, easier to test, and we need no modifications to our read paths. Things like MEP and replication will "just work" as will indexing and much more. For me to approve this plugin, I really want to see it being a write-path transformation of values into other values, and it should be focused, targeted, and simple. I do want to make one thing clear though - I think it's much better that this plugin exist in 389-ds rather than in freeipa. The 389-ds project has better tooling (like ASAN/LSAN), faster testing capability and a group of subject matter experts for code review. I think that if you were to move this to freeipa, you would not have the same level of testing or review quality as here, so I'd prefer to see you put it here. Sure, I might be difficult on this topic, but I do it because I believe there is a better, more robust manner to approach this problem space than currently you are considering. :) Thanks, > > best regards > thierry > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review 00core.ldif
https://pagure.io/389-ds-base/pull-request/50948 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review: givenName compat pr50946
https://pagure.io/389-ds-base/pull-request/50946 https://pagure.io/389-ds-base/issue/50945 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Please review: 50935 - systemd override for dscontainer
https://pagure.io/389-ds-base/issue/50935 https://pagure.io/389-ds-base/pull-request/50936 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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-devel@lists.fedoraproject.org
[389-devel] Re: Thoughts on swapping to rfc2307bis.ldif by default
> On 4 Mar 2020, at 10:31, William Brown wrote: > > > >> On 4 Mar 2020, at 00:26, thierry bordaz wrote: >> >> >> >> On 3/3/20 11:59 AM, Alexander Bokovoy wrote: >>> On ti, 03 maalis 2020, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> I have no expertise in this area, but would like to get also Alexander's >>>> opinion and view from IPA >>> >>> I don't have much to add to what Thierry and William covered already. >>> Having a new draft with clarifications would be nice. >>> >>> Given that both 10rfc2307.ldif and 10rfc2307bis.ldif are present in >>> default 389-ds deployment, why this schema conflict isn't a problem >>> right now? >> >> Good point :) >> 10rfc2307bis.ldif is in /share/dirsrv/data and 10rfc2307.ldif in >> /share/dirsrv/schema. >> Only 'schema' definitions are loaded in 'cn=schema'. The definitions in >> 'data' are available for users but are not part of QE scope. >> >> I guess most of the users choose one rfc or the other and then the entries >> will conform the chosen RFC. >> A risk exists if we are moving a dataset from one rfc to the other. This >> either during an import or if instances in the same replicated topology >> create incompatible entries. > > It's not a problem, because while we include both, we only actually install > and load rfc2307.ldif. rfc2307bis.ldif is in a seperate directory as "example > data", and thus is not loaded. > > In the past we made a decision to make schema load from /usr, which has > caused at least one or two users to have issues with this specific schema as > there was "no way" to remove rfc2307.ldif from the schema directory, but they > wanted to use rfc2307bis. > > I think part of the reason we don't hear more complaints about this is as > thierry said, we don't enforce the structural chain on posixGroup which is > one of the major issues for rfc2307 that rfc2307bis resolves. So it's likely > that most people don't notice that they are using rfc2307, instead thinking > it's rfc2307bis as you can add posixGroup to other objectClasses. > > > If we were to straight replace rfc2307 with rfc2307bis today I think we would > have a compatability issue that may affect IPA, but the idea to have a compat > that is a supported hybrid of both, would likely be non-disruptive, keep IPA > working, and allow openldap imports. > >>>>>> >>>>>> A possibility is making a rfc2307bis-compat.ldif instead that allows the >>>>>> MAY of everything in rfc2307, but is based on rfc2307bis as the base. >>>>>> For example, allowing "MAY description $ l $ o $ ou $ owner $ seeAlso $ >>>>>> serialNumber" on ieee802Device and bootableDevice. That would make it >>>>>> forward compatible, and actually quite seamless to upgrade. If we wanted >>>>>> we could consider formalising it to a draft rfc given that's what >>>>>> rfc2307bis is (a draft rfc). >>>>>> >>>>>> Thoughts? >>>>> >>>>> Sorry missed the end of the email ! >>>>> Yes I think it is a good approach, deliver what we can that does not >>>>> break existing deployment. >>>>> For the remaining part of 2307bis we create a diagnostic/healthcheck tool >>>>> that gives a go/no-go to apply a full 2307bis definition. > > I think that the compatibility I proposed wouldn't need an extra tool because > both rfc2307 and rfc2307bis would be valid within it, so we could be > supporting both in parallel. If anything I'd just need to code into my > openldap migration tool to ignore the rfc2307 schema oids since we already > have them in the compat. > > So, does drafting a rfc2307compat.ldif sound reasonable at this point? Do we > think this is worth adding a draft rfc online as well, or is this something > that really only affects us? If it's only us (i suspect it is ...) then I can > also write a corresponding doc on the wiki. https://pagure.io/389-ds-base/pull-request/50934 This is a PR of the compat schema. I can also provide supporting docs on the wiki if desired. > > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-
