Re: Ars claims: Fedora 32 is sluggish

[Viktor Ashirov]

On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro 
wrote:

> Hi,
>
> Has anybody investigated Jim Salter's claims that Fedora 32 is slow to
> launch applications? Recent article:
>
>
> https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/
>
> "in my experience, Fedora 32 is noticeably, demonstrably more sluggish
> to launch applications than Ubuntu is in general."
>
> Original article:
>
>
> https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workstation-32/
>
> Would be good to know, for starters, whether this difference is real
> and measurable.
>
This was bugging me for a while. I also noticed that Fedora 32 is a bit
slower than it used to be. Compilation time of a project that I'm working
on went from ~35-36 seconds to ~47-48. At first I thought that it's just
another round of CPU vulnerabilities mitigations that introduced a
performance drop. But after some digging I found that the default CPU
governor was switched from 'ondemand' to 'schedutil' in Fedora kernel 5.9.7:
https://src.fedoraproject.org/rpms/kernel/c/73c86ebaee23df8310b903c1dab2176d443f5a3a?branch=rawhide
(see configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL)

I switched it back using cpupower from kernel-tools:
$ sudo cpupower frequency-set --governor ondemand

And confirmed that my compilation time went back to the previous ~35
seconds.
In the end I switched the governor to 'performance' and shaved another 5
seconds. And gnome-shell no longer feels sluggish, switching tabs in the
browser is also instant.
To make the change permanent I used settings in /etc/sysconfig/cpupower and
enabled cpupower service:
$ sudo systemctl enable --now cpupower.service

The change of the default CPU governor looks pretty significant to me, but
I couldn't find any discussions about it.


> Michael
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Viktor
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-devel] 389-ds-base-1.4.4.5

[Viktor Ashirov]

Hi,

I see 389-ds-base-1.4.4.5-1.fc33 in Fedora 33:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1620743
But the latest master is 1.4.4.4. And I don't see the 389-ds-base-1.4.4.5
tag.
Do we miss the tag or Fedora release should not be 1.4.4.5?

Thanks.

-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: 389 DS nightly 2020-07-29 - 97% PASS

[Viktor Ashirov]

Only some tests were executed, there is an issue with pytest:
https://github.com/pytest-dev/pytest/issues/7559

On Wed, Jul 29, 2020 at 1:31 AM  wrote:

>
> https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/29/report-389-ds-base-1.4.4.4-20200728git98d6c7f.fc32.x86_64.html
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>


-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Please review: PR 51087 - Fix CI test suite issues

[Viktor Ashirov]

https://pagure.io/389-ds-base/pull-request/51087

Thanks!
-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: tests take minutes to start

[Viktor Ashirov]

On Wed, May 13, 2020 at 12:05 PM William Brown  wrote:
>
> It's due to the way that docker for mac works, the IO pipe to the container 
> is via the CPU path, so anything that needs a grep like this will take a long 
> time.
OK, that's why I asked about 'other OS' :)
Have you tried mounting volumes via nfsmount [1]?
In the meantime, I'm working on integrating pre-commit [2] and various
linters/checkers for lib389. I think we can add another hook that will
generate markers for pytest.ini.

[1] 
https://www.jeffgeerling.com/blog/2020/revisiting-docker-macs-performance-nfs-volumes
[2] https://pre-commit.com/
>
> > On 13 May 2020, at 17:15, Viktor Ashirov  wrote:
> >
> > On Wed, May 13, 2020 at 9:13 AM William Brown  wrote:
> >>
> >>
> >>
> >>> On 13 May 2020, at 17:01, Viktor Ashirov  wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Wed, May 13, 2020 at 8:31 AM William Brown  wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I noticed today that my tests now take minutes to start executing. It 
> >>>> looks like it's spinning on:
> >>>>
> >>>> dirsrv   84605 12.8  0.1  16672  7704 pts/0S+   16:25   0:08 grep 
> >>>> -rh ^@pytest.mark.\(ds\|bz\)[0-9]\+
> >>>>
> >>>> Do we know anything about this? Did we add something in a fixture or 
> >>>> something to grep for tests? That kind of pattern does look like our 
> >>>> bz/ds here, so I suspect it comes from us.
> >>> It is this change:
> >>> https://pagure.io/389-ds-base/c/6a7a154159583c09fcbba0578eaf576d577ccb11?branch=master
> >>> But for me on Fedora it doesn't take minutes:
> >>> $ time grep -rh ^@pytest.mark.\(ds\|bz\)[0-9]\+
> >>>
> >>> real 0m0.144s
> >>> user 0m0.093s
> >>> sys 0m0.050s
> >>>
> >>> How are you running your tests? Is it on OpenSUSE or some other OS?
> >>
> >> It's a known IO performance issue inside of docker.
> > Do you mount a volume with git/tests inside of the container or it's
> > in the container FS itself?
> >>
> >>> Thanks.
> >>>>
> >>>>
> >>>>
> >>>> —
> >>>> Sincerely,
> >>>>
> >>>> William Brown
> >>>>
> >>>> Senior Software Engineer, 389 Directory Server
> >>>> SUSE Labs
> >>>> ___
> >>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> >>>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> >>>> Fedora Code of Conduct: 
> >>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >>>> List Archives: 
> >>>> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >>>
> >>>
> >>>
> >>> --
> >>> Viktor
> >>> ___
> >>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> >>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> >>> Fedora Code of Conduct: 
> >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >>> List Archives: 
> >>> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >>
> >> —
> >> Sincerely,
> >>
> >> William Brown
> >>
> >> Senior Software Engineer, 389 Directory Server
> >> SUSE Labs
> >> ___
> >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> >> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >
> >
> >
> > --
> > Viktor
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: tests take minutes to start

[Viktor Ashirov]

On Wed, May 13, 2020 at 9:13 AM William Brown  wrote:
>
>
>
> > On 13 May 2020, at 17:01, Viktor Ashirov  wrote:
> >
> > Hi,
> >
> > On Wed, May 13, 2020 at 8:31 AM William Brown  wrote:
> >>
> >> Hi all,
> >>
> >> I noticed today that my tests now take minutes to start executing. It 
> >> looks like it's spinning on:
> >>
> >> dirsrv   84605 12.8  0.1  16672  7704 pts/0S+   16:25   0:08 grep -rh 
> >> ^@pytest.mark.\(ds\|bz\)[0-9]\+
> >>
> >> Do we know anything about this? Did we add something in a fixture or 
> >> something to grep for tests? That kind of pattern does look like our bz/ds 
> >> here, so I suspect it comes from us.
> > It is this change:
> > https://pagure.io/389-ds-base/c/6a7a154159583c09fcbba0578eaf576d577ccb11?branch=master
> > But for me on Fedora it doesn't take minutes:
> > $ time grep -rh ^@pytest.mark.\(ds\|bz\)[0-9]\+
> >
> > real 0m0.144s
> > user 0m0.093s
> > sys 0m0.050s
> >
> > How are you running your tests? Is it on OpenSUSE or some other OS?
>
> It's a known IO performance issue inside of docker.
Do you mount a volume with git/tests inside of the container or it's
in the container FS itself?
>
> > Thanks.
> >>
> >>
> >>
> >> —
> >> Sincerely,
> >>
> >> William Brown
> >>
> >> Senior Software Engineer, 389 Directory Server
> >> SUSE Labs
> >> ___
> >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> >> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >
> >
> >
> > --
> > Viktor
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: tests take minutes to start

[Viktor Ashirov]

Hi,

On Wed, May 13, 2020 at 8:31 AM William Brown  wrote:
>
> Hi all,
>
> I noticed today that my tests now take minutes to start executing. It looks 
> like it's spinning on:
>
> dirsrv   84605 12.8  0.1  16672  7704 pts/0S+   16:25   0:08 grep -rh 
> ^@pytest.mark.\(ds\|bz\)[0-9]\+
>
> Do we know anything about this? Did we add something in a fixture or 
> something to grep for tests? That kind of pattern does look like our bz/ds 
> here, so I suspect it comes from us.
It is this change:
https://pagure.io/389-ds-base/c/6a7a154159583c09fcbba0578eaf576d577ccb11?branch=master
But for me on Fedora it doesn't take minutes:
$ time grep -rh ^@pytest.mark.\(ds\|bz\)[0-9]\+

real 0m0.144s
user 0m0.093s
sys 0m0.050s

How are you running your tests? Is it on OpenSUSE or some other OS?
Thanks.
>
>
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Meeting?

[Viktor Ashirov]

On Tue, Feb 11, 2020 at 1:11 PM William Brown  wrote:

> hey everyone,
>
> I joined at UTC+10 22:00, and was in the room for 10 minutes but didn't
> hear from anyone. Did I miss something?
>
The meeting should be next week. I've forwarded you the email.

