mirrorrequest
                                
                                 mirrorrequest copied to clipboard
                                
                                    mirrorrequest copied to clipboard
                            
                            
                            
                        增加Vyos 软件仓库和ISO镜像
上游源(官方镜像)的地址
DEB: http://dev.packages.vyos.net/ ISO: https://downloads.vyos.io/?dir=rolling/current/amd64
该项目的介绍
VyOS是基于Debian GNU / Linux的开源网络操作系统。
VyOS提供了一个免费的路由平台,可以与知名网络提供商的其他商业解决方案直接竞争。由于VyOS在标准的amd64,i586和ARM系统上运行,因此可以用作云部署的路由器和防火墙平台。
为什么希望添加该镜像
Vyos是一个欧洲的开源专业级通用软路由系统,但是如果需要人工编译时,往往会发现官方的deb路径网络传输相对较慢,因此希望建立中国的镜像站点。同时从官方下载ISO可能会比较慢,因此从国内下载ISO也许是更好地选择
国内其他镜像源同步情况
中国大陆无镜像站
note: https://wiki.vyos.net/wiki/Mirrors
note: https://github.com/tuna/issues/issues/1094#issuecomment-751184593
https://dev.packages.vyos.net/
是否可以从如下地址镜像?

而ISO,可以考虑镜像rolling即可
https://dev.packages.vyos.net/
是否可以从如下地址镜像?
这里的问题是,网页的 URL 的格式是 https://dev.packages.vyos.net/?dir=<文件夹>,而不是 https://dev.packages.vyos.net/<文件夹>。现有的 HTTP 同步程序没有办法正确处理这样的 URL。
好吧,这确实是问题
@taoky 是否有其他的办法呢?
首先要确认 VyOS 在 1.3 版本后是否可以再分发,比如与上游沟通
之后如果可以而且需要镜像,需要提供一个同步脚本,可以参考 https://github.com/tuna/tunasync-scripts 中的脚本
我去了解下,但是需要一点时间
官方表示可以镜像滚动版本的预编译ISO和所有软件包,但是不能镜像LTS的预编译映像文件
You can distribute rolling release images and any packages anywhere. You cannot distribute prebuilt LTS images, since it disincentivizes business users from supporting the project.
ISO:
https://downloads.vyos.io/rolling/current/amd64/vyos-rolling-latest.iso https://downloads.vyos.io/rolling/current/amd64/vyos-rolling-latest.iso.sha256
@taoky 我发现将https://raw.githubusercontent.com/tuna/tunasync-scripts/master/apt-sync.py 稍作修改后可以用于镜像vyos
需要进行测试以便确认 https://github.com/vyos/vyos-build/ 是否可以使用该源
https://docs.vyos.io/en/latest/contributing/build-vyos.html#customize
https://github.com/tuna/tunasync-scripts/pull/110
可以参考这个
https://github.com/tuna/tunasync-scripts/pull/110#issuecomment-753364003
经过测试,直接用 https://github.com/ustclug/ustcmirror-images#aptsync 同步软件仓库看起来是可以的。关于 ISO,目前我们没有可以只同步单个文件的同步脚本。我有计划写一个通用的 HTTP 同步程序,但是这一段时间估计无法完成。
tuna/tunasync-scripts#110 (comment)
经过测试,直接用 https://github.com/ustclug/ustcmirror-images#aptsync 同步软件仓库看起来是可以的。关于 ISO,目前我们没有可以只同步单个文件的同步脚本。我有计划写一个通用的 HTTP 同步程序,但是这一段时间估计无法完成。
计划这周末添加 Vyos 的 APT 软件仓库镜像测试。
计划这周末添加 Vyos 的 APT 软件仓库镜像测试。
https://mirrors.ustc.edu.cn/vyos/
仅同步了 https://dev.packages.vyos.net/?dir=repositories/current 下的内容。
可否使用vyos-build测试编译?我正在进行编译。测试不会马上进行
编译文档:docs.vyos.io
另外,crux的repo同步其实可以用来手动编译
我现在尝试对这个源进行测试
 为什么会这样
为什么会这样
edit: 好吧,我试试看http
@taoky 这个镜像站同步时间是多少?
为什么会这样
应该是因为 Let's Encrypt 换了新的根证书 CA 导致旧的客户端(没有提前信任这个新的 Root CA 的)不接受新的 LE 证书。暂时使用 HTTP 可以绕过问题,不过能更新客户端或系统里的 ca-certificates 软件包会更好。
@taoky 这个镜像站同步时间是多少?
目前设置的是每天 5:25 开始同步。
另外,
crux的repo同步其实可以用来手动编译
由于上游目录结构的原因,加除了 current 以外的不太方便。
应该是因为 Let's Encrypt 换了新的根证书 CA 导致旧的客户端(没有提前信任这个新的 Root CA 的)不接受新的 LE 证书。暂时使用 HTTP 可以绕过问题,不过能更新客户端或系统里的
ca-certificates软件包会更好。
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html 这一项更改推迟了。出现证书问题可能只是单纯 ca-certificates 没有安装。
由于上游目录结构的原因,加除了 current 以外的不太方便。
好的
由于上游目录结构的原因,加除了 current 以外的不太方便。
实际上确实可能是,因为每一次发行版,都会多出一个新的分支,比如vyos 1.3是equuleus,只有current是固定不变的,对于手动编译滚动版本的,只同步current确实足够
@taoky 测试构建正常,但是有个问题,我怀疑是源拉取跳过了一些实际发生改动的目录,导致现在散列不对(之前正常)

似乎存在被弃用的软件包,每次拉取时,没有对原始目录进行删除?
current目录是滚动目录,因此随时可能发生变动
@taoky 测试构建正常,但是有个问题,我怀疑是源拉取跳过了一些实际发生改动的目录,导致现在散列不对(之前正常)
似乎存在被弃用的软件包,每次拉取时,没有对原始目录进行删除?
current目录是滚动目录,因此随时可能发生变动
所以,vyos 存在一些在包的内容更新时,包的版本号不会发生变化的包?在镜像站上 vyatta-cfg-quagga_0.19.1+vyos2+current9_all.deb 是在 1 月 4 日创建(最后更新)的,但是上游这个包在 1 月 11 日更新的。
@taoky 是的,滚动包都是在jenkins的作用下,自动完成的编译,通常版本号不会随机更新,因此,您需要考虑对滚动更新分支的源执行特殊处理设置,如清空镜像repo目录
感谢您增加这个源这让我完全编译时间从几个小时到十几个小时,减少到1小时内
@taoky 您能处理下这个问题么?
现在同步程序换用了包装了 tuna 的 apt-sync.py 的容器,相比于原先增加的功能是会检查每个包的大小与上游目录文件是否一致。但是这里的情况是 vyatta-cfg-quagga_0.19.1+vyos2+current9_all.deb 这个包上游原地更新后的大小与原先一致,所以仍然不会选择同步新的版本。
由于每次同步都把整个仓库的所有文件扫一遍一般认为是耗时且会给磁盘 IO 带来压力的,所以一般来说同步程序不会检查已有的 checksum 是否一致。由于我们使用了 tuna 的同步脚本,我将与对应的同学讨论如何进行处理。另外,每次都先清空镜像再同步的方式不会考虑。
临时的可能有效的解决方案是将官方源加在最后面,如果从镜像站下载失败的话就从官方源下载(未测试)