> On 19 Nov 2019, at 22:36, Matus Honek <mho...@redhat.com> wrote: > > Hello folks, > > Context: My setup is a running dscontainer with exported /data. While > developing (outside of the container) I am trying to run `dsconf > ldapi://%2fpath%2fto%2fdscontainers%2fsocket security get`. > > Issue 1: I get IndexError exception: > File "/home/mhonek/src/ds/up/src/lib389/lib389/_mapped_object.py", > line 158, in display > How to fix the fact we can get no results to display, and to fix it > correctly so that nothing else eventually blows up? Don't know...
Raise an issue seems like the first place to deal with this, especially with the stack trace associated. > > Issue 2: Tracing back I find out I autobinded as non-root (non 0 UID). > Expectable, but still unexpected. So I tried to override this by > providing `-D` and `-w` explicitly to dsconf. No change, still > autobinding. Turns out the autobind has preference over simple bind in > DirSrv.open, this comes from [implementation]. > Possible solution: Instead of `elif can_autobind(): ... else: > simple_bind` do `elif self.binddn is not None: ... else > can_autobind(): ...`. Worked for me. Would this blow up some use-case? > Don't know... autobind is super important for ldapi - you have to prefer autobind else things go wildly wrong .... but also that whole section of dirsrv.open is extremely cursed and never should have been structured like that. But this is the bed we have, so we have to lie in it now. A major drawback that I have been suffering from here is in your statement - would this blow up some use-case? I have no idea. It's python, which is basically schroedingers language. It's unknown unless it's observed running. I'd suggest we open an issue here and then let's think about how we could solve it, but it won't be easy because all of the def open code needs a rethink - we need a better approach to how to determine how we want to present authentication credentials. > > Sub-issue 2a: Given I was able to autobind as non-root UID, the > wording in a log message [aubind-log]. The word "root" probably > shouldn't be there? Sure, just open an issue and fix it? (This is kind of why I want PR's to not need an issue, to encourage quicker small fixes like this rather than a lot of admin overhead to the process). > > Somewhat troubling 1: At the time of running open in the autobind > branch in DirSrv.open [autobind] the value of `self.bindpw` is > literally "password" even though no `-D` nor `-w` was provided on > command line for dsconf. I believe there are some reasons (besides > "because the code is written so") why this is so but I would like to > be enlightened here. Lib389 didn't always have a topologies module. Previously each instance would be setup manually in each test with ds.allocate(); ds.create(); ds.bind() ... So that meant a lot of "testing" defaults ended up in DirSrv. It became a kitchen sink. It was later on that we start to really modularise it out with DSLdapObject, topologies and others. That caused a lot of defaults to shift out, but a lot of fragments of that legacy still exist in DirSrv because it has an extremely fragile design. Anyway, this can probably be removed, it shouldn't be needed, and it could confuse def open(). In general, I've been trying to push toward local_simple_allocate and remote_simple_allocate, but I never got traction on it. The whole way we setup DirSrv as a type is really messy :( ... Actually, the whole DirSrv type is a small microcosm of evil ... Honestly I would *love* a solid two weeks in a room with you, simon, mark, viktor, and we just clean and replace DirSrv as a type. That would be amazing. > > [implementation] https://pagure.io/389-ds-base/c/e07e489 > [autobind-log] > https://pagure.io/389-ds-base/blob/6d70cbe/f/src/lib389/lib389/__init__.py#_1063 > [autobind] > https://pagure.io/389-ds-base/blob/6d70cbe/f/src/lib389/lib389/__init__.py#_1060 > > Please, share your ideas, where I went wrong, what we could go ahead with. Computers were a mistake, that was where we went wrong :) But when you see a problem, you talk about it (which you did), then we fix it. :) > > Thanks, > Matus > > -- > Matúš Honěk > Software Engineer > Red Hat Czech > _______________________________________________ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
