[389-devel] please review 3 : py3 compat
https://pagure.io/lib389/issue/3 https://pagure.io/lib389/issue/raw/files/351a677d39ec53c54cdfccee730f8f 40be0500e09d585dd11ca8da73235215d2-0001-Ticket-lib389-3-python-3- support.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: csiphash on Sparc
On Wed, 2017-10-11 at 13:36 +0200, Lukas Slebodnik wrote:
> On (11/10/17 12:42), Carsten Grzemba wrote:
> >
>
> >
>
> >On 11.10.17 10:54, William Brown <wibr...@redhat.com> wrote:
>
> >>
>
> >> On Tue, 2017-10-10 at 16:28 +0200, Carsten Grzemba wrote:
>
> >> >
>
> >> > On 10.10.17 16:10, William Brown <wibr...@redhat.com> wrote:
>
> >> > >
>
> >> > > On Fri, 2017-10-06 at 10:21 +0200, Carsten Grzemba wrote:
>
> >> > > > Currently the code src/libsds/external/csiphash/csiphash.c do not
> >> > > > work on Sparc.
>
> >> > > > The casting void* or char* to unit64_t* throws Bus-Error.
>
> >> > > >
>
> >> > > > The solution would be to copy the content of the void and char
> >> > > > pointer so that the variabeles are suitably aligned.
>
> >> > > > To prevent have to use malloc: do we know the max of src_sz?
>
> >> > > >
>
> >> > >
>
> >> > >
>
> >> > > What line is this? I assume you are refering to:
>
> >> > >
>
> >> > > https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82
>
> >> > >
>
> >> > yes!
>
> >> >
>
> >> > >
>
> >> > > (https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82)
>
> >> > >
>
> >> > > No, we can't know the max of src_sz, in theory it could be uint64_t
> >> > > max.
>
> >> > > So this may not be an option.
>
> >> > >
>
> >> > So is malloc for uint64 alignment of the src variable the only option?
>
> >> >
>
> >> > >
>
> >> > >
>
> >> > >
>
> >> > > Are you trying this on a 32bit platform perhaps? What's the arch of the
>
> >> > > machine with the issue?
>
> >> > >
>
> >> > 64bit, Fujitsu M4000
>
> >> > $ isainfo -v
>
> >> > 64-bit sparcv9 applications
>
> >> > fmaf vis2 vis popc
>
> >>
>
> >> I feel like there is something I'm missing here in the problem. What is
>
> >> sizeof(void *) on this platform? I'm assuming 4 or 16 rather than 8
>
> >> bytes? Is this correct?
>
> >>
>
> >no it is 8.
>
> >
>
> >The following programm works on x86 but dumps on Sparc:
>
> >
>
> >
>
> >
>
> >#include
>
> >#include
>
> >
>
> >int func(const void *str, size_t sz, const char key[16]){
>
> > uint64_t *ip = (uint64_t*) str;
>
> > printf ("str: %lx:%lx\n", ip, *ip);
>
> >}
>
> >
>
> >int main()
>
> >{
>
> > char str[25] = "ABCDEFGH12345678";
>
> > char key[16];
>
> >
>
> But following code should work. Please correct me if I am wrong. I didn't
> test.
> char *str = strdup("ABCDEFGH12345678");
> char *key = malloc(16);
>
> yes, function sds_siphash13 is not ideal because it rely on properly alligned
> input data.
>
We are free to change the signature of the function, it's just that I
used this from another open source component (thus why it's slightly
different style wise)
What would you suggest here Lukas?
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: Merge lib389 to source tree
https://pagure.io/389-ds-base/issue/49363 https://pagure.io/389-ds-base/issue/raw/files/85897f15e4523511c5a01cf20f10dcf05882beaed804ffe666e4e16e28c7d8b3-0001-Ticket-49363-Merge-lib389.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: csiphash on Sparc
On Tue, 2017-10-10 at 16:28 +0200, Carsten Grzemba wrote: > > On 10.10.17 16:10, William Brown <wibr...@redhat.com> wrote: > > > > On Fri, 2017-10-06 at 10:21 +0200, Carsten Grzemba wrote: > > > Currently the code src/libsds/external/csiphash/csiphash.c do not work on > > > Sparc. > > > The casting void* or char* to unit64_t* throws Bus-Error. > > > > > > The solution would be to copy the content of the void and char pointer so > > > that the variabeles are suitably aligned. > > > To prevent have to use malloc: do we know the max of src_sz? > > > > > > > > > What line is this? I assume you are refering to: > > > > https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82 > > > yes! > > > > > (https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82) > > > > No, we can't know the max of src_sz, in theory it could be uint64_t max. > > So this may not be an option. > > > So is malloc for uint64 alignment of the src variable the only option? > > > > > > > > > Are you trying this on a 32bit platform perhaps? What's the arch of the > > machine with the issue? > > > 64bit, Fujitsu M4000 > $ isainfo -v > 64-bit sparcv9 applications > fmaf vis2 vis popc I feel like there is something I'm missing here in the problem. What is sizeof(void *) on this platform? I'm assuming 4 or 16 rather than 8 bytes? Is this correct? -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: csiphash on Sparc
On Fri, 2017-10-06 at 10:21 +0200, Carsten Grzemba wrote: > Currently the code src/libsds/external/csiphash/csiphash.c do not work on > Sparc. > The casting void* or char* to unit64_t* throws Bus-Error. > > The solution would be to copy the content of the void and char pointer so > that the variabeles are suitably aligned. > To prevent have to use malloc: do we know the max of src_sz? > What line is this? I assume you are refering to: https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82 No, we can't know the max of src_sz, in theory it could be uint64_t max. So this may not be an option. Are you trying this on a 32bit platform perhaps? What's the arch of the machine with the issue? -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] attn: lib389 python 3 only and merge
Hi, As a team we've decide to conduct the merge of the lib389 source tree with the 389-ds-base source code. In addition, we are in a position where we will only support python 3 for the usage of lib389. Given that most people have not packaged or shipped python-lib389 in most forms, this should be a relatively easy transition - we only need to add and support the python 3 module build steps following the make steps. This merger will happen in the next week, and we will notify when this process is complete. We will update our build documentation on port389.org to reflect this change, Thanks, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: Raise min tls version to 1.2
https://pagure.io/389-ds-base/issue/49395 https://pagure.io/389-ds-base/issue/raw/files/0af22a1dea2fb06b9a3445ea7a98255be89406fcf3e065308511aac5db9ac35c-0001-Ticket-49395-Raise-min-TLS-version-to-1.2.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49279 remove dsktune
https://pagure.io/389-ds-base/issue/49279 https://pagure.io/389-ds-base/issue/raw/files/903b16c6b17de4ec3614ecd6c5e01212d8191d36857bbef19443ab6e51637e21-0001-Ticket-49279-remove-dsktune.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review 49235 change pwhash default
https://pagure.io/389-ds-base/issue/49235 https://pagure.io/389-ds-base/issue/raw/files/fe32ad62a5b40e482426c4f7d6d2b4af0a97e2dc83224183df9e51804afa1517-0001-Ticket-49235-pbkdf2-by-default.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49392 - memavail
https://pagure.io/389-ds-base/issue/49392 https://pagure.io/389-ds-base/issue/raw/files/1e66f9169fad19093c163c51c3ec7f16313712997b72382002c436db06d039e1-0001-Ticket-49392-memavailable-not-available.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Plan for merge of lib389 and svrcore
Hi all, As you may know, we have planned to merge the lib389, svrcore codebases into the 389-ds-base source tree. The current status of the plan is: * merge all remaining patches on lib389 * bring in svrcore, and have rpm-obsoletes from svrcore to a 389-ds-svrcore package * bring in lib389 source * clone all open lib389 tickets to 389-ds-base * archive both projects, We are on track to do this likely in the next 2 months, so please pay attention to when this happens. The goal is to make builds, release and distribution simpler. It's also a major step forward to using our lib389 based CLI tools by default for the server, Thanks, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49376 idlistscanlimit
https://pagure.io/389-ds-base/issue/49376 https://pagure.io/389-ds-base/issue/raw/files/cb1422e5fd77af81ae60ed94275180c57dc5355e3458967aabd9314549b22ce3-0001-Ticket-49376-raise-idscanlimit.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] [Fwd: [389-users] Please review: lib389 referral support]
Forwarded Message From: William Brown <wibr...@redhat.com> Reply-to: "General discussion list for the 389 Directory server project." <389-us...@lists.fedoraproject.org> To: 389-us...@lists.fedoraproject.org <389-us...@lists.fedoraproject.org> Subject: [389-users] Please review: lib389 referral support Date: Tue, 03 Oct 2017 12:59:07 +1000 https://pagure.io/lib389/issue/102 https://pagure.io/lib389/issue/raw/files/7cf92e2939686c1ecf757c1df40a2aa564dc628c00117641de8a6632a39abd3e-0001-Ticket-102-referral-support.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane ___ 389-users mailing list -- 389-us...@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Rust-Lang
On Fri, 2017-09-29 at 08:41 +0200, Carsten Grzemba wrote: > > > > > As a curious question, does solaris have rustlang support ? > > > > > Not in the moment, but there some issues open for rust related Solaris. So it > tried somebody already. OKay, because I (we?) are pursuing integration of rust with 389-ds, so this will become a blocker for you in the future I expect. Probably a few months away still, but I think it's something you need to keep in mind :) -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49387 pkbdf rounds too high
https://pagure.io/389-ds-base/issue/49387 https://pagure.io/389-ds-base/issue/raw/files/dcb804622ee5fb5606ddd03ee59c609288c658587dfa48b7b2260e9e93855302-0001-Ticket-49387-pbkdf2-settings-were-too-aggressive.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: PR_ASSERT problem
On Thu, 2017-09-28 at 08:17 +0200, Carsten Grzemba wrote: > > On 28.09.17 00:49, William Brown <wibr...@redhat.com> wrote: > > > > On Wed, 2017-09-20 at 14:30 +0200, Carsten Grzemba wrote: > > > my build on OpenIndiana with the IllumOS provided NSPR cores on startup > > > of some commands: > > > > > > $ pwdhash > > > Assertion failure: 0 == lock->notified.length, at > > > /jenkins/jobs/oi-userland/workspace/components/library/mozilla-nspr/nspr-4.12/nspr/pr/src/pthreads/ptsynch.c:159 > > > /usr/bin/pwdhash: line 60: 5993: Abort(coredump) > > > > > > $ pstack core > > > core 'core' of 5993: /usr/bin/amd64/pwdhash-bin > > > fd7fff2b4eda _lwp_kill () + a > > > fd7fff2480e0 raise (6) + 20 > > > fd7fff220818 abort () + 98 > > > fd7ff943fda2 () > > > fd7ff9457828 PR_DestroyLock () + d8 > > > fd7ff978bc2a slapi_entry_free () + 11a > > > 00402888 init_config () + 2d8 > > > 00402d43 main () + 353 > > > 0040235c _start () + 6c > > > > > > Before I dive in the source code, has anyone a hint where I can start to > > > search what happens here? > > > > > > > Sounds like the lock may not have been created properly? Sadly I think > > you need to dive into the source, > > > > :( > > > > Let me know if you need any other advice. > > > It works, if I compile with > > AC_DEFINE([USE_POSIX_RWLOCKS], [1], [POSIX rwlocks]) > > Because this is also set in Linux, I guess the NSPR Threads is not tested > anymore. Yes, we only use pthreads, and we are likely to drop NSPR locks too. NSPR is probably going to be only used for NSS/socket interactions going forward because it adds overheads for no gains. As a curious question, does solaris have rustlang support ? -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] I'm back! Please review 49378
In typical fashion, I'm taking it slow on my return. Which means I have two patches for review. https://pagure.io/389-ds-base/issue/49378 https://pagure.io/389-ds-base/issue/raw/files/9f43e2d45818aa9adba4bea8a41f732c565a5e03510c24b984a808e2759cabbc-0001-Ticket-49378-server-init-fails.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review, /49372
Fixes to the filter optimiser, https://pagure.io/389-ds-base/issue/49372 https://pagure.io/389-ds-base/issue/raw/files/60d7f2c562f8e4d2f2ac2b1a3dd610e0c482e3e20ef290b901260d40292a2dd6-0001-Ticket-49372-filter-optimisation-improvements-for-co.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: revised: Ticket 49305 - Need to wrap atomic functions for certain platforms
On Tue, 2017-09-26 at 16:56 -0400, Mark Reynolds wrote: > https://pagure.io/389-ds-base/issue/raw/files/7249aa3bf493cffef4c7e3a3eb843d2626b3a4e6c3802a3d246e0f5cfeafbb33-0001-Ticket-49305-Need-to-wrap-atomic-calls.patch > Cool, so I think this patch touches on something that we need to consider for the future - HPUX support. Today, we can't test this, and we are really shooting blind in our support for it. I've already opened this ticket to drop 32bit: https://pagure.io/389-ds-base/issue/49365 I think that for 1.4.x we should drop HPUX support also. This would limit our support to: * x86_64 * aarch64 * ppc64 (le) And for OS this would put us at: 100% support of Linux Partial support for FreeBSD Someone is working on re-adding Solaris With that in mind, I think that given this atomic wrapper exists *just* for hpux perhaps this patch should *only* be in 1.3.7 branch? I'd like to see it cleaned out/reverted for 1.4.x. perhaps. We have a lot of old legacy support, and I think we really need to take a clearer line on what we do and don't support, and we need to cleanup these shim layers because they *do* add overheads. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: PR_ASSERT problem
On Wed, 2017-09-20 at 14:30 +0200, Carsten Grzemba wrote: > my build on OpenIndiana with the IllumOS provided NSPR cores on startup of > some commands: > > $ pwdhash > Assertion failure: 0 == lock->notified.length, at > /jenkins/jobs/oi-userland/workspace/components/library/mozilla-nspr/nspr-4.12/nspr/pr/src/pthreads/ptsynch.c:159 > /usr/bin/pwdhash: line 60: 5993: Abort(coredump) > > $ pstack core > core 'core' of 5993: /usr/bin/amd64/pwdhash-bin > fd7fff2b4eda _lwp_kill () + a > fd7fff2480e0 raise (6) + 20 > fd7fff220818 abort () + 98 > fd7ff943fda2 () > fd7ff9457828 PR_DestroyLock () + d8 > fd7ff978bc2a slapi_entry_free () + 11a > 00402888 init_config () + 2d8 > 00402d43 main () + 353 > 0040235c _start () + 6c > > Before I dive in the source code, has anyone a hint where I can start to > search what happens here? > Sounds like the lock may not have been created properly? Sadly I think you need to dive into the source, :( Let me know if you need any other advice. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: improve filter optimisation behaviours
https://pagure.io/389-ds-base/issue/49372 https://pagure.io/389-ds-base/issue/raw/files/ce5d3364e29c7d79069df4373be59edb330be918ef39dbb70eb142655450ed50-0001-Ticket-49372-filter-optimisation-improvements-for-co.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Build failed in Jenkins: NIGHTLY #71
root-pw'\'': '\''password'\'', '\''root-dn'\'':
> > '\''cn=Directory Manager'\'', '\''group-id'\'': None,
> > '\''InstScriptsEnabled'\'': None, '\''user-id'\'': None,
> > '\''ldap-secureport'\'': None} was created.
> > INFO:lib389.topologies:Instance with parameters {'\''ldap-port'\'': 38902,
> > '\''suffix'\'': '\''dc=example,dc=com'\'', '\''krb5_realm'\'': None,
> > '\''deployed-dir'\'': '\''/usr'\'', '\''inst-backupdir'\'': '\''/tmp'\'',
> > '\''hostname'\'': '\''localhost'\'', '\''server-id'\'':
> > '\''standalone2'\'', '\''root-pw'\'': '\''password'\'', '\''root-dn'\'':
> > '\''cn=Directory Manager'\'', '\''group-id'\'': None,
> > '\''InstScriptsEnabled'\'': None, '\''user-id'\'': None,
> > '\''ldap-secureport'\'': None} was created.
> > INFO:lib389:List backend with suffix=dc=example,dc=com
> > INFO:lib389:Found entry dn: cn=replrepl,cn=config
> > cn: bind dn pseudo user
> > cn: replrepl
> > objectClass: top
> > objectClass: person
> > sn: bind dn pseudo user
> > userPassword:
> > {SSHA512}fSVgiwmjzWOsGKZZ1a3igvjLrXAtzvviaoqQJxjTCOxq/50irwUXg1uSGGRQlku1eKvg3atsFhADux2dVWHGikmnIhpyDCHZ
> >
> >
> > INFO:lib389:List backend with suffix=dc=example,dc=com
> > INFO:lib389:Found entry dn: cn=replrepl,cn=config
> > cn: bind dn pseudo user
> > cn: replrepl
> > objectClass: top
> > objectClass: person
> > sn: bind dn pseudo user
> > userPassword:
> > {SSHA512}jRRQmpXrtZYjcClT8h0WxbDXSWrOabFbllVqEU7IL7OTMNISaeGCHrOxC8aHhWHXqw7gm8VM+14TR7PEKzTJRYWxpcdPbCow
> >
> >
> > - Captured stderr call
> > -
> > CRITICAL:lib389:Replication is not in sync with replica server (standalone2)
> > = 2 failed, 580 passed, 1 skipped in 13789.67 seconds
> > =='
> > + '[' 1 -ne 0 ']'
> > + echo CI Tests 'FAILED!'
> > CI Tests FAILED!
> > + MSG=FAILED
> > + RC=1
> > + sudo /usr/sbin/sendmail mreyno...@redhat.com firsty...@redhat.com
> > + sudo rm -rf /var/tmp/slapd.vg.121587 /var/tmp/slapd.vg.121743
> > /var/tmp/slapd.vg.5621 /var/tmp/slapd.vg.96805
> > + exit 1
> > Build step 'Execute shell' marked build as failure
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
>
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: autotune the dncache
https://pagure.io/389-ds-base/issue/48831 https://pagure.io/389-ds-base/issue/raw/files/cb09850e9b2e8c51d37d1b5a8e438cb36824eee21c08ee2f9da31440fd478435-0001-Ticket-48831-Autotune-dncache-with-entry-cache.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: pwdhash when used with -D should use root pw scheme
https://pagure.io/389-ds-base/issue/49312 https://pagure.io/389-ds-base/issue/raw/files/7df9ee2e141074de221c035287a6d411c218f04d7b7a07c19dee924d11098348-0001-Ticket-49312-pwdhash-D-used-default-hash-algo.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: certmap plugin interface
https://pagure.io/389-ds-base/issue/49218#comment-463241 https://pagure.io/389-ds-base/issue/raw/files/88eb07a719d70ba1c0e9cbfca5fd4ca3cfaf9b3135bf8d593f0ec896cff3b908-0001-Ticket-49218-Certmap-plugin-capabalities-for-freeipa.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Update: please review rust queue in ds
https://pagure.io/389-ds-base/issue/49325 https://pagure.io/389-ds-base/issue/raw/files/77f66e60d9f091502c8109ffc68e7ed0f441b3696475b7460e33f0047191bd32-0001-Ticket-49325-Proof-of-concept-rust-tqueue-in-sds.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: Template dse.ldif was not complete
https://pagure.io/389-ds-base/issue/49371 https://pagure.io/389-ds-base/issue/raw/files/2b7e2906e8d262f536156a15f09d68e4432bf93a19b37ebd11d6989d233119c0-0001-Ticket-49371-Template-dse.ldif-did-not-contain-all-n.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: incorrect header definition.
https://pagure.io/389-ds-base/issue/49364 https://pagure.io/389-ds-base/issue/raw/files/8506b6c2724c4d9011dc610d02f18cd88a72d7d7efbb6dbed5cec5179a5b1f42-0001-Ticket-49364-incorrect-function-declaration.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: future of lib389 - seperate or merged?
> > -- Merging lib389 to 389-ds-base > > One proposal is to merge them. We would mix in lib389 and the > dirsrvtests into lib389 tests. It is often the case that lib389's > features are bound tightly to a version of directory server. Hi all, This seems to be the most popular answer right now (and I support it too, but I'm biased :) ) I'm going to open a ticket to 389-ds-base to suggest this is the course of action we take. https://pagure.io/389-ds-base/issue/49363 -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Strategy proposal for making DB dump in LDIF format from dbscan
> > > > I have a question / concern though. I thought that we want dbscan 2 > > ldif for emergency recovery scenarios when all else has gone bad and > > assuming that id2entry is still readable. In the approach you > > described we make the assumption that the parentid index is readable > > as well. So we depend on two files instead of one for exporting the > > database. Does this matter or we don't care at all? > There are two scenarios here in my opinion. Backup, and emergency > backup :-) As I've previously stated: performance is important. It > should not take forever to process a 100 million entry database. I > think the tool should use multiple index files (id2entry + friends) if > we can generate the LDIF faster. But, if some of those indexes are > corrupted, then we need an alternate algorithm to generate it just from > id2entry. Also, if we are dealing with a corrupted db, then performance > is not important, recovery is. So if we can do it fast, do it, > otherwise grind it out. > > All that being said there is something we need to consider, which I > don't have an answer for, and that is when databases do get corrupted > which files typically get corrupted? Is it indexes, or is it id2entry? > To be honest database corruption doesn't happen very often, but the tool > should be smart enough to realize that the data could be inaccurate. > Perhaps a parent could be missing, etc. So the tool should be robust > enough to use multiple techniques to complete an entry, and if it can't > it should log something, or better yet create a rejects file that an > Admin can take and repair manually. > > I know this is getting more complicated, but we need to keep these > things in mind. > > Regards, > Mark > > With the current design of id2entry and friends, we can't automatically detect this so easily. I think we should really just have a flag on dbscan that says "ignore everything BUT id2entry" and recover all you can. We should leave this to a human to make that call. If our database had proper checksumming of content and pages, we could detect this, but today that's not the case :( -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Critical: Please review: crash during replication total update
https://pagure.io/389-ds-base/issue/49356 https://pagure.io/389-ds-base/issue/raw/files/e2748604f59eb73141b42a3aca59c7ce5082d9b1e270fa2d4e157b913643db1d-0001-Ticket-49356-mapping-tree-crash-can-occur-during-tot.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Strategy proposal for making DB dump in LDIF format from dbscan
On Fri, 2017-08-11 at 17:49 +0300, Ilias Stamatis wrote: > Hi everybody, > > Following Ludwig's and Mark's suggestions on how to perform a database dump > in LDIF format from dbscan, I have come up with a strategy. I'm talking > about ticket #47567: https://pagure.io/389-ds-base/issue/47567 > > I'd like to discuss this strategy and get some feedback. > > The general idea is: > > - We are cursing though id2entry.db printing entries in order. > - Parents should be printed before children. > - Hence if for some entry parenitd > entryid, we have to print its parent > first (out of order) and track that we did so. > - In order to do the above, we don't need to move the db cursor. We can > just go fetch something from a random place in the db and the cursor will > remain in its place, so we can continue from where we left off after we're > done with printing a parent. > - We also need to construct and print the DN of each entry using its RDN > and the DN of its father. > - Let's use something like a hash map to pair entryids with dns (only for > entries that has children), e.g. map[1] = "dc=example,dc=com", map[4] = > "ou=People,dc=example,dc=com", etc. > > I'll present the algorithm that I came up with in python-like pseudo-code. > > First, the following function constructs the entry's DN and updates the > hash map if needed. We can know whether an entry is a parent or not, by the > presence of the numSubordinates attribute. > > # assumes that parentid already exists in the map > function display_entry(e, map): > if not e.parentid: > e.dn = e.rdn > else: > e.dn = e.rdn + map[e.parentid] > if isparent(e): > map[e.entryid] = e.dn > print_to_ldif_format(e) > > Then, the main loop: > > map = new(hashmap) > printed_in_advance = [] > > for e in entries: > if e.entryid in printed_in_advance: > continue # skip this, we have already displayed it > > if e.parentid < e.entryid: > display_entry(e, map) > > else: > # we need to display parents before children > > list_of_parents = [] > > p = e > while p.parentid > p.entryid: > p = get_from_db(key = p.parentid) > list_of_parents.append(p) # see note below (*) > > for p in reversed(list_of_parents): > display_entry(p, map) > printed_in_advance.append(p.entryid) > > > * here we store the whole entry in the list (aka its data) and not just > its id, in order to avoid fetching it from the database again > > As a map, we can use a B+ tree implementation from libsds. > > I would like to know how the above idea sounds to you before going ahead > and implementing it. > Looks like a pretty good plan to me. What happens if you have this situation? rdn: a entryid: 1 parentid: 2 rdn: b entryid: 2 parentid: 3 rdn: c entryid: 3 parentid: 4 etc. Imagine we have to continue to work up ids to get to the parent. Can your algo handle this case? It seems like the way you could approach this is to sort the id order you need to display them in *before* you start parsing entries. We can file allids in memory anyway, because it's just a set of 32bit ints, so even at 50,000,000 entries, this only takes 190MB of ram to fit allids. So I would approach this as an exercise for a comparison function to the set. universal_entry_set = [] # entryrdn / id2entry # The list of entries to print print_order = [] for e in universal_entry_set: printer_order_insert_sorted(e) So we can imagine that this would invoke a sorting function. Something that would work is: compare(e1, e2): # if e1 parent is 0, return -1 # if e2 parent is 0, return 1 # If e1 is parent to e2, return -1 # If e2 is parent to e1, return 1 # return compare of eid. Then this would create a list in order of parent relationships, and you can just do: for e in print_order: Which despite jumping about in the cursor, will print in order. So you'll need to look at entryrdn once, and then id2entry once for this. If you want to do this without entryrdn, you'll need to pass id2entry twice. But You'll only need 1 entry in memory at a time to achieve it I think. It also doesn't matter about order of ids at all here. You could easily demo this algo in py with entry objects and implement __cmp__, then do "sorted(list)' on it. For the C variant, you would give the cmp function to the btree map, and then as it inserts, it orders them, then you can just do "sds_bptree_map(print_fn)" and it will apply print to each entry in the order. Hope that helps, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: future of lib389 - seperate or merged?
> * No more split patches for lib389 features and tests. > >> > > >> > Cons: > >> > * Need to invest time into version detection of the 389-ds-base package > >> > for configuration (both local and remote). IE we add a plugin in 1.3.7, > >> > but we need to know if lib389 is accessing 1.3.6 (and disallow the > >> > change). > >> I think of this as not a con, but a feature. Also adding more sanity > >> checks would be good. Our tools should be fool-proof. > >> > * Continue to manage separate release of software. > >> > * Need to manage lib389's older versions operating against *newer* > >> > 389-ds-base versions. This adds a lot of complexity and version checks > >> > (potentially with some server awareness?) > >> > > >> > -- Do nothing > >> > > >> > This is the current status. > >> I thought that separate lib389 is a current status, no? > > > > Yes, but this means we leave it seperate, and continue as is. The others > > propose moving the test suites *from* 389-ds-base/dirsrvtests to lib389, > > *OR* merging lib389 to 389-ds-base. > Moving 389-ds-base/dirsrvtests is a no-go IMHO, especially if we want to > gate changes when tests do not pass. Code and tests should live together. Yep - thus why I'm on the "merging" side of this argument. I think there is no reason to seperate our test cases in DS from the framework that runs them - especially if we keep changing the framework, we need to keep dirsrvtests in sync. If we have to lock-step them, then again, justification to merge. > > > >> > > >> > Pros: > >> > * We don't spend any time on the issue at all. > >> > > >> > Cons: > >> > * We get the worst of both worlds. > >> > * Continue to increase complexity as these diverge. > >> > * we often see the need to expand lib389 to express a test in > >> > 389-ds-base, so we will continue to need to split patches > >> > > >> > > >> > > >> > > >> > My vote is to merge them. I came to this decision because I believe that > >> > this will make development against multiple branches easier with regard > >> > to testing and backport of patches. For example, we'll know that lib389 > >> > that's inside of 1.3.7 will *always* work with that release, even if we > >> > have improved in 1.4.x etc. > >> My vote is to merge them as well. But for slightly different reasons: > >> packaging (blocking dependencies are not fun), single place of > >> development. > > > > Cool! That's 2 for merge so far :) > > > >> > > >> > We also are developing new CLI and admin tools, and these are often > >> > tightly linked to a version of Directory Server. I think that it's > >> > easier for us as developers to have this specific linking, than trying > >> > to spend large amounts of time making something generic that works for > >> > all versions. > >> What about migration scenario, when you have a mix of old and new > >> versions of DS, and latest tools should be able to handle them? > > > > You would use the tools on the local host to manage it I would think. > > Just the same today with the pl tools. > I was thinking about new admin server capabilities, similar to what we > have currently with 389-admin and 389-console, where console from one > machine can control other versions of DS. Yep. I was coming at this from the angle of "you should only manage the instance with the tools on the same server". If we push for a seperate admin server, I think that would use mark's DMC design (which is easily a year or more away). So today, I think saying the admin tools have to be the ones on the server is fine, and when we go to DMC, we need the version logic there - and that's a whole different set of challenges in itself for us to work out. It saves me in engineering the extra work of api compat over versions, because let's face it, we have X hours in a day, and I need to spend them on things that are not "how can I maek this work with old version X". As well, that would make CI more difficult perhaps, because we would need to CI lib389+ds of version X, and then test them with version X minus N that we decide to keep compat for (or X plus N for forward admin). Both of which are a harder task to achieve, and I don't want to invest in. We have bigger issues to deal with IMO. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review 49275 compiler warning fixes
https://pagure.io/389-ds-base/issue/49275 https://pagure.io/389-ds-base/issue/raw/files/e2dff59ba3e07a1e43772328f6224c8052687df5e5d100d578b7d4800def97c0-0001-Ticket-49275-fix-compiler-warns-for-gcc-7.patch This should resolve the current CI compiler warning issues. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49348 and 88
Hi, While at pyconau I was very quiet - because I was working toward a major goal that I have had for a while. This patch allows a perl-less install of the 389-ds server: https://pagure.io/389-ds-base/issue/49348 https://pagure.io/389-ds-base/issue/raw/files/fe5ffea4d8cbcd9f0a806aecf39d523684ecefe5660760b152370a949d61de4a-0001-Ticket-49348-support-perlless-and-wrapperless-instal.patch This ticket provides the enablement for lib389 to support testing our server with no perl - ie we can create and remove instances with pure python 3 tools. https://pagure.io/lib389/issue/88 https://pagure.io/lib389/issue/raw/files/a1201152a0861b50098aa7f84c83e7bc201334332d5fc42ca75319b96883164e-0001-Ticket-88-python-install-and-remove-for-tests.patch This is a really exciting milestone for us for our new administrative toolkit in python, and is a major stepping stone to deprecating and removing perl from our codebase. This will make platform ports significantly easier as we will no longer rely on the perl-mozldap components. Thanks, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: future of lib389 - seperate or merged?
> > > > -- Merging lib389 to 389-ds-base > > ... > > * Testing DS is guaranteed to work. Right now we have rapid change in > > lib389 and the tests in say 1.3.5 or 1.2.11.x are unlikely to work with > > latest lib389. > Another problem here is that tests are not backported to the older > branches. The only true source of tests is master branch that is > guaranteed to work with the latest lib389. But the issue here is we don't always mark them with versions properly... > > * We can tightly tie in features of DS with lib389 and their > > administration (ie no need to worry about backward compatibility). > > * Simpler release process - we only need to release 389-ds-base, and we > > are done. > > * No more split patches for lib389 features and tests. > > > > Cons: > > * We will need to backport lib389 features to backport tests for fixes > > to older versions. > > * Inability for latest lib389 to manage older (or newer) versions of ds. > > > > -- Separate lib389 > > > > We have lib389 as a project that moves at a different rate to the > > 389-ds-base project. > > > > Pros: > > * lib389 is able to use it's "knowledge" to administer *multiple* > > versions of Directory Server, rather that singly linked ones. > > * We can write tests into lib389 once and test them against all DS > > versions, or just relevant versions. > > * We can have the admin tools manage many versions of the software which > > may be cross platform/distro. > Why these 3 points can't be done in merged lib389 using version specific > logic in lib389 and the tests? This is also true. But once we merge, is there much need? We only need the connected test set. Issues we find in version 1.3.7 are unlikely to be backported as fixes to 1.3.6 so the test cases aren't relevant here IMO. My thinking is rather than have many cases/switches for all our lib389 to ds versions (which means we need to define a support policy), we can have a simpler 1:1 mapping. Makes the code easier for us, and given that most distributors will ship these together, makes that job easier too. > > * No more split patches for lib389 features and tests. > > > > Cons: > > * Need to invest time into version detection of the 389-ds-base package > > for configuration (both local and remote). IE we add a plugin in 1.3.7, > > but we need to know if lib389 is accessing 1.3.6 (and disallow the > > change). > I think of this as not a con, but a feature. Also adding more sanity > checks would be good. Our tools should be fool-proof. > > * Continue to manage separate release of software. > > * Need to manage lib389's older versions operating against *newer* > > 389-ds-base versions. This adds a lot of complexity and version checks > > (potentially with some server awareness?) > > > > -- Do nothing > > > > This is the current status. > I thought that separate lib389 is a current status, no? Yes, but this means we leave it seperate, and continue as is. The others propose moving the test suites *from* 389-ds-base/dirsrvtests to lib389, *OR* merging lib389 to 389-ds-base. > > > > Pros: > > * We don't spend any time on the issue at all. > > > > Cons: > > * We get the worst of both worlds. > > * Continue to increase complexity as these diverge. > > * we often see the need to expand lib389 to express a test in > > 389-ds-base, so we will continue to need to split patches > > > > > > > > > > My vote is to merge them. I came to this decision because I believe that > > this will make development against multiple branches easier with regard > > to testing and backport of patches. For example, we'll know that lib389 > > that's inside of 1.3.7 will *always* work with that release, even if we > > have improved in 1.4.x etc. > My vote is to merge them as well. But for slightly different reasons: > packaging (blocking dependencies are not fun), single place of > development. Cool! That's 2 for merge so far :) > > > > We also are developing new CLI and admin tools, and these are often > > tightly linked to a version of Directory Server. I think that it's > > easier for us as developers to have this specific linking, than trying > > to spend large amounts of time making something generic that works for > > all versions. > What about migration scenario, when you have a mix of old and new > versions of DS, and latest tools should be able to handle them? You would use the tools on the local host to manage it I would think. Just the same today with the pl tools. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: [PATCH] Allow to override build date
On Tue, 2017-08-08 at 08:00 +0200, Bernhard M. Wiedemann wrote:
> in order to make builds reproducible.
> See https://reproducible-builds.org/ for why this is good
> and https://reproducible-builds.org/specs/source-date-epoch/
> for the definition of this variable.
> ---
> buildnum.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/buildnum.pl b/buildnum.pl
> index 6d8804f..8db83da 100755
> --- a/buildnum.pl
> +++ b/buildnum.pl
> @@ -31,7 +31,7 @@ if ($opt_H) {exitHelp();}
> $platdir = $opt_p;
>
> # Get current time
> -@now = gmtime;
> +@now = gmtime($ENV{SOURCE_DATE_EPOCH} || time);
>
> # Format buildnum as .DDD.HHMM
> $year = $now[5] + 1900;
> --
> 2.12.3
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Please see https://pagure.io/389-ds-base/issue/49347
Where I have merged this commit. Thanks for your contribution!
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: /49336 password rate limit bypass
https://pagure.io/389-ds-base/issue/49336 https://pagure.io/389-ds-base/issue/raw/files/2b4ac80f5ecc5e4903e303103771fd1d03d4c61ce09d2fa46ab000de7bbc6baa-0001-Ticket-49336-SECURITY-Locked-account-provides-differ.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49331 autotuning defaults changes
https://pagure.io/389-ds-base/issue/49331 https://pagure.io/389-ds-base/issue/raw/files/d13fdab8bc1998b394f6614362ae36205a57f52b42eb8cb6eb496ac6c40458b0-0001-Ticket-49331-change-autoscaling-defaults.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49330 improve ndn cache performance
https://pagure.io/389-ds-base/issue/49330 https://pagure.io/389-ds-base/issue/raw/files/c96758b3001c6ea5853ab6ea2a119bc80e59a109041f5cff78aaed4bf7be1924-0001-Ticket-49330-Improve-ndn-cache-performance.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Please review: poc - optional rust queue for ns events
On Fri, 2017-07-14 at 17:15 +1000, William Brown wrote: > https://pagure.io/389-ds-base/issue/49325 > > https://pagure.io/389-ds-base/issue/raw/8ef878a1004308b10982350df76c0378063147024706bdc774bd8b755e07cd67-0001-Ticket-49325-Proof-of-concept-rust-tqueue-in-sds.patch > > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org https://pagure.io/389-ds-base/issue/raw/177ec1c917aa306b5e0006eddad8b805325af5ee3a47afc8b92c53b63dc92f5c-0001-Ticket-49325-Proof-of-concept-rust-tqueue-in-sds.patch Updated based on comments from jistone. It's worth noting the Rust queue is now *faster* than the C queue with work on optimisation. Additionally, thanks to some work with rustc, it's leak free and proven correct with asan, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: pass 1 gcc 7 shadow warns
https://pagure.io/389-ds-base/issue/49275 https://pagure.io/389-ds-base/issue/raw/ca882e9e8cb106549f4eaad1cc62e4bf96647ba53888ef1879b81a40f3a17146-0001-Ticket-49275-shadow-warnings-for-gcc7-pass-1.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: poc - optional rust queue for ns events
https://pagure.io/389-ds-base/issue/49325 https://pagure.io/389-ds-base/issue/raw/8ef878a1004308b10982350df76c0378063147024706bdc774bd8b755e07cd67-0001-Ticket-49325-Proof-of-concept-rust-tqueue-in-sds.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49316 - DS multithread clock safety
https://pagure.io/389-ds-base/issue/49316 https://pagure.io/389-ds-base/issue/raw/4e695b492aeab6dd59f673c986468bf62f6d33d8a5071541e05455c277289de2-0001-Ticket-49316-Fix-clock-unsafety-in-DS.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Implementing Referential Integrity by using a queue instead of a file
On Fri, 2017-07-07 at 11:44 +0200, Ludwig Krispenz wrote: > On 07/07/2017 10:44 AM, Ludwig Krispenz wrote: > > > > On 07/07/2017 07:10 AM, William Brown wrote: > >>>>>> Any thoughts or objections on the above would be welcome. > >>>>> The only problem with going to a queue is if the server goes down > >>>>> unexpectedly. In such a case those RI updates would be lost. > >>>> We already have this issue because there is a delay between the change > >>>> to the object and the log being sync() to disk. So we can already lose > >>>> changes here. TBH the only fix is ot remove the async model. I actually > >>>> question why we still need async/delay processing of the refint > >>>> plugin ... > >>> Historically speaking, a long time ago, we used to see high CPU when the > >>> RI plugin was engaged. Setting the delay to 1 second, and allowing the > >>> log thread to do the work, improved performance. Of course this is now > >>> obsolete with the betxn plugin model and other improvements, but I > >>> wanted to share why the feature even existed. > >> I guess that would be related to internal op searches / lack of > >> indexing. These days it's not as big of an issue. > > boldly said. How do you know, did you verify it ? > > we have seen many customer issues with refereint which were resolved > > by making it async, just removing this option without proof of a > > better solution is no good. > > I also am not sure if we need to tie anything into the betxn. There > > are operations, which, in my opinion, can be delayed, even redone by > > fixup tasks, so it is not necessary to have it in one txn, and if the > > option is there to delay it if you want, we should not take it away > >> So, lets open a ticket to remove delayed processing mode then? > > you can, but I will oppose to implement it :-) > I would even go and suggest to implement the delay feature for memberof, > like a continuous fixup task. I disagree: Right now a delayed / async mode causes us issue because you have a seperation between "the change" then the database reflecting that. Be it through memberof or refint. We have lost the atomic nature of the DB as a result. Memberof especially so because SSSD uses this for membership. If we implemented this we could cause undue delays to access controls be it addition or removal while a consumer waits for the processing to occur. Additionally, the async modes *force* the plugin to run on a single master, rather than all masters lest we cause many replication conflicts. For the sake of replication master consistency being able to run the same configuration on all masters is extremely important. Finally, any delays in refint/memberof processing: * We have a better MO algorithm there, it's just not been implemented yet. * Perhaps refint is missing indexes, or needs an algorithmic change of it's own. I think that it's a better investment of time to *fix* our problems, rather than hide and delay them behind async processing tasks (which arguably, will cause other random delays by being batched, and holding the write lock for a longer time period than a single write). So, I will open this ticket, and I think that given your concerns about this Ludwig, we'll need to keep in mind that refint processing performance is a key aspect of this change, and that we will need to perform some significant load testing to guarantee we will not cause a regression in this space. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Implementing Referential Integrity by using a queue instead of a file
> >>> > >>> Any thoughts or objections on the above would be welcome. > >> The only problem with going to a queue is if the server goes down > >> unexpectedly. In such a case those RI updates would be lost. > > We already have this issue because there is a delay between the change > > to the object and the log being sync() to disk. So we can already lose > > changes here. TBH the only fix is ot remove the async model. I actually > > question why we still need async/delay processing of the refint > > plugin ... > Historically speaking, a long time ago, we used to see high CPU when the > RI plugin was engaged. Setting the delay to 1 second, and allowing the > log thread to do the work, improved performance. Of course this is now > obsolete with the betxn plugin model and other improvements, but I > wanted to share why the feature even existed. I guess that would be related to internal op searches / lack of indexing. These days it's not as big of an issue. So, lets open a ticket to remove delayed processing mode then? -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Implementing Referential Integrity by using a queue instead of a file
On Thu, 2017-07-06 at 14:33 -0400, Mark Reynolds wrote: > > On 07/06/2017 01:07 PM, Ilias Stamatis wrote: > > Hello, > > > > A desire had been expressed to get rid of referint plugin's logfile: > > https://pagure.io/389-ds-base/issue/49202 > > > > It finally turns out that this file is used for other purposes than > > real logging. > > > > The referint plugin currently works like that; When the delay update > > is set to be more than 0 a new thread is created executing referential > > integrity code every x seconds (set by delay update). When a delete or > > modrdn operation happens, the plugin will write that down to its > > logfile. So, every x seconds the plugin will check the logfile, see > > what happened and apply the changes. Finally, it deletes the file, > > thus clearing the state for the next time it reads from it. > > > > After discussing this with William he suggested it's better to replace > > the file with a queue, since the fileinvolves excess fsync / sync, and > > has all kinds of potential state/race issues. Using a queue will be > > much faster as well. > > > > William went even further and suggested that we could get rid of the > > async referint update completely. This probably wouldn't happen soon > > though, since likely customers are using it. For now we could provide > > a warning such as "we recommend you set delay to 0". > > > > Finally, the referint-logchanges attribute does absolutely nothing. It > > seems to be completely ignored by the plugin, so we could remove this > > as well. > > > > I'll start working on these changes soon. > > > > Any thoughts or objections on the above would be welcome. > The only problem with going to a queue is if the server goes down > unexpectedly. In such a case those RI updates would be lost. We already have this issue because there is a delay between the change to the object and the log being sync() to disk. So we can already lose changes here. TBH the only fix is ot remove the async model. I actually question why we still need async/delay processing of the refint plugin ... > > This also brings up a different point... the RI plugin is a backend txn > plugin. If we write changes to a log, and those changes end up failing > for some reason, then there is no way to rollback the original > transaction --> breaking the backend txn plugin model. > > Perhaps the log/delay should just be removed? Or ignore the log/delay > settings if the plugin is set as a backend txn plugin? Completely agree. Because of the delay, if we roll back the txn we still do the refint check. I would be fully in support of removing the delay option and going betxn for the plugin only. This delay behaviour is the reason we advise you only run refint on one master in a topology, where if we remove this and go betxn, we can run on all masters correctly. I think we would need to make the plugin ignore replicated ops then too. My only concern would be what version to have this change land in - as much as I'm excited to make the change we should be careful. Perhaps we remove the delay processing, and have the "delay" process flag act as a switch to check incoming repl ops? Because today if you have delay > 0, you likely have refint on one master, so we need to refint incoming repl ops. If you have delay 0, you ignore repl ops because you assume all masters have refint? No matter what, it's not a smooth upgrade process here, but I think long term it's nicer to just have it on "all masters". -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Beginner's questions + referint-logfile missing
On Wed, 2017-07-05 at 01:28 +0300, Ilias Stamatis wrote: > Hi all, > > I'm kind of a C newbie and I'm trying to take a crack at fixing some things > on the C codebase of DS. I've got a few really entry-level questions that > I'd like to ask. > > 1. How can I re-compile only a single file e.g. > /ldap/servers/plugins/referint/referint.c? > How about re-compiling all plugins only? Make will automatically pick up the timestamp of the file and recompile it, along with any objects that depend on this. > > 2. What do you normally use to locate/jump to function/types definitions > and declarations when you don't know what something is? C tags? grep, lots of grep. I often use other plugins as examples. slapi-plugin.h has a lot of references in it too. Sometimes it's a bit of experience, trial and error etc. Two things that will help you when building plugins is to use ASAN (--enable-asan) because you'll quickly find any C logic errors you make wrt out of bounds. The other is to use gdb and br on your plugin hooks to step through what's going on, when the functions are called, in what order etc. I think that a simple plugin to start with might be addn. I wrote this recently, and I tried to use "best practices" when doing so. https://pagure.io/389-ds-base/blob/master/f/ldap/servers/plugins/addn/addn.c It's also really well commented I hope. > > 3. Which test cases are expected to be written in C, and which in python? Python is for functional server behaviours, IE modifying this entry has this plugin effect triggered. The C tests in cmocka are to test behaviours of single functions. It's hard (today) to mock the slapi_* apis to test a whole plugin, but you can test *parts* of a plugin with cmocka. The password tests are a great example of this. > > 4. After compiling the server, git status reports a list of untracked files: > > benchmark_par_sds > benchmark_sds > docs/slapi.doxy > doxyfile.stamp > html/ > ldap/admin/src/defaults.inf > ... > > Is there a reason why all these are not added in the .gitignore? None - feel free to add them to the .gitignore :) > > Additionally, I have another question regarding the Referential Integrity > plugin. > > The "referint-logfile" attribute is supposed to point to the plugin's log > file. The plug-in itself in my setup seems to work just fine. However the > file /opt/dirsrv/var/log/dirsrv/slapd-localhost/referint declared in the > configuration does not exist at all. Why's that? Is it somewhere else? Is the referint logging turned on? The file may only be created once you enable that plugin's logging feature ... Another aspect is not to worry too much about it - we don't really care if the old log system works on not, because we want to replace it with our known existing slapi_log_err interface. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49310 sds debug logging
https://pagure.io/389-ds-base/issue/49310 https://pagure.io/389-ds-base/issue/raw/631b04000b6d93ef1cac9edc48cdb2e2e8467460fcc6d3df4417e87ba864a2e8-0001-Ticket-49310-remove-sds-logging-in-debug-builds.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Slapi plugin v4
Hi, I'm about to start on https://pagure.io/389-ds-base/issue/49218 In order to reduce duplicate work, I want to start working on the slapi-plugin v4 api. This would be "team only" initially for 1.3.x (IE we won't support you if you roll your own plugins yet), but would be supported on 1.4.x, with the intent to move all plugins to use this api. The main driver of this change is: http://www.port389.org/docs/389ds/design/transactional-operations.html http://www.port389.org/docs/389ds/design/plugin-v4.html If there are no objections, I will create the new certmap plugin interface as a plugin-v4 implementation. Thanks, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49305 - improve atomic handling in ds
https://pagure.io/389-ds-base/issue/49305 https://pagure.io/389-ds-base/issue/raw/4c7748a3d08382a8effacdcc01e2cd06cda7817fa0a10b8b56e3b2de671be451-0001-Ticket-49305-Improve-atomic-behaviours-in-389-ds.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: Fix majority of broken CI cases
https://pagure.io/389-ds-base/issue/49302 https://pagure.io/389-ds-base/issue/raw/012558ba4eefe04a6cbfb7eb5c742cf1b66f610552b6f05fc2262105bd53bc69-0001-Ticket-49302-fix-dirsrv-importst-due-to-lib389-chang.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49290 - improve idl behaviours
https://pagure.io/389-ds-base/issue/49290 https://pagure.io/389-ds-base/issue/raw/8b29ce7a120a6bbd3c75f588bcdddeca11b1e6e81f324c8fc23bb30f95ae2063-0001-Ticket-49290-unindexed-range-searches-don-t-provide-.patch https://pagure.io/389-ds-base/issue/raw/a3a0e4bfb013388f71f38fb9f492d9d497b84e9a2a49c89cc616fcc620605664-0001-Ticket-49290-improve-idl-handling-in-complex-searche.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] lib389 change may break tests
Hi, This morning I acked a commit from Ilias regarding a change to get_attr_type, which added the wrapper ensure int. In the same commit it changed an import * line to use specific imports in the file. This change seemed correct, but it has broken a number of tests in dirsrvtests which relied on the implicit import through the utils namespace. Please be aware of this, and fix the dirsrvtest imports as needed. I'm fixing the suite and ticket cases in the next 24 hours. Sorry for the mistake, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Review follow up: mo crash and ptr deref in sds
https://pagure.io/389-ds-base/issue/49284 https://pagure.io/389-ds-base/issue/49297 -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: lib389 index support
https://pagure.io/lib389/issue/59 https://pagure.io/lib389/issue/raw/4f90364d1f8501a607b3ab4d82b0412e35b77555c5d561ff97c36e55e8c7a403-0001-Ticket-59-lib389-support-for-index-management.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: improve bpt search perf
https://pagure.io/389-ds-base/issue/49297 https://pagure.io/389-ds-base/issue/raw/bf3017244fe26453e9f6b718a4e0a1cbb5bee3b3234bcb71d21cdc0db114c48d-0001-Ticket-49297-improve-search-perf-in-bpt-by-removing-.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: abrt with ns during debug
https://pagure.io/389-ds-base/issue/49289 https://pagure.io/389-ds-base/issue/raw/ce833d102be78d03756a0f05db373aabe06d866dd2bf44a95ccdedbba1e2e1b3-0001-Ticket-49289-Improve-result-handling-from-connection.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] lib389 Please review attr types
https://pagure.io/lib389/issue/67 https://pagure.io/lib389/issue/raw/55b12e95d28acba596cefb45c8cba6507863c2e846ac9839b8371d4329779d26-0001-Ticket-67-get-attr-by-type.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review:radiusd.service dep in unit files
https://pagure.io/389-ds-base/issue/49294 https://pagure.io/389-ds-base/issue/raw/4c081a9f998c7c72335a569db2bea3d2041c856026de08f1f05e0519eb371bcd-0001-Ticket-49294-radiusd-before-in-unit-file.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] please review: lib389 spec requries
https://pagure.io/lib389/issue/69 https://pagure.io/lib389/issue/raw/d6c992f7e147ed794d02ae0690a0e60a733f445c3629fb6e5e6989c17a69bf7a-0001-Ticket-69-add-specfile-requires.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: memberof attr del crash
https://pagure.io/389-ds-base/issue/49284 https://pagure.io/389-ds-base/issue/raw/e8327558132665092605efec809a1f338c5c2526c2c6804ad51adb4d5e357187-0001-Ticket-49284-resolve-crash-in-memberof-when-deleting.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: inttypes in ns tests
https://pagure.io/389-ds-base/issue/49293 https://pagure.io/389-ds-base/issue/raw/60040afe96ae47b72d84a85164bc7afe3b4d1cc1265ca669dc2785c4efc0f96d-0001-Ticket-49293-inttypes-in-nunc-stans.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: crash in mo during attr del
https://pagure.io/389-ds-base/issue/49284 https://pagure.io/389-ds-base/issue/raw/735f2ae301e8d16988289448ca938a335fb5361d676d537b091a20aa0669fd08-0001-Ticket-49284-DS-crashes-when-trying-to-completely-re.patch https://pagure.io/389-ds-base/issue/raw/42a3354077d78dd8822161c03458e550a0db67160445764e0e9138b7c89e9541-0001-Ticket-49284-resolve-crash-in-memberof-when-deleting.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: dsconf expand healthcheck command
https://pagure.io/lib389/issue/66 https://pagure.io/lib389/issue/raw/ba24a3188966f918269ff56086488c3e5167a4be6097ce7dfe6d7a265e31b1b9-0001-Ticket-66-expand-healthcheck-for-Directory-Server.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: update tests in ds due to lib389 50
https://pagure.io/389-ds-base/issue/49281 https://pagure.io/389-ds-base/issue/raw/91da62697b56378343cfc37d2586e9ac80eadcf99d4a151a1baa62b8ef77171a-0001-Ticket-49281-improve-db2-tests.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Please review: lib389 bytes vs str
On Mon, 2017-06-05 at 15:14 +1000, William Brown wrote: > https://pagure.io/lib389/issue/63 > > https://pagure.io/lib389/issue/raw/394bd115d8a1c00f70dffb5f59cad7c49dd82fe4e791551432862fb508df033c-0001-Ticket-63-lib389-python-3-fix.patch > This fixes some more issues as well: https://pagure.io/lib389/issue/raw/edd1ba80e51dba98f68fa1c1e804b7a75cd5a9639427bf84cad9a876c26d87ea-0001-Ticket-63-part-2-agreement-test.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: lib389 bytes vs str
https://pagure.io/lib389/issue/63 https://pagure.io/lib389/issue/raw/394bd115d8a1c00f70dffb5f59cad7c49dd82fe4e791551432862fb508df033c-0001-Ticket-63-lib389-python-3-fix.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] please review: improve default system tuning
https://pagure.io/389-ds-base/issue/49277 https://pagure.io/389-ds-base/issue/raw/367515e90ab969c8d9f4ca0ddfd50478407f10eb5edd253a36c9582982e58ff4-0001-Ticket-49277-improve-out-of-box-system-tuning-for-EL.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: DBVERSION corruption segfaults server
https://pagure.io/389-ds-base/issue/49273 https://pagure.io/lib389/issue/62 https://pagure.io/lib389/issue/raw/3df8468e3c48e8c9a4a40c45eaa7a4b8c09be41db12d68afd0165de1009652ae-0001-Ticket-62-dirsrv-offline-log.patch https://pagure.io/389-ds-base/issue/raw/a6d66e4b16195d4f8c7bd74ddc5f673c7e5601f722104889019c2266927a4616-0001-Ticket-49273-crash-when-DBVERSIOn-is-corrupt.patch Python pathch is needed to test the error. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: lib389 60 add dsrc to lib389 cli tools
https://pagure.io/lib389/issue/60 https://pagure.io/lib389/issue/raw/b6fa6930685f1b8016e845bffa7e33c788fe5c1ec25e67c68d85be7bedd80dcf-0001-Ticket-60-add-dsrc-to-dsconf-and-dsidm.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: tls external auth in lib389
https://pagure.io/lib389/issue/32 https://pagure.io/lib389/issue/raw/a147f04cf43205491633007e3b1b2ce10228f0a2a2a8eeaa933eb31ec99b25f1-0001-Ticket-32-Add-TLS-external-bind-support-for-testing.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Please review: TLS external support for lib389
On Fri, 2017-05-26 at 15:42 +1000, William Brown wrote: > https://pagure.io/lib389/issue/32 > > https://pagure.io/lib389/issue/raw/c28190e9d78697b986b680b2f823943fd0cdd947350aa510f09260144121eeeb-0001-Ticket-32-Add-TLS-external-bind-support-for-testing.patch > > Didn't add the test case >.< https://pagure.io/lib389/issue/raw/5d2b907412f23b96fb12c2005fcff50f316b7739256c2d38ab8dfc9ca96f718a-0001-Ticket-32-Add-TLS-external-bind-support-for-testing.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: TLS external support for lib389
https://pagure.io/lib389/issue/32 https://pagure.io/lib389/issue/raw/c28190e9d78697b986b680b2f823943fd0cdd947350aa510f09260144121eeeb-0001-Ticket-32-Add-TLS-external-bind-support-for-testing.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: build failures on ppc64
https://pagure.io/389-ds-base/issue/49268 https://pagure.io/389-ds-base/issue/raw/0344430c509da99fd7d42e212f200674ab29724bf6956e4cebb4d9d2ab8dd58c-0001-Ticket-49268-master-branch-fails-on-big-endian-syste.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49267
https://pagure.io/389-ds-base/issue/49267 https://pagure.io/389-ds-base/issue/raw/files/b2750629fb851eac81a04baa1b6790ec4d1f8dd09cda6f8f141f0adf6d1b5f85-0001-Ticket-49267-autosize-split-of-0-results-in-dbcache-.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: improve gdb tools for DS
https://pagure.io/389-ds-base/issue/49242 https://pagure.io/389-ds-base/issue/raw/files/5ff4e26b52b3fa5cb4df7d4e19a435097b25967c7250330ab0e671009b095d49-0001-Ticket-49242-add-gdb-script-to-rpm.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: systemd and ns startup issue
https://pagure.io/389-ds-base/issue/49099 https://pagure.io/389-ds-base/issue/raw/files/2b1d52cde0e14c593cc035ac2eefdbab53e5ecf2412847ee8ef4f651c21c4dc2-0001-Ticket-49099-resolve-systemd-startup-interaction-wit.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: lib389 account lock/unlock
https://pagure.io/lib389/issue/30 https://pagure.io/lib389/issue/raw/files/6b7c82e32c5cac218eefbd880533413e29a5f34c6a181367580d0e17ab8a12a9-0001-Ticket-30-Add-initial-support-for-account-lock-and-u.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: create contrib section
https://pagure.io/389-ds-base/issue/48123 https://pagure.io/389-ds-base/issue/raw/files/6b53f2e9606bca698fde5265ad137336116f891b5f23f5e2c964ff1037f23eb0-0001-Ticket-48123-create-contrib-section.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review; remove mempool experimental
https://pagure.io/389-ds-base/issue/49250 https://pagure.io/389-ds-base/issue/raw/files/721b51b0f5d1a8b5623582e6af2764a23c0547d1dfedee1d1ff97bc4761d7a69-0001-Ticket-49250-remove-mempool-experimental.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49247 incorrect linking statement in tests
https://pagure.io/389-ds-base/issue/49247 https://pagure.io/389-ds-base/issue/raw/files/948a1068a083fc1be9f5b86b8da98b8c9cc4fccfa5291d055164be46f3045537-0001-Ticket-49247-resolve-build-issues-on-debian.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: ns-workers prep
https://pagure.io/389-ds-base/issue/49099 https://pagure.io/389-ds-base/issue/raw/files/69bc1f2f7ecc97a2cc2489cc64b301f9c4765f9d98af3a357c3108193c5ea93f-0001-Ticket-49099-ns-workers-prep.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review (again): memory leaks in dblayer and compute init
https://pagure.io/389-ds-base/issue/49185 https://pagure.io/389-ds-base/issue/raw/files/d49cebc581af8657a92062a176b8ee8032e5c7d9f47ad62ccca02084e791be83-0001-Ticket-49185-Fix-leaks-in-compute-init-and-dblayer.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] query: ldapu_ function struct
Hi all, I've been looking at https://pagure.io/389-ds-base/issue/49053 and noticed issues with the functions here. It seems we export a set of macros (like ldapu_err2string) that overload on a symbol name. Given the current usage of these, I think we can purge the macros, and the function table and just rely on our default implementations of these. The impact is that we would no longer support compilation on Windows. Given that I don't think we have built on windows in maybe years, (our remaining supported platforms are Linux and FreeBSD today), I would like to purge this code and simplify this so that I can enable LTO. If I don't hear anything in the next few days, I'll go ahead and do this anyway, Thanks, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: parent_txn null during fixup
https://pagure.io/389-ds-base/issue/49243 https://pagure.io/389-ds-base/issue/raw/files/e027ada0fe3a11dde79a3e2db9d53501a3290f2b85bbc41715d9979a2da50d6c-0001-Ticket-49243-segv-in-memberof-fixup.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 48985 nsmemberof
https://pagure.io/389-ds-base/issue/48985 https://pagure.io/389-ds-base/issue/raw/files/0fb39267ed2fb03ead468e41c3c81a0bc862fe7414b4dfe4368bff9f166751f3-0001-Ticket-48985-Add-schema-for-nested-groups-to-work-ou.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: ci compiler warnings
https://pagure.io/389-ds-base/issue/49240 https://pagure.io/389-ds-base/issue/raw/files/6ff46c02adb9b01418343a5817e76792127bee938dccca88a1fb9b104827da0e-0001-Ticket-49240-ci-compiler-warns.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Build failed in Jenkins: 389-ds-base #1274
https://pagure.io/389-ds-base/issue/49240
I'm working on these now.
On Wed, 2017-05-03 at 01:41 +, jenk...@fedoraproject.org wrote:
> See <https://jenkins.fedorainfracloud.org/job/389-ds-base/1274/>
>
> --
> Started by user William Brown
> Building remotely on F25 (Fedora25 fedora Fedora fedora25) in workspace
> <https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/>
> Wiping out workspace first.
> Cloning the remote Git repository
> Cloning repository http://pagure.io/389-ds-base.git
> > git init <https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/> #
> timeout=10
> Fetching upstream changes from http://pagure.io/389-ds-base.git
> > git --version # timeout=10
> > git -c core.askpass=true fetch --tags --progress
> http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
> > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
> > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* #
> timeout=10
> > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
> Fetching upstream changes from http://pagure.io/389-ds-base.git
> > git -c core.askpass=true fetch --tags --progress
> http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
> > git rev-parse origin/master^{commit} # timeout=10
> Checking out Revision 7995007049678a0009216b9d31b4c18520d9a1a6 (origin/master)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f 7995007049678a0009216b9d31b4c18520d9a1a6
> > git rev-list 7995007049678a0009216b9d31b4c18520d9a1a6 # timeout=10
> [389-ds-base] $ /bin/sh -e /tmp/hudson3123558708947843228.sh
>
> Running configure...
> CFLAGS= -Wall -Wno-deprecated -Wno-deprecated-declarations CXXFLAGS=
> -Wall -Wno-deprecated -Wno-deprecated-declarations ./configure
> --with-tmpfiles-d=/etc/tmpfiles.d --with-openldap --enable-cmocka
> --enable-gcc-security --with-systemdsystemunitdir=/lib/systemd/system
> --with-systemdsystemconfdir=/etc/systemd/system --enable-debug
> Build log is
> https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1274.txt
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal --force -I m4
> autoreconf: configure.ac: tracing
> autoreconf: running: libtoolize --copy --force
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: putting macros in 'm4'.
> libtoolize: copying file 'm4/libtool.m4'
> libtoolize: copying file 'm4/ltoptions.m4'
> libtoolize: copying file 'm4/ltsugar.m4'
> libtoolize: copying file 'm4/ltversion.m4'
> libtoolize: copying file 'm4/lt~obsolete.m4'
> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
> libtoolize: and rerunning libtoolize and aclocal.
> autoreconf: running: /usr/bin/autoconf --force
> autoreconf: running: /usr/bin/autoheader --force
> autoreconf: running: automake --add-missing --copy --force-missing
> configure.ac:29: installing './compile'
> configure.ac:25: installing './config.guess'
> configure.ac:25: installing './config.sub'
> configure.ac:14: installing './install-sh'
> configure.ac:14: installing './missing'
> Makefile.am: installing './depcomp'
> parallel-tests: installing './test-driver'
> autoreconf: Leaving directory `.'
>
> Running make...
> Build log is
> https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1274.txt
>
> Checking for warnings...
> Build https://jenkins.fedorainfracloud.org/job/389-ds-base/1274/ failed
> There are build warnings
> Warning log is
> https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build-warns.1274.txt
> Last 100 lines of warning log:
>
> ldap/servers/slapd/pblock.c:220:24: warning: assignment from incompatible
> pointer type [-Wincompatible-pointer-types]
> ldap/servers/slapd/pblock.c:227:25: warning: assignment from incompatible
> pointer type [-Wincompatible-pointer-types]
> ldap/servers/slapd/pblock.c:234:23: warning: assignment from incompatible
> pointer type [-Wincompatible-pointer-types]
> ldap/servers/slapd/pblock.c:241:25: warning: assignment from incompatible
> pointer type [-Wincompatible-pointer-types]
> ldap/servers/slapd/pblock.c:248:26: warning: assignment from incompatible
> pointer type [-Wincompatible-pointer-types]
> ldap/servers/slapd/pblock.c:255:30: warning: assignment from incompatible
> pointer type [-Wincompatible-pointer-types]
> ldap/servers/slapd/pblock.c:262:31: warning: assignment from incompatible
> pointer type [-Wincompatible-pointer-types]
> src/libsds/test/test_sds_bpt.c:25:
[389-devel] Future of setup-ds.pl and the dscreate python tool
Hi, I've been doing a lot of the work to replace the aging setup-ds.pl script with a python tool. I would like to discuss this direction in light of our desire to put ds in a container. Fundamentally, containers are about a static application, that are completely bundled. There is no guarantee that rpm upgrade scripts or otherwise are run. This is very contrary to our current model of setup-ds.pl, and partially even our model of dscreate the new python tool. I'm wondering if we need to change our approach here. I think that perhaps it could be worth us saying "right, the python installer was fun, but it doesn't work in containers". Upgrades between DS versions is a big part of this equation. I think that instead, we should develop a C (or Rust ;) ) module inside of ns-slapd that does this for us. We have access to libini for C, or toml in rust that can parse the setup.inf, do our "templating", and create directories etc on first run. We can write in a config value like nsslapd-config-version: , and then on each upgrade we can update that value. We would provide all our upgrade and migration scripts as modules that run "just before" the socket listeners start and we start processing operations. This would reduce instance creation to: ns-slapd create -f setup.inf It would also mean that in containers on upgrade, we upgrade at startup - and the same is true of current deployments. I think that we should consider this as a better approach. Containers encourage tighter, integrated modules, and I think that we should follow this path if we want to be successfully integrated in this space. Comments and questions? If I don't hear back in say the next week, I'll just assume everyone is cool with this topic, and I'll start working on it. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: fix leaks in db2archive and co
https://pagure.io/389-ds-base/issue/49185 https://pagure.io/389-ds-base/issue/raw/files/cd1f8e24adcf6296520eda2a9d4ed612529c3574ca0619cfab57547fc91d3e5a-0001-Ticket-49185-Fix-leaks-in-compute-init-and-dblayer.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] please review: 49097 pblock refactor
https://pagure.io/389-ds-base/issue/49097 https://pagure.io/389-ds-base/issue/raw/files/3adf5b3edf54a26bd8efaab40e7ab7770e634b144bd528f25b4798f7f8891579-0001-Ticket-49097-fix-the-pblock-to-be-a-hierachial-struc.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Branched master to 389-ds-base-1.3.6
On Wed, 2017-04-26 at 11:40 -0400, Mark Reynolds wrote: > Just a heads up for developers that we branched master to > 389-ds-base-1.3.6. So master branch is now 1.3.7 > Thanks Mark for this. I'll start on some of my 1.3.7 items then :) -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 21, serverid issue in lib389
https://pagure.io/lib389/issue/21 https://pagure.io/lib389/issue/raw/files/f6d5e9b2bdbc0b95e274632abe908051ce13b45bc39a6b229241f8c2b53461ee-0001-Ticket-21-Missing-serverid-in-dirsrv_test-due-to-inc.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49233 correct psearch regression
https://pagure.io/389-ds-base/issue/49233 https://pagure.io/389-ds-base/issue/raw/files/7714e5de5c1d872bb387f286da406c9cd648e6982ecaea8a741f37c7a8ff21ce-0001-Ticket-49233-Fix-crash-in-persistent-search.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] lib389 replica class
Hi Mark / others Given that one of our community members (ankity) is hitting up against some issues, and the function they need is in the ReplicaLegacy object, maybe it's time we bit the bullet and broke the old ReplicaObject in favour of the new one? It would be worth us sinking some time down into this improvement, as it's going to help ease people into lib389 in the future. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: 49135 pbkdf2 time based rounds
https://pagure.io/389-ds-base/issue/49135 https://pagure.io/389-ds-base/issue/raw/files/88d4c18f6f95d9e47e8893f35bc90df6bef8565d232340352c57efb76d1681c0-0001-Ticket-49135-PBKDF2-should-determine-rounds-at-start.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Design: dynamic certificate mapping
http://www.port389.org/docs/389ds/design/certmap-ipa.html https://pagure.io/389-ds-base/issue/49218 This is a design related to providing plugin hooks for certificate mapping features. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Config attribute - nsslapd-allowed-sasl-mechanisms - behaviour
On Sun, 2017-04-23 at 22:28 +0200, Simon Pichugin wrote: > On Fri, Apr 21, 2017 at 04:02:50PM +1000, William Brown wrote: > > On Fri, 2017-04-21 at 07:55 +0200, Simon Pichugin wrote: > > > On Fri, Apr 21, 2017 at 09:25:23AM +1000, William Brown wrote: > > > Partly, yes. My question was about possible regression. > > > > > > We have a lot of tests for nsslapd-allowed-sasl-mechanisms in TET. > > > It has raised two concerns I have now. > > > > > > First, if we are trying to set 'empty value' with a replace operation, it > > > fails (and it is okay). > > > > > > But now with your new cn=config feature we have > > > 'nsslapd-allowed-sasl-mechanisms' empty by default. > > > It seems to be wrong as long as the servers forbids to set 'empty value' > > > manually. > > > > Well, the bug there is we can't set an empty value. You should be able > > to delete the attribute though, and that should reset it. > > > > Additionally, it may be worth checking that if the value is empty sasl > > treats that as *all* mechs are allowed. This would be one of the few > > config items where I think it should be a blacklist, rathar than > > whitelist. > > > > So certainly, this could be a bug. > > > > > > > > Second test that fails now asserts that we can't add more values to the > > > single-value attribute (nsslapd-allowed-sasl-mechanisms is the one). > > > The test excpects an error. But the server just replaces the value with > > > a new one. No error happens. Is it by design or we should fix it? > > > > I did fix some code related to add/replace. I think that if you add > > another value, and it replaces, that's a bug. It contradicts the ldap > > standard I think. > > Hi William, > after some investigation I've found out that my previous report was > misleaded by TET. Though I've found some strange behaviour in the > cn=config reset to defaults feature and the subject. > > On clean instance: > 1. Check the supportedSASLMechanisms on a clean instance with a default > nsslapd-allowed-sasl-mechanisms: > [root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D > "cn=directory manager" -w Secret123 -b "" -s base supportedSASLMechanisms > dn: > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: DIGEST-MD5 > supportedSASLMechanisms: CRAM-MD5 > supportedSASLMechanisms: LOGIN > supportedSASLMechanisms: PLAIN > supportedSASLMechanisms: ANONYMOUS > > 2. Set some particular SASL mechanism: > [root@qeos-236 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D > "cn=directory manager" -w Secret123 > dn: cn=config > changetype: modify > replace: nsslapd-allowed-sasl-mechanisms > nsslapd-allowed-sasl-mechanisms: DIGEST-MD5 > > modifying entry "cn=config" > > 3. Check the supportedSASLMechanisms: > [root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D > "cn=directory manager" -w Secret123 -b "" -s base supportedSASLMechanisms > dn: > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > > 4. Reset to default by deleting the attribute: > [root@qeos-236 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D > "cn=directory manager" -w Secret123 > dn: cn=config > changetype: modify > delete: nsslapd-allowed-sasl-mechanisms > > modifying entry "cn=config" > > 5. Check the supportedSASLMechanisms once againg: > [root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D > "cn=directory manager" -w Secret123 -b "" -s base supportedSASLMechanisms > dn: > supportedSASLMechanisms: EXTERNAL > > 6. Restart the instance: > [root@qeos-236 dirsrv-tet-install]# restart-dirsrv > Restarting instance "qeos-236" > > 7. Check the supportedSASLMechanisms: > [root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D > "cn=directory manager" -w Secret123 -b "" -s base supportedSASLMechanisms > dn: > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: DIGEST-MD5 > supportedSASLMechanisms: CRAM-MD5 > supportedSASLMechanisms: LOGIN > supportedSASLMechanisms: PLAIN > supportedSASLMechanisms: ANONYMOUS > > Results: So if we reset the attribute it will not be applied without a > restart. > Though if we set some SASL mechanism manually it will be applied instantly. > Ahhh, so the issue is in how we reset this value to a default. Okay, that is a bug. Do you mind opening an issue an assigning it to me? Should be relatively easy to resolve. Do you have a lib389 testcase? Or is this tet? -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Rust in DS poc
Hi all, I've been working on some demo's of rust + c in various use cases we need for DS. https://github.com/Firstyear/ds_rust_experiments/blob/master/simple_plugins/core/src/lib.rs Simple POC of how we could write the plugin system in rust. I'm thinking that it would be cool to get a small API in there somewhere that uses this: https://github.com/Firstyear/ds_rust_experiments/tree/master/weaklink So we could replace an existing simple C function with a rust one for testing and see how it goes :) Another option is to use a seperate .so as per this example: https://github.com/Firstyear/ds_rust_experiments/tree/master/exposed_header_and_symbols What do you think. Something we could actually test in the branch soon? -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
