本地镜像配置yum源安装Apache httpd实战（CentOS 7）

1. 为什么装个Apache还要折腾本地镜像源

先交代一下背景。很多刚接触Linux运维的朋友会有个疑惑：装httpd这种基础服务，直接yum install httpd不就行了？但真实生产环境里，yum默认走的网络源经常是没法用的——机房服务器没有外网权限、内网隔离环境、或者源站慢到难以忍受。这时候你手头最靠谱的东西，反而是当初装系统时用的那张ISO镜像或者已经拷贝到本地的镜像文件。

本地镜像里带着一整套RedHat系发行版的RPM包仓库，把它挂载出来配成本地yum源，装httpd、配虚拟主机、补依赖，整个过程不仅不依赖外网，而且速度快、版本可控。这个思路在工作中非常常用，尤其是内网环境批量部署服务器的时候，你不可能每台机器都去外网拉包，把镜像源配好之后，yum install、yum groupinstall都能顺滑跑起来。

这篇文章就把整个流程完整梳理一遍，从怎么挂载镜像、怎么写repo文件，到怎么把httpd装起来、怎么改配置、怎么验证服务可用，最后把我在实际操作中踩过的坑也一并列出来。内容基于CentOS 7环境实测，其他RHEL系发行版操作基本一样。

先说明一下整体思路：本地镜像RPM包安装httpd，核心其实是两步——先把本地镜像变成系统认可的软件仓库，再通过yum从仓库拉取并安装httpd及其依赖。这里不推荐直接rpm -ivh去装那个httpd的rpm包，因为httpd依赖很多子包和库，手动rpm安装很容易陷入依赖地狱，而yum自动解决依赖问题，省心太多。

2. 准备工作：确认环境与镜像文件

2.1 系统版本与镜像匹配

在做任何操作之前，先确认三件事：操作系统版本、镜像文件是否匹配、以及磁盘空间是否够用。我这边测试机是CentOS 7.9，镜像用的是CentOS-7-x86_64-DVD-2009.iso，这是比较经典的组合。

bash复制# 查看系统版本
cat /etc/redhat-release

# 查看内核信息
uname -a

# 确认磁盘空间，至少预留5G以上
df -h

镜像文件的存放位置建议放在/root或者/home这种不影响系统运行的分区，不要直接丢在/boot这种小分区。镜像大小通常在4G左右，拷贝或者挂载之前先确认目标分区有足够空间。

2.2 挂载镜像的两种方式

物理服务器一般直接插入光盘或者挂载iLO/VNC的虚拟光驱，虚拟机则可以直接在虚拟机设置里挂载ISO镜像文件。无论是哪种方式，最终都会在系统里出现一个光驱设备，一般是/dev/cdrom或者/dev/sr0。

挂载的动作我就直接写了：

bash复制# 创建挂载目录
mkdir -p /mnt/cdrom

# 挂载镜像到目录
mount /dev/cdrom /mnt/cdrom

# 验证挂载结果
df -h /mnt/cdrom
ls /mnt/cdrom

如果一切正常，ls /mnt/cdrom你会看到Packages、repodata、LiveOS等目录，其中Packages目录里就是成千上万个RPM包，repodata目录里则是yum源的关键索引数据。能看到这两个目录，就说明镜像内容完好，可以做源了。

这里有个细节值得注意：/mnt/cdrom只是临时挂载点，系统重启之后挂载关系就丢了。如果想让服务器重启后依然保留这个本地源，需要把挂载信息写进/etc/fstab。比如我用的这行配置：

code复制/dev/cdrom    /mnt/cdrom    iso9660    defaults,ro    0 0

写完之后可以执行mount -a测试一下配置有没有问题。不过对于一次性实验环境，不写fstab也没关系，每次重启后手动mount一次就行。

3. 搭建本地yum源：核心操作详解

3.1 备份原有repo配置

这一步容易被忽略，但非常重要。系统自带的/etc/yum.repos.d/目录里通常有几个默认的repo文件，指向的源基本都是外网地址。如果这些源处于不可达状态，yum在尝试连接的过程中会浪费大量时间，甚至导致后续安装命令迟迟没有响应。所以我习惯先把它们全部移到备份目录：

