[389-users] Re: CentOS 7: unable to create AdmldapInfo

David Barr Mon, 04 Jan 2016 19:51:08 -0800

> On Jan 4, 2016, at 07:53, Rich Megginson <rmegg...@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.

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)
```

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?
- How do I provide a password to `cn=admin-serv-$(hostname -s)`? Is it the same 
password as the admin user?
- Or, how do I tell the Admin Server to use the `userdn` and (presumably) the 
password in `admpw`?
- 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…)


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!"

signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[389-users] Re: CentOS 7: unable to create AdmldapInfo

Reply via email to