企业官网建设流程全解析

用Linux当主力机的人，迟早会碰上远程控制这台机器的时候。试过几个方案之后，大部分人会选择向日葵，原因不外乎两条：一是它对Linux桌面的支持算是国内商业方案里比较上心的，二是不用折腾公网IP和端口映射。但Ubuntu20.04和Debian10这两个发行版，一个用的是较新的GTK3栈，一个因为追求稳定把依赖库版本压得很低，装向日葵的deb包时经常被依赖问题卡住。这篇就把我在这两个系统上反复安装、踩坑、清理、重装的过程完整记录下来，重点说清楚依赖报错的底层逻辑和不同报错对应的解法。

如果你准备在Ubuntu20.04或Debian10上安装向日葵远程控制客户端，或者说你已经装了但打不开、起不了服务、登录转圈，这篇文章应该是目前能直接照着操作、少走弯路的一份参考。内容不涉及编译源码，也不用换软件源，只在官方deb包和系统自带依赖管理工具的范围内解决问题。

1. 安装前的准备工作与整体思路拆解

1.1 下载渠道与版本选择：为什么我建议你直接去官网下

向日葵的Linux客户端没有放在GitHub发布页，也没有进Ubuntu的官方源，唯一的可靠渠道是向日葵官网的下载中心。搜索“向日葵远程控制下载”会看到官网地址，进入下载页面后有一个“Linux”选项卡，里面分了两类：一类是图形界面的完整客户端（deb包），另一类是命令行版本的SunloginClient（同样是deb包）。我这里说的是图形界面版本，因为大部分人要的是能远程操作桌面，而不是只在终端里跑命令。

下载时要特别注意区分系统架构。x86_64的机器下载amd64版，ARM架构（比如树莓派4B装Ubuntu20.04）下载arm64版。官方页面会有一个小下拉框让你选架构，如果选错了，安装时倒不会报错，但运行时会直接提示“段错误”或者连界面都起不来。这个坑我在树莓派上踩过一次，至今印象深刻。

版本号方面，我建议直接下当前官网提供的最新版，不要去找旧版本。Linux图形客户端的版本迭代对系统的兼容性影响很大，比如2024年之后的版本已经移除了对lightdm的强制依赖，而2023年之前的很多版本还在依赖项里写死lightdm，这在纯GNOME环境下会造成严重冲突。选择最新版能从源头规避掉一类历史问题。

1.2 清理历史残留：不卸干净新版本装不上的真实原因

如果你之前装过向日葵，或者装过旧版本后来又卸载了，一定要先做一次彻底清理。很多人在“安装新版后连不上服务”“图标点了没反应”时反复重装，其实问题不是安装本身，而是旧版本的配置文件和残留服务干扰了新版的注册逻辑。

清理分三步：

# 第一步，停掉旧服务 sudo systemctl stop runsunloginclient.service # 第二步，卸载旧包 sudo dpkg -r sunloginclient # 第三步，删除残留配置 sudo rm -rf /etc/sunlogin /usr/local/sunlogin /root/.sunlogin

这三步做完，再检查一下系统里还有没有残留的进程：

ps aux | grep -i sunlogin

如果有残留进程还活着，用kill命令结束掉。不卸载干净的直接后果是，新包安装后systemd服务注册失败，或者服务能起来但一直提示“账号已在其他设备登录”，因为旧的设备标识文件还在。这个逻辑类似Windows上卸载软件后要清理注册表，Linux只是把注册表换成了/etc和/home下的配置文件。

1.3 安装前必须做的两件事：更新索引与校验依赖连通性

在Ubuntu20.04和Debian10上安装任何deb包之前，我都建议先跑一次系统更新。这里的更新不是让你升级整个系统，而是刷新软件源索引，让apt知道当前源里有哪些包可用、各自是什么版本。这一步对后面的依赖解析至关重要，因为apt在安装本地deb包时也是通过自己的软件源数据库来查找依赖项的。

sudo apt update

然后安装几个基础工具，后面排查依赖时会用到：

sudo apt install -y wget dpkg apt-utils

wget用来下载deb包，dpkg是deb包管理工具本身，apt-utils提供一些辅助工具。这里强调一下，我下载的deb包都默认放在~/Downloads目录下，后面所有命令都以这个路径为例。

