1. 为什么非要在纯命令行的CentOS 7上装向日葵

1.1 我遇到的实际场景：一台没有桌面的服务器需要图形远程

先交代一下背景。我之前帮朋友维护一台机房里的 CentOS 7 机器，系统是最小化安装的，连桌面环境都没装，平时全靠 SSH 登进去敲命令。某天客户需要远程看一下服务器上某个图形化工具的界面，还希望能在界面上直接点两下演示给他们看。SSH 干不了这事儿，我在现场又没法跑一趟机房，只能想别的办法。

这时候我第一个想到的其实是 VNC，但折腾了一圈发现配置成本太高：要装 tigervnc-server、设置密码、改 xstartup、还要处理本地回环和防火墙，更麻烦的是这台机器在 NAT 后面，根本没有公网 IP，VNC 要对外提供服务还得先在路由器上做端口映射。我连路由器后台都进不去，这条路直接堵死。

后来想到向日葵。向日葵的核心模式是"识别码 + 验证码"，由客户端主动向云端发起连接，不需要公网 IP，也不需要你在路由器上开端口，远程连接的时候对面只需要拿到你的识别码和验证码，在任意一台有向日葵客户端的设备上输入就能连过来。这就非常适合内网服务器、无公网 IP 的机器，以及像我这种只能通过 SSH 远程操作的场景。

没错，向日葵并不是只能在 Windows 或带桌面的 Linux 上装。它其实有一整套 Linux 版客户端，在纯命令行的 CentOS 7 环境下也能通过 rpm 包安装，装完以后守护进程在后台运行，不需要你自己去启动图形界面。关键在于安装过程要足够"干净"，全程不依赖浏览器，全凭命令完成。这篇文章就是把我在 CentOS 7 最小化安装环境下纯命令行部署向日葵的完整过程、踩过的坑、以及排查思路都记录下来，给同样需要在无头服务器上装远程控制软件的朋友一个参考。

1.2 先确认系统和环境，别急着找安装包

很多人在这一步容易翻车：下载了 rpm 包，结果架构不对，安装的时候直接报错"wrong architecture"。所以不管多着急，动手之前先把系统和机器架构确认清楚。

在 SSH 终端里依次执行这几条命令：

cat /etc/redhat-release uname -m

cat /etc/redhat-release会显示当前系统版本，比如 CentOS Linux release 7.9.2009 (Core)。uname -m会显示机器架构，绝大多数服务器是 x86_64，但如果你用的是 ARM 架构的国产机器或者树莓派类似的板子，这里会显示 aarch64。向日葵的 Linux 版对 x86_64 的支持是最成熟的，aarch64 部分版本也有，但安装包必须对应，混着装必挂。

接下来看网络环境。向日葵的客户端需要和向日葵云端服务器通信，如果服务器不通外网，那装完之后也没法完成连接。用最简单的命令测一下：

curl -I https://www.oray.com

能返回 HTTP 响应头，说明外网通路基本没问题。这一步很重要，特别是那些部署在客户内网、只开放了特定端口出站的机器，如果不提前确认，后面排查起"连不上"的问题会非常痛苦。

1.3 为什么不推荐 VNC：几个方案放在一起看你就能做决定了

我当时的处境是"无桌面、无公网 IP、只有 SSH"。如果你也遇到类似的限制，可以先把常见方案摆在一起对比一下，再决定用哪个。

看表格就明白了。VNC 这类传统方案本身没有穿透能力，要暴露到外网必须额外配置端口映射或者搭 frp 跳板机，配置链路很长。向日葵把"识别码"和"云端调度"打包在客户端里，相当于把穿透这件事做成了默认能力，对没有公网 IP 的机器是天然友好的。

不过我也要说清楚：向日葵是商用软件，个人使用免费版就能满足基本的远程桌面、远程文件功能，但它在 Linux 端的体验和 Windows 端有差距，比如某些版本不提供完整的命令行帮助文档，远程画面在某些极简环境下还可能出现黑屏。这些坑我下面会专门讲，你现在先记住一句话：向日葵适合的是"快速、省事、不折腾网络"的场景，而不是"追求极致的图形性能"的场景。

