On Mon, Oct 14, 2013 at 1:36 AM, Tollef Fog Heen <tfh...@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-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/m2li1w8ldp....@rahvafeir.err.no > -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACFaiRwrnx6Vnz3Tm=cx9mybco+rzxmhhcp3sqqbedw39h6...@mail.gmail.com