Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size
Hi all, we do second this. While we always installed workstations automatically with debian preseeding and the default receipts (lvm encrypted) we noticed the defaults suddenly changed in bullseye. I would support the assumption that for server installations this is not a big issue since one (at least we) do special partitioning any way for servers. So: please set a default again which is reasonable for laptops and workstations. We always recommend debian for desktops to our customers. But if many things are not really suitable for Desktops people will avoid debian. Thanks Jan -- datenkollektiv.net OHG Böhmische Str. 14 01099 Dresden Tel: (0351) 41 88 66 00 E-Mail: carsten.ungewit...@datenkollektiv.net http://www.datenkollektiv.net Registergericht: Amtsgericht Dresden HRA 11427
Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
Hi again, Am 17.09.19 um 18:02 schrieb Mike Gabriel: > Hi, > completing the story... > > During package upgades, I see upgrade failures: > > ``` > root@jessie:~# apt-get install 389-ds-base --reinstall > Paketlisten werden gelesen... Fertig > Abhängigkeitsbaum wird aufgebaut. > Statusinformationen werden eingelesen Fertig > 0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen > und 0 nicht aktualisiert. > Es müssen noch 0 B von 1.459 kB an Archiven heruntergeladen werden. > Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt. > (Lese Datenbank ... 137483 Dateien und Verzeichnisse sind derzeit > installiert.) > Vorbereitung zum Entpacken von > .../389-ds-base_1.3.3.5-4+deb8u6_amd64.deb ... > Entpacken von 389-ds-base (1.3.3.5-4+deb8u6) über (1.3.3.5-4+deb8u6) ... > Trigger für man-db (2.7.0.2-5) werden verarbeitet ... > Trigger für systemd (215-17+deb8u13) werden verarbeitet ... > 389-ds-base (1.3.3.5-4+deb8u6) wird eingerichtet ... > dpkg: Fehler beim Bearbeiten des Paketes 389-ds-base (--configure): > Unterprozess installiertes post-installation-Skript gab den Fehlerwert > 1 zurück > Fehler traten auf beim Bearbeiten von: > 389-ds-base > E: Sub-process /usr/bin/dpkg returned an error code (1) > ``` I've reported this bug in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905184 But unfortunately it doesn't seemed to be backported to lts. In stretch it is fixed. Great that you did now also for jessie. Kind regards Jan
Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
Hi Mike,
Am 17.09.19 um 17:38 schrieb Mike Gabriel:
> What I did:
>
> 1. Setup a fresh 389-ds instance using jessie's original version
> (see http://snapshot.debian.org/package/389-ds-base/1.3.3.5-4/)
>
> 2. Upgrade to +deb8u4, test login, LDAP queries, etc.
>
> -> worked
>
> 3. Upgrade to +deb8u5, test login, LDAP queries, etc.
>
> -> worked
>
> 4. Upgrade to +deb8u6, test login, LDAP queries, etc.
>
> -> worked
>
> Can you be any chance provide more info about this issue? What exactly
> are the LDAP queries, that Nextcloud does on your 389-ds server?
unfortunately not. It was an setup we don't have any more, we updated
nextcloud and moved to an newer ldap version. And in fact at that time I
couldn't figure out the exact problem since the queries worked when I
provided them via ldapsearch command line.
My notes about the error where:
nextcloud-log:
root@nextcloud:/etc# tail -f /srv/ncdata/nextcloud-demo/nextcloud.log
{"reqId":"U7vRHqej7uRmeA2JsBIf","level":3,"time":"2018-10-26T16:26:40+00:00","remoteAddr":"88.198.xx.xxx","user":"--","app":"PHP","method":"POST","url":"\/login?redirect_url=\/apps\/files\/%3Fdir%3D\/%26fileid%3D955=demo%40example.org","message":"ldap_control_paged_result_response():
Result is: Protocol error (2) at
\/opt\/nextcloud-demo\/apps\/user_ldap\/lib\/LDAP.php#74","userAgent":"Mozilla\/5.0
(X11; Linux x86_64; rv:52.0) Gecko\/20100101
Firefox\/52.0","version":"14.0.3.0"}
Note the: "Protocol error (2)"
When we encountered the bug we had an replication of multiple ldap
servers with slightly different versions:
Access log of the ldap server with 389-ds version 1.3.3.5-4+deb8u3:
[26/Oct/2018:16:32:41.929490646 +] conn=5364586 op=0 BIND
dn="uid=owncloud-bind,ou=Special Users,dc=example,dc=org" method=128
version=3
[26/Oct/2018:16:32:41.929803839 +] conn=5364586 op=0 RESULT err=0
tag=97 nentries=0 etime=0 dn="uid=owncloud-bind,ou=special
users,dc=example,dc=org"
[26/Oct/2018:16:32:41.987048655 +] conn=5364586 op=1 SRCH
base="dc=example,dc=org" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=d...@example.org)))"
attrs="entryuuid nsUniqueId objectguid guid ipauniqueid
distinguishedName uid samaccountname memberOf mail displayName
jpegPhoto thumbnailphoto"
[26/Oct/2018:16:32:41.987905862 +] conn=5364586 op=1 RESULT err=0
tag=101 nentries=1 etime=0 notes=P pr_idx=0 pr_cookie=-1
[26/Oct/2018:16:32:42.459561451 +] conn=5364586 op=2 UNBIND
[26/Oct/2018:16:32:42.459584128 +] conn=5364586 op=2 fd=825 closed - U1
Access log at the other one with 389-ds version 1.3.5.17-2:
[26/Oct/2018:18:29:19 +0200] conn=66 op=0 BIND
dn="uid=owncloud-bind,ou=Special Users,dc=example,dc=org" method=128
version=3
[26/Oct/2018:18:29:19 +0200] conn=66 op=0 RESULT err=0 tag=97 nentries=0
etime=0 dn="uid=owncloud-bind,ou=special users,dc=example,dc=org"
[26/Oct/2018:18:29:19 +0200] conn=66 op=1 SRCH base="(null)" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=d...@example.org)))",
invalid attribute request
[26/Oct/2018:18:29:19 +0200] conn=66 op=1 RESULT err=2 tag=101
nentries=0 etime=0
[26/Oct/2018:18:29:19 +0200] conn=66 op=2 SRCH base="(null)" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))",
invalid attribute request
[26/Oct/2018:18:29:19 +0200] conn=66 op=2 RESULT err=2 tag=101
nentries=0 etime=0
[26/Oct/2018:18:29:19 +0200] conn=66 op=3 SRCH base="(null)" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))",
invalid attribute request
[26/Oct/2018:18:29:19 +0200] conn=66 op=3 RESULT err=2 tag=101
nentries=0 etime=0
[26/Oct/2018:18:29:32 +0200] conn=66 op=4 UNBIND
[26/Oct/2018:18:29:32 +0200] conn=66 op=4 fd=279 closed - U1
there ist an search base with "null" in access log. But this seems to
happen on the server side. Providing the same query on command line worked.
> Can anyone else give feedback about 389-ds in jessie LTS? Any observed
> problems that look similar to #912224 [1]?
Maybe we've been the only who where affected.
Kind regards
Jan
Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
Hi Mike, hi Hugo, Am 11.09.19 um 14:04 schrieb Mike Gabriel: > Hi Hugo, > > sorry for the late reply on this urgent matter. > > On So 08 Sep 2019 10:46:26 CEST, Hugo Lefeuvre wrote: > >> Sorry for the very late answer. For some reason, it looks like the LTS >> team >> was not aware of this bug... >> >> I am the one who provided these updates. This issue must have slipped >> through my LDAP tests. I will investigate this as soon as possible and >> provide a fix consequently. >> >> Mike, you did the latest 389-ds-base update. Did you notice anything >> wrong >> during your tests? > > For uploading 1.3.3.5-4+deb8u6, I unfortunately did not do much smoke > testing regarding the LDAP query stuff (the patch was about indefinite > SSL connection hangs). > > Let me know, if you need help looking into this (due to e.g. time > constraints or what not on your side). as with version 1.3.5.17-2 everything worked fine, we didn't investiagte further... So I can only report that we didn't encounter any errors with all the versions shipped in debian 9. Regards Jan
Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
to mention: with version 1.3.5.17-2 in stretch everything works fine again.
Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
Package: 389-ds Version: 1.3.3.5-4+deb8u5 Severity: high since 26.10.2018 our nextcloud installations can't authenticate against 389-ds anymore. This seems to have an relation to the latest update in 389-ds - it happend after we applied these two updates: 389-ds-base (1.3.3.5-4+deb8u5) jessie-security; urgency=high * Non-maintainer upload by the LTS Team. * Fix regression introduced by +deb8u4: checking of empty attributes causes crash. -- Hugo Lefeuvre Thu, 25 Oct 2018 13:03:54 +0200 389-ds-base (1.3.3.5-4+deb8u4) jessie-security; urgency=high * Non-maintainer upload by the LTS Team. * CVE-2018-14648: A specially crafted search query could lead to excessive CPU consumption in the do_search() function. An unauthenticated attacker could leverage this flaw to cause a denial of service. -- Hugo Lefeuvre Wed, 24 Oct 2018 17:16:21 +0200 On the php-side (nextcloud we get the error: Result is: Protocol error (2) at \/opt\/nextcloud-demo\/apps\/user_ldap\/lib\/LDAP.php On the 389-ds side we find in access log "invalid attribute request": [26/Oct/2018:18:29:19 +0200] conn=66 op=0 BIND dn="uid=owncloud-bind,ou=Special Users,dc=example,dc=net" method=128 version=3 [26/Oct/2018:18:29:19 +0200] conn=66 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=owncloud-bind,ou=special users,dc=example,dc=net" [26/Oct/2018:18:29:19 +0200] conn=66 op=1 SRCH base="(null)" scope=2 filter="(&(|(objectClass=inetorgperson))(|(mail=d...@example.org)))", invalid attribute request [26/Oct/2018:18:29:19 +0200] conn=66 op=1 RESULT err=2 tag=101 nentries=0 etime=0 [26/Oct/2018:18:29:19 +0200] conn=66 op=2 SRCH base="(null)" scope=2 filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))", invalid attribute request [26/Oct/2018:18:29:19 +0200] conn=66 op=2 RESULT err=2 tag=101 nentries=0 etime=0 [26/Oct/2018:18:29:19 +0200] conn=66 op=3 SRCH base="(null)" scope=2 filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))", invalid attribute request [26/Oct/2018:18:29:19 +0200] conn=66 op=3 RESULT err=2 tag=101 nentries=0 etime=0
Bug#911223: still references for icedove and iceweasel in /etc/mate/defaults.list
Package: debian-mate-default-settings Version: 1.16.1-1 Severity: normal Since iceweasel and icedove are replaced in Debian stretch completely, the mate defaults.list should be updated accordingly. The actual settings leads e.g. to the problem, that in ltsp environment an remote thunderbird doesn't know how to open http links in emails. Maybe other things are affected as well. diff -u defaults.list.orig defaults.list --- defaults.list.orig 2018-10-17 11:37:14.057760705 +0200 +++ defaults.list 2018-10-17 11:37:31.805712725 +0200 @@ -2,7 +2,7 @@ application/csv=libreoffice-calc.desktop application/excel=libreoffice-calc.desktop application/javascript=pluma.desktop -application/mbox=icedove.desktop +application/mbox=thunderbird.desktop application/msexcel=libreoffice-calc.desktop application/mspowerpoint=libreoffice-impress.desktop application/msword=libreoffice-writer.desktop @@ -11,8 +11,8 @@ application/pdf=atril.desktop application/postscript=atril.desktop application/ram=vlc.desktop -application/rdf+xml=iceweasel.desktop -application/rss+xml=iceweasel.desktop +application/rdf+xml=firefox-esr.desktop +application/rss+xml=firefox-esr.desktop application/rtf=libreoffice-writer.desktop application/sdp=vlc.desktop application/smil=vlc.desktop @@ -118,7 +118,7 @@ application/x-gzip=engrampa.desktop application/x-gzpdf=atril.desktop application/x-gzpostscript=atril.desktop -application/xhtml+xml=iceweasel.desktop +application/xhtml+xml=firefox-esr.desktop application/x-hwp=libreoffice-writer.desktop application/x-java-archive=engrampa.desktop application/x-javascript=pluma.desktop @@ -257,16 +257,16 @@ image/x-xpixmap=eom.desktop image/x-xwindowdump=gimp.desktop inode/directory=caja-folder-handler.desktop -message/rfc822=icedove.desktop +message/rfc822=thunderbird.desktop misc/ultravox=vlc.desktop multipart/x-zip=engrampa.desktop text/comma-separated-values=libreoffice-calc.desktop text/abiword=abiword.desktop -text/calendar=icedove.desktop +text/calendar=thunderbird.desktop text/css=pluma.desktop text/csv=libreoffice-calc.desktop text/google-video-pointer=vlc.desktop -text/html=iceweasel.desktop +text/html=firefox-esr.desktop text/javascript=pluma.desktop text/mathml=pluma.desktop text/plain=pluma.desktop @@ -296,7 +296,7 @@ text/x-sql=pluma.desktop text/x-tcl=pluma.desktop text/x-tex=pluma.desktop -text/x-vcard=icedove.desktop +text/x-vcard=thunderbird.desktop text/x-xml-abiword=abiword.desktop video/3gpp=vlc.desktop video/dv=vlc.desktop @@ -349,12 +349,12 @@ x-scheme-handler/apt=apturl.desktop x-scheme-handler/ghelp=yelp.desktop x-scheme-handler/help=yelp.desktop -x-scheme-handler/http=iceweasel.desktop -x-scheme-handler/https=iceweasel.desktop +x-scheme-handler/http=firefox-esr.desktop +x-scheme-handler/https=firefox-esr.desktop x-scheme-handler/icy=vlc.desktop x-scheme-handler/icyx=vlc.desktop x-scheme-handler/info=yelp.desktop -x-scheme-handler/mailto=icedove.desktop +x-scheme-handler/mailto=thunderbird.desktop x-scheme-handler/magnet=transmission-gtk.desktop; x-scheme-handler/man=yelp.desktop x-scheme-handler/mmsh=vlc.desktop
Bug#910874: unattended-upgrades removes packages even if
Package: unattended-upgrades
Version: 0.93.1+nmu1
Severity: serious
Even if I have configured 'Remove-Unused-Dependencies "false";' in
apt.conf.d/50unattended-upgrades:
// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
Unattended-Upgrade::Remove-Unused-Dependencies "false";
it DOES remove packages (see below) as long as apt is configured as:
APT::AutoRemove::RecommendsImportant "false";
In my understanding this shouldn't be the case.
Here is the output of unattended-upgrade:
unattended-upgrade -d -v --dry-run
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: ['o=Debian,n=stretch,l=Debian-Security',
'o=Debian,n=stretch,l=Debian-Security']
Checking: icedove ([, ])
pkg 'enigmail' now marked delete
sanity check failed
Checking: icedove-l10n-de ([, ])
pkg 'enigmail' now marked delete
sanity check failed
Checking: iceowl-extension ([, ])
pkg 'enigmail' now marked delete
sanity check failed
Checking: libsnmp-base ([, ])
Checking: libsnmp30 ([])
Checking: lightning ([, ])
pkg 'enigmail' now marked delete
sanity check failed
Checking: thunderbird ([])
pkg 'enigmail' now marked delete
sanity check failed
Checking: thunderbird-l10n-de ([, ])
pkg 'enigmail' now marked delete
sanity check failed
pkgs that look like they should be upgraded: libsnmp-base
libsnmp30
Fetched 0 B in 0s (0 B/s)
fetch.run() result: 0
http://security.debian.org/pool/updates/main/n/net-snmp/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb'
ID:0 ErrorText: ''>
check_conffile_prompt('/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb')
found pkg: libsnmp-base
No conffiles in deb
'/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb'
(There is no member named 'conffiles')
http://security.debian.org/pool/updates/main/n/net-snmp/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb'
ID:0 ErrorText: ''>
check_conffile_prompt('/var/cache/apt/archives/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb')
found pkg: libsnmp30
No conffiles in deb
'/var/cache/apt/archives/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb'
(There is no member named 'conffiles')
blacklist: []
whitelist: []
Option --dry-run given, *not* performing real actions
Packages that will be upgraded: libsnmp-base libsnmp30
Writing dpkg log to
'/var/log/unattended-upgrades/unattended-upgrades-dpkg.log'
found partition of size 2 (['libsnmp-base', 'libsnmp30'])
found leaf package libsnmp-base
applying set ['libsnmp-base']
apt-listchanges: Reading changelogs...
/usr/bin/dpkg --status-fd 9 --no-triggers --unpack --auto-deconfigure
/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb
/usr/bin/dpkg --status-fd 9 --configure --pending
left to upgrade {'libsnmp30'}
found partition of size 2 (['libsnmp-base', 'libsnmp30'])
applying set ['libsnmp-base', 'libsnmp30']
apt-listchanges: Reading changelogs...
/usr/bin/dpkg --status-fd 9 --no-triggers --unpack --auto-deconfigure
/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb
/var/cache/apt/archives/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb
/usr/bin/dpkg --status-fd 9 --configure --pending
left to upgrade set()
All upgrades installed
marking acpid for remove
marking acpi-support-base for remove
marking libao-common for remove
marking gstreamer1.0-plugins-ugly for remove
marking libsidplay1v5 for remove
marking dvdauthor for remove
marking libfreerdp-plugins-standard for remove
marking growisofs for remove
marking genisoimage for remove
marking brasero-cdrkit for remove
marking libopencore-amrnb0 for remove
marking libperl4-corelibs-perl for remove
marking cdrdao for remove
marking dmz-cursor-theme for remove
marking libopencore-amrwb0 for remove
marking libao4 for remove
marking wodim for remove
Packages that are auto removed: 'acpi-support-base acpid brasero-cdrkit
cdrdao dmz-cursor-theme dvdauthor genisoimage growisofs
gstreamer1.0-plugins-ugly libao-common libao4
libfreerdp-plugins-standard libopencore-amrnb0 libopencore-amrwb0
libperl4-corelibs-perl libsidplay1v5 wodim'
echo 'acpi-support-base:all deinstall' | /usr/bin/dpkg --set-selections
echo 'acpid:amd64 deinstall' | /usr/bin/dpkg --set-selections
echo 'brasero-cdrkit:amd64 deinstall' | /usr/bin/dpkg --set-selections
echo 'cdrdao:amd64 deinstall' | /usr/bin/dpkg --set-selections
echo 'dmz-cursor-theme:all deinstall' | /usr/bin/dpkg --set-selections
echo 'dvdauthor:amd64 deinstall' | /usr/bin/dpkg --set-selections
echo 'genisoimage:amd64 deinstall' | /usr/bin/dpkg --set-selections
echo 'growisofs:amd64 deinstall' | /usr/bin/dpkg --set-selections
echo 'gstreamer1.0-plugins-ugly:amd64 deinstall' | /usr/bin/dpkg
--set-selections
echo 'libao4:amd64 deinstall' | /usr/bin/dpkg --set-selections
echo 'libao-common:amd64 deinstall' | /usr/bin/dpkg --set-selections
echo 'libfreerdp-plugins-standard:amd64 deinstall' | /usr/bin/dpkg
--set-selections
echo 'libopencore-amrnb0:amd64 deinstall' | /usr/bin/dpkg --set-selections
echo
Bug#905184: [Pkg-freeipa-devel] Bug#905184: upgrade of 389-ds-base fails if /var/lib/dirsrv is on different partition as /etc
solves the issue:
--- updates.orig/60upgradeconfigfiles.pl2018-09-03 09:58:45.911804203
+0200
+++ updates/60upgradeconfigfiles.pl 2018-09-03 09:59:36.420699451 +0200
@@ -31,7 +31,7 @@
next if (! -f $oldname); # does not exist - skip - already
(re)moved
my $newname = "$bakdir/$file";
$! = 0; # clear
-rename $oldname, $newname;
+move $oldname, $newname;
if ($!) {
push @errs, ["error_renaming_config", $oldname, $newname, $!];
}
@@ -57,7 +57,7 @@
next if (! -f $oldname); # does not exist - not backed up
my $newname = $inf->{slapd}->{config_dir} . "/" . $file;
next if (-f $newname); # not removed
-rename $oldname, $newname;
+move $oldname, $newname;
}
return @errs;
}
Bug#905184: [Pkg-freeipa-devel] Bug#905184: upgrade of 389-ds-base fails if /var/lib/dirsrv is on different partition as /etc
Hi Timo, sorry for delay, I missed the mail. > What if you change 'rename' with 'move' in /usr/share/dirsrv/updates/*.pl? It's suffucient to change it in /usr/share/dirsrv/updates/60upgradeconfigfiles.pl then it works fine. Regards Jan
Bug#905184: upgrade of 389-ds-base fails if /var/lib/dirsrv is on different partition as /etc
Package: 389-ds-base
Version: 1.3.5.17-2
Severity: serious
Upgrade to newer version of 389-ds-base fails with dpkg configuration
error on postinstall script /var/lib/dpkg/info/389-ds-base.postinst
After getting full log of postinstall I saw:
[18/08/01:10:33:37] - [Setup] Info Could not rename config file
'/etc/dirsrv/slapd-INSTANCE/slapd-collations.conf' to
'/var/lib/dirsrv/slapd-INSTANCE/bak.bak/slapd-collations.conf'. Error:
Invalid cross-device link
This is caused by line 24:
setup-ds -l $OUT -u -s General.UpdateMode=offline > $OUT 2>&1
calling this directly we got the same failure.
The reason is that the script tries to make a backup of configuration
files in /var/lib/dirsrv/INSTANCE/bak.bak:
# these files are obsolete, or we want to replace
# them with newer versions
my @toremove = qw(slapd-collations.conf);
# make a backup directory to store the deleted config file, then
# don't really delete it, just move it to that directory
my $mode = (stat($inf->{slapd}->{config_dir}))[2];
my $bakdir = $inf->{slapd}->{bak_dir} . ".bak";
if (! -d $bakdir) {
$! = 0; # clear
mkdir $bakdir, $mode;
if ($!) {
return ('error_creating_directory', $bakdir, $!);
}
}
my @errs;
for my $file (@toremove) {
my $oldname = $inf->{slapd}->{config_dir} . "/" . $file;
next if (! -f $oldname); # does not exist - skip - already (re)moved
my $newname = "$bakdir/$file";
$! = 0; # clear
rename $oldname, $newname;
if ($!) {
push @errs, ["error_renaming_config", $oldname, $newname, $!];
}
}
According to
https://www.unix.com/shell-programming-and-scripting/27747-perl-rename-failed.html
the perl rename call can cause this error.
My workaround was to create the directories in /etc and make symlinks in
/var/lib/dirsrv/...
mkdir /etc/dirsrv/slapd-INSTANCE/bak
ln -s /etc/dirsrv/slapd-INSTANCE/bak /var/lib/dirsrv/slapd-INSTANCE/bak
mkdir /etc/dirsrv/slapd-INSTANCE/bak.bak
ln -s /etc/dirsrv/slapd-INSTANCE/bak.bak
/var/lib/dirsrv/slapd-INSTANCE/bak.bak
Upgrade succeeded now.
I originally encountered this problem while upgrading 389-ds-base on
jessie from 1.3.3.5-4 to 1.3.3.5-4+deb8u1. Since upgrade scripts didn't
change this should be still valid for the actual version.