2. 下载安装包：没有浏览器的服务器怎么把 rpm 拿下来

2.1 官方渠道获取正确的 rpm 包

纯命令行环境最大的问题是没有浏览器，你不能像在 Windows 上那样打开官网下载页再点"下载"。但换个思路：你在任何一台能上网的电脑上打开向日葵官网的下载中心，找到 Linux 版，选择对应的发行版和架构，右键复制下载链接，然后拿到服务器上用 wget 或 curl 去拉。

这里特别提醒一句：千万不要图省事在一些第三方软件站或者某个博客的附件里下安装包。向日葵 Linux 版的安装包是编译好的二进制，来历不明的包很可能被塞进额外的东西，尤其是这种跑在服务器上的远程控制软件，一旦被动手脚，等于把服务器后门交到别人手里。我从来只认准官网下载页的 CDN 链接。

官网下载页里 Linux 版的 rpm 包命名一般类似：

SunloginClient-15.2.0.63064.x86_64.rpm

版本号会随官方更新而变化，不必纠结数字本身。你只需要确认两件事：后缀是.x86_64.rpm，并且匹配当前系统的架构。

拿到链接之后，先别急着下载，在服务器上用curl -I验证一下链接是否有效：

curl -I "https://官方下载链接/SunloginClient-15.2.0.63064.x86_64.rpm"

返回 200 就可以放心用 wget 拉取。这个习惯能帮你避开很多坑，比如官网改版后链接失效、或者 CDN 临时抽风，提前验证比下载到一半才发现要省时间得多。

2.2 装依赖前先修好 yum 源：CentOS 7 停更后的第一个坑

这一步是我这次安装过程中遇到的最大的坑，也最容易被教程忽略。CentOS 7 官方已经停止维护了，默认的 yum 源地址mirrorlist.centos.org基本处于失效状态，直接执行任何需要联网装依赖的命令，都会报类似这样的错误：

Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was 14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"

向日葵的 rpm 包安装时虽然自带了很多库，但依然可能有依赖需要从 yum 源里拉取，所以源不修好，后面的yum localinstall可能直接失败。我在第一次操作的时候就被这个报错卡了十几分钟，最后把源切到 Vault 才解决问题。

所谓 Vault，就是 CentOS 官方存放历史版本软件包的仓库。CentOS 7 停更后，所有旧版本的软件包都被归档到这个地址。你只需要修改/etc/yum.repos.d/CentOS-Base.repo，把里面的mirrorlist行注释掉，baseurl指向 Vault 就行了。大致配置长这样：

[base] name=CentOS-$releasever - Base baseurl=https://vault.centos.org/7.9.2009/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [updates] name=CentOS-$releasever - Updates baseurl=https://vault.centos.org/7.9.2009/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [extras] name=CentOS-$releasever - Extras baseurl=https://vault.centos.org/7.9.2009/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

如果你在国内服务器上访问 Vault 速度很慢，就把baseurl替换成国内云厂商提供的 Vault 镜像路径，原理一模一样。改完以后执行：

yum clean all yum makecache

等到makecache能正常跑完，说明源已经可用了。这一步是后续所有安装操作的前提，我建议你无论如何先处理掉。

2.3 用 wget 拉包并做基础校验

源修好之后，回到下载环节。在服务器上创建一个临时目录，下载 rpm 包：

mkdir -p /tmp/sunlogin cd /tmp/sunlogin wget "https://官方下载链接/SunloginClient-15.2.0.63064.x86_64.rpm"

下载完以后，用ls -lh看一下文件大小，再用file命令确认文件格式：

ls -lh SunloginClient-*.rpm file SunloginClient-*.rpm

正常输出里会出现RPM字样，并且标明x86_64架构。如果你看到的是一个 HTML 文件或者 zip 压缩包，说明你复制的链接错了，或者被网站防火墙挡了，返回了一个页面而不是安装包本体。

有条件的话还可以做一下 SHA256 校验，和官网给出的哈希值比对。这一步不是必须的，但对安全要求高的生产环境值得做。我个人的习惯是至少把校验码保存下来，万一后续排查问题需要确认文件完整性时能用上。

3. 从 rpm 到可连接：安装、启动、拿识别码