bash复制mkdir -p /etc/yum.repos.d/backup
mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/

备份这一步的好处是后面随时可以还原，不至于把系统自带的源配置弄丢。做完之后/etc/yum.repos.d/目录下应该没有repo文件了，这时就可以创建属于我们自己的本地源配置。

3.2 编写本地源repo文件

在/etc/yum.repos.d/目录下新建一个文件，名字随意，但后缀必须是.repo。我习惯叫local.repo，简单明了：

bash复制vim /etc/yum.repos.d/local.repo

内容如下：

ini复制[local]
name=Local CentOS Repository
baseurl=file:///mnt/cdrom
enabled=1
gpgcheck=0

这四个核心参数逐一说一下：

• [local]是仓库ID，必须全局唯一，后面执行yum命令时如果报错说找不到这个仓库，首先检查ID有没有写错。
• name是仓库描述信息，随便填，主要给人看的。
• baseurl是仓库地址，file://协议指向本地路径，后面跟的就是你镜像挂载的路径。这里容易写错，注意是三个斜杠。
• enabled=1表示启用这个仓库，如果写成0那yum会自动忽略它。
• gpgcheck=0表示不进行GPG密钥校验。正常来讲官方源都建议开启GPG校验，但本地镜像源用的就是原版安装包，不开启也不会有安全问题。实验中为了省事我直接关掉了。

写完repo文件后执行配置刷新：

bash复制yum clean all
yum makecache

如果配置没问题，yum makecache会在输出里看到local这个仓库，并且提示元数据缓存已建立。此时可以用yum repolist确认仓库状态：

bash复制yum repolist

如果列出的仓库里有local，并且包数量有好几千，那就说明本地yum源已经可用了。整个过程中最常见的错误是baseurl路径写错、目录没挂载成功，这两个问题通过ls /mnt/cdrom和cat /etc/yum.repos.d/local.repo基本都能定位出来。

3.3 验证依赖解析能力

本地源到底好不好用，装个东西试试就知道。直接装httpd之前，可以先装个小的工具验证依赖解析能力，比如vim或者lsof。lsof这个工具后面排查端口占用时会用到，顺手装上：

bash复制yum install -y lsof

安装过程正常走完、没有报错，那就说明yum能够从本地源正常拉取并安装软件包，依赖解析也是OK的，这时候可以放心装httpd了。

4. httpd安装与基础配置

4.1 安装httpd及依赖

既然本地源已经就绪，装httpd就非常直接：

bash复制yum install -y httpd

yum会自动解析依赖，把httpd-tools、apr、apr-util、mailcap等依赖包一并装好。相比手动rpm -ivh逐个安装，这一步省下的时间不是一点半点。

安装完成后查看版本：

bash复制httpd -v

正常输出会显示Server version: Apache/2.4.6 (CentOS)之类的信息。到这里httpd本体就装好了，接下来是配置环节。

在CentOS 7上，httpd的主要目录和文件分布如下：

了解这个结构很重要，后续所有操作都围绕这些路径展开。尤其是conf.d目录，强烈建议一个站点一个配置文件放在这里，而不是全部堆在主配置文件里。这样后期维护和排查问题都方便得多。

4.2 主配置文件关键参数解读

打开/etc/httpd/conf/httpd.conf，虽然文件很长，但真正需要理解的核心配置其实就那么几块。我挑实验中最常用的几个参数说，这些也是面试和实践中最高频的考点。

第一个是Listen参数，默认是：

code复制Listen 80

它决定了httpd监听的端口。如果机器上80端口被占用，或者你想把服务跑在8080等自定义端口上，就改这里。改完必须重启服务才会生效。

第二个是DocumentRoot，默认值是：

code复制DocumentRoot "/var/www/html"

这个就是网站根目录的路径，当用户访问服务器域名或IP时，httpd会从这个目录去找默认页面文件。实验环境里我一般会在该目录下创建一个index.html测试页面，内容随意，能确认服务可访问就行。

第三个是Directory配置块，主配置文件里有一段默认配置：

code复制<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

这里的关键是Require all granted，它表示允许所有来源的请求访问该目录。CentOS 7默认httpd配置里是允许访问的，但网上很多教程会让你自己去加这行，原因是你自己新增的虚拟主机配置里如果没有这行，访问时会直接403。

