成立镜像站联盟的可能性

[cosli china]

今日中午12点左右，清华镜像站http://mirrors.tuna.tsinghua.edu.cn/首页撤下了评论，不知道问题是否已经解决~

我几乎全程网上关注了清华镜像站经历的这场风波，昨晚开始很多网站都有转载相关信息，突然觉得各个开源镜像站孤军奋斗不是长久之计，上学期我们地大的镜像站http://mirrors6.cugb.edu.cn/也因为上面的文件被关了很久很久（当然是因为北京开大会的原因，不是学校老师的原因），这学期才算是小范围低调重开。

所以，我觉得各个镜像站之间需要一个能顺畅快速地地进行相互沟通，团结起来，共同进步的桥梁，所以我认为需要有这样一个组织或者平台，不知道各位觉得如何，是否有什么好的建议可以提出来讨论一下

[heroxbd]

Hi,

cosli china <china...@gmail.com> writes:

> 今日中午12点左右，清华镜像站http://mirrors.tuna.tsinghua.edu.cn/首页撤
> 下了评论，不知道问题是否已经解决~

感谢您的关注和支持，我们的公开信中引用了地质大学的工作，借此机会表达感谢！

> 我几乎全程网上关注了清华镜像站经历的这场风波，昨晚开始很多网站都有转载
> 相关信息，突然觉得各个开源镜像站孤军奋斗不是长久之计，上学期我们地大的
> 镜像站http://mirrors6.cugb.edu.cn/也因为上面的文件被关了很久很久（当然
> 是因为北京开大会的原因，不是学校老师的原因），这学期才算是小范围低调重
> 开。

嗯，是的，学生和愿志者维护的服务器会被校方担心有被利用破坏和谐的风险。

> 所以，我觉得各个镜像站之间需要一个能顺畅快速地地进行相互沟通，团结起来，
> 共同进步的桥梁，所以我认为需要有这样一个组织或者平台，不知道各位觉得如
> 何，是否有什么好的建议可以提出来讨论一下

我们在受到阻力时其实也想到了这一点，当时想的都是技术层面的，比如说在有地
大同学直接从我们这里下载时，我们可以重定向到你们的网站（可以通过 DNS　地
理定位实现？类似于 CDN　技术）。另外，同步脚本的我们也可以共享起来，形成
一些标准，减轻维护负担和建站门槛。

BTW, 当时甚至连计划和名称都想好了：泛中国高校开源镜像同盟 :D

本达

[Hexcles Ma]

我认为这是可行及有意义的，几方面首先是可以做的：

一、共享镜像维护经验，共同维护一个健壮、泛用的脚本套件。
二、建立一个教育网内镜像的数据库，收集各个镜像站点的cron时间表、上游源等等，给出一些选择源的建议，方便有需要者选择合适的源。如果可能，还可以动态地维护各个站点的更新状态。
三、可以建立一个CDN机制，鉴于教育网的特点，采用DNS判断的方式做CDN就已经足够好了。在维护一个DNS数据表（甚至是一台DNS服务器）的基础上，可以有两种实现方法：有需要的站点将域名绑到这台DNS，将外校的访问请求分流到就近的站点，减少负担；建立一个公共域名，使用该域名可以自动使用最近的教育网源。
四、推动IPV6。鼓励教育网内使用IPV6进行同步。因为至少在我们这里，IPV6是免费甚至鼓励使用的（每月全校还有一定的IPV6指标，必须达到）。

--
您收到此邮件是因为您订阅了 Google 网上论坛的“THU Opensource Mirror Admin”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 thu-opensource-mirr...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。

--
Hexcles Ma

My Blog: http://robotshell.org/

[Qijiang Fan]

在我们学校，IPv6和IPv4都要收钱 >_<

在 2013年3月12日下午2:17，Hexcles Ma <bob...@gmail.com>写道：

四、推动IPV6。鼓励教育网内使用IPV6进行同步。因为至少在我们这里，IPV6是免费甚至鼓励使用的（每月全校还有一定的IPV6指标，必须达到）。

--
Qijiang Fan

fqj...@gmail.com

Contact Address:

Room 811, Liangsheng Building

Huazhong University of Science and Technology

1037 Luoyu Road, Wuhan, HUBEI

THE PEOPLE'S REPUBLIC OF CHINA

[Jiaqi Zhang]

刚和cosli china讨论了下

关于这个CDN，说点儿想法。每个参与的学校，可以给每个镜像或者镜像站设定一个表示“可用性”的变量（综合服务器繁忙程度，出口链路的占用率的值）之后和公网链路质量进行加权（也许可以近似用ping值，用来表示地理位置（如果存在内网，这个ping值一般都比外网小），以及连接质量（可以优先ipv6，如果ipv6不可达，ping也可以起到判断选择作用来选择ipv4链路）等。），得到一个相对更科学（或者说更快）的源的选择。

在 2013年3月12日下午2:17，Hexcles Ma <bob...@gmail.com>写道：

[cosli china]

联盟可能要做的事情：

1.建立公网统一域名（最好提供ipv6），域名提供CDN机制，该机制能够自动判别镜像站与用户双向的ipv4/6通断状况、服务器带宽负载，自动地将用户请求转发至最优镜像站

2.建立联盟内顺畅快速交流机制

3.建立一套完善的开源镜像站搭建技术手册供大家完善以及新站参考

4.商定各个镜像站所用上游源与同步时间，例如A、B两站做国内debian官方源，其它镜像站可以以A、B两站作为debian上游源，C、D做ubuntu国内官方源，其他镜像站可以以C、D两站作为ubuntu上游源，以此确保不会过度浪费国际带宽与加重国外主站的负载

可能面临的问题：

1.部分镜像站设计风格不统一

2.部分镜像站提供帮助页面不够完善

3.各个镜像站所提供的发行版可能不同

4.部分镜像站对校外只能提供ipv6服务

最重要的：

明正言顺，后台强大

[sd542...@gmail.com]

我们这里也可以考虑参加联盟，虽然对外网带宽真心很小，希望能够参加讨论。

在 2013年3月12日星期二UTC+8下午12时21分00秒，cosli china写道：

[cosli china]

当然可以一起讨论，有什么好的建议尽管说就好，我们真的需要团结。

在 2013年3月12日星期二UTC+8下午7时21分49秒，sd542...@gmail.com写道：

[Zhang Cheng]

Hi,

