关于目前archlinux源同步更新镜像时间的疑问

[kosmosoahc]

• USTC archlinux 已从 TUNA 更换为 Tier 1 的镜像，不过同步 archlinux 官方镜像的间隔仍是之前的一小时每次，尽管这样并没有任何问题，过几十分钟就能更新仓库的软件包，比之前 Tier 2 的镜像算是很快了。

• 现在我使用的其它 Tier 1 的镜像，如 pkgbuild , rit.edu , 以及国内的东软，他们的同步时间间隔都是在 archlinux 官方更新软件包的一两分钟内同步对应的 repository，这样能让我马上立马升级使用最新版本的软件包，换回 USTC源 仍需要等待一会到当时该点50分过后才能进行镜像同步更新。

• 我并不是想来说 USTC archlinux 源同步时间慢，实际上一个小时能同步到最新的镜像我已经觉得比起之前好很多了。我的疑问是——固定时间间隔同步我觉得应该是考虑到之前上游 TUNA源 同步更新时间并不确定，每小时同步一次以镜像更新而又不会太过于频繁进行无谓的同步。但是现在已经换到 Tier 1，是否能考虑换到更好的时间机制（参照东软的方式）来进行 archlinux 源同步呢？

[zhsj]

如果有管理员希望减短同步时间至1小时之内，请参考以下脚本来同步，而不要盲目减短同步间隔。
https://git.server-speed.net/users/flo/bin/tree/syncrepo.sh

[knight42]

仍需要等待一会到当时该点50分过后才能进行镜像同步更新。

这是因为我们设置了每小时的 50 分开始同步

这样能让我马上立马升级使用最新版本的软件包

本人也是 Arch Linux 用户，但在日常使用中我似乎还没遇到需要这么频繁更新的需求。我想了解下你的使用场景是什么呢？

固定时间间隔同步我觉得应该是考虑到之前上游 TUNA源 同步更新时间并不确定，每小时同步一次以镜像更新而又不会太过于频繁进行无谓的同步

这固然是一个原因，但其实现在除了 debian 上游更新后有推送这个例外，所有软件源都是以类似 crontab 的方式同步的。如果想更及时地同步，那就不能用现在通用的 rsync 同步方法，需要减少同步间隔并另外实现专门同步 ArchLinux 上游的脚本（参考 @zhsj 给出的链接）。如果有管理员愿意实现的话，可以考虑顺便解决 这个 issue。

[kosmosoahc]

我没有什么特殊场景要求需要使用频繁更新，一个小时间隔而言我觉得已经挺好了。但是使用过其它的 Tier 1源能实时同步，国内东软archlinux也是这样的，想问一下USTC是否能改变之前同步上游TUNA的更新时间机制。

[hosiet]

如果问可不可以的话，当然是可以的。具体实现方法上面已经给出。

现状就是：我们只差一个程序员了™

[lilydjwg]

对了，你们有没有兴趣接收 archlinuxcn 的更新通知呢？

[zhsj]

@lilydjwg 类似 debian 的 ssh push trigger 吗？

[lilydjwg]

@zhsj 那是啥，我先去了解一下。
我现在用的方案是发一个带签名的 UDP 包。

update: Debian 这方案设置起来有点麻烦呀，不像 UDP，fire then forget。

[zhsj]

@lilydjwg 简单的讲就是，我在服务器的 ~/.ssh/authorized_keys 文件里加一行：

command="~/bin/start-sync-archlinuxcn.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty <upstream's public key>

然后你们什么时候想让我们同步，就 ssh 连一下。

[lilydjwg]

@zhsj 明白了，上游的话调用一下 ssh 命令大概就完事了。
所以，要搞起来吗？RSA 还是 Ed25519？