准备工作中还有一个容易被忽略的点：确认系统时间是否正确。如果系统时间和实际时间差太多，下载deb包或者后续登录远程服务时会出现TLS证书校验失败的问题，报错看起来像“无法建立安全连接”，实际却是时间同步的问题。检查一下，必要时安装ntpdate或chrony同步时间。这一点在安装任何需要联网验证license的软件时都通用。

2. Ubuntu20.04依赖问题核心链路：报错逐条分析与解决

2.1 最常见的依赖报错长什么样：从libgtk-3-0到libappindicator

在Ubuntu20.04上安装向日葵deb包，最常见的报错是dpkg提示一堆依赖缺失。这里我以当前官网的最新版为例，忘记具体版本号，但依赖关系大同小异。用dpkg安装时会出现类似这样的输出：

dpkg: dependency problems prevent configuration of sunloginclient: sunloginclient depends on libgtk-3-0 (>= 3.10); however: Package libgtk-3-0 is not installed. sunloginclient depends on libappindicator3-1; however: Package libappindicator3-1 is not installed. sunloginclient depends on libnotify4; however: Package libnotify4 is not installed.

看到这种报错不用慌，这恰恰说明deb包本身没问题，只是系统里缺少它运行时的依赖库。Ubuntu20.04的软件源里其实都有这些包，直接用apt安装即可：

sudo apt install -y libgtk-3-0 libnotify4 libxtst6 libxss1

这里libgtk-3-0是图形界面框架，libnotify4是系统通知库，libxtst6提供X11的键盘鼠标事件捕获能力（远程控制必须用到），libxss1是屏幕保护相关的X扩展库。对于远程控制软件来说，libxtst6尤其重要，如果缺失，即使装上了客户端，远端也无法模拟键盘鼠标操作。

重点来了：libappindicator3-1在Ubuntu20.04的官方源里并不存在。Ubuntu18.04及更早的版本里确实有这个包，但从20.04开始，Ubuntu用libayatana-appindicator3-1替换了它。这是一个典型的“包名变更”问题，如果不清楚这个背景，会卡在这一步很久。

sudo apt install -y libayatana-appindicator3-1

装上这个包之后，向日葵客户端的托盘图标才能正常显示。如果不装，客户端主窗口能打开，但最小化到托盘后图标消失，你甚至找不到重新打开窗口的入口。很多人在这一步以为软件坏了，其实就差这么一个兼容层包。

2.2 为什么apt install libappindicator3-1会失败：Ubuntu20.04包名变更的来龙去脉

上面说了libappindicator3-1在20.04里不存在，这里展开讲一下原因。

Ubuntu20.04引入了一个新的AppIndicator实现，叫Ayatana Indicators，它是Ubuntu桌面项目的一部分，用来替换老的AppIndicator3。这个替换带了依赖包名变更，老包libappindicator3-1被拆成libayatana-appindicator3-1和libayatana-appindicator3-dev等几个包。很多第三方软件打包时还沿用老的依赖名，所以安装时会报“无法找到libappindicator3-1”。

解决思路有两种：第一种是直接装新包名，也就是上面说过的libayatana-appindicator3-1；第二种是把老包名做一个虚拟包映射。第二种方案不推荐新手尝试，因为需要自己写本地仓库配置或者用equivs-control创建虚拟包，复杂度比较高。用第一种方案，装好新包后，向日葵的托盘图标就可以正常显示了。

需要注意：如果你在别的教程里看到让你安装libappindicator3-1的，那套教程大概率是给Ubuntu18.04写的，在20.04上不会生效。识别这种旧教程的一个技巧是看它推荐的软件源地址和依赖包名，凡是出现bionic字样的，全部可以关掉了。

2.3 新版客户端的隐藏依赖：ukui-setting-daemon这个冷门包

这可能是整个Ubuntu20.04安装过程中最让人崩溃的一个依赖。部分新版本向日葵客户端的deb包，其Depends字段里除了常见的libgtk-3-0之外，还包含一项：

Depends: ... , ukui-setting-daemon (>= 1.1.1)

ukui-setting-daemon是什么？它是UKUI桌面环境的设置守护进程。UKUI是麒麟和优麒麟桌面环境的组件，在普通的Ubuntu20.04默认源里根本没有这个包。如果你用dpkg -i直接安装，会看到这样的报错：