我把这几个参数从默认值改成实验需要的内容时，通常只动端口和域名相关的，其他保持默认。能不动就不动，这是运维的一个基本原则。

4.3 创建自定义配置实例

为了验证配置能力，我一般会在conf.d目录下新建一个站点配置，比如test.conf：

bash复制vim /etc/httpd/conf.d/test.conf

内容：

apache复制Listen 8080

<VirtualHost *:8080>
    ServerName localhost
    DocumentRoot /var/www/html
    <Directory "/var/www/html">
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
    ErrorLog "logs/test-error_log"
    CustomLog "logs/test-access_log" common
</VirtualHost>

这里简单说明几个配置意图：

• Listen 8080表示服务额外监听8080端口。
• VirtualHost配置块定义了一个虚拟主机，ServerName是主机名，DocumentRoot指向网站根目录。
• 我在虚拟主机里单独指定了错误日志和访问日志的名称，这样测试站点和默认站点可以分开记录日志，方便排查。

自定义配置写完后，有一个非常关键的动作：用httpd -t检查语法。

bash复制httpd -t

如果输出Syntax OK，说明配置文件语法没问题，可以重启服务了。如果输出里有Syntax error on line ...的提示，就需要根据提示的行号去对应文件里排查。我遇到过的情况大多是不小心漏掉了某个标签闭合、或者路径写错，按照行号去查基本都能解决。

4.4 启动服务与开机自启

配置通过语法检查后，启动服务：

bash复制systemctl start httpd

查看服务运行状态：

bash复制systemctl status httpd

如果希望服务器重启后httpd自动启动，执行：

bash复制systemctl enable httpd

这步在真实环境里通常必须做，不然服务器一重启Web服务直接挂掉，等着被投诉吧。

启动服务后可以用ss -lntp或者lsof -i:80确认监听状态：

bash复制ss -lntp | grep httpd

或者：

bash复制lsof -i:80

正常情况下能看到httpd进程监听在80端口，8080端口如果也配置了虚拟主机，同样会看到监听。如果lsof没有任何输出，检查服务是否真的启动了。

5. 防火墙与SELinux处理

5.1 防火墙放行端口

CentOS 7默认开启了firewalld防火墙，即使httpd服务本身启动正常，外部机器访问时也极大概率被防火墙拦下来。为了让实验能够被其他机器访问到，需要放行相关端口。

bash复制firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --reload

--permanent参数表示永久生效，--reload让配置立即生效。改完后可以再执行一次：

bash复制firewall-cmd --list-ports

看到80/tcp 8080/tcp输出就说明放行成功。

这里要特别提醒：如果是在真实生产环境，防火墙放行前一定要确认安全策略，不要为了图省事直接关防火墙。很多安全事故就是这种看似不经意的操作埋下的隐患。实验环境里如果你确认只是内部测试，放行几个测试端口就够了，别去执行systemctl stop firewalld这种操作。

5.2 SELinux对Web目录的影响

用过CentOS的朋友都知道，SELinux是另一个容易坑人的东西。如果开启了SELinux并且处于Enforcing模式，你自定义的网站目录如果没有打上正确的SELinux标签，httpd访问时会被拒绝，表现就是浏览器访问报403。

检查SELinux状态：

bash复制getenforce

输出Enforcing说明SELinux处于强制模式。查看网站目录的SELinux上下文：

bash复制ls -Z /var/www/html

如果你把网站目录换到了别的位置，比如/data/www，就需要对新目录设置正确的上下文：

bash复制semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
restorecon -Rv /data/www

如果系统里没有semanage命令，说明没有安装policycoreutils-python，用yum从本地源装一个就行：

bash复制yum install -y policycoreutils-python

这个坑特别典型：httpd配置完全正确、防火墙也放开了，但访问就是403，查了半天最后发现是SELinux标签的问题。所以这里写详细一点，希望能帮大家少踩一次坑。

实在嫌麻烦的实验环境，可以临时把SELinux切到Permissive模式观察对比：

bash复制setenforce 0

