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
** 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
-
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 /var/log/chk
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
Sta
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 rec
*** 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 ntp
> 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
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, th
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 'kno
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
> u
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 y
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) ge
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
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
Specifies
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 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
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
> p
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 w
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
I think this proposed patch will not do anything to help people who've
already upgraded from Lucid to Maverick, but who have just left the
package half-configured because of this problem (since it won't trigger
the upgrade if the $OLD_VERSION is "2.4.23-0ubuntu3", for example).
I guess that's unav
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 allow
** 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 subsc
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 underlyin
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
normally,
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
.../slapd_2.4.21-0ubuntu3
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
s
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 the
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
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:
https://lists.ubuntu.com/archives/ubuntu-devel/2010
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 LDA
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 dr
** 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
https://bugs.launchpad.net/bugs/42
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 versio
** 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 comm
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
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
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 /etc/ldap/slapd.d/cn=config/olcDa
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 "
** 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 su
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:
dc=cpd,dc
** 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
`olcDbDirectory\nolcDbD
For what it's worth, I just had this error when trying to upgrade to to
the recent Lucid slapd upgrade:
==
Preparing to replace slapd 2.4.21-0ubuntu5 (using
.../slapd_2.4.21-0ubuntu5.3_amd64.deb) ...
Stopping OpenLDAP: slapd.
Unpacking r
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:
https://help.ubuntu.com/10.04/serverguide/C/open
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 OpenLDA
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 "include"d files... but it assumes that the
"database", "suffix", and "directory" lines for a particular datab
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
`olc
Yep, in your case, the problem is the existence of the
"olcDatabase={1}hdb.ldif~" backup file.
(The postinst script currently assumes that only one file will contain
the string "olcSuffix: dc=nasgul,dc=local", but here both the .ldif and
.ldif~ file contain it.)
If you don't care much about keepi
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)?
grep
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 happen
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
--
package slapd 2.4.
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 (используетс
*** 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
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 clie
*** 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
pac
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
I was also able to use "ldapmodify" to make the necessary changes:
* shut down slapd, removed the two lines I had added manually, restarted
slapd, and confirmed that the three test searches were not returning any
results
* created the file "frontend_acls.ldif" using the input lines given in
bug #
Based on hints found in the documents mentioned in bug #506317 and other
places, I think the following three commands can be used to confirm that
the permissions are set up correctly to allow various LDAP-related
functionality to work:
Naming context discovery (e.g. "ldapvi --discover"):
ldapsea
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, wh
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 l
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 that
** Description changed:
Currently the slapd.postinst script uses /var/backups/slapd-/ 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 -.ldapdb destinatio
Public bug reported:
Currently the slapd.postinst script uses /var/backups/slapd-/ 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 -.ldapdb destination directo
** 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 ov
Public bug reported:
When called in "upgrade" mode, the slapd.postinst script starts out by
making a backup of the $SLAPD_CONF directory into /var/backups/slapd
-/ .
However, if the upgrade fails (e.g. because of bug #571057), then later
attempts to run the upgrade script will still be called wit
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 avo
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 skip
As touched on in the discussion for bug #563829, the release notes
should also mention that after upgrading to slapd 2.4.21-0ubuntu5, the
user will need to manually clean up the slapd config files in order to
complete the switch from the use of the "cn=localroot,cn=config" mapping
to the direct use
(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 d
(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 2.4.2
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
t
(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 this
(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
(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
zain
(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 i
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 beca
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 newly-
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
https:/
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
https:/
On a separate note, I did a test upgrade from a stock hardy install
directly to lucid/slapd 2.4.21-0ubuntu5. The package upgrade completed
successfully, but I can confirm that
$ ldapvi --discover -h ldap://testhost/
does not work until I manually add the
olcAccess: {1}to dn.base="" by * read
It seems like the new slapd.postinst in 2.4.21-0ubuntu5 will cause a
configuration error for upgrades from previous Lucid versions of the
package.
Specifically, up through 2.4.21-0ubuntu4, the postinst script added the
following line:
olcAccess: to * by dn.exact=cn=localroot,cn=config manage by
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
fil
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 *** ]
Przygotowanie
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 ...
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 o
(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 ma
Also, should the edits made to the the olcDatabase={-1}frontend.ldif file
include granting
to dn.base="" by * read'
permissions, too? It appears that that statement exists in (for example) the
Hardy version of slapd.conf, but the slapd.conf -> slapd.d conversion migrates
it to the olcDatabas
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
au
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: /etc/lda
** 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 notifica
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
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 conversio
(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
Using this new version of the slapd.postinst script, the "cn=config"
database ends up with these two oldAccess attributes:
$ sudo slapcat -b"cn=config" -s"olcDatabase={0}config,cn=config" | grep
olcAccess
olcAccess: {0}to * by * none
olcAccess: {1}to * by dn.exact=cn=localroot,cn=config manage b
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.
--
sl
** 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
https://bugs.launchpad.net/
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 che
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 pa
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
1 - 100 of 115 matches
Mail list logo