dpkg: dependency problems prevent configuration of sunloginclient: sunloginclient depends on ukui-setting-daemon (>= 1.1.1); however: Package ukui-setting-daemon is not installed.

这时候apt也帮不上忙，因为apt搜索不到这个包：

sudo apt install -y ukui-setting-daemon # 输出：E: Unable to locate package ukui-setting-daemon

解决方式比较迂回，需要理解Debian系依赖体系里的一个特性：dpkg实际上只检查Depends字段写的包名是否满足，不关心这个包是不是“本意”的那个包。因此可以手动创建一个本地虚拟包，把它的名字写成ukui-setting-daemon，版本写成大于1.1.1，然后安装这个本地包。dpkg看到系统里已经存在满足名字和版本要求的软件包，就认为依赖满足了。

创建虚拟包具体步骤如下：

# 安装构建工具 sudo apt install -y equivs # 创建一个空描述文件 equivs-control ukui-setting-daemon # 编辑文件，修改以下关键字段 vim ukui-setting-daemon

编辑文件时把下面几行改成：

Package: ukui-setting-daemon Version: 1.1.1 Architecture: all Description: dummy package to satisfy sunloginclient dependency

然后保存，生成deb包并安装：

equivs-build ukui-setting-daemon sudo dpkg -i ukui-setting-daemon_1.1.1_all.deb

装完这个虚拟包之后，再回到向日葵的安装流程，dpkg就不会再报这个依赖缺失了。

这个虚拟包方案是Debian系安装第三方软件时常用的手段，等价于告诉dpkg：“这个依赖我已经处理了，别拦着我”。它不会影响系统本身的正常运行，因为ukui-setting-daemon本来就不是系统必需组件。唯一需要注意的是，如果你后续要安装真正的UKUI套件，两个包会冲突，需要先卸载虚拟包。但在绝大多数Ubuntu20.04桌面环境里不会遇到这种情况。

2.4 Ubuntu20.04完整安装流程梳理：一条命令一条命令照着做

综合上面几个点，这里给出一套完整的操作步骤。假设deb包已经下载到~/Downloads目录下：

cd ~/Downloads # 第一步，尝试直接安装，这里大概率会看到依赖缺失报错 sudo dpkg -i SunloginClient-*.deb # 第二步，如果上面报错，先安装能通过apt直接装上的依赖 sudo apt install -y libgtk-3-0 libnotify4 libxtst6 libxss1 libayatana-appindicator3-1 # 第三步，处理ukui-setting-daemon虚拟包 sudo apt install -y equivs equivs-control ukui-setting-daemon sed -i 's/Package: <package name>/Package: ukui-setting-daemon/' ukui-setting-daemon sed -i 's/Version: <version>/Version: 1.1.1/' ukui-setting-daemon sed -i 's/Architecture: <arch>/Architecture: all/' ukui-setting-daemon equivs-build ukui-setting-daemon sudo dpkg -i ukui-setting-daemon_1.1.1_all.deb # 第四步，重新安装向日葵 sudo dpkg -i SunloginClient-*.deb # 第五步，如果第四步仍然报依赖错误，强制修复 sudo apt --fix-broken install -y # 第六步，安装完成后重新加载服务 sudo systemctl daemon-reload sudo systemctl start runsunloginclient.service sudo systemctl enable runsunloginclient.service

这套流程跑完后，Ubuntu20.04上的向日葵客户端应该能正常打开图形界面了。打开方式有两种：从应用菜单里搜“向日葵”点击启动，或者在终端里输入sunloginclient启动。

这里解释一下第五步的apt --fix-broken install的作用。dpkg在安装过程中遇到依赖缺失或冲突时，会把包留在“半配置”状态，这个状态是很讨厌的，因为后续任何dpkg操作都会被阻塞。执行apt --fix-broken install会让apt自动尝试修复这些半安装状态，补齐缺失依赖或卸载损坏的包。如果在第四步dpkg -i成功但出现candidate包状态异常，执行第五步后大概率能修复。

3. Debian10独有的坑：老系统装新软件的血泪经验

3.1 Debian10源里没有新版GTK3：版本号不满足怎么处理

Debian10（Buster）发布于2019年，其软件源里的依赖库版本整体比Ubuntu20.04更旧。向日葵的新版客户端虽然要求的最低版本通常是libgtk-3-0 (>= 3.10)，Debian10源里的libgtk-3-0是3.24.5，理论上满足这个要求。但实际安装时仍然可能出现版本不匹配的报错，比如：

sunloginclient depends on libgtk-3-0 (>= 3.22); however: Version of libgtk-3-0 on system is 3.24.5-1.

注意：如果这个报错出现了，说明你的软件源被配置成了只使用某些旧版本的软件包，或者某些源被注释掉了导致apt无法看到Debian10官方源里的最新版本。正常情况下，Debian10的源里libgtk-3-0就是3.24.5，大于3.22，不会触发这个报错。

如果真遇到版本不满足的情况，大概率是你的/etc/apt/sources.list里只保留了Debian10的“初始安装”源，需要补充updates源和安全更新源：

# Debian10的sources.list参考配置 deb http://deb.debian.org/debian buster main contrib non-free deb http://deb.debian.org/debian buster-updates main contrib non-free deb http://security.debian.org/debian-security buster/updates main contrib non-free

编辑好之后执行sudo apt update，再回头去安装向日葵依赖，版本问题大概率会消失。这里有个判别技巧：如果apt update后显示大量包更新但升级时提示“已安装的软件包版本高于软件源中可用版本”，说明你的源指向了旧镜像，换成官方源即可。

3.2 没有sudo命令怎么办：Debian10最小化安装的权限坑

Debian10的最小化安装和Ubuntu的默认安装有一个很大区别：Debian在最小化模式下不一定安装sudo包。你登录系统的用户可能根本不在sudoers里，或者sudo命令本身就不存在。

遇到这种情况，不要慌，有两种方式处理。

第一种是用su切换到root用户后再执行命令：

su - # 输入root密码，然后执行安装命令

第二种是需要当前普通用户能使用sudo时，手动安装sudo并添加用户到sudo组：

su - apt install -y sudo usermod -aG sudo 你的用户名 # 重新登录或执行newgrp sudo使权限生效

在Debian10上安装向日葵，我个人更推荐直接用su切root操作，省去sudo权限配置的时间。但要注意，root环境下安装的软件，其配置文件默认放在/root目录而不是用户home目录下，这不是问题，因为向日葵的服务本身是系统级的，不影响使用。

如果你后续发现命令行能启动向日葵但桌面图标点了没反应，有可能是你用root安装了客户端，但当前桌面用户没有执行权限。解决方式是执行：

sudo chmod -R 755 /usr/local/sunlogin

3.3 64位系统装32位依赖：多架构开启引发的恩怨

Debian10上还有一个Ubuntu20.04不会遇到的新坑：缺少i386架构的依赖。有些软件（比如某些输入法框架或商业软件）会在安装时提示开启多架构支持，而开启后apt的依赖解析会变得异常复杂。如果你之前为了装Wine或者Steam执行过：

sudo dpkg --add-architecture i386 sudo apt update

那么向日葵的deb包在安装时可能出现奇怪的架构相关报错：

sunloginclient : Depends: libgtk-3-0 but it is not installable

这个报错的意思不是说不存在libgtk-3-0，而是说libgtk-3-0的某些依赖在跨架构情况下无法满足。排查方式是用apt直接安装相关包，看它会提示什么：

sudo apt install -y libgtk-3-0:i386

如果你不需要32位库，最简单的处理方式是移除多架构支持：

sudo dpkg --remove-architecture i386 sudo apt update

然后重新执行向日葵的安装流程。

这里要提醒一句：卸载多架构支持可能会破坏已经安装的Wine、Steam等依赖32位库的软件。如果你确实离不开这些软件，就别删架构，改用下述方案：直接跳过依赖检查强制安装：

sudo dpkg -i --force-depends SunloginClient-*.deb sudo apt --fix-broken install -y

这种方式虽然不优雅，但在特定环境下是唯一快速可用的方案。它的原理是：先跳过Depends检查安装向日葵，然后用apt --fix-broken尝试补齐能补的依赖，补不上但是不影响核心功能的，就让它保持缺失状态。对向日葵来说，即使个别非关键库缺失，主界面和服务仍然能正常工作。