>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>


-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Please review: PR 50714 - Fix CI test suite issues

[Viktor Ashirov]

https://pagure.io/389-ds-base/pull-request/50714

Thanks!
-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: What is the tier1 pytest mark for?

[Viktor Ashirov]

On Fri, Oct 4, 2019 at 11:52 PM William Brown  wrote:

>
>
> > On 4 Oct 2019, at 17:50, Viktor Ashirov  wrote:
> >
> > Hi,
> >
> > On Fri, Oct 4, 2019 at 7:25 AM William Brown 
> wrote:
> > pytestmark = pytest.mark.tier1
> >
> > I saw this in a test and curious as to it's function? I'm sure it has
> one :)
> > See https://pagure.io/389-ds-base/issue/50353 for more context.
> > We use tier0 and tier1 for downstream component gating (similar to
> https://docs.fedoraproject.org/en-US/ci/gating/ but for RHEL).
> > I.e. 389-ds-base build should pass tier0 and tier1 tests 100% in order
> to land in the compose.
>
> That's a really good explanation, thanks!
>
> So when I'm adding new tests I should choose the tier based on those
> categories I expect?

Right. And if it's a test for a feature/bug fix that's not present in older
versions, please mark it as xfail based on the DS version (for example
https://pagure.io/389-ds-base/c/99f1131226b40e3d385cca66b2b35d5ea8cee582 ).
Thanks.

>
>
> > HTH
> >
> > --
> > Sincerely,
> >
> > William
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >
> >
> > --
> > Viktor
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>


-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: What is the tier1 pytest mark for?

[Viktor Ashirov]

Hi,

On Fri, Oct 4, 2019 at 7:25 AM William Brown 
wrote:

> pytestmark = pytest.mark.tier1
>
> I saw this in a test and curious as to it's function? I'm sure it has one
> :)
>
See https://pagure.io/389-ds-base/issue/50353 for more context.
We use tier0 and tier1 for downstream component gating (similar to
https://docs.fedoraproject.org/en-US/ci/gating/ but for RHEL).
I.e. 389-ds-base build should pass tier0 and tier1 tests 100% in order to
land in the compose.
HTH

>
> --
> Sincerely,
>
> William
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>


-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Issue with building RPMs with ASAN_ON

[Viktor Ashirov]

On Tue, Jun 18, 2019 at 7:54 AM Viktor Ashirov  wrote:

> On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin 
> wrote:
> >
> > Hi team,
> > I'm in the process of creating a Vagrant file which is close to the
> customer's ENV.
> > It is heavilly based on Viktor's beaker task.
> > I use it for building and testing my code. And it is pretty important to
> build with ASAN.
> >
> > Currently, what I do is:
> > 1. Set 'ASAN_ON = 1' in rpm.mk
> > 2. Run `make -f rpm.mk srpms` target
> > 3. Build the RPM using `mock -q my_generated.srpm`
> > 4. Install it
> >
> > Then I've tried running `dscreate` manually or running tests with
> py.test.
> > Every time I have the same error here:
> /run/dirsrv/ns-slapd-standalone1.asan.X
> >
> > ==22487==LeakSanitizer has encountered a fatal error.
> > ==22487==HINT: For debugging, try setting environment variable
> LSAN_OPTIONS=verbosity=1:log_threads=1
> > ==22487==HINT: LeakSanitizer does not work under ptrace (strace,
> gdb, etc)
> Ludwig also recently had this issue. Looks like you're hitting this
> bug: https://github.com/google/sanitizers/issues/723
> We're using posix_memalign() in a few places and LeakSanitizier can't
> handle it.
>
So, the issue Simon was seeing is not related to the issue above.
Turns out, it's just SELinux :)




time->Tue Jun 18 11:27:24 2019


type=AVC msg=audit(1560871644.883:596): avc:  denied  { ptrace } for
 pid=3632 comm="ns-slapd" scontext=system_u:system_r:dirsrv_t:s0
tcontext=system_u:system_r:dirsrv_t:s0
tclass=process permissive=0

[root@server ds]# ausearch -m AVC  | audit2allow








#= dirsrv_t ==


allow dirsrv_t self:process ptrace;



> There is a workaround in the last comment. I did the builds for gcc8
> and gcc9 in copr, both internal and fedora one, but they failed (not
> related to the patch).
> So I did a local build with the patch and it worked like a charm. I
> will share the links to the rpms for you to try.
>
> Perhaps we should review our usage of posix_memalign() or convince the
> upstream to implement a proper fix for this.
> >
> > I've tried setting `export LSAN_OPTIONS=verbosity=1:log_threads=1` and
> run once again.
> > Same issue.
> >
> > Did anybody encountered the issue? Maybe, Viktor or William, could you
> please check?
> > I'm putting the Vagrantfile to the attachments so you can reproduce.
> > Just run: `ASAN=on vagrant up` from the directory with Vagrantfile.
> >
> > William, I think, libvirt is present on SUSE so you should have no
> issues with this too...
> >
> > Thanks,
> > Simon
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
>
>
> --
> Viktor
>


-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Issue with building RPMs with ASAN_ON

[Viktor Ashirov]

On Tue, Jun 18, 2019 at 2:45 PM William Brown  wrote:

>
>
> > On 18 Jun 2019, at 14:38, Viktor Ashirov  wrote:
> >
> >
> >
> > On Tue, Jun 18, 2019 at 2:33 PM William Brown  wrote:
> >
> >
> > > On 18 Jun 2019, at 14:19, Viktor Ashirov  wrote:
> > >
> > >
> > >
> > > On Tue, Jun 18, 2019 at 2:10 PM William Brown  wrote:
> > >
> > > >
> > > > Memalign is pretty important - the short version is "we can not
> remove it".
> > > > I didn't say "remove", I said "review".
> > > >
> > > > There are some structures in the code that rely on this for
> performance to guarantee that they memory is aligned to a page boundary, or
> cache line boundary. In some cases it's required to allow the atomics to
> work in nunc-stans (well, lfds, but the value of that today is questionable
> when the rust version is possibly safer and faster).
> > > > Since you're the expert in this area, maybe you can leave a comment
> in the issue linked above with the justification for upstream to reconsider?
> > >
> > > You mean upstream LSAN/ASAN in this case, yes?
> > > Yes, this https://github.com/google/sanitizers/issues/723
> >
> > Reading the report, that is only about mprotect of alligned memory, not
> of memory that is just aligned. Perhaps our issue is different?
> >
> > Maybe. I only tried the workaround that worked for me. At least I got
> some sensible results, not just LeakSanitizer failure.
>
>
> Where did you find the work around? Maybe I'm blind, but I do not see it
> on this issue 
>
https://github.com/google/sanitizers/issues/723#issuecomment-438265698
I rebuilt gcc with the patch I sent earlier.

>
> >
> > >
> > >
> > > —
> > > Sincerely,
> > >
> > > William Brown
> > >
> > > Senior Software Engineer, 389 Directory Server
> > > SUSE Labs
> > > ___
> > > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > > To unsubscribe send an email to
> 389-devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> > >
> > >
> > > --
> > > Viktor
> > > ___
> > > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > > To unsubscribe send an email to
> 389-devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >
> >
> > --
> > Viktor
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>


-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Issue with building RPMs with ASAN_ON

[Viktor Ashirov]

On Tue, Jun 18, 2019 at 2:33 PM William Brown  wrote:

>
>
> > On 18 Jun 2019, at 14:19, Viktor Ashirov  wrote:
> >
> >
> >
> > On Tue, Jun 18, 2019 at 2:10 PM William Brown  wrote:
> >
> > >
> > > Memalign is pretty important - the short version is "we can not remove
> it".
> > > I didn't say "remove", I said "review".
> > >
> > > There are some structures in the code that rely on this for
> performance to guarantee that they memory is aligned to a page boundary, or
> cache line boundary. In some cases it's required to allow the atomics to
> work in nunc-stans (well, lfds, but the value of that today is questionable
> when the rust version is possibly safer and faster).
> > > Since you're the expert in this area, maybe you can leave a comment in
> the issue linked above with the justification for upstream to reconsider?
> >
> > You mean upstream LSAN/ASAN in this case, yes?
> > Yes, this https://github.com/google/sanitizers/issues/723
>
> Reading the report, that is only about mprotect of alligned memory, not of
> memory that is just aligned. Perhaps our issue is different?
>
> Maybe. I only tried the workaround that worked for me. At least I got some
sensible results, not just LeakSanitizer failure.

>
> >
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >
> >
> > --
> > Viktor
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>


-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Issue with building RPMs with ASAN_ON

[Viktor Ashirov]

On Tue, Jun 18, 2019 at 2:10 PM William Brown  wrote:

>
> >
> > Memalign is pretty important - the short version is "we can not remove
> it".
> > I didn't say "remove", I said "review".
> >
> > There are some structures in the code that rely on this for performance
> to guarantee that they memory is aligned to a page boundary, or cache line
> boundary. In some cases it's required to allow the atomics to work in
> nunc-stans (well, lfds, but the value of that today is questionable when
> the rust version is possibly safer and faster).
> > Since you're the expert in this area, maybe you can leave a comment in
> the issue linked above with the justification for upstream to reconsider?
>
> You mean upstream LSAN/ASAN in this case, yes?
>
Yes, this https://github.com/google/sanitizers/issues/723

>
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>


-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Issue with building RPMs with ASAN_ON

[Viktor Ashirov]

On Tue, Jun 18, 2019 at 9:50 AM William Brown  wrote:

>
>
> > On 18 Jun 2019, at 07:54, Viktor Ashirov  wrote:
> >
> > On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin 
> wrote:
> >>
> >> Hi team,
> >> I'm in the process of creating a Vagrant file which is close to the
> customer's ENV.
> >> It is heavilly based on Viktor's beaker task.
> >> I use it for building and testing my code. And it is pretty important
> to build with ASAN.
> >>
> >> Currently, what I do is:
> >> 1. Set 'ASAN_ON = 1' in rpm.mk
> >> 2. Run `make -f rpm.mk srpms` target
> >> 3. Build the RPM using `mock -q my_generated.srpm`
> >> 4. Install it
> >>
> >> Then I've tried running `dscreate` manually or running tests with
> py.test.
> >> Every time I have the same error here:
> /run/dirsrv/ns-slapd-standalone1.asan.X
> >>
> >>==22487==LeakSanitizer has encountered a fatal error.
> >>==22487==HINT: For debugging, try setting environment variable
> LSAN_OPTIONS=verbosity=1:log_threads=1
> >>==22487==HINT: LeakSanitizer does not work under ptrace (strace,
> gdb, etc)
> > Ludwig also recently had this issue. Looks like you're hitting this
> > bug: https://github.com/google/sanitizers/issues/723
> > We're using posix_memalign() in a few places and LeakSanitizier can't
> handle it.
> > There is a workaround in the last comment. I did the builds for gcc8
> > and gcc9 in copr, both internal and fedora one, but they failed (not
> > related to the patch).
> > So I did a local build with the patch and it worked like a charm. I
> > will share the links to the rpms for you to try.
>
> Which patch?
>
The patch with the workaround mentioned in
https://github.com/google/sanitizers/issues/723
diff --git a/libsanitizer/lsan/lsan_common.cc
b/libsanitizer/lsan/lsan_common.cc
index a4424a887..77d522da6 100644
--- a/libsanitizer/lsan/lsan_common.cc
+++ b/libsanitizer/lsan/lsan_common.cc
@@ -582,7 +582,7 @@ static bool CheckForLeaks() {
 "LSAN_OPTIONS=verbosity=1:log_threads=1\n");
 Report(
 "HINT: LeakSanitizer does not work under ptrace (strace, gdb,
etc)\n");
-Die();
+return false;
   }
   param.leak_report.ApplySuppressions();
   uptr unsuppressed_count = param.leak_report.UnsuppressedLeakCount();



>
> >
> > Perhaps we should review our usage of posix_memalign() or convince the
> > upstream to implement a proper fix for this.
>
> Memalign is pretty important - the short version is "we can not remove it".
>
I didn't say "remove", I said "review".

>
> There are some structures in the code that rely on this for performance to
> guarantee that they memory is aligned to a page boundary, or cache line
> boundary. In some cases it's required to allow the atomics to work in
> nunc-stans (well, lfds, but the value of that today is questionable when
> the rust version is possibly safer and faster).
>
Since you're the expert in this area, maybe you can leave a comment in the
issue linked above with the justification for upstream to reconsider?

>
> >>
> >> I've tried setting `export LSAN_OPTIONS=verbosity=1:log_threads=1` and
> run once again.
> >> Same issue.
> >>
> >> Did anybody encountered the issue? Maybe, Viktor or William, could you
> please check?
> >> I'm putting the Vagrantfile to the attachments so you can reproduce.
> >> Just run: `ASAN=on vagrant up` from the directory with Vagrantfile.
> >>
> >> William, I think, libvirt is present on SUSE so you should have no
> issues with this too...
>
> It is, but I run on a mac so ... my setup is fun fun fun :)
>
> I would normally run this on my home lab, but I'm a few thousand km's away
> 
>
> >>
> >> Thanks,
> >> Simon
> >> ___
> >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> >> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >
> >
> >
> > --
> > Viktor
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fed

