> On Jan 4, 2016, at 07:53, Rich Megginson <rmeggins@xxxxxxxxxx> 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!"
Attachment:
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@xxxxxxxxxxxxxxxxxxxxxxx