3.4 Debian10上安装后的服务启动问题：systemd与/etc/init.d的历史遗留

Debian10系统上安装向日葵后，有一个特定的历史遗留问题：旧版本向日葵同时安装了systemd服务脚本和/etc/init.d启动脚本，而systemd的启动脚本可能依赖一个旧的守护进程路径。如果你在安装新版时没有卸载干净旧版，运行sudo systemctl start runsunloginclient.service时可能没有任何报错，但客户端仍然无法连接。

排查方法如下：

systemctl status runsunloginclient.service journalctl -u runsunloginclient.service -n 50

journalctl输出里如果出现“Failed at step EXEC”或“No such file or directory”，说明systemd单元文件里指定的可执行文件路径不存在。这种情况通常是旧版卸载时只移除了/etc/init.d脚本，没同步清理/usr/lib/systemd/system下的服务文件，而新版安装时发现服务文件已存在，跳过覆盖，导致路径指向了旧版本的二进制。

解决方式也简单：手动删除旧的systemd服务文件，重新安装或手动创建新的：

sudo rm -f /usr/lib/systemd/system/runsunloginclient.service sudo systemctl daemon-reload sudo dpkg -i SunloginClient-*.deb

重新安装后，systemd服务文件会重新生成，路径就能对齐了。

4. 服务、配置与运行时的完整实操记录

4.1 安装完成后的目录结构长什么样：知道文件在哪才好排查

无论Ubuntu还是Debian，安装完向日葵之后系统里会多出这么几个关键目录和文件。搞清楚这些位置，后续排查任何问题都能顺着目录一层层摸下去。

# 主程序安装目录 /usr/local/sunlogin/ # 配置文件目录 /etc/sunlogin/ # 日志文件目录 /var/log/sunlogin/ # 用户级配置（root用户） /root/.sunlogin/ # systemd服务文件 /usr/lib/systemd/system/runsunloginclient.service

主程序目录里最重要的文件是bin/sunloginclient（图形界面主程序）和sbin/sunlogin-service（后台守护服务）。这两个程序的关系可以理解为：sunlogin-service负责维持远程连接和账号登录状态，sunloginclient是操作界面。安装后服务启动失败时，需要先确认sunlogin-service这个守护进程是否在运行：

ps -ef | grep sunlogin

正常状态应该能看到类似sunlogin-service的进程，以及你手动启动sunloginclient后出现的图形界面进程。如果守护进程都不存在，即使你打开了客户端，界面也会一直停留在“连接中”而无法远程。

日志目录下的文件是排查问题的第一手资料。比如如果登录一直转圈，就可以查看日志：

cat /var/log/sunlogin/sunlogin_service.log | tail -50

日志里如果有“login failed”或“authentication failed”，说明是账号密码问题；如果出现“network error”则可能是防火墙阻断了通信端口。这里不展开日志解析，具体的常见问题在下一节详细梳理。

4.2 配置远程访问：无人值守与系统服务的联动

运行向日葵图形界面后，登录账号，然后在设置里开启“开机自动启动”和“无人值守访问”，就能实现远程随时连接本机。这两个选项背后依赖的就是systemd服务能正常运行。

在Ubuntu20.04和Debian10上，开机自动启动的开关本质上是在配置里面写入一个标记，然后由runsunloginclient.service这个systemd服务在启动时读取。如果服务没有enable，客户端设置里的开机启动即使打开，重启后也不会生效。因此建议在安装完成后手动确认一次：

sudo systemctl enable runsunloginclient.service sudo systemctl is-enabled runsunloginclient.service

如果输出enabled，说明开机自启已经配置好了。注意，向日葵的版本偶尔会自行覆盖服务配置，导致enable状态丢失，所以升级版本后最好再检查一次。

4.3 网络与防火墙：哪些端口和协议不能拦

这一点容易被忽视，但远程连接失败有相当比例是防火墙导致的。向日葵远程控制的通信分为两个阶段：登录服务器阶段和点对点连接阶段。

登录服务器阶段使用HTTPS（443端口）与向日葵的中转服务器通信，用于验证账号、获取设备列表。点对点连接阶段根据网络情况会尝试UDP打洞，UDP端口范围比较宽，通常在1024到65535之间。如果系统防火墙拦截了UDP通信，远程控制就会卡在“连接中”然后超时。