(Note, this mail is also cc'd mir...@ustc.edu.cn and ustc...@googlegroups.com)

我现在所在的公司（云成互动），两位创始人分别是清华娆班和科大的，他们得知此事后也非常想帮忙，希望能够使得清华的这个镜像站点能够继续下去，我们公司有一些带宽和CDN的冗余量，可以想办法用到这上面来。我在公司担任SA，线上的服务器大量的使用了mirrors.tuna和mirrors.ustc镜像。我本人也是mirrors.ustc的维护者之一，对镜像站点的需求有一些了解。

po主提议的镜像联盟，我觉得是个很不错、且具有可行性的想法。首先说一下CDN，开源镜像站点很难直接使用国内各商业CDN，主要原因有：(1)任何一个镜像的体积都很大，活跃数据小；(2)许多镜像严重依赖于数据一致性，该一致性一般通过同步脚本来保证，以同步为周期，而CDN主要靠expires time，这是很难设置的。然后说一下国内各镜像的现状。国内一些站点具有很大的硬盘，如tuna、ustc，还有一些站点硬盘比较小，存储的资源很少，在这样的情况下，大家都会选择同步一些最热门的资源，而冷门资源则很少有人提供。

关于镜像联盟，我粗略想了一个实现方式，以ubuntu镜像为例：

* 假定主域名为 edumirrors.net (该域名不存在)，大家访问 http://edumirrors.net/ubuntu/时，会被跳转到 http://ubuntu.edumirrors.net/ubuntu/。

* 所有提供ubuntu镜像的站点，都将成为ubuntu.edumirrors.net解析的candidate。

* 所有站点定期的上报自己的同步状态，由一个中心的服务器采集、分析这些状态，得到一份可用的列表，成为ubuntu.edumirrors.net的最终轮询节点。

这样，任何一个站点，提供一个新的镜像时，只需要注册为 <project>.edumirrors.net的candidate即可，同时使用统一的同步状态分析机制即可。在上述步骤中，还可以增加判断每个镜像站点的负载（网络带宽、系统负载），来更好的做流量调度。流量调度可以完全靠DNS控制。这个系统需要一个中心的控制程序，该程序负责采集各镜像状态并实时更新DNS。

用上述方案的话，我们公司如果可以贡献一些带宽的话，只需要同步一个镜像并注册即可。还有许多学校的LUG组织，可能本来也想提供镜像站点服务，但苦于自己的资源太少，在这个方案里，则可以提供一些小的项目镜像，大家都能出一份力。

2013/3/12 cosli china <china...@gmail.com>

今日中午12点左右，清华镜像站http://mirrors.tuna.tsinghua.edu.cn/首页撤下了评论，不知道问题是否已经解决~

我几乎全程网上关注了清华镜像站经历的这场风波，昨晚开始很多网站都有转载相关信息，突然觉得各个开源镜像站孤军奋斗不是长久之计，上学期我们地大的镜像站http://mirrors6.cugb.edu.cn/也因为上面的文件被关了很久很久（当然是因为北京开大会的原因，不是学校老师的原因），这学期才算是小范围低调重开。

所以，我觉得各个镜像站之间需要一个能顺畅快速地地进行相互沟通，团结起来，共同进步的桥梁，所以我认为需要有这样一个组织或者平台，不知道各位觉得如何，是否有什么好的建议可以提出来讨论一下

--

您收到此邮件是因为您订阅了 Google 网上论坛的“THU Opensource Mirror Admin”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 thu-opensource-mirr...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
 
 

--

Cheng,

Best Regards

[Bojie Li]

＋1
USTC mirrors的磁盘空间暂时不是问题，但某些地区的下载速度不如人意。如能联合各高校源就近提供服务，不仅可以解决新镜像站可贡献资源不多的问题，还能加强各高校开源社区间的联系，善莫大焉。建议Zhang
Cheng建立一个邮件列表，先聊聊呗。

> --
> -- 来自USTC LUG
> 请使用gmail订阅，不要灌水。
> 更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "USTC_LUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ustc_lug+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

[ideal]

Hi，

这个还是很有意义的。

首先如之前几封邮件提到的，如能有一套基本的代码和脚本，可以通过配置来实现管理，新增镜像，并在上游失效时自动切换（当然这里可能需要检查本地是否比切换之后的上游更新）。可以降低其他学校新增镜像的门槛。

另外如能分流，从全局上进行平衡，也许能够减少某些站点的流量过大，这样学校的信息中心不至于过于反对，毕竟用的是学校的服务器，也占用了学校的大量出口带宽，却没有任何经济利益。（这不是势利，若是信息中心的领导，这么想也是正常的。）

P.S. 看到这个联盟首先想到的是五岳剑派，囧。。

ideal

[cosli china]

现在参与讨论有镜像站有清华、中科大、北交、地大四所学校，云成互动公司成员，一个数据中心的管理员（https://groups.google.com/forum/#!topic/thu-opensource-mirror-admin/Fbu4pVqkkhU），中国互联网络信息中心（https://groups.google.com/forum/#!topic/thu-opensource-mirror-admin/NnQS4J-q_7c），所以，既然大家都认为做这件事有意义，有必要，何不趁此机会约个时间，找个平台聚在一起具体的讨论一下呢。一直在邮件列表讨论似乎有点低效了

[Guo, Jiahua]

这周末在irc或gtalk上开会？

2013/3/14 cosli china <china...@gmail.com>

现在参与讨论有镜像站有清华、中科大、北交、地大四所学校，云成互动公司成员，一个数据中心的管理员（https://groups.google.com/forum/#!topic/thu-opensource-mirror-admin/Fbu4pVqkkhU），中国互联网络信息中心（https://groups.google.com/forum/#!topic/thu-opensource-mirror-admin/NnQS4J-q_7c），所以，既然大家都认为做这件事有意义，有必要，何不趁此机会约个时间，找个平台聚在一起具体的讨论一下呢。一直在邮件列表讨论似乎有点低效了

[cosli china]

嗯，现在是到底能不能把大家都聚在一起，至少每个镜像站得有人参与才行~我是地大的，表示可以参加，虽然我更习惯QQ······

在 2013年3月14日星期四UTC+8下午9时13分01秒，Guo, Jiahua写道：

这周末在irc或gtalk上开会？

2013/3/14 cosli china <china...@gmail.com>

现在参与讨论有镜像站有清华、中科大、北交、地大四所学校，云成互动公司成员，一个数据中心的管理员（https://groups.google.com/forum/#!topic/thu-opensource-mirror-admin/Fbu4pVqkkhU），中国互联网络信息中心（https://groups.google.com/forum/#!topic/thu-opensource-mirror-admin/NnQS4J-q_7c），所以，既然大家都认为做这件事有意义，有必要，何不趁此机会约个时间，找个平台聚在一起具体的讨论一下呢。一直在邮件列表讨论似乎有点低效了

--
您收到此邮件是因为您订阅了 Google 网上论坛的“THU Opensource Mirror Admin”论坛。

要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 thu-opensource-mirror-admin+unsub...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
 
 

[Cheer Xiao]

在 2013-3-14 下午9:13，"Guo, Jiahua" <gjh...@gmail.com>写道：
>
> 这周末在irc或gtalk上开会？
>

IRC TUNA 就有~ freenode #tuna

不过我觉得不着急开会，应该先解决一下基本技术问题。

我熟悉 CDN 的概念，但对它实现所用到的技术一无所知。作为一个菜鸟，我有以下疑问：

1) 地域解析的准确性是如何保证的？对节点的选择是基于静态数据还是动态的？
2) 数据一致性是如何保证的？

