Re: [Qemu-devel] Improved shared folders support

[Peter Wu]

On Tuesday 04 November 2014 09:13:31 Michael Tokarev wrote:
> >> The whole thing needs to be rewritten to use a shell script to create
> >> smb.conf and to call smbd.  It's something I wanted to do for very long
> >> time, the only question is where to put this script so a user can
> >> easily customize it.  In debian we have a rule that anything in /etc
> >> is a conffile, and it gets upgraded (when upgrading the corresponding
> >> package) only if it hasn't been modified by the user.  Everything else
> >> (in /usr/lib, /usr/share etc) gets upgraded unconditionally.  So maybe
> >> storing it in /etc/qemu/run-smbd.sh or somehting like that makes sense.
> > 
> > I do not think that everyone is (or wants to be) a Samba wizard. For
> > that reason, I see little value in giving the user too much control over
> > the creation of the samba config file. There exists helpers for setting up
> > bridges, but that is because it may need more privileges, and starting 
> > samba is
> > not such a case.
> 
> The talk is not about being a wizard or relying on users creating that
> script.  The talk is about letting user a quick way to fix stuff with
> new or unusual samba combination, without a need to recompile qemu
> binary.  Changing a shell script is trivial, including trial and error
> (so you dont really need to be a wizard), while recompiling is much
> more difficult.

So this is more to workaround bugs in Samba should they occur? I
previously mentioned a possible smbd=/path/to/smbd option, but it could
also become a smbhelper=/path/to/helper.sh. Possible options:

 - Generate the smb.conf and pass the temp dir containing it to that
   helper. smbd is started by the helper.
 - Do not create smb.conf nor create a tempdir, let the helper control
   this. smbd is started by the helper.
 - Same as previous, but allow smb and smbhelper to co-exist and pass
   the smb option via an envvar to smbhelper.

> > That single program could be a wrapper script that modifies the files as
> > needed.
> > 
> > I propose to keep a simple interface which do not need users to modify a
> > shell script or learn Samba. Consider Virtual Box' and VMWare' shared
> > folders functionality. It allows multiple folders to be specified with
> > these properties:
> 
> Again, my variant does not mean users will need to learn anything, it
> is only needed in emergency cases.  My proposal is to move all current
> smb.conf file creation from qemu binary to an external shell script
> which is *shipped by qemu*, and which creates the same setup as currently
> done by qemu binary.  But with it being a shell script, it will be easy
> to modify it *if needed*.

If Samba options have be to be modified in this way, then that is a bug
in QEMU and must be fixed (consider the Samba config an implementation
detail which does not need to be exposed to the user in one way or
another).

I would like to have the ability to let QEMU generate the config file
*without* having to rely on an external script with a hard-coded path.
Consider out-of-tree builds and testing such binaries. If a helper is
wanted, see above for a possible smbhelper.

> Modifying already created smb.conf is not a good idea, that requires
> even more wizardy skills.

For manual *testing* you can actually modify the smb.conf between
invocations of smbd (that is, before the guest accesses port 139 or
445). I actually did this to add "log level". In the proposed extension
of the smb option I mentioned rewriting smb.conf on config changes, but
that would then be done by QEMU, not the user.

Btw, what do you think about the proposed smb extension to allow more
shares with custom names?
-- 
Kind regards,
Peter
https://lekensteyn.nl