[Webapps-common-discuss] Notes from webapp BoF yesterday at Debconf

[Geoffrey Thomas]

(BCC people who were present)

Hey webapps-common folks!

Yesterday at Debconf, I got some people together for a BoF to discuss how 
best to handle webapps in Debian and to try revitalizing the 
webapps-common effort. We talked about a bunch of issues, and I've 
included detailed notes at the bottom for those who are curious, but here 
are some high-level topics:

We're more interested in reasonable automatic configuration for people who 
don't deeply care how an app works, than making things work very well for 
people who will be closely working with an app (mass hosts, etc.). But we 
do want to support multiple deployments.

We want a common tool that each webapp has config for, that handles
   - Deploying new instances of a site
   - Importing/exporting content, if the webapp supports some format for
     it upstream
   - Handling database migrations on upgrade
   - Keeping plugins in a symlink farm, with a2enmod-style tools to add
     and remove them to an instance, so that installing a plugin's package
     doesn't automatically enable it for all instances
   - Snapshotting the current version of everything from Debian, which
     gives you stability, but cuts you loose from Debian (including for
     security updates)

It seems like having short-security-lifecycle webapps in the stable 
release is of limited value to users, and a pain to the security team. One 
possible approach is webapps that live in testing and backports but never 
reach stable itself. It's still valuable to have apt-installable webapps 
even if we don't have stable-quality security support for them, since 
Debian packaging provides other benefits.

More detailed notes follow.


On automatic configuration:
- One important role for policy to play is in negotiating automatic
   configuration / the desire to work out of the box, against the limited
   URL namespace.
- The priority should be towards people casually interested in the
   package who just want to `apt-get install` something and have it work.
   - People who are doing careful deployment of a site are likely to learn
     a lot about the package and how its upstream works, and work with the
     upstream release directly.
   - People who are doing mass hosting will probably have some tooling that
     they're familiar with, and getting Debian clearly better than theirs
     seems like it may not be worth the work, immediately.
- That said, we do want to support deploying multiple instances on the
   same machine.
   - We'd prefer not to use upstream support for multi-site within a
     deployment. Not many upstreams support it, and some (e.g. Drupal)
     recommend against it.
- We also strongly want to support importing content from existing
   sites. Not all webapps will have an import/export mechanism, but for
   those that do, it's important to document and standardize how to get
   your content running on the deployment.
- Handling database configuration sounds awesome.
- Handling database upgrades / migrations on version upgrade sounds very
   awesome. We're not sure if doing this in the postinst makes sense.
- dbconfig-common should be involved. It seems like it hasn't seen a lot
   of work recently, and none of us are very familiar with it or how to
   make it work well.

On deployment configuration:
- General preference is to support multiple deployment, geared towards
   small numbers of deployments. People seem to like Trac's packaging,
   incidentally.
- Make a directory with a symlink farm for plugins that the tool
   mentioned above can manipulate. It's also a convenient place to put
   unpackaged plugins and have them work against a packaged webapp; in
   addition, you can convert the symlinks into copies to detach yourself
   from Debian updates.
- Possibly we could use this directory for non-plugin language modules,
   but that gets somewhat tricky. For that, and especially if we want to
   talk about snapshotting the interpreter, we're better off integrating
   with Docker (and the Docker maintainers present were interested in
   making this work smoothly).
- Import/export is important for freedom reasons, to make packaged
   webapps useful (migration from some existing server), and to support
   backups. Database backups should integrate with dbconfig-common.

On security support:
- WordPress is fairly high-percentile on security support quality, and
   even it doesn't have a support lifecycle as long as a stable release.
   Many apps have no stable release policy.
- There's probably not much value in installing from Debian from a
   security viewpoint, and major version updates in stable seem to defeat
   the point.
- Maybe we should have certain webapps be present in unstable and
   testing and backports, but never in stable.
   - We'd need to define some mechanism for this to work in the archive.
- Alternatively, we could use a webapp team PPA.
- Setting up webapps so that their code / docroot isn't writable by the
   web useful is very valuable for security / hardening, and that's hard
   to do with upstream-distributed webapps. So even without security
   support, we can provide security advantages in packaging.
   - Having policies about this would be nice.
- We might want to be steering users towards apps that are more
   security-supportable instead of the popular and highly-vulnerable
   ones, but to some extent the vulnerability is merely due to their
   popularity.

Also:
- There are lots of ways to run a webapp (straight CGI, mod_foo,
   FastCGI) and we should make it easy to move between them.
- When a webapp needs a database, it shouldn't depend on a database
   package because running a separate DB server is pretty common, but we
   _should_ make it the case that a normal apt install is helpful for
   users who don't already have a database server.
- cPanel has a deployment interface and a one-click upgrade interface,
   but they don't really work. We may or may not be able to do better,
   but it's worth noting we aren't the first people to try.
- We might want to aggressively use systemd's template unit stuff to
   support multiple instances (you could have wordpress at myblog.service,
   wordpress at teamblog.service, etc.)
- We could define an fstab-style file (tentative name "/etc/webtab") to
   handle URL namespace allocation and routing, in a way that's agnostic
   to web server etc.

-- 
Geoffrey Thomas
https://ldpreload.com
geofft at ldpreload.com