web server in Samba4
tridge at osdl.org
Sun May 29 03:18:24 GMT 2005
Support for web administration in Samba4 is starting to take shape, so
I thought it might be worthwhile to outline some design decisions here
in case anyone has any comments.
The main aims are:
- create a web administration interface that is good enough that
everyone wants to use it. It should not just be an interface for
inexperienced admins, it should be something that everyone
(including team members) finds the best way of working with the
- make sure it is trivial to use, while being secure.
- provide a much richer interface than the Samba3 SWAT tool. It
should be more like the typical 'NAS' interfaces that vendors tend
to wrap around Samba, with admin and monitoring interfaces.
- make it easy to extend with new functionality.
- make it easy to access core smbd functionality from inside the web
server code (for things like ldb, messaging, loadparm, libnet etc)
The code is now starting to take shape quite well. The basic features
of it so far are:
- async web server running as a task inside smbd. It is enabled by
default, and by default listens on port 901.
- after doing 'make install' you can start a smbd with no config
file and no samdb and you can point your web browser at server:901
and get the web interface
- support for https using gnutls
- it supports automatic http/https detection. It looks at the first
byte from the client to work out if you are using SSL. This allows
us to have both the https server and http server on the same
port. That makes things less error prone for inexperienced users.
- automatic TLS self-signed certificate creation. One of the things
new users always struggle with is creating some certificates for
their new web server. Experienced admins have no trouble, but new
admins find this a major pain, despite the existance of zillions
of howtos. We avoid that completely by auto-creating self-signed
certificates if none exist. Experienced admins will install their
own certificates of course, but at least the auto creation means
that less experienced admins will get a https connection the first
time they use SWAT. The autocreation is done directly using the
gnutls API, rather than calling external programs, which should
make it much more robust to installing and packaging problems.
- server side scripting using esp/ejs. I have integrated the
the Samba4 source tree, and hooked it into the web server. See
for more information.
This should allow the easy creation of quite a rich web interface
for Samba4, as it is vastly easier to generate good html with a
server side scripting language than with straight C.
- I have added hooks to support session and application persistant
stores in the esp scripting environment. These make web
programming much easier, as they get around the core problem of
web programming, which is the handling of state between requests.
- I have started to add extensions to ejs to allow for calls into
the Samba4 C code. For example, you can access any smb.conf
variable, and can do ldb searches from esp pages. Simo is working
on auth hooks.
If you want to see what esp/ejs programming is like, then take a look
at http://samba.org/ftp/unpacked/samba4/swat/ and have a read of the
example scripts in the esptest/ directory. Also note the
auto-redirection to https in index.esp.
I am quite hopeful that this will provide a good basis for an
excellent web admin interface for Samba4.
Some open questions:
nice menus? Maybe we should use one of the existing js menu
systems, like http://www.mojavelinux.com/projects/dommenu/ ?
- what sort of look&feel should we go for? Deryck will very likely be
the lead for the web design part, and we have discussed this a
bit, but if you have a favorite example site you think we should
look at then please do tell.
Some obvious questions and answers:
Q) why didn't we use apache or a similar existing web server?
A) because I want the web server to be a core part of Samba4 that
_every_ Samba4 install can rely on being present. For core features
I am very reluctant to rely on external tools. There is also the
problem of integration with calls into the smbd C library.
In contrast, I didn't grab an embeddable TLS library, and instead
used gnutls. This is because the web server is perfectly functional
without TLS, so Samba4 can still be used if gnutls is not present.
Q) why use esp/ejs instead of perl/python/ruby/foobar ?
A) because its small and simple enough to embed inside the Samba4
sources, so we can absolutely rely on it being present. It also has
very good support for extending the language with C calls, and
More information about the samba-technical