在Ubuntu20.04桌面版默认不启用UFW防火墙，但如果你自己开启过：

sudo ufw status

如果状态是active，建议放行：

sudo ufw allow 443/tcp sudo ufw allow 80/tcp

UDP端口范围太宽，不建议直接全部放行。实测中大部分UDP打洞是在较高的随机端口上进行的，如果你的网络环境比较固定，可以先关闭防火墙测试一下远程能否连上，如果能连上再逐条放行必要的端口。

Debian10默认也没有启用防火墙，但如果你装了firewalld或者其他安全组策略，同样需要放开相关端口。

4.4 图形界面打不开或黑屏：X11会话与Wayland的边界问题

Ubuntu20.04默认使用的显示协议是X11，也有一些桌面环境（比如Wayland会话）可以切换。向日葵的Linux客户端目前对Wayland的支持还不完善，如果你在登录界面选择了Wayland会话，安装向日葵后打开客户端可能会出现黑窗或者画面异常。

处理方式是在登录界面点击用户后，在密码框下方或右上角选择“Ubuntu on Xorg”（X11会话）登录。这一点在远程控制场景下特别重要，因为Wayland下向日葵无法捕获屏幕内容和模拟输入，远程体验基本不可用。

Debian10默认使用的桌面环境可能是GNOME3的X11版本，一般不涉及Wayland问题。但如果自己装过Sway或者其他Wayland合成器，同样会遇到画面捕获问题，这时只能切回X11。

5. 常见问题与排查技巧实录：速查表模式

5.1 高频问题逐条排雷：从报错信息到根因

以下是在Ubuntu20.04和Debian10上安装使用向日葵时最常见的问题，我把报错现象、根因、解决办法整理成对照表方便快速查询。

5.2 深度排查：ldd检查动态库缺失

如果客户端能启动但功能异常（比如无法远程、无法显示设备列表），可以用ldd检查可执行文件依赖的动态库是否全部解析成功。这是Linux下排查“装上了但运行半残”类问题的通用手段。

ldd /usr/local/sunlogin/bin/sunloginclient

输出中如果出现“not found”，说明对应动态库缺失。根据缺失库名逐一用apt安装。比如输出里有libXtst.so.6 not found，就执行：

sudo apt install -y libxtst6

ldd输出的意义在于定位那些deb包依赖声明里没写、但实际运行必需的库。这类库通常是间接依赖，deb包的Depends字段不可能完全列举所有传递依赖，只能靠运行时解析来发现。

5.3 安装到一半卡住怎么办：dpkg锁与中断处理

你在执行dpkg -i中途退出或断电，系统会报：

E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a'

直接照做：

sudo dpkg --configure -a

如果提示“dpkg status database is locked”，说明系统里还有一个dpkg进程没有释放锁。确认没有其他安装了在跑的话，可以强行释放：

sudo rm -f /var/lib/dpkg/lock-frontend sudo rm -f /var/lib/dpkg/lock

然后再执行dpkg --configure -a收尾。

在某些极端情况下，包状态会变成“F”或“H”等异常状态，用以下命令查看：

dpkg -l | grep sunloginclient

状态列第二个字符是期望状态，第一个字符是实际状态。如果显示“iF”或“iU”，说明安装不完整，需要卸载后重新安装：

sudo dpkg --remove --force-all sunloginclient sudo dpkg -i SunloginClient-*.deb

5.4 独家技巧：apt install时报“无法定位软件包”的终极处理

有时候执行sudo apt install -y libgtk-3-0，系统会报“E: Unable to locate package libgtk-3-0”。这个报错通常意味着源里没有同名包，可能是源配置错误，也可能是包名不对。

排查步骤先确认源列表：

grep -rh ^deb /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Debian10的源会写着buster，Ubuntu20.04的源会写着focal。如果源列表是空的或者指向了不存在的地址，需要重新配置sources.list。

除此之外，还有一个很隐蔽的问题：有些第三方源会设置“Pin-Priority”把所有非自家源的包优先级降到0，导致即使源里有某个包，系统也认为它不可安装。这时可以临时指定从官方源安装：

sudo apt install -t focal libgtk-3-0

这个方法在Ubuntu20.04上尤其好用。Debian10对应的是buster版本号，命令改成：

sudo apt install -t buster libgtk-3-0

如果指定版本号还不行，那就动用终极方案：直接从官方源下载deb包手动安装。用浏览器打开https://packages.ubuntu.com或https://packages.debian.org，搜索对应的库名，下载amd64版本deb，然后用dpkg -i安装。这种方式能绕过所有源配置问题，但需要注意下载版本的依赖关系，必要时需要手动下载多个依赖包按顺序安装。

6. 双系统与虚拟机场景下的额外观察

6.1 双系统用户装Ubuntu20.04后远程控制的特殊性

如果你是用双系统安装的Ubuntu20.04，远程控制时还有一个独特问题：往往你不是只装了一个系统，可能Windows和Ubuntu都有向日葵客户端。这时要注意两个系统里不要同时登录同一个账号的无人值守模式，否则远程连接时会反复跳到另一个系统。

这个现象有点反直觉，很多人以为是软件坏了，其实只是两个系统的设备指纹都被同一个账号绑定，向日葵服务器在匹配连接设备时发生了混乱。解决办法是：只在一个系统上开启无人值守，另一个系统仅在有需要时手动运行。如果已经登录了两个系统，把其中一个的无人值守关掉，然后在已登录的账号里删掉多余设备。

6.2 虚拟机里安装向日葵：网络模式选NAT还是桥接

在VMware或Virtual Machine Manager里安装Ubuntu20.04后再装向日葵，需要注意网络模式对远程控制的影响。NAT模式下，虚拟机能上网但外部设备无法主动连接到虚拟机，向日葵的打洞成功率会明显下降。桥接模式下，虚拟机会被分配和宿主机同一网段的IP地址，远程控制的连通性最好。

如果是VMware Workstation Pro 17安装Ubuntu20.04后，网络默认是NAT模式，远程连不上的概率很高。建议在虚拟机设置里把网络适配器改成“桥接模式”，然后重启虚拟机。在Virtual Machine Manager里也是一样的逻辑，把网卡类型改成virtio并设置为桥接。

在虚拟机里远程控制的另一个问题是桌面分辨率。如果虚拟机窗口分辨率比较小，远程连接时远程桌面的尺寸也会受限制。装好向日葵后，在客户端设置中把分辨率调到与宿主显示器匹配，远程操作体验会好很多。

7. 卸载与重装：折腾了一圈怎么全身而退

7.1 干净的卸载流程：卸载、清理、回到原始状态

如果你折腾了半天最后还是决定不装向日葵，或者想彻底清掉换TeamViewer、ToDesk等其他方案，这里给出一套完整的卸载流程。重点是把服务、配置、数据全部清理干净，不留残余。

# 停服务 sudo systemctl stop runsunloginclient.service sudo systemctl disable runsunloginclient.service # 卸载软件包 sudo dpkg -r sunloginclient # 删除遗留文件和配置 sudo rm -rf /usr/local/sunlogin /etc/sunlogin /var/log/sunlogin /root/.sunlogin

卸载之后，如果之前创建过ukui-setting-daemon虚拟包，也一并清理：

sudo dpkg -r ukui-setting-daemon

如果你在清理后发现系统dpkg状态异常，执行：

sudo dpkg --configure -a sudo apt --fix-broken install -y

这一套做完，系统基本能恢复到安装向日葵之前的状态，不会影响apt后续其他包的操作。

7.2 升级客户端时的注意事项：别带着旧配置升级

向日葵客户端有自动更新提示，但通常只提示你去下载新版，不会主动帮你替换deb包。手动升级时最常见的坑是只执行dpkg -i新包却不先卸载旧包，导致新老文件混在一起。

建议升级流程：

# 先停服务 sudo systemctl stop runsunloginclient.service # 用dpkg安装新版，它会自动覆盖旧版 sudo dpkg -i SunloginClient-新版.deb # 修复可能出现的依赖变化 sudo apt --fix-broken install -y # 重启服务 sudo systemctl start runsunloginclient.service

如果新版安装后登录状态丢失，检查/root/.sunlogin目录里的配置文件是否因为权限问题无法写入。新版第一次启动需要重新生成登录凭证，如果当前用户对该目录没有写权限，会出现登录界面打不开或登录后无法获取设备列表的问题。遇到这种情况直接：

sudo chmod -R 777 /root/.sunlogin

不过提醒一句：这个目录下的文件里可能包含设备凭证，权限给到777后仅限个人单机环境使用，多用户服务器上不要这么干。

7.3 卸载ukui-setting-daemon虚拟包后导致系统异常？先分清主次

如果你按照我的方案创建了ukui-setting-daemon虚拟包，后来又因为某种原因卸载了它，且此时向日葵还装着，可能会出现向日葵客户端无法启动的问题，因为dpkg在依赖检查时会发现sunloginclient的Depends不满足，从而阻止后续apt操作。

解决办法是把向日葵也一并卸载，或者重新创建虚拟包。所以我的建议是：在确认稳定使用向日葵之后，不需要特意去卸载虚拟包。它占用的磁盘空间几乎为零，也不会和任何正常软件包冲突，留着反而省心。

8. 从安装到运行的经验总结与最后建议

8.1 为什么这两个系统踩坑特别多：从依赖管理的视角看

把Ubuntu20.04和Debian10的安装踩坑放在一起看，会发现它们踩的坑完全不同。Ubuntu20.04的问题是“包名变更”，典型代表就是libappindicator3-1变成了libayatana-appindicator3-1，以及ukui-setting-daemon这种第三方包强行进依赖列表。Debian10的问题则是“版本过老”，典型代表是部分新版客户端要求的GTK3版本在Debian10源里根本提供不了，只能靠虚拟包破解，或者从源码编译高版本。

这个差异背后的根源在于两个发行版采用的发布策略。Ubuntu每两年更新一个大版本，更新频率相对较快，大量软件包会跟进新库；Debian每当一个版本进入稳定状态，之后极少做非安全更新，库版本基本冻结。这种差异对普通用户来说感受不深，但安装第三方商业软件时就会暴露出来。

理解了这一层，你在Ubuntu和Debian上安装任何商业软件时，都可以举一反三：先在apt源里确认依赖包是否存在、版本是否足够，然后再决定直接安装还是需要走虚拟包路线。

8.2 几个提升成功率的小习惯

踩过的坑多了，自然养成了一些习惯。这里挑几个和向日葵安装直接相关的分享。

第一，永远保留一个干净能用的终端环境。安装前先开一个root终端或者确认当前用户有sudo权限，不然装到一半发现权限不够，又要去查sudo配置，非常影响节奏。

第二，每个步骤执行后都看一眼输出。dpkg在安装成功时输出相对安静，但如果某个文件被覆盖或依赖被跳过，它会留一行警告。不要忽视这些警告，它们往往预示着后续某个功能会异常。

第三，如果官方给了解压即用的tar.gz版本，就别非要和deb包死磕。向日葵官网的Linux下载界面偶尔会同时提供deb包和tar.gz包。tar.gz版解压后直接运行bin/sunloginclient就能用，省去所有依赖烦恼，代价是需要手动创建桌面快捷方式和systemd服务。对于已经被依赖问题折磨半天的人来说，这是一个值得考虑的备选方案。tar.gz版的完整使用方法，官网有对应的说明，大体思路是把整个目录放到/usr/local/sunlogin，然后创建软链接或desktop文件。

第四，记录下自己执行过哪些命令。特别是创建过虚拟包、修改过系统服务这类操作，记不住的话下次重装系统后又要重新摸索一遍。

8.3 最后的体会

我在Ubuntu20.04和Debian10上分别完整走过一遍向日葵的安装流程，前后加起来重装了不下七八次，才把整套依赖关系摸清楚。回头看在Debian系系统上安装商业软件，最核心的障碍往往不是软件本身，而是系统的依赖管理策略和第三方打包方式之间的错位。搞懂了dpkg的依赖检查机制和apt的修复逻辑，这类问题就再也不神秘了。如果你在安装过程中遇到我这里没写到的报错，先用dpkg --info查看deb包的Depends字段，再对照报错一步步安装缺失项，大概率能自己解决问题。动手之前先想清楚每一步在做什么，比盲目复制粘贴命令要高效得多。