3.1 用 yum localinstall 一次解决依赖

安装这一步，我强烈建议用yum localinstall而不是直接rpm -ivh。很多教程喜欢写rpm -ivh SunloginClient-xxx.rpm，但 rpm 命令本身不具备自动解决依赖的能力，它只会告诉你缺什么库，然后让你手动一个个去装。向日葵 Linux 版依赖的库很可能包括libappindicator-gtk3、libXScrnSaver、xdotool这类系统组件，在一个最小化安装的 CentOS 7 上，缺三四个依赖是家常便饭，手动补起来非常痛苦。

而yum localinstall会把本地 rpm 包的依赖需求自动交给 yum 仓库去解决，它在本地安装这个包的同时，会自动下载并安装所有缺失的依赖。命令很简单：

cd /tmp/sunlogin yum localinstall -y SunloginClient-*.rpm

如果你在 2.2 节已经把 yum 源修好了，这一步通常能顺利跑完。如果中间报错提示某个依赖找不到，先确认一下源是不是没配置好，而不是急着去网上搜"强制安装"的方案。强制跳过依赖在远程控制软件这种场景下非常危险，装到一半缺库的话，后续服务根本起不来。

我那次安装的时候，就看着终端里自动补装了libICE、libSM、libXScrnSaver、libappindicator-gtk3等一堆东西，整个过程无脑等它跑完就行。装上之后，安装路径一般在/usr/local/sunlogin，这里面有主程序、库文件和日志目录。

3.2 启动服务并确认进程在跑

向日葵的 Linux 版安装完成之后，会注册一个系统服务。不同版本的服务名可能有差异，我见过runsunloginclient，也见过sunloginclient.service。别去猜服务名，先查一下最保险：

systemctl list-unit-files | grep -i sunlogin

看到类似sunloginclient.service的输出之后，启动并设置开机自启：

systemctl enable --now sunloginclient

然后确认服务状态：

systemctl status sunloginclient

如果你看到active (running)，说明守护进程已经起来了。为了保险，再用ps看一眼实际进程：

ps -ef | grep sunlogin

这一步的作用是确认进程确实在跑，因为某些情况下 systemd 显示 active，但进程因为缺库闪退了，靠ps能发现真相。如果你发现服务起不来，先看日志，排查方向在第 4 节，我那里会展开讲。

3.3 没有图形界面时，怎么拿到识别码和设置验证码

装完之后，远程连接最关键的两个东西是识别码和验证码。识别码相当于这台机器在向日葵网络里的"门牌号"，验证码是"开门密码"。在有图形界面的场景里，桌面上会有一个向日葵主窗口显示这两项；但我们这环境没有图形界面，所以必须靠命令行工具来获取。

向日葵安装目录下有主程序，一般是/usr/local/sunlogin/bin/sunloginclient。不同版本支持的参数不一样，先看帮助文档：

/usr/local/sunlogin/bin/sunloginclient --help

常见选项会包含类似--getsn或-c用来获取本机识别码，以及类似--setpasswd用来设置验证码。以我使用的版本为例：

/usr/local/sunlogin/bin/sunloginclient --getsn

输出结果是一串纯数字，大概 9 到 10 位，这就是本机识别码。再设置一个验证码：

/usr/local/sunlogin/bin/sunloginclient --setpasswd "你的验证码"

设置完成之后，你可以把识别码和验证码发给需要远程连接的人，他们在自己的 Windows/Mac/Linux 向日葵客户端里输入这两个信息，就能连上这台服务器。

这里有个容易混淆的点：向日葵不光支持"输入识别码+验证码"连接，还支持登录同一个向日葵账号后，把设备加到自己的设备列表里，从云端设备列表直接发起远控。如果你走账号体系的方式，验证码就不一定是必要的，但第一次配置我还是建议设置一个验证码兜底，后面登录绑定之后再做调整。

4. 连不上、黑屏？按这三层思路排查

4.1 服务状态和日志：systemd 日志才是第一现场

装完向日葵之后，第一次连接失败其实是常态，尤其是纯命令行环境，各种隐藏问题都会冒出来。我自己见过最多的是两种情况：一是服务根本没起来，二是连上了但画面是黑的。

