[Qemu-devel] handling samba shares in slirp networking

[Qemu-devel] handling samba shares in slirp networking

[Michael Tokarev]

Hello.

We're getting more and more various bugreports and questions
about -net user,smb=xxx - about usage of "private" smbd to
share a given directory.

In short: it does not quite work.  Due to alot of various
reasons, most things being wrong/insufficient smb.conf
generated by slirp code.

Looking at the code, I'd say it should be much easier to
do it the other way: to run a script with two parameters --
directory to export, and a share name for the said directory.
This script will create a temporary config/runtime dir,
like qemu slirp code does now, create necessary smb.conf
in there, and run smbd with appropriate options (including,
for example, -l (logdir) and -F (stay in foreground)).

When smbd finishes, the script will remove that temp dir
and exit.

This way, it will be possible to customize the script easily,
to compensate for samba being changed over time, or it even
can check smbd version and generate different configs.

This way, it will also be possible to run custom smbd binary,
or add a debug option, or whatnot.

I propose a new -net user parameter, smbscript=, defaulting
to $libdir/smbscript.

Also, current code has at least 3 more defects.

First, it uses home-grown implementation of socketpair()
function, which should be used instead.

Second, the code does not watch for smbd dying (it
should be possible to do if smbd does not daemonize).

And 3rd, when smbd process we just spawned dies, slirp
code happily redirects samba-related network packets
to HOST smbd.  This is completely wrong.

I can implement at least the main part, but I wanted to
discuss it first.

Comments?

Thanks,

/mjt

Re: [Qemu-devel] handling samba shares in slirp networking

[Jan Kiszka]

On 2012-07-17 20:50, Michael Tokarev wrote:
> Hello.
> 
> We're getting more and more various bugreports and questions
> about -net user,smb=xxx - about usage of "private" smbd to
> share a given directory.
> 
> In short: it does not quite work.  Due to alot of various
> reasons, most things being wrong/insufficient smb.conf
> generated by slirp code.
> 
> Looking at the code, I'd say it should be much easier to
> do it the other way: to run a script with two parameters --
> directory to export, and a share name for the said directory.
> This script will create a temporary config/runtime dir,
> like qemu slirp code does now, create necessary smb.conf
> in there, and run smbd with appropriate options (including,
> for example, -l (logdir) and -F (stay in foreground)).
> 
> When smbd finishes, the script will remove that temp dir
> and exit.

Cleanup should remain the domain of QEMU as the script may stumble and
fall as well. So the temp dir has to be provided by QEMU, too.

> 
> This way, it will be possible to customize the script easily,
> to compensate for samba being changed over time, or it even
> can check smbd version and generate different configs.
> 
> This way, it will also be possible to run custom smbd binary,
> or add a debug option, or whatnot.

Agreed.

> 
> I propose a new -net user parameter, smbscript=, defaulting
> to $libdir/smbscript.

Should probably carry something "qemu" related in its name.

> 
> Also, current code has at least 3 more defects.
> 
> First, it uses home-grown implementation of socketpair()
> function, which should be used instead.
> 
> Second, the code does not watch for smbd dying (it
> should be possible to do if smbd does not daemonize).
> 
> And 3rd, when smbd process we just spawned dies, slirp
> code happily redirects samba-related network packets
> to HOST smbd.  This is completely wrong.

Hmm, the latter is bad indeed, the first issue is just a bit ugly.
Patches welcome, of course.

> 
> I can implement at least the main part, but I wanted to
> discuss it first.
> 
> Comments?

Sounds good, looking forward to patches. Outsourcing the smbd setup to a
script will likely help debugging and fixing version related smbd issues
quicker. I just want those fixes upstream, not in some private user
scripts - though I guess that is obvious.

Note that I recently fixed yet another issue of the smbd configuration
for Windows 7 guests. Maybe that resolves some of your bug reports.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux