qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Wu <peter@lekensteyn.nl>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Improved shared folders support
Date: Wed, 05 Nov 2014 18:29:58 +0100	[thread overview]
Message-ID: <2755042.udDQ3D2s5V@al> (raw)
In-Reply-To: <54586E8B.2040802@msgid.tls.msk.ru>

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

  reply	other threads:[~2014-11-05 17:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 16:55 [Qemu-devel] slirp-smb broken with Samba 4.1 Jan Kiszka
2014-10-24 18:29 ` Michael Tokarev
2014-10-24 19:58   ` Michael Tokarev
2014-10-24 20:43     ` Michael Tokarev
2014-10-25  7:23       ` Jan Kiszka
2014-11-03 12:22 ` Peter Wu
2014-11-03 12:58   ` Michael Tokarev
2014-11-03 19:46     ` [Qemu-devel] Improved shared folders support (was: Re: slirp-smb broken with Samba 4.1) Peter Wu
2014-11-04  6:13       ` [Qemu-devel] Improved shared folders support Michael Tokarev
2014-11-05 17:29         ` Peter Wu [this message]
2014-11-04 22:53   ` [Qemu-devel] slirp-smb broken with Samba 4.1 Peter Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2755042.udDQ3D2s5V@al \
    --to=peter@lekensteyn.nl \
    --cc=jan.kiszka@siemens.com \
    --cc=mjt@tls.msk.ru \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).