mirrorrequest
mirrorrequest copied to clipboard
ustclug
Can USTC mirror GuixSD to mainland China?
项目名称与简介
GNU GuixSD
GNU GuixSD 是 GNU 项目下基于 Guix 包管理器的一个 GNU/Linux 发行版，它使用 Linux-libre 内核，并提供事务式升级、回滚、可重现建构、各用户独立配置等包管理特性。
The Guix System Distribution (GuixSD) and the GNU Guix package manager are free software projects developed by volunteers around the world under the umbrella of the GNU Project. It uses the Linux-libre kernel, and provides package management features such as transactional upgrades and roll-backs, reproducible build environments, unprivileged package management, and per-user profiles.
项目主页：https://www.gnu.org/software/guix/
上游源地址
https://mirror.hydra.gnu.org/ https://bayfront.guixsd.org/
Ludovic from #guix@freenode provided an nginx.conf at: http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf . I'm not sure if it will be useful or not to the ones who want to mirror the repo.
为什么希望添加该镜像？
随着 Linux 使用门槛的下降，Linux 用户越来越多，部分用户尝试了多种传统的发行版后，总会发现传统包管理器一些不方便避开的问题，比如多个包版本共存，来自上游和自己编译的包没法都在包管理器管理下等，一些用户选择使用 Gentoo 这样完全从源码构建的发行版，也有些用户在尝试 NixOS 和 GNU GuixSD 这些引入很多新的包管理特性的发行版。这类支持可重现重构、方便回滚的包管理特性，是软件包管理的发展趋势。GNU 项目下基于 Guix 包管理器的 GuixSD，就是一个值得尝试的发行版，所以希望 USTC 能把 GuixSD 的软件源镜像到大陆，方便国内的 Linux 用户尝试这个新的发行版，当前 GuixSD 上游已经有接近五千个软件包 。谢谢。
Confirmed by one of GuixSD's maintainer Ludovic that https://mirror.hydra.gnu.org/ is the preferred upstream to mirror from. And he said if you could afford it, you could even build things yourself. And he gave a GuixSD config at https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm to start from.
Ludovic also said that "for all 4 architectures, mirror.hydra.gnu.org uses 1.3T". I think he meant "x86_64 i686 mips64el armhf" by "4 architectures". This is not small size. :-) I can see multiple versions of the same package in the distribution when looking into https://www.gnu.org/software/guix/packages/. That's why it takes huge disk space.
@bigeagle
Cheers.
This would be much welcomed. Currently traditional packaging system is not reliable in various aspects. The new trend for Sandbox packaging systems like Flatpak are not suitable for server use and much less flexible. Experimenting with Nix and Guix, we might actually find a solution to the infamous dependency hell problem and a unified way to configure systems. Besides, having a attractive Linux-libre based distro might help accelerate the progress on open sourcing some blocking firmware.
---------- Forwarded message --------- From: Leo Famulari [email protected] Date: Wed, Dec 5, 2018 at 1:38 PM Subject: Re: Using a CDN or some other mirror? To: Meiyo Peng [email protected] Cc: [email protected]
On Wed, Dec 05, 2018 at 10:32:02AM +0800, Meiyo Peng wrote:
If at some point we need to setup traditional mirrors like other major Gnu/Linux distros, I can contact my friends in China to setup mirrors in several universities. I was a member of LUG@USTC, which provides the largest FLOSS mirror in China.
That would be cool, especially if it's hard to reach our servers from within China.
The Nginx configuration for our mirrors is available in the Guix "maintenance" repo:
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror-locations.conf
... along with similar files 'berlin.conf' and 'bayfront.conf' for those servers.
You can use those files to run your own mirror by changing at least 'server_name', 'ssl_certificate', and 'ssl_certificate_key'.
没有找到可行的镜像方法，下面这段配置实际上是反向代理，而非全量镜像。 如果国内用户直接访问上游会遇到网络问题，那么国内的反向代理服务器访问上游时，也会遇到网络连通性不佳的问题。反代并不能从根本上解决问题。
在官方开放 rsync 等标准同步方式或找到其他可靠同步方法前，可能不容易镜像 GuixSD。
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror-locations.conf
@gaoyifan 可不可以参考这个 https://guix-china.github.io/wiki/mirror/ https://github.com/guix-china
- GuixSD 已经更名为Guix System，即Guix操作系统。GuixSD这个单词已弃用。建议更新此issue标题内的GuixSD为Guix。
- 上游源地址已变。新的地址是
https://ci.guix.gnu.org。 - Guix China组织已提供镜像，欢迎测试。详见： https://guix-china.github.io/wiki/mirror/ 。
- 希望不要因为第3点关闭此issue。mirror.guix.org.cn的硬件资源有限，无法提供大规模的服务。我们仍然希望国内高校能提供Guix镜像服务。
mirror.guix.org.cn 运行59天之后的统计数据：
- Nginx缓存文件共25GB。没有删除过缓存文件，因此累计入站流量也是25GB。
- 从Nginx日志统计的累计出站流量76GB。
由此得出：日均入站流量0.42GB，日均出站流量1.29GB。出站流量是入站流量的三倍。
我估计活跃用户有10个人左右。
@pmeiyu 你能不能把镜像的方法写个教程啊 ustc和tuna的镜像站维护人员不知道怎么镜像 https://github.com/tuna/issues/issues/199
你能不能把镜像的方法写个教程啊 ustc和tuna的镜像站维护人员不知道怎么镜像
只是一个简单的Nginx代理，上面提到的Nginx配置就可以用。mirror.guix.org.cn服务器的配置文件在：https://github.com/guix-china/guix-china-maintenance/
代理和镜像是两码事吧
如果一个网站长得像ci.guix.gnu.org，用起来像ci.guix.gnu.org，即使脱离ci.guix.gnu.org，它仍然还能活着。那么它为什么不可以叫ci.guix.gnu.org的镜像？
@pmeiyu 代理和镜像确实是两码事。镜像的话我们只需要定期同步数据，同步完成后所有内容都在我们的镜像主机上存储，不需要消耗额外的入站流量，但是反代的时候对于每个请求，我们都需要向上游重新获取内容并转发给用户，这对典型的中国网络环境并不友好，也有其他安全风险，因此对于添加反代的请求我们会非常谨慎的考虑。
Guix不适合做传统发行版的“镜像”。
Guix/Nix的机制决定了，一个package更新，这个package的reverse dependecies都必须rebuild，目前Guix支持x86_64, i386, armhf, aarch64四大平台，需要构建的量本来就多，而且Guix CI原则上不删除构建过的旧包。如果USTC选择全部镜像，磁盘空间占用将是十分可怕的，为了空间，TUNA的nix镜像会删除老包的二进制，如果用户不及时升级channel,很可能就面临无二进制可用的尴尬情况，事实上我也是因此转换到Guix上。
另一方面ci.guix.gnu.org 本质上是一个持续集成服务器，提供二进制下载只是其中一个功能，其他更多功能依赖持续集成服务器的状态。比如guix可以用guix weather 查询持续集成服务器是否在建构某个package，使用单纯的镜像很难实现。就算我们强制对这种需要查询CI服务器的命令使用官方CI地址，而由于镜像比原地址常常有一定时间上的滞后，官方有二进制的时候镜像可能没同步，不一定有，导致这类命令的可用性也会下降。
不知道可否参考类似 @skyzh 的方法 https://github.com/flathub/flathub/issues/813#issuecomment-738917403
The mirror works differently from traditional reverse proxy. It is served by our custom-made server https://github.com/sjtug/mirror-intel , and uses a S3-like backend as cache. Upon user connection, it will:
check if requested file is summary / config (https://github.com/sjtug/mirror-intel/blob/master/src/utils.rs#L10) If so, redirect user to flathub original site. then query if that object exists in s3 backend if yes, it will redirect user to s3 object storage (s3.jcloud.sjtu.edu.cn) if not, it will redirect user to original flathub site, and submit task for background download the task will download file from original site and upload it to s3 backend
不知道可否参考类似 @skyzh 的方法 flathub/flathub#813 (comment)
The mirror works differently from traditional reverse proxy. It is served by our custom-made server https://github.com/sjtug/mirror-intel , and uses a S3-like backend as cache. Upon user connection, it will:
check if requested file is summary / config (https://github.com/sjtug/mirror-intel/blob/master/src/utils.rs#L10) If so, redirect user to flathub original site. then query if that object exists in s3 backend if yes, it will redirect user to s3 object storage (s3.jcloud.sjtu.edu.cn) if not, it will redirect user to original flathub site, and submit task for background download the task will download file from original site and upload it to s3 backend
您可以提供一份 ci.guix.gnu.org 的文件特性列表（e.g. 哪些文件是一经上传不会变化，哪些需要回源或反代，哪些需要改写内容再返回用户），我们可以搭建一个基于 mirror-intel 的缓存。
与此同时，如果可以拿到所有需要下载文件的链接，就可以集成到 https://github.com/sjtug/mirror-clone 做全量同步。比如目前 SJTUG 的 rustup 镜像就是通过 HTTP HEAD 访问 mirror-intel 所有需要缓存文件 URL 的方法，同步近 30 天的所有工具链。
您可以提供一份 ci.guix.gnu.org 的文件特性列表（e.g. 哪些文件是一经上传不会变化，哪些需要回源或反代，哪些需要改写内容再返回用户），我们可以搭建一个基于 mirror-intel 的缓存。
这个文件特性列表要以什么样的方式提供呢，是所有文件名的集合吗。还是可以使用可编程的规则（如regexp）？
您可以提供一份 ci.guix.gnu.org 的文件特性列表（e.g. 哪些文件是一经上传不会变化，哪些需要回源或反代，哪些需要改写内容再返回用户），我们可以搭建一个基于 mirror-intel 的缓存。
这个文件特性列表要以什么样的方式提供呢，是所有文件名的集合吗。还是可以使用可编程的规则（如regexp）？
只要是可以编程的规则都可以。我们会直接硬编码到代码里。您可以参考：
- https://github.com/sjtug/mirror-intel/blob/master/src/utils.rs#L10 是 ostree 的规则。包含这些字符串的文件直接重定向到源站点。
- https://github.com/sjtug/mirror-intel/blob/master/src/repos.rs#L159 是 dart-pub 的规则。api 反代并进行字符串替换，过大的 api 文件重定向到源站点，其他文件通过 s3 缓存读取。
您可以提供一份 ci.guix.gnu.org 的文件特性列表（e.g. 哪些文件是一经上传不会变化，哪些需要回源或反代，哪些需要改写内容再返回用户），我们可以搭建一个基于 mirror-intel 的缓存。
@skyzh 你好，感谢你对Guix镜像的兴趣。
ci.guix.gnu.org 含有如下资源：
-
narinfo文件 narinfo是软件包的元数据。文件大小通常在0.5kB至2kB之间。 URL以".narinfo"结尾，模式是"/${hash}.narinfo"。 例如："/x1jgawvxlqckw519hg657xs0gg1n90m4.narinfo"。 -
nar文件 nar是软件包。和其它发行版的软件包类似，文件大小不固定。 URL以"/nar/"开头，模式是"/nar/${compression_algorithm}/${hash}-${package_name}"。 例如："/nar/lzip/b81g1xfpqrf68aw9r3fzn30g0j7db6yi-guix-system"。 -
/nix-cache-info这是一个历史遗留下来的文件，内容固定，只有几十字节。可以不处理。 -
剩下的URL是CI服务的网页资源和API，可以直接转发给上游，也可以不处理。
narinfo和nar文件对用户来说是最重要的。narinfo和nar的内容都是不会变化的，可以保存很久。但是随着时间推移，旧的资源就 没人用了。为了节省硬盘空间，可以定期清理长时间没有访问过的文件。
与此同时，如果可以拿到所有需要下载文件的链接，就可以集成到 https://github.com/sjtug/mirror-clone 做全量同步。比如目前 SJTUG 的 rustup 镜像就是通过 HTTP HEAD 访问 mirror-intel 所有需要缓存文件 URL 的方法，同步近 30 天的所有工具链。
这个不好实现，因为即使CI已经构建好了某个软件，这个软件是以普通文件的形式存放在CI服务器的/gnu/store文件夹里，只有当用户向CI服务器请求这个软件时，CI服务器才会生成narinfo和nar，然后返回给用户。所以没法预先拿到全部的下载链接。上游愿意开放rsync接口，提供guix-publish缓存文件夹，guix-publish缓存文件夹里有CI生成出来的narinfo和nar文件，但是文件保存路径和URL路径是不一致的，不能通过静态HTTP服务直接提供给用户。最近问了开发者，他们在这一块暂时没有改动的意愿。我们可以通过guix-publish缓存文件夹里的文件信息预先拉取部分的软件包，但是我觉得没太大必要。目前rsync接口还没开放出来，我最近再催一催。
与此同时，如果可以拿到所有需要下载文件的链接，就可以集成到 https://github.com/sjtug/mirror-clone 做全量同步。比如目前 SJTUG 的 rustup 镜像就是通过 HTTP HEAD 访问 mirror-intel 所有需要缓存文件 URL 的方法，同步近 30 天的所有工具链。
这个不好实现，因为即使CI已经构建好了某个软件，这个软件是以普通文件的形式存放在CI服务器的
/gnu/store文件夹里，只有当用户向CI服务器请求这个软件时，CI服务器才会生成narinfo和nar，然后返回给用户。所以没法预先拿到全部的下载链接。上游愿意开放rsync接口，提供guix-publish缓存文件夹，guix-publish缓存文件夹里有CI生成出来的narinfo和nar文件，但是文件保存路径和URL路径是不一致的，不能通过静态HTTP服务直接提供给用户。最近问了开发者，他们在这一块暂时没有改动的意愿。我们可以通过guix-publish缓存文件夹里的文件信息预先拉取部分的软件包，但是我觉得没太大必要。目前rsync接口还没开放出来，我最近再催一催。
如果可以拿到两者的对应关系，就可以接入 mirror-clone 做全量同步。现在看起来可以做缓存。
与此同时，如果可以拿到所有需要下载文件的链接，就可以集成到 https://github.com/sjtug/mirror-clone 做全量同步。比如目前 SJTUG 的 rustup 镜像就是通过 HTTP HEAD 访问 mirror-intel 所有需要缓存文件 URL 的方法，同步近 30 天的所有工具链。
这个不好实现，因为即使CI已经构建好了某个软件，这个软件是以普通文件的形式存放在CI服务器的
/gnu/store文件夹里，只有当用户向CI服务器请求这个软件时，CI服务器才会生成narinfo和nar，然后返回给用户。所以没法预先拿到全部的下载链接。上游愿意开放rsync接口，提供guix-publish缓存文件夹，guix-publish缓存文件夹里有CI生成出来的narinfo和nar文件，但是文件保存路径和URL路径是不一致的，不能通过静态HTTP服务直接提供给用户。最近问了开发者，他们在这一块暂时没有改动的意愿。我们可以通过guix-publish缓存文件夹里的文件信息预先拉取部分的软件包，但是我觉得没太大必要。目前rsync接口还没开放出来，我最近再催一催。如果可以拿到两者的对应关系，就可以接入 mirror-clone 做全量同步。现在看起来可以做缓存。
可以对应起来的。如果你愿意的话，也可以这么做。
我已经写好了缓存的规则，近几天会上线。SJTUG Guix 镜像后续的进展，可以移步 https://github.com/sjtug/mirror-requests/issues/131 讨论。
Guix不适合做传统发行版的“镜像”。
Guix/Nix的机制决定了，一个package更新，这个package的reverse dependecies都必须rebuild，
其实我不太同意这个观点，GuixSD 的一个卖点是可重现构建，所以，理论上，只有官方频道里没有的二进制包和用户自己需要去验证某个包是从指定的源码编译出来的，才需要用户去构建那个包。
不过 GuixSD 的镜像确实和传统的镜像不太一样，它不是直接提供静态文件，但本人没有仔细的去调查过。