On Fri, Jan 16, 2015 at 18:05:04 -, Ryan Tandy wrote:
will no longer be used. But switching to nss-pam-ldapd is a good
recommendation anyway, since the older modules are dead upstream.
(In fact there is discussion underway regarding downgrading libnss-ldap
and libpam-ldap out of main; see
If you are working on cleaning up the slapd.postinst script, you may
find some of these related discussions to be interesting and/or
helpful...:
LP: #450645 error during slapd configuration: chown: cannot access
`olcDbDirectory\nolcDbDirectory'
LP: #632051 Improve slapd postinst error message in
** Also affects: ntp via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672
Importance: Unknown
Status: Unknown
** Also affects: ntp (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672
Importance: Unknown
Status: Unknown
** No longer affects: ntp
Public bug reported:
the cron.daily/chkrootkit script's current logic for simplifying the
PACKET SNIFFER lines for dhclient and dhcpcd processes needs to be
updated to include the names of current versions of those binaries.
** Affects: chkrootkit (Ubuntu)
Importance: Undecided
We have found that chkrootkit now complains after each reboot, with a message
similar to:
-eth0: PACKET SNIFFER(/sbin/dhclient[895])
+eth0: PACKET SNIFFER(/sbin/dhclient[888])
---[ END: diff -u
I noticed that the proposed branch (
lp:~shuff/ubuntu/precise/net-snmp/fix-for-701944 ) includes a new copy of the
line:
if [ ! `getent passwd snmp /dev/null` ]; then
(and also leaves the existing group line untouched), so I thought it was
worth mentioning debbugs #609430, which points out
Saivann,
1:9.8.1.dfsg.P1-3 changes the default value of the bind9/run-resolvconf
debconf setting to false -- but if that setting has already been set
to true by an earlier installation of the bind9 package then the
RESOLVCONF=yes will still get written to the config file until you
manually
On Thu, May 17, 2012 at 19:33:37 -, Paul Crawford wrote:
domain, I think). I don't really understand NIS, and the
guy usually responsible for this sort of thing is away,
but as far as I know it only provides local-area
user/machine authentication and so I would be surprised
if it 'knows'
On Fri, May 18, 2012 at 17:47:21 -, Paul Crawford wrote:
I think this bug should concentrate on the key issue:
that ntp (and maybe others?) is being brought up on the
wrong event, that is it comes up with the interface, and
not with the chosen type of name server.
More specifically, the
I'm not sure off hand how the decision is made whether to
convert a package such as ntp to Upstart... but I see a
couple other bugs open on the topic: LP #604717 , LP #913379
Sorry, should have written those bug references as: LP: #604717 , LP:
#913379
--
You received this bug notification
*** This bug is a duplicate of bug 604717 ***
https://bugs.launchpad.net/bugs/604717
** This bug has been marked a duplicate of bug 604717
Please convert init script to upstart
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
On Thu, May 17, 2012 at 16:10:39 -, Paul Crawford wrote:
# The primary network interface
auto eth0
iface eth0 inet static
address 134.36.22.69
netmask 255.255.255.0
gateway 134.36.22.1
Since the resolvconf package is installed by default in Precise, you'd
normally need to have a
On Thu, May 17, 2012 at 16:46:15 -, Paul Crawford wrote:
Results for 12.04 machine are:
$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Apr 30 17:39 /etc/resolv.conf -
../run/resolvconf/resolv.conf
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated
On Thu, May 17, 2012 at 18:43:59 -, Paul Crawford wrote:
So ping is able to perform the name-to-IP conversion fine, but host
and nslookup both fail!
Right, host and nslookup both (attempt to) do DNS queries directly,
while ping does the lookup using libc6 library routines...
So, what do
On Thu, May 17, 2012 at 19:33:37 -, Paul Crawford wrote:
$ cat /etc/nsswitch.conf
[...]
hosts: files nis dns
domain, I think). I don't really understand NIS, and the
guy usually responsible for this sort of thing is away,
but as far as I know it only provides local-area
As mentioned earlier in this bug report, the TLS_CACERTDIR configuration
directive stopped working when the openldap packages were linked to the GNUTLS
library. (At least in the Lucid version, the ldap.conf man page specifcially
mentions this issue:
TLS_CACERTDIR path
James, would you also be able to re-try an upgrade from Lucid to the
current Maverick version (slapd 2.4.23-0ubuntu3), and then confirm that
the slapcat command does fail at that point (i.e. without having done
the manually recovery steps)?
(I'd just like to be sure that once 2.4.23-0ubuntu3 is
On Thu, Oct 14, 2010 at 16:31:20 -, Steve Langasek wrote:
That's not unavoidable; just bump the minimum version check to the
maverick release version instead of the lucid version. New
installations of maverick will get an excess database dump/restore, but
the upgrade will be clean for
On Thu, Oct 14, 2010 at 17:47:19 -, Steve Langasek wrote:
Ah, you're probably right then and I'm just
misremembering how this was
handled in Debian.
Looking through the Debian changelog, it appears that
there was a similar problem between 2.4.23-1 and 2.4.23-4.
The switch to libdb4.8 was
On Thu, Oct 14, 2010 at 19:07:47 -, Mathias Gug wrote:
+ if dpkg --compare-versions $OLD_VERSION lt-nl 2.4.23-0ubuntu3.1; then
return 0
else
That will force a database dump for every upgrade to
maverick. This is the same fix as in Debian (modulo the
package
On Thu, Oct 14, 2010 at 19:07:47 -, Mathias Gug wrote:
I've uploaded a fix to maverick-update:
How long before this new version will be available by
default for a user upgrading to Maverick?
Would it make sense to add a Maverick Release Note
mentioning this error and advising users with the
This bug is related to to LP: #632051. The two are triggered by a
different specific issue within the slapd.conf file, and would need
different changes to the postinst script in order to allow it to
actually parse the config file correctly... but I think the patch I
proposed in that bug would
Given that this seems to affect any system upgrading slapd from Lucid to
Maverick, I wonder if it's worth trying to get it added to the Maverick
release notes?
** Summary changed:
- upgrade process does not upgrade underlying BDB format from 4.7 to 4.8
+ upgrade process does not upgrade
** Changed in: openldap (Ubuntu)
Status: Incomplete = Confirmed
--
Dist-Upgrade Karmic-Lucid: Upgrading slapd fails with chown: invalid
argument: `'
https://bugs.launchpad.net/bugs/574474
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Can you look through the /var/log/dist-upgrade/apt-term.log and post the
lines that come from the upgrade of the slapd package?
(I don't know off hand if any of the discussion there applies in the
Lucid-to-Mavick upgrade case, but in case it's helpful I'll point you to
LP #536958, which covers
Ubuntu devs,
I took a quick look at the slapd.posting/slapd.scripts-common files in
the lp:ubuntu/maverick/openldap branch, and also in the Bazaar change
summary for revision 26 (which is the one that includes the note Use
libdb4.8-dev (LP: #572489)), but I don't see any edits to the postinst
Andrew,
As we expected, this shows that the slapd scripts made no attempt to do an
export/import cycle on your database. (When that happened during my
Hardy-Lucid upgrade, I had a Dumping... line, like this:
Preparing to replace slapd 2.4.9-0ubuntu0.8.04.3 (using
I just remembered that the postinst failure I mentioned in my previous
post wasn't triggered by the restart of the slapd daemon, but rather by
another step that the postinst script was attempting to do at that time.
So, in your case, did the apt upgrade/configure cycle appear to complete
I noticed that this very topic (the default file descriptor limit) is
currently being discussed on the ubuntu-dev mailing list.
In particular, there was a little discussion of the fact that
/etc/security/limits.conf does not apply to services:
On Mon, Sep 20, 2010 at 14:39:27 -, Nathan Stratton Treadway wrote:
(The very last comment on Debian bug 378261 seems to
indicate that the -DOPENLDAP_FD_SETSIZE=8192 patch
shouldn't actually make any difference in the Lucid
version.)
The bug is currently closed, but just in case new
On Wed, Sep 22, 2010 at 22:26:31 -, greenmoss wrote:
My bug 509734 was marked as a duplicate of this one. This was a special
case using the atd job scheduler. At jobs launched by ldap users worked,
but at jobs launched by root did *not* work. atd was doing a group
lookup, and nss was
On Fri, Sep 24, 2010 at 16:46:25 -, Nathan Stratton Treadway wrote:
As greenmoss found, when I was running with libpam/nss-ldap and
no nscd (and didn't have any of the users in question listed in
the ignoreusers line), my at commands worked for LDAP users
but not for ones defined in /etc
** Summary changed:
- NSS using LDAP+SSL breaks setuid applications like su and sudo
+ NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec,
and atd
--
NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec,
and atd
Alex, have you tried going back to using the stock Lucid version of the
slapd binary (but with the /etc/defaults/slapd ulimit changes)?
(The very last comment on Debian bug 378261 seems to indicate that the
-DOPENLDAP_FD_SETSIZE=8192 patch shouldn't actually make any difference
in the Lucid
** Summary changed:
- Improve error message in case suffix is incorrect
+ Improve slapd postinst error message in case database directory can't be
determined for a given LDAP suffix
** Description changed:
Bug is due to buggy configuration, but we could have a better error
message. See
** Changed in: openldap (Ubuntu)
Status: Incomplete = Confirmed
--
error during slapd configuration: chown: cannot access
`olcDbDirectory\nolcDbDirectory'
https://bugs.launchpad.net/bugs/450645
You received this bug notification because you are a member of Ubuntu
Server Team, which is
I didn't explain clearly in my earlier comments that it's only the
olcDbDirectory grep that actually causes the chown error here. I added
the .ldif extension to the grep in the get_suffix function only to
keep the two consistent (figuring that if it's true we only care about
files that end in
I wonder if the cause of this chown error is at all related to the one
discussed in bug #450645
If you can post the output of the following commands it might provide
enough information to figure out what exactly is triggering the bug:
$ sudo sh -c ls -l
Ah, okay, you are still using the slapd.conf file, rather than the
slapd.d configuration directory, so your error and the one in #450645
are more like cousins than siblings :)
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
database hdb
suffix
It occured to me that when the postinst script is unable to determine
the database directory associated with a particular suffix (for whatever
reason), simply producing the error message chown: invalid argument:
`' and then aborting isn't very helpful to the system administrator.
Here's a patch
** Patch added: restrict grep searches to files with names ending in .ldif
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/450645/+attachment/1535371/+files/slapd_2.4.21-0ubuntu5.3_postinst.patch
--
error during slapd configuration: chown: cannot access
Ross,
In your case, I believe the error is triggered because you have two different
olcDatabase files that include the same oldSuffix line:
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcSuffix:
dc=cpd,dc=co,dc=uk
/etc/ldap/slapd.d/cn=config/olcDatabase={3}ldap.ldif:olcSuffix:
On Thu, Apr 29, 2010 at 15:03:46 -, Adam Sommer wrote:
The OpenLDAP instructions have been updated for Ubuntu Lucid, and they work
for Karmic.
I noticed that the Lucid version of the Ubuntu Server Guide is now
available on the web site:
The DpkgTerminalLog.txt file shows several attempts to upgrade the slapd
package, each with the same result; here is the output from one of them:
=
Setting up slapd (2.4.21-0ubuntu5) ...
Backing up /etc/ldap/slapd.d/ in /var/backups/slapd-2.4.21-0ubuntu4... done.
Starting
Yes, I think that explains why you are getting the chown: invalid
argument `' error
Specifically, when the slapd.postinst parses through the slapd.conf
file, it attempts to process included files... but it assumes that the
database, suffix, and directory lines for a particular database
are
The slapd.postinst script attempts to ensure that various files and
directories have the proper ownerships (and permissions) set. It looks
like it may be having trouble extracting the correct list of directories
in your case.
Can you post the output of the following command (run as root)?
Mathias (or other OpenLDAP developers):
Any reason the grep commands in the get_suffix and get_directory
fuctions shouldn't use olcDatabase*.ldif for the list of files to
search (instead of olcDatabase*, as they currently do)?
--
error during slapd configuration: chown: cannot access
*** This bug is a duplicate of bug 573048 ***
https://bugs.launchpad.net/bugs/573048
(I confirmed that the VarLogDistupgradeApt* and
VarLogDistupgradeMainlog.gz files attached here are exactly the same as
those attached to bug 473048.)
** This bug has been marked a duplicate of bug 573048
Looking through VarLogDistupgradeApttermlog, I see that slapd is
restarted successfully a few times (i.e. when packages such as libc6,
libpam0g, and libssl are upgraded). Then later on these lines appear:
===
Подготовка к замене пакета ldap-utils 2.4.9-0ubuntu0.8.04.3
deutsche Makar,
I'm thinking something may have gone wrong setting the permissions on
the BDB database files.
Can you post the output of the following commands?
ls -ld /var/backups/dc*
ls -l /var/backups/dc*
uname -a
grep ^directory /etc/ldap/slapd.conf*
ls -la path listed in output
Looking more closely at the slapd.postinst script, I see that the word
failed. is actually associated with the Migrating slapd.conf file
message below it, not with the chowning database directory message
above it. So I don't think there's problem with the permissions after
all.
What happens if
Mathias, Thierry: neither of these scripts appear to clean up the
olcAuthzRegexp:
gidNumber=\[\[:digit:]]\+\\\+uidNumber=0,cn=peercred,cn=external,cn=auth
cn=localroot,cn=config'
line that got added to the ${SLAPD_CONF}/cn=config.ldif file by earlier
upgrades. I believe that as long as
On Thu, Apr 29, 2010 at 02:57:36 -, Stephen Warren wrote:
Re: the mention of symptoms in comment #12 above: My symptom was that I
could not log in at all, and in existing sessions, sudo wouldn't work
etc. I store user information in LDAP, with just system users in
/etc/passwd etc., so
Public bug reported:
As a result of LP: #427842, the initial configuration created upon installation
of slapd 2.4.21-0ubuntu4 and later will include the following ACLs on the
{-1}frontend database:
olcAccess: to dn.base= by * read
olcAccess: to dn.base=cn=subschema by * read
However, when
I have opened Bug #571752 for the issue related to missing ACLs for the
frontend database after upgrading from earlier versions of slapd
(discussed in comments 3 12 here).
(Obviously, the discussion related to the issue mentioned in comment 11
here has moved to Bug #571057.)
--
olcAccess are
*** This bug is a duplicate of bug 427842 ***
https://bugs.launchpad.net/bugs/427842
Note that the fix committed as part of bug #427842 only changed the
settings for new installations, while this bug is actually about
permission problems after migrating from an earlier version of the slapd
Thierry, any chance of of adding another release note covering the post-
upgrade access permissions problems discussed here and in bug #571752?
Even though they won't cause the upgrade process to abort the way the
ordered_value_sort error does, it still seems pretty significate that
some LDAP
The history for bug 563829 includes some discussion of this situation
with the olcDatabase={-1}frontend.ldif file.
--
slapd 2.4.21-0ubuntu5 corrupts olcDatabase={-1}frontend.ldif with duplicate
olcAccess lines (again)
https://bugs.launchpad.net/bugs/571057
You received this bug notification
(Assuming the /var/log/syslog does include a line saying:
config error processing olcDatabase={-1}frontend,cn=config:
ordered_value_sort failed on attr olcAccess#012
, then this bug is probably a duplicate of LP: #571057.
--
package slapd 2.4.21-0ubuntu5 failed to install/upgrade: subprocess
(Assuming the /var/log/syslog includes a line saying:
config error processing olcDatabase={-1}frontend,cn=config:
ordered_value_sort failed on attr olcAccess#012
, then this bug is probably a duplicate of LP: #571057.)
--
package slapd 2.4.21-0ubuntu5 failed to install/upgrade: podproces
(Also, for what it's worth, the slapd.postinst script does include a
package-version check which attempts to prevent the new line from being
added more than once. However, since the slapd-failure prevents the
package from reaching configured status, the script is still trying to
upgrade from the
(I think systems installed in Hardy and then upgraded to pre-release
Lucid versions before upgrading to 0ubuntu5 will also be affected.)
--
slapd 2.4.21-0ubuntu5 corrupts olcDatabase={-1}frontend.ldif with duplicate
olcAccess lines (again)
https://bugs.launchpad.net/bugs/571057
You received
To follow up on my comment #2: I did some more testing and determined that the
behavior I was seeing related to the olcAccess lines in the
olcDatabase={0}config.ldif file was due to the localroot-related lines left
over from earlier versions of the slapd.posting script. Once I removed all
(To be precise, if I have followed the changelog correctly, the problem will be
triggered when the upgrade path looks like:
slapd older than 2.4.17-1ubuntu3 --
slapd between 2.4.17-1ubuntu3 and 2.4.21-0ubuntu4 --
(maybe some upgrades within that range) --
slapd
(To clarify my previous comment: note that while the symptoms are
similar, this bug and bug 526230 actually have different underlying
causes, and the thus details of the upgrade paths that trigger each one
are different, too.)
--
slapd 2.4.21-0ubuntu5 corrupts olcDatabase={-1}frontend.ldif with
The DpkgTerminalLog file shows that this is an upgrade from slapd
2.4.21-0ubuntu4 to 2.4.21-0ubuntu5 :
==
Vorbereiten zum Ersetzen von slapd 2.4.21-0ubuntu4 (durch .../slapd_2.4.21-0ubun
tu5_i386.deb) ...
Stopping OpenLDAP: slapd.
Entpacke Ersatz für slapd ...
[ *** lines
A few other points that hopefully can be worked into the release notes:
* A symptom that indicates the need for this config-file cleanup is when
commands that rely on EXTERNAL SASL authentication no longer work for
the local root user (e.g. ldapsearch -Y EXTERNAL -Hldapi:/// )
* One can
** Summary changed:
- when slapd upgrade fails, later upgrade attempts overwrite saved copies of
pre-upgrade configuration files
+ when slapd upgrade fails, later upgrade attempts overwrite saved backups of
pre-upgrade configuration files
--
when slapd upgrade fails, later upgrade attempts
Public bug reported:
Currently the slapd.postinst script uses /var/backups/slapd-old-
package-version/ to store both the backup copy of $SLAPD_CONF and the
slapcat-generated .ldif file. However, if there is a need to move the
BDB files out of the way, they are instead moved to separate rootdn
** Description changed:
Currently the slapd.postinst script uses /var/backups/slapd-old-
package-version/ to store both the backup copy of $SLAPD_CONF and the
slapcat-generated .ldif file. However, if there is a need to move the
BDB files out of the way, they are instead moved to
The DpkgTerminalLog.gz file includes the following lines related to the
slapd package upgrade:
===
Log started: 2010-04-03 20:07:47
[...]
Preparing to replace ldap-utils 2.4.21-0ubuntu3 (using .../ldap-utils_2.4.21-0ub
untu4_i386.deb) ...
Unpacking replacement ldap-utils ...
Looking through the DpkgTerminalLog lines, it seems that slapd was
upgraded to slapd 2.4.21-0ubuntu4 on 4/19, but the restart of the
OpenLDAP daemon isn't shown in the log due to an unrelated failure:
===
Log started: 2010-04-19 03:40:24
[ *** lines skipped *** ]
If your syslog file includes a line that looks similar to
slapd[7087]: config error processing olcDatabase={0}config,cn=config:
ordered_value_sort failed on attr olcAccess#012
, then it would also be helpful to attach a copy of the
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif
Or, if the syslog line instead mentions olcDatabase={-1}frontend, the
related file would be
/etc/ldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif .
--
package slapd 2.4.21-0ubuntu5 failed to install/upgrade: subprocess installed
post-installation script returned error exit status 1
When you say bugs, would you like two separate new bugs, one for the
slapd-won't-start-after-upgrading issue and the other about the
dn.base= permissions?
(Or do you just need a new bug related to the permissions issue?)
--
olcAccess are options broken on upgrade in {-1}frontend.ldif
On Tue, Apr 27, 2010 at 19:10:03 -, Mathias Gug wrote:
A bug for each separate problem as it makes things simpler to
track and to focus on.
I guess my question is whether you consider the issue raised in
comment 11 to be a separate problem from this bug (LP#563829),
thus requiring a
On Tue, Apr 27, 2010 at 02:40:11 -, Mathias Gug wrote:
The issue with deleting the old configuration is that it's hard (if not
impossible) to figure out if the olcAuthzRegexp and relevant olcAccess options
have been added by the package or manually by the local sysadmin.
Having the old
I took a quick look through the new slapd.postinst script found in:
lp:~mathiaz/ubuntu/lucid/openldap/fix-root-olcaccess-upgrade
Am I correct that you no longer attempt to delete the
olcAccess: {0}to * by * none
line from the olcDatabase={0}config.ldif file (i.e the line that is generated
(Obviously, that should be LP: #427842 .)
--
olcAccess are options broken on upgrade in {-1}frontend.ldif
https://bugs.launchpad.net/bugs/563829
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in ubuntu.
--
Ubuntu-server-bugs
Using this new version of the slapd.postinst script, the cn=config
database ends up with these two oldAccess attributes:
$ sudo slapcat -bcn=config -solcDatabase={0}config,cn=config | grep
olcAccess
olcAccess: {0}to * by * none
olcAccess: {1}to * by dn.exact=cn=localroot,cn=config manage by *
(A few days ago) I unpacked the /etc/ldap tar archive attached to this
bug, and found that the slapd.d/cn=config/olcDatabase={0}config.ldif
file inside it does contain just one olcAccess line, so I went ahead and
updated the title of this bug to more precisely describe the situation.
--
existing
For what it's worth, I'm attaching here the (plain text)
olcDatabase={0}config.ldif file, as pulled out of the tar file
ldap.tar.gz file that Stephen attached to this bug.
In particular, the olcAccess line found there is indeed the same as the
one that is created by the cn=config backend
Jay, I don't believe your problem is actually the same as the one
described in this bug report (which involves a chown: cannot access
`olcDbDirectory\nolcDbDirectory': No such file or directory error
message).
Instead, I think your particular problem is described in bug #526230
--
Problem
** Summary changed:
- Problem install slapd
+ error during slapd configuration: chown: cannot access
`olcDbDirectory\nolcDbDirectory'
--
error during slapd configuration: chown: cannot access
`olcDbDirectory\nolcDbDirectory'
https://bugs.launchpad.net/bugs/450645
You received this bug
Md. Afzalur Rashid,
If you are still having this problem, please post the output of the
following commands:
$ sudo sh -c ls -l /etc/ldap/slapd.d/cn=config/olcDatabase*
$ sudo sh -c grep olcSuffix: /etc/ldap/slapd.d/cn=config/olcDatabase*
and
$ sudo sh -c grep olcDbDirectory:
** Summary changed:
- On upgrade modifies multiple olcAccess definition are not handled correclty
+ existing olcAccess line conflicts with new one added by jaunty - karmic
upgrade
--
existing olcAccess line conflicts with new one added by jaunty - karmic
upgrade
I just did another hardy - lucid upgrade run (on a test machine running
an as-installed-by-the-package slapd configuration), and can confirm
that the new version of the slapd.postinst was able to complete without
triggering the Program version 4.7 doesn't match environment version
error.
--
I will try to actually run a test of this scenario sometime in the next
few days, but at first glance it appears to me that simply adding {1}
to both the grep and the sed lines of the postinst script will fix
Hardy - Lucid upgrades, but will cause new problems for other upgrade
paths.
In
Ah, never mind.
I was thinking that if the user upgraded from jaunty up to karmic and
then again to lucid, both copies of the oldAccess line would be added to
the file (i.e. one with no index, by the karmic upgrade, and one with
{1}, by the lucid upgrade) -- but I see now the postinst script
I took a closer look at the slapd.postinst script, and I believe I see
what is causing this issue.
In the postinst_upgrade_configuration function, the script first
checks to see if the configuration info needs to be converted from
slapd.conf to slapd.d format, and if so it runs the slaptest
(As a side note, I noticed that the actual version number printed out in
the doesn't match environment version 0.XXX message was not consistent
-- when I did the original upgrade it was 0.44, but in my later
testing it started out at 0.143 and then kept getting larger.
It turns out that the
I did some more investigation into this issue, and it looks like this
bug will affect all Hardy - Lucid upgrades.
To test this I went through the following steps:
On a machine running Hardy (and which had never had slapd installed before):
1a) installed the slapd package, allowed the postinst
Public bug reported:
When I upgrade the slapd package from Hardy to Lucid, the slapd.postinst
script automatically attempts to convert from the slapd.conf file to the
slapd.d configuration directory. If that conversion attempt fails, a
notification message is printed (Migrating slapd.conf file
** Patch added: slapd.postinst.diff
http://launchpadlibrarian.net/40935969/slapd.postinst.diff
--
slapd.postinst doesn't mention configuration conversion step
https://bugs.launchpad.net/bugs/538848
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Attaching corrected patch file.
** Patch removed: slapd.postinst.diff
http://launchpadlibrarian.net/40935969/slapd.postinst.diff
** Patch added: slapd.postinst.diff
http://launchpadlibrarian.net/40936137/slapd.postinst.diff
--
slapd.postinst output doesn't mention configuration
** Summary changed:
- slapd.postinst doesn't mention configuration conversion step
+ slapd.postinst output doesn't mention configuration conversion step
--
slapd.postinst output doesn't mention configuration conversion step
https://bugs.launchpad.net/bugs/538848
You received this bug
Public bug reported:
I recently upgraded my server from Hardy to Lucid, using do-release-
upgrade -d from the command line.
When the upgrade process attempted to install the new version of the
slapd package, the package installation/configuration failed due to
problems with the DBD database
I found that running slaptest -F /etc/ldap/slapd.d generated that same
error message.
To investigate further, I used the command line
slaptest -F /etc/ldap/slapd.d -d 1 21 | grep \.ldif
to track down the full path of the file that contained the offending line,
which turned out to be
I did some additional testing and believe that all Hardy - Lucid
upgrades will hit this bug.
Specifically, I installed the slapd package on Hardy box, one that had
never had any openldap packages installed. I let the package
installation script create the default slapd.conf file there, and then
A few other notes:
Bug #526230 On upgrade modifies multiple olcAccess definition are not
handled correclty is definitely related to this one. However, #526230
deals with a Jaunty-Karmic upgrade, and specifically mentions that the
pre-upgrade configuration had multiple oldAccess lines (so
1 - 100 of 103 matches
Mail list logo
