Hi Andrew, On Thu, Oct 31, 2013 at 09:26:43AM +1300, Andrew Bartlett wrote: > > If these assumptions are correct (can someone confirm that?), we only need > > to > > deal with passdb.tdb. If we can find a way to work around that race > > condition, > > we could do that move as well. > > Could we ensure the pam module is disabled in .preinst and conditionally > re-installed in a .postinst?
Excellent question! We can do this with conflicts in samba-libs. > Also, is this .postinst on the right package anyway? Shouldn't it be on > whatever package actually references passdb.tdb, such as samba-libs > (presumably that owns libpdb)? Correct. I have patches (which I will test some more and commit soon), which do the move in the samba-libs preinst. Together with a conflict on the earlier version of the packages which accessed the tdb files directly, this should fix the problem: With the conflicts, samba-libs can only be installed once the old packages (samba, winbind, samba-common-bin [for smbpasswd and net] and libpam-smbpass) are no longer present. During the upgrade, this means they will already be upgraded (on new installations, there is no issue). There is no race condition, however, as none of these new versions will work, because they are all linked against libraries in samba-libs, which don't exist yet. So smbd and winbind will not be running, and will be unable to run (even if the admin tries to start them). The pam module also fails silently (this doesn't prevent login). In the samba-libs preinst, we can fix the location of the files without any risk, as there is nothing on the system which accesses the affected tdb files. The move happens before samba-libs is installed, so before any of the binaries mentioned above are able to run, the tdb files are already in the right location. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
