跳转到主要内容

为Debian和Ubuntu提供自动、健壮的apt-get镜像选择

项目描述

https://travis-ci.org/xolox/python-apt-mirror-updater.svg?branch=master https://coveralls.io/repos/xolox/python-apt-mirror-updater/badge.svg?branch=master

apt-mirror-updater 软件包通过启用发现可用的镜像、对可用的镜像进行排序、自动在镜像之间切换以及健壮的包列表更新(请参阅 功能),实现了Debian和Ubuntu的apt-get镜像选择的自动化。目前已在Python 2.7、3.5+和PyPy(尽管测试覆盖率仍然较低,请参阅 状态)上进行了测试。

功能

发现可用的镜像

DebianUbuntu镜像通过查询Debian镜像列表Ubuntu镜像列表(根据当前平台自动选择适用的镜像列表)自动发现。

对可用的镜像进行排序

发现的镜像按带宽排名(以选择最快的镜像)并排除正在更新的镜像(见镜像更新问题)。

镜像之间的自动切换

/etc/apt/sources.list中配置的主要镜像可以通过单个命令进行更改。新的(待配置)镜像可以自动选择或由用户明确配置。

健壮的包列表更新

如果当前镜像正在更新,一些apt-get子命令可能会失败(见镜像更新问题),而apt-mirror-updater通过封装apt-get update以在失败时重试,并在看起来当前镜像正在更新时自动切换到另一个镜像(因为我见过这样的更新需要超过15分钟,而且长时间等待并不总是可接受的,尤其是在自动解决方案中)。

状态

一方面,apt-mirror-updater软件包是在使用apt-getDebianUbuntu系统以及大规模自动化apt-get(在150多个远程系统上工作)方面拥有多年经验的基础上开发的。另一方面,Python包本身相对较新:它于2016年3月开发和发布。因此

我正在开发一个自动测试套件,但到目前为止,我仍然对如何创建代表性测试用例来处理错误代码路径感到有些困惑(此外,编写一个良好的测试套件需要大量的时间 :-)。

安装

apt-mirror-updater软件包可在PyPI上获得,这意味着安装应该非常简单

$ pip install apt-mirror-updater

实际上有无数种安装Python包的方法(例如,用户特定的site-packages目录、虚拟环境或只是全局安装)并且我无意在这里进行讨论,所以如果您感到害怕,请在这份说明返回之前了解您的选项;-)。

使用

使用apt-mirror-updater软件包有两种方法:作为命令行程序apt-mirror-updater和作为Python API。有关Python API的详细信息,请参阅Read the Docs上的API文档。以下将描述命令行界面。

用法: apt-mirror-updater [OPTIONS]

apt-mirror-updater程序通过启用可用镜像的发现、可用镜像的排名、镜像之间的自动切换和健壮的包列表更新来自动化Debian和Ubuntu的apt-get镜像选择。

支持选项

选项

描述

-r, --remote-host=SSH_ALIAS

在远程系统上操作,而不是本地系统。SSH_ALIAS参数给出了远程主机的SSH别名。假设远程帐户具有root权限或密码免密的sudo访问。

-f, --find-current-mirror

确定在 /etc/apt/sources.list 中当前配置的主镜像,并在标准输出上报告其URL。

-b--find-best-mirror

发现可用镜像,对其进行排名,选择最佳镜像,并在标准输出上报告其URL。

-l--list-mirrors

以人类可读的格式在终端上列出可用的(排名)镜像。

-c--change-mirror=MIRROR_URL

更新 /etc/apt/sources.list 以使用给定的 MIRROR_URL

-a--auto-change-mirror

发现可用镜像,按连接速度和更新状态对镜像进行排名,并更新 /etc/apt/sources.list 以使用最佳可用镜像。

-u--update--update-package-lists

使用“apt-get update”更新软件包列表,在失败时重试,并在当前镜像似乎正在更新时自动切换到另一个镜像。

-x--exclude=PATTERN

将一个模式添加到镜像选择黑名单中。 PATTERN 预期是一个 shell 模式(包含通配符如“?”和“*”),它将与每个镜像的完整 URL 进行匹配。

-m--max=COUNT

不要查询超过 COUNT 个镜像的连接状态(默认为50)。如果您给出数字0,则不应用任何限制。

由于Ubuntu镜像发现可以报告超过300个镜像,因此限制要查询的镜像数量是有用的,否则镜像排名将花费很长时间(因为需要建立超过300个连接)。

-v--verbose

增加日志详细程度(可重复)。

-q--quiet

减少日志详细程度(可重复)。

-h--help

显示此信息并退出。

镜像更新问题

在过去五年中,我的团队(在工作中)和我一直在管理一个由150多个Ubuntu服务器组成的集群,最初使用手动系统管理,但随着时间的推移,为了各种用例(配置、安全更新、部署等)自动化了 apt-get。随着我们自动化程度的提高,我们开始遇到 apt-get 的各种瞬时故障模式,主要是与 apt-get update 相关,但偶然也与其他子命令相关。

我们遇到的最常见的故障是 apt-get update 因为“哈希值不匹配”错误而崩溃(另见 Debian错误 #624122)。当发生这种情况时,有时可以在正在使用的镜像的索引页上找到名为 Archive-Update-in-Progress-* 的文件(另见 Debian错误 #110837)。我见过这些情况持续超过15分钟。

我对这些“哈希值不匹配”错误的工作理论是,它们是由镜像更新不是原子性的事实引起的,这显然导致apt-get update下载了一个数据文件之间不一致的软件包列表。如果这个假设被证明是正确的(并且假设不同的镜像在不同时间更新),那么命令apt-mirror-updater --update-package-lists应该可以绕过这种令人烦恼的故障模式(通过在遇到“哈希值不匹配”错误时自动切换到不同的镜像)。

apt-mirror-updater发布到世界是我的尝试,而不是在问题跟踪器(见上文)中抱怨,那里没有出现稳健和自动化的解决方案(在撰写本文时)。谁知道呢,也许有一天,这些问题将通过将我这里实现的类似逻辑移动到apt-get本身来解决。当然,如果镜像更新是原子的,那也会有所帮助...

联系方式

apt-mirror-updater的最新版本可在PyPIGitHub上找到。文档托管在Read the Docs上,包括一个变更日志。有关错误报告,请GitHub上创建一个问题。如果您有任何问题、建议等,请随时通过peter@peterodding.com给我发电子邮件。

许可证

本软件根据MIT许可证授权。

© 2020 Peter Odding。

项目详情


下载文件

下载适用于您平台文件的文件。如果您不确定要选择哪个,请了解更多关于安装软件包的信息。

源分布

apt-mirror-updater-7.3.tar.gz (43.6 kB 查看哈希值)

上传时间

构建分布

apt_mirror_updater-7.3-py2.py3-none-any.whl (41.4 kB 查看哈希值)

上传时间 Python 2 Python 3

支持者:

AWS AWS 云计算和安全赞助商 Datadog Datadog 监控 Fastly Fastly CDN Google Google 下载分析 Microsoft Microsoft PSF赞助商 Pingdom Pingdom 监控 Sentry Sentry 错误日志 StatusPage StatusPage 状态页面