[389-devel] Re: Issue with building RPMs with ASAN_ON

[Viktor Ashirov]

On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin  wrote:
>
> Hi team,
> I'm in the process of creating a Vagrant file which is close to the 
> customer's ENV.
> It is heavilly based on Viktor's beaker task.
> I use it for building and testing my code. And it is pretty important to 
> build with ASAN.
>
> Currently, what I do is:
> 1. Set 'ASAN_ON = 1' in rpm.mk
> 2. Run `make -f rpm.mk srpms` target
> 3. Build the RPM using `mock -q my_generated.srpm`
> 4. Install it
>
> Then I've tried running `dscreate` manually or running tests with py.test.
> Every time I have the same error here: 
> /run/dirsrv/ns-slapd-standalone1.asan.X
>
> ==22487==LeakSanitizer has encountered a fatal error.
> ==22487==HINT: For debugging, try setting environment variable 
> LSAN_OPTIONS=verbosity=1:log_threads=1
> ==22487==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
Ludwig also recently had this issue. Looks like you're hitting this
bug: https://github.com/google/sanitizers/issues/723
We're using posix_memalign() in a few places and LeakSanitizier can't handle it.
There is a workaround in the last comment. I did the builds for gcc8
and gcc9 in copr, both internal and fedora one, but they failed (not
related to the patch).
So I did a local build with the patch and it worked like a charm. I
will share the links to the rpms for you to try.

Perhaps we should review our usage of posix_memalign() or convince the
upstream to implement a proper fix for this.
>
> I've tried setting `export LSAN_OPTIONS=verbosity=1:log_threads=1` and run 
> once again.
> Same issue.
>
> Did anybody encountered the issue? Maybe, Viktor or William, could you please 
> check?
> I'm putting the Vagrantfile to the attachments so you can reproduce.
> Just run: `ASAN=on vagrant up` from the directory with Vagrantfile.
>
> William, I think, libvirt is present on SUSE so you should have no issues 
> with this too...
>
> Thanks,
> Simon
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: How to create a user with certificate with lib389

[Viktor Ashirov]

On Fri, Jun 14, 2019 at 9:28 AM William Brown  wrote:
>
>
>
> > On 13 Jun 2019, at 16:09, Viktor Ashirov  wrote:
> >
> > On Thu, Jun 13, 2019 at 3:26 PM William Brown  wrote:
> >>
> >> Is the test case *just* testing if binary searching of attributes works?
> > The test was to check if we can query the server for
> > userCertificate=, where  is a string representation of a
> > base64 encoded x509 certificate. The original test was also passing
> > binary representation (usercertificate;binary=...) to ldapsearch (to
> > see if it translates correctly to base64).
>
> Thanks for telling me what the test is meant to do! This is what I wanted to 
> know from the start ...
Thank you for your patience. I'm sorry I missed this email thread, I'd
replied sooner to reduce the confusion.
To give some context: this test case also was testing client tools
(mozldap) to support binary filters. But this test case didn't age
well, so your approach below should be sufficient.
Thanks!
>
> So the base64 is only if the attribute is "longer" than a certain amount the 
> ldapclient tools base64 it for viewing - the server actually doesn't care or 
> know that it's going on at all, so really, this is a test if binary matching 
> works.
>
> You can thus, setup a simpler test by setting
>
> with open('/tmp/test') as f:
> data = f.readlines()  # or read(), I can't remember what does it all 
> without newlines)
> Account.set('usercertificate', data)
> Accounts.filter('userCert=%b' % data)
>
> So then I'd tweak if it's %b or %s, I'd probably also to see what works and 
> prevents python leaking state or formatting.
>
> Then work up to a full certificate.
>
> If you have a failuing example, please send me the access log and -v 
> (DEBUGGING=True) lib389 output so I can help
>
> Thanks,
>
>
> >
> > --
> > Viktor
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: How to create a user with certificate with lib389

[Viktor Ashirov]

On Thu, Jun 13, 2019 at 3:26 PM William Brown  wrote:
>
> Is the test case *just* testing if binary searching of attributes works?
The test was to check if we can query the server for
userCertificate=, where  is a string representation of a
base64 encoded x509 certificate. The original test was also passing
binary representation (usercertificate;binary=...) to ldapsearch (to
see if it translates correctly to base64).

