On Mon, Jan 24, 2022 at 10:31:01AM +0100, Sébastien Delafond wrote:
>
> As part of an upcoming survey that we are preparing, we plan to ask
> Debian developers to rank, by order of importance, the most popular
> ideas of improvements for Debian.
>
> That's where you come into play: it would be nice if you could share
> what are — according to you — the most important projects/improvements
> that Debian ought to make. You can share your ideas here by replying to
> this email, but it would be interesting to file them as new issues in
> the "grow-your-ideas" project and then reply here pointing to your new
> issue:
I have raised https://salsa.debian.org/debian/grow-your-ideas/-/issues/15
# 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.org
The 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*)
Attachment:
signature.asc
Description: PGP signature