On 01/04/2016 08:50 PM, David Barr wrote:

On Jan 4, 2016, at 07:53, Rich Megginson <rmeggins@redhat.com> wrote:

We'll need to know what platform/version you are upgrading from, because there is not supposed to be a missing log directory, and the SELinux labels are already supposed to be provided.  In order for us to fix this issue, we need to know how to reproduce it.

I’m not going to be able to figure out the previous version, but it turns out it doesn’t matter. I have a “Blow It Away And Start Over” script[1], and going through that process has been illuminating. The delete and install section for CentOS 7 is relevant for the two possible bug write ups:

```
(case statement separating CentOS 6 and CentOS 7)
  7)
    systemctl stop dirsrv.target
    systemctl stop dirsrv-admin

    yum -y remove \
      389-ds-base \
      389-ds-base-libs \
      389-admin \
      389-adminutil

    selinuxenabled \
      && semanage port \
      --delete \
      --proto tcp \
      9830

    rm -rf /etc/dirsrv \
      /usr/lib64/dirsrv \
      /var/lib/dirsrv \
      /var/log/dirsrv \
      /var/run/dirsrv

    yum -y install \
      389-ds-base \
      389-ds-base-libs \
      389-admin \
      389-adminutil

    if [ ! -d /var/log/dirsrv/admin-serv ]
    then
      mkdir -p /var/log/dirsrv/admin-serv
    fi

    # Open the port for the httpd running the admin server.
    selinuxenabled \
      && semanage port \
      --add \
      --type http_port_t \
      --proto tcp \
      9830
    ;;
esac


/usr/sbin/setup-ds-admin.pl --file=${df_389ds_setup} --silent
```

When I run the script with `set -x`, I see the test for the absence of the admin-serv log directory return true and the directory gets created. Also, the `semanage port —add` returns without error, particularly without the error telling me that port 9830 has already been added. I have not tried the directory and semanage tests *after* setup-ds-admin.pl. If the directory and the port setup are handled in the script, I’m just catching the changes early.

OK.  So it is possible that the problem is that we don't clearly document how to blow everything away and start over from scratch.  The setup-ds-admin.pl --force is supposed to do that, but perhaps it has a bug.

Now, on to my original problem, which still appears. First, some `cn=config` setting changes in my “BIAASO" script:

```
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: SSHA256
-
replace: nsslapd-security
nsslapd-security: on
-
replace: nsslapd-ssl-check-hostname
nsslapd-ssl-check-hostname: off
-
replace: nsslapd-certdir
nsslapd-certdir: ${d_nssdb}
-
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: off
-
replace: nsslapd-require-secure-binds
nsslapd-require-secure-binds: on
-
replace: nsslapd-listenhost
nsslapd-listenhost: 127.0.0.1
-
replace: nsslapd-securelistenhost
nsslapd-securelistenhost: $(hostname -f)
```

Does it work if you enable anonymous access and/or disable secure binds?

So, I edit `/etc/dirsrv/admin-serv/adm.conf` to change `ldapurl: ldaps://$(hostname -f):636/o=NetscapeRoot`.

Now, I can get to http://localhost:9830, and log in with the admin user and password. I click through to get to the “Start Config DS” button. Once I click on that, I get a “StartConfigDS Error, your request could not be fulfilled.” And, my slapd access log shows this (with some obfuscation):

```
[04/Jan/2016:19:15:53 -0800] conn=6 fd=65 slot=65 SSL connection from ${correct_ip} to ${correct_ip}
[04/Jan/2016:19:15:53 -0800] conn=6 TLS1.2 256-bit AES
[04/Jan/2016:19:15:53 -0800] conn=6 op=0 BIND dn="cn=admin-serv-$(hostname -s),cn=389 Administration Server,cn=Server Group,cn=$(hostname -f),ou=$(hostname -d),o=NetscapeRoot" method=128 version=3
[04/Jan/2016:19:15:53 -0800] conn=6 op=0 RESULT err=48 tag=97 nentries=0 etime=0
[04/Jan/2016:19:15:53 -0800] conn=6 op=1 UNPROCESSED OPERATION - Anonymous access not allowed
[04/Jan/2016:19:15:53 -0800] conn=6 op=1 RESULT err=48 tag=101 nentries=0 etime=0
[04/Jan/2016:19:15:53 -0800] conn=6 op=2 UNBIND
[04/Jan/2016:19:15:53 -0800] conn=6 op=2 fd=65 closed - U1
```

Now, the contents of `adm.conf`, again with some obfuscation:

```
# cat /etc/dirsrv/admin-serv/adm.conf
AdminDomain: $(hostname -d)
sysuser: nobody
isie: cn=389 Administration Server,cn=Server Group,cn=$(hostname -f),ou=$(hostname -d),o=NetscapeRoot
SuiteSpotGroup: nobody
sysgroup: nobody
userdn: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot
ldapStart: /usr/lib64/dirsrv/slapd-${instance}/start-slapd
ldapurl: ldaps://$(hostname -f):636/o=NetscapeRoot
SuiteSpotUserID: nobody
sie: cn=admin-serv-$(hostname -s),cn=389 Administration Server,cn=Server Group,cn=$(hostname -f),ou=$(hostname -d),o=NetscapeRoot
```

So, my questions at this point:

- Why is the `sie` value being used as the BIND DN, and not the `userdn` value?

When you login with your username and password, it needs to lookup what is the BIND DN corresponding to the user name.  In order to do that, it needs to bind to perform a search.  The sie is used for historical reasons.

- How do I provide a password to `cn=admin-serv-$(hostname -s)`?

Not sure.  Does one of the devs know?

Is it the same password as the admin user?

No.

- Or, how do I tell the Admin Server to use the `userdn` and (presumably) the password in `admpw`?

The password in admpw is hashed, so you can't directly use that.  That password is used for "fallback" auth when LDAP is down and the admin server has to fallback to local password auth.

- More generally, if I’m going to require that every BIND be authenticated, how do I set up the `adm.conf` file to specify that? (Did I miss a wiki page, somewhere? Wouldn’t surprise me…)

Not sure.  Anyone?

Thanks!
David


[1]: https://github.com/dafydd2277/systemAdmin/blob/master/ldap/99_389dsCleanInstall.sh



--

David - Offbeat
dafydd - Online		http://pgp.mit.edu/

----5----1----5----2----5----3----5----4----5----5----5----6----5----7--

Pavlov walks into a bar. The phone rings and he says,

"Damn! I forgot to feed the dog!"

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org