排查第一个问题，不要瞎猜，直接看日志。向日葵的服务日志既可以通过 systemd 获取，也会写到自己的日志目录里。先用 journalctl 看系统服务日志：

journalctl -u sunloginclient -f

如果日志里出现类似Failed to initialize、Cannot open shared object file、segfault这样的关键字，多半是运行库缺失或者版本冲突，回到 3.1 节重新处理依赖。

向日葵自己的日志一般在/usr/local/sunlogin/logs目录下，文件名通常包含当天的日期。这个日志文件记录的信息比 systemd 更细，比如云端连接状态、识别码是否成功登记、虚拟网卡是否启动等。我强烈建议你在排查的时候两个日志配合着看，先看 systemd 有没有致命错误，再看向日葵自己的日志确认业务状态。

我遇到过一个比较隐蔽的情况：服务日志显示一切正常，识别码也能拿到，但对端就是"连接超时"。后来发现我机器上跑着一个旧版本的向日葵残留进程，把服务端口占住了，新装的服务虽然起来了，但真正处理连接的还是那个旧进程。杀掉旧进程、重启新服务后，一切恢复正常。所以如果你也碰到"日志正常但连不上"，别忘了ps -ef | grep sunlogin看一眼是不是有多个进程在打架。

4.2 防火墙和 SELinux 到底影响什么

你可能会想，向日葵不是走云端中转吗，那是不是意味着服务器防火墙可以完全不管？其实不完全对。向日葵在工作时，客户端会主动向云端建立出站连接，所以一般情况下，你不需要在服务器上放行任何入站端口，防火墙默认拒绝入站并不会阻止向日葵正常工作。但是，如果防火墙规则把出站流量也做限制，只允许 80/443 等特定端口，那向日葵云调度用的端口可能被挡住，表现就是"一直显示正在连接"。

排查的时候先看当前防火墙状态：

firewall-cmd --list-all

确认默认 zone 的 outbound 没有被额外限制。大多数云服务器默认是不会限制出站的，所以你重点检查的是有没有安全组层面的出站规则。我在给客户处理问题的时候，就遇到过一台服务器安全组只放行了 SSH 端口，向日葵连不上，最后查了一圈发现是云平台安全组把出站全拦了，放行之后立刻就连上了。

另一个经常在 CentOS 7 上出问题的东西是 SELinux。默认 enforcing 模式下，向日葵的进程可能被限制访问某些资源，导致虚拟网卡起不来或者连接异常。排查方法很简单，临时关闭 SELinux 测试一下：

setenforce 0

如果关掉之后连接恢复正常，那就基本锁定是 SELinux 的拦截。这时你需要在/etc/selinux/config里把SELINUX=enforcing改成permissive，让策略不再拦截，同时保留日志记录，方便后续观察。有些人会直接改成 disabled，但我不建议，因为这会彻底关闭 SELinux 的保护，对生产环境来说风险太大。

4.3 无桌面环境下的显示依赖：为什么连上了却是一片黑屏

这是我觉得最值得展开讲的一个问题，因为教程里很少提到。向日葵在 Linux 上远程控制时，被控端必须有对应的图形画面可以投递，哪怕那张画面本质上是服务器自己启动的虚拟显示。如果你的 CentOS 7 是最小化安装，连 X Window 都没有，那么远程连过来看到的很可能是一片黑屏，或者干脆提示"远程桌面无法创建"。

很多人遇到黑屏以后，第一反应是怀疑向日葵坏了，其实问题出在目标机器缺少图形环境。

解决方法是在服务器上补装 X 相关组件。最省事的方式是直接安装 X Window System 组包：

yum groupinstall -y "X Window System"

这个组包会装上一整套 X 服务相关组件，体积比较大，几百 MB 到 1GB 左右，但一劳永逸。如果觉得太重，可以只装最小必需件：

yum install -y xorg-x11-xauth xorg-x11-server-Xvfb xorg-x11-utils

我个人倾向于前者，因为向日葵的远程画面最终需要一个可交互的图形会话，只装一个Xvfb虚拟显示虽然能投递画面，但没有完整的窗口管理器和基础桌面环境，远程看了也没什么用。你既然要在服务端看图形界面，那至少让服务器具备一个可用的 X 环境。

