Re: Debian services and Debian infrastructure
On 21/01/14 22:09, Tollef Fog Heen wrote:
> ]] Lucas Nussbaum
>
> This mail has been maturing in my in- and outbox for a little while, and
> it seems like the debate died down until the recent dda mail, so
> restarting the underlying discussion a bit.
>
>> Q1. How much should we push for Debian services (services useful to
>> Debian) to be hosted on Debian infrastructure?
> A lot.
>
>> Q2. Should we seek other hosting opportunities to ease Debian services
>> development and hosting? Should I authorize the use of Debian money to
>> fund infrastructure not managed by DSA, in the case of a useful service
>> that DSA has been unable to accept in the infrastructure it manages?
> I don't think so. We've been pretty open with the requirements and the
> reasoning behind the requirements. If those requirements don't apply
> for some reason, we should fix the requirements and not work around them.
>
> [...]
>
>> The recurring pattern seems to be that, when DSA is approached to move the
>> service to Debian infrastructure, their evaluation of the service's design
>> results in changes requests or constraints that the service maintainers
>> consider too hard to satisfy.
> I don't think this is an accurate statement. There have been a few
> cases where people have shown up with a design we were unable to
> accomodate and progress have stopped, but in general there's been a
> tremendous forward progress in what's hosted on DSA infrastructure. I
> don't think it's ever been easier to get new services hosted on DSA
> infrastructure in the history of the project. Examples over the last
> six months are voip, tracker, manpages, contributors, and that's without
> looking at any of the various static vhosts added.
Looking at the SIP implementation
a) I've run SIP perfectly well "my way" (TM) for many years
b) when I approached DSA, I discovered there was an alternative to "my way"
c) we discussed, we found common ground, the service is live - the DSA
way - which is quite OK, because it is better to have it working in a
way that is suitable for a team to support rather than relying on any
single individual or vendor
As I've mentioned before on this DSA services topic, there are many
technical issues that differ from one service to the next, e.g. you
can't keep private data, credentials, private keys on some cloud system
with a SAN underneath. Copying static web content to mirrors in the
cloud is probably quite OK and if some apache log file is lost, who
cares - but a Git repository is another thing and it should be on our
own hardware.
DSA can actually hand some responsibilities out to people to allow them
to run things in the cloud but this depends on putting the right
interfaces in place and keeping any original data within the official
infrastructure.
One mechanism we used for RTC is RADIUS (FreeRADIUS server) doing a
delegated digest authentication for SIP. With this model, it would be
possible to run SIP or TURN servers in the cloud and they would not need
a copy of the user database or password hashes. The RADIUS server could
potentially be the point where DSA responsibility ends and people can
then run other types of service that trust authorized users. If we have
to relay a lot of video traffic through TURN, then it would make sense
to have local TURN servers in different regions. They keep no local
data and can potentially do all access control using RADIUS.
Rather than having some awkward discussion about it as a social problem,
maybe we can try and look for ways to define such interfaces and give
DDs a chance to propose things around them.
Reply to: