系统通用部署手册一套能直接抄作业的部署方法论干了这么多年部署和运维我最大的感受是部署这件事80%的坑其实都是重复的。今天装个数据库、明天搭个日志平台、后天又给客户装一套国产系统表面看是不同的事情底层流程翻来覆去就是那几步——环境评估、系统安装、初始化、装依赖、改配置、调权限、验证、收尾。可惜大多数人每次都是边装边查装完就忘下次换个环境又从零开始踩坑。这篇东西我想以“系统通用部署手册”为骨架把这些年沉淀下来的部署套路完整写一遍覆盖企业Linux、统信UOS桌面系统、openEuler、麒麟V10这些主流的服务器与桌面系统也把Grafana Loki日志系统、远程syslog服务器、vsftpd虚拟用户、甚至openEuler下的DeepSeek本地部署、Windows下的Hermes智能体部署这类具体场景串进来。不管你是刚入门的小白还是被部署流程反复折磨的运维老手这篇文章的目标只有一个让你下次拿到任何一台机器心里都有一条清晰的部署路线图。1. 部署前要想清楚的三件事需求、基线、回退1.1 先摸清需求再动工具很多部署翻车不是因为技术不行而是因为一开始就没搞清楚“要部署成什么样”。接到部署任务之后我习惯先问自己五个问题你也可以直接套用这套清单这台机器的角色是什么是生产、测试、还是临时演示生产环境部署的谨慎程度完全不同。上层业务是什么部署完要跑Web服务、数据库、日志采集、模型推理还是文件传输不同业务的系统依赖和性能需求差异非常大。硬件基线是什么CPU核数、内存大小、磁盘类型和容量、是否直通GPU。这决定了后面分区怎么切、依赖怎么装、模型能不能跑。有没有既有的规范要求比如公司规定的IP段、DNS、软件源镜像、NTP服务器或者等保要求里的密码策略、双因素认证。谁来接手维护如果后面不是我负责我需要在部署过程中留下什么文档和注释。这个阶段最忌讳的是“拿到一台机器直接开装”。我见过不少同事IP都没规划好就装系统装到一半发现网段冲突又重来一遍。多花十分钟把需求写清楚后面至少省半天返工的时间。1.2 建立部署基线与配置台账部署基线这个词听起来很正式说白了就是“这台机器从装完系统到交付所有配置项的标准答案”。我每次部署都要建一个简单的台账不需要什么高大上的CMDB一张表格就够了配置项标准值实际值备注主机名app-prod-01app-prod-01根据业务域命名IP地址192.168.10.10192.168.10.10静态IP子网掩码255.255.255.0255.255.255.0-网关192.168.10.1192.168.10.1-DNS114.114.114.114、8.8.8.8同上内网请替换时区Asia/Shanghai已确认统一使用国内时区系统语言en_US.UTF-8已确认避免乱码软件源内网镜像源已配置生产环境建议内网源内核版本锁定当前已锁定等保稳定性要求这份台账在部署前先写好一个“计划表”装完系统后再把实际结果回填两边一对比就知道哪里不一致。别小看这个动作它对排障和交接的帮助甚至比后面写的部署文档还大。1.3 回退方案不是选配而是标配很多人部署系统时满脑子都是“怎么成功”从来不考虑“失败了怎么办”。但生产环境部署回退方案的优先级应该等同正式方案。说白了就是我这么干万一干砸了能不能把系统恢复到之前的可用状态部署前的回退方案通常包括三个层次第一层是系统快照或备份。如果是虚拟机部署前一定要做一次完整快照如果是物理机至少要备份好原始的分区表和关键配置。很多服务器管理平台都支持整机快照点一下就能做别省这个动作。第二层是配置文件的备份。改任何配置文件之前先复制一份带日期的备份文件。比如要改sshd_config就先执行cp sshd_config sshd_config.bak-20240101。这个习惯一旦养成回退时就是一条命令的事。第三层是服务层的灰度与预留。如果部署的是新系统、新服务尽量保留旧版本的可执行文件或容器镜像。比如部署新版本vsftpd之前把旧版本rpm包手动缓存一份后续出问题可以直接yum本地安装回退。记住一句话没有回退方案的部署都是在赌运气。赌赢了没人夸你赌输了锅全是你的。2. 不同操作系统的部署要点速查2.1 企业级Linux最小化安装与加固基线企业Linux部署系统最常见的发行版是CentOS、Rocky Linux、AlmaLinux、Ubuntu Server以及国内的openEuler和麒麟。不管选哪个核心原则都一样能最小化就最小化能不加的包坚决不加。我在给企业部署Linux服务器时一般会遵循一套比较固定的安装选择安装模式选择Minimal或Server不装图形界面。生产服务器装GNOME既浪费资源又增加攻击面。分区方案在安装阶段就规划好。建议/boot独立分区1GBswap按业务需求设置一般4GB以上物理内存时给4GB即可需要休眠的机器除外/根分区使用LVM剩余空间都给根卷同时单独挂一份/data给业务数据。网卡命名、IP配置、主机名在安装时直接写死避免安装完成后手工改。用系统自带的SELinux或AppArmor不要一上来就禁掉。确实有兼容问题再按需调整到Permissive出问题再恢复Enforcing。安装完成之后我会立刻执行一轮基础加固这部分属于通用动作任何Linux发行版都适用# 升级所有已安装软件包 dnf update -y # 安装基础运维工具 dnf install -y vim wget curl git net-tools lsof telnet bash-completion # 修改SSH配置禁止root密码登录建议先配好密钥再改 vim /etc/ssh/sshd_config # PermitRootLogin no # PasswordAuthentication no # 重启SSH服务 systemctl restart sshd # 设置时区和时间同步 timedatectl set-timezone Asia/Shanghai systemctl enable --now chronyd这套步骤做完一台可供业务安装的基础环境就出来了。后面的所有服务部署都可以在这套基线上继续叠加。2.2 国产操作系统的安装与适配细节国产操作系统这两年在政企和关键行业用得越来越多统信UOS桌面系统、openEuler 24.03 LTS、麒麟高级服务器系统V10是三个最常见的代表。它们和传统CentOS/RHEL系有很深的渊源但又各有各的坑部署前要心里有数。先看统信UOS桌面系统。这类桌面系统主要用于办公场景安装流程和Windows、Ubuntu Desktop比较接近。需要注意的细节如下镜像建议从官网下载对应的CPU架构版本统信UOS分为amd64、arm64、mips64el等多个版本下错了直接装不上。制作启动盘时Linux下直接dd烧录Windows下用balenaEtcher或Ventoy都行。但注意UOS对UEFI Secure Boot的兼容性相对一般启动失败时先尝试关闭Secure Boot。安装过程会要求创建用户这里的用户名和密码就是后续登录系统的凭据不需要额外分配root权限给普通用户需要提权时用sudo。UOS默认使用DDE桌面环境安装完成后第一件事检查内网激活和软件源设置否则装软件会一直报错。再来说openEuler 24.03 LTS。openEuler是华为主导的开源服务器操作系统内核版本较新对AI、云原生场景的支持很积极。它的安装包管理方式很接近CentOS系用dnf/yum这对我来说是最熟悉的。openEuler 24.03 LTS默认使用Linux 6.6内核对新一代服务器硬件和GPU驱动都很友好。部署时我建议选择“服务器”安装环境磁盘分区用自动分区也行但生产环境仍然建议手工规划LVM。麒麟高级服务器系统V10也是一款和RHEL体系兼容性很好的系统dnf、yum包管理自然支持很多CentOS的部署脚本稍微改改就能跑。但有一点很多人会忽略麒麟V10不同SP版本的软件源配置不一样我记得V10-SP3的软件源地址在系统安装完后往往没有自动配置好需要手工配置或挂载本地ISO源。初装后第一时间检查源的有效性避免后面装vsftpd、pam等软件时抓瞎。2.3 Windows侧的部署思路智能体部署的场景选型Windows系统部署在通用部署里的戏份相对少但也不是没有。尤其像“Window系统如何部署Hermes智能体比较合适”这种需求实际工作中会越来越多。这里我把Windows环境下的部署选型思路讲清楚比直接给两个命令有用得多。在Windows上部署这类AI智能体或Python应用通常有三种方案第一种是原生Python环境。直接在Windows里装Python然后pip install依赖再跑模型服务。好处是路径简单、调试直观坏处是依赖管理和性能隔离都很差一旦装坏系统很难清理。第二种是WSL2。在Windows里启用Windows Subsystem for Linux跑一个完整的Linux发行版然后在Linux环境里部署。对AI、模型推理这类应用WSL2是Windows上一个很平衡的选择既能复用Linux下的成熟生态又能访问Windows文件系统性能损耗也可接受。第三种是Docker Desktop。优点是环境隔离彻底、部署可复现一条docker compose up就能把服务拉起来缺点是Windows上Docker Desktop的资源占用偏大GPU透传和USB设备透传还是远不如Linux原生流畅。我的个人建议是如果你只是要在Windows上做开发和单机测试用WSL2最合适如果考虑到后续要交付给客户或上生产优先Docker化只有在项目必须用Windows原生API的情况下才考虑原生Python环境。另外不管选哪种方案模型权重文件的目录一定要规划好Windows路径里的反斜杠和空格经常是各种脚本报错的根源宁可统一用英文短路径也不要图方便放在“D:\我的文件\New Folder”这种路径下。2.4 初始化配置的统一标准网络、源与时区不管装什么系统初始化配置里网络、软件源、时区这三样东西是必须统一的。很多部署不成功的案例最后查出来的根源往往是这三样没配好。网络的第一个要点是固定IP。服务器或者长期运行的机器生产环境必须有静态IP。如果用的是DHCPIP漂移或者其他机器占IP都会造成服务不可达排查起来非常痛苦。第二个要点是DNS配置要合理内网环境建议配置内网DNS公共DNS的组合并保证正向解析和反向解析都正常很多依赖主机名认证的服务对反解比较敏感。软件源的选择直接影响后续安装的顺畅程度。公网服务器可以用官方源内网机器强烈建议配置企业内网镜像源或本地离线源。国内常见的开源镜像站有清华TUNA、阿里云镜像、华为云镜像等openEuler有专属的mirrors麒麟系统部署时也建议优先用官方源。离线环境更直接把ISO挂载为本地源再配置好repo文件比什么都靠谱。时区的坑也很常见。系统默认时区经常是UTC业务日志里记录的时间和北京时间差了8小时排障时容易抓狂。所有系统的部署步骤里都要加上一句timedatectl set-timezone Asia/Shanghai同时打开NTP自动同步让时间保持在正确轨道上。3. 通用部署流程的标准化拆解3.1 分区方案与安装模式选择“分区怎么分”是系统部署里问得最多的问题之一。很多人习惯了“全部分给根分区”短时间没问题但遇到日志爆满或者需要扩展数据盘时就很难受。我的通用建议是这样的挂载点大小推荐格式说明/boot1GBxfs或ext4放内核和引导文件大了浪费/boot/efi512MBvfatUEFI启动必需swap4~8GBswap视内存和业务需求而定/剩余可用空间LVMxfs系统盘根分区/data独立逻辑卷xfs放业务数据方便备份和扩容对生产环境服务器我几乎一律选择LVM原因很朴素LVM可以在不重装系统的情况下扩展分区。今天你给根分区分配了100GB半年后日志容量不够了只要卷组里有剩余空间一条lvextend就能解决这在传统固定分区下是做不到的。安装模式方面能用“最小化”就不用“完整”图形界面、桌面办公套件、开发工具包这些在生产服务器上基本都是多余。少一个包就是少一个潜在漏洞。3.2 软件源、依赖与版本管理部署时经常遇到的依赖地狱其实源头往往是软件源没配好。CentOS系的经验是yum/dnf源要同时配置好base、epel和一些特殊软件需要的第三方源Debian系要处理好sources.list和apt-key问题国产系统则在初次安装后要检查源是否可用。这里我给一个openEuler的本地ISO源配置示例直接在刚装好的24.03 LTS机器上执行适合无法访问公网的服务器mkdir -p /mnt/iso mount -o loop /path/to/openEuler-24.03-LTS-x86_64.iso /mnt/iso cat /etc/yum.repos.d/openEuler-local.repo EOF [openEuler-local] nameopenEuler $releasever - Local ISO baseurlfile:///mnt/iso enabled1 gpgcheck0 EOF dnf clean all dnf makecache依赖版本的问题则要靠“环境隔离”来解决。Python项目用virtualenv/condaNode项目用nvm容器化项目直接用Docker。部署AI模型、智能体这类依赖很复杂的服务时一定要把依赖锁在虚拟环境里不要让pip直接装到系统Python目录否则很容易和系统原有包冲突。3.3 用户、权限与基本安全设置很多部署习惯是“所有服务都用root跑”图省事。这在测试环境可以生产环境绝对不行。原因是多方面的服务被攻破后攻击者直接获得最高权限多个服务共用一个root账号日志审计根本分不清谁干了什么权限过大也容易误操作。通用做法是为每个服务创建独立的系统用户只赋予它运行服务所需的最小权限。给出的命令示例# 创建独立运行用户不登录shell不建立home目录 useradd -r -s /sbin/nologin -M myservice # 授权日志目录 mkdir -p /var/log/myservice chown -R myservice:myservice /var/log/myservice # 服务配置文件只允许root读 chown root:root /etc/myservice.conf chmod 600 /etc/myservice.conf文件权限的基线也很清晰配置文件600可执行文件755数据文件根据是否需要外部访问来定640或660。SELinux如果开启的话还要给服务设置正确的SELinux上下文这个后面第五节展开讲。3.4 可复用的一键初始化脚本示例部署经验积累到一定程度就应该沉淀成自动化脚本。下面这个init.sh是我日常部署Linux服务器时反复在用的模板你可以根据自己的环境需求增删改#!/bin/bash # 系统初始化脚本适用于CentOS/RHEL/openEuler/Kylin # 用法sudo bash init.sh set -e # 1. 确认以root运行 if [ $EUID -ne 0 ]; then echo 请使用root用户运行 exit 1 fi # 2. 设置时区 timedatectl set-timezone Asia/Shanghai # 3. 配置主机名通过参数传入 HOSTNAME${1:-server-unknown} hostnamectl set-hostname $HOSTNAME # 4. 更新系统并安装常用工具 dnf update -y dnf install -y vim wget curl git net-tools lsof telnet bash-completion parted # 5. 关闭NetworkManager或确认网络服务正常 systemctl enable --now network 2/dev/null || true # 6. 配置SSH保留密码登录生产环境再改为密钥 sed -i s/^#PermitRootLogin yes/PermitRootLogin prohibit-password/ /etc/ssh/sshd_config systemctl restart sshd # 7. 关闭或配置firewalld systemctl enable --now firewalld # 8. 内网环境替换软件源请在这里添加 sed 操作 echo 系统初始化完成。脚本的核心目的不是炫技而是保证每一台机器经过同样的步骤、达到同样的状态。这种可复现性正是项目标题“系统通用部署手册”想表达的核心价值——手册不是给人看的是要能指导自动化执行的。4. 典型业务场景部署实操4.1 轻量级Grafana Loki日志系统部署日志系统是很多企业内部刚需但Elasticsearch那套重维护成本高。Grafana Loki是一个很适合中小规模的轻量级日志聚合方案它通过标签索引代替全文索引资源消耗小很多。我部署Loki时习惯用Docker Compose三件套一次拉起来promtail采集日志、loki存储日志、grafana展示日志。下面是一份可以直接用的docker-compose.yml简化版部署前请确认主机已安装Docker和Docker Composeversion: 3.9 services: loki: image: grafana/loki:2.9.2 ports: - 3100:3100 volumes: - ./loki-config.yaml:/etc/loki/local-config.yaml command: -config.file/etc/loki/local-config.yaml promtail: image: grafana/promtail:2.9.2 volumes: - /var/log:/var/log:ro - ./promtail-config.yaml:/etc/promtail/config.yml command: -config.file/etc/promtail/config.yml grafana: image: grafana/grafana:10.1.4 ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin123promtail配置的核心在scrape_configs它决定采集哪些日志、打上什么标签。假设要采集Nginx访问日志并按照host标签区分scrape_configs: - job_name: nginx static_configs: - targets: [localhost] labels: job: nginx __path__: /var/log/nginx/*.log启动之后访问Grafana的3000端口添加数据源时选Loki地址填http://loki:3100或宿主机IP:3100然后就能在Explore里用LogQL查询日志了。LogQL的语法和PromQL有相似之处例如{jobnginx}就能筛选出Nginx日志。这套系统在单机日志量每天几个GB的场景下非常稳几十台机器完全扛得住。但日志量要是每天上TB还是趁早换Elasticsearch或者ClickHouse这类方案。4.2 远程syslog日志服务器部署和Loki这类新晋日志系统相比syslog仍然是网络设备和很多Linux服务日志传递的标准协议。部署远程syslog服务器核心就是把Linux自带rsyslog从“本地写日志”改成“接收远程日志”。服务端操作如下假设角色是集中式日志接收服务器# 编辑rsyslog配置 vim /etc/rsyslog.conf # 取消以下行注释启用TCP和UDP的514端口接收 # module(loadimudp) # input(typeimudp port514) # module(loadimtcp) # input(typeimtcp port514) # 增加远程日志接收模板按主机名和程序名分类存储 $template RemoteLogs,/data/syslog/%fromhost-ip%/%programname%.log *.* ?RemoteLogs # 重启服务 systemctl restart rsyslog # 放行防火墙 firewall-cmd --permanent --add-port514/tcp firewall-cmd --permanent --add-port514/udp firewall-cmd --reload客户端只要在/etc/rsyslog.conf末尾加一行把所有日志实时转发到服务端*.* 192.168.10.20:514注意是UDP是TCP。内网环境我一般用TCP因为UDP丢包不重传日志会悄悄消失。syslog服务器本身没多少技术含量但踩坑点集中在两个地方一是防火墙514端口是特权端口如果配置没生效会一直收不到日志二是SELinuxrsyslog要写/var/log之外的自定义目录时会被SELinux拦截需要执行semanage fcontext -a -t var_log_t /data/syslog(/.*)?然后restorecon -Rv /data/syslog。4.3 麒麟V10部署vsftpd并创建虚拟用户麒麟高级服务器系统V10-SP3部署vsftpd并创建虚拟用户是文件服务场景里非常典型的需求。之所以用虚拟用户而不是直接用系统用户核心原因是安全和管理便利虚拟用户不能登录系统也不占系统账号批量管理和权限控制都很方便。先安装相关软件包dnf install -y vsftpd db4-utils然后准备虚拟用户口令文件。格式是每两行一组奇数行是用户名偶数行是密码cat /etc/vsftpd/vusers.txt EOF zhangsan passwd123 lisi passwd456 EOF生成Berkeley DB数据库文件cd /etc/vsftpd db_load -T -t hash -f vusers.txt /etc/vsftpd/vusers.db chmod 600 /etc/vsftpd/vusers.db # 删除明文口令文件 rm -f vusers.txt配置PAM认证让vsftpd使用刚生成的数据库做密码校验。修改/etc/pam.d/vsftpdauth required pam_userdb.so db/etc/vsftpd/vusers account required pam_userdb.so db/etc/vsftpd/vusers接着创建一个系统账户作为虚拟用户的映射身份所有虚拟用户登录后都会映射到这个本地用户useradd -d /data/ftp -s /sbin/nologin vftp chown -R vftp:vftp /data/ftp再修改vsftpd主配置文件/etc/vsftpd/vsftpd.conf核心参数如下anonymous_enableNO local_enableYES write_enableYES local_umask022 guest_enableYES guest_usernamevftp chroot_local_userYES allow_writeable_chrootYES pam_service_namevsftpd pasv_min_port30000 pasv_max_port31000每个虚拟用户的独立权限可以在/etc/vsftpd/下建目录按文件名对应虚拟用户名放置配置文件。比如只允许zhangsan上传但禁止lisi上传给zhangsan建/etc/vsftpd/vusers.d/zhangsan内容为anon_world_readable_onlyNO、write_enableYESlisi的配置就不写write_enableYES。最后配置防火墙和SELinuxfirewall-cmd --permanent --add-port20-21/tcp firewall-cmd --permanent --add-port30000-31000/tcp firewall-cmd --reload setsebool -P allow_ftpd_full_access on setsebool -P ftpd_use_passive_mode on这里有个非常隐蔽的坑如果vsftpd开启了chroot并且用户主目录当前是可写的高版本vsftpd会拒绝登录报500 OOPS错误。所以要么把vftp的home设为/data/ftp但ftp目录权限不要给write再建一个子目录做上传目录要么启用allow_writeable_chrootYES。4.4 openEuler 24.03 LTS下本地模型与评估框架的部署最近DeepSeek本地部署很火openEuler 24.03 LTS做AI模型的本地环境确实合适。这里说的不只模型本身还包括评估框架harness的安装。很多人一提到本地模型部署就以为要GPU其实中低规格的CPU机器也能跑小尺寸蒸馏模型只是速度和吞吐量别期待太高。先说硬件基线。如果跑DeepSeek-R1-Distill-Qwen-7B这类7B左右的模型量化后需要大约6-8GB内存空间机器内存建议不低于16GB。如果跑13B以上模型32GB内存起步建议有GPU加速。在openEuler 24.03 LTS上的安装步骤分四步第一步安装基础编译依赖dnf install -y git gcc gcc-c make cmake python3-devel第二步创建独立的Python虚拟环境python3 -m venv /opt/deepseek-env source /opt/deepseek-env/bin/activate pip install --upgrade pip第三步安装PyTorch和transformers生态。CPU版本先按CPU安装有NVIDIA GPU再换成CUDA版本pip install torch --index-url https://download.pytorch.org/whl/cpu pip install transformers datasets accelerate sentencepiece第四步安装lm-evaluation-harness这是“deepseek harness”里最常指的那个评估框架git clone https://github.com/EleutherAI/lm-evaluation-harness.git cd lm-evaluation-harness pip install -e .模型权重下载可以借助huggingface-cli把DeepSeek蒸馏版模型拉到本地然后在harness里跑评测。实际运行中模型首次加载会比较慢因为要反序列化权重文件。为了加速可以先转成safetensors格式再利用。评估任务跑起来后CPU推理会非常耗时一个简单的评测集合跑上几个小时都正常做计划时要有预期。对没有GPU的环境更推荐用llama.cpp配合GGUF量化模型。用llama-cpp-python加载q4_K_M量化文件内存占用能再降三分之一单机部署体验会好很多。这个方向后续再单独写今天先给出主线部署路径。4.5 Windows下部署Hermes智能体的选型建议前面2.3节已经说了WSL2、Docker、原生Python三种方式的取舍。这里补充一些Hermes智能体部署的具体操作思路。所谓智能体部署一般可以拆成三块运行环境、模型或API连接、调度服务。我的推荐组合是WSL2 Miniconda Python虚拟环境。以管理员身份打开PowerShell执行wsl --install -d Ubuntu-22.04然后进入WSL后安装Minicondawget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p ~/miniconda3 eval $(~/miniconda3/bin/conda shell.bash hook) conda create -n hermes python3.10 -y conda activate hermes git clone hermes仓库地址 cd hermes pip install -r requirements.txt模型部分有两种情况如果Hermes调用的是云端API直接在配置文件里设置API Key就行如果在本地加载模型可以参照4.4节在WSL2内安装PyTorch和transformers。Windows本地的CUDA在WSL2里一般是透传可用如果跑N卡建议直接安装支持CUDA的PyTorch版。服务调度方面开发测试阶段前台运行方便看日志正式一点可以在WSL2里用systemd或supervisor来守护进程。WSL2在较新版本中默认支持systemd通信协议也做了适配Windows开机自启时把wsl命令写到“启动”文件夹里wsl.exe -d Ubuntu-22.04 -u root -- supervisorctl start hermes这套方案的核心优势是你在WSL2里获得了一个和Linux服务器几乎一致的环境后续想迁到云服务器或企业Linux服务器几乎不用改代码。5. 部署过程中的常见问题与排查实录5.1 部署失败的第一诊断思路部署失败时新手容易慌老手先看日志。所有的部署问题排查我建议遵循一个固定的顺序看服务状态、看系统日志、看应用日志、复现操作。以systemd管理的服务为例一套组合拳打过去systemctl status nginx journalctl -u nginx --no-pager -n 50 tail -f /var/log/nginx/error.log看到什么报错再往下定位。如果连状态都是active那就用curl、telnet、ss这些工具按网络链路来查。部署问题百分之八十都能靠日志解决剩下的才涉及配置语义、版本兼容这些需要靠经验判断的问题。5.2 网络和软件源问题软件源出问题的表现通常是yum install或者apt install时报404、Could not resolve host、Connection refused。排查顺序是# 1. 确认能否解析域名 nslookup mirrors.aliyun.com # 2. 确认能否连通镜像源 curl -I https://mirrors.aliyun.com # 3. 查看当前repo配置 yum repolist cat /etc/yum.repos.d/*.repo常见解法是换源。把baseurl改成内网镜像地址或者改用本地ISO挂载源。这里提醒一点改完源之后一定要dnf clean all dnf makecache否则缓存里的旧元数据会持续报错。5.3 依赖冲突与编译器版本问题编译安装是部署中最容易翻车的场景。最常见的是gcc版本太老编译新版本软件时报unknown type name、未定义的引用等错误。建议安装BuildTools组包一次性把各种开发工具都补充完整dnf groupinstall -y Development ToolsPython层面的依赖冲突也经常出现升级某个包之后其他包崩了。2024年以来Python 3.12对部分老库的兼容性依然存在比如一些C扩展模块还没有预编译wheel。解决方案很简单用适合项目的Python版本创建虚拟环境锁版本requirements.txt禁止随意pip install --upgrade到全局。5.4 权限、SELinux和防火墙问题运维界有个经典笑话服务起不来关了SELinux试试能起来了于是把SELinux彻底关掉。很多部署文档也这样写给生产埋下大雷。实际上SELinux的问题正确动作是调整策略而不是关闭权威保护机制。排查SELinux拦截的最直接命令是ausearch -m avc -ts recent或者临时用setenforce 0再测试服务是否恢复正常。如果确实是SELinux拦截就用semanage调整上下文或布尔值。例如vsftpd需要开放FTP相关端口和目录写权限执行setsebool -P allow_ftpd_full_access on再配合semanage fcontext定义自定义目录的类型。文档里我建议统一写清楚这些策略调整动作不要动不动就setenforce 0还因为重启后自动恢复而误“修好”了问题。防火墙问题的表现也很典型本机能访问局域网其他机器访问不了。先看监听地址是不是0.0.0.0再看firewalld或ufw规则最后用nc、telnet从客户端测试端口通不通。一层层排查基本都能定位。5.5 排查速查表症状优先排查项常用命令/操作服务启动失败配置文件语法、日志journalctl -u 服务名 --no-pager -n 50端口无监听服务未启动或监听地址错误ss -lntp外部无法访问防火墙、安全组、SELinuxfirewall-cmd --list-all安装软件报404软件源失效yum repolist、curl -I 源地址编译报gcc错误编译器版本、依赖库缺失dnf groupinstall Development Tools登录FTP报500 OOPSchroot目录可写、PAM配置检查vsftpd.conf、PAM模块模型推理OOM内存不够、量化不足free -h、换低bit量化或减少并发Python包冲突混用环境使用虚拟环境、检查pip list6. 部署完成的收尾验证、备份与文档化服务能跑起来系统部署只能算完成了七成。剩下三成不做好后续维护会让你天天加班。验证工作要做一套可执行的测试清单。比如部署了vsftpd就从另一个客户端实际登录、上传、下载一遍部署了Loki日志系统就故意在Nginx产生一条访问日志等一分钟看Grafana里能不能查到。验证不通过的环节当场修正不要拖到交付后。系统自身也有几个指标要确认systemctl is-system-running的输出是否为running内存swap使用率磁盘根分区剩余空间负载是不是在正常区间。备份方面至少要把以下几个东西单独备份系统关键配置目录/etc、数据库数据目录、日志采集配置、部署时用的所有脚本和软件包清单。物理机和虚拟机快照做得越早越好最好在部署前做一次部署完成后做一次两次快照之间的差异就是你所有的部署改动回滚时直接回到第一次快照相当于所有步骤都白干了重新来其实这就是最好的回退保障。文档化的原则是“让一个没参与部署的人也能看懂”。以项目为维度建一个文件夹里面放三样东西部署前的需求确认和基线台账、部署过程中的操作记录和配置快照、部署后的验证结果和常见问题说明。别嫌麻烦三个月后你回来看这些文档会发现它们是你最值钱的经验资产。7. 一些部署经验上的私货最后分享几个不太会写进官方文档、但实战中特别管用的习惯。第一部署全程保留操作日志。很多人喜欢一次性输入一串命令直到报错才停下来。我的习惯是每执行一步操作就在终端前面注明这条命令的目的比如# 更新软件源、# 创建服务用户。这个日志既是排障线索也是最后写部署文档的原材料。第二遇到报错先查错误码和日志再动手改配置。部署中改配置更像是做实验一次只改一个变量改完立刻验证。很多运维事故就是嫌麻烦一次改了七八个配置项出问题后根本不知道是哪一项引起的全线回滚又浪费时间。第三多做环境复用的思考。今天部署在openEuler上的vsftpd配置明天放到Rocky Linux上大概率只是包管理器命令略有差异。所以每一份配置都要想着能通用该用变量抽出的部分就不要写死。这套“通用部署手册”的思路最终会形成一个属于自己的知识库你日常维护的机器越多这个知识库的价值就越大。部署这个活表面上是和机器打交道本质上是管理风险和效率。把流程标准化、把操作自动化、把文档沉淀好才能真正做到一次部署长期省心。希望这篇东西能让你在下一次部署时少踩几个坑哪怕只帮到一点也是值得的。 
长河君 · 2026/9/20 4:05:01 · 阅读 1.2k 系统通用部署手册：从Linux到国产系统的全场景实战指南
系统通用部署手册一套能直接抄作业的部署方法论干了这么多年部署和运维我最大的感受是部署这件事80%的坑其实都是重复的。今天装个数据库、明天搭个日志平台、后天又给客户装一套国产系统表面看是不同的事情底层流程翻来覆去就是那几步——环境评估、系统安装、初始化、装依赖、改配置、调权限、验证、收尾。可惜大多数人每次都是边装边查装完就忘下次换个环境又从零开始踩坑。这篇东西我想以“系统通用部署手册”为骨架把这些年沉淀下来的部署套路完整写一遍覆盖企业Linux、统信UOS桌面系统、openEuler、麒麟V10这些主流的服务器与桌面系统也把Grafana Loki日志系统、远程syslog服务器、vsftpd虚拟用户、甚至openEuler下的DeepSeek本地部署、Windows下的Hermes智能体部署这类具体场景串进来。不管你是刚入门的小白还是被部署流程反复折磨的运维老手这篇文章的目标只有一个让你下次拿到任何一台机器心里都有一条清晰的部署路线图。1. 部署前要想清楚的三件事需求、基线、回退1.1 先摸清需求再动工具很多部署翻车不是因为技术不行而是因为一开始就没搞清楚“要部署成什么样”。接到部署任务之后我习惯先问自己五个问题你也可以直接套用这套清单这台机器的角色是什么是生产、测试、还是临时演示生产环境部署的谨慎程度完全不同。上层业务是什么部署完要跑Web服务、数据库、日志采集、模型推理还是文件传输不同业务的系统依赖和性能需求差异非常大。硬件基线是什么CPU核数、内存大小、磁盘类型和容量、是否直通GPU。这决定了后面分区怎么切、依赖怎么装、模型能不能跑。有没有既有的规范要求比如公司规定的IP段、DNS、软件源镜像、NTP服务器或者等保要求里的密码策略、双因素认证。谁来接手维护如果后面不是我负责我需要在部署过程中留下什么文档和注释。这个阶段最忌讳的是“拿到一台机器直接开装”。我见过不少同事IP都没规划好就装系统装到一半发现网段冲突又重来一遍。多花十分钟把需求写清楚后面至少省半天返工的时间。1.2 建立部署基线与配置台账部署基线这个词听起来很正式说白了就是“这台机器从装完系统到交付所有配置项的标准答案”。我每次部署都要建一个简单的台账不需要什么高大上的CMDB一张表格就够了配置项标准值实际值备注主机名app-prod-01app-prod-01根据业务域命名IP地址192.168.10.10192.168.10.10静态IP子网掩码255.255.255.0255.255.255.0-网关192.168.10.1192.168.10.1-DNS114.114.114.114、8.8.8.8同上内网请替换时区Asia/Shanghai已确认统一使用国内时区系统语言en_US.UTF-8已确认避免乱码软件源内网镜像源已配置生产环境建议内网源内核版本锁定当前已锁定等保稳定性要求这份台账在部署前先写好一个“计划表”装完系统后再把实际结果回填两边一对比就知道哪里不一致。别小看这个动作它对排障和交接的帮助甚至比后面写的部署文档还大。1.3 回退方案不是选配而是标配很多人部署系统时满脑子都是“怎么成功”从来不考虑“失败了怎么办”。但生产环境部署回退方案的优先级应该等同正式方案。说白了就是我这么干万一干砸了能不能把系统恢复到之前的可用状态部署前的回退方案通常包括三个层次第一层是系统快照或备份。如果是虚拟机部署前一定要做一次完整快照如果是物理机至少要备份好原始的分区表和关键配置。很多服务器管理平台都支持整机快照点一下就能做别省这个动作。第二层是配置文件的备份。改任何配置文件之前先复制一份带日期的备份文件。比如要改sshd_config就先执行cp sshd_config sshd_config.bak-20240101。这个习惯一旦养成回退时就是一条命令的事。第三层是服务层的灰度与预留。如果部署的是新系统、新服务尽量保留旧版本的可执行文件或容器镜像。比如部署新版本vsftpd之前把旧版本rpm包手动缓存一份后续出问题可以直接yum本地安装回退。记住一句话没有回退方案的部署都是在赌运气。赌赢了没人夸你赌输了锅全是你的。2. 不同操作系统的部署要点速查2.1 企业级Linux最小化安装与加固基线企业Linux部署系统最常见的发行版是CentOS、Rocky Linux、AlmaLinux、Ubuntu Server以及国内的openEuler和麒麟。不管选哪个核心原则都一样能最小化就最小化能不加的包坚决不加。我在给企业部署Linux服务器时一般会遵循一套比较固定的安装选择安装模式选择Minimal或Server不装图形界面。生产服务器装GNOME既浪费资源又增加攻击面。分区方案在安装阶段就规划好。建议/boot独立分区1GBswap按业务需求设置一般4GB以上物理内存时给4GB即可需要休眠的机器除外/根分区使用LVM剩余空间都给根卷同时单独挂一份/data给业务数据。网卡命名、IP配置、主机名在安装时直接写死避免安装完成后手工改。用系统自带的SELinux或AppArmor不要一上来就禁掉。确实有兼容问题再按需调整到Permissive出问题再恢复Enforcing。安装完成之后我会立刻执行一轮基础加固这部分属于通用动作任何Linux发行版都适用# 升级所有已安装软件包 dnf update -y # 安装基础运维工具 dnf install -y vim wget curl git net-tools lsof telnet bash-completion # 修改SSH配置禁止root密码登录建议先配好密钥再改 vim /etc/ssh/sshd_config # PermitRootLogin no # PasswordAuthentication no # 重启SSH服务 systemctl restart sshd # 设置时区和时间同步 timedatectl set-timezone Asia/Shanghai systemctl enable --now chronyd这套步骤做完一台可供业务安装的基础环境就出来了。后面的所有服务部署都可以在这套基线上继续叠加。2.2 国产操作系统的安装与适配细节国产操作系统这两年在政企和关键行业用得越来越多统信UOS桌面系统、openEuler 24.03 LTS、麒麟高级服务器系统V10是三个最常见的代表。它们和传统CentOS/RHEL系有很深的渊源但又各有各的坑部署前要心里有数。先看统信UOS桌面系统。这类桌面系统主要用于办公场景安装流程和Windows、Ubuntu Desktop比较接近。需要注意的细节如下镜像建议从官网下载对应的CPU架构版本统信UOS分为amd64、arm64、mips64el等多个版本下错了直接装不上。制作启动盘时Linux下直接dd烧录Windows下用balenaEtcher或Ventoy都行。但注意UOS对UEFI Secure Boot的兼容性相对一般启动失败时先尝试关闭Secure Boot。安装过程会要求创建用户这里的用户名和密码就是后续登录系统的凭据不需要额外分配root权限给普通用户需要提权时用sudo。UOS默认使用DDE桌面环境安装完成后第一件事检查内网激活和软件源设置否则装软件会一直报错。再来说openEuler 24.03 LTS。openEuler是华为主导的开源服务器操作系统内核版本较新对AI、云原生场景的支持很积极。它的安装包管理方式很接近CentOS系用dnf/yum这对我来说是最熟悉的。openEuler 24.03 LTS默认使用Linux 6.6内核对新一代服务器硬件和GPU驱动都很友好。部署时我建议选择“服务器”安装环境磁盘分区用自动分区也行但生产环境仍然建议手工规划LVM。麒麟高级服务器系统V10也是一款和RHEL体系兼容性很好的系统dnf、yum包管理自然支持很多CentOS的部署脚本稍微改改就能跑。但有一点很多人会忽略麒麟V10不同SP版本的软件源配置不一样我记得V10-SP3的软件源地址在系统安装完后往往没有自动配置好需要手工配置或挂载本地ISO源。初装后第一时间检查源的有效性避免后面装vsftpd、pam等软件时抓瞎。2.3 Windows侧的部署思路智能体部署的场景选型Windows系统部署在通用部署里的戏份相对少但也不是没有。尤其像“Window系统如何部署Hermes智能体比较合适”这种需求实际工作中会越来越多。这里我把Windows环境下的部署选型思路讲清楚比直接给两个命令有用得多。在Windows上部署这类AI智能体或Python应用通常有三种方案第一种是原生Python环境。直接在Windows里装Python然后pip install依赖再跑模型服务。好处是路径简单、调试直观坏处是依赖管理和性能隔离都很差一旦装坏系统很难清理。第二种是WSL2。在Windows里启用Windows Subsystem for Linux跑一个完整的Linux发行版然后在Linux环境里部署。对AI、模型推理这类应用WSL2是Windows上一个很平衡的选择既能复用Linux下的成熟生态又能访问Windows文件系统性能损耗也可接受。第三种是Docker Desktop。优点是环境隔离彻底、部署可复现一条docker compose up就能把服务拉起来缺点是Windows上Docker Desktop的资源占用偏大GPU透传和USB设备透传还是远不如Linux原生流畅。我的个人建议是如果你只是要在Windows上做开发和单机测试用WSL2最合适如果考虑到后续要交付给客户或上生产优先Docker化只有在项目必须用Windows原生API的情况下才考虑原生Python环境。另外不管选哪种方案模型权重文件的目录一定要规划好Windows路径里的反斜杠和空格经常是各种脚本报错的根源宁可统一用英文短路径也不要图方便放在“D:\我的文件\New Folder”这种路径下。2.4 初始化配置的统一标准网络、源与时区不管装什么系统初始化配置里网络、软件源、时区这三样东西是必须统一的。很多部署不成功的案例最后查出来的根源往往是这三样没配好。网络的第一个要点是固定IP。服务器或者长期运行的机器生产环境必须有静态IP。如果用的是DHCPIP漂移或者其他机器占IP都会造成服务不可达排查起来非常痛苦。第二个要点是DNS配置要合理内网环境建议配置内网DNS公共DNS的组合并保证正向解析和反向解析都正常很多依赖主机名认证的服务对反解比较敏感。软件源的选择直接影响后续安装的顺畅程度。公网服务器可以用官方源内网机器强烈建议配置企业内网镜像源或本地离线源。国内常见的开源镜像站有清华TUNA、阿里云镜像、华为云镜像等openEuler有专属的mirrors麒麟系统部署时也建议优先用官方源。离线环境更直接把ISO挂载为本地源再配置好repo文件比什么都靠谱。时区的坑也很常见。系统默认时区经常是UTC业务日志里记录的时间和北京时间差了8小时排障时容易抓狂。所有系统的部署步骤里都要加上一句timedatectl set-timezone Asia/Shanghai同时打开NTP自动同步让时间保持在正确轨道上。3. 通用部署流程的标准化拆解3.1 分区方案与安装模式选择“分区怎么分”是系统部署里问得最多的问题之一。很多人习惯了“全部分给根分区”短时间没问题但遇到日志爆满或者需要扩展数据盘时就很难受。我的通用建议是这样的挂载点大小推荐格式说明/boot1GBxfs或ext4放内核和引导文件大了浪费/boot/efi512MBvfatUEFI启动必需swap4~8GBswap视内存和业务需求而定/剩余可用空间LVMxfs系统盘根分区/data独立逻辑卷xfs放业务数据方便备份和扩容对生产环境服务器我几乎一律选择LVM原因很朴素LVM可以在不重装系统的情况下扩展分区。今天你给根分区分配了100GB半年后日志容量不够了只要卷组里有剩余空间一条lvextend就能解决这在传统固定分区下是做不到的。安装模式方面能用“最小化”就不用“完整”图形界面、桌面办公套件、开发工具包这些在生产服务器上基本都是多余。少一个包就是少一个潜在漏洞。3.2 软件源、依赖与版本管理部署时经常遇到的依赖地狱其实源头往往是软件源没配好。CentOS系的经验是yum/dnf源要同时配置好base、epel和一些特殊软件需要的第三方源Debian系要处理好sources.list和apt-key问题国产系统则在初次安装后要检查源是否可用。这里我给一个openEuler的本地ISO源配置示例直接在刚装好的24.03 LTS机器上执行适合无法访问公网的服务器mkdir -p /mnt/iso mount -o loop /path/to/openEuler-24.03-LTS-x86_64.iso /mnt/iso cat /etc/yum.repos.d/openEuler-local.repo EOF [openEuler-local] nameopenEuler $releasever - Local ISO baseurlfile:///mnt/iso enabled1 gpgcheck0 EOF dnf clean all dnf makecache依赖版本的问题则要靠“环境隔离”来解决。Python项目用virtualenv/condaNode项目用nvm容器化项目直接用Docker。部署AI模型、智能体这类依赖很复杂的服务时一定要把依赖锁在虚拟环境里不要让pip直接装到系统Python目录否则很容易和系统原有包冲突。3.3 用户、权限与基本安全设置很多部署习惯是“所有服务都用root跑”图省事。这在测试环境可以生产环境绝对不行。原因是多方面的服务被攻破后攻击者直接获得最高权限多个服务共用一个root账号日志审计根本分不清谁干了什么权限过大也容易误操作。通用做法是为每个服务创建独立的系统用户只赋予它运行服务所需的最小权限。给出的命令示例# 创建独立运行用户不登录shell不建立home目录 useradd -r -s /sbin/nologin -M myservice # 授权日志目录 mkdir -p /var/log/myservice chown -R myservice:myservice /var/log/myservice # 服务配置文件只允许root读 chown root:root /etc/myservice.conf chmod 600 /etc/myservice.conf文件权限的基线也很清晰配置文件600可执行文件755数据文件根据是否需要外部访问来定640或660。SELinux如果开启的话还要给服务设置正确的SELinux上下文这个后面第五节展开讲。3.4 可复用的一键初始化脚本示例部署经验积累到一定程度就应该沉淀成自动化脚本。下面这个init.sh是我日常部署Linux服务器时反复在用的模板你可以根据自己的环境需求增删改#!/bin/bash # 系统初始化脚本适用于CentOS/RHEL/openEuler/Kylin # 用法sudo bash init.sh set -e # 1. 确认以root运行 if [ $EUID -ne 0 ]; then echo 请使用root用户运行 exit 1 fi # 2. 设置时区 timedatectl set-timezone Asia/Shanghai # 3. 配置主机名通过参数传入 HOSTNAME${1:-server-unknown} hostnamectl set-hostname $HOSTNAME # 4. 更新系统并安装常用工具 dnf update -y dnf install -y vim wget curl git net-tools lsof telnet bash-completion parted # 5. 关闭NetworkManager或确认网络服务正常 systemctl enable --now network 2/dev/null || true # 6. 配置SSH保留密码登录生产环境再改为密钥 sed -i s/^#PermitRootLogin yes/PermitRootLogin prohibit-password/ /etc/ssh/sshd_config systemctl restart sshd # 7. 关闭或配置firewalld systemctl enable --now firewalld # 8. 内网环境替换软件源请在这里添加 sed 操作 echo 系统初始化完成。脚本的核心目的不是炫技而是保证每一台机器经过同样的步骤、达到同样的状态。这种可复现性正是项目标题“系统通用部署手册”想表达的核心价值——手册不是给人看的是要能指导自动化执行的。4. 典型业务场景部署实操4.1 轻量级Grafana Loki日志系统部署日志系统是很多企业内部刚需但Elasticsearch那套重维护成本高。Grafana Loki是一个很适合中小规模的轻量级日志聚合方案它通过标签索引代替全文索引资源消耗小很多。我部署Loki时习惯用Docker Compose三件套一次拉起来promtail采集日志、loki存储日志、grafana展示日志。下面是一份可以直接用的docker-compose.yml简化版部署前请确认主机已安装Docker和Docker Composeversion: 3.9 services: loki: image: grafana/loki:2.9.2 ports: - 3100:3100 volumes: - ./loki-config.yaml:/etc/loki/local-config.yaml command: -config.file/etc/loki/local-config.yaml promtail: image: grafana/promtail:2.9.2 volumes: - /var/log:/var/log:ro - ./promtail-config.yaml:/etc/promtail/config.yml command: -config.file/etc/promtail/config.yml grafana: image: grafana/grafana:10.1.4 ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin123promtail配置的核心在scrape_configs它决定采集哪些日志、打上什么标签。假设要采集Nginx访问日志并按照host标签区分scrape_configs: - job_name: nginx static_configs: - targets: [localhost] labels: job: nginx __path__: /var/log/nginx/*.log启动之后访问Grafana的3000端口添加数据源时选Loki地址填http://loki:3100或宿主机IP:3100然后就能在Explore里用LogQL查询日志了。LogQL的语法和PromQL有相似之处例如{jobnginx}就能筛选出Nginx日志。这套系统在单机日志量每天几个GB的场景下非常稳几十台机器完全扛得住。但日志量要是每天上TB还是趁早换Elasticsearch或者ClickHouse这类方案。4.2 远程syslog日志服务器部署和Loki这类新晋日志系统相比syslog仍然是网络设备和很多Linux服务日志传递的标准协议。部署远程syslog服务器核心就是把Linux自带rsyslog从“本地写日志”改成“接收远程日志”。服务端操作如下假设角色是集中式日志接收服务器# 编辑rsyslog配置 vim /etc/rsyslog.conf # 取消以下行注释启用TCP和UDP的514端口接收 # module(loadimudp) # input(typeimudp port514) # module(loadimtcp) # input(typeimtcp port514) # 增加远程日志接收模板按主机名和程序名分类存储 $template RemoteLogs,/data/syslog/%fromhost-ip%/%programname%.log *.* ?RemoteLogs # 重启服务 systemctl restart rsyslog # 放行防火墙 firewall-cmd --permanent --add-port514/tcp firewall-cmd --permanent --add-port514/udp firewall-cmd --reload客户端只要在/etc/rsyslog.conf末尾加一行把所有日志实时转发到服务端*.* 192.168.10.20:514注意是UDP是TCP。内网环境我一般用TCP因为UDP丢包不重传日志会悄悄消失。syslog服务器本身没多少技术含量但踩坑点集中在两个地方一是防火墙514端口是特权端口如果配置没生效会一直收不到日志二是SELinuxrsyslog要写/var/log之外的自定义目录时会被SELinux拦截需要执行semanage fcontext -a -t var_log_t /data/syslog(/.*)?然后restorecon -Rv /data/syslog。4.3 麒麟V10部署vsftpd并创建虚拟用户麒麟高级服务器系统V10-SP3部署vsftpd并创建虚拟用户是文件服务场景里非常典型的需求。之所以用虚拟用户而不是直接用系统用户核心原因是安全和管理便利虚拟用户不能登录系统也不占系统账号批量管理和权限控制都很方便。先安装相关软件包dnf install -y vsftpd db4-utils然后准备虚拟用户口令文件。格式是每两行一组奇数行是用户名偶数行是密码cat /etc/vsftpd/vusers.txt EOF zhangsan passwd123 lisi passwd456 EOF生成Berkeley DB数据库文件cd /etc/vsftpd db_load -T -t hash -f vusers.txt /etc/vsftpd/vusers.db chmod 600 /etc/vsftpd/vusers.db # 删除明文口令文件 rm -f vusers.txt配置PAM认证让vsftpd使用刚生成的数据库做密码校验。修改/etc/pam.d/vsftpdauth required pam_userdb.so db/etc/vsftpd/vusers account required pam_userdb.so db/etc/vsftpd/vusers接着创建一个系统账户作为虚拟用户的映射身份所有虚拟用户登录后都会映射到这个本地用户useradd -d /data/ftp -s /sbin/nologin vftp chown -R vftp:vftp /data/ftp再修改vsftpd主配置文件/etc/vsftpd/vsftpd.conf核心参数如下anonymous_enableNO local_enableYES write_enableYES local_umask022 guest_enableYES guest_usernamevftp chroot_local_userYES allow_writeable_chrootYES pam_service_namevsftpd pasv_min_port30000 pasv_max_port31000每个虚拟用户的独立权限可以在/etc/vsftpd/下建目录按文件名对应虚拟用户名放置配置文件。比如只允许zhangsan上传但禁止lisi上传给zhangsan建/etc/vsftpd/vusers.d/zhangsan内容为anon_world_readable_onlyNO、write_enableYESlisi的配置就不写write_enableYES。最后配置防火墙和SELinuxfirewall-cmd --permanent --add-port20-21/tcp firewall-cmd --permanent --add-port30000-31000/tcp firewall-cmd --reload setsebool -P allow_ftpd_full_access on setsebool -P ftpd_use_passive_mode on这里有个非常隐蔽的坑如果vsftpd开启了chroot并且用户主目录当前是可写的高版本vsftpd会拒绝登录报500 OOPS错误。所以要么把vftp的home设为/data/ftp但ftp目录权限不要给write再建一个子目录做上传目录要么启用allow_writeable_chrootYES。4.4 openEuler 24.03 LTS下本地模型与评估框架的部署最近DeepSeek本地部署很火openEuler 24.03 LTS做AI模型的本地环境确实合适。这里说的不只模型本身还包括评估框架harness的安装。很多人一提到本地模型部署就以为要GPU其实中低规格的CPU机器也能跑小尺寸蒸馏模型只是速度和吞吐量别期待太高。先说硬件基线。如果跑DeepSeek-R1-Distill-Qwen-7B这类7B左右的模型量化后需要大约6-8GB内存空间机器内存建议不低于16GB。如果跑13B以上模型32GB内存起步建议有GPU加速。在openEuler 24.03 LTS上的安装步骤分四步第一步安装基础编译依赖dnf install -y git gcc gcc-c make cmake python3-devel第二步创建独立的Python虚拟环境python3 -m venv /opt/deepseek-env source /opt/deepseek-env/bin/activate pip install --upgrade pip第三步安装PyTorch和transformers生态。CPU版本先按CPU安装有NVIDIA GPU再换成CUDA版本pip install torch --index-url https://download.pytorch.org/whl/cpu pip install transformers datasets accelerate sentencepiece第四步安装lm-evaluation-harness这是“deepseek harness”里最常指的那个评估框架git clone https://github.com/EleutherAI/lm-evaluation-harness.git cd lm-evaluation-harness pip install -e .模型权重下载可以借助huggingface-cli把DeepSeek蒸馏版模型拉到本地然后在harness里跑评测。实际运行中模型首次加载会比较慢因为要反序列化权重文件。为了加速可以先转成safetensors格式再利用。评估任务跑起来后CPU推理会非常耗时一个简单的评测集合跑上几个小时都正常做计划时要有预期。对没有GPU的环境更推荐用llama.cpp配合GGUF量化模型。用llama-cpp-python加载q4_K_M量化文件内存占用能再降三分之一单机部署体验会好很多。这个方向后续再单独写今天先给出主线部署路径。4.5 Windows下部署Hermes智能体的选型建议前面2.3节已经说了WSL2、Docker、原生Python三种方式的取舍。这里补充一些Hermes智能体部署的具体操作思路。所谓智能体部署一般可以拆成三块运行环境、模型或API连接、调度服务。我的推荐组合是WSL2 Miniconda Python虚拟环境。以管理员身份打开PowerShell执行wsl --install -d Ubuntu-22.04然后进入WSL后安装Minicondawget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p ~/miniconda3 eval $(~/miniconda3/bin/conda shell.bash hook) conda create -n hermes python3.10 -y conda activate hermes git clone hermes仓库地址 cd hermes pip install -r requirements.txt模型部分有两种情况如果Hermes调用的是云端API直接在配置文件里设置API Key就行如果在本地加载模型可以参照4.4节在WSL2内安装PyTorch和transformers。Windows本地的CUDA在WSL2里一般是透传可用如果跑N卡建议直接安装支持CUDA的PyTorch版。服务调度方面开发测试阶段前台运行方便看日志正式一点可以在WSL2里用systemd或supervisor来守护进程。WSL2在较新版本中默认支持systemd通信协议也做了适配Windows开机自启时把wsl命令写到“启动”文件夹里wsl.exe -d Ubuntu-22.04 -u root -- supervisorctl start hermes这套方案的核心优势是你在WSL2里获得了一个和Linux服务器几乎一致的环境后续想迁到云服务器或企业Linux服务器几乎不用改代码。5. 部署过程中的常见问题与排查实录5.1 部署失败的第一诊断思路部署失败时新手容易慌老手先看日志。所有的部署问题排查我建议遵循一个固定的顺序看服务状态、看系统日志、看应用日志、复现操作。以systemd管理的服务为例一套组合拳打过去systemctl status nginx journalctl -u nginx --no-pager -n 50 tail -f /var/log/nginx/error.log看到什么报错再往下定位。如果连状态都是active那就用curl、telnet、ss这些工具按网络链路来查。部署问题百分之八十都能靠日志解决剩下的才涉及配置语义、版本兼容这些需要靠经验判断的问题。5.2 网络和软件源问题软件源出问题的表现通常是yum install或者apt install时报404、Could not resolve host、Connection refused。排查顺序是# 1. 确认能否解析域名 nslookup mirrors.aliyun.com # 2. 确认能否连通镜像源 curl -I https://mirrors.aliyun.com # 3. 查看当前repo配置 yum repolist cat /etc/yum.repos.d/*.repo常见解法是换源。把baseurl改成内网镜像地址或者改用本地ISO挂载源。这里提醒一点改完源之后一定要dnf clean all dnf makecache否则缓存里的旧元数据会持续报错。5.3 依赖冲突与编译器版本问题编译安装是部署中最容易翻车的场景。最常见的是gcc版本太老编译新版本软件时报unknown type name、未定义的引用等错误。建议安装BuildTools组包一次性把各种开发工具都补充完整dnf groupinstall -y Development ToolsPython层面的依赖冲突也经常出现升级某个包之后其他包崩了。2024年以来Python 3.12对部分老库的兼容性依然存在比如一些C扩展模块还没有预编译wheel。解决方案很简单用适合项目的Python版本创建虚拟环境锁版本requirements.txt禁止随意pip install --upgrade到全局。5.4 权限、SELinux和防火墙问题运维界有个经典笑话服务起不来关了SELinux试试能起来了于是把SELinux彻底关掉。很多部署文档也这样写给生产埋下大雷。实际上SELinux的问题正确动作是调整策略而不是关闭权威保护机制。排查SELinux拦截的最直接命令是ausearch -m avc -ts recent或者临时用setenforce 0再测试服务是否恢复正常。如果确实是SELinux拦截就用semanage调整上下文或布尔值。例如vsftpd需要开放FTP相关端口和目录写权限执行setsebool -P allow_ftpd_full_access on再配合semanage fcontext定义自定义目录的类型。文档里我建议统一写清楚这些策略调整动作不要动不动就setenforce 0还因为重启后自动恢复而误“修好”了问题。防火墙问题的表现也很典型本机能访问局域网其他机器访问不了。先看监听地址是不是0.0.0.0再看firewalld或ufw规则最后用nc、telnet从客户端测试端口通不通。一层层排查基本都能定位。5.5 排查速查表症状优先排查项常用命令/操作服务启动失败配置文件语法、日志journalctl -u 服务名 --no-pager -n 50端口无监听服务未启动或监听地址错误ss -lntp外部无法访问防火墙、安全组、SELinuxfirewall-cmd --list-all安装软件报404软件源失效yum repolist、curl -I 源地址编译报gcc错误编译器版本、依赖库缺失dnf groupinstall Development Tools登录FTP报500 OOPSchroot目录可写、PAM配置检查vsftpd.conf、PAM模块模型推理OOM内存不够、量化不足free -h、换低bit量化或减少并发Python包冲突混用环境使用虚拟环境、检查pip list6. 部署完成的收尾验证、备份与文档化服务能跑起来系统部署只能算完成了七成。剩下三成不做好后续维护会让你天天加班。验证工作要做一套可执行的测试清单。比如部署了vsftpd就从另一个客户端实际登录、上传、下载一遍部署了Loki日志系统就故意在Nginx产生一条访问日志等一分钟看Grafana里能不能查到。验证不通过的环节当场修正不要拖到交付后。系统自身也有几个指标要确认systemctl is-system-running的输出是否为running内存swap使用率磁盘根分区剩余空间负载是不是在正常区间。备份方面至少要把以下几个东西单独备份系统关键配置目录/etc、数据库数据目录、日志采集配置、部署时用的所有脚本和软件包清单。物理机和虚拟机快照做得越早越好最好在部署前做一次部署完成后做一次两次快照之间的差异就是你所有的部署改动回滚时直接回到第一次快照相当于所有步骤都白干了重新来其实这就是最好的回退保障。文档化的原则是“让一个没参与部署的人也能看懂”。以项目为维度建一个文件夹里面放三样东西部署前的需求确认和基线台账、部署过程中的操作记录和配置快照、部署后的验证结果和常见问题说明。别嫌麻烦三个月后你回来看这些文档会发现它们是你最值钱的经验资产。7. 一些部署经验上的私货最后分享几个不太会写进官方文档、但实战中特别管用的习惯。第一部署全程保留操作日志。很多人喜欢一次性输入一串命令直到报错才停下来。我的习惯是每执行一步操作就在终端前面注明这条命令的目的比如# 更新软件源、# 创建服务用户。这个日志既是排障线索也是最后写部署文档的原材料。第二遇到报错先查错误码和日志再动手改配置。部署中改配置更像是做实验一次只改一个变量改完立刻验证。很多运维事故就是嫌麻烦一次改了七八个配置项出问题后根本不知道是哪一项引起的全线回滚又浪费时间。第三多做环境复用的思考。今天部署在openEuler上的vsftpd配置明天放到Rocky Linux上大概率只是包管理器命令略有差异。所以每一份配置都要想着能通用该用变量抽出的部分就不要写死。这套“通用部署手册”的思路最终会形成一个属于自己的知识库你日常维护的机器越多这个知识库的价值就越大。部署这个活表面上是和机器打交道本质上是管理风险和效率。把流程标准化、把操作自动化、把文档沉淀好才能真正做到一次部署长期省心。希望这篇东西能让你在下一次部署时少踩几个坑哪怕只帮到一点也是值得的。