> On Jan 4, 2016, at 07:53, Rich Megginson <[email protected]> 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/[email protected]
