web server in Samba4

[Andrew Tridgell]

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
    server.

  - 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
    'embedded server pages' and 'embedded javascript' processors into
    the Samba4 source tree, and hooked it into the web server. See 
      http://www.appwebserver.org/products/esp/esp.html
    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:

  - should we rely on client side javascript support, for things like
    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
  javascript is a language that web designers are almost always
  familiar with.

Cheers, Tridge