1. 为什么离线装 OpenOffice 这件事比想象中更折腾在完全断网或者内网隔离的 CentOS 8 机器上装 OpenOffice很多人第一反应是下个 rpm 包rpm -ivh一把梭。我最早也是这么想的结果在一台内网服务器上折腾了整整一个下午才跑通。原因很简单OpenOffice 的 rpm 包之间依赖关系盘根错节而 CentOS 8 默认的软件源里根本没有 OpenOfficeyum在离线状态下既不能联网拉依赖也不能自动解决包冲突。你手里只有几个孤零零的 rpm 文件系统却告诉你缺了一堆.so库和基础组件。这篇文章面向的是需要在无外网环境下部署文档处理能力的运维和开发人员。典型场景包括内网办公服务器需要批量做 Word/Excel 到 PDF 的格式转换、某台隔离机器要跑文档预览服务、或者单纯就是公司安全策略不允许生产机连外网。我会把整个流程拆成准备什么包、怎么传进去、按什么顺序装、装完怎么验证、出问题怎么查这几块每一步都给出背后的理由而不是甩一串命令让你照抄。需要先明确一个概念离线安装的核心难点从来不是安装这个动作而是依赖闭环。在线安装时yum帮你做了依赖解析和下载离线时这个活儿得你自己干。所以整篇文章的主线就是教你怎么把依赖这件事在离线条件下搞定。理解了这条主线后面所有操作你都能自己想明白而不是死记命令。另外提前说一句OpenOffice 和 LibreOffice 经常被拿来比较。两者同源LibreOffice 是 OpenOffice 的分支功能更活跃、更新更勤。但很多老系统、老脚本、老接口是围绕 OpenOffice 的soffice命令和它的目录结构写的迁移成本不低所以必须装 OpenOffice的需求是真实存在的。本文只讲 OpenOffice 的离线部署不展开两者选型之争。2. 离线包从哪来在一台联网机器上把依赖闭环凑齐2.1 先搞清楚要装的是哪个版本、哪个架构OpenOffice 目前主流的稳定版本是 4.1.x 系列官方提供 rpm 和 deb 两种包格式CentOS 8 用的是 rpm。架构上现在绝大多数服务器是 x86_64但如果你面对的是 ARM 服务器比如某些国产化平台那就得找对应的 aarch64 包这一步搞错了后面全白搭。我建议在动手前先确认三件事目标机器的 CPU 架构uname -m输出x86_64还是aarch64目标机器的系统版本cat /etc/redhat-release确认是 CentOS 8 而不是 7 或 Stream目标机器是否装了图形环境OpenOffice 严格来说依赖一些图形库即使你只用命令行转换也需要部分 X11 相关库提示很多人以为服务器上跑soffice --headless就完全不需要图形库这是误解。headless 模式只是不弹窗口底层仍然会链接部分图形相关的.so缺了照样报错。2.2 用一台联网的同版本机器做依赖采集最稳的做法是找一台和目的一模一样的联网 CentOS 8 机器同架构、同小版本在上面用yum把 OpenOffice 及其全部依赖下载下来而不是只下主包。具体思路是借助yumdownloader或者dnf download配合--resolve参数把依赖树一次性拉全。如果你能拿到 OpenOffice 官方提供的 rpm 包集合它通常是一个压缩包解压后是一堆 rpm那更好因为官方包里已经包含了大部分运行时依赖。但即便如此系统级的基础库比如某些libX系列、字体包还是可能缺需要额外补。采集依赖时我常用的命令逻辑是这样的# 在联网机器上先装好 yum-utils dnf install -y yum-utils # 把目标 rpm 及其所有依赖下载到指定目录 dnf download --resolve --alldeps --destdir/tmp/oa_pkgs /path/to/openoffice.rpm--resolve会解析依赖--alldeps会把所有层级的依赖都拉下来。跑完之后/tmp/oa_pkgs里就是一套相对完整的包集合。这里有个坑dnf download默认只下载能通过仓库解析到的依赖如果某个依赖在系统里已经装了它可能不下载。所以更保险的做法是在一台最小化安装的干净 CentOS 8 上做采集这样依赖树最完整。2.3 别忘了字体和语言包这两个隐形依赖文档转换场景里字体缺失是最容易被忽略、又最影响结果的问题。OpenOffice 本身不带中文字体如果你要转换的文档里有中文而目标机器没装中文字体转出来的 PDF 里中文会变成方块或者直接丢失。所以离线包里一定要带上字体比如常见的中文字体包。语言包同理。OpenOffice 的界面和拼写检查依赖语言包虽然 headless 转换不一定用到界面但某些文档属性处理会涉及。稳妥起见把openoffice的语言包也一并下载。我一般会把离线包目录整理成这样的结构方便后续管理oa_offline/ ├── core/ # OpenOffice 主程序 rpm ├── deps/ # 系统依赖 rpm ├── fonts/ # 字体 rpm 或 ttf 文件 └── lang/ # 语言包 rpm分目录不是为了好看而是安装时你能按先依赖、后主程序、再字体语言的顺序来出问题也容易定位是哪一类包的问题。3. 把包搬进内网并建立本地仓库3.1 传输方式的选择与校验包采集好之后要弄进内网。传输方式取决于你的环境U 盘、内网文件服务器、跳板机中转都行。这里不展开具体工具重点说校验这一步千万别省。rpm 包在多次拷贝、压缩解压过程中损坏的概率不低装到一半报包损坏能让你怀疑人生。传输完成后进到包目录跑一遍校验# 对每个 rpm 做完整性校验 for f in *.rpm; do rpm -K $f; done输出里带OK的才是好的。如果嫌一个个看麻烦可以过滤出失败的for f in *.rpm; do rpm -K $f | grep -v OK$ echo 损坏: $f; done3.2 用 createrepo 建本地源比裸 rpm 安装省心得多直接rpm -ivh *.rpm的问题是rpm 不会自动处理安装顺序遇到依赖没装就报错你得反复试。更好的办法是把所有 rpm 放进一个目录用createrepo生成仓库元数据然后配置一个本地 yum 源让dnf来帮你解析依赖和顺序。# 安装 createrepo如果联网机器上有把它的 rpm 也带上 dnf install -y createrepo # 在离线机器上把所有 rpm 放到一个目录 mkdir -p /opt/local_repo cp /path/to/oa_offline/**/*.rpm /opt/local_repo/ # 生成仓库元数据 createrepo /opt/local_repo然后新建一个 repo 配置文件cat /etc/yum.repos.d/local-oa.repo EOF [local-oa] nameLocal OpenOffice Repo baseurlfile:///opt/local_repo enabled1 gpgcheck0 EOFgpgcheck0是因为我们自己打的包没有签名内网环境可以接受。配好之后dnf clean all dnf makecache再dnf install openoffice依赖就自动解决了。注意createrepo这个工具本身也可能不在离线机器上所以采集依赖时记得把它也带上。这是个特别容易漏的点我踩过。3.3 如果坚持用 rpm 直接装顺序怎么定有些环境不允许配本地源只能裸 rpm 装。那顺序原则是先装被依赖的再装依赖别人的。判断方法是用rpm -qpR xxx.rpm看某个包需要哪些依赖被需要的先装。实际操作中OpenOffice 的包大致按这个顺序比较稳系统基础库各种lib*、fontconfig等OpenOffice 的ure和core基础包OpenOffice 的base、calc、writer、impress等组件包语言包和字体装的时候用rpm -ivh --nodeps强行跳过依赖检查是下策能不用就不用因为它会把问题推迟到运行时爆发更难查。4. 安装后的验证与 headless 转换实测4.1 确认 soffice 能跑起来装完之后第一件事是确认命令可用which soffice soffice --version如果which找不到说明安装路径没进 PATH。OpenOffice 通常装在/opt/openoffice4/program/下可以手动加软链ln -s /opt/openoffice4/program/soffice /usr/local/bin/sofficesoffice --version能正常输出版本号说明主程序没问题。如果报缺库用ldd查ldd /opt/openoffice4/program/soffice.bin | grep not found把缺的库对应的 rpm 补上即可。4.2 headless 模式转换文档的完整命令验证功能最直接的方式是拿一个文档转 PDFsoffice --headless --invisible --norestore --convert-to pdf --outdir /tmp/output /tmp/test.docx参数逐个解释一下这些不是随便加的--headless无界面模式服务器必备--invisible不显示任何界面元素--norestore不尝试恢复上次会话避免残留进程干扰--convert-to pdf目标格式也可以换成docx、xlsx等--outdir输出目录不指定会输出到当前目录实测下来第一次转换会慢一些因为 OpenOffice 要初始化用户配置目录。之后会快很多。这里有个关键坑如果同时并发跑多个soffice转换会因为用户配置目录锁冲突而失败。解决办法是给每个进程指定独立的配置目录soffice --headless -env:UserInstallationfile:///tmp/soffice_$$ --convert-to pdf ...$$是当前进程号保证每个进程用独立的配置目录并发就不会打架。这个技巧在批量转换场景里几乎是必须的。4.3 中文字体验证不能只看转换成功转换命令返回成功不代表结果正确。一定要打开生成的 PDF 确认中文显示正常。我遇到过转换成功但 PDF 里中文全是方块的案例根因就是字体没装。验证字体是否被识别fc-list :langzh如果输出为空说明系统里没有中文字体需要把字体文件拷到/usr/share/fonts/下再fc-cache -fv刷新缓存。5. 那些让我返工的坑依赖、权限与进程残留5.1 依赖缺失的报错信息往往具有误导性离线安装最折磨人的是依赖报错。比如报libXinerama.so.1 is needed你去找这个库的 rpm 装上结果又报另一个库。这是因为依赖是链式的缺一个会暴露下一个。我的经验是一次性把所有报错收集齐再动手。用rpm -ivh装的时候加--test参数先做测试安装它会列出所有缺失的依赖而不实际安装rpm -ivh --test /opt/local_repo/openoffice*.rpm 21 | grep is needed把列出来的依赖一次性找齐比装一个报一个效率高得多。5.2 权限问题别用 root 跑转换服务OpenOffice 官方明确不建议用 root 直接跑soffice会有权限和安全上的隐患。正确做法是建一个专用用户useradd -r -s /sbin/nologin oasvc然后用这个用户跑转换。但这里有个连带问题专用用户对输出目录、配置目录都要有写权限否则会静默失败。我一般会提前把相关目录的属主改好mkdir -p /var/lib/oasvc /var/output chown -R oasvc:oasvc /var/lib/oasvc /var/output5.3 进程残留导致后续转换全部卡死这是最隐蔽的坑。soffice有时候转换完不会自己退出会留一个后台进程。下次再跑转换时新进程发现配置目录被占用就一直等待表现为命令卡住不动。排查方法ps -ef | grep soffice如果发现有残留进程先杀掉再重试。长期方案是在脚本里加超时和清理逻辑timeout 120 soffice --headless ... pkill -u oasvc soffice 2/dev/nulltimeout保证单次转换不会无限等待pkill清理残留。这两个配合使用后我的批量转换脚本再没卡死过。6. 批量转换脚本的工程化写法6.1 一个能直接用的转换脚本骨架把前面所有经验揉在一起我常用的脚本结构是这样的#!/bin/bash # 批量文档转 PDF INPUT_DIR$1 OUTPUT_DIR$2 CONCURRENCY4 mkdir -p $OUTPUT_DIR convert_one() { local src$1 local base base$(basename $src) local tmpcfg tmpcfg$(mktemp -d) timeout 180 soffice --headless --invisible --norestore \ -env:UserInstallationfile://$tmpcfg \ --convert-to pdf --outdir $OUTPUT_DIR $src local ret$? rm -rf $tmpcfg if [ $ret -ne 0 ]; then echo FAILED: $src $OUTPUT_DIR/error.log fi } export -f convert_one export OUTPUT_DIR find $INPUT_DIR -type f \( -name *.doc -o -name *.docx -o -name *.xls -o -name *.xlsx \) \ -print0 | xargs -0 -P $CONCURRENCY -I {} bash -c convert_one $ _ {}这个脚本的几个设计点值得说每个任务用独立的临时配置目录解决并发冲突timeout防止单个文件卡死拖垮整批失败的文件记录到日志方便事后重跑xargs -P控制并发数别开太大OpenOffice 吃内存6.2 并发数到底开多少合适这个没有标准答案取决于机器配置。我的经验值是每 2GB 可用内存开 1 个并发。OpenOffice 单个转换进程内存占用在 200MB 到 500MB 之间波动文档越复杂越高。开太多会导致内存不足进程被 OOM 杀掉反而更慢。可以先小批量测试观察内存和 CPU# 转换过程中监控 watch -n 1 free -m; ps -ef | grep -c soffice找到不触发 swap、CPU 没跑满的并发数就是这台机器的甜点值。6.3 转换失败的常见原因对照表现象可能原因排查方向命令卡住不返回配置目录被占用检查残留 soffice 进程PDF 中文变方块缺中文字体fc-list :langzh是否为空报缺 .so 库依赖没装全ldd查具体缺哪个转换成功但文件为空输出目录无写权限检查目录属主和权限部分文件失败文档本身损坏或加密单独手动转换该文件看报错这张表是我踩坑踩出来的遇到问题先对照能省不少时间。7. 关于离线部署这件事的一点个人体会折腾完这一整套我最大的感受是离线安装的功夫八成花在准备阶段而不是安装阶段。真正在目标机器上敲命令的时间可能就几分钟但在联网机器上采集依赖、校验包完整性、整理目录结构往往要花掉大半天。所以如果你经常要做这类离线部署值得把这套流程脚本化、模板化下次换个软件也能复用。另外字体这个问题我要再强调一次。文档转换类需求里字体缺失导致的问题占了至少一半而且它不会让命令报错只会让结果悄悄出错特别难发现。我的习惯是任何离线部署文档处理能力的场景先把中文字体装好、fc-cache刷新、fc-list验证这三步做完再谈其他。最后分享一个后续可以扩展的方向如果你需要的不只是转换而是文档内容提取、格式批量处理可以在 OpenOffice 的 UNO 接口上做二次开发用 Python 调用它做更精细的控制。不过那就是另一个话题了离线部署这一关先过了再说。