我一直在使用用于内部 Linux 系统的 RedHat Satellite。它设置为同步 RedHat 提供的频道子集，并且同步已satellite-sync在 cron 作业中完成。
该卫星最近从 5.7 升级到 5.8。此升级包括用satellite-sync新的
cdn-sync. 根据 RedHat 文档，它应该是一个替代品，他们建议通过一个 cron 作业来运行它，该作业将运行时间随机化为凌晨 1 点到凌晨 3 点之间，如下所示：
0 1 * * * perl -le 'sleep rand 9000' && cdn-sync --email >/dev/null 2>1
但是，我们发现当我们这样做时，没有下载任何内容。没有错误信息；我们得到的只是一封电子邮件，上面写着该命令运行时间为 00:00 分：秒。我们还尝试将输出定向到日志文件而不是 /dev/null，但我们没有得到其他信息，也没有错误消息。尽管如此，没有任何东西得到同步。
我们如何才能cdn-sync真正同步包？
我们有一个带有 4 TB 文件系统的 Linux 服务器，用于存储 subversion 存储库。有许多存储库，其中一些已经使用了几年。
该磁盘最初约为 1 TB，但大约一年前我们开始用完空间并将其增加到 4 TB。现在，人们报告无法将文件签入他们的存储库。错误消息是No space left on device。
该磁盘有大约 1,5 TB 的可用空间，并且还报告有可用的 inode - 但是，无法在其上创建新文件。仍然可以更新旧文件，并且会间歇性地更新一些存储库，但同一存储库可能会在下一次尝试时失败。
我们有一个内部 yum 服务器，其中包含多个存储库（RHEL 存储库的副本、内部创建的程序等）。我们的内部系统与互联网隔离，因此它们只能使用我们的内部服务器。
为了在将补丁全部推送到生产环境之前对其进行测试，我们有一个stable默认启用的存储库。任何更新都会放在-latest回购中。当我们修补服务器时，我们将使用该-latest-repo 来构建一个新的基线并在一些服务器上对其进行测试。测试后，我们将该基线设为新的stable. 默认情况下-latest禁用存储库。
其中一个存储库用于我们从 epel、rpmforge 等获取的一些包。我们有一个脚本，它只同步我们想要的包和他们需要的任何依赖项。包同步后，每晚使用 createrepo 重建 repo。由于这些软件包未经测试，它们最终会出现在int-optional-latest通常被禁用的 repo 中。如果服务器需要来自该 repo 的包，我们将使用enable-repo=int-optional-latest.
今天一位同事试图在服务器上安装 perl-Excel-Writer-XLSX。服务器没有找到包裹。我尝试使用 createrepo 重建存储库，并对 repodata 文件进行 grep 以确保该文件存在。它是。我还使用以下方法验证了该文件是否存在于存储库中
repoquery -q --repoid=int-optional-latest -l perl-Excel-Writer-XLSX
我还清除了客户端的元数据缓存，使用
sudo yum clean expire-cache
尽管如此，客户端仍然声称该软件包在服务器上不存在。
我不认为问题出在服务器端，因为当我尝试从另一台机器进行搜索时，它找到了包。我验证了 repo 文件是正确的，并且名称yum.example.com在两台服务器上解析为相同的 IP 地址 - 但其中一台可以找到包，而另一台则不能。
我们有一个 linux box（称为jumper），用于访问几个单独的 DMZ 中的服务器。每个 DMZ 都有自己的子域名（例如idmz.example.org, jdmz.example.org），每个子域都有自己的权威名称服务器。
我们正在用新的 Linux 机器替换旧的 Solaris 跳线。大多数事情都运行良好，但是我们在idmz.example.com使用 SSH 连接到子域中的服务器时遇到了问题。平工作正常；我们可以使用 解析名称dig，但 SSH 显示“无法解析”。
名称解析在服务器端运行良好，当我们使用 IP 地址连接时，没有延迟或超时。但是客户端的 SSH 声称无法解析服务器。
jenny@jumper$ ping server.idmz.example.com
PING server.idmz.example.com (192.168.1.3) 56(84) bytes of data.
jenny@jumper$ ssh -v server.idmz.example.com
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
ssh: Could not resolve hostname server.idmz.example.com: Name or service not known
jenny@jumper$ ssh 192.168.1.3
[email protected]'s password:
我可以从客户端看到的一个区别是我无法从名称服务器获得权威答案idmz，但我确实从所有其他 DMZ 域中获得了它。