可人儿黄同学1. 这份作业的实际场景：从标题看RHEL学习路线
看到"RHEL第二次作业"这个标题，很多刚开始接触Linux的朋友可能会觉得困惑——第二次作业到底要做什么？结合最近RHEL相关的学习资料、国内镜像源配置这些热词来看，这大概率是系统运维或者云计算方向的一门实操课程作业，而且难度比第一次要上了一个台阶。
第一次作业通常还停留在熟悉命令行、用户管理、文件权限这些基础操作。到了第二次作业，基本就进入真正贴近生产环境的环节了：给一台刚装好的RHEL系统配好可用的软件源、装上一批后续实验必需的兼容库、验证系统能够正常从网络拉取安装包。换句话说，这一阶段的核心目标是让一台"裸系统"变成一台"能干活"的系统。
从我这些年接触过的学员和同行的情况看，RHEL学习路径中翻车最多的地方往往不在系统安装本身，而是在安装完成之后的源配置、依赖处理和仓库排错上。特别是国内网络环境下，RHEL默认的订阅源经常连不上或者慢到无法忍受，这几乎成了每个初学者绕不过去的坎。所以这篇内容我打算围绕RHEL第二次作业最常见的几个潜在任务来展开：镜像源配置、系统镜像获取与校验、兼容库安装、以及安装前后的验证排错。每个环节都会结合我实际踩过的坑来说。
如果你正在做RHEL相关的作业或者自学，这篇文章可以当作一份"操作底稿"来用，按照章节顺序走一遍，基本能把第二次作业的常见套路打通。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 国内镜像源配置：为什么这一步几乎决定了后续所有操作的成败
2.1 默认源在国内环境的真实使用体验
RHEL系统的软件仓库默认指向Red Hat官方的订阅源，这个源本身没有问题，问题出在网络链路上。很多初次接触RHEL的朋友都会遇到这样的场景：执行yum install或者dnf install的时候，进度条走到一小半就卡住不动了，等了几分钟直接报超时错误。有些人会以为是网络断了，反复检查网卡、IP、DNS，折腾半天才发现是源的问题。
在国内做RHEL实验，第一步几乎必然是换成国内镜像源。这里需要注意一个核心区别：RHEL和CentOS在源配置上不太一样。CentOS直接换baseurl指向国内镜像站的CentOS目录就行，但RHEL因为涉及订阅认证，默认情况下dnf会走subscription-manager的插件去验证订阅状态。如果你在做实验时用的是开发者订阅或者评估版，直接把源指向国内镜像站是可行的，但前提是要把订阅相关的插件处理妥当，否则即使改了源，dnf还是会去找订阅服务器校验，一样会卡住。
我自己在实验环境里验证过的做法是：先把subscription-manager相关的插件禁用掉，再修改repo文件指向国内镜像。这样做的逻辑很简单——实验环境不需要订阅管理功能，禁用掉能避免每次操作都被多余的认证流程拖慢。
2.2 配置文件修改的三个关键步骤
修改RHEL镜像源，核心动作就三个：备份、改地址、清缓存。
第一步，把系统自带的repo文件做个备份，防止改挂了之后没法恢复。RHEL 8及之后版本的dnf仓库配置在/etc/yum.repos.d/目录下，默认会有redhat.repo这类文件。备份命令很简单：
bash复制mkdir -p /etc/yum.repos.d/backup
cp /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/
第二步，写入国内镜像源的配置。以清华源为例，RHEL 9的仓库配置可以写成这样：
ini复制[AppStream]
name=RHEL AppStream
baseurl=https://mirrors.tuna.tsinghua.edu.cn/redhat/rhel9/AppStream/x86_64/os/
enabled=1
gpgcheck=0
[BaseOS]
name=RHEL BaseOS
baseurl=https://mirrors.tuna.tsinghua.edu.cn/redhat/rhel9/BaseOS/x86_64/os/
enabled=1
gpgcheck=0
这里需要注意一个细节：gpgcheck=0是实验环境下为了省事的选择。生产环境建议保留gpgcheck=1并导入对应公钥，否则无法校验软件包签名，存在安全隐患。但在做作业、做实验的场景下，很多源镜像的GPG密钥路径和官方不完全一致，反而容易因为校验失败导致报错，所以这一步我一般直接关掉。
第三步，清理缓存并重新生成：
bash复制dnf clean all
dnf makecache
如果makecache能跑通，说明源配置已经生效。后面再看一下仓库列表：
bash复制dnf repolist
正常情况下会看到配置的两个仓库都处于启用状态。
2.3 配置过程中最常见的报错与定位方法
镜像源配置过程中有三个报错出现频率最高，我一个个说。
第一个是Cannot find a valid baseurl for repo。这个报错八成是baseurl地址写错了，或者镜像站路径结构变了。不同镜像站的RHEL目录结构可能略有差异，有些是redhat/rhel9/BaseOS/x86_64/os/，有些则是redhat/9/BaseOS/x86_64/os/。遇到这个报错，先别急着检查网络，直接用浏览器或者curl访问一下配的baseurl路径，看目录是否存在。网络畅通、路径正确，这个问题基本就能解决。
第二个是Failed to download metadata for repo。这个报错通常有两种原因：一种是网络确实到不了镜像站，另一种是gpgcheck开启但密钥没导入，导致元数据校验失败。排查思路很直接：先curl -I测试镜像站连通性，再检查repo文件里gpgcheck的设置。前面提到的实验环境关掉gpgcheck，就是为了规避第二种情况。
第三个是Could not resolve host，这就是DNS解析问题。检查/etc/resolv.conf，确保配置了可用的DNS服务器。如果用的是虚拟机，桥接模式下有时候需要手动配置DNS地址，不能完全依赖自动分配。
3. 系统镜像获取与校验：夸克网盘分享的ISO到底能不能放心用
3.1 教材ISO资源的特点与使用前提
热搜词里提到"我用夸克网盘给你分享了「教材iso」"，里面包含了RHEL/CentOS 7.4、8、9以及欧拉22.03、24的系统镜像。这个使用场景其实非常典型——课程教材配套的资源包，老师在网盘上分享给学生，学生下载下来用来装系统做实验。
这类网盘分发的ISO文件，有一个不能忽视的问题：文件完整性。系统镜像是大文件，少则3GB多则10GB，网盘传输过程中偶尔会出现数据损坏。如果下载下来的ISO文件已经不完整，安装过程中可能在任意一个阶段报错，而且报错信息往往很迷惑——有时候是Unable to read package metadata，有时候是安装到一半直接卡死。
所以拿到任何渠道的ISO，第一件事不是急着装系统，而是校验文件校验值。大部分教材资源分享时，作者会把SHA256或者MD5值一并放出来，或者文件名后缀里直接带了校验串。如果老师没有提供校验值，也至少要把ISO文件的创建时间和文件大小和资源描述对比一下，做基本的合理性检查。
3.2 Linux环境下三种校验方式对比
在已经跑起来的Linux系统里校验ISO，用sha256sum命令最直接：
bash复制sha256sum rhel-9.4-x86_64-dvd.iso
输出的哈希值如果和官方或分享者给出的值完全一致，说明文件完好。如果不一致，那就老老实实重新下载一遍，别抱着"可能只有一点点损坏"的侥幸心理，安装时的报错会让你付出更多时间成本。
如果手上只有Windows机器，可以用certutil命令校验：
batch复制certutil -hashfile rhel-9.4-x86_64-dvd.iso SHA256
macOS上则用：
bash复制shasum -a 256 rhel-9.4-x86_64-dvd.iso
这里想多提醒一句：校验步骤在赶作业的时候最容易跳过，但它恰恰是最值得花时间的环节。一个完好的ISO文件，可以在后续安装和实验中省掉大量排查问题的时间。我见过太多学员在安装时报错后从软件包、硬件兼容性、虚拟化设置一路排查，最后才发现是ISO文件本身有问题。
3.3 网盘资源与镜像站资源的取舍
网盘资源的使用场景主要是上课需要，老师提前把镜像打包好了，方便学生直接用。但如果你是自己学习，我的建议是优先去官方渠道或者镜像站下载。
网盘资源有两个局限性：一个是版本可能滞后，比如老师上传的是RHEL 8.6，但官方已经到了8.10；另一个是资源分享链接可能失效，有时候做到一半发现还需要另一张DVD镜像，但链接已经打不开了，就很被动。镜像站则没有这个问题，随时打开随时下载。
国内比较常用的RHEL镜像站在前面已经提到过清华源，此外还有阿里云、华为云、网易等多家镜像站都有RHEL目录。虽然RHEL的镜像因为版权问题，部分镜像站会限制只同步到特定版本，但做实验和学习用途基本够了。
4. compat-libstdc++：一个让无数人卡壳的兼容库问题
4.1 这个库到底是干什么的
热搜词里有一条"rhel 8.10 compat-libstdc++"，这说明很多人在RHEL 8.10上安装软件时遇到了和这个库相关的依赖问题。compat-libstdc++是一个兼容性库，它的作用是提供旧版本C++标准库的ABI（应用二进制接口）兼容。
用生活场景类比：新版本的libstdc++就像一套新的房屋装修标准，老软件是按照老标准装修的，新环境下某些接口对不上，就装不上或者跑不起来。compat-libstdc++就像是一套转换器，让老软件可以在新系统上正常安装和运行。
RHEL 8.10上需要安装这个库，最典型的原因是要装Oracle数据库。Oracle在RHEL 8/Ist版本上的安装前置检查，会明确要求compat-libstdc++这个包存在。其他场景还包括一些商业软件和老的编译器工具链。如果你做实验时安装某个软件一直报缺少libstdc++.so.6、GLIBCXX_3.4.x之类的错误，大概率就是需要装这个兼容库。
4.2 安装方法与依赖冲突处理
在RHEL 8.10上安装compat-libstdc++，最常规的方式是：
bash复制dnf install compat-libstdc++
如果能顺利安装，那皆大欢喜。但实际情况下经常会报依赖冲突，最典型的问题是：
text复制Error: Problem: conflicting requests
- nothing provides libstdc++.so.6()(64bit) needed by compat-libstdc++-...
这个报错信息看起来非常绕，翻译过来就是：我需要先有libstdc++.so.6这个动态库文件，但系统当前环境里没有提供它的包。解决方法分两步走：
第一步，确认系统当前libstdc++的版本和库文件位置：
bash复制rpm -q libstdc++
find /usr/lib64 -name "libstdc++.so*"
正常情况下，RHEL 8.10自带的libstdc++版本是10.x，对应的库文件是存在的。如果find的结果空无一物，说明基础库出了问题，需要先安装基础库：
bash复制dnf install libstdc++
第二步，再次尝试安装compat-libstdc++。如果还是报找不到libstdc++.so.6，可以用dnf provides来查一下这个文件到底属于哪个包：
bash复制dnf provides "*/libstdc++.so.6"
根据查询结果安装对应包，然后再装compat-libstdc++。这整个排查过程其实就是RHEL依赖体系的一个缩影：dnf会告诉你缺什么，但不一定会告诉你从哪里补，需要你自己去反查。
4.3 安装后的验证方法
安装完成后，验证工作不能省。检查动态库是否注册成功：
bash复制ldconfig -p | grep libstdc++
正常情况下会列出多个libstdc++.so.6的链接路径。再用strings看一下GLIBCXX版本支持情况（注意这一步做实验用没问题，但别在生产环境乱跑，耗时较大）：
bash复制strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
如果这里能看到GLIBCXX_3.4.29等较高版本号，说明兼容库工作正常。后续安装Oracle或者商业软件时，前置检查就能顺利通过了。
5. 从零到可用的完整实验流程：镜像、安装、配置一条龙
5.1 虚拟化环境准备与安装参数选择
做RHEL实验，最常用的环境是VMware Workstation或者VirtualBox。如果是跑RHEL 9.4这些新版本，VirtualBox需要比较新的版本才能保证兼容性，7.x以下版本可能会出现图形界面显示异常、鼠标整合失灵等问题。相比之下VMware Workstation的兼容性更好一点，这也是很多学校实验室选它的原因。
虚拟机配置方面，给RHEL 9实验机分配2核CPU、4GB内存、80GB磁盘是比较稳的起步配置。硬盘容量不用抠抠搜搜，实验过程中可能要装数据库、开发工具链、中间件，这几个大件下来磁盘空间消耗很快。安装源直接挂载下载好的ISO文件，启动虚拟机后就能进入图形化安装界面。
分区方案方面，除非作业明确要求手动分区，否则直接使用"自动分区"就行。有些学生会纠结于/home要不要独立分区、swap要多大、/boot够不够用这类问题，在实验场景下这些纠结完全没有必要，系统自动分区方案足够可靠。RHEL 9的自动分区会自动划分LVM卷组，后续要扩容也方便。
软件包选择是容易被忽略的一个点。安装界面中的"软件选择"步骤，默认是"带图形界面的服务器"。如果你后续要做数据库或者中间件实验，建议选"带图形界面的服务器"并额外勾选"开发工具"；如果你习惯纯命令行操作，选"最小安装"即可。最小安装会省去图形环境，后续全部通过命令行操作，运行速度快，也更能帮助理解系统底层。坏处是缺少一些方便调试的工具需要单独安装。
5.2 安装完成后必须立刻做的四件事
系统装好重启进入系统后，我建议按顺序执行以下四件事，它们能让后续所有实验少很多折腾。
第一件事，配置网络。RHEL 9默认用NetworkManager管理网络，检查当前网卡状态：
bash复制nmcli device status
nmcli connection show
如果是DHCP自动获取IP的虚拟机，这一步能直接看到IP地址。如果没有获取到IP，手动配置一下：
bash复制nmcli connection modify ens160 ipv4.method manual ipv4.addresses 192.168.x.x/24 ipv4.gateway 192.168.x.1 ipv4.dns 223.5.5.5
nmcli connection up ens160
题外话先说清楚：用国内公共DNS没有问题，我这里只举阿里DNS和223.5.5.5都是合规的公共DNS服务，放心用。
第二件事，关闭SELinux或者设置为宽松模式。这个操作在实验环境很常见，因为很多第三方软件的安装和运行会触发SELinux的拦截，报错信息又比较难懂。实验环境下建议先把SELinux设为disabled：
bash复制sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
从安全角度看，生产环境绝对不建议这样做，但学习场景下为了顺畅完成作业，先关掉能节省大量排错时间。等理解了SELinux的机制再重新开启也不迟。
第三件事，配置国内镜像源。这部分上一章已经详细介绍过，直接按那个步骤操作即可。
第四件事，更新系统并安装常用工具：
bash复制dnf update -y
dnf install -y vim wget tar unzip net-tools
net-tools里包含ifconfig、netstat这些命令，虽然在新版本中已不是默认安装，但很多教材和实验步骤仍然基于这些命令编写，装上能省去不少因命令不存在产生的困惑。
5.3 安装compat-libstdc++的完整操作序列
在完成上述四件事基础上，安装compat-libstdc++就很简单了。完整的操作序列如下：
bash复制# 1. 确认基础库存在
rpm -q libstdc++
# 2. 从配置好的镜像源安装兼容库
dnf install -y compat-libstdc++
# 3. 验证安装结果
rpm -qa | grep compat-libstdc++
如果你是按作业要求安装Oracle数据库前置依赖，装完这一步之后继续安装其他依赖包，就不会再卡在compat-libstdc++上了。
6. 实验中的踩坑复盘：五个值得记录的真实问题
6.1 网盘ISO与VMware版本不匹配导致安装卡死
有次实验环境里，一位同学下载了老师分享的RHEL 8 ISO，装在VMware Workstation 15里，进度条走到硬件检测阶段就黑屏了。排查后发现不是系统镜像问题，而是VMware版本太老，对RHEL 8的虚拟硬件支持不完善。解决方法是把VMware升级到16.x以上版本，或者创建虚拟机时选择"CentOS 7"兼容性模式。这个技巧很管用，老版本VMware跑新系统卡住时，可以试试修改客户机操作系统匹配类型。
6.2 夸克网盘下载的ISO文件MD5不一致
另一个同学用夸克网盘下载了RHEL 9.4的ISO，下载完成后直接挂载安装，结果安装过程反复报错，安装日志里全是Failed to read from file之类的错误。最后用sha256sum一校验，和官方给的哈希值差了十万八千里。重新下载一次之后，所有问题消失。这个案例再次说明，ISO校验是第一步，不能跳过。
6.3 镜像源配好之后makecache指挥报错
镜像源配置本身没有问题，但makecache时报了Error: Failed to download metadata for repo 'AppStream'。排查过程是这样的：先尝试curl访问镜像站，发现能通，那就排除网络问题；再翻看repo文件，发现问题出在gpgcheck=1而镜像站路径下没找到对应的repomd.xml.key公钥文件。关掉gpgcheck后重试，问题解决。
这个坑非常典型，尤其是用清华源的时候，它的RHEL仓库结构中GPG密钥存放路径和官方不一样，直接用默认配置很容易踩雷。国内各镜像站RHEL仓库的密钥路径都有差异，实验环境中无脑关掉gpgcheck反而最省心。
6.4 依赖冲突：libstdc++版本错乱
还有一次遇到的情况是系统里既有RHEL 8.10自带的libstdc++，又有从第三方源装的高版本库，导致安装Oracle依赖时检测出冲突。这个问题解决思路是先统一软件源——只使用一个镜像源，不要同时启用多个第三方源。用dnf remove先把不再需要的第三方库卸载掉，再用一个源重新安装依赖。这也解释了为什么在配置镜像源时，我建议把系统自带repo文件备份后全部清理掉，只保留一个镜像站仓库。
6.5 安装Oracle时前置检查显示缺少32位库
compat-libstdc++装好之后，Oracle前置检查可能还会报缺少32位兼容库，比如glibc.i686。这属于连锁依赖问题：
bash复制dnf install -y glibc.i686 libaio.i686
安装时看到.i686后缀的包名就明白，这是32位架构的软件包。某些商业数据库软件包含32位组件，即使系统是纯64位环境也需要这些库。这类问题在RHEL实验中出现频率很高，多储备几个常见包的安装命令很有用。
7. 作业之外的延伸思考：这些技能在实际工作里意味着什么
镜像源配置、兼容库安装、依赖排错，这几个操作在很多初学者眼里就是"作业步骤"，背下来能过就行。但换个角度来看，它们其实是Linux运维中最基础也最核心的三大能力：配置系统能力、解决依赖能力、处理报错能力。
先看配置系统能力。配置镜像源的本质，是理解系统从哪里获取软件组件，如何管理软件包来源。工作中不论是在云上部署生产环境，还是给客户搭一套私有环境，软件源的配置都是第一件事。换个源地址、加一个内网镜像、配置客户端代理，这些操作换汤不换药。
而配置系统能力，意味着能理解仓库源的优先级和覆盖关系。多个源之间的包版本冲突，往往是生产事故的重要源头之一。
再看解决依赖能力。RHEL系的dnf虽然比老牌的yum在依赖解析方面聪明了不少，但依然会因为库版本、架构不匹配、第三方源混用等问题出现依赖灾。解决依赖问题的过程，培养的是"根据错误线索反向定位根因"的能力。这种能力在系统学习、应用部署、故障排查中全都能复用。
最后是处理报错能力。实验中的报错信息是最宝贵的教材。直接问人拿到答案和自己一步步排查出来的答案，长期记忆效果完全不一样。报错无非是三类原因：网络、路径、配置，学会了这三板斧，很多工作场景中的问题都能快速定位到大致方向。
RHEL第二次作业虽然只是一次课程练习，但它几乎是对"Linux系统运维基本功"的一次集中检验。把镜像源配置和兼容库安装这些环节做扎实了，后面真正进入服务部署、Shell脚本、自动化运维阶段时，就不会再被这些基础问题绊住手脚。