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