算起来接触Linux运维也有年头了。从最开始装个系统都要折腾半天的纯小白到现在能独立搭起一套完整的自动化装机环境中间踩过的坑、翻过的车估计都够写好几本“血泪史”了。最近正好在给团队整理内部培训资料翻到早期记录的笔记发现Linux系统这一整套核心知识其实是非常成体系的。很多人学Linux喜欢零散地学比如今天弄个NFS明天折腾个FTP这样虽然上手快但知识是割裂的遇到复杂的故障排查就抓瞎了。我个人的体会是Linux运维真正难的不是某个单独的命令或服务而是把这些核心组件串起来理解它们在真实的生产环境里是如何协同工作的。比如一台崭新的服务器从通电到能跑Web服务中间隔着硬件自检、内核启动、服务初始化、网络配置、应用部署这么多环节每个环节都有它的脾气和坑。所以这次我就想着把系统启动过程、WEB工作原理、DHCP、DNS、NFS、FTP以及最后的PXEKickstart自动装机整个串成一条线写成一份比较完整的总结。这份总结不仅仅是罗列知识点更多的是我这些年实战中积累下来的核心原理梳理、配置要点、以及那些常规文档里通常不会写到的避坑经验。无论你是刚入门想建立知识体系的运维新人还是已经工作一段时间想查漏补缺的同行我都觉得这份梳理值得一看。这篇东西没法面面俱到但一定都是最核心、最常用的干货希望能帮你在运维这条路上少走几步弯路。1. Linux系统启动过程从按下电源键到看见登录界面很多初学者对Linux的印象就是“黑乎乎的终端和一堆命令”但对系统从通电到完全启动这一路发生了什么往往不太关心。其实这是运维的基本功。很多时候排查启动故障比如卡在某个界面、内核panic、某个服务起不来都需要靠理解启动流程去定位。我把整个流程拆解成六个核心阶段。1.1 第一阶段硬件自检与BIOS/UEFI接管当你按下电源键此时CPU还是“裸奔”状态操作系统根本不存在。真正第一个登场的是固化在主板上芯片里的固件程序传统叫BIOS现在主流新机器都是UEFI。这个阶段做的事情通俗讲就是“硬件的自我体检”它会检查CPU、内存、显卡、键盘磁盘控制器这些最基本的硬件能不能正常工作。如果某个硬件挂了就会听到报警蜂鸣声或者直接黑屏报错。BIOS/UEFI完成自检后会根据你设定的启动顺序Boot Order去尝试加载引导程序。这个顺序默认可能是U盘、光盘、硬盘网络。所以有时候你插着一个启动盘忘记拔服务器重启后可能又进了安装界面就是这个原因。在UEFI模式下它还会涉及安全启动Secure Boot的问题如果开启了这个功能且内核没有相应签名启动会被拦下来。1.2 第二阶段引导程序GRUB2的使命BIOS/UEFI把控制权交给了启动扇区里的引导程序。在主流Linux发行版中这个角色基本被GRUB2垄断了。GRUB2的核心使命就是加载内核到内存并把控制权交接给内核。它的配置文件在现代发行版里通常不让你直接改比如CentOS/RHEL系列主配置在/etc/default/grub修改后需要用grub2-mkconfig -o /boot/grub2/grub.cfg重新生成。这一点必须记牢手动改了/boot/grub2/grub.cfg下次内核更新或者重新生成配置的时候你的改动很容易被直接覆盖掉。GRUB2还有个很实用的功能是在启动菜单界面按E键进入编辑模式。系统如果因为内核参数导致起不来比如误加了nomodeset或者奇怪的selinux参数可以在启动时临时修改参数然后按CtrlX启动这种临时修改不进配置文件非常适合紧急救援场景。1.3 第三阶段内核初始化与虚拟文件系统GRUB2把内核加载进内存后内核开始运行。它做的第一件事是解压自身初始化各种核心子系统比如内存管理、进程调度器、中断处理等等。但这里有一个颇为棘手的逻辑问题内核需要加载磁盘驱动才能识别根文件系统可驱动模块本身又存放在磁盘上这就陷入一种“先有鸡还是先有蛋”的循环。为了解决这个问题内核引入了虚拟文件系统也就是initramfs。它是一个存放在/boot目录下的压缩镜像里面打包了必要的驱动模块和初始化脚本。内核先在内存中把这个镜像释放出来加载磁盘驱动然后才能去挂载真正的根分区。这也是为什么有时候你误删了initramfs文件比如/boot下的initramfs-xxx.img系统会直接启动失败提示找不到根设备。1.4 第四阶段systemd接管与默认目标内核完成初始化后会启动系统中的第一个进程——PID 1。在现代Linux世界里这个角色就是systemd。它同时也是所有其他进程的“老祖宗”。systemd通过并行启动各个服务单元来加速系统启动速度这也是它相对于老旧的SysV init的一个核心优势。systemd引进了“目标”的概念来替代传统的运行级别。常见的映射关系是默认运行级别对应关系运行级别systemd目标说明3multi-user.target多用户字符界面5graphical.target图形化界面的多用户模式0poweroff.target关机6reboot.target重启想查看当前默认的启动目标用systemctl get-default命令想修改用systemctl set-default multi-user.target。服务器一般建议直接设置成multi-user.target省掉图形界面占用的那部分内存开销也减少被攻击的面。1.5 第五阶段系统服务与初始化systemd根据默认目标开始启动依赖的服务。这里有两个问题需要特别注意。第一服务之间是有依赖关系的比如网络服务晚于网卡初始化NFS挂载要在网络就绪之后。systemd通过unit文件的Before、After、Wants等字段来控制启动顺序。第二也是最重要的服务之间是有依赖关系的比如网络服务晚于网卡初始化NFS挂载要在网络就绪之后。很多人一上来就抱怨“机器启动慢”却不去想为什么慢其实用systemd-analyze blame看看耗时排行往往能发现是某个服务在等待超时。一个很常见的坑系统里配置了某个网络文件系统挂载点但服务器启动时对端还没准备好systemd会等待网络挂载超时默认可能要90秒。这种故障表现为服务器启动极慢登录后一条“A start job is running for Wait for Network to be Configured”的日志。解决思路是让挂载服务不阻塞启动关键路径或者调整网络等待超时时间。1.6 最后阶段getty登录与用户空间所有服务都启动完成后systemd会启动getty服务也就是在终端上显示登录提示符。到这一步系统的启动流程才算真正走完。整个过程看下来从固件到内核再到用户空间层层接力任何一环掉了链子系统就会罢工。2. WEB工作原理揭开浏览器与服务器的互动面纱WEB服务是现在IT系统对外提供服务的绝对主力。哪怕你不是专职的运维只要跟服务器打交道总会遇到“网页打不开”“500错误”“502 Bad Gateway”这类问题。搞懂WEB工作原理基本上就拿到了排查这些问题的“万能钥匙”。2.1 HTTP协议的请求响应模型WEB服务的底层基础是HTTP协议。它的核心逻辑极其简单就是“请求—响应”模型。客户端通常是我们使用的浏览器发起一条HTTP请求服务器处理后返回一个HTTP响应。这意味着HTTP本身是无状态的服务器不会主动记着你上一次干了什么。所谓的会话保持、用户登录状态那都是通过Cookie、Session等额外机制在应用层面实现的。我们来看一个典型的请求报文的构成GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Accept: text/html Connection: keep-alive而浏览器的响应找服务端要数据服务端经过内部处理后返回给浏览器的内容就是响应报文第一行就是状态码。这也是运维日常打交道最多的东西在这里我把它整理成表格方便对照常见HTTP状态码速查状态码含义运维排查思路200请求成功正常无需处理301永久重定向常用于HTTP跳HTTPS检查站点配置302临时重定向常用于登录跳转关注服务端逻辑403禁止访问检查目录权限、防火墙、访问控制列表404页面不存在检查静态文件路径、伪静态规则500服务端内部错误查看后端程序日志大概率是代码或运行时异常502网关错误Nginx无法连接后端服务检查PHP-FPM或Tomcat死活503服务不可用服务器过载或正在维护504网关超时后端处理超时调大proxy_read_timeout2.2 从URL输入到页面呈现的完整链路这个过程其实是理解WEB工作原理最透彻的方式。当你在浏览器里输入一个网址比如http://www.example.com回车之后发生了什么我按自己的理解拆解一下首先浏览器要去查这个域名对应的IP地址。它先看本地浏览器缓存再看操作系统Hosts文件然后走系统配置的DNS服务器也就是本系列后面要单独讲的DNS解析。拿到IP后浏览器与服务器建立TCP连接。如果这个站点用的是HTTPS协议中间还会多一次TLS握手过程。紧接着浏览器发送HTTP请求报文经过互联网上的各种路由设备最终到达服务器的网卡。此时服务器上监听80端口HTTPS是443的WEB服务软件——Nginx或者Apache——接收到了这个请求。WEB服务软件解析请求报文根据配置的虚拟主机规则域名、端口和URI路径决定如何处理。它可能直接返回一个静态文件比如HTML、图片也可能通过FastCGI协议把请求转发给后端的动态处理程序比如PHP-FPM或者通过反向代理转发给Java应用容器。后端处理完把结果原路返回。WEB服务软件在响应中指定Content-Type加上内容长度等头信息然后通过网络传回浏览器。浏览器拿到响应后解析HTML文档发现里面还引用了CSS、JavaScript、图片等资源于是再次发起多个请求去获取这些资源最终渲染出完整的页面。你会感觉“打开网页很快”其实背后可能是几十个请求在并行工作。2.3 静态与动态请求的分离生产环境里我们很少让Nginx直接处理动态请求因为动态请求需要执行脚本、查询数据库响应慢并发能力受限于后端语言。所以典型的架构是Nginx处理静态资源比如图片、CSS、JS文件把这些高性能的工作让Nginx干而动态请求则通过代理转发给PHP-FPM或者Java应用的Tomcat。在配置Nginx时这个分离逻辑是通过location块实现的。比如location ~ \.php$ { root /usr/share/nginx/html; fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }这个配置把以.php结尾的请求转给PHP-FPM处理。这里有个容易踩坑的地方SCRIPT_FILENAME这个参数很多老教程写的是绝对路径比如/var/www/html$fastcgi_script_name如果你改了站点目录很容易因为参数不一致导致“白屏”或者File not found错误。我自己更推荐用$document_root$fastcgi_script_name这种动态写法它吃的是root指令定义的路径避免路径不一致的低级问题。2.4 常见的WEB架构演进从单机LNMP到集群架构WEB的原理是万变不离其宗。早期业务量小的时候一台服务器同时跑Nginx、PHP、MySQL简单直接。业务增长后WEB服务器和后端数据库分离。再往后为了扛住高并发增加多台WEB服务器前面挂一台负载均衡器对外统一提供服务。这里贴一段最常见的负载均衡配置思路upstream backend_servers { server 192.168.1.11:80 weight3 max_fails2 fail_timeout30s; server 192.168.1.12:80 weight3 max_fails2 fail_timeout30s; } server { listen 80; server_name www.example.com; location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }配置里给后端真实IP打了码主要是为了示意。这里务必牢记反向代理场景下后端的WEB日志默认记录的是负载均衡器的IP如果不设置proxy_set_header X-Forwarded-For你排查问题的时候会非常痛苦根本不知道真实的客户端IP来自哪里。3. DHCP工作原理让设备自动获取网络参数在网络管理里配置IP地址是基础中的基础。如果每台机器都靠人工静态配置几百上千台服务器工作量巨大且容易出错。于是DHCP协议横空出世它的核心功能就是“自动发地址”。我早年管过一段时间办公网几百号人的电脑IP冲突、断网、分错VLAN的事儿时有发生后来把DHCP服务理顺了省了太多事儿。3.1 DHCP的四种报文交互流程DHCP是基于UDP协议工作的。它的工作流程可以浓缩成四个关键阶段通常概括为DORA发现阶段客户端在网络上广播发送DHCP Discover报文因为此时它连IP地址都没有只能用广播去寻找网络里的DHCP服务器。提供阶段DHCP服务器收到Discover后在自己维护的地址池里挑一个可用IP单播或广播回一个DHCP Offer报文其中包含IP地址、子网掩码、网关、租期等信息。选择阶段客户端收到Offer后广播发送DHCP Request报文明确表示“我要选择这个IP”。之所以用广播是为了让网络中其他DHCP服务器也能收到消息从而释放它们预留的地址。确认阶段DHCP服务器收到Request后确认分配成功广播回复DHCP ACK报文。客户端收到ACK后把IP地址正式绑定到网卡上就可以正常通信了。3.2 租约机制与续租过程DHCP分配的IP地址并不是永久有效的而是有“租约”的概念。这个设计相当精巧它保证了IP地址能被回收和复用避免设备长期占用稀缺的IP资源。默认租期一般是86400秒一天。客户端在租期过半时也就是约12小时后会尝试向DHCP服务器单播发送Request报文请求续租。如果服务器同意就回复ACK租约会重新计算如果服务器没回应客户端在租期第七个八分之一时段再试一次以此类推一旦失败到某个阈值仍没续租成功客户端就会放弃这个IP重新走一遍DORA流程去请求新的地址。3.3 核心配置文件与常见坑主流的DHCP服务端软件是dhcpd或者Kea在CentOS上就是dhcp包。配置文件路径在/etc/dhcp/dhcpd.conf。一个最基本的内网配置长这样subnet 192.168.10.0 netmask 255.255.255.0 { range 192.168.10.100 192.168.10.200; option routers 192.168.10.1; option domain-name-servers 192.168.10.1, 223.5.5.5; option domain-name example.local; default-lease-time 600; max-lease-time 7200; }这里需要注意配置文件里非常容易遗漏的是option routers这行。有些同事配了半天客户端确实能拿到IP了但发现上不了网、跨网段都通不了多半就是网关没下发下去。还有另外一个非常隐蔽的坑如果网段里存在多个DHCP服务器比如有同事临时搭了个测试环境忘了关DHCP服务就很容易导致部分客户端获取到错误的IP设置表现是时通时断、IP地址跟规划对不上。这种问题排查起来极其恶心需要在交换机上开DHCP Snooping或者在客户机上抓包看Offer来源得罪人的活儿。3.4 地址保留与固定分配某些特殊设备比如网络打印机、考勤机、或者公司内网服务器它们的IP地址需要固定下来又不能去设备上手动配置。这时候可以在DHCP配置里做静态绑定原理就是借网卡MAC地址做一对一映射host printer1 { hardware ethernet 00:16:3E:12:34:56; fixed-address 192.168.10.88; }配置好重启服务后这台打印机无论什么时候获取IP都会拿到192.168.10.88。这比手动去设备上配IP灵活得多后续如果要统一调整网段只在DHCP服务器上改一下就行不需要跑遍全公司一台台改。4. DNS解析原理互联网世界的通讯录如果DHCP解决的是“网络参数怎么发”的问题那DNS解决的就是“名字怎么变成IP”的问题。对于运维来说DNS的排错几乎是最常见的活儿。很多“莫名其妙”的故障追根溯源最后都落在DNS上。4.1 域名解析的完整递归流程以解析www.example.com这个域名为例。客户端发起解析请求时首先检查自己的hosts文件然后看本地DNS缓存如果都没有就向配置的本地DNS服务器发起查询。如果本地DNS服务器自己没有缓存它会代替客户端去递归查询先向全球13个根DNS服务器中的某一个问“.com的顶级域服务器在哪里”拿到顶级域服务器地址后再问“example.com的权威服务器在哪里”最终找到example.com的权威DNS服务器从中拿到www这个主机记录对应的IP然后逐级返回给客户端。整个链条就是不停地“往上问、往下查”的过程。这个流程里有个概念要分清本地DNS服务器替客户端做完整个查询过程并返回结果这叫递归查询而根服务器指引本地DNS服务器去找下一步该问谁这叫迭代查询。从客户端的角度看它只向本地DNS服务器发了一个请求。4.2 记录类型与主要配置文件DNS服务器上存储着各种记录运维日常接触比较多的有这几种常用DNS记录对照记录类型含义使用场景A将域名指向IPv4地址www.example.com → 1.2.3.4AAAA将域名指向IPv6地址用于IPv6环境CNAME域名别名让多个名字指向同一个目标MX邮件交换记录指定邮件服务器NS域名服务器记录指定由哪台DNS服务器负责解析TXT文本记录常用于验证域名归属、SPF反垃圾邮件当然要强调的是A、AAAA、CNAME、MX、NS这类记录是我日常工作里最常用的。在主流的BIND配置里一个正向解析区域文件的片段长这样$TTL 86400 IN SOA ns1.example.com. admin.example.com. ( 2024051201 ; serial 3600 ; refresh 1800 ; retry 604800 ; expire 86400 ) ; minimum IN NS ns1.example.com. IN A 192.168.10.5 www IN A 192.168.10.100 mail IN A 192.168.10.5 IN MX 10 mail.example.com.每个域名的管理都基于SOA记录串行号递增。4.3 视图与智能DNS大型公司内外网常使用不同的DNS解析策略。例如内网用户访问某个域名得到内网地址外网用户访问得到公网地址原理在于BIND的视图功能。在named.conf里可以配置多个view每个view匹配不同的客户端来源网段view internal { match-clients { 192.168.0.0/16; }; recursion yes; zone example.com { type master; file example.com.internal; }; }; view external { match-clients { any; }; recursion no; zone example.com { type master; file example.com.external; }; };之前就有一次情况我们把某个域名解析配置改了结果发现内网用户体验不正常、外网却正常。后来排查半天才确定是视图配置里内网段的match-clients写错了位置导致内网用户匹配到了外部视图。凡是涉及多视图的改配置时必须慎之又慎改之前先确认当前生效的是哪个视角的文件。4.4 排查DNS问题的经典套路遇到“能上QQ但网页打不开”这种经典故障我通常会按这个顺序排查先用nslookup或者dig命令去解析目标域名确认是不是解析出了问题然后检查客户端配置的DNS服务器是否能通有时候网络正常但DNS指向错了网关的地址解析自然失败再用dig 指定服务器看权威应答是否正常这一步能区分“本地DNS缓存污染”还是“源头解析错误”最后如果怀疑是本地DNS服务器的问题会去检查named进程日志和缓存情况。这里分享一个实用小技巧很多系统里的web应用会缓存DNS解析结果Java虚拟机默认对DNS记录有缓存可能长达24小时甚至更久。所以在一次域名迁移IP后客户端报错“域名解析不了”但服务端明明正常。这时需要在JVM参数里加上-Dsun.net.inetaddr.ttl30来缩短缓存时间方便快速生效不然就只能干等缓存过期了。5. NFS网络文件系统跨平台共享存储的基础方案NFS是Linux/Unix世界里老牌的网络文件系统协议。它的核心设计目标就是让客户端把远程服务器上的目录像使用本地目录一样来使用。我最早接触NFS是在搭建集群环境的时候需要把多个节点的工作目录、软件包目录统一共享出来NFS就是最简单直接的方案。5.1 NFS与RPC的协作机制NFS本身的设计相对复杂它并不是一个独立的服务而是构建在远程过程调用协议之上。RPC负责实现“客户端调用远程服务器上的函数就像调用本地函数一样”这个机制。所以我们在部署NFS服务端时除了安装nfs-utils还要确保rpcbind服务处于运行状态。NFS服务端正常启动后会随机为一些子功能分配端口比如mountd可能用随机端口nfsd本身固定2049端口。而rpcbind的职责就是充当“端口注册中心”客户端首先连接服务器的rpcbind端口111查询某个NFS功能当前用的端口号然后再建立数据连接。这也是为什么在防火墙配置里除了放行2049端口还要放行rpcbind的111端口以及一些随机端口否则当客户端执行showmount、mount时就会出现“RPC超时”之类的报错。5.2 服务端配置与参数解析服务端的核心配置是/etc/exports文件。每一行定义“要共享的目录 允许访问的客户端及权限选项”。来一个典型的例子/data/share 192.168.10.0/24(rw,sync,no_root_squash) 172.16.0.0/16(ro,sync)这里rw表示读写ro是只读sync表示数据同步写入磁盘。还有一个重要参数是no_root_squash这个参数决定当客户端以root身份访问时映射为服务端的root权限还是匿名用户权限。在实际生产环境里我一般很少用no_root_squash因为它的安全隐患很大——客户端root可以直接改服务端共享目录里的任何文件及其权限。默认的root_squash把它压制成匿名用户权限能有效降低风险。修改完exports文件后用exportfs -arv让配置即时生效。这个命令会重新读取exports文件并增量更新导出列表不需要重启整个NFS服务切换无感。5.3 客户端挂载与自动挂载客户端挂载NFS目录的命令很直观mount -t nfs 192.168.10.5:/data/share /mnt/data这里面有一个重要的挂载选项需要单独拿出来说那就是版本号。NFS协议的版本从v3到v4再到v4.2在挂载时可以显式指定mount -t nfs -o nfsvers4,hard,intr 192.168.10.5:/data/share /mnt/data生产环境里我更推荐在/etc/fstab中配置自动挂载。但NFS挂载有一个天然难题如果你直接写在fstab里开机时网络可能还没就绪导致挂载失败。所以通常要加上_netdev选项告诉系统在网络服务就绪后再尝试挂载192.168.10.5:/data/share /mnt/data nfs4 _netdev,defaults 0 05.4 性能与一致性经验NFS的坑在于多客户端并发写同一个文件时可能出现数据不一致或者文件锁冲突的情况。这需要在应用层面设计好比如日志类数据按主机名分目录写入而不是大家同时写单个文件。此外NFS在高并发下性能瓶颈一般在服务端磁盘。如果客户端数量很大建议服务端用SSD并启用sync参数保证数据可靠性。还有一个常见故障是客户端执行df -h时卡住。这种情况通常是因为NFS服务端宕机或网络中断而客户端挂载选项里用了hard模式导致进程在等待IO响应。排查思路是先尝试umount如果umount也卡住可能需要加-f强制卸载。更麻烦的是umount -f也失败时这类情况往往只能重启客户端所以运维生产环境时NFS服务端的稳定性和网络其实是最关键的。6. FTP文件传输协议经典文件交换方案在HTTP还没这么普及的年代FTP是互联网上文件传输的主力。即便在今天一些内网环境、旧系统的数据交换场景依然大量使用FTP。运行它的服务端软件最常见的有vsftpd和ProFTPD。我维护的几台“老古董”服务器至今还在跑着vsftpd给业务系统传数据文件用。6.1 FTP的两种工作模式辨析FTP协议最让初学者困惑的就是它有两套连接一套是控制连接默认监听21端口用来传输命令和响应另一套是数据连接用来传输真正的文件内容。这就决定了FTP比HTTP复杂得多。数据连接的建立有两种模式主动模式PORT和被动模式PASV。主动模式下客户端在控制连接上告诉服务器“我开放某个端口等你来连”然后服务器主动去连接客户端的那个端口。问题来了如果客户端在内网服务器无法主动连接到它主动模式直接失败。被动模式下则相反服务器开放一个随机端口告诉客户端“你来连接我吧”由客户端发起数据连接。因为被动模式更适应有防火墙和NAT的现代网络日常基本都用它。在vsftpd中需要做相应配置pasv_enableYES pasv_min_port30000 pasv_max_port31000这段配置一定要和防火墙规则配套使用。我就遇到过这样的情况FTP登录正常也能看到文件列表但一执行get命令下载就卡死看服务端日志发现是PASV模式使用的随机端口被防火墙拦住了。后来在防火墙上放行了30000-31000这个区间问题立刻消失。6.2 虚拟用户与权限隔离FTP本身依赖于操作系统的系统用户来认证。但如果给每个需要FTP业务的人开设系统账号一是账号管理混乱二是安全风险大至少本着最小权限原则来说都不太好。更合理的做法是用虚拟用户来隔离。以vsftpd为例配置虚拟用户需要叠加上PAM认证模块# 创建虚拟用户数据库文件里面每两行为一组“用户名/密码” vi /etc/vsftpd/vuser.txt user1 password1 user2 password2 # 使用db_load命令生成db数据库文件 db_load -T -t hash -f /etc/vsftpd/vuser.txt /etc/vsftpd/vuser.db然后修改vsftpd.conf指定PAM服务和用户配置目录。虚拟用户还可以通过guest_username参数映射成某个本地用户比如ftpuser文件就放在它的家目录里。这种模式的好处是灵活每个虚拟用户可以有自己的目录和权限配置而且不占用系统登录权限比开一堆系统账号安全得多。6.3 与SFTP的选择必须提醒一下FTP在各云厂商和大型互联网公司已经越来越不受待见因为它的密码和文件内容默认都是明文传输非常容易被抓包窃取。现在更推荐的是SFTP——它并是“FTP的安全版”而是基于SSH协议的文件传输服务天然加密、传输走SSH的22端口。客户端却可以直接用习惯了FTP的工具比如WinSCP、Xshell内置的文件传输连接SFTP几乎是无缝衔接。所以除非遇到那种老的不支持SSH的设备或者有强制合规要求的内网系统我一般都建议能用SFTP就用SFTP。FTP的地位目前主要残存在很多遗留系统和特定业务里新项目尽量不要用。6.4 限速与带宽控制生产环境中FTP经常承担批量文件分发任务。如果不对传输速度做限制可能会把带宽全部吃满影响其他业务。vsftpd里可以使用限速指令max_clients50 max_per_ip5 local_max_rate1000000 anon_max_rate200000local_max_rate以字节/秒为单位1000000就是约1MB/s的限速。实际项目中如果同时有几十个客户端在拉取大文件限速就显得尤为重要不然带宽被burst吃满丢包频繁不光FTP慢其他业务也跟着遭殃。7. PXEKickstart自动安装系统批量部署的终极方案最后一个大佬也是我觉得整个Linux运维里最“爽”的一块——PXEKickstart自动安装系统。想想看几十上百台新服务器到货如果要一台台用U盘装系统、然后手动做各种初始化配置光是想想就头皮发麻。用自动装机整个过程只需要选择好模板服务器开机就能自动完成装系统算是这边性价比很高的制度设计。7.1 PXE的工作原理解析预启动执行环境。“预启动”的意思就是“在操作系统启动之前”。支持PXE的网卡在BIOS/UEFI启动阶段如果被配置为网络启动优先网卡就会向网络广播一个DHCP Discover报文但这个报文的特殊之处在于它还携带了PXE客户端的标识。DHCP服务器收到后除了分配IP地址还会额外返回两个关键参数引导服务器地址和启动文件名。也就是说客户端不仅知道自己用什么IP还知道该去哪台TFTP服务器下载启动程序。这个启动程序就是我们常说的PXE引导文件。7.2 搭建自动装机环境DHCPTFTPHTTP/NFS搭建整个PXE服务环境轻车熟路的流程大致是一台服务器上同时配置DHCP、TFTP、HTTP或NFS服务。架构涉及的关键组件与配置如下TFTP服务器用来提供引导文件比如pxelinux.0、内核vmlinuz、initrd.img以及GRUB2的配置文件。TFTP虽然古老且效率不高但PXE协议层面就是基于这种简单文件传输协议来拉取启动阶段文件的。DHCP服务器在dhcpd.conf里需要额外配置subnet 192.168.20.0 netmask 255.255.255.0 { range 192.168.20.100 192.168.20.200; option routers 192.168.20.1; next-server 192.168.20.10; filename pxelinux.0; }next-server告诉客户端TFTP服务器的地址filename指定要下载的引导文件名。这个是PXE装机能否成功的第一步很多“开机找不到启动文件”多半就出在这个配置上。HTTP服务则用来存放系统的安装树和Kickstart配置文件供安装程序Anaconda在安装过程中通过网络去获取软件包。相比早期用NFS来提供安装文件HTTP的兼容性和速度都好不少也更符合现在的使用习惯。7.3 Kickstart应答文件的核心结构Kickstart的核心价值在于它把Anaconda交互式提问的步骤全部用文件预先回答了。服务器启动进入安装程序后读取这个应答文件就可以全程无人工干预地完成分区、语言、时区、软件包选择、root密码设置等一系列操作。一个精简的Kickstart文件ks.cfg可以长这样# 安装源 url --urlhttp://192.168.20.10/centos/ # 语言与时区 lang en_US.UTF-8 keyboard us timezone Asia/Shanghai --isUtc # root密码使用grub-crypt或openssl生成哈希 rootpw --iscrypted $6$xxx... # 分区方案 zerombr clearpart --all --initlabel autopart --typelvm # 网络配置 network --bootprotodhcp --deviceeth0 --onbootyes # 安装的软件包 %packages core vim-enhanced net-tools %end # 安装完成后的执行脚本 %post echo nameserver 192.168.20.10 /etc/resolv.conf %end需要当心的是rootpw那一行明文密码在kickstart文件里会有很大的安全隐患。因为整个PXE局域网内都是明文TFTP和HTTP通信别人很容易把ks文件抓下来看到密码哈希。建议使用加密哈希并且把ks文件放在HTTP服务器上配合访问控制而不是放在NFS那种完全可读的共享里。7.4 装机后的自动化扩展%post脚本Kickstart真正威力强大的地方在于它的%post脚本功能。这个脚本在系统安装完成后、重启之前执行意味着你可以在这时候完成一切初始化动作比如设置主机名、安装监控Agent、配置YUM仓库、创建运维用户、部署SSH密钥、甚至直接执行某些业务初始化脚本。举个例子可以用下面这种方式在系统装好后立即完成基础配置%post --log/root/post_install.log echo HOSTNAMEweb-$(hostname) /etc/sysconfig/network useradd -m opsadmin mkdir -p /home/opsadmin/.ssh echo ssh-rsa AAAA... /home/opsadmin/.ssh/authorized_keys chown -R opsadmin:opsadmin /home/opsadmin/.ssh chmod 700 /home/opsadmin/.ssh chmod 600 /home/opsadmin/.ssh/authorized_keys systemctl disable firewalld %end这样新上架的机器从开机到“裸奔可交付”整个过程我们只需要做一件事看着它启动。装完后主机名虽然是默认的但通过脚本里逻辑去改就能做到批量环境中每台机器的个性化。7.5 PXE部署中常见的翻车现场每年帮人解决PXE装不上系统的需求高频踩坑点其实就那么几个。第一是防火墙TFTP服务默认开放69端口但TFTP的数据传输有时会使用随机端口如果防火墙策略过严引导文件下载就会失败。建议把PXE部署环境先放在一个安全网段关掉防火墙来排除这个因素。第二是SELinux如果TFTP服务没有配置对应的SELinux布尔值也会导致文件读取被拒通常需要setsebool -P tftp_home_dir 1。第三是syslinux版本与UEFI兼容性传统BIOS用pxelinux.0没问题但UEFI机器需要shim.efi或者grubx64.efi拿错引导文件会直接启动失败。每次部署新环境我都会先确认好客户机的固件类型再去准备引导文件省得在现场折腾半天。8. 这些知识如何串联起来写到这里回头看看Linux运维这套核心知识的内部关系。从全局来看系统启动过程是“地基”WEB工作原理是业务窗口DHCP是自动化的网络基石DNS是流量的入口调度NFS和FTP是数据流转的生命线PXEKickstart则是把这些环节前期化、规模化、“交付即标准”的最终解决方案。这里单从业务场景来串一遍一台全新的裸机通过PXEKickstart完成了系统安装网络通过DHCP拿到了合法的IP配置DNS让它能被人用域名找到NFS让它能挂载共享存储WEB服务对外提供业务FTP让业务数据能批量流进流出。一套完整的系统闭环就这么形成了。在排查问题的时候我习惯先理清“请求流向谁”“数据经过哪里”“哪一环最可能出问题”再动手。比如用户反馈某个内网站点很慢我至少会去看DNS解析是否走了“冤枉路”WEB服务器到后端数据库的链路是否拥堵以及NFS共享是否存在IO瓶颈。运维排错的整体思维不是“我不会查这个命令”而是“我知道用户请求的整个链路我能一步一步找瓶颈”。9. 给运维新手的几句实在话如果你还在学习阶段有几点建议可能会对你有帮助。强烈建议自己在虚拟机里搭一套实验环境亲手去安装一次CentOS/Rocky看它启动时的每一步输出亲手配一次DHCP和DNS用Kickstart自动装一台虚拟机。这些东西只看文档或者视频印象不会深踩过坑才能真正内化成经验。每个服务不要只看配置文件要懂得看日志。NFS的日志在/var/log/messagesFTP的vsftpd日志在/var/log/xferlogDNS的named日志可能在/var/log/messages里或者需要单独配置。排错绕不开日志应该把它当成第一依赖。保持记录文档的习惯。我早年踩过的每个坑都会记在自己的运维笔记里。很多在当时看起来“浪费时间的记录”后来在公司出现第二次甚至第三次同类问题时直接翻出来缩小排查范围效果很不错。这也是我为什么愿意把“系统启动、WEB、DHCP、DNS、NFS、FTP、PXE”这些内容整理成文的原因这是一个运维人员的基本功也是后续进阶分布式、容器化、云原生时绕不开的底子。地基打不牢楼盖得越高越危险。以后有机会再把Kubernetes、容器网络、监控告警这些进阶内容也整理出来。运维这条路没有天花板但只要把这些基础吃透后面遇到新东西会轻松很多。