Re: Possibly moving Debian services to a CDN
On Mon, Oct 14, 2013 at 1:36 AM, Tollef Fog Heen <tfheen@err.no> wrote:
> ]] Paul Wise
>
>> About the archive mirrors, some reworded thoughts from the DPL IRC
>> channel when this came up a few days ago:
>>
>> <pabs> [...] I think the current state of affairs is fine;
>
> I don't believe you're one of the person who is doing the legwork in
> maintaining any of the CDNs we're currently running, so how would you
> know that? Because it's not visibly broken (most of the time)? I see
> it breaking on a weekly basis, if not more often.
>
>> [...] Removing the mirror network won't be possible anyway, people are
>> still going to create mirrors, especially ISPs will for their
>> customers; due to quotas and distant mirrors being much slower.
>
> Nobody has suggested removing the mirror network. What's being
> discussed is using a CDN for some .d.o services. If somebody wants to
> continue running their mirror they will of course be free to do so.
>
>> <bgupta>Not all CDNs support IPv6.
>
> We will want to use CDNs that do support IPv6. It's one of the
> technical bits that need to fall into place before we will want to
> switch.
>
>> I would rather expand the mirror network.
>
> Does that mean you're volunteering for the task of doing this and
> maintaining the various existing CDNs?
Yes, the hardest part of this is Debian itself would need to basically
build its own distribution network. Whether this is something I would
personal volunteer to help with, if we decide not to go the route of
using CDNs, the answer is yes. However, I don't think in this case,
whether or not I would volunteer for this should be a factor in the
decision, and will share my more fleshed out point of view than the
couple of lines I shared on IRC.
In believe the considerations here fall into a number of areas:
1) Technical. e.g. - CNAMEs, IPv6 support, security concerns related
to caching, and support for protocols other than HTTP under the same
DNS name as the HTTP services (rsync, SMTP, etc.). I believe these are
the biggest challenges that Debian would find moving to using CDNs,
but trust that if the DSA is seriously considering this, they know
what these issues are and would address them before making any
changes.
2) DFSG concerns - These blackbox services may or may not be built
using Free Software. We really have no way of knowing for sure, since
we would be abdicating the actual responsibility of running software.
That said, if our end users and Debian itself are not required to use
proprietary protocols or tools, I think this issue isn't as major of a
concern that it might seem, and believe that a CDN would be classified
as a "network service", as defined by the FSF. RMS has an interesting
blog post on this topic [1], that I largely agree with. Although there
are other issues raised, I don't believe they would impact our
decision whether or not to use a CDN, but I encourage everyone to read
this before making any decisions. My take on this, is that using a CDN
does not violate the DFSG, but defer to more experienced hands on this
particular issue.
3) Privacy - There have been issues raised about logging by these
third party CDNs. My sense is that if the CDNs do not replace our
mirror network, and people are free to continue to use existing
mirrors, my take is this change may not introduce new privacy
concerns.
4) Commercial nature of CDN services - As Tollef correctly points out,
Debian does rely on monetary and in-kind donations from a number of
for-profit enterprises. A CDN does not change this, so I think this
particular point should not be a major factor in our decision.
5) Relationships - We do have relationships with the members of our
mirror network. An open question remains, "Would migrating to CDN
services damage these relationships?" I suspect that if we allow the
mirror network to remain in place, and we communicate a solid case for
this change to our mirror network partners, prior to making it, the
majority would likely support the change.
6) Single point of failure - While technically any properly designed
CDN should be a distributed system resilient to single failures, the
fact remains, that a CDN as a whole, if it were to be compromised or
have a systematic failure (technical or other), could be catastrophic
for Debian, and our users. That said, I believe Toleff's proposal to
work with multiple CDNs, is likely a good way to address this concern,
which could further be mitigated by keeping our mirror network in
place. One thing to bear in mind, is that if any single CDN makes
accommodations/changes for our unique technical needs, this means that
it is less likely that these CDNs would be easily interchangeable. One
way to work around this, is to make sure from the start we are working
with at least two networks.
7) User experience - Does the use of CDNs improve the end user
experience? From my understanding and experience working with CDNs,
the answer is almost certainly yes, but defer to the DSA to confirm
this is in fact the case. Obviously, if the answer is no, then this
raises the question, why are we considering this?
8) Project Overhead - Does this change save the Project significant
work and overhead, that could more effectively be used elsewhere? If
sounds like yes, but perhaps, in an effort to educate and make the
case for making use of CDNs stronger, we could consider elaborating on
both the issues of sticking with the current status quo, and the
benefits to the Project and our users for making the change.
I will say in summary, that IF the technical issues with using CDNs
can be resolved, and we get the general support of our mirror network
to make this change, I would support the DSA's proposal to make use of
CDNs.
-Brian
[1] - http://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html
>
> --
> Tollef Fog Heen
> UNIX is user friendly, it's just picky about who its friends are
>
>
> --
> To UNSUBSCRIBE, email to debian-project-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] m2li1w8ldp.fsf@rahvafeir.err.no">http://lists.debian.org/[🔎] m2li1w8ldp.fsf@rahvafeir.err.no
>
Reply to: