Ubuntu Trusty 的一些源 Hash 不符？

[old9]

前两天还没这个问题，今天 apt update 的时候报如下错误：

W: Failed to fetch http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-security/main/source/Sources  Hash Sum mismatch
W: Failed to fetch http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-security/main/binary-amd64/Packages  Hash Sum mismatch
W: Failed to fetch http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-security/main/binary-i386/Packages  Hash Sum mismatch

[SJ Zhu]

把http换成https再试试。

应该是你被劫持了，你用 curl -v
测一测看，http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-security/main/source/Sources
这个文件是不存在的，apt 实际下的是
http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-security/main/source/Sources.gz
或 http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-security/main/source/Sources.bz2

> --
> -- 来自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.
> To post to this group, send email to ustc...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Best regards,
Zhu Shengjing

[old9]

是从校内 PXE 安装的，也就是默认的 sources.list。
刚手动把 sources.list 里面的地址都改成 https 也是一样的错，而且现在 trusty updates 也 mismatch 了：

Fetched 32.3 MB in 18s (1792 kB/s)                                             
W: Failed to fetch https://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-amd64/Packages  Hash Sum mismatch
W: Failed to fetch https://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-i386/Packages  Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead.

尝试过

apt-get clean
apt-get update

也没效果

​

[崔灏 (CUI Hao)]

老毛病。有条件可以 http 抓包看看，自己用 wget 或 curl replay 一下。
不一定是源的问题，感觉 apt 有些 bug，有时候会发莫名其妙的越界 range 请求。

崔灏 / CUI Hao
Homepage: i-yu.me
Twitter: @cuihaoleo

[SJ Zhu]

我在mirrors上检查了文件，应该是没问题的

试试清空 /var/lib/apt/lists/partial

另外校内我也遇到过劫持，不过不是mirrors，而是校外的网站，当时用的是移动出口，然后就被移动劫持了。。。。
http://bbs.ustc.edu.cn/cgi/bbstcon?board=USTCnet&file=M.1395482729.A

[old9]

抓了一下果然是啊，HTTP Headers 里面多了个 Range: bytes=668550-

服务器返回 416 了

[SJ Zhu]

这个我猜是，原来 /var/lib/apt/lists/partial 里有文件，然后 apt 就去 range 请求，但本地的文件比服务器真实的大。。。

[old9]

我清空了 /var/lib/apt/lists/partial （其实之前也清过整个 lists 目录），这次请求没带 range 头，有正常返回，但还是报 mismatch。

实际请求的两个文件是：

http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-amd64/Packages.bz2
http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-i386/Packages.bz2

在服务器上直接 wget 了一下，不知道 apt 是用什么做校验的，手动做了一下 sha1 是：

455c979631f761fbd34a387876932aaa538b3252
35ec1429efa6c85c5061663db4222feec7efdaee

另外注意到有一个 404 的请求 GET /ubuntu/dists/trusty/InRelease 不知道是否和这个问题相关

[Zhang Cheng]

On Tue, Feb 2, 2016 at 3:45 PM, old9 <qi.j...@gmail.com> wrote:

我清空了 /var/lib/apt/lists/partial （其实之前也清过整个 lists 目录），这次请求没带 range 头，有正常返回，但还是报 mismatch。

实际请求的两个文件是：

http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-amd64/Packages.bz2
http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-i386/Packages.bz2

在服务器上直接 wget 了一下，不知道 apt 是用什么做校验的，手动做了一下 sha1 是：

455c979631f761fbd34a387876932aaa538b3252
35ec1429efa6c85c5061663db4222feec7efdaee

另外注意到有一个 404 的请求 GET /ubuntu/dists/trusty/InRelease 不知道是否和这个问题相关

​这个问题我这里可以重现。

apt-get 会用这个文件 http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/InRelease 中的hash来验证上述两个文件：

http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-amd64/Packages.bz2

http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-i386/Packages.bz2​

​现在的情况，确实验证失败：

​$ wget -O- -q http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-amd64/Packages.bz2 | md5sum

81b12be7ecaa5d84597cecf35dee54ab  -

$ grep main/binary-amd64/Packages.bz2 InRelease

 4f9815a9136f644fea7d4cd9fcd2f46d           693687 main/binary-amd64/Packages.bz2

 73b7968092d4ddc52f932c9ed2f555d13ac08f16           693687 main/binary-amd64/Packages.bz2

 9e9e4bd2d88692a27eed483ccdedfb7d83601eee695b127e15bb1cd7404b1924           693687 main/binary-amd64/Packages.bz2

$ wget -O- -q http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/main/binary-i386/Packages.bz2 | md5sum

dbba8af9febfe9f7465d0f813f18d5d9  -

$ grep main/binary-i386/Packages.bz2 InRelease

 91da39e5dc51a18d33e78ac115406387           668552 main/binary-i386/Packages.bz2

 1660d0062f8ad699e0b4203044a1e8684b11170d           668552 main/binary-i386/Packages.bz2

 ed930be3954d83d9e3439497df475b7551badcc81b5f46a42acd2a9d196b28fb           668552 main/binary-i386/Packages.bz2