我觉得应该先了解一下目前商业 CDN 解决这些问题的基本思路，再根据镜像站的情况做模仿和调整。

[cosli china]

首先我觉得，数据一致性的程度应该不需要达到商业那样的标准。其次，我对CDN也不熟悉，USTC有管理员在云成互动公司，USTC的技术帝也许可以给我们一些指导

[Zhang Cheng]

​商业CDN，一般的结构是这样的，CDN本身分两层，一层是边缘节点，即用户访问的节点，另外一层是自己的cache，这一层会到客户的源站回源（注意客户和用户的区别）。第二层的目的是，减少到客户的回源量，一般一个文件回源一到两次即可（边缘节点可能有30+个）。

我们这个连盟，如果看作是CDN的话，跟商业CDN的区别是，只有边缘节点，不存在​中间缓存层，我们没有“客户”，在我们的情形下，“客户”就是上游，各边缘节点分别通过rsync(或其他方式)从上游同步。

开源镜像站点很难跟商业CDN合作，主要的困难有两个：

1、缓存时间的问题。http缓存（不仅仅是商业CDN）一般都是通过源站的response header中的cache-control（以及其他cache相关的头）来控制缓存时间，没有cache-control头的，则默认缓存一段时间（一般10分钟到1天不等）。开源镜像站点的文件缓存时间无法合理的设置cache-control。

2、文件大小不一。商业CDN一般分大文件和小文件分发平台。这里简单讲一下为什么要分平台。假设源站是A，CDN简化成一个节点B，用户是C。对于小文件，有许多C同时向B请求同一个文件时，B上如果cache miss，则会block所有的请求，用http到A回源，等回源结束后，再一下子给所有的C返回内容。这里可以看出，如果都是小文件，问题不大，但如果文件很大，则block的时间会很长，甚至导致C timeout。另一方面，对于大文件，一般还会有bytes range请求，例如一个文件有100M，C1来请求0~10M的部分，C2请求5~15M的部分，那么B回源时，该请求整个文件？还是分别对两个block各缓存一份呢？显然都不合适。所以，一般商业CDN会独立出大文件频道，大文件频道不采用回源的方式，而是客户将文件推送到B出，B能直接对C提供服务。当然，有些cache软件支持streaming模式，即C向B请求时，B不block，而是一边从A回源一边服务C，但这仍然不能解决bytes range的问题。

​开源镜像里的文件大小不一，大的上百兆甚至上G，小的只有几K。

上述内容与@Cheer Xiao的问题无关。

下面针对Cheer Xiao的问题说一下。

1）低于解析的准确性如何保证？对节点的选择是基于静态数据还是动态的？

​这里，DNS可以用第三方的（国内的DNSPod做的很不错），也可以自建。DNSPod的免费版本中，可以按电信、联通分别解析，从我们使用的情况看效果还是非常不错的。自建的话，可以有更灵活的解析，例如我们可以统计所有联盟成员学校的DNS服务器地址，然后尽可能让成员学校使用自己学校的镜像。然后对外服务，可以简单的按省份、ISP进行区别解析。

解析时尽量不要用A记录轮询，对同一个区域/ISP的用户，短时间内连续若干次解析都保证解析到同一个节点，那么就不需要考虑各节点数据一致性的问题了。不过我们需要收集一些国内各地区/ISP的DNS服务器IP段（这个很容易，随便找一个学校的DNS服务器上采样一些日志分析一下即可），然后通过调节地区的分配来尽可能均衡的各节点的流量。

上面说的可能不太清楚，举个例子来说吧。一般常见的DNS轮询是这么做的，例如解析example.com：

example.com 默认 A 1.1.1.1

example.com 默认 A 2.2.2.2

example.com有两个A记录，那么用户解析这个域名时，就会得到两个IP，一般客户端会随机选一个IP用，这种情况下，两个节点的流量是平均的。

而我们可以这么做：

example.com 学校x A <ip-of-x>

example.com 学校y A <ip-of-y>

example.com 安徽电信 A <ip-of-ustc>

example.com 北京联通 A <ip-of-tuna>

example.com 默认 A <ip-of-blabla>

这里，“默认”的意思是除了提到过的区域以外的所有其他区域。这种解析，每个区域都只解析出一个IP，那么就不用考虑各节点的数据一致性问题了，因为一个用户总是会被解析到同一个节点上。但是，这种解析的缺点是，各节点流量分配会不均衡，需要手动的调节、摸索，在各区域之间去优化。

当然，我们可以结合上述两种方法。一方面，选定一个数据一致性检查的方式，例如检查镜像的时间戳，将同步的最新的几个镜像都放到“默认”线路的A记录轮询。这里，检查一致性本身可能是一个比较困难的事，不是所有的镜像都提供时间戳，一个比较简单的方法是，对同一个镜像，所有联盟都到其中一个成员处同步。 

2013/3/15 Cheer Xiao <xiaq...@gmail.com>

IRC TUNA 就有~ freenode #tuna

不过我觉得不着急开会，应该先解决一下基本技术问题。

我熟悉 CDN 的概念，但对它实现所用到的技术一无所知。作为一个菜鸟，我有以下疑问：

1) 地域解析的准确性是如何保证的？对节点的选择是基于静态数据还是动态的？
2) 数据一致性是如何保证的？

我觉得应该先了解一下目前商业 CDN 解决这些问题的基本思路，再根据镜像站的情况做模仿和调整。

--

Cheng,

Best Regards

[Zhang Cheng]

2013/3/16 Bojie Li <boj...@gmail.com>

自建DNS服务器要保证高稳定性啊，发生单点故障就要命了。

听说有一种CDN的方法是anycast，在每个边缘节点附近设一个DNS服务器，返回这个边缘节点的IP。各DNS服务器共享IP地址，DNS请求哪个返回得快就解析到哪个IP，自动实现了“就近访问”。这是否可行？

anycast需要运营商的配合，现在很少有anycast。自建DNS没啥问题，许多学校都有自建DNS，比如科大，让学校帮忙托管就行了。

​​

> 这里，“默认”的意思是除了提到过的区域以外的所有其他区域。这种解析，每个区域都只解析出一个IP，那么就不用考虑各节点的数据一致性问题了，因为一个用户总是会被解析到同一个节点上。但是，这种解析的缺点是，各节点流量分配会不均衡，需要手动的调节、摸索，在各区域之间去优化。

流量分配本来就不应该是完全均衡的吧，毕竟各个源的网络条件都不一样，跨运营商也会很慢。建议以地理位置远近、运营商为基础，人肉协商确定一个初始策略，然后定期汇总各源的访问日志，根据下载速度判断出各IP段访问哪个镜像站更快，并据此调整DNS解析策略。这个有点像迭代的方法合适吗？

​要更“精确”的控制流量的话，按地区来手动调整是可行的最好的方案了，不过这个工作量太大了，而且具体到每个镜像，A镜像和B镜像的边缘节点个数和分布是不一样的，用户分布也是不一样的，那么​分配的方案也不一样。这个磨合的过程会很长。

 

“比较简单的方法”+1
每个镜像由一个节点充当主节点，它从上游同步，同步完成后通知联盟内的其他节点来自己这里同步。CERNET内部网速应该是很快的（想想六维空间），这样就可以把联盟内部不一致的时间缩短到最小。如果主节点同步失败，也应该通知其他节点，让他们自己到上游去同步。至于主节点的选取，可以测量从上游同步的速度，结合其他因素人肉协商。上述方案需要一套通用脚本，作为各高校开源社区共同参与的开源项目也挺好的。

​CERNET的情况没有想象的好。白天时，南北通信非常拥堵，瓶颈主要在山东、天津一段。夜里CERNET的整体情况都还不错。

 

才疏学浅，欢迎拍砖~

--

Cheng,

Best Regards

[Bojie Li]

2013/3/15 Zhang Cheng <steph...@gmail.com>:

> 1）低于解析的准确性如何保证？对节点的选择是基于静态数据还是动态的？
> 这里，DNS可以用第三方的（国内的DNSPod做的很不错），也可以自建。DNSPod的免费版本中，可以按电信、联通分别解析，从我们使用的情况看效果还是非常不错的。自建的话，可以有更灵活的解析，例如我们可以统计所有联盟成员学校的DNS服务器地址，然后尽可能让成员学校使用自己学校的镜像。然后对外服务，可以简单的按省份、ISP进行区别解析。

自建DNS服务器要保证高稳定性啊，发生单点故障就要命了。

听说有一种CDN的方法是anycast，在每个边缘节点附近设一个DNS服务器，返回这个边缘节点的IP。各DNS服务器共享IP地址，DNS请求哪个返回得快就解析到哪个IP，自动实现了“就近访问”。这是否可行？

> 这里，“默认”的意思是除了提到过的区域以外的所有其他区域。这种解析，每个区域都只解析出一个IP，那么就不用考虑各节点的数据一致性问题了，因为一个用户总是会被解析到同一个节点上。但是，这种解析的缺点是，各节点流量分配会不均衡，需要手动的调节、摸索，在各区域之间去优化。

流量分配本来就不应该是完全均衡的吧，毕竟各个源的网络条件都不一样，跨运营商也会很慢。建议以地理位置远近、运营商为基础，人肉协商确定一个初始策略，然后定期汇总各源的访问日志，根据下载速度判断出各IP段访问哪个镜像站更快，并据此调整DNS解析策略。这个有点像迭代的方法合适吗？

> 当然，我们可以结合上述两种方法。一方面，选定一个数据一致性检查的方式，例如检查镜像的时间戳，将同步的最新的几个镜像都放到“默认”线路的A记录轮询。这里，检查一致性本身可能是一个比较困难的事，不是所有的镜像都提供时间戳，一个比较简单的方法是，对同一个镜像，所有联盟都到其中一个成员处同步。

“比较简单的方法”+1
每个镜像由一个节点充当主节点，它从上游同步，同步完成后通知联盟内的其他节点来自己这里同步。CERNET内部网速应该是很快的（想想六维空间），这样就可以把联盟内部不一致的时间缩短到最小。如果主节点同步失败，也应该通知其他节点，让他们自己到上游去同步。至于主节点的选取，可以测量从上游同步的速度，结合其他因素人肉协商。上述方案需要一套通用脚本，作为各高校开源社区共同参与的开源项目也挺好的。

才疏学浅，欢迎拍砖~

> 2013/3/15 Cheer Xiao <xiaq...@gmail.com>
>>
>> IRC TUNA 就有~ freenode #tuna
>>
>> 不过我觉得不着急开会，应该先解决一下基本技术问题。
>>
>> 我熟悉 CDN 的概念，但对它实现所用到的技术一无所知。作为一个菜鸟，我有以下疑问：
>>
>> 1) 地域解析的准确性是如何保证的？对节点的选择是基于静态数据还是动态的？
>> 2) 数据一致性是如何保证的？
>>
>> 我觉得应该先了解一下目前商业 CDN 解决这些问题的基本思路，再根据镜像站的情况做模仿和调整。
>
>
>
>
>
> --
> Cheng,
> Best Regards
>

[Aron Xu]

2013/3/16 Bojie Li <boj...@gmail.com>:

> 2013/3/15 Zhang Cheng <steph...@gmail.com>:
>> 1）低于解析的准确性如何保证？对节点的选择是基于静态数据还是动态的？
>> 这里，DNS可以用第三方的（国内的DNSPod做的很不错），也可以自建。DNSPod的免费版本中，可以按电信、联通分别解析，从我们使用的情况看效果还是非常不错的。自建的话，可以有更灵活的解析，例如我们可以统计所有联盟成员学校的DNS服务器地址，然后尽可能让成员学校使用自己学校的镜像。然后对外服务，可以简单的按省份、ISP进行区别解析。
>
> 自建DNS服务器要保证高稳定性啊，发生单点故障就要命了。
>

DNS 可以做得很稳定的，而且因为流量不大所以靠谱的托管也比较好找。

> 听说有一种CDN的方法是anycast，在每个边缘节点附近设一个DNS服务器，返回这个边缘节点的IP。各DNS服务器共享IP地址，DNS请求哪个返回得快就解析到哪个IP，自动实现了“就近访问”。这是否可行？
>

以我们现在的情况很难，这个要运营商配合。

>> 这里，“默认”的意思是除了提到过的区域以外的所有其他区域。这种解析，每个区域都只解析出一个IP，那么就不用考虑各节点的数据一致性问题了，因为一个用户总是会被解析到同一个节点上。但是，这种解析的缺点是，各节点流量分配会不均衡，需要手动的调节、摸索，在各区域之间去优化。
>
> 流量分配本来就不应该是完全均衡的吧，毕竟各个源的网络条件都不一样，跨运营商也会很慢。建议以地理位置远近、运营商为基础，人肉协商确定一个初始策略，然后定期汇总各源的访问日志，根据下载速度判断出各IP段访问哪个镜像站更快，并据此调整DNS解析策略。这个有点像迭代的方法合适吗？
>

可以用 HTTP redirect 的办法，可以参考 http://http.debian.net，用 DNS
来按地区调整的方法效果并不好，而且实现起来成本比较高，这种例子参考 http://cdn.debian.net

