Services offered by Debian should be dogfooding the real packages on DSA hosts.
The problem
If I had a magic wand, I would like to resolve the situation around official instances of packaged servers being unable to dogfood their packaging work. I think this sends the wrong message as "If it's not good enough for Debian to use, why should I?".
Actual situation
From what I've noticed in DebConf talks, it's explained by the fact the service maintainers do not have root access on DSA machines. This leads to either using upstream installation methods or deploying to non-DSA machines. It seems to me that this is either a solved problem, or can be made so, given it's similar to University provided computing resources.
Expected situation
For (a simplified) example that I'm familiar with, matrix.debian.social
should be as trivial as apt install matrix-synapse plus a config file.
Going by the existing docs on apache vhosts and email, one possible
interface would be:
echo matrix-synapse >> /srv/foo.debian.org/packages/install
vi /srv/foo.debian.org/packages/etc/matrix-synapse/conf.d/social.yaml
sudo -u foo package-setup foo.debian.orgThe permitted packages and config paths could even be managed by a whitelist under the control of DSA to prevent a complete wildwest. The important thing is that a service owner can make (certain) direct changes without having to co-ordinate DSA approval.
Additional information
I first wrote directly to debian-admin but that list isn't publicly archived, so I'll only paraphrase the response I got:
- Installation + configuration can have a risk of privilege escalation
- DSA might be happy with MRs to the puppet setup for the simple cases
- There is no external testing on the current puppet code, holding back collaboration by non-DSA
- There have been small experiments with containerisation (IMO, that's abandoning the strength of Debian's integration)