[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:
>>> http
[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_se
[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 sho
[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] Re: stable/dev branches
> On 3 Nov 2020, at 23:50, Stanislav Levin wrote: > > > > 03.11.2020 15:58, Mark Reynolds пишет: >> >> On 11/3/20 4:41 AM, Stanislav Levin wrote: >>> Hello. >>> >>> Currently, I package 1.4.1 branch as the former-stable for ALTLinux. >>> But it is not updated since July, too stable? >>> >>> >>> 1.4.x branches in upstream: >>> >>> upstream/389-ds-base-1.4.1 >> This is no longer being maintained >>> upstream/389-ds-base-1.4.2 >> This branch is about to stop being maintained >>> upstream/389-ds-base-1.4.3 >> This would be the "most" stable branch at this time. >>> upstream/389-ds-base-1.4.4 >>> upstream/master >> >> 1.4.4 and master (2.0.0) are not "stable" and include more cutting edge >> changes and features. >> >> HTH, >> >> Mark > > It would be much appreciated such future changes will be announced at > time. I think the other distro-packagers need this information too. > It's a good point Mark, maybe we need to be able to tag dev streams from release streams as 2.0.0 is a "future release" branch at this point. It could also help to have a list of "supported streams" on the front page of the wiki too ... — 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
> On 21 Oct 2020, at 02:47, Pierre Rogier wrote: > > Hi, > > As we are speaking about the test, we should not forget to test the different > mapping tree usages: >the common ones (like standard, chaining or referral on update backends) >and the uncommon ones (like those involving the various distribution > plugins) > I am a bit uneasy about thoses, as I remember they sometimes involved weird > configuration and custom plugins), that said it is old stories and things > have probably changed. Let's hope that we now have a nice list of supported > distribution scenarios These are all really good ideas for expansion of the tests, for certain. Since the scope of the change is just the tree hierarchy, not the backend type though, then there should be no impact if it's chaining/bdb/referral in the tree, only that the nodes are correctly arranged. But more testing is always good, and I'm looking at the area now anyway, so I'll add some of these. 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
> In the first case we could easily mitigate the risk by testing and be fairly > confident, in the second case the tests are too complex to achieve the same > confidence and we should take this kind of risk only if there were a serious > benefit to balance it, but in this case, there are other solutions with less > risks. Actually, I think testing the lib389 tooling would be even harder. You would need to recreate the logic of the mapping tree and sorting in python, which may have subtle differences compared to the C version. So it would be harder to test and gain confidence in. It also doesn't solve the issue that may come about from manual misconfiguration. > I can understand it could seem too conservervative and frustrating but that > is the price when working on mature projects. If you do not do that, the > product becomes unstable, and users quickly abandon it. I have worked on this project for a number of years, so I'm well aware of the culture in the team. We are a team who values the highest quality of code, with customers who demand the very best. To satisfy this as engineers we need to be confident in what we do and the work we create. But every day we make changes that are bigger than this, or have "more unknowns" and more. It's out attitude as a team to quality, our attention to testing, and designs, that make us excellent at effectively making changes with confidence. Because just as easily, when a product has subtle traps, unknown configuration bugs and lets people mishandle it, then they also abandon us. Our user experience is paramount, and part of that experience is not just stability, but reliability and correctness, that changes performed by administrators will work and not "silently fail". This bug is just as much a risk for people to abandon us because when the server allows misconfiguration to exist that is hard to isolate and understand that too can cause a negative user experience. So here, I think we are going to have to "agree to disagree", but as Mark has stated - the fix is created, the PR is open. If you have more configuration cases to contribute to the test suite, that would benefit the project significantly to ensure the quality of the change, and the quality of the mapping tree in general. Our job is to qualify and create scenarios that were "unknown" and turn them to "knowns" so we can control changes and have confidence in our work. > On 20 Oct 2020, at 06:10, Mark Reynolds wrote: > > Hi, > > So some of the arguments here is that we are introducing risk for something > that is not really a big problem. Or, simply not worth investing in. From a > Red Hat perspective "we" would never fix this, it's just not a problem that > comes up enough to justify the work and time. But... The initial work has > been done by the upstream community (William). With a corporate interest too, we have a customer at SUSE who has hit this :). > So from a RH perspective we are getting this work for free. Personally I > don't see this code change as "very" risky, but this is a very sensitive area > of the code. That being said, I am not opposed to adding it, but... I think > we need much more testing around it to build confidence in the patch. I > would want tests that deal with suffixes of varying size, names, nested > levels/complexity: > > o=my_server.com > > dc=example,dc=com > > dc=abcdef,dc=abc (same length as suffix above - since the patch uses > sizing as a way of sorting) > > dc=test,dc=this,dc=patch Yep, these are some great test ideas. I can add these. > > > > I want tests that are adding and removing subsuffixes, and sub-subsuffixes, > and making sure ldap ops work, and replication, etc. I want tests that use > many different suffixes at the same time and many subsuffixes - some > customers have 50 subsuffixes. Our current CI test suite does not have these > kinds of tests, and we need them. I have already checked with replication suite too, and of course, with ASAN. I think that these also are good to have added in general, so I can expand the testing to include more suffixes too. Do you see 50 subsuffixes in a single level nesting or deeper? I can do some shallow nesting and deep nesting hierarchies with that kind of number if you want. I think an interesting test would also be to have ou=x,ou=y,dc=example,dc=com dc=example,dc=com and then add ou=y,dc=example,dc=com in between. Today I think the pre-patched MT code would actually not handle this either, but that's a pretty big edge case IMO. The real guarantee is that we do assemble the tree correctly. We thankfully gain confidence already because the CN is already relied on for routing and query matching an
[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: Mapping tree rework
> > Hi, > > For my part, I have seen mapping tree misconfiguration popping from time to > time but it is quite rare (maybe 7 or 8 times in 15 years) > So although in pure term or architecture your proposal is IMHO the cleanest, > in term of risks it is not a good solution: > there will likely be regressions (it always happens when a component get > redesigned) > and that means that the number of people that will be annoyed by the change > will be far greater than the few people that will be helped by the change. Today, we already rely upon the attribute of cn to determine what suffix the mapping tree element provides. We must trust this value, and already do. This also implies that all current deployments, also trust this value to be correct. It is also provable by tests that *invalid* nsslapd-parent-suffix configs cause backends to "not appear" in the mapping tree. So invalid parent suffixes already fail "noisly". This means, yes, that most deployments have both valid cn's for suffixes and valid nsslapd-parent-suffix values. While it may be rare, we have had a few cases here at suse because the lib389 tools make a mistake in configuration that can easily and trivially cause this failure. So changing this to trust a value of cn to provide ordering, this is already a value we rely on to be correct *and* we remove an obvious configuration consistency failure that has occurred. It is because of these factors that I am more confident that we can make this change with low risk. > > So my feeling is that we should rather go for a trade off. > Since the goal is to prevent that user misconfigures the mapping tree > without warning, > we should do that without changing the way the mapping tree is handled > internally. > simply by adding a consistency check when starting the server or changing > the mapping tree configuration. > > If we want to limit the risk we could phase things: > in first phase we only log warning if inconsistency are found > and latter on when we get more confident about the code we could reject the > configuration change in case of inconsistency > > I know that my proposal is less appealing in term of architecture but such a > solution is safer because it does not change the way mapping tree are handled > and that drastically limits the regression risks Generally it's my view that we should always prioritise constraint and "inability to make mistakes" over "warning about mistakes". There is certainly value in providing warnings about mistakes when they occur, but preventing the mistake from ever occuring is a far more reliable option. Our server should ensure that there is "no way to hold it incorrectly". In the situation where we "warn", that would then actually mean we have to redesign some parts of lib389 to parse and generate a mapping tree itself so it can then correctly determine the parent-suffixs to emit into configs when it attaches a backend into the tree. This would also itself be a significant chunk of work, and a risk of breaking our cli tools too, while also "not preventing" the issue for any other administration methods that exist. I think that your suggestion is moving the burden of correctness from our work in the server as engineers, onto administrators and our tooling to "understand and use it correctly", and that doesn't really sit right with me. So I'd rather continue with the suggestion I have made as we eliminate an entire class of potential problems. In order to really see understand the percieved risks of this change, I'd really like to see configurations that would cause this proposal to fail, and then those can become tests that we can understand and resolve issues with. 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: 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 51177 on upgrade configuration
https://pagure.io/389-ds-base/pull-request/51220 https://pagure.io/389-ds-base/issue/51177 — 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)
ion" and experience with the quirks of 389 lead me to think 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 Serv
[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 >>>> >>>> Se
[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
et_entry (dn=0x7fc8abe90240, > 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-deve
[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: >>>>>
[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. &
[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 tra
[389-devel] Re: Please have a look at rewriters design
> 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. 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" 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. I think everytime I have spoken to you about this, I have kept learning more and more about this, and the more I see, I have many concerns about this feature. I think we do not have the full picture. You have admitted that you don't know the full extend or ideas here. There is clearly a communication break down here to our team from the IPA project, and they aren't telling us what they want. It sounds like they are asking you to just do "a small piece" but only they know the bigger picture. The IPA project has the following designs: https://www.freeipa.org/page/V4/Global_Catalog_Support https://www.freeipa.org/page/V4/Global_Catalog_HLD https://www.freeipa.org/page/V4/Global_Catalog_Access_Control https://www.freeipa.org/page/V4/Global_Catalog_Data_Transformation This also links to: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc737410(v=ws.10)?redirectedfrom=MSDN The freeipa design pages are extremely shallow on details. The entire section on how they plan to get data into the GC is: """ Global Catalog provisioning The data in Global Catalog is provisioned from the primary LDAP server instance running on the same FreeIPA master. A SYNCREPL mechanism is used to retrieve the changes and a modified slapi-nis module is used to transform FreeIPA original data to a schema compatible with Global Catalog in Active Directory. Unlike the original slapi-nis module, the data is stored in a proper LDAP backend so it is persistent across the directory server restarts. """ Where is the example config? Proof of concept? Even a conceptual set of accounts and groups showing the data transformation? How will they synthesise stable object data points? The section of "data transformation" even goes to a blank page. Is the rewrite you are being asked to do just for objectSid once all these other transforms are done? Or is there more? Honestly, it's worth reading the "how global catalog works" from msdn. Just to put it in contrast, that document (when converted to a pdf) is 61 pages long. Look at the features. Group caching, GC replication, partialAttribute replication based on schema, more ... Honestly, Thierry, I trust you as a very smart and capable engineer, but you do not have the full picture here - none of us do. This seems like a feature that will explode in complexity and scale, and if not done *properly* from the start, may end up with many many half-baked, poorly designed solutions tacked together to make it look like it works. And that means
[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