-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Viktor Ashirov]

On Tue, May 7, 2019 at 2:09 PM William Brown  wrote:
>
>
>
> > On 7 May 2019, at 22:03, Viktor Ashirov  wrote:
> >
> > On Mon, Apr 29, 2019 at 6:48 AM William Brown  wrote:
> >>
> >>
> >>
> >>> On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
> >>>
> >>> @William Brown
> >>>
> >>> Thanks for the tip!
> >>>
> >>> (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, 
> >>> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> >>>  ['attrlist=cn:sn:uid:testUserAccountControl']))
> >>> 6
> >>> (Pdb) len(Accounts(topo.standalone, 
> >>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> >>> 6
> >>>
> >>> We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with 
> >>> filter , like we do with search_s .
> >>>
> >>> (Pdb) len(Accounts(topo.standalone, 
> >>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> >>>  ['attrlist=cn:sn:uid:testUserAccountControl']))
> >>> *** TypeError: filter() takes 2 positional arguments but 3 were given
> >>> (Pdb) len(Accounts(topo.standalone, 
> >>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> >>>  ['attrlist=cn:sn:uid:testUserAccountControl']"))
> >>> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 
> >>> 'No such file or directory'}
> >>>
> >>> Again i have to use "re" module for the same .
> >>>
> >>>
> >>
> >> What are you trying to achieve?
> > Test case is very simple: search for entries using different filters
> > and request specific attributes.
>
> But those entries have types and classes - you know what you are expecting to 
> get.
>
> > The problem that Anuj is facing is that filter() doesn't support
> > attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
> > attributes, it omits operational attributes (like nsRoleDN).
> > IMHO, search_s is good enough here.
>
> If you want to avoid any of the "magic" use DSLdapObjects(instance).filter() 
> then because that doesn't prescribe any classes. But it does take a lot of 
> the safety out of the library, and I still think that there is something 
> missing in the approach here.
I have a problem with DSLdapObjects(instance).filter() is that it
takes way more effort to write *test* code with a very little benefit.
Consider this example: I need to fetch all regular attributes,
operational attributes and entry state information from the server.
With DSLdapObjects I had to do the following:
(Pdb) _ = Accounts(topo.standalone, DEFAULT_SUFFIX)
(Pdb) _._filterattrs=["*", "+", "nscpEntryWSI"]
(Pdb) _.filter(F10)[0].get_all_attrs()

get_all_attrs() doesn't return nscpEntryWSI at all, and, as a bonus,
lowercases some of the attribute names.

vs.

(Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
attrlist=["*", "+", "nscpEntryWSI"])

Safety here is not a main concern, since it's a test code. In tests we
need more than often to have a raw LDAP access without too much
abstractions. Main concern is precision and certainty.
Abstractions are good when they increase clarity and make things
certain. In case of the very common search pattern above, DSLdapObject
doesn't work really well. For me at least.
>
>
> >>
> >>
> >> Sincerely,
> >>
> >> William Brown
> >>
> >> Senior Software Engineer, 389 Directory Server
> >> SUSE Labs
> >> ___
> >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> >> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >
> >
> >
> > --
> > Viktor
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archive

[389-devel] Re: Groups are not accessible by filter

[Viktor Ashirov]

On Mon, Apr 29, 2019 at 6:48 AM William Brown  wrote:
>
>
>
> > On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > Thanks for the tip!
> >
> > (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, 
> > ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> >  ['attrlist=cn:sn:uid:testUserAccountControl']))
> > 6
> > (Pdb) len(Accounts(topo.standalone, 
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> > 6
> >
> > We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with 
> > filter , like we do with search_s .
> >
> > (Pdb) len(Accounts(topo.standalone, 
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> >  ['attrlist=cn:sn:uid:testUserAccountControl']))
> > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > (Pdb) len(Accounts(topo.standalone, 
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> >  ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 
> > 'No such file or directory'}
> >
> > Again i have to use "re" module for the same .
> >
> >
>
> What are you trying to achieve?
Test case is very simple: search for entries using different filters
and request specific attributes.
The problem that Anuj is facing is that filter() doesn't support
attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
attributes, it omits operational attributes (like nsRoleDN).
IMHO, search_s is good enough here.
>
>
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



--
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: 389 DS nightly 2019-01-15 - 0% PASS

[Viktor Ashirov]

On Tue, Jan 15, 2019 at 1:45 AM William Brown  wrote:
>
> Why are we using setup-ds.pl on 1.4.x at all? :S
To catch all the broken things :P
https://pagure.io/389-ds-base/pull-request/50125#comment-72746

But actually it's because we build from master with the same config
(with perl tools) as in Fedora and RHEL, because they are still
shipped there and need regression testing.
>
> > On 15 Jan 2019, at 10:33, vashi...@redhat.com wrote:
> >
> > https://fedorapeople.org/groups/389ds/ci/nightly/2019/01/15/report-389-ds-base-1.4.0.20-20190115git0666b52.fc29.x86_64.html
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: 389 DS nightly 2019-01-10 - 93% PASS

[Viktor Ashirov]

On Thu, Jan 10, 2019 at 8:03 AM William Brown  wrote:
>
> Hey there,
>
> I think we are missing a large suite of tests from: src/lib389/lib389/tests
>
> Should we move these into the suites? Or should we add this path to the CI?
We wanted to decouple some tests from lib389 tests directory and move
them under dirsrvtests.
There is a ticket open for this separation:
https://pagure.io/389-ds-base/issue/50023
One of the issues was lib389.topologies usage. It shouldn't be shipped
and ideally should be converted to conftest.py fixtures for
dirsrvtests. Lib389 tests that use topologies should also be moved to
dirsrvtests. I want to leave only unit tests and run them with tox,
but I hit problems with venv (PR#50085) and selinux (you fixed this in
PR#50124). So once this is fixed, I will move the tests and include
them in nightlies.
>
>
>
> > On 10 Jan 2019, at 13:10, vashi...@redhat.com wrote:
> >
> > https://fedorapeople.org/groups/389ds/ci/nightly/2019/01/10/report-389-ds-base-1.4.0.20-20190110git50e290d.fc29.x86_64.html
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
> --
> Sincerely,
>
> William
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Error building manpages in setup.py

[Viktor Ashirov]

On Fri, Aug 3, 2018 at 3:22 AM William Brown  wrote:
>
> make[2]: Leaving directory '/home/william/build/ds'
> make[1]: Leaving directory '/home/william/build/ds'
> make -j1 -C ~/build/ds lib389
> make[1]: Entering directory '/home/william/build/ds'
> cd /home/william/development/389ds/ds/src/lib389; python3 setup.py
> build ; python3 setup.py build_manpages
> Traceback (most recent call last):
>   File "setup.py", line 17, in 
> from build_manpages import build_manpages
> ModuleNotFoundError: No module named 'build_manpages'
> Traceback (most recent call last):
>   File "setup.py", line 17, in 
> from build_manpages import build_manpages
> ModuleNotFoundError: No module named 'build_manpages'
> make[1]: *** [Makefile:14617: lib389] Error 1
> make[1]: Leaving directory '/home/william/build/ds'
> make: *** [Makefile:51: ds] Error 2
>
> What package provides build_manpages?
In Fedora it is python3-argparse-manpage.
>
> pip search manpage
> sphinxcontrib-manpage (0.4)  - Sphinx linux manpage extension
> manpage (0.1)- Functionality to create Unix manual
> pages.
> argparse-manpage (1.1)   - Build manual page from python's
Looks like this one.
> ArgumentParser object.
> cli2man (0.2.4)  - Converts the help message of a program
> into a manpage
> xmlmp (1.0)  - Simple XML-based manpage authoring tools
>
> And then I'll need to work out the relevant rpm or dep (I've swapped to
> openSUSE also, so that'll be fun ;)
>
> Thanks!
>
> --
> Sincerely,
>
> William
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/J5RE6FCHLTAM3SKDKXMHIARJTMEO3X55/



-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/IZR7IHGK3BFM2J67JOT2XDFFY6QJGMRS/

[389-devel] Please review: Issue 49820 - lib389 requires wrong python ldap library

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49820
https://pagure.io/389-ds-base/pull-request/49821
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/IM5X4276Z52RNXF7VGL77WSJYVMC2KHU/

[389-devel] Please review: Issue 49588 - Add py3 support for tickets

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49588

https://pagure.io/389-ds-base/pull-request/49810

-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/3SRWMK3ZXIFTMYENFBHVLDOYJNUGOO7U/

[389-devel] Re: New DS CLI design

[Viktor Ashirov]

On Fri, May 25 2018 at 10:19:26 +1000, William Brown  
wrote:
>> 
>> You treat  as a broad concept, when in fact it is a
>> parameter
>> that is a subject to change. We should use keyword, not a parameter.
>
>
> Instance IS a broad concept. I don't administer 2 or more instances
> generally on a server. There is a 1:1 ratio of DS to servers in the
> wild generally. And even if I have multiple servers, I am generally
> focused on one.
>
> So I want to do:
>
> ds* instance thing 
>
> and I'm going to change "" between commands.
ds* instance -i  thing
>
>> 
>> Here are few problems with the current design:
>> * dsctl has "remove" subcommand, but "create" is separate in dscreate
>>   command. 
>> 
>> It can be solved with the same logic that you mentioned above:
>> dsctl instance create ...
>> dsctl instance remove 
>
> There is excellent logic and research behind this design. It comes down
> to instance discovery and the allocation of the DirSrv object.
>
> Earlier versions of this tool had:
>
> dsctl create
> dsctl stop instance
> dsctl remove instance
>
> What resulted was every Subcommand group had to parse and setup
> instance itself. It was a huge spew of boilerplate, and it also made
> the command NOT match the dsconf and dsidm commands that took:
>
> dsidm instance user 
>
> So in order to keep a consistent design across all the tools, I decided
> that instance should be second - I didn't just make the decision, I
> actually contacted a group of LDAP admins and asked them what they
> preferred. Instance is the broad topic I am working under, and I tend
> to change parameters at the tail of the command, like user create, then
> user edit, or user list. 
>
> Now the second part. If you have:
>
> dsctl instance create
>
> What's the issue? Well in the design of dsctl, this means we have to
> delay instance allocation to very late in the command's processing, and
> means that errors are not reported correctly, it makes the design
> really complex, and horrendous, and it just made for bad code logic.
>
> So in the end I made a choice to split dscreate out. 
>
> dscreate works on the absence of an instance. 
> dsctl works on a local instance you have root access too. 
> dsconf works on a remote instance via cn=config. 
> dsidm manages a backend of an instance.
As I mentioned before, we have too many tools already, which sit in ds*
namespace. It's hard to tell by name which one is doing what. Why there
is dscreate, but no dsremove? Why dsidm is so opinionated? Each
installation has its own requirements to OCs, has custom schema, etc.
This tool doesn't fit everyone's needs. I can't use it on my custom DIT
that is tailored for my organization needs, so why ship this tool at
all? If I want IdM, I'd use IPA.

My point is that we shouldn't have so many tools, but rather one, that
can be used for remote and local instances. Then there is no need to
jump around different command line syntaxes since there will be just
one.
>
> Huge amounts of work were put in into this design, it's not just magic
> from no where. The first versions of these tools were created in 2016
> at pycon AU, and have been evolving (and rewritten) since based on
> usage and trials. :)  
Well, here's my first experience and I find it confusing. Does that
count? And if this tool has been around since 2016, why I still can't
find man pages for it?
>
>> 
>> We can prepend all instance specific tasks with "instance" word, we
>> can
>> even short it to "inst" or "i", similar to GDB commands for those,
>> who
>> doesn't like type. So we have a broad concept of "instance", and
>> specific actions are followed by parameters like instance name.
>> 
>> * "dsctl  status" shows only one instance status, and there
>> is
>>   no easy way to get status of all instances on the server, besides
>>   falling back to systemctl.
>> 
>> Consider this:
>> dsctl status -- shows status of all instances
>> dsctl status   ..  -- shows status
>> of
>>   specified instances
>
> I'm sorry, but I do not agree. I do not work across 16 instances at
> once. I focus on one and conduct a task. Most installs only have one.
>
> We should not focus on the idea that we have the capability for
> multiple instances. I would guarantee almost 95% or more deployments
> have a single instance per server, and would never "gain" from the
> excess work done here to support many instances, and the "divergent"
> command line formats would cause confusion.
We use multiple instances in QA and development. That 5% would benefit
to all, since the tool won't be so stiff and can be used for both
scenarios.
>
> For example: do I want to perform "user create" on 13 instances at
> once? See how suddenly the command logic breaks down suddently?
Some actions can require multiple instances as an argument. 'status' is
one of them. 'user create' is not. Other commands that might require
that - stop/start replication agreements, add indices, reindex db, etc. 

> the instance 

[389-devel] Please review: Issue 49717 - Add conftest.py for tests

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49717

https://pagure.io/389-ds-base/pull-request/49718


signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/XUPLZUH6SYVQY3R7MFIN3ISA3WFJNQNW/

[389-devel] Re: New DS CLI design

[Viktor Ashirov]

Hi William,
On Thu, May 24 2018 at 09:06:14 +1000, William Brown <will...@blackhats.net.au> 
wrote:
> On Wed, 2018-05-23 at 11:34 +0200, Viktor Ashirov wrote:
>> Hi,
>> 
>> I'd like to continue our discussion about feature parity with perl
>> tools
>> and overall user experience of the new CLI tools.
>> 
>> Here are some projects where we can take inspiration for our own
>> design:
>> 
>> * bpython interpreter
>>   https://bpython-interpreter.org/screenshots.html
>> 
>> * fish shell
>>   http://fishshell.com/docs/current/design.html
>> 
>> * Python Prompt Toolkit
>>   https://github.com/jonathanslenders/python-prompt-toolkit
>>   (it's used to build tools like pgcli and mycli: https://github.com/
>> dbcli)
>> 
>> * OpenStack CLI:
>>   https://docs.openstack.org/python-openstackclient/pike/cli/commands
>> .html
>>   https://docs.openstack.org/python-openstackclient/pike/cli/interact
>> ive.html
>> 
>> Common theme is that all of these CLIs are primarily used in REPL
>> mode,
>> but they can be used in script mode as well.
>> 
>> Here's the quote from fish shell's design page about the law of
>> discoverability:
>> 
>> * Everything should be tab-completable, and every tab completion
>> should
>>   have a description.
>> 
>> * Every syntax error and error in a built-in command should contain
>> an
>>   error message describing what went wrong and a relevant help page.
>>   Whenever possible, errors should be flagged red by the syntax
>>   highlighter.
>> 
>> * The help manual should be easy to read, easily available from the
>>   shell, complete and contain many examples
>> 
>> * The language should be uniform, so that once the user understands
>> the
>>   command/argument syntax, they will know the whole language, and be
>>   able to use tab-completion to discover new features.
>> 
>
> Hey there,
>
> When building these tools I took a lot of inspriation from the
> openshift tools actually, but there is a logic to the design.
I like the design of openshift tools, but I think we have a flaw in our
implementation of this logic.

> Everything goes from "least specific" to "most specific"
>
> So for example, 
>
> dsctl start 
>
> This doesn't make sense because you have a "specific" action, before
> the "broad concept" of an instance.
>
> So everything is in the pattern of:
>
> dsctl  start/thing 
> dsidm  user create 
>
> Everything goes from least specific to most. 
>
You treat  as a broad concept, when in fact it is a parameter
that is a subject to change. We should use keyword, not a parameter.

Here are few problems with the current design:
* dsctl has "remove" subcommand, but "create" is separate in dscreate
  command. 

It can be solved with the same logic that you mentioned above:
dsctl instance create ...
dsctl instance remove 

We can prepend all instance specific tasks with "instance" word, we can
even short it to "inst" or "i", similar to GDB commands for those, who
doesn't like type. So we have a broad concept of "instance", and
specific actions are followed by parameters like instance name.

* "dsctl  status" shows only one instance status, and there is
  no easy way to get status of all instances on the server, besides
  falling back to systemctl.

Consider this:
dsctl status -- shows status of all instances
dsctl status   ..  -- shows status of
  specified instances


> I actually did put a lot of work into these based on design principles
> already. About all we are missing is tab complete, and IIRC there is a
> python argparse module for that which should work given our design. 
I'm not sure how argparse can help here, because in that case we're
relying on shell's support for autocompletion. It might not work, it
might be not enabled. Moreover, "ds" namespace is overloaded. Here's the
output on my F28 box:

# ds 
ds-cockpit-setup dsidmds_selinux_port_query
dsconf   ds-logpipe.py
ds_systemd_ask_password_acl
dscreate ds-replcheck 
dsctlds_selinux_enabled   

Some of these commands are moved to a proper place in master, but that
still leaves us with at least:
dsconf
dscreate
dsctl
dsidm

Without looking at man pages (which do not exist, btw), it's hard to
tell what each of these commands does. What's the difference between
dsctl and dsconf? I need to run all of these with --help to get more
information.

In REPL mode I can press  and get context-aware hel

[389-devel] New DS CLI design

[Viktor Ashirov]

Hi,

I'd like to continue our discussion about feature parity with perl tools
and overall user experience of the new CLI tools.

Here are some projects where we can take inspiration for our own design:

* bpython interpreter
  https://bpython-interpreter.org/screenshots.html

* fish shell
  http://fishshell.com/docs/current/design.html

* Python Prompt Toolkit
  https://github.com/jonathanslenders/python-prompt-toolkit
  (it's used to build tools like pgcli and mycli: https://github.com/dbcli)

* OpenStack CLI:
  https://docs.openstack.org/python-openstackclient/pike/cli/commands.html
  https://docs.openstack.org/python-openstackclient/pike/cli/interactive.html

Common theme is that all of these CLIs are primarily used in REPL mode,
but they can be used in script mode as well.

Here's the quote from fish shell's design page about the law of
discoverability:

* Everything should be tab-completable, and every tab completion should
  have a description.

* Every syntax error and error in a built-in command should contain an
  error message describing what went wrong and a relevant help page.
  Whenever possible, errors should be flagged red by the syntax
  highlighter.

* The help manual should be easy to read, easily available from the
  shell, complete and contain many examples

* The language should be uniform, so that once the user understands the
  command/argument syntax, they will know the whole language, and be
  able to use tab-completion to discover new features.

Please let me know what do you think.

Thanks!

--
Viktor


signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/QFJVIX5CTRPBA2VPZIEXUDCZG7L2TS2O/

[389-devel] Please review: Issue 49684 - AC_PROG_CC clobbers CFLAGS set by --enable-debug

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49684

https://pagure.io/389-ds-base/pull-request/49690


signature.asc
Description: PGP signature
___
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: Issue 49684 - AC_PROG_CC clobbers CFLAGS set by --enable-debug

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49684

https://pagure.io/389-ds-base/pull-request/49686


signature.asc
Description: PGP signature
___
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: Issue 49685 - make clean fails if cargo is not installed

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49685

https://pagure.io/389-ds-base/pull-request/49687


signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: lib389 usage cheatsheet

[Viktor Ashirov]

On Mon, May 14 2018 at 13:16:02 +1000, William Brown  
wrote:
> On Fri, 2018-05-11 at 09:41 +0200, Simon Pichugin wrote:
>> Hi Thierry,
>> I agree with you, it was exactly my proposition :)
>> 
>> Keeping main python-ldap elements is important because we don't want
>> to implement or mask/wrap this basic functionality (like working with
>> controls, etc)
>> we just want to redirect them.
>> 
>> Ideally, we should make our admin library very intuitive for the
>> people
>> who already knows python-ldap and just LDAP concepts.
>
> The issue is that if we want to use python-ldap, we wouldn't have
> lib389. We'd just use raw ldap all over the place  
>
>> 
>> I will continue adding more information to the docs regarding
>> DSLdapObject
>> and I'll try to make it a bit closer to LDAP concepts (at least in
>> wording), I already have something in mind.
>> 
>> Thanks,
>> Simon
>
>> 1. I think it is okay to use instance.add_s and instance.modify_s
>>for simple operations.
>
> The issue here is that Entry() isn't py3 safe. It also really limits
> what we can do, and the whole "dirsrv is a subclass of
> simpleldapobject" and intercepts operations to create Entry is just
> complex.
>
>> 2. If you'd like to make your life easier, you can use DSLdapObjects
>> API
>>(and I'll help you with that)
>> 3. We should stop using old lib389 API because we don't support it
>> anymore
>>and it will be depricated in the future. We should use
>> DSLdapObject
>>instead and we should improve it if we don't like something about
>> it.
>
>
> The point of DSLdapObject is to:
>
> * capture knowledge of administration to an accessible api
> * To make a bridge between py2/3
> * to give a higher level abstraction that "raw ldap" (which is frankly
> unusable)
> * to allow the elimination of Entry() and the DirSrv subclassing of
> simple ldap object.
>
> So everytime you find your self writing ".add_s()" or ".modify_s()",
> it's REALLY LIKELY that an adminsitrator needs to do this too!
It's not just about CLI tools. Please don't forget about tests. There we
need fine-grained access to LDAP primitives to write correct
reproducers. High level abstractions can stand in a way and do not
*exactly* do what is required.
>
> And although it's more work to encapsulate this to dsldapobject, it
> means we have implemented it once and can re-use it - and the jump from
> dsldapobject to a cli tool is very very short. It also makes the new
> webui easier because that will need to access all those apis too!
>
> There is much more vision here in this api then maybe I let on. It's a
> much bigger scope than some convinence functions, it's actually a
> gateway to ldap administration to eliminate the unusability of ldap.
>
> Of course, given my history with lib389, I would strongly advise us to
> follow options 2 or 3. I'm also happy to write up and knowledge
> transfer anything needed for the team. (And I apologise deeply for my
> recent abscence on mailing lists, I was traveling, and needed some time
> off).
>
> Thanks,
>
> William,
>
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org


signature.asc
Description: PGP signature
___
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: Issue 49678 - organiSational vs organiZational spelling in lib389

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49678

https://pagure.io/389-ds-base/pull-request/49681

--
Viktor


signature.asc
Description: PGP signature
___
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: Issue 49679 - Missing nunc-stans documentation and doxygen warnings

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49679

https://pagure.io/389-ds-base/pull-request/49680

--
Viktor


signature.asc
Description: PGP signature
___
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: Issue 49106 - Move ds_* scripts to libexec

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49106

https://pagure.io/389-ds-base/pull-request/49633

--
Viktor


signature.asc
Description: PGP signature
___
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: 389-ds-base package rebuilt on EPEL can't be installed due to missing dependencies

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49603

https://pagure.io/389-ds-base/pull-request/49604


signature.asc
Description: PGP signature
___
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: Issue 49542 - Unpackaged files on el7 break rpm build

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49542

https://pagure.io/389-ds-base/issue/raw/files/b86d47927141e4823eb44826374803435a69a513c45f2b5af59690e88552fc76-0001-Issue-49542-Unpackaged-files-on-el7-break-rpm-build.patch




signature.asc
Description: PGP signature
___
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: Issue 49530 - Add pseudolocalization option for dbgen

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49530

https://pagure.io/389-ds-base/issue/raw/files/3f9866675f564c1b9b978f92ca56fdd300f24bf69840d2b03603fd93ca1eeffc-0001-Issue-49530-Add-pseudolocalization-option-for-dbgen.patch


signature.asc
Description: PGP signature
___
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: Issue 49485 - Typo in gccsec_defs

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49485

https://pagure.io/389-ds-base/issue/raw/files/f65eb81ead8a83a251c1385ebf2160c4de735f7ba46949892404a83712a4b4a4-0001-Issue-49485-Typo-in-gccsec_defs.patch


signature.asc
Description: PGP signature
___
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: Issue 49451 - Add environment markers to lib389 dependencies

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49451

https://pagure.io/389-ds-base/issue/raw/files/1edc0eca851d6ee33e7e9a6ce832254545cb9cd1123f810248455b1e003a8fd0-0001-Issue-49451-Add-environment-markers-to-lib389-depend.patch



signature.asc
Description: PGP signature
___
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: Issue 49434 - RPM build errors

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49434

https://pagure.io/389-ds-base/issue/raw/files/0e9fa41dad063026dabae27cc70a2583a82d2c42aae3f05c73f3cc00fe892388-0001-Issue-49434-RPM-build-errors.patch



signature.asc
Description: PGP signature
___
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: Issue 49409 - Update lib389 requirements

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49409

https://pagure.io/389-ds-base/issue/raw/files/b3f493ed9a37d69e5010330d038d632da12ae390f84efb180bb9f7527556b58e-0001-Issue-49409-Update-lib389-requirements.patch


signature.asc
Description: PGP signature
___
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: Issue 49400 - Add clang support to rpm builds

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49400

https://pagure.io/389-ds-base/issue/raw/files/2bc0af51505472748cfebf4098ff6ab8f8d60ef4b9eae833431100d09b021a6a-0001-Issue-49400-Add-clang-support-to-rpm-builds.patch



signature.asc
Description: PGP signature
___
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: Issue 48081 - CI test - password

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/48081

https://pagure.io/389-ds-base/issue/raw/files/fbee362e98a949d6366cafc66b26a198d024b2f798bf8b70cc7e4a8507bbf94f-0001-Issue-48081-CI-test-password.patch




signature.asc
Description: PGP signature
___
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: Issue 49295 - Fix CI tests

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49295

https://pagure.io/389-ds-base/issue/raw/files/2f0dc7dde205e6ef303729a72910567689ba0133aab7efcd8e676b8a6d2e7089-0001-Issue-49295-Fix-CI-tests.patch



signature.asc
Description: PGP signature
___
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 #73

[Viktor Ashirov]

On Fri, Sep 08 2017 at 06:34:24 +0200, marey...@redhat.com wrote:

> === FAILURES 
> ===
>  test_default_behavior 
> _
>
> topology_st = 
> global_policy_default = None, add_user = None
>
> def test_default_behavior(topology_st, global_policy_default, add_user):
> """Test the default behavior of password
> expiry warning time
> 
> :ID: c47fa824-ee08-4b78-885f-bca4c42bb655
> :feature: Password Expiry Warning Time
> :setup: Standalone DS instance with,
> 1. Global password policy configured as follows,
>passwordExp: on
>passwordMaxAge: 86400
>passwordWarning: 86400
>passwordSendExpiringTime: off
> 2. User entry for binding to the server
> :steps: 1. Bind as the user
> 2. Request the control for the user
> :expectedresults: Password expiry warning time should be returned by 
> the
>   server by the server since passwordMaxAge and
>   passwordWarning are set to the same value
> """
> 
> res_ctrls = None
> try:
> log.info("Binding with {:s} and requesting the password expiry 
> warning time" \
>  .format(USER_DN))
> res_ctrls = get_password_warning(topology_st)
> 
> log.info('\''Check that control is returned even'\''
>  '\''if passwordSendExpiringTime is set to off'\'')
>>   assert res_ctrls
> E   assert []
>

I broke this one by adjusting global_policy_defaults fixture to have the
actual defaults that we have in the slap.h:
./ldap/servers/slapd/slap.h:#define SLAPD_DEFAULT_PW_MAXAGE 864
./ldap/servers/slapd/slap.h:#define SLAPD_DEFAULT_PW_MAXAGE_STR "864"
./ldap/servers/slapd/slap.h:#define SLAPD_DEFAULT_PW_WARNING 86400
./ldap/servers/slapd/slap.h:#define SLAPD_DEFAULT_PW_WARNING_STR "86400"

So the original test was not testing the default behavior, but another
case where PW_MAXAGE and PW_WARNING are the same. I'll send a fix today.

--
Viktor


signature.asc
Description: PGP signature
___
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: Issue 49295 - Fix CI tests

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49295

https://pagure.io/389-ds-base/issue/raw/files/eca54ddf3248bea2f57e181167546d647bdfb7475a5b910f90ff4e766e066eda-0001-Issue-49295-Fix-CI-tests.patch


signature.asc
Description: PGP signature
___
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: Issue 49349 - global name 'imap' is not defined

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49349

https://pagure.io/389-ds-base/issue/raw/files/afdefcb51b7da430e34ec8830a94c4c5c592edd7a1972adb3c1df8df27208b2d-0001-Issue-49349-global-name-imap-is-not-defined.patch


signature.asc
Description: PGP signature
___
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?

[Viktor Ashirov]

Hi William,
On Tue, Aug 01 2017 at 16:00:23 +1000, William Brown  wrote:
> Hi all,
>
> Last night on IRC we were discussing the curious case of lib389. I think
> this is a discussion we should have at some point.
>
> The question really boils down to - "is lib389 a seperate project? Or is
> it part of 389-ds-base?"
>
> There are some pros and cons to both view points. 
>
> lib389 is a python library that exposes high level interactions with 389
> directory server. This is done by making various calls via LDAP to the
> server. 
>
> The issue is that we have a split: we have tests in
> 389-ds-base/dirsrvtests that are often *version* dependent. They relate
> to features of the server, or issues in specific versions of the server
> that may not exist in older versions. Today we kind of stradle the line
> of "it's a bit of both". We have tests in 389-ds-base that depend on
> versions of lib389 - but lib389 moves quickly and has little ability to
> distinguish 389-ds-base versions.
I don't think that we will avoid version dependency completely. These
days we mark tests that can't be executed on the older versions of DS
with skipif fixture as we run tests from master branch.
>
> -- 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.
>
> Pros:
> * No need to separate version lib389 to ds. lib389 is guaranteed to work
> with *that* version of DS
> * 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.
> * 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?
> * 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?
>
> 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.
>
> 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?
>
> For example, this would make the CI workflow much simpler as we just get
> 

[389-devel] Please review: Issue 49306 - make -f rpm.mk rpms produces build without

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49306

https://pagure.io/389-ds-base/issue/raw/acca6645dcd1626b16719d56faa696392f6ff2e58787406d5eba6664d9468471-0001-Issue-49306-make-f-rpm.mk-rpms-produces-build-withou.patch


signature.asc
Description: PGP signature
___
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: Issue 48864 - Fix FreeIPA build

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/48864

https://pagure.io/389-ds-base/issue/raw/files/1c67169f0fc1ef066c7d625698fae3dea965e80548e637c1cae0e975048287e7-0001-Issue-48864-Fix-FreeIPA-build.patch


signature.asc
Description: PGP signature
___
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: Issue 49159 - test_schema_comparewithfiles fails with python-ldap>=2.4.26

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49159

https://pagure.io/389-ds-base/issue/raw/files/6ee1eb7319ffb0c4aba546a23f45233c38308e4731c28c189b3d594f6e306141-0001-Issue-49159-test_schema_comparewithfiles-fails-with-.patch


signature.asc
Description: PGP signature
___
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: Issue 49122 - Fix rpm build

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49122

https://pagure.io/389-ds-base/issue/raw/files/07e70f3f62cb8eb08186b7538aec5be6e6b465121cd03d46c7d3a3b16730e29b-0001-Issue-49122-Fix-rpm-build.patch


signature.asc
Description: PGP signature
___
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: Ticket 49108 - ds_selinux_port_query doesn't detect ports

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/49108

https://fedorahosted.org/389/attachment/ticket/49108/0001-Ticket-49108-ds_selinux_port_query-doesn-t-detect-po.patch


signature.asc
Description: PGP signature
___
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: Ticket 49057 - Fix tests failures on older versions of DS - rebased on master

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/49057

https://fedorahosted.org/389/attachment/ticket/49057/0001-Ticket-49057-Fix-tests-failures-on-older-versions-of-v2.patch

--
Viktor
___
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: Ticket 49060 - Increase number of masters, hubs and consumers

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/49060

lib389 fix:
https://fedorahosted.org/389/attachment/ticket/49060/0001-Ticket-49060-Increase-number-of-masters-hubs-and-con.patch

ds (create_test.py) fix:
https://fedorahosted.org/389/attachment/ticket/49060/0001-Ticket-49060-Increase-number-of-masters-hubs-and-con.2.patch

--
Viktor


signature.asc
Description: PGP signature
___
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: Ticket 49049 - Fix error_log path in defaults.inf for 1.2.11

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/49049

https://fedorahosted.org/389/attachment/ticket/49049/0001-Ticket-49049-Fix-error_log-path-in-defaults.inf-for-.patch


signature.asc
Description: PGP signature
___
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: Ticket 49048 - Fix rpm build failure

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/49048

https://fedorahosted.org/389/attachment/ticket/49048/0001-Ticket-49048-Fix-rpm-build-failure.patch


signature.asc
Description: PGP signature
___
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-COMMIT #139

[Viktor Ashirov]

On Wed, Nov 02 2016 at  3:36:53 pm CET, William Brown  
wrote:
>> > --
>> >  Captured stderr call 
>> > ---
>> > INFO:suites.basic.basic_test:Running test_basic_ldapagent...
>> > CRITICAL:suites.basic.basic_test:test_basic_ldapagent: Failed to start
>> > snmp ldap agent sudo /usr/sbin/ldap-agent /etc/dirsrv/config/agent.conf:
>> > error 256
>> Error 256 says command can't locate the binary. I guest 389-ds-base-snmp
>> is not installed on the test machine.
>
> Should be getting installed as part of the jenkins job shouldn't it?

Hmm, it is:
> + cd dist/rpms/
> + sudo rpm -iUvh 389-ds-base-1.3.6.1-20161103git095b720.fc24.x86_64.rpm 
> 389-ds-base-libs-1.3.6.1-20161103git095b720.fc24.x86_64.rpm
> 389-ds-base-debuginfo-1.3.6.1-20161103git095b720.fc24.x86_64.rpm 
> 389-ds-base-devel-1.3.6.1-20161103git095b720.fc24.x86_64.rpm
> 389-ds-base-snmp-1.3.6.1-20161103git095b720.fc24.x86_64.rpm
> Preparing...  
> Updating / installing...
> 389-ds-base-libs-1.3.6.1-20161103git09
> 389-ds-base-1.3.6.1-20161103git095b720
> 389-ds-base-snmp-1.3.6.1-20161103git09
> 389-ds-base-devel-1.3.6.1-20161103git0
> 389-ds-base-debuginfo-1.3.6.1-20161103
> Cleaning up / removing...
> 389-ds-base-devel-1.3.5.14-1.fc24 
> 389-ds-base-1.3.5.14-1.fc24   
> 389-ds-base-libs-1.3.5.14-1.fc24  

On my system this test passed. But before it was failing with the exact
same error because of the missing package.
>
> -- 
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Brisbane


signature.asc
Description: PGP signature
___
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-COMMIT #117

[Viktor Ashirov]

On Thu, Oct 13 2016 at  8:46:14 pm CEST, Jenkins  wrote:
> See 
> 
>
> Changes:
>
> [firstyear] Ticket 49006 - Enable nunc-stans by default.

With nunc-stans enabled file /dev/shm/sem.slapd-standalone.stats gets
created. And if the instance was killed, it can't clean it up because of
selinux denials:

[15/Oct/2016:06:53:03.508211988 -0400] - INFO - main - 389-Directory/1.3.6.0 
B2016.288.2056 starting up
[15/Oct/2016:06:53:03.510215312 -0400] - EMERG - snmp_collator_create_semaphore 
- Failed to delete old semaphore for stats file 
(/var/run/dirsrv/slapd-standalone.stats). Error 13 (Permission denied).

time->Sat Oct 15 06:53:03 2016
type=SYSCALL msg=audit(1476528783.509:538): arch=c03e syscall=87 success=no 
exit=-13 a0=7ffccb008cf0 a1=7fe14287a7c1 a2=7fe13fee5a16 a3=7ffccb008ae0 
items=0 ppid=1 pid=22093 auid=4294967295 uid=389 gid=389 euid=389 suid=389 
fsuid=389 egid=389 sgid=389 fsgid=389 tty=(none) ses=4294967295 comm="ns-slapd" 
exe="/usr/sbin/ns-slapd" subj=system_u:system_r:dirsrv_t:s0 key=(null)
type=AVC msg=audit(1476528783.509:538): avc:  denied  { unlink } for  pid=22093 
comm="ns-slapd" name="sem.slapd-standalone.stats" dev="tmpfs" ino=49935 
scontext=system_u:system_r:dirsrv_t:s0 
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

And the message is misleading, because
/var/run/dirsrv/slapd-standalone.stats can be deleted, but
/dev/shm/sem.slapd-standalone.stats - can't be. I reopened 48538.

To reproduce:
py.test -v suites/basic/basic_test.py::test_basic_dse 
suites/betxns/betxn_test.py::test_betxn_init

>
> [firstyear] Ticket 49007 - Update DS basic test to better work with systemd.
>
> --
> [...truncated 4366 lines...]
> Processing files: 389-ds-base-1.3.6.0-20161013git83a7705.fc24.x86_64
> Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.P3dvoo
> + umask 022
> + cd 
> 
> + cd 389-ds-base-1.3.6.0.20161013git83a7705
> + 
> DOCDIR=
> + export DOCDIR
> + /usr/bin/mkdir -p 
> 
> + cp -pr LICENSE 
> 
> + cp -pr LICENSE.GPLv3+ 
> 
> + cp -pr LICENSE.openssl 
> 
> + exit 0
> Provides: 389-ds-base = 1.3.6.0-20161013git83a7705.fc24 389-ds-base(x86-64) = 
> 1.3.6.0-20161013git83a7705.fc24 config(389-ds-base) = 
> 1.3.6.0-20161013git83a7705.fc24 ldif2ldbm libacctpolicy-plugin.so()(64bit) 
> libacctusability-plugin.so()(64bit) libacl-plugin.so()(64bit) 
> libattr-unique-plugin.so()(64bit) libautomember-plugin.so()(64bit) 
> libback-ldbm.so()(64bit) libbitwise-plugin.so()(64bit) 
> libchainingdb-plugin.so()(64bit) libcollation-plugin.so()(64bit) 
> libcontentsync-plugin.so()(64bit) libcos-plugin.so()(64bit) 
> libderef-plugin.so()(64bit) libdistrib-plugin.so()(64bit) 
> libdna-plugin.so()(64bit) libhttp-client-plugin.so()(64bit) 
> liblinkedattrs-plugin.so()(64bit) libmanagedentries-plugin.so()(64bit) 
> libmemberof-plugin.so()(64bit) libpam-passthru-plugin.so()(64bit) 
> libpassthru-plugin.so()(64bit) libpbe-plugin.so()(64bit) 
> libposix-winsync-plugin.so()(64bit) libpwdstorage-plugin.so()(64bit) 
> libreferint-plugin.so()(64bit) libreplication-plugin.so()(64bit) 
> libretrocl-plugin.so()(64bit) libroles-plugin.so()(64bit) 
> librootdn-access-plugin.so()(64bit) libschemareload-plugin.so()(64bit) 
> libstatechange-plugin.so()(64bit) libsyntax-plugin.so()(64bit) 
> libusn-plugin.so()(64bit) libviews-plugin.so()(64bit) 
> libwhoami-plugin.so()(64bit) perl(DSCreate) perl(DSDialogs) perl(DSMigration) 
> perl(DSUpdate) perl(DSUpdateDialogs) perl(DSUtil) perl(Dialog) 
> perl(DialogManager) perl(DialogYesNo) perl(FileConn) perl(Inf) 
> perl(Migration) perl(Resource) perl(Setup) perl(SetupDialogs) perl(SetupLog)
> Requires(interp): /bin/sh /bin/sh /bin/sh
> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) 
> <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> Requires(post): /bin/sh systemd-units

[389-devel] Please review: Ticket #47911 - Move dirsrv-snmp.service to 389-ds-base-snmp subpackage

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/47911

https://fedorahosted.org/389/attachment/ticket/47911/0001-Ticket-47911-Move-dirsrv-snmp.service-to-389-ds-base.patch

Thanks!

--
Viktor
___
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: Ticket #48953 - Add an option or env variable to skip port label removal

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/48953

https://fedorahosted.org/389/attachment/ticket/48953/0001-Ticket-48953-Skip-labelling-and-unlabelling-ports-du.patch

--
Viktor


signature.asc
Description: PGP signature
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Re: Please review: Ticket #48965 - Fix generation of the pre-release version

[Viktor Ashirov]

On Mon, Aug 22 2016 at  4:31:57 pm CEST, Viktor Ashirov <vashi...@redhat.com> 
wrote:
> https://fedorahosted.org/389/ticket/48965
>
> https://fedorahosted.org/389/attachment/ticket/48965/0001-Ticket-48965-Fix-generation-of-the-pre-release-versi.patch
Fix building failures using rpm.mk:
https://fedorahosted.org/389/attachment/ticket/48965/0002-Ticket-48965-Fix-building-rpms-using-rpm.mk.patch
> --
> Viktor
> --
> 389-devel mailing list
> 389-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Please review: Ticket #48965 - Fix generation of the pre-release version

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/48965

https://fedorahosted.org/389/attachment/ticket/48965/0001-Ticket-48965-Fix-generation-of-the-pre-release-versi.patch
--
Viktor
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Please review 48895: tests package should be noarch

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/48895

https://fedorahosted.org/389/attachment/ticket/48895/0001-Ticket-48895-tests-package-should-be-noarch.patch
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Please review: Ticket #48889 - lldclt - fix man page and usage info

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/48889

https://fedorahosted.org/389/attachment/ticket/48889/0001-Ticket-48889-ldclt-fix-man-page-and-usage-info.patch

Thanks!

--
Viktor


signature.asc
Description: PGP signature
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Re: Please review: #48771: lib389 - get ns-slapd version

[Viktor Ashirov]

Please review my new patch:
https://fedorahosted.org/389/ticket/48771

https://fedorahosted.org/389/attachment/ticket/48771/0001-Ticket-48771-lib389-get-ns-slapd-version.patch

Thanks!

--
Viktor


signature.asc
Description: PGP signature
--
389-devel mailing list
389-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Please review: #48771: lib389 - get ns-slapd version

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/48771

https://fedorahosted.org/389/attachment/ticket/48771/0001-Ticket-48771-lib389-get-ns-slapd-version.patch


signature.asc
Description: PGP signature
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-de...@lists.fedoraproject.org

[389-devel] Please review: [389 Project] #48765: Change default ports for standalone topology

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/48765

https://fedorahosted.org/389/attachment/ticket/48765/0001-Change-default-ports-for-standalone-topology.patch

Thanks!


signature.asc
Description: PGP signature
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Please review: 48405 python-lib389 in rawhide is missing dependencies

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/48405

https://fedorahosted.org/389/attachment/ticket/48405/0001-Add-missing-dependencies-for-python-lib389.patch


signature.asc
Description: PGP signature
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Please review: Ticket 48301 - lib389 - add tox support

[Viktor Ashirov]

https://fedorahosted.org/389/ticket/48301

https://fedorahosted.org/389/attachment/ticket/48301/0001-Ticket-48301-add-tox-support.patch


signature.asc
Description: PGP signature
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel