On Tue, Oct 29, 2013 at 10:10:58AM +1300, Andrew Bartlett wrote: > On Mon, 2013-10-28 at 22:00 +0100, Ivo De Decker wrote: > > Hi, > > > > On Mon, Oct 21, 2013 at 10:37:49PM +1300, Andrew Bartlett wrote: > > > > Ok. I think we need to undo this /var/lib/samba/private nonsense. It > > > > is a > > > > pointless and imperfect migration (as shown by this bug report), and the > > > > only rationale upstream ever gave for keeping these files in a separate > > > > "private" directory is some stupid and ancient target OS that couldn't > > > > properly set per-file permissions. Debian users have been using > > > > /var/lib/samba exclusively for the better part of a decade; migrating to > > > > this private/ directory adds no value for our users. > > > > > > In the alternate, the only reason this happened now is because we are > > > finally having the Debian packages follow where upstream has decided to > > > put the files. Having different packages moving files around to > > > different places only increases user confusion, and creates 'only on > > > Debian' bugs. > > > > > > For example, a significant number of issues came about as folks tried to > > > divine if a particular TDB was short, medium or long-term, when no such > > > separation existed in the code. > > > > > > We (upstream) have gone to significant effort to integrate the FHS > > > changes that have been proposed via Debian, I can only ask that having > > > got to a mutually agreed state, that Debian not change it again, having > > > once more Debian packages special and different. > > > > I had a long talk with Jelmer yesterday about this bug. Here are a number of > > considerations from that discussion: > > > > > > First of all, it certainly isn't clear that the issue is caused by a mistake > > in unstable some time ago. I haven't been able to find any indication for > > that > > (yet) in any of the samba versions available on snapshot.debian.org. We've > > been using /etc/samba as private dir from the first 3.2 upload to the last > > 3.6 > > upload and there is no apparent usage of /var/lib/samba/private anywhere in > > the code of any of these versions. > > > > It is quite possible that the issue is triggered by a race condition in the > > tdb-handling (especially for passdb.tdb), which can result in the creation > > of > > the wrong tdb file during the upgrade, which messes up our move. This could > > be > > caused by the usage of the 'smbpasswd' command or the pam-smbpass pam > > module. > > I haven't had the time yet to create a situation where I can trigger the > > race > > condition. > > > > There are a number of ways to work around these possible race conditions > > during at the time of the move. An incomplete list of ideas (some of these > > would have to be combined to get to a complete fix): > > > > - Patch the passdb tdb module to do the move, instead of having it in > > samba.postinst. This isn't completely unprecedented, as the move of > > MACHINE.SID was supported by the samba code. > > > > - Track the fact that the move was done, by adding some field to the new tdb > > file. This might cause issues in tools that don't handle unknown fields. > > The > > samba4 upgrade script might be one of those. > > > > - Track the fact that the move was done, by making sure the old tdb can't be > > used anymore. This could be done by changing the version number of the old > > tdb to something non-existent. > > > > - Do some kind of merge of both tdb files, if they both exist. > > > > - When both tdb files exist, have a debconf question that gives some > > information about both (eg number of users), and ask the user to choose > > between them. > > > > Any decent implementation will require some careful planning and probably > > quite some discussion as well. It is clear that the new samba 4.x packages > > provide a nice step forward compared to the samba 3.6 packages, and these > > changes shouldn't be blocked by this problem. Therefore we are proposing to > > postpone this move for now. > > > > Moving the private dir to /var/lib/samba would cause an issue with the files > > kept by samba4 in /var/lib/samba/private. So the only obvious way forward > > would be to have a new version of our previous patch, which moves the 4 > > affected files back to /var/lib/samba. I really regret having to propose > > this, > > as I very much would like to avoid reintroducing a patch like that, but at > > this point, I don't really see any other short term options. > > > > So the proposal is to reintroduce something like the old patch, and try to > > get > > that version into shape for testing/jessie. After that, we can figure out > > how > > to get this move done the right way. > > > > Any thoughts, comments? > > > > > Or in the alternate, propose such changes upstream. > > > > Moving the files upstream would inflict all this pain on other > > distributions, > > so someone would still have to sort this all out. > > I strongly oppose both proposals. The upgrade to Samba 4.0 is the time > to correct this silly business of having files in different paths to > what upstream has, rightly or wrongly, chosen.
What approach would you suggest for a race-free migration of existing files to privatedir? Cheers, Jelmer
signature.asc
Description: Digital signature