Robert P. J. Day 写道:
i finally pulled the trigger on this, almost 300 packages upgraded,
rebooted and here are some of the (apparently non-fatal) issues i ran
across:
1) my /etc/aliases.db file was deleted. no problem, i just recreated
it with
# postalias hash:/etc/aliases
easy enough to fix but should i have expected that? couldn't
something that obvious be part of the automatic upgrade process?
2) log error that there was no permission to read
/etc/ldap/slapd.conf, not surprising since the perms on that file
were:
root root -rw-------
changed perms to 644, that seems to have solved that problem.
should i have expected that as well? or was there a better way
to solve that access problem?
3) in fact, running "aptitude upgrade" tells me that slapd is still
only partially configured, but trying to finish the configuration
gives me:
=====
Setting up slapd (2.4.11-1) ...
Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.3.30-5+etch2... done.
Upgrading BDB 'checkpoint' options... .
Moving old database directories to /var/backups:
Loading from /var/backups/slapd-2.3.30-5+etch2:
- directory dc=<XXXXXX>,dc=com... failed.
Loading the database from the LDIF dump failed with the following
error while running slapadd:
/etc/ldap/slapd.conf: line 50: unknown directive <defaultaccess> outside
backend info and database definitions.
slapadd: bad configuration file!
dpkg: error processing slapd (--configure):
subprocess post-installation script returned error exit status 1
=====
i'm not an LDAP expert -- can i just comment out the offending line?
defaultaccess write
Don't know if defaultaccess is set to write is good enough for your
application.
You can try comment it out or add the following line to your config file:
access to *
by * write
As far as I know, it's really dangerous and should be fully tested in
advance.
Hope this helps.
i'm guessing there's been a change in the syntax of that config file
and i just have to read up on it.
off to check if there are any more issues, but if that's the extent of
them, i'm in good shape.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