但如果服务器重启，SELinux会恢复为Enforcing，这只能作为定位问题的手段，不建议作为长期方案。我个人的建议是：把上下文打正确，别用setenforce 0来绕，毕竟SELinux是对抗入侵的重要防线，生产环境把它关掉纯粹是在给自己挖坑。

6. 测试访问与验证服务可用性

6.1 本机验证HTTP响应

启动服务、放行防火墙之后，第一步先在本机验证服务是否正常响应。我在/var/www/html下放一个测试页面：

bash复制echo "<h1>Hello, Local Yum Apache</h1>" > /var/www/html/index.html

然后在服务器本机执行：

bash复制curl -I http://localhost

正常返回的响应头里会包含HTTP/1.1 200 OK，这说明httpd已经能正常处理请求了。如果返回Connection refused，多半是服务没起来；如果返回403，则是目录权限或者SELinux的问题。

测试自定义端口，也就是刚才配的8080：

bash复制curl -I http://localhost:8080

同样期待返回200状态码。两个端口都通了，说明本机验证阶段通过。

6.2 从客户端机器访问测试

本机验证通过之后，再从另一台机器访问服务器IP测试。假设服务器IP是192.168.1.100，客户端执行：

bash复制curl -I http://192.168.1.100

这一步能通，说明网络路径、防火墙策略、httpd配置都没问题。如果通不了，按顺序排查：先ping服务器IP确认网络通不通，再检查防火墙是否放行了端口，最后用ss -lntp在服务器上看服务是否在监听。

用浏览器访问时，如果看到测试页面的内容，那么整个基于本地镜像RPM包安装并配置Apache的实验就算走通了。从挂载镜像到服务对外可访问，整个闭环已经完成。

6.3 日志验证与检查

服务访问正常后，可以通过日志确认请求确实被服务端正确处理了。httpd默认日志在/var/log/httpd/下：

bash复制tail -f /var/log/httpd/access_log

再在浏览器刷新一次页面，可以看到类似下面的记录：

code复制192.168.1.101 - - [05/Jan/2025:14:23:11 +0800] "GET / HTTP/1.1" 200 45 "-" "Mozilla/5.0 ..."

里面有客户端IP、访问时间、请求方法、状态码、返回字节数这些信息。如果页面报错，日志会反映在error_log里。养成看日志的习惯，是运维从业者最基本的素养。

7. 实验中的坑与排查技巧实录

7.1 yum无法使用本地源

实验中最常见的坑就是yum报错，比如提示找不到仓库、或者下载元数据失败。这类问题可以先执行：

bash复制yum repolist

看仓库列表里有没有local。如果没有，检查/etc/yum.repos.d/local.repo里的baseurl路径是否与实际的挂载点一致。

如果提示file:///mnt/cdrom/repodata/repomd.xml找不到，首先要确认镜像真的挂在/mnt/cdrom下面：

bash复制ls /mnt/cdrom

很多时候就是服务器重启过、fstab没配置，挂载关系丢了，重新mount一下就好。这个问题我在一开始就提到过，重启后挂载丢失是本地源最常见的故障点。

7.2 httpd启动报错与端口占用

启动httpd时报错启动失败，用systemctl status httpd -l查看详细日志，常常能看到类似Address already in use的提示，说明端口被其他进程占用。

这时候用lsof排查端口占用：

bash复制lsof -i:80

输出里的COMMAND列如果是nginx或者其他进程，说明80端口被别的服务占了。解决方案有两个方向：一是停掉占用进程，二是修改httpd的Listen参数换一个端口，二选一即可。

7.3 配置文件语法错误

修改配置文件后，httpd启动失败，httpd -t检查时提示类似：

code复制httpd: Syntax error on line 506 of /etc/httpd/conf/httpd.conf:
Invalid command 'xyz', perhaps misspelled or defined by a module not included in the server configuration

这种报错在搜索引擎里很常见，包括phpStudy集成的Apache环境里也经常遇到。出现的原因通常有三种：

第一种是拼写错误，某个指令名称写错了，比如把DocumentRoot写成Documentroot，Apache指令是区分大小写的，这种错误最常见。

第二种是模块缺失。某个指令依赖的模块没有被加载，比如mod_rewrite的指令如果没有加载对应模块，就会报错。解决方法是在配置里加载对应模块，CentOS 7的httpd一般通过LoadModule指令加载。

