Samba management

Deryck Hodge deryck at
Wed Jun 21 14:16:29 GMT 2006

On 6/21/06, Volker Lendecke <Volker.Lendecke at> wrote:
> On Wed, Jun 21, 2006 at 05:00:45PM +0400, Alexander Bokovoy wrote:
> > I agree with you on this. I also had ideas to actually rewrite SWAT in
> > samba3 by backporting ejs and webserver code (as standalone app) from
> > samba4. This way the SWAT actual code will be in ejs and the same API
> > can be maintained (and used) between both samba3 and samba4 for most of
> > the interface code while actual low-level implementation will be different.
> How well encapsulated is the ejs engine really? Can we just
> dump it into Samba3 and have it available?

I just don't think this is a good idea.  EJS makes a nice experiment, but
from my playing with it, I don't think it's ready for prime time.  And
it doesn't
really solve the larger question here.  EJS is just an embedded language,
all the hooks into Samba have to be created separately.  Case in point, it
takes a SoC project just to get someone to write a user manager in EJS.
Granted some of this work has been done, but my impression is that it's
very ldb/samba4 specific.

And what does EJS really gain you?  If we're concerned about consumers,
who is the consumer of EJS?  It's not the same JavaScript that web developers
are familiar with.  The hooks into Samba and language addons (like decent
string handling) are implemented in an especially C-like syntax, rather
than a JavaScript-like object model.  Sys/Network Admins certainly don't
know JavaScript, at least not any I've ever met. :-)

EJS is just trying to be too clever, and muddies the waters of the
real problem,
IMO.  A GUI and a management library are two separate issues, and you can't
write a web app to manage Samba without a proper management API.  EJS
does not provide that API.  The hooks into Samba4 do not provide that API, at
least not in any way that I could follow.

No matter how strongly people feel about a web GUI, I just don't see the point
now.  Every distro I've played with ships with a Samba configuration tool, which
all work much better than SWAT (either in Samba3 or Samba4).  If your just
absolutely stuck on having to provide a nice web GUI inside Samba itself,
then get the management API right first, expose that API as a web service,
and let someone write the web client on top of that.  This
architecture just makes web development, and I suspect other development as
well ;-), a nightmare.


Deryck Hodge

"Aimless days, uncool ways of decathecting" --Mike Doughty (2005)

More information about the samba-technical mailing list