提到欧拉数学圈的朋友第一时间想到的是欧拉函数、欧拉筛这些精巧的数学工具运维圈的朋友想到的多半是装了openEuler操作系统的服务器。这两个“欧拉”其实有一个共同气质严谨。欧拉函数算错一位整个推导就崩了欧拉系统维护漏看一条日志、少配一个参数生产环境可能就安静地出问题。这篇文章就是我这一段时间维护欧拉系统openEuler的实际总结面向的是Linux运维、服务器管理员以及准备在服务器上跑欧拉系统的个人开发者。内容覆盖从安装规划、图形化界面配置到日常更新、服务管理、日志分析、磁盘网络维护、安全加固、故障排查的完整链路。我把能直接抄作业的命令、参数和思路都放在里面了希望帮你把维护工作从“被动救火”变成“有序保养”。1. 维护从安装规划开始认知与布局1.1 欧拉系统的定位与维护思路在动手维护之前先要搞清楚自己面对的是一个什么样的系统。openEuler目前主要面向服务器和数据中心场景它也提供桌面环境组件但本质上更像个“服务器底子”。它的软件包管理走的是Red Hat系列那套dnf/yum都能用systemd做服务管理这在维护思路上跟CentOS、Rocky、Fedora颇为接近。所以我在整个维护过程中一直坚持一个原则把欧拉系统当作一个成熟的企业级Linux发行版来对待而不是当作某种特殊玩具。这意味着不随手关闭SELinux除非确认业务兼容性严格执行最小安装和按需装包定期做更新但在生产环境会提前做兼容性评估统一命名和管理配置避免“每台机器一个样”。我见过不少朋友一拿到系统就先把SELinux关了防火墙也停了理由是“方便”。短期确实方便等真出了安全事故、或者等后来想加固再开SELinux就发现一堆坑。我这边负责的一批机器坚持不关SELinux配合正确放行规则系统运行一直很稳。1.2 安装规划磁盘、分区、图形化界面怎么选安装欧拉系统有几个关键决策点这些决策决定了后续维护的难度。第一磁盘规划。我建议服务器场景用LVM而不是直接怼裸分区。LVM的好处是后续扩容方便遇到分区不够用不用重新做系统。给个参考/boot1GiB左右ext4启动文件和内核镜像用swap物理内存的1到2倍或者按业务峰值评估/剩余空间的相当一部分比如30到50GiB/var如果有大量日志、容器镜像建议单独分出来20到50GiB起步/home视情况独立分区很多时候不用给它太多空间。如果只是个人测试用也可以单分一个根分区加swap甚至不做swap直接上swap文件。第二安装介质与引导。可以从官网下载ISO开机引导后选择“Install openEuler”设置语言和时区配置安装源与安装包选择磁盘分区按前面说的思路来然后设置root密码和创建用户等待安装结束重启即可。第三图形化界面。很多朋友搜索“欧拉操作系统安装图形化界面”其实图形化在服务器场景里不是必需品但如果你确实需要比如跑桌面应用、给非运维同事用的内网机器可以在安装时就勾选相应的包组例如“图形化环境”或“带图形的服务器”这比事后补装省事很多。也可以在装好之后用命令行补装。我个人的建议是能不用图形化就不用。服务器维护的主要方式是SSH图形化界面除了占资源、多一层攻击面对维护工作本身帮助不大。如果你只是想用浏览器做监控那装个Web控制台类工具比整套桌面环境划算得多。1.3 安装后的初始化检查清单系统装完、能ping通这只是开始。我每次装完一台欧拉机器都会按下面的清单过一遍避免后面出幺蛾子。更新系统dnf update -y装完之后确认内核版本确认主机名和解析hostnamectl set-hostname检查/etc/hosts把主机名和IP对应关系写清楚配置时间同步装chrony配好NTP源时间不同步在运维里是最容易被忽视却影响很大的问题确认SSH服务检查/etc/ssh/sshd_config确认PermitRootLogin策略、密钥登录是否启用配置防火墙firewall-cmd --list-all放行需要暴露的端口检查SELinux状态getenforce别一上来就设成disabled至少设置成enforcing并配好放行规则校验存储lsblk、df -h确认分区挂载创建日常运维账号不要所有操作都顶着root干独立账号配合sudo才是正道。这些步骤看着基础但每次重新执行一遍都能规避大量后期问题。2. 日常维护三板斧更新、服务与日志2.1 软件包管理dnf/yum与镜像源配置欧拉系统的软件包管理沿用了dnf/yum体系。有些老运维习惯只记yum实际上在欧拉系统上yum可能只是一个到dnf的符号链接底层动作都由dnf完成为主。日常维护里我依赖最多的几个操作查包dnf list --installed | grep xxx、dnf provides /path/to/file判断文件属于哪个包装卸载dnf install -y nginx、dnf remove -y xxxremove前建议先看依赖影响检查更新dnf check-update应用更新dnf update -y内核更新后记得重启历史回滚dnf history list、dnf history info N、dnf history undo N在出问题时可以快速还原。关于镜像源换源时要小心先备份原有repo文件然后编辑/etc/yum.repos.d/下对应的repo文件把baseurl换成可用的镜像地址dnf makecache重建缓存再dnf update验证。换源经验谈别只改baseurl不改gpgcheck策略半吊子配置最容易导致“明明改了源安装还是报错”。如果你搞不清某个repo文件是谁在维护就先ls /etc/yum.repos.d/看清楚再下手别一把梭全删了然后源彻底不可用。2.2 服务管理systemd单元文件的正确维护姿势服务管理是系统维护的心脏。欧拉系统用systemd常用命令大家也熟systemctl start/stop/restart/status/enable/disable xxx。我觉得容易被忽略的有几个细节。第一systemctl status只看状态还不够要养成journalctl -u xxx -n 50 --no-pager的习惯。status显示的是“这个服务当前是否活着”journal能看到它怎么活的、活得舒不舒服。第二改完服务单元文件/usr/lib/systemd/system/xxx.service或/etc/systemd/system/下的覆盖文件之后必须执行systemctl daemon-reload否则改了半天服务根本不会按新配置重启。第三写自己的服务单元文件时注意几个字段After和Requires定义启动顺序依赖Restart设置为always或on-failure配合RestartSec避免服务崩溃后一直重启无脑刷日志服务尽量用专用用户跑User和Group不要留空。我给一个自写服务单元文件的习惯模板[Unit] Description自定义业务服务 Afternetwork.target [Service] Typesimple Userappuser Groupappgroup ExecStart/usr/bin/python3 /opt/business/main.py Restarton-failure RestartSec5 EnvironmentFile/etc/sysconfig/business [Install] WantedBymulti-user.target写完之后执行systemctl daemon-reload systemctl enable --now xxx。第四排查服务启动失败先看两个地方journalctl -u xxx -e和systemctl cat xxx。前者看日志后者看服务定义十有八九问题就出在命令路径不对、参数引号丢了、权限不够、缺依赖这四类情况。2.3 日志体系journalctl与标准日志分析思路日志是排障的第一现场。欧拉系统默认用journald集中管理日志配合rsyslog也可以。我比较常用的排查套路看最近日志journalctl -xe按时间范围过滤journalctl --since 2024-01-01 00:00:00 --until 2024-01-01 12:00:00按服务过滤journalctl -u nginx.service --since today按进程号过滤journalctl _PID1234看内核日志journalctl -k看上次启动以来的开机日志journalctl -b 0分析日志的核心思路我一直跟团队讲三步走先锁定时间窗口再锁定服务或进程最后从错误行往上翻上下文。不要一上来就搜ERROR很多故障的根因在ERROR上面几行就埋着。还有一点日志量大的服务要配置轮转。别等/var/log分区被撑爆再处理。如果发现磁盘有告警先看大文件du -sh /var/log/* | sort -rh | head然后决定是清理还是改轮转策略。3. 稳定性保障存储、网络与性能监控3.1 磁盘与文件系统的维护实操磁盘维护是服务器运维的高频工作。欧拉系统的文件系统默认常见的是ext4和xfs我自己更偏爱xfs多一点主要看重它在高吞吐和大文件场景下的表现但日常维护步骤大同小异。常用步骤df -h看使用率df -i看inodeinode耗尽比空间满更隐蔽典型的“df显示有空间但就是写不进去”lsblk -f看文件系统类型和挂载点、UUIDjournalctl或dmesg | tail看是否有磁盘I/O报错。LVM操作也绕不开。比如根分区不够了添加一块新盘lsblk确认设备名pvcreate /dev/sdb创建PVvgextend vg0 /dev/sdb扩展到VGlvextend -L 50G /dev/vg0/root扩LVxfs_growfs /xfs或resize2fs /dev/vg0/rootext4。我经常看到有人卡在最后一步LVM扩展完忘记给文件系统扩容结果空间还是老样子。xfs和ext4的区别要记住xfs的在线扩容是xfs_growfs加挂载点ext4是resize2fs加设备路径。磁盘清理也讲究。永远不要直接rm -rf看着大但没搞清用途的目录。先lsof L1找已删除但仍被进程占用的文件再du -sh定位大目录确认业务影响后再清理。特别强调别乱删/tmp下还在被进程使用的socket或临时文件删完服务直接hang。3.2 网络配置与防火墙策略欧拉系统的网络配置如果用传统方式主要在/etc/sysconfig/network-scripts/ifcfg-*下有些版本也支持和NetworkManager协同。我个人为了稳定和维护简单通常会统一一个套路要么纯NetworkManager用nmcli管理要么纯传统配置文件方式别搞“这台机器nmcli那台机器ifcfg”的混搭否则后期排查非常痛苦。用nmcli的常用操作查看连接nmcli connection show配置静态IPnmcli connection modify ens160 ipv4.addresses 192.0.2.10/24 nmcli connection modify ens160 ipv4.gateway 192.0.2.1 nmcli connection modify ens160 ipv4.dns 192.0.2.53 8.8.8.8 nmcli connection modify ens160 ipv4.method manual nmcli connection up ens160防火墙层面firewalld是主力放行端口firewall-cmd --add-port8080/tcp --permanent firewall-cmd --reload放行服务firewall-cmd --add-servicehttp --permanent查看规则firewall-cmd --list-all临时规则不加--permanent重启失效适合调试。注意一个细节别把--add-port8080/tcp --permanent这条命令拆成两条并发执行中间不加--reload结果规则写进去了当前会话没生效你还以为配置错了。还要定期检查默认zone是不是反直觉的比如某些环境默认zone不是public规则放行时要小心作用范围。我是每次配完防火墙都执行firewall-cmd --list-all-zones通读一遍。3.3 性能监控的常用命令与判断阈值日常维护不见得出事才看性能我建议形成定期巡检的肌肉记忆。简单套餐uptime看系统负载15分钟负载长期高于核数乘以0.7就要留意top/htop看CPU和内存占用重点找持续高占用进程free -h看内存是否够swap使用率持续增长说明内存吃紧iostat -xz 1看磁盘I/O情况vmstat 1 5看系统层面的CPU、内存、IO综合状况ss -tlnp看监听端口sar如果要看历史监控欧拉系统默认通常有sysstat可以配cron定期抓数据。我一般这样判断问题CPU单核持续超过85%先看进程再考虑优化内存Used高不一定有毛病关键是看available和swap使用available持续很低才需要处理磁盘util接近100%或者await长期偏大结合iowait判断是否有IO瓶颈。性能问题的处理顺序我一直强调先看现象和数据再看进程和线程最后看内核和配置。很多“性能问题”其实是日志级别开太高、或者全链路里有个慢依赖一通乱调内核参数适得其反。4. 安全加固与故障排查实录4.1 SELinux、SSH、账号安全这些坑安全加固这个环节我在维护欧拉系统时从不跳过。先说SELinux。我见过太多人第一件事就是/etc/selinux/config里改成disabled图省心。这带来的问题不是立刻显现的而是后患。在生产环境我建议保持enforcing如果某个服务被阻止用ausearch -m avc -ts recent查审计日志根据日志给对应进程或端口放行策略或者对特定目录设置正确的file context。举个例子如果你把一个服务的数据目录从默认上下文改成/opt/dataSELinux很可能拦截。解决办法可以用semanage fcontext -a -t httpd_sys_content_t /opt/data(/.*)?然后restorecon -Rv /opt/data。这比直接关SELinux干净得多。SSH安全上几条硬规矩禁止root直接密码登录PermitRootLogin no能密钥登录就密钥登录PasswordAuthentication no监听端口如果非必要不改成怪异端口改端口这种“安全”更多是心理安慰真正有用的是密钥认证加fail2ban这类防护定期检查/root/.ssh/authorized_keys和所有用户的authorized_keys防止有人悄悄塞进去公钥。账号管理也不要放松。每季度检查一次账号列表lastlog看最近登录看看有没有长期不登录、却还活着的账号/etc/sudoers用visudo编辑别用乱七八糟的编辑器改坏语法。4.2 启动异常、依赖缺失、空间占满的排查实录故障排查这块我分享几个我实际踩过的坑给大家一个排查思路。案例一系统启动到一半卡住。有一次重启机器画面卡在等待某个挂载点。我第一时间按CtrlC看是哪个单元卡住发现是home分区挂载等待。根因是修改了fstab里home分区的UUID但没对应更新系统在等待一个不存在的设备。修复方法进入单用户或救援模式修正/etc/fstab执行systemctl daemon-reload重新挂载。排查启动问题时的建议顺序是先看有没有报错单元再检查fstab、dracut配置、网络服务是否等待超时最后才看内核参数。案例二服务能跑起来但连不上。nginx起来了端口8899也监听防火墙也放行了但外部访问就是连不上。一排查发现SELinux拦了非标准端口。解决用半自动工具或者手动加放行规则让nginx在8899上合法工作。这个案例就是典型的“规则没问题但系统策略拦着”所以排查连接问题时除了防火墙、监听还要把SELinux列进检查清单。案例三磁盘显示有空间但写不进去。df -h显示有20G剩余但程序报No space left on device。排查过程df -i看到inode已经100%占用。原因是某个目录下产生了海量小文件。定位之后配合删除、迁移来缓解。这个坑很多人一辈子没遇过但一遇就是大事inode监控要纳入巡检。空间占满还有另一个隐藏情况某个大文件被进程打开后删除了但进程还在写导致磁盘空间无法释放。处理办法是lsof L1找到对应进程重启或停用进程即可。4.3 维护脚本与自动化的小技巧运维要能省事就省事能自动化就别手敲。我分享两个实用脚本思路。第一个是巡检脚本。以前我都是逐台上线跑命令后来写成shell脚本然后用循环在清单上执行。内容大致包括检查磁盘使用率、内存、CPU负载、关键服务状态、最近SSH失败登录次数。脚本核心是收拢输出用颜色或特殊前缀标记异常项。例如模块化写法#!/bin/bash host$(hostname) date_time$(date %Y-%m-%d %H:%M:%S) disk_usage$(df -h / | awk NR2 {print $5}) mem_usage$(free -h | awk /Mem:/ {print $3/$2}) load_avg$(uptime | awk -Fload average: {print $2}) echo [$date_time] $host disk$disk_usage mem$mem_usage load$load_avg别当脚本怪人也别写一堆复杂逻辑。巡检脚本的定位是“快速发现问题提醒人关注”不是替代人工判断。第二个是定时清理脚本。比如日志轮转、临时文件清理、打包归档。但这类脚本务必加个DRYRUN开关没确认安全之前别直接删。我踩过的坑就是清理脚本把还在使用的临时socket文件删了服务直接崩溃。现在写清理脚本都是先DRYRUNtrue跑一遍人工确认清单后再正式执行。自动化还有一环就是配置管理。如果你有多台欧拉机器强烈建议尽早考虑用Ansible这类工具做批量管理和配置漂移检测。我自己就是从“手工改ifcfg”慢慢过渡到“Ansible管理网络和安装包”迭代效率提升明显。初始化阶段用Ansible批量拉齐hostname、时区、用户、防火墙规则比一台一台改靠谱得多。写到这里我把欧拉系统维护里最常碰到的那些事儿基本上都过了一遍。说点个人体会。我印象最深的是一次跨天故障排查最后发现只是内核参数vm.swappiness和某个业务的缓存回收策略打架导致服务CPU居高不下。那之后我给自己立了一条规矩凡是改动系统配置一定记录“改前状态、改后状态、为什么改”并统一放在一个维护文档里。半年下来再遇到问题翻这份文档能省掉大半猜测。如果你也刚开始接手欧拉系统的维护工作我的建议很朴素先别碰那些花哨的调优参数老老实实把安装规划、日志习惯、服务管理、安全加固这几件基础事做扎实。等基础盘稳了再逐步引入自动化。系统维护这东西功夫都在平时真正出问题的时候你拼的是对这台机器的熟悉程度和平时的准备。