第三种是引用了不存在的文件或路径，比如ErrorLog指向的目录不存在，httpd语法检查也会报错。

每次修改配置后都执行一遍httpd -t，是避免这类问题最有效的方法。不要直接重启服务，因为语法错误导致服务起不来，在业务高峰期是很尴尬的事情。

7.4 浏览器访问403

curl能看到响应，但浏览器访问403，这是权限问题。排查步骤简单整理如下：

从我的实际经验来看，这个问题的元凶大概率是SELinux。在CentOS 7上，如果网站目录不是标准的/var/www/html而是手工创建的自定义目录，就很容易遇到。

7.5 通过rpm命令直接安装时的路径问题

有些场景下，比如没有做本地源但手里只有一个httpd的rpm包，纯靠rpm -ivh硬装也是可行的，但麻烦在于依赖包可能要手动下载好几个。如果你确实需要走这条路，建议先查清楚依赖关系，把apr、apr-util、httpd-tools、mailcap这些包提前准备好，按照依赖从底层往上逐个安装。不过有了本地镜像源之后，yum自动解决依赖就是最舒服的选择，这也是我在文章开头强调要做本地源的原因。用rpm单包安装httpd，大概率在依赖上消耗的时间比配置服务本身还多。

7.6 安装JDK等包时举一反三

这个实验做完之后你会发现，本地yum源是个通用能力。装httpd能用它，装JDK也一样。比如搜索linux安装配置jdk11 rpm包就能看到类似思路——把jdk-11*.rpm放在本地目录，通过yum localinstall或者rpm命令直接装，本质都是把RPM包变成系统可识别的安装源。

如果后续自己收集了一些不在系统镜像里的软件包，想做成一个私有源，可以用createrepo这个工具对某个目录建立repodata索引，再写一个repo文件指向它，这就成了一个完全自定义的本地软件仓库。团队里备一个这种仓库，批量部署效率会提升非常多。

8. rpm包依赖无法满足时的替代思路

虽然本地镜像自带的软件包数量已经很庞大，但偶尔也会遇到镜像源里找不到某个依赖的情况，比如某些第三方软件需要特定版本的库，而镜像里的版本偏旧。

这种场景下有两个可选的替代思路。第一个是用yumdownloader从能联网的机器上下载所需rpm包，再拷贝到内网机器上安装。这个工具包含在yum-utils包里，如果没有就先装yum-utils：

bash复制yum install -y yum-utils

然后在一台能联网的同版本CentOS上执行：

bash复制yumdownloader --resolve --destdir=/tmp/rpms 某个软件名

--resolve参数会自动把依赖包一并下载到指定目录。下载完成后把整个目录拷贝到内网机器，执行：

bash复制yum localinstall /tmp/rpms/*.rpm

这样就能绕过本地镜像源缺少依赖的问题。

第二个思路是把这些额外下载的rpm包放进一个统一目录，用createrepo建成本地私有源，然后写一个repo文件指向该目录，就能像使用系统源一样使用它。这个思路适合需要长期维护私有软件包的场景。

9. 实验总结与个人经验

整个实验走下来，最核心的收获是对“软件仓库”这个概念有了更直观的理解。yum本质上是rpm的封装，它做的事情是自动从仓库里获取软件包并解决依赖关系。理解这一点后你会发现，远程源也好、本地源也好、私有源也好，核心都是提供一个带repodata索引的目录让yum去读，区别只在于是走网络还是走本地路径。

我个人在实际操作中的体会是：本地镜像源这种方式，解决的不只是能装不能装的问题，更重要的是让整个安装过程的依赖关系变得透明可控。尤其是在内网环境里做实验或者交付项目，用本地镜像做源是成本最低、最稳妥的方案，一次配好，后面所有软件安装全部复用，性价比极高。

最后再分享一个小技巧：实验完成后，建议把完整的操作步骤整理成脚本，从挂载镜像到配置repo文件再到安装服务，这样下次在别的机器上复现时直接执行脚本就能完成环境搭建，省掉大量重复操作的时间。尤其当你需要在十几台服务器上重复同样配置时，这个脚本的价值会体现得非常明显。