但是使用 http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/Release 去校验的话，发现是可以通过的。InRelease 文件应该是Release文件加上签名的结果。现在看来，这两个文件不一致。

​说明mirrors.ustc服务器上的文件一致性是有问题的。​

--

Cheng,

Best Regards

[SJ Zhu]

2016-02-02 15:58 GMT+08:00 Zhang Cheng <steph...@gmail.com>:
> 但是使用 http://mirrors.ustc.edu.cn/ubuntu/dists/trusty-updates/Release
> 去校验的话，发现是可以通过的。InRelease 文件应该是Release文件加上签名的结果。现在看来，这两个文件不一致。
>
> 说明mirrors.ustc服务器上的文件一致性是有问题的。

问题应该确认了，mirrors上确实 Release 和 InRelease 文件不一致。
但现在上游已经更新文件了，所以无法确认是不是上游的问题。

zsj@mirrors /srv/repo/ubuntu/dists/trusty-updates $ stat Release
File: ‘Release’
Size: 63457 Blocks: 128 IO Block: 4096 regular file
Device: 831h/2097d Inode: 21858064116 Links: 1
Access: (0655/-rw-r-xr-x) Uid: ( 1008/ mirror) Gid: ( 1008/ mirror)
Context: unconfined_u:object_r:public_content_t:SystemLow
Access: 2016-02-02 10:19:22.420886918 +0800
Modify: 2016-02-02 08:03:00.000000000 +0800
Change: 2016-02-02 11:05:33.916632678 +0800
Birth: -
zsj@mirrors /srv/repo/ubuntu/dists/trusty-updates $ stat InRelease
File: ‘InRelease’
Size: 64439 Blocks: 128 IO Block: 4096 regular file
Device: 831h/2097d Inode: 21858064115 Links: 1
Access: (0655/-rw-r-xr-x) Uid: ( 1008/ mirror) Gid: ( 1008/ mirror)
Context: unconfined_u:object_r:public_content_t:SystemLow
Access: 2016-02-02 10:19:22.416887063 +0800
Modify: 2016-02-02 09:27:00.000000000 +0800
Change: 2016-02-02 11:05:33.916632678 +0800
Birth: -

stage2同步时间都是在这个文件change之后，但是这两个文件的change时间不应该会有时间差。

Feb 02 10:16:48 mirrors ftpsync-ubuntu[25357]: Running stage2: rsync
--partial-dir=.rsync-partial --ipv4 --address=202.141.176.110
--progress --bwlimit=0 -pr$
tvHSB8192 --timeout 3600 --stats
--filter=protect_Archive-Update-in-Progress-mirrors.ustc.edu.cn
--filter=protect_project/trace/mirrors.ustc.edu.cn --filter=$
rotect_Archive-Update-Required-mirrors.ustc.edu.cn --max-delete=40000
--delay-updates --delete --delete-excluded --delete-delay
--exclude=.~tmp~/ mirror.pn$
.gov::ubuntu /srv/repo/ubuntu/
Feb 02 11:09:32 mirrors ftpsync-ubuntu[25357]: Back from rsync with returncode 0

[Zhang Cheng]

我看了下 http://mirrors.ustc.edu.cn/status/，mirrors.ustc目前的Ubuntu上游是 rsync://mirror.pnl.gov/ubuntu，会不会是这个上游有问题？

我看这个上游目前的Release和InRelease文件是一致的（从时间戳上看是一直的，目前mirrors.ustc上这两个文件的时间不一样）：

$ rsync rsync://mirror.pnl.gov/ubuntu/dists/trusty-updates/

###############################################################################

This mirror is managed by Pacific Northwest National Labratory.

It is located in Richland, WA.

If you have any questions, or problems, please email:

mirror at pnnl dot gov

###############################################################################

drwxr-xr-x          4,096 2016/01/28 16:24:44 .

-rw-rwxr-x     23,627,630 2016/02/02 14:11:49 Contents-amd64.gz

-rw-rwxr-x     23,933,370 2016/02/02 14:11:49 Contents-i386.gz

-rw-r-xr-x         64,439 2016/02/02 14:24:00 InRelease

-rw-r-xr-x         63,457 2016/02/02 14:24:00 Release

-rw-r-xr-x            933 2016/02/02 14:24:00 Release.gpg

drwxr-xr-x          4,096 2014/08/22 05:03:11 main

drwxr-xr-x          4,096 2014/02/17 11:24:27 multiverse

drwxr-xr-x          4,096 2014/02/17 11:24:27 restricted

drwxr-xr-x          4,096 2014/02/17 11:24:27 universe

2016-02-02 15:58 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

--

Cheng,

Best Regards

[old9]

我发第一帖的时候是 trusty-security 报错，现在看 trusty-security 里面这两个文件是一致的了。

--

[old9]

看起来似乎是正在同步导致的？

[SJ Zhu]

2016-02-02 16:10 GMT+08:00 old9 <qi.j...@gmail.com>:
> 看起来似乎是正在同步导致的？


ubuntu 确实正在同步，从下午2点40开始的，但现在还在 stage1， 不会同步 Release/InRelease/Package* 这类文件。

[Zhang Cheng]

2016-02-02 16:10 GMT+08:00 old9 <qi.j...@gmail.com>:

看起来似乎是正在同步导致的？

​按理说，如果每一级的镜像都是用ftpsync同步的话，ftpsync会保证在同步的过程中始终是一致的（所有跟索引相关的文件会一起更新）。从目前mirrors.ustc的trace目录（http://mirrors.ustc.edu.cn/ubuntu/project/trace/）看，路径是 mirrors.ustc.edu.cn -> mirror.pnl.gov -> wahoo.canonical.com -> ...，这里有mirror.pnl.gov，说明它用了ftpsync，而它的上游已经是canonical的域名，往上肯定都用的ftpsync。这么看的话，这个链条上应该没有问题。

猜测有这样的可能：

* mirror.pnl.gov 的直接上游不是 wahoo.canonical.com，而是一个没有用ftpsync同步的站点，因此没有留下trace文件。

* ftpsync 有bug，这个的可能性不大，如果是这样的话，应该早就被修了，ftpsync已经有10个月没有更新了。

从mirror.pnl.gov的trace目录（http://mirror.pnl.gov/ubuntu/project/trace/）看，比目前mirrors.ustc的多了一跳 likho.canonical.com，说明 mirror.pnl.gov 最近刚刚更换了上游（或者其没有使用ftpsync的直接上游更换了上游）。

--

Cheng,

Best Regards

[Zhang Cheng]

2016-02-02 16:23 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

​按理说，如果每一级的镜像都是用ftpsync同步的话，ftpsync会保证在同步的过程中始终是一致的（所有跟索引相关的文件会一起更新）。从目前mirrors.ustc的trace目录（http://mirrors.ustc.edu.cn/ubuntu/project/trace/）看，路径是 mirrors.ustc.edu.cn -> mirror.pnl.gov -> wahoo.canonical.com -> ...，这里有mirror.pnl.gov，说明它用了ftpsync，而它的上游已经是canonical的域名，往上肯定都用的ftpsync。这么看的话，这个链条上应该没有问题。

猜测有这样的可能：

* mirror.pnl.gov 的直接上游不是 wahoo.canonical.com，而是一个没有用ftpsync同步的站点，因此没有留下trace文件。

* ftpsync 有bug，这个的可能性不大，如果是这样的话，应该早就被修了，ftpsync已经有10个月没有更新了。

从mirror.pnl.gov的trace目录（http://mirror.pnl.gov/ubuntu/project/trace/）看，比目前mirrors.ustc的多了一跳 likho.canonical.com，说明 mirror.pnl.gov 最近刚刚更换了上游（或者其没有使用ftpsync的直接上游更换了上游）。

​我建议我们直接从Ubuntu/Canonical官方的镜像开始同步，或者找一个确定整条链都用ftpsync同步的站点作为上游，以保证我们的镜像总是可用。至于如何找“确定整条链都用ftpsync同步的站点”，这个没有可靠的方法，那我们就尽量用“知名”的站点作为上游吧（凭经验啰）。

--

Cheng,

Best Regards

[SJ Zhu]

2016-02-02 16:28 GMT+08:00 Zhang Cheng <steph...@gmail.com>:
> 我建议我们直接从Ubuntu/Canonical官方的镜像开始同步，或者找一个确定整条链都用ftpsync同步的站点作为上游，以保证我们的镜像总是可用。至于如何找“确定整条链都用ftpsync同步的站点”，这个没有可靠的方法，那我们就尽量用“知名”的站点作为上游吧（凭经验啰）。

官方速度实在是太慢了，好像不是网速慢，我试过用vpn来同步也慢。。可能同步的人太多了。。

npl 当时试了试速度不错，而且它上级是官方源

[Zhang Cheng]

2016-02-02 16:44 GMT+08:00 SJ Zhu <zsj9...@gmail.com>:

官方速度实在是太慢了，好像不是网速慢，我试过用vpn来同步也慢。。可能同步的人太多了。。

npl 当时试了试速度不错，而且它上级是官方源

​npl有官方说明他们上级用的是哪个站点么？仅从trace目录看不出来，不排除它的上级是一个没有用ftpsync的站点。​

--

Cheng,

Best Regards

[SJ Zhu]

2016-02-02 16:46 GMT+08:00 Zhang Cheng <steph...@gmail.com>:
> npl有官方说明他们上级用的是哪个站点么？仅从trace目录看不出来，不排除它的上级是一个没有用ftpsync的站点。


这一点比较坑，没法保证。。。

[SJ Zhu]

写了个脚本来比对md5值，https://gist.github.com/zhsj/ba990286b3ebffd202e5

然后发现又有新文件md5不对，于是现在ubuntu上游已经换掉了，现在是 kaist。