Printing and smbd -i

[simo]

On Thu, 2011-06-30 at 22:57 +0400, Matthieu Patou wrote:
> Hello Simo,
> On 30/06/2011 15:45, simo wrote:
> > Hello all,
> >
> > One of the goals we have for the printing subsystem is to be able to
> > completely disable it (to the point of not even compiling it in in order
> > to further reduce size of binaries for embedded devices).
> >
> > In order to do that we started building a spoolssd daemon that is forked
> > off smbd early on. This daemon also takes care of starting the
> > background queue process, and all internal calls to the printing
> > subsystem have been changed to use the rpc protocol (short-circuited
> > when spoolssd is not configured to run).
> >
> > One of the final steps is to move some of the stuff that should have
> > been done in the background queue process but were recently put into the
> > main smbd process instead by David Disseldorp.
> >
> > The 'problem' here is that the background queue process is not started
> > when smbd is run in interactive mode, which would make printing
> > unavailable when smbd is run in that mode.
> >
> > I think the goal of making the printing susbsystem more independent and
> > pluggable is more important, so I would like to know if always forking
> > the background queue process even when the -i switch is provide is a
> > good enough compromise. Same fate for spoolssd, if you configured it to
> > be used it would be forked even in the smbd -i case.
> >
> > If there are no strong objections I'll proceed this way, if you have
> > objection though, please give me alternatives, as doing nothing is not
> > an option I am willing to accept.
> And what about smdb -i that would create only 1 process for print server 
> so that it wouldn't be too complicated to debug the print server if needed ?

The print server needs the smbd server. We may try to see if there is a
clever way to still run the background queue processing in the main smbd
but I am asking if this is really worth the effort.

> Also how do you think this integrate with the vision of a unified samba 
> 4.0 where as kai noted samba -i -M single starts 1 process that don't 
> exit after the first served request.

I don't think we can make smbd part of it without loosing features or
compromising smbd's security for now.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>