简介围绕 CentOS 6.3 系统主题的网页源码包基于一套名为 mobilyblocks 的前端框架制作面向需要快速搭建系统介绍、版本说明或技术博客站点的开发运维人员。压缩包为 RAR 格式共计 19 个文件其中以 14 张 PNG 图片为主要视觉资源另有 3 个 JavaScript 脚本、1 个 CSS 样式表和 1 个 HTML 入口页面整套资源仅 244KB体积小巧、结构清楚。资源内部划分出主页、图片、社交链接、脚本与样式等模块方便用户按需替换内容或二次开发。目前已有 514 人学习下载。通过这套源码读者可以直接得到一份可运行的页面框架修改文字与图片即可用于 CentOS 6.3 相关分享同时也能了解前端开发中 HTML、CSS、JavaScript 与图片资源的组织方式对在 Linux 环境下进行页面调试和快速部署很有帮助也能节省从零编写页面的时间。无论是用于个人学习笔记整理还是团队内部知识库展示都较为合适。 2013年夏天我从前同事手里接过一台跑着CentOS 6.3的服务器。那是一台老旧的PowerEdge装着一套内部业务系统没人说得清当年是谁装的、怎么装的只知道别乱动动了会出问题。接手之后我做了个完整检查结果发现swap分区是0yum源全是失效链接防火墙iptables默认全放行。从那时候起我就和这个版本代号较上了劲。CentOS 6.3在当年的定位非常明确RHEL 6.3的社区重新构建版内核2.6.32glibc 2.12GCC 4.4.7Python 2.6.6。这套组合在2012年是主流到2020年11月底官方彻底停止维护时它已经生存了八年多。今天这篇东西不是劝你这都什么年代了还碰老古董恰恰相反到现在仍有不少内网机器、工控主机、老业务数据库跑在这类系统上。写给正在维护存量系统的朋友也写给第一次接触这个老版本、对着黑屏不知所措的新人。1. CentOS 6.3当初凭什么站稳脚跟1.1 2012年前后的服务器生态把时间拨回2012年那时候的服务器市场不像现在这样群雄并起。Windows Server还在一代代迭代Ubuntu在桌面端闹得欢但在服务器上还偏极客而企业级生产环境里选择其实不多。CentOS在当时最大的卖点就是你不需要买红帽的服务订阅却能得到和RHEL完全同源的操作系统。稳定、可预测、支持周期长对企业来说这三个词就是钱。CentOS 6.3并不是6.x系列的起点但它是当时社区在6.x周期里一个承上启下的关键版本。它默认使用ext4文件系统支持ext4作为根文件系统的默认选择取代了5系列时代ext3的老规矩。同时LVM2已经非常成熟整块磁盘做LVM逻辑卷成了标准做法。对于维护者来说这意味着以后调整分区大小不需要再对着fdisk发愁。从网络协议栈角度看2.6.32内核本身是2009年发布的长期稳定分支红帽将其不断backport更新到6.3版本所以在2012年拿出这台系统时它对新硬件、新协议的支持虽然比上游主线激进版本慢半拍但胜在稳定。生产服务器最怕的不就是新功能没用到先被新bug教做人1.2 CentOS 6.3的产品定位和关键指标这个版本在产品线上扮演的角色简单说就是够用且安全的中间力量。CentOS 6系列从6.0到6.10走过了漫长的道路。6.3处于6.2和6.4之间它在虚拟化、文件系统、电源管理上都做了不少增强但最核心的还是对x86_64架构的全面普及。6.0时代你还会认真考虑装32位版本到6.364位基本是标配。几个关键指标我列一下内核版本2.6.32-279这是6.3初始发行版的kernel基线glibc版本2.12GCC版本4.4.7Python版本2.6.6注意连2.7都不是OpenSSL版本1.0.1e已支持TLS 1.1和TLS 1.2默认文件系统ext4支持XFS但非默认这套配置放在今天看确实老态龙钟但在2012年它正好命中了一个巨大的存量市场需求企业内网、Web托管、数据库服务器、OA/ERP系统。换句话说CentOS 6.3吃到了国内互联网快速扩张的红利大量早期部署的业务系统到今天还存在。2. 装CentOS 6.3时最值得留意的三个决定2.1 位数和内核的选择我见过很多早期装机器的人因为服务器内存只有2G或4G顺手选了i386版本。这在当时不算错但后来业务一扩容内存加到8G、16G32位内核单个进程最多只能用到约3G用户空间直接卡死。如果现在你还要在虚拟机里装一个CentOS 6.3做测试或复现旧环境别犹豫直接选x86_64。选64位之后kernel-PAE这种词就不用管了那是32位下的补丁玩法。同时要注意CentOS 6.3在虚拟机里安装时如果虚拟机CPU模型太新安装内核可能会报Kernel requires an x86-64 CPU之类的错不是系统坏了是虚拟化层把CPU特性隐藏了。我遇到这种问题通常会在虚拟机的CPU配置里把启用Nested Virtualization或者CPU模型调成兼容模式再不行就换VMware的Intel VT-x/EPT设置而不是怀疑镜像文件损坏。2.2 磁盘分区与LVM规划Anaconda安装器里进入分区界面时很多人习惯一键自动分区这个习惯在CentOS 6.3年代可以接受但如果让我现在重新规划我会手动做一套LVM方案。我的典型规划是这样按100G数据盘举例挂载点建议大小文件系统说明/boot200Mext4引导文件不需要LVMswap与内存1倍~2倍swap老系统swap别省OOM后用swap能续命/20Gext4LVM根分区预留系统日志和软件安装空间/data剩余全部ext4LVM业务数据单独放备份和快照方便为什么/boot不用LVM因为老版本GRUB对LVM的识别能力有限一旦/boot放进LVM里grub-install阶段容易出诡异问题。我见过不止一次因为把/boot塞进LVM导致开机进不了系统最后只能用rescue模式救。这是一个典型的当时多省了一步事后多花三个小时的教训。还有一点CentOS 6.3的Anaconda在分区界面支持创建分区时填写预期大小但你要留一个概念LVM逻辑卷在扩容时要保证卷组里有剩余空间。所以建LV时不要在VG满打满算比如整块VG 80G/根分区先用20G剩下的留给/data这样以后想扩其他目录都还有余地。2.3 软件包选择最小化安装原则安装过程中会让你选软件包组这是最容易被新手忽略的步骤。CentOS 6.3默认组里有Desktop、Minimal Desktop、Minimal等一堆选项。早期的运维朋友很喜欢选Desktop或者Server with GUI因为怕不会用命令行。但在服务器上没有图形界面反而省心。我建议只选Minimal最小化安装。这样装完以后系统只有不到400个包干净、页面响应快、攻击面小。后面需要什么服务yum再单独装。有一个实际的好处是很多老版本盲装时经常出现图形界面相关的依赖冲突走了Minimal之后这类问题一了百了。不过这里有个小坑Minimal安装默认不带ifconfig、wget、vim这些工具。所以装完第一件事就是yum install -y net-tools wget vim-enhanced否则你会发现连ip地址都不方便查。如果yum源也没配好那就会陷入一种没有工具没法装工具的哲学困境。所以顺序一定是先配yum源再装基础工具。3. 装完系统后的基础配置直接影响运维成本3.1 yum源的配置和仓库选择CentOS 6.3的yum源官方默认走mirrorlist到2020年EOL之后官方mirror自然就消失了。如果你现在想装必须把yum源手动改成归档源或国内镜像站的vault目录。在/etc/yum.repos.d/CentOS-Base.repo里把baseurl指向归档目录并把mirrorlist注释掉。归档源在网上有比如vault.centos.org国内的阿里云也有对旧版本的归档目录。这里有个操作细节改完之后先跑一下yum clean all再yum makecache。老机器上makecache可能很慢如果出现超时可以把yum.conf里的timeout调大比如timeout30。除了Base源另一个值得配的是EPEL源。CentOS 6.3的自带仓库软件版本都比较旧比如nginx没有redis也没有很多新一点的工具都在EPEL里。但要注意CentOS 6上的EPEL也停更了需要从archive里单独找epel-release-6-8.noarch.rpm这类老包。还有一组仓库是CentOS 6时代很多人会配的Remi仓库、RPMForge、RPMFusion。我的实际经验是不要贪多。仓库配得越多依赖冲突的概率越大。尤其是Remi这个PHP仓库它提供的PHP版本比系统自带的5.3新很多但风险也高一旦你不想用了卸载会牵连一堆包。主用Base加EPEL个别包手动编译是我最后沉淀下来的稳定方案。3.2 SSH与防火墙的初始加固CentOS 6.3上SSH默认是OpenSSH 5.3它支持的算法在今天看来很陈旧比如默认的HostKey里有ssh-dssDSA算法新版OpenSSH客户端默认已经禁用了。如果你在一台新电脑上用ssh登录老服务器报no matching key exchange method found之类的错误不是密码错了是密钥交换算法对不上。我的经验是在服务端/etc/ssh/sshd_config里加三行历史兼容配置Ciphers aes128-ctr,aes192-ctr,aes256-ctr MACs hmac-sha1,hmac-sha2-256,hmac-sha2-512 KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1这样新版本ssh客户端才能正常连上来。注意修改前先备份sshd_config改完跑service sshd restart之前一定要先另开一个连接窗口测试不然旧连接一断新连接又进不去你就只能在机房门口吹风了。防火墙上CentOS 6.3还是iptables不是firewalld。配置规则用命令行直接敲的有效时间是当前会话想持久化要service iptables save它会写入/etc/sysconfig/iptables。我习惯初始规则就三件事开SSH端口、开业务端口、其他全拒。iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -P INPUT DROP service iptables save这里要提醒一件事别上来就-A先把默认策略搞清楚。-P INPUT DROP之后如果你忘了加允许回包的那条规则容易把已经建立的连接断掉。3.3 内核参数与文件句柄调整CentOS 6.3默认的文件句柄限制是1024对于Web服务来说太低了。改文件句柄不是只改ulimit/etc/security/limits.conf里要加* soft nofile 65535 * hard nofile 65535但注意CentOS 6.This系统里SSH登录的会话默认不加载PAM limits如果改完不生效要检查/etc/pam.d/login和/etc/pam.d/sshd里是否包含了pam_limits.so那一行。内核参数方面TCP连接重用那三条至今仍然有效net.ipv4.ip_local_port_range可以扩大到1024-65000net.core.somaxconn调大net.ipv4.tcp_max_syn_backlog调大。有一个坑当年很多人喜欢开net.ipv4.tcp_tw_recycle1在NAT环境下这会造成随机丢包你在老系统上调优时尽量避免它。文件系统层面我建议把atime关掉在/etc/fstab的挂载参数里加上noatime。这是个老技巧减少每次读取文件时的元数据写入尤其适合那些大量读操作的业务。4. 在CentOS 6.3上跑业务遇到的兼容性问题4.1 Web服务端PHP/MySQL组合发行版自带的PHP是5.3.3MySQL是5.1/5.5。2012年这是一套黄金组合今天再回头看PHP 5.3的很多函数已经废弃mysql扩展注意不是mysqli也不是PDO在PHP 7里被整个删掉了。如果你负责的老系统还是用mysql_connect写的那在CentOS 6.3上反而能跑因为整套环境就是为它量身定做的。但如果你想在CentOS 6.3上装个比较新的PHP比如PHP 5.6就得使用第三方仓库或自己编译。我自己编译过一次PHP 5.6.40这是5.6系列最终版编译前要解决一堆依赖libxml2-devel、openssl-devel、curl-devel、gd-devel这些都得yum装好。有个坑是libcurl版本太老安装新版PHP扩展时可能报错curl版本过低解决办法是编译curl或升级到EPEL的curl版本。MySQL方面CentOS 6.3装MySQL 5.5还是5.1取决于你用的发行版ISO和仓库状态。默认Base仓库里是mysql和mysql-server版本5.1针对老内核优化过InnoDB引擎在5.1的表现和5.5相比差距明显5.5对多核和扩展性的支持更强。所以我建议如果业务允许尽量升级MySQL 5.5。4.2 老编译链带来的软件安装难题这是我在CentOS 6.3上最头疼的部分。GCC 4.4.7和glibc 2.12的组合导致很多新版本软件没法直接编译典型问题是undefined reference to...或者GLIBC_2.14 not found。出现GLIBC_2.14 not found是因为程序编译时依赖了新版glibc但系统里只有2.12。遇到这个情况很多人第一反应是升级glibc这非常危险。glibc是系统最底层组件版本不对可能导致所有命令都无法运行ssh都进不去系统直接变砖。我绝对不会在CentOS 6.3上贸然升级glibc尤其生产环境。针对老系统的软件安装我总结出一套优先二进制其次老版本源码最后才考虑工具链的策略优先用yum装发行版仓库里的老版本软件如果必须上新版先检查对方是否提供rpm包编译前认真看README里的版本要求很多项目明确写了仅支持glibc 2.14对新版软件真的需要就考虑容器化用Docker跑新版软件把系统隔离出去有一种场景是内网无法拉取外部环境这时你需要在同版本系统上先配好依赖环境再把软件包批量拷贝到目标机器。CentOS 6.3的依赖关系比新版要简单但也更容易因为个别依赖缺失导致安装中断。我习惯在准备环境时先用yumdownloader把rpm包全拉下来再通过本地目录安装免得一台一台去解决网络问题。4.3 老内核的稳定与局限CentOS 6.3的内核虽然版本号是2.6.32但红帽做了大量backport很多新特性实际上已经包含在内只是不强制执行。它的稳定是经过无数生产环境验证过的。我见过这台内核在裸机上连续运行四五年没重启过的场景swap不到10%负载长期平稳确实有老前辈的风骨。但它也有明显的局限性。首先是对新硬件支持非常差。NVMe固态、新一代网卡、高性能GPU这类设备在2.6.32上要么没驱动要么无法发挥性能。其次是文件系统层面的限制ext4在CentOS 6.3上建议单文件不超过16T如果你有大容量存储需求得单独评估而XFS在2.6.32上的支持虽然存在但不像后来RHEL 7上那样成熟。还有内核的TCP/IP栈在极高并发下它的性能和现代内核有明显差距。我在一台CentOS 6.3上压测过一个Nginx服务并发升到8000左右时出现大量time_wait占用后来调整了ip_local_port_range和tw_reuse参数勉强能撑住一万并发但在同样的物理机上升级到新系统后不调优就能超过这个数字。老内核被时代淘汰原因不是稳定性而是性能增长停滞和硬件兼容跟不上。5. EOL之后的老系统我总结的维护与迁移经验5.1 系统EOL不等于业务马上崩2020年11月30日CentOS 6所有版本正式EOL。但EOL只代表官方不再发布安全补丁不代表你在跑的业务系统会立刻出问题。很多人一听到EOL就焦虑其实真正需要担心的是那些依赖公网、暴露在攻击面上的服务器。如果系统在隔离的内网里业务又一直稳定运行那就没必要为了追新而强行迁移。不过你可以做的是确认yum源已切到归档配置中清掉那些失效的mirrorlist避免每次跑yum都卡半天。然后做一次完整镜像备份。我建议至少保留一份系统盘和一份数据盘的快照放异地或独立存储上。老系统就像老仓库平时刻意维护不多真出事时备份就是你最后一根救命稻草。5.2 没有官方补丁时的替代加固方案EOL之后补丁没了但加固思路还能跟上。外部访问不到的部分靠网络隔离必须暴露的部分加前置防护。比如Nginx前面套一层云WAF或安全组数据库不直接对全网开放只允许内网网段连接。越是不更新补丁的系统越要在网络架构层面把攻击面缩小。日志监控也得更勤快。Syslog、/var/log/messages、/var/log/secure这些日志建议直接转发到远程日志中心别留在本地万一被入侵者清理了还能从远端查。文件完整性监控如果有条件可以做例如给bin目录和/etc目录定期做校验和比对发现异常及时报警。没必要再去折腾杀毒软件毕竟商业版杀毒根本不支持2.6.32。把精力放在最小化开放端口、最小化账户权限、定期review访问控制上收益更大。5.3 从6.3迁移出去的现实路径如果你终于决定让老系统退休迁移过程别搞一步到位的浪漫主义。现实中我见到比较稳的迁移路径是这样先在虚拟机里起一台和目标业务匹配的新系统比如Rocky Linux或AlmaLinux在老系统上导出现有配置包括nginx/apache配置、MySQL数据导出、计划任务crontab、环境变量等逐项保存新系统安装完软件后先做数据迁移再做配置迁移切换前保留老系统至少一周确认新系统稳定后再下线CentOS 6.3迁移到新系统时最大的问题不是配置格式而是软件版本的跃升。PHP 5.3到PHP 7.4/8.xMySQL 5.5到MariaDB 10.x代码里的语法和调用全都要过一遍。启动一个兼容性验证环节把所有业务功能列成清单逐项测试。还有一个非常现实的点如果老系统上的业务代码已经无人维护强行迁移新版本会导致整个应用跑不起来。这时要做的不是升级而是考虑封装把老系统做成虚拟机镜像固化版本和环境在虚拟化平台上继续运行同时在前面增加接入层的访问控制。这比强行迁移更实际很多企业在做一些关键老应用时就是这么干的。最后再分享一个我的习惯每次处理完CentOS 6.3相关的维护工作我都会把这个系统当前的状态、依赖的所有自定义脚本、用到的所有第三方rpm包路径单独写进一份README放在/etc/system_readme.txt里。老机器维护最怕的不是技术难题而是不知道当初改了哪里。花十分钟留个文档下次接手的人能少熬三个夜。本文还有配套的精品资源点击获取 CentOS 6.3运维实战：老系统安装配置与EOL后维护指南
简介围绕 CentOS 6.3 系统主题的网页源码包基于一套名为 mobilyblocks 的前端框架制作面向需要快速搭建系统介绍、版本说明或技术博客站点的开发运维人员。压缩包为 RAR 格式共计 19 个文件其中以 14 张 PNG 图片为主要视觉资源另有 3 个 JavaScript 脚本、1 个 CSS 样式表和 1 个 HTML 入口页面整套资源仅 244KB体积小巧、结构清楚。资源内部划分出主页、图片、社交链接、脚本与样式等模块方便用户按需替换内容或二次开发。目前已有 514 人学习下载。通过这套源码读者可以直接得到一份可运行的页面框架修改文字与图片即可用于 CentOS 6.3 相关分享同时也能了解前端开发中 HTML、CSS、JavaScript 与图片资源的组织方式对在 Linux 环境下进行页面调试和快速部署很有帮助也能节省从零编写页面的时间。无论是用于个人学习笔记整理还是团队内部知识库展示都较为合适。 2013年夏天我从前同事手里接过一台跑着CentOS 6.3的服务器。那是一台老旧的PowerEdge装着一套内部业务系统没人说得清当年是谁装的、怎么装的只知道别乱动动了会出问题。接手之后我做了个完整检查结果发现swap分区是0yum源全是失效链接防火墙iptables默认全放行。从那时候起我就和这个版本代号较上了劲。CentOS 6.3在当年的定位非常明确RHEL 6.3的社区重新构建版内核2.6.32glibc 2.12GCC 4.4.7Python 2.6.6。这套组合在2012年是主流到2020年11月底官方彻底停止维护时它已经生存了八年多。今天这篇东西不是劝你这都什么年代了还碰老古董恰恰相反到现在仍有不少内网机器、工控主机、老业务数据库跑在这类系统上。写给正在维护存量系统的朋友也写给第一次接触这个老版本、对着黑屏不知所措的新人。1. CentOS 6.3当初凭什么站稳脚跟1.1 2012年前后的服务器生态把时间拨回2012年那时候的服务器市场不像现在这样群雄并起。Windows Server还在一代代迭代Ubuntu在桌面端闹得欢但在服务器上还偏极客而企业级生产环境里选择其实不多。CentOS在当时最大的卖点就是你不需要买红帽的服务订阅却能得到和RHEL完全同源的操作系统。稳定、可预测、支持周期长对企业来说这三个词就是钱。CentOS 6.3并不是6.x系列的起点但它是当时社区在6.x周期里一个承上启下的关键版本。它默认使用ext4文件系统支持ext4作为根文件系统的默认选择取代了5系列时代ext3的老规矩。同时LVM2已经非常成熟整块磁盘做LVM逻辑卷成了标准做法。对于维护者来说这意味着以后调整分区大小不需要再对着fdisk发愁。从网络协议栈角度看2.6.32内核本身是2009年发布的长期稳定分支红帽将其不断backport更新到6.3版本所以在2012年拿出这台系统时它对新硬件、新协议的支持虽然比上游主线激进版本慢半拍但胜在稳定。生产服务器最怕的不就是新功能没用到先被新bug教做人1.2 CentOS 6.3的产品定位和关键指标这个版本在产品线上扮演的角色简单说就是够用且安全的中间力量。CentOS 6系列从6.0到6.10走过了漫长的道路。6.3处于6.2和6.4之间它在虚拟化、文件系统、电源管理上都做了不少增强但最核心的还是对x86_64架构的全面普及。6.0时代你还会认真考虑装32位版本到6.364位基本是标配。几个关键指标我列一下内核版本2.6.32-279这是6.3初始发行版的kernel基线glibc版本2.12GCC版本4.4.7Python版本2.6.6注意连2.7都不是OpenSSL版本1.0.1e已支持TLS 1.1和TLS 1.2默认文件系统ext4支持XFS但非默认这套配置放在今天看确实老态龙钟但在2012年它正好命中了一个巨大的存量市场需求企业内网、Web托管、数据库服务器、OA/ERP系统。换句话说CentOS 6.3吃到了国内互联网快速扩张的红利大量早期部署的业务系统到今天还存在。2. 装CentOS 6.3时最值得留意的三个决定2.1 位数和内核的选择我见过很多早期装机器的人因为服务器内存只有2G或4G顺手选了i386版本。这在当时不算错但后来业务一扩容内存加到8G、16G32位内核单个进程最多只能用到约3G用户空间直接卡死。如果现在你还要在虚拟机里装一个CentOS 6.3做测试或复现旧环境别犹豫直接选x86_64。选64位之后kernel-PAE这种词就不用管了那是32位下的补丁玩法。同时要注意CentOS 6.3在虚拟机里安装时如果虚拟机CPU模型太新安装内核可能会报Kernel requires an x86-64 CPU之类的错不是系统坏了是虚拟化层把CPU特性隐藏了。我遇到这种问题通常会在虚拟机的CPU配置里把启用Nested Virtualization或者CPU模型调成兼容模式再不行就换VMware的Intel VT-x/EPT设置而不是怀疑镜像文件损坏。2.2 磁盘分区与LVM规划Anaconda安装器里进入分区界面时很多人习惯一键自动分区这个习惯在CentOS 6.3年代可以接受但如果让我现在重新规划我会手动做一套LVM方案。我的典型规划是这样按100G数据盘举例挂载点建议大小文件系统说明/boot200Mext4引导文件不需要LVMswap与内存1倍~2倍swap老系统swap别省OOM后用swap能续命/20Gext4LVM根分区预留系统日志和软件安装空间/data剩余全部ext4LVM业务数据单独放备份和快照方便为什么/boot不用LVM因为老版本GRUB对LVM的识别能力有限一旦/boot放进LVM里grub-install阶段容易出诡异问题。我见过不止一次因为把/boot塞进LVM导致开机进不了系统最后只能用rescue模式救。这是一个典型的当时多省了一步事后多花三个小时的教训。还有一点CentOS 6.3的Anaconda在分区界面支持创建分区时填写预期大小但你要留一个概念LVM逻辑卷在扩容时要保证卷组里有剩余空间。所以建LV时不要在VG满打满算比如整块VG 80G/根分区先用20G剩下的留给/data这样以后想扩其他目录都还有余地。2.3 软件包选择最小化安装原则安装过程中会让你选软件包组这是最容易被新手忽略的步骤。CentOS 6.3默认组里有Desktop、Minimal Desktop、Minimal等一堆选项。早期的运维朋友很喜欢选Desktop或者Server with GUI因为怕不会用命令行。但在服务器上没有图形界面反而省心。我建议只选Minimal最小化安装。这样装完以后系统只有不到400个包干净、页面响应快、攻击面小。后面需要什么服务yum再单独装。有一个实际的好处是很多老版本盲装时经常出现图形界面相关的依赖冲突走了Minimal之后这类问题一了百了。不过这里有个小坑Minimal安装默认不带ifconfig、wget、vim这些工具。所以装完第一件事就是yum install -y net-tools wget vim-enhanced否则你会发现连ip地址都不方便查。如果yum源也没配好那就会陷入一种没有工具没法装工具的哲学困境。所以顺序一定是先配yum源再装基础工具。3. 装完系统后的基础配置直接影响运维成本3.1 yum源的配置和仓库选择CentOS 6.3的yum源官方默认走mirrorlist到2020年EOL之后官方mirror自然就消失了。如果你现在想装必须把yum源手动改成归档源或国内镜像站的vault目录。在/etc/yum.repos.d/CentOS-Base.repo里把baseurl指向归档目录并把mirrorlist注释掉。归档源在网上有比如vault.centos.org国内的阿里云也有对旧版本的归档目录。这里有个操作细节改完之后先跑一下yum clean all再yum makecache。老机器上makecache可能很慢如果出现超时可以把yum.conf里的timeout调大比如timeout30。除了Base源另一个值得配的是EPEL源。CentOS 6.3的自带仓库软件版本都比较旧比如nginx没有redis也没有很多新一点的工具都在EPEL里。但要注意CentOS 6上的EPEL也停更了需要从archive里单独找epel-release-6-8.noarch.rpm这类老包。还有一组仓库是CentOS 6时代很多人会配的Remi仓库、RPMForge、RPMFusion。我的实际经验是不要贪多。仓库配得越多依赖冲突的概率越大。尤其是Remi这个PHP仓库它提供的PHP版本比系统自带的5.3新很多但风险也高一旦你不想用了卸载会牵连一堆包。主用Base加EPEL个别包手动编译是我最后沉淀下来的稳定方案。3.2 SSH与防火墙的初始加固CentOS 6.3上SSH默认是OpenSSH 5.3它支持的算法在今天看来很陈旧比如默认的HostKey里有ssh-dssDSA算法新版OpenSSH客户端默认已经禁用了。如果你在一台新电脑上用ssh登录老服务器报no matching key exchange method found之类的错误不是密码错了是密钥交换算法对不上。我的经验是在服务端/etc/ssh/sshd_config里加三行历史兼容配置Ciphers aes128-ctr,aes192-ctr,aes256-ctr MACs hmac-sha1,hmac-sha2-256,hmac-sha2-512 KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1这样新版本ssh客户端才能正常连上来。注意修改前先备份sshd_config改完跑service sshd restart之前一定要先另开一个连接窗口测试不然旧连接一断新连接又进不去你就只能在机房门口吹风了。防火墙上CentOS 6.3还是iptables不是firewalld。配置规则用命令行直接敲的有效时间是当前会话想持久化要service iptables save它会写入/etc/sysconfig/iptables。我习惯初始规则就三件事开SSH端口、开业务端口、其他全拒。iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -P INPUT DROP service iptables save这里要提醒一件事别上来就-A先把默认策略搞清楚。-P INPUT DROP之后如果你忘了加允许回包的那条规则容易把已经建立的连接断掉。3.3 内核参数与文件句柄调整CentOS 6.3默认的文件句柄限制是1024对于Web服务来说太低了。改文件句柄不是只改ulimit/etc/security/limits.conf里要加* soft nofile 65535 * hard nofile 65535但注意CentOS 6.This系统里SSH登录的会话默认不加载PAM limits如果改完不生效要检查/etc/pam.d/login和/etc/pam.d/sshd里是否包含了pam_limits.so那一行。内核参数方面TCP连接重用那三条至今仍然有效net.ipv4.ip_local_port_range可以扩大到1024-65000net.core.somaxconn调大net.ipv4.tcp_max_syn_backlog调大。有一个坑当年很多人喜欢开net.ipv4.tcp_tw_recycle1在NAT环境下这会造成随机丢包你在老系统上调优时尽量避免它。文件系统层面我建议把atime关掉在/etc/fstab的挂载参数里加上noatime。这是个老技巧减少每次读取文件时的元数据写入尤其适合那些大量读操作的业务。4. 在CentOS 6.3上跑业务遇到的兼容性问题4.1 Web服务端PHP/MySQL组合发行版自带的PHP是5.3.3MySQL是5.1/5.5。2012年这是一套黄金组合今天再回头看PHP 5.3的很多函数已经废弃mysql扩展注意不是mysqli也不是PDO在PHP 7里被整个删掉了。如果你负责的老系统还是用mysql_connect写的那在CentOS 6.3上反而能跑因为整套环境就是为它量身定做的。但如果你想在CentOS 6.3上装个比较新的PHP比如PHP 5.6就得使用第三方仓库或自己编译。我自己编译过一次PHP 5.6.40这是5.6系列最终版编译前要解决一堆依赖libxml2-devel、openssl-devel、curl-devel、gd-devel这些都得yum装好。有个坑是libcurl版本太老安装新版PHP扩展时可能报错curl版本过低解决办法是编译curl或升级到EPEL的curl版本。MySQL方面CentOS 6.3装MySQL 5.5还是5.1取决于你用的发行版ISO和仓库状态。默认Base仓库里是mysql和mysql-server版本5.1针对老内核优化过InnoDB引擎在5.1的表现和5.5相比差距明显5.5对多核和扩展性的支持更强。所以我建议如果业务允许尽量升级MySQL 5.5。4.2 老编译链带来的软件安装难题这是我在CentOS 6.3上最头疼的部分。GCC 4.4.7和glibc 2.12的组合导致很多新版本软件没法直接编译典型问题是undefined reference to...或者GLIBC_2.14 not found。出现GLIBC_2.14 not found是因为程序编译时依赖了新版glibc但系统里只有2.12。遇到这个情况很多人第一反应是升级glibc这非常危险。glibc是系统最底层组件版本不对可能导致所有命令都无法运行ssh都进不去系统直接变砖。我绝对不会在CentOS 6.3上贸然升级glibc尤其生产环境。针对老系统的软件安装我总结出一套优先二进制其次老版本源码最后才考虑工具链的策略优先用yum装发行版仓库里的老版本软件如果必须上新版先检查对方是否提供rpm包编译前认真看README里的版本要求很多项目明确写了仅支持glibc 2.14对新版软件真的需要就考虑容器化用Docker跑新版软件把系统隔离出去有一种场景是内网无法拉取外部环境这时你需要在同版本系统上先配好依赖环境再把软件包批量拷贝到目标机器。CentOS 6.3的依赖关系比新版要简单但也更容易因为个别依赖缺失导致安装中断。我习惯在准备环境时先用yumdownloader把rpm包全拉下来再通过本地目录安装免得一台一台去解决网络问题。4.3 老内核的稳定与局限CentOS 6.3的内核虽然版本号是2.6.32但红帽做了大量backport很多新特性实际上已经包含在内只是不强制执行。它的稳定是经过无数生产环境验证过的。我见过这台内核在裸机上连续运行四五年没重启过的场景swap不到10%负载长期平稳确实有老前辈的风骨。但它也有明显的局限性。首先是对新硬件支持非常差。NVMe固态、新一代网卡、高性能GPU这类设备在2.6.32上要么没驱动要么无法发挥性能。其次是文件系统层面的限制ext4在CentOS 6.3上建议单文件不超过16T如果你有大容量存储需求得单独评估而XFS在2.6.32上的支持虽然存在但不像后来RHEL 7上那样成熟。还有内核的TCP/IP栈在极高并发下它的性能和现代内核有明显差距。我在一台CentOS 6.3上压测过一个Nginx服务并发升到8000左右时出现大量time_wait占用后来调整了ip_local_port_range和tw_reuse参数勉强能撑住一万并发但在同样的物理机上升级到新系统后不调优就能超过这个数字。老内核被时代淘汰原因不是稳定性而是性能增长停滞和硬件兼容跟不上。5. EOL之后的老系统我总结的维护与迁移经验5.1 系统EOL不等于业务马上崩2020年11月30日CentOS 6所有版本正式EOL。但EOL只代表官方不再发布安全补丁不代表你在跑的业务系统会立刻出问题。很多人一听到EOL就焦虑其实真正需要担心的是那些依赖公网、暴露在攻击面上的服务器。如果系统在隔离的内网里业务又一直稳定运行那就没必要为了追新而强行迁移。不过你可以做的是确认yum源已切到归档配置中清掉那些失效的mirrorlist避免每次跑yum都卡半天。然后做一次完整镜像备份。我建议至少保留一份系统盘和一份数据盘的快照放异地或独立存储上。老系统就像老仓库平时刻意维护不多真出事时备份就是你最后一根救命稻草。5.2 没有官方补丁时的替代加固方案EOL之后补丁没了但加固思路还能跟上。外部访问不到的部分靠网络隔离必须暴露的部分加前置防护。比如Nginx前面套一层云WAF或安全组数据库不直接对全网开放只允许内网网段连接。越是不更新补丁的系统越要在网络架构层面把攻击面缩小。日志监控也得更勤快。Syslog、/var/log/messages、/var/log/secure这些日志建议直接转发到远程日志中心别留在本地万一被入侵者清理了还能从远端查。文件完整性监控如果有条件可以做例如给bin目录和/etc目录定期做校验和比对发现异常及时报警。没必要再去折腾杀毒软件毕竟商业版杀毒根本不支持2.6.32。把精力放在最小化开放端口、最小化账户权限、定期review访问控制上收益更大。5.3 从6.3迁移出去的现实路径如果你终于决定让老系统退休迁移过程别搞一步到位的浪漫主义。现实中我见到比较稳的迁移路径是这样先在虚拟机里起一台和目标业务匹配的新系统比如Rocky Linux或AlmaLinux在老系统上导出现有配置包括nginx/apache配置、MySQL数据导出、计划任务crontab、环境变量等逐项保存新系统安装完软件后先做数据迁移再做配置迁移切换前保留老系统至少一周确认新系统稳定后再下线CentOS 6.3迁移到新系统时最大的问题不是配置格式而是软件版本的跃升。PHP 5.3到PHP 7.4/8.xMySQL 5.5到MariaDB 10.x代码里的语法和调用全都要过一遍。启动一个兼容性验证环节把所有业务功能列成清单逐项测试。还有一个非常现实的点如果老系统上的业务代码已经无人维护强行迁移新版本会导致整个应用跑不起来。这时要做的不是升级而是考虑封装把老系统做成虚拟机镜像固化版本和环境在虚拟化平台上继续运行同时在前面增加接入层的访问控制。这比强行迁移更实际很多企业在做一些关键老应用时就是这么干的。最后再分享一个我的习惯每次处理完CentOS 6.3相关的维护工作我都会把这个系统当前的状态、依赖的所有自定义脚本、用到的所有第三方rpm包路径单独写进一份README放在/etc/system_readme.txt里。老机器维护最怕的不是技术难题而是不知道当初改了哪里。花十分钟留个文档下次接手的人能少熬三个夜。本文还有配套的精品资源点击获取 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