装完之后重启向日葵服务：

systemctl restart sunloginclient

再从对端发起连接测试，正常情况下就能看到向日葵生成的虚拟桌面画面了。如果你希望画面里有一个完整的桌面环境，后续还可以装 GNOME 或者 XFCE，但这取决于你的实际需求，演示一个图形工具的话，X 环境加那个工具本身的界面基本就够了。

5. 装完后的自启、升级与卸载

5.1 开机自启和重启后的验证

向日葵作为远程控制软件，最怕的就是服务器重启之后服务没起来，你又不在现场，只能干瞪眼。所以只要确认服务能正常工作，第一件事就是确保它开机自启。

在 3.2 节里，我已经用了systemctl enable --now sunloginclient，这句命令同时完成了"设置开机自启"和"立即启动"。但为了保险，建议重启一次服务器，验证整个链路是否完整：

reboot

重启回来之后，重新 SSH 登录，按这个顺序检查：

systemctl is-enabled sunloginclient systemctl status sunloginclient ps -ef | grep sunlogin

然后重新执行一次获取识别码的命令，确认识别码没有变化。这里有个容易忽略的细节：向日葵的识别码跟机器的硬件标识和系统状态绑定，只要你不重装系统、不更换网卡，识别码一般不会变。但有些虚拟化环境下网卡的 MAC 地址可能随重启发生变化，识别码就会变。如果你发现重启后识别码变了，先检查一下网卡是不是被 DHCP 换地址导致，必要时在网卡配置里固定 MAC。

5.2 升级覆盖与日志位置

向日葵会不定期发布新版本，官方一般会修复安全漏洞和连接稳定性问题，所以定期升级是应该的，特别是向日葵这种暴露在公网连接场景下的软件。

升级过程很简单：去官网下载新版本的 rpm 包，然后直接执行：

yum localinstall -y SunloginClient-新版.x86_64.rpm

这个命令会覆盖安装新版，同时保留原有的配置文件、识别码绑定关系和设备列表中的名称。但我不建议你手贱删掉/usr/local/sunlogin目录再装新版，那相当于重装系统，识别码会变，还得重新绑定。

日志方面，向日葵的运行日志在/usr/local/sunlogin/logs，升级一般不会清空这个目录，但旧日志会比较多，建议定期手动清理：

find /usr/local/sunlogin/logs -name "*.log" -mtime +30 -exec rm -f {} \;

这条命令会删除 30 天前的日志文件，避免日志把磁盘占满。

5.3 不想要了怎么干净卸载

卸载向日葵比安装简单，但也要按顺序来，不然容易留下残留进程。

先停止服务并关闭自启：

systemctl stop sunloginclient systemctl disable sunloginclient

然后通过 rpm 查询确认包名：

rpm -qa | grep sunlogin

卸载：

rpm -e SunloginClient

这里要注意，rpm 卸载可能会提示某些配置文件的归属问题，如果报错，加上--nodeps强行卸载是可以的，但前提是你确认不再使用这个软件了。卸载完成后，检查一下/usr/local/sunlogin目录是否还在，这个目录是软件的数据目录，属于安装时自动创建的，rpm 卸载不一定删干净，需要手动清理：

rm -rf /usr/local/sunlogin

最后再检查一遍进程和端口，确保没有残留：

ps -ef | grep sunlogin ss -tnlp | grep sunlogin

干干净净，不留尾巴。

装向日葵这件事本身不难，真正难的是那些隐藏的环境问题：yum 源失效、依赖缺失、SELinux 拦截、没有 X 环境导致黑屏。把这些坑挨个趟平之后，你会发现纯命令行部署一个远程控制软件其实也就十来分钟的事。

我再分享一个实操习惯：向日葵装完、服务启动之后，不要急着把服务器扔在一边，最好立刻用手机上的向日葵客户端或者另一台电脑发起一次测试连接，验证画面、键盘、鼠标全部正常后再关机收工。我在实际运维中吃过亏，装完当天没测，第二天客户远程连接时才发现黑屏，最后又花了大半个小时补装 X 环境，白白耽误了事情。先测一次，后面就稳了。