>> 当然，我们可以结合上述两种方法。一方面，选定一个数据一致性检查的方式，例如检查镜像的时间戳，将同步的最新的几个镜像都放到“默认”线路的A记录轮询。这里，检查一致性本身可能是一个比较困难的事，不是所有的镜像都提供时间戳，一个比较简单的方法是，对同一个镜像，所有联盟都到其中一个成员处同步。
>

其实只要保持一段时间内用户得到的结果基本稳定就行，比如说科大附近的人总被指向科大，只有在科大镜像状态很不合适的情况下才被指向其他地方，这样一致性的问题就不需要解决了。想把所有
mirror 的一致性解决掉几乎不可能。

> “比较简单的方法”+1
> 每个镜像由一个节点充目前应该许多镜像通过 IPv6 连接国外的服务器能比连接国内的快当主节点，它从上游同步，同步完成后通知联盟内的其他节点来自己这里同步。CERNET内部网速应该是很快的（想想六维空间），这样就可以把联盟内部不一致的时间缩短到最小。如果主节点同步失败，也应该通知其他节点，让他们自己到上游去同步。至于主节点的选取，可以测量从上游同步的速度，结合其他因素人肉协商。上述方案需要一套通用脚本，作为各高校开源社区共同参与的开源项目也挺好的。
>

教育网内部白天南北通信还是有点问题的，但比电信/联通好很多。。。


--
Regards,
Aron Xu

[Cheer Xiao]

在 2013年3月17日上午11:54，Aron Xu <happya...@gmail.com> 写道：
> 2013/3/16 Bojie Li <boj...@gmail.com>:
>> 2013/3/15 Zhang Cheng <steph...@gmail.com>:
>>> 1）低于解析的准确性如何保证？对节点的选择是基于静态数据还是动态的？
>>> 这里，DNS可以用第三方的（国内的DNSPod做的很不错），也可以自建。DNSPod的免费版本中，可以按电信、联通分别解析，从我们使用的情况看效果还是非常不错的。自建的话，可以有更灵活的解析，例如我们可以统计所有联盟成员学校的DNS服务器地址，然后尽可能让成员学校使用自己学校的镜像。然后对外服务，可以简单的按省份、ISP进行区别解析。
>>
>> 自建DNS服务器要保证高稳定性啊，发生单点故障就要命了。
>>
>
> DNS 可以做得很稳定的，而且因为流量不大所以靠谱的托管也比较好找。
>
>> 听说有一种CDN的方法是anycast，在每个边缘节点附近设一个DNS服务器，返回这个边缘节点的IP。各DNS服务器共享IP地址，DNS请求哪个返回得快就解析到哪个IP，自动实现了“就近访问”。这是否可行？
>>
>
> 以我们现在的情况很难，这个要运营商配合。
>
>>> 这里，“默认”的意思是除了提到过的区域以外的所有其他区域。这种解析，每个区域都只解析出一个IP，那么就不用考虑各节点的数据一致性问题了，因为一个用户总是会被解析到同一个节点上。但是，这种解析的缺点是，各节点流量分配会不均衡，需要手动的调节、摸索，在各区域之间去优化。
>>
>> 流量分配本来就不应该是完全均衡的吧，毕竟各个源的网络条件都不一样，跨运营商也会很慢。建议以地理位置远近、运营商为基础，人肉协商确定一个初始策略，然后定期汇总各源的访问日志，根据下载速度判断出各IP段访问哪个镜像站更快，并据此调整DNS解析策略。这个有点像迭代的方法合适吗？
>>
>
> 可以用 HTTP redirect 的办法，可以参考 http://http.debian.net，用 DNS
> 来按地区调整的方法效果并不好，而且实现起来成本比较高，这种例子参考 http://cdn.debian.net
>

从这里来看的话 APT 是支持 HTTP redirect 的……我刚才试验了一下，pacman 也是支持 HTTP redirect
的，但是界面上有一点小问题。(每一个下载进度会跑两次，第一次是 HTTP redirect。。有兴趣的同学可以试试把源改成
mirrors.tuna.tsinghua.edu.cn/archlinuux)

不过还是不知道其他包管理器支持如何哎。。。

>>> 当然，我们可以结合上述两种方法。一方面，选定一个数据一致性检查的方式，例如检查镜像的时间戳，将同步的最新的几个镜像都放到“默认”线路的A记录轮询。这里，检查一致性本身可能是一个比较困难的事，不是所有的镜像都提供时间戳，一个比较简单的方法是，对同一个镜像，所有联盟都到其中一个成员处同步。
>>
>
> 其实只要保持一段时间内用户得到的结果基本稳定就行，比如说科大附近的人总被指向科大，只有在科大镜像状态很不合适的情况下才被指向其他地方，这样一致性的问题就不需要解决了。想把所有
> mirror 的一致性解决掉几乎不可能。
>

+1

>> “比较简单的方法”+1
>> 每个镜像由一个节点充目前应该许多镜像通过 IPv6 连接国外的服务器能比连接国内的快当主节点，它从上游同步，同步完成后通知联盟内的其他节点来自己这里同步。CERNET内部网速应该是很快的（想想六维空间），这样就可以把联盟内部不一致的时间缩短到最小。如果主节点同步失败，也应该通知其他节点，让他们自己到上游去同步。至于主节点的选取，可以测量从上游同步的速度，结合其他因素人肉协商。上述方案需要一套通用脚本，作为各高校开源社区共同参与的开源项目也挺好的。
>>
>

恩，我担心的同步问题主要是就是这个，就是及时发现同步失败的情况。。。

以及我觉得咱们可以在 IRC 上讨论一下了，最好@张成同学能来讲讲可用的具体技术方案~

时间我提议在这周六晚上 8:00，在 freenode #tuna 频道~

> 教育网内部白天南北通信还是有点问题的，但比电信/联通好很多。。。
>
>


--
Regards,
Cheer Xiao

[Hao Gu]

Great, 其实我前两天也有类似的想法。本来准备回科大后和boj商量的。
正好我那时候也有时间做一些事情。所以非常支持，希望能有一个讨论的结果。

2013/3/13 Zhang Cheng <steph...@gmail.com>:

> --
> -- 来自USTC LUG
> 请使用gmail订阅，不要灌水。
> 更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "USTC_LUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ustc_lug+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Linux User Group
University of Science and Technology of China
Homepage: http://lug.ustc.edu.cn/
E-Mail: l...@ustc.edu.cn
Mirror Admin: mir...@ustc.edu.cn
Hal Gu <snu...@gmail.com>

[Zhang Cheng]

2013/3/18 Cheer Xiao <xiaq...@gmail.com>

恩，我担心的同步问题主要是就是这个，就是及时发现同步失败的情况。。。

以及我觉得咱们可以在 IRC 上讨论一下了，最好@张成同学能来讲讲可用的具体技术方案~

时间我提议在这周六晚上 8:00，在 freenode #tuna 频道~

​这个时间我应该没事，不过要看实际情况，这几周在合肥考驾照，下周二考试，教练说这个周末可能要整天整天的练。​

--

Cheng,

Best Regards

[Bojie Li]

这周六晚上我们有每周小聚活动，改到周日怎么样？

@Zhang Cheng 晚上也要练车吗？

[Zhang Cheng]

2013/3/19 Bojie Li <boj...@gmail.com>

这周六晚上我们有每周小聚活动，改到周日怎么样？

@Zhang Cheng 晚上也要练车吗？

​练车的时间不确定，由教练决定，而且一般要到提前一天才知道。​

--

Cheng,

Best Regards

[Bojie Li]

那就在周日20:00吧，估计一次讨论也定不下来，有时间的就都来IRC聊聊吧。 @Cheer Xiao 行吗？

[Ray]

>>> 这周六晚上我们有每周小聚活动，改到周日怎么样？
>>>
>>> @Zhang Cheng 晚上也要练车吗？
>>
>> 练车的时间不确定，由教练决定，而且一般要到提前一天才知道。
>

> 那就在周日20:00吧，估计一次讨论也定不下来，有时间的就都来IRC聊聊吧。 @Cheer Xiao 行吗？

每人事先把要說的話列出來，到時候一次性貼到 pastebin(wgetpaste) 上？
我在考慮討論如何做到高效

[cosli china]

我（mirrors6.cugb.edu.cn）应该可以参加，至少对我来说，拖得太久就会有好了伤疤忘了疼的感觉，虽然这学期重开了站点，但现在我们的镜像站还不能正大光明的宣传（去年大会之前我们镜像站的宣传链接还上了学校一个访问量很大的页面），因为这学期大领导还没有正式同意重开，说的好听点我们的镜像站是在夹缝中求生存，说的难听点就是在苟且偷生，说起来都是眼泪。

总而言之，真的希望能加快联盟成立的进程

在 2013年3月19日星期二UTC+8下午3时59分32秒，Bojie Li写道：

[Bojie Li]

我觉得事先要说的内容贴到邮件列表就行啊，Gmail的thread挺方便的。

[cosli china]

到底需要讨论些什么，这是我的思考，不太完善，仅供参照http://mirrors6.cugb.edu.cn/stream/post/union.html

[Bojie Li]

这是我的思考，欢迎拍砖
http://boj.blog.ustc.edu.cn/index.php/2013/03/mirrors-union-nontech/
http://boj.blog.ustc.edu.cn/index.php/2013/03/mirrors-union-tech/

2013/3/19 cosli china <china...@gmail.com>:
> 到底需要讨论些什么，这是我的思考，不太完善，仅供参照http://mirrors6.cugb.edu.cn/stream/post/union.html

[Aron Xu]

2013/3/19 Bojie Li <boj...@gmail.com>:

> 这是我的思考，欢迎拍砖
> http://boj.blog.ustc.edu.cn/index.php/2013/03/mirrors-union-nontech/
> http://boj.blog.ustc.edu.cn/index.php/2013/03/mirrors-union-tech/
>

Debian 的所有名为 ftp.XY.debian.org 的 mirror 均为 push
trigger，即在上游服务器完成更新后立即通知所有已知的下游服务器开始同步，这套工具可以借鉴。科大的 ftp.cn.debian.org
是接受来自 syncproxy.wna.debian.org 的 push，同时其本身是 Push-Primary
镜像，可以直接为下游源提供推送服务。



--
Regards,
Aron Xu

[Zhang Cheng]

2013/3/19 Bojie Li <boj...@gmail.com>

这是我的思考，欢迎拍砖
http://boj.blog.ustc.edu.cn/index.php/2013/03/mirrors-union-nontech/
http://boj.blog.ustc.edu.cn/index.php/2013/03/mirrors-union-tech/

​个人认为，302的方案基本不可取：

* 一旦主节点宕机，则所有服务不可用

* 可能有些系统、软件不支持镜像302跳转

域名解析的方案，本身​其实没有问题，你博客里提到的问题也都可以解决：

* 调度精确性：至少可以精确到学校，这个精确度已经足够

* 修改调度策略的生效时间：自建DNS的话，可以将ttl设的很小（如1s），实际生效时间基本上也是满意的。

* 镜像目录结构一致性：只要保证对同一个用户总是只解析出同一个节点即可。

不过域名的方案倒是有一些问题：

* 备案问题。大多数学校是不能接受未备案域名指向本校IP的。不过这个问题并不严重，个人申请备案也不是那么的难。

至于自建DNS服务器的事，我已经联系jameszhang，在科大的DNS服务器上采集一两天全国各来访DNS服务的IP地址。将来DNS部署在什么位置待定，个人倾向于在多个学校各部署几个点，如科大部署一两个点、清华部署一两个点，我相信这些学校应该会提供资源支持这样的DNS服务器。

--

Cheng,

Best Regards

[Cheer Xiao]

原来上周日晚上在 IRC 上讨论。。。。。。。。。。。。。。。。。。。。。
居然忘了。。。。。。。。。。。。。。。。。。
后知觉。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
看 log ing。。。。。。。。。。。。。。。。。。。。。。。。。。。。。


--
Regards,
Cheer Xiao

[Benda Xu]

大家好,

我正在着手设计一套能在清华内的几个服务器 (ftp3, ftp4, solar, lunar) 上使用的"联盟"镜像原型.

因为最近我们的 NFS 实在扛不住现在的流量了.

谁保存了周日的 IRC 讨论的日志? (ping xiaq) 请发给我一下.

写出草案后会发来列表接受审阅.

本达

2013/3/26 Cheer Xiao <xiaq...@gmail.com>

原来上周日晚上在 IRC 上讨论。。。。。。。。。。。。。。。。。。。。。
居然忘了。。。。。。。。。。。。。。。。。。
后知觉。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
看 log ing。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

--
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

[Benda Xu]

Hi,

2013/3/19 Bojie Li <boj...@gmail.com>

http://boj.blog.ustc.edu.cn/index.php/2013/03/mirrors-union-tech/

请问第一点

       每个镜像分配一个二级域名，以便分别调度；NS记录设置为主站

具体指什么, 可以举一个例子说明吗?

[Bojie Li]

2013/3/28 Benda Xu <her...@gmail.com>:

> 谁保存了周日的 IRC 讨论的日志? (ping xiaq) 请发给我一下.
>

http://lug.ustc.edu.cn/~guo/irc/irclog-tuna.html

[Bojie Li]

2013/3/28 Benda Xu <her...@gmail.com>:

> 2013/3/19 Bojie Li <boj...@gmail.com>
>> http://boj.blog.ustc.edu.cn/index.php/2013/03/mirrors-union-tech/
>
> 请问第一点
>
> 每个镜像分配一个二级域名，以便分别调度；NS记录设置为主站
>
> 具体指什么, 可以举一个例子说明吗?

参见Zhang Cheng的邮件：
http://blog.ustc.edu.cn/pipermail/ustc_lug/2013-March/009974.html

上周末我们讨论的主要包括镜像联盟的名称和域名，DNS调度方式的可行性，还有各节点状态报告的数据格式。
关于DNS调度方式能精确到什么程度，需要分析一个现有DNS的查询日志，Zhang Cheng已经联系科大网络中心，现在还没有回复。

[Qijiang Fan]

另，我们这边校内镜像应该快了（不过禁止校外IP），并且IPv4 Only

RAID现在还在初始化 >_<

网络现在还没拿到对校外服务的许可

--
您收到此邮件是因为您订阅了 Google 网上论坛的“THU Opensource Mirror Admin”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 thu-opensource-mirr...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。

--
Qijiang Fan

fqj...@gmail.com

Contact Address:

Room 811, Liangsheng Building

Huazhong University of Science and Technology

1037 Luoyu Road, Wuhan, HUBEI

THE PEOPLE'S REPUBLIC OF CHINA

[cosli china]

建立了一个QQ群，专门讨论成立联盟的事宜，欢迎各位加入。QQ群号：49221736

ps：在论坛实在是不很方便，有时候墙太厉害，帖子根本打不开，重要的是交流也不够迅速、敏捷，囧了~

ps2：验证请说明一下身份、目的之类~保证群的纯洁性

[Ray]

> 建立了一个QQ群，专门讨论成立联盟的事宜，欢迎各位加入。QQ群号：49221736
>
> ps：在论坛实在是不很方便，有时候墙太厉害，帖子根本打不开，重要的是交流也不够迅速、敏捷，囧了~
> ps2：验证请说明一下身份、目的之类~保证群的纯洁性
>

爲什麼不用 IRC?

console:
weechat
irssi

graphical:
kvirc
konversation
pidgin

web:
webchat.freenode.net

[Qijiang Fan]

同支持irc
qq消息丢了连存档都没有

[cosli china]

主要是需要一种能下线后还能联系到大家的一种工具，上次IRC讨论之后就再没什么进展，因为大家退出频道之后便不能再迅速联系上了。来论坛发帖又觉得不是太便捷（还容易沉）。

ps：既然大家一下子想到了这么多交流的方式，可能也是感到论坛有时候是不够便捷，有更好的选择为什么现在才提出来呢？

在 2013年4月7日星期日UTC+8上午10时38分24秒，Qijiang Fan写道：

同支持irc
qq消息丢了连存档都没有

在 2013-4-7 上午10:37，"Ray" <i...@maskray.me>写道：

> 建立了一个QQ群，专门讨论成立联盟的事宜，欢迎各位加入。QQ群号：49221736
>
> ps：在论坛实在是不很方便，有时候墙太厉害，帖子根本打不开，重要的是交流也不够迅速、敏捷，囧了~
> ps2：验证请说明一下身份、目的之类~保证群的纯洁性
>

爲什麼不用 IRC?

console:
  weechat
  irssi

graphical:
  kvirc
  konversation
  pidgin

web:
  webchat.freenode.net

--
您收到此邮件是因为您订阅了 Google 网上论坛的“THU Opensource Mirror Admin”论坛。

要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 thu-opensource-mirror-admin+unsub...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。

[Qijiang Fan]

发邮件啊

[cosli china]

这就是邮件列表在我视野里的展现~看起来着实着急。

[Qijiang Fan]

用邮箱订阅，用邮箱参与讨论啊。别用网页。

在 2013-4-7 上午11:06，"cosli china" <china...@gmail.com>写道：

这就是邮件列表在我视野里的展现~看起来着实着急。

[cosli china]

这样的话，看邮件列表最新回复是可以，但还是没有那种即时查看、即时回复的感觉。

有类似IRC那样能即时连天，又能说明  我这一会即使不在线，但我一直在这个组织里面 的那种工具吗，可以推荐一下，至少会增加一种小团体的责任感

[Qijiang Fan]

irc可以开一个bot记录聊天记录啊，然后存在服务器上

在 2013-4-7 上午11:18，"cosli china" <china...@gmail.com>写道：

这样的话，看邮件列表最新回复是可以，但还是没有那种即时查看、即时回复的感觉。

有类似IRC那样能即时连天，又能说明  我这一会即使不在线，但我一直在这个组织里面 的那种工具吗，可以推荐一下，至少会增加一种小团体的责任感

--

[Ray]

> 这样的话，看邮件列表最新回复是可以，但还是没有那种即时查看、即时回复的感觉。
> 有类似IRC那样能即时连天，又能说明 我这一会即使不在线，但我一直在这个组织里面 的那种工具吗，可以推荐一下，至少会增加一种小团体的责任感

大致有兩種配置方法：

# thunderbird

沒用過

# mutt + various third-party tools

MRA (mail retrieval agent) 基本上就兩種選擇

## getmail

## offlineimap

儲存格式基本上就一種選擇：Maildir

郵件檢索，一種選擇：notmuch

新郵件提醒：inotify-tools

可以參見鄙人的 http://maskray.me/blog/2012-11-13-personal-mail-system


手機上也可以用 gmail 客戶端。我收發郵件的效率比短信要高

[Ray]

> 这样的话，看邮件列表最新回复是可以，但还是没有那种即时查看、即时回复的感觉。
> 有类似IRC那样能即时连天，又能说明 我这一会即使不在线，但我一直在这个组织里面 的那种工具吗，可以推荐一下，至少会增加一种小团体的责任感

願意折騰得話 tmux 裏放 weechat，隨時 detach/attach

或者用 znc (IRC bouncer)

[Zhang Cheng]

​说到irc logger，我倒是有个想法，最近找时间做一下。

写个irc logger，然后动态的更新maildir中的邮件，然后在gmail中建一个irc/的标签，把本地的irc目录跟gmail中的irc/标签同步（可以用offlineimap）。这样就基本可以达到gtalk的效果了。

--

Cheng,

Best Regards

[Shan Yafeng]

2013/4/7 Zhang Cheng <steph...@gmail.com>

说到irc logger，我倒是有个想法，最近找时间做一下。

写个irc logger，然后动态的更新maildir中的邮件，然后在gmail中建一个irc/的标签，把本地的irc目录跟gmail中的irc/标签同步（可以用offlineimap）。这样就基本可以达到gtalk的效果了。

同步脚本我用python写过，使用python imap库实现，https://github.com/cuckoohello/synctool/blob/master/bin/synctool.py

不过里面加了很多针对Pyside Qt图形界面，稍微改下就行了

不过目前使用的是单条信息产生一条邮件记录，需要类型gtalk设定一个规则生成合集，不过这个不难

 

--

Cheng,

Best Regards

[Zhang Cheng]

2013/4/7 Shan Yafeng <cucko...@gmail.com>

同步脚本我用python写过，使用python imap库实现，https://github.com/cuckoohello/synctool/blob/master/bin/synctool.py

不过里面加了很多针对Pyside Qt图形界面，稍微改下就行了

不过目前使用的是单条信息产生一条邮件记录，需要类型gtalk设定一个规则生成合集，不过这个不难

​不必要完全跟gtalk一样的规则。一个比较简单的规则：如果当前消息与上一条消息时间差小于5min，则合并​

--

Cheng,

Best Regards

[Shan Yafeng]

我觉得需要有人拍板拿出结论

其实干起来都不需要耗费多久

时间都浪费在扯皮上

2013/4/7 Zhang Cheng <steph...@gmail.com>

--

[heroxbd]

Zhang Cheng <steph...@gmail.com> writes:

> 说到irc logger，我倒是有个想法，最近找时间做一下。
> 写个irc logger，然后动态的更新maildir中的邮件，然后在gmail中建一个irc/
> 的标签，把本地的irc目录跟gmail中的irc/标签同步（可以用offlineimap）。
> 这样就基本可以达到gtalk的效果了。

我勒个去！这太逆天了！

[cosli china]

同意，没必要一直纠结于能放在以后解决的一些事情上，我们列表里的成员早已有了成立联盟的姿态，却一直也没有实际的行动，就是缺乏一个拍板开干的人

在 2013年4月7日星期日UTC+8下午2时43分48秒，cuckoohello写道：

我觉得需要有人拍板拿出结论

其实干起来都不需要耗费多久

时间都浪费在扯皮上

2013/4/7 Zhang Cheng <steph...@gmail.com>

2013/4/7 Shan Yafeng <cucko...@gmail.com>

同步脚本我用python写过，使用python imap库实现，https://github.com/cuckoohello/synctool/blob/master/bin/synctool.py

不过里面加了很多针对Pyside Qt图形界面，稍微改下就行了

不过目前使用的是单条信息产生一条邮件记录，需要类型gtalk设定一个规则生成合集，不过这个不难

不必要完全跟gtalk一样的规则。一个比较简单的规则：如果当前消息与上一条消息时间差小于5min，则合并

--

Cheng,

Best Regards

--
您收到此邮件是因为您订阅了 Google 网上论坛的“THU Opensource Mirror Admin”论坛。

[cosli china]

北京航空航天大学开源镜像站帮助页面底部有关Ubuntu的部分（http://mirror.buaa6.edu.cn/help.html），那种形式的帮助很不错，在没能解决分发机制之前，可以先用这个来实现用户自行选择，不知道各位觉得怎样

[Benda Xu]

好主意，联盟可以从互相添加友情链接开始一步一步走起

On Apr 7, 2013 5:57 PM, "cosli china" <china...@gmail.com> wrote:

北京航空航天大学开源镜像站帮助页面底部有关Ubuntu的部分（http://mirror.buaa6.edu.cn/help.html），那种形式的帮助很不错，在没能解决分发机制之前，可以先用这个来实现用户自行选择，不知道各位觉得怎样

--

您收到此邮件是因为您订阅了 Google 网上论坛的“THU Opensource Mirror Admin”论坛。

[Xilin Sun]

IRC 不是早就说过么…………
2013/4/7 cosli china <china...@gmail.com>:

> 主要是需要一种能下线后还能联系到大家的一种工具，上次IRC讨论之后就再没什么进展，因为大家退出频道之后便不能再迅速联系上了。来论坛发帖又觉得不是太便捷（还容易沉）。
> ps：既然大家一下子想到了这么多交流的方式，可能也是感到论坛有时候是不够便捷，有更好的选择为什么现在才提出来呢？

--
May the source be with you.

孙锡麟

[Benda Xu]

我们可以在 TUNA 完成去 NFS 依赖后再组织一次 IRC 会议讨论具体实施办法。

届时 USTC 的统计数据也会出炉了吧？

[Qijiang Fan]

Partychat似乎不错

http://partychapp.appspot.com/

用gtalk就可以

[cosli china]

请朋友做的一个构想http://mirrors6.cugb.edu.cn/choose/，还很粗糙，不懂技术的我还是只能默默在自家服务器按照自己的想法试验，不知道各位对那些高深技术什么的研究的怎么样了，是否有什么新的进展，是否仍要再等等各位的研究成果？

五一过去又要准备考试，时光飞逝，距创建此帖一月有余，距此帖最后回复正好十日，特回复此帖以示此帖“一息尚存”，还没有“呜呼哀哉”。

[imji...@gmail.com]

不知道大家现在讨论的怎么样了，我是中国地质大学（武汉的）。http://mirrors.cug.edu.cn/

在 2013年3月12日星期二UTC+8下午12时21分00秒，cosli china写道：

今日中午12点左右，清华镜像站http://mirrors.tuna.tsinghua.edu.cn/首页撤下了评论，不知道问题是否已经解决~

我几乎全程网上关注了清华镜像站经历的这场风波，昨晚开始很多网站都有转载相关信息，突然觉得各个开源镜像站孤军奋斗不是长久之计，上学期我们地大的镜像站http://mirrors6.cugb.edu.cn/也因为上面的文件被关了很久很久（当然是因为北京开大会的原因，不是学校老师的原因），这学期才算是小范围低调重开。

所以，我觉得各个镜像站之间需要一个能顺畅快速地地进行相互沟通，团结起来，共同进步的桥梁，所以我认为需要有这样一个组织或者平台，不知道各位觉得如何，是否有什么好的建议可以提出来讨论一下

[cosli china]

看到又有一股新力量注入，真是万分激动~如以上帖子所见，当时大家纠结于讨论交流工具、数据分发、网站架构、域名等等具体的且可以待联盟成立之后解决的问题，于是当大家纷纷献言献策之时及之后，却忘记了我们最初的首要目的是要成立镜像站联盟。我虽创此贴，奈何当时mirrors.cugb.edu.cn简陋的服务器也在一年中三番五次的崩溃，隔三差五的宕机而且ipv6 only，个人技术浅薄更是难以改变必是境地。何况大家也可以理直气壮地把宕机、崩溃等问题看作是技术的积累，看作是推翻重来的机会，就像ustc与tsinghua年初一样，能学习到很多，也能重温建站历程，收货颇丰，简直需要万民同贺呢~所以呢，嗯，先不说这帖子沉了有没有一年，也不说为之而心力交瘁过的mirrors.cugb.edu.cn还存不存在，更不用说，哦，没什么可说了。总之呢，如果你需要帮助，欢迎随时联系，但若想要固执地成立镜像站联盟，希望你不要感到失望~如有言辞有不妥之处，还请原谅~

在 2014年4月18日星期五UTC+8上午11时34分51秒，imji...@gmail.com写道：

[yi lu]

神贴啊，想法很好的，我个人也有过类似想法（只是想法），只是实现起来不那么容易了。
收藏了

--
您收到此邮件是因为您订阅了Google网上论坛中的“THU Opensource Mirror Admin”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到thu-opensource-mirr...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。