基于sctgdeskSserver搭建你的全能rustdesk服务端

rustdesk在远程届可谓是“当红小生”，本文就将介绍如何基于sctgdeskServer在懒猫微服搭建您的rust全能服务端。之所以全能，是因为sctgdeskServer提供了一些只有Pro版本才有的功能。让我们开始撸起袖子开干！ ## 准备 - 一台懒猫微服 - 能设置端口转发的路由器 - 公网IP，有公网ip最好，转发以后就不需要跟懒猫组网了。 https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.developer.tools https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.sctgdesk-server > 如果没有公网IP，则其他设备需要连接rustdesk服务端的时候，就需要通过tailscale或者懒猫微服cli的方式组网。 ## 安装步骤 ### 安装SctgDesk Server 安装软件，以后，需要打开懒猫开发者工具，查看自动生成的key信息，这个后面要用到  然后打开软件，默认账户为`admin`，密码为`Hello,world!`，登录以后最好禁用admin，然后自己创建一个管理员权限的用户。  ### 端口转发 在路由器转发 + TCP 21114-21119 到懒猫微服 + UDP 21116 到懒猫微服 以我的梅林路由器为例，下面的设置的转发规则  这样外部21114-21119的请求都会被转发到懒猫 > 如果您有域名，可以借助动态域名自动更新您域名的A记录到，如果没有域名，在后面的客户端设置步骤可以使用ip ### 客户端设置 您需要从rustdesk官方网站下载rustdesk对应平台的客户端程序。 rustdesk官网 https://rustdesk.com 然后通过设置客户端的网络选项进行设置。我这里给我的rustdesk服务端指定了两个域名： + tcp和udp的连接指向的域名或者ip（端口2116-2117，只需要填写域名或者ip即可） + web服务转发出来的域名 （http 端口 21114 ），如果您不想再把http服务转发一次，直接使用http://域名或ip:21114即可  设置好以后，就可以在客户端界面上使用管理员或者新创建的人员登录  可以创建自己的地址簿，这样在不同的设备登录就可以直接连接设备  这样在不同的设备进行登录使用就可快速方便地连接。

国民NAS 飞牛零日漏洞之后：我们需要什么样的 NAS ？

前些日子被飞牛刷屏了，因为他们的零日漏洞。对于这种事我并不意外，这种“某个厂商又被爆出高危漏洞”的新闻，在过去几年里已经见过太多次了。威联通被勒索软件批量打过，群晖也出过远程代码执行的高危洞，甚至于阿里云盘也有照片“串号”的问题。只是平时刷到这类消息的时候，大多数人都会下意识地划过去，觉得这更多是厂商的锅，恰好我们没有用这个产品，或者没有被攻击过。直到这次轮到飞牛，论坛里有人说“已经被扫到”“后台被进过”“文件目录被翻过”，甚至资料被公开售卖，我甚至想说，我只想安安静静地存个东西就那么难吗。 但是感慨的原因，并不在于某一个厂商被爆出漏洞，而在于我们一直默认家用 NAS 是一类“相对安全的设备”，但现实并不完全是这样。当我们做内网穿透、端口转发的时候，运营商会禁止我们对外提供服务，这么看来倒是一种保护了。在漫长的斗智斗勇过程中，我们也学到了不少专业知识，但如果非要用数据泄露来交学费，那实在是太过惨痛了。 先说清楚，这篇文章无意针对飞牛以及其他厂家，我也是飞牛，群晖和威联通的忠实用户。他们能在市场上有这么多用户量，靠的是真本事，这一点谁都没法否认。 但这次漏洞事件暴露出来的东西，不是换个品牌、打个补丁就能翻篇的。它让我开始琢磨一个更根本的问题：我们玩了这么多年的家用 NAS，这套远程访问的路子，是不是从架构上就有一道天花板在那摆着？ https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.developer.tools 如果把情绪抽离掉，从工程视角来看，飞牛这次零日漏洞暴露出来的问题其实很清晰。攻击路径并不是“有人猜中了你的账号密码”，也不是“你没开双因素认证”。根据已公开的信息，这次事件中至少涉及一个 CVSS 评分 9.8 的严重目录遍历漏洞（CVE-2025-0510），攻击者无需任何认证即可从OS中获取敏感信息，执行任意脚本，完成从“数据窃取”到“完全控制”的整条攻击链。 从飞牛论坛用户的清理反馈来看，攻击者的持久化手段相当专业：修改系统启动脚本（system_startup.sh）植入恶意代码，加载恶意内核模块隐藏进程，给恶意文件设置 immutable 属性防止删除，甚至篡改 DNS 设置将 OTA 升级域名指向无效地址，让设备无法自动更新补丁。 有用户反馈恶意程序在凌晨三点定时激活，每隔一小时执行一次，反复清理三天才最终平息。飞牛官方虽然紧急发布了 fnOS 1.1.15 和 1.1.18 安全补丁，但对于那些已经被植入内核级后门的设备来说，补丁来得再快也已经晚了——因为攻击者早就把升级通道堵死了。 这不是飞牛独有的问题。，它出现在一个已经上市的 NAS 产品中，恰恰说明了一个残酷的现实：NAS 厂商的安全开发水平参差不齐，而用户对此几乎没有任何鉴别能力。放在任何一家做 NAS 的厂商身上，本质都是同一个模型下的必然风险。 我跟很多人的第一反应一样：后台开了 MFA，SSH 加了密钥认证，密码也够复杂，应该没事吧？  但这次事件让我不得不面对一个很残酷的事实：这些防护手段，防的是“有人试图登录你的账号”，而不是“有人绕过登录直接打穿你的服务”。零日漏洞的可怕之处恰恰在于，它往往发生在认证流程之外。攻击者不需要知道你的密码，不需要通过你的 MFA，他直接请求一个有漏洞的接口，就能拿到系统权限。你精心配置的那些安全措施，在这条攻击路径上根本没有出场的机会。 就像你给大门装了三道锁，但小偷是从窗户翻进来的。 这件事真正让我警醒的，是它逼我重新审视“家用 NAS 到底是什么”这个问题。我们习惯把 NAS 当成一个“带点智能的网盘”，买回来插上硬盘，装几个套件，配好远程访问，就觉得万事大吉了。 但从技术结构上看，它更像是一台长期在线的小服务器：有 Web 管理后台，有文件服务接口，有各种插件和后台服务在跑，有远程访问需求，有公网可达入口。换句话说，它具备了服务器的全部攻击面，却经常被用户用消费电子的心态来对待。我们会很自然地为了方便打开端口映射、配置 DDNS，让设备可以随时在外网访问，却很少有人真正意识到：这相当于把一台服务复杂、补丁节奏完全依赖厂商的服务器，直接放在了公网边缘，24 小时不间断地接受全球扫描器的“体检”。 飞牛的零日漏洞，其实只是把这个结构性问题放大到了所有人眼前。 我后来花了不少时间去想一个问题：为什么 NAS 的安全事故总是以这种方式发生？不是用户密码太弱，不是配置太离谱，而是厂商的某个服务组件出了洞，然后大量暴露在公网的设备被批量扫描、批量利用。 想来想去，答案其实很简单——因为传统 NAS 的远程访问模型，从根子上就是“让公网能直接打到你家设备”。无论你是通过端口映射、DDNS，还是厂商提供的云中转服务，最终都意味着你的管理面或服务面在公网有一个可被发现的入口。这个模型在便利性上没问题，但安全性完全依赖两个前提：厂商永远不出漏洞，以及用户永远配置正确。而这两个前提，在现实中从来没有同时成立过。 做过安全的人都知道一个很朴素的原则：缩小攻击面，永远优先于修补漏洞。与其指望“厂商永不出洞”，不如从架构上减少公网暴露。如果攻击者连你的设备都扫不到，那么即使系统里存在未知漏洞，被利用的概率也会断崖式下降。这不是什么高深的安全理论，这是安全工程的第一课。但遗憾的是，绝大多数消费级 NAS 的产品设计，并没有把这个原则放在优先位置。它们更关心的是“用户能不能方便地远程访问”，而不是“这种访问方式是否在架构上足够安全”。 也正因为这样，我后来开始反思一个更根本的问题：是不是我们一开始就选错了“家用私有云”的技术路线？传统 NAS 的远程访问模型，本质上是假设“公网直连 + 用户自行加固”，这在早期小规模使用时尚且可控，但随着 NAS 功能越来越复杂、用户群体越来越非技术化，这种模型注定会不断放大安全风险。它把服务器级别的安全责任，转嫁给了普通家庭用户，而这本身就是一个不太合理的设计前提。你不能一边把产品卖给“想要一个家庭网盘”的普通人，一边要求他们具备运维一台公网服务器的安全能力。 想清楚这一点之后，我重新选方案的第一标准就变了：不是功能多不多，不是品牌响不响，而是——公网能不能扫到我。在这个标准下，任何能做到“默认不暴露公网”的方案，都比传统 NAS 架构更符合我的安全预期。 后来接触到懒猫微服的时候，说实话我一开始是带着怀疑态度的。市面上打着“私有云”旗号的产品太多了，很多不过是换了个壳的 NAS。但真正让我停下来认真看的，是它的整体架构设计思路。 根据懒猫微服官方开发者文档的描述，懒猫微服的系统分为三层架构：最底层是一个极度精简的底层系统，只负责网络连接、安全认证，以及业务操作系统的启动和更新，目标是保证不管怎么升级，系统永远不会挂；中间层是业务操作系统，负责网络隔离、应用调度、资源管理；最上层是 LPK 应用层，这是懒猫自己的容器格式，官方强调这种容器格式在权限隔离与运行时控制上的安全边界更可控，并计划逐步补充网络流量审计、网络限制和用户权限控制等能力，用来尽量降低应用层对系统整体安全的影响。这种分层设计的好处很直观：底层保证稳定性，中间层保证隔离性，应用层尽量把风险限制在可控范围内，不会因为某一层出问题就牵连整个系统。  但真正让我觉得这个产品在安全思路上跟传统 NAS 拉开差距的，是它的网络传输机制。懒猫微服的远程访问分为两种模式：当终端设备所在网络具备 IPv6 或 NAT3 条件时，系统会自动与用户设备建立直连传输；当网络环境较差时，系统会自动切换到中继数据传输服务。关键在于，无论哪种模式，数据传输都采用端到端加密技术，传输内容对包括平台运营团队在内的任何第三方均不可见。而且这个穿透服务属于系统网络层能力，所有应用——包括官方应用、开发者自主开发的应用、甚至开发者搭建的虚拟机——都自动受益，不需要用户为每个服务单独配置网络穿透规则。 这意味着什么？意味着你不需要在路由器上开端口映射，不需要配置 DDNS，不需要自己搭建穿透机制或反向代理。设备是主动向外建立加密通道的，公网扫描器看到你家的公网 IP，也发现不了任何可直接访问的服务入口。这从根本上改变了攻击面模型：传统 NAS 是“我把服务摆在公网等你来连”，懒猫微服更像是“我主动出去建立连接，但外面的人看不到我”。对于这类零日漏洞的攻击场景——攻击者批量扫描公网 IP、发现暴露的管理接口、利用漏洞打进去——在这种架构下，第一步就很难成立，因为根本没有暴露在公网的入口可以被扫描到。 当然，这种“默认不暴露公网、依赖穿透与中继”的模型也不是没有代价：它对平台控制平面的稳定性依赖更强，也意味着用户在一定程度上需要信任厂商的网络基础设施能力。安全复杂度从用户侧转移到了平台侧，这对厂商自身的安全工程能力提出了更高要求。一旦平台侧出现故障，设备本身是安全的，但远程访问体验可能会受到影响，这是这种模型天然需要承担的代价。而且作为一个相对年轻的产品，它的生态成熟度跟老牌 NAS 厂商相比还有差距，自研的容器格式也需要更长时间的社区检验。这些都是选择这种架构路线之前必须接受的现实成本。 懒猫微服的理念文档里有一段话让我印象很深。它的创始人做了二十多年开源社区，他观察到的一个长期问题是：当个人数据逐步被公有云化之后，商业模式往往会不可避免地走向基于数据的变现逻辑。懒猫微服希望通过私有硬件把个人数据重新放回用户手里。这句话本身听起来像口号，但如果从产品架构反推，这确实是它很多设计选择背后的出发点——例如默认不暴露公网入口、强调端到端加密、尽量减少对第三方的信任假设。当一个产品从理念层面就把“数据尽量掌握在用户自己手里”当成优先目标，它在安全设计上的取舍，确实会和那些更偏向功能堆叠的产品不太一样。 从工程实现的角度看，懒猫微服更像是在家庭场景下尝试零信任网络的落地：默认不信任公网，默认不暴露服务，通过身份认证与加密通道来建立访问路径。它并不能保证系统永远没有漏洞——没有任何系统能做到这一点——但它把风险从“公网随意可达、被扫到就可能被打穿”，压缩到了“必须先突破身份体系和加密隧道”的范围内，攻击成本的量级明显不在一个级别上。 硬件层面的事情也值得单独提一下，因为很多人忽略了一个事实：安全能力本身是吃资源的。端到端加密、容器隔离、服务沙箱、AI 本地索引，这些能力全部打开之后，对 CPU 和内存的消耗是实打实存在的。很多入门级 NAS 为了控制成本，硬件资源本身就偏紧张，用户为了“用得顺”，最后只能关掉一部分功能，甚至包括一些安全相关的能力。懒猫的硬件定位更偏向“家庭私有云工作站”，整体资源相对充裕一些，所以在实践中更容易做到“该开的安全能力不需要为了性能被迫关闭”。这一点对安全体验的影响，其实比参数表本身更重要。 还有一点我觉得值得单独说的，是这个团队给人的感觉。 用过 NAS 的人大概都有过类似体验：遇到问题去官方论坛发帖，要么石沉大海，要么收到比较模板化的回复，很难确认对面是否真正理解你的具体场景。 懒猫这边给我的感受完全不一样。他们的一线技术支持是真正懂 Linux 的工程师在做，不是外包给念话术脚本的客服。你提一个问题，回你的人可能就是写那段代码的人，给出的不是套话，而是具体的排查思路或实现路径。用他们自己的话说，逻辑其实很简单：我们是最会玩 Linux 的那批人，你要的我们都有，花钱支持我们的客户，我们就实时响应。这种态度在国内硬件厂商里不多见，对我这种爱折腾的人来说，这种沟通方式本身就是产品体验的一部分。  实际使用下来也确实如此。懒猫有自己的用户论坛，也有比较活跃的社群，用户反馈的问题经常能看到开发团队跟进。社区里有一个长期存在的主题是“说出你的需求，我们来移植”，开发者会协助把用户常用的自托管应用移植到他们的应用体系里。官方还提供了一些社区激励机制，鼓励开发者参与生态建设。这些机制本身并不决定产品好坏，但它们让生态的扩展变成了一种可持续的系统行为，而不是完全依赖官方单点投入。 我在论坛上写了 80 多篇懒猫微服的实战连载，从开箱到进阶到炫技，写着写着就停不下来了。推荐你在论坛的攻略里感受到我折腾这台机器的状态：《懒猫智慧屏，我以为是地表最强电视盒子，结果竟然可以改装成闺蜜机？》《用懒猫微服倒推停电时间》《sunshine+moonlight 双人串流打游戏》《蓝牙音浪，懒猫开唱》《西湖邂逅后，我手把手教她玩转 NAS》《坏掉的 Windows 不要扔，硬盘插在懒猫上还能用》《服务器宕机之后，我和前端靠懒猫微服结对编程》。这些都是我在真实场景里折腾出来的记录。写着写着发现社区里其他人也在这么玩：有人用它存 Steam 游戏，有人用它替代 1Password 订阅，有人用它给大疆 Pocket3 导素材，有人用它做 24×7 在线开发机，有人用它的穿透服务让车机远程听黑群晖的歌。这些用法本身说明的不是“产品多强”，而是这种架构在家庭场景下确实覆盖了一些真实需求。如果你恰好是开发者，参与应用移植的过程本身也是学习——Docker 实践、npm 构建这些东西，社区里的工程师会直接带着你走一遍，至少在某个深夜，帮我解答了 docker 的 bind mount 和 volume 的异同和场景对比。  说回我自己现在的方案。折腾了这么一圈之后，我最终把家里的存储和服务迁到了懒猫微服上。不是因为它完美，而是因为它的安全模型让我第一次觉得“在远程访问这件事上不用操心”。不用开端口，不用配 DDNS，不用自己搭反向代理，也不用担心哪天又爆出一个新的零日漏洞就得手忙脚乱地去堵洞——因为公网本身看不到我的设备。端到端加密是默认开启的，平台侧也无法看到你的数据内容。三层系统架构把底层稳定性、业务隔离和应用安全分得比较清楚，不至于因为装了一个有问题的应用就牵连整个系统。 对我个人而言，权衡之后答案很明确：我宁可接受“平台偶尔不稳定”带来的体验波动，也不太愿意继续承担“设备 24 小时暴露在公网”这种结构性风险。前者更多是体验问题，后者本质上是安全问题，两者的风险量级并不在一个维度上。 如果一定要给这次零日漏洞事件一个更有价值的意义，那可能不是提醒我们“哪个厂商不安全”，而是提醒我们：家用 NAS 这条路，本身就存在一个被长期忽视的安全天花板。这个天花板不是靠换品牌能突破的，也不是靠多加几层认证能突破的，它是由“公网暴露”这个基本架构决定的。 这大概是这次事件教给我的最重要一课：安全这件事，靠补洞永远是被动的，靠架构才是主动的。选 NAS 不是在选品牌，而是在选默认风险模型。 

Vibe打金计划(3)：一二三，分步走

## 罗马不是一天建成的，骡马也不是一天累死的。 随着AI的编码能力越来越强大，像Claude和Gemini这样的模型已经可以一次性输出一个小型全栈项目了。 但这是你想要的吗？就算是，这是你敢要的吗？人类的屎山尚且无法扛起的你，能承受住这么猛烈的硅基屎山吗？ --- 回到正题，前一篇[《Vibe打金计划(2)：数据库功能测试与演示》](https://lazycat.cloud/playground/#/guideline/758) 这篇文章里说编了一个测试数据库的小应用Demo，本想这次贴出来但在审核上有点小问题目前还没有上架。（小编说测试过程中的报错会吓着用户，所以要修改一下提示。~~加上Demo没激励我也就不是很急🌚~~） 总之所以无论如何于是我同步开始了另一个应用的编写，一个真正可用的应用。 照惯例今天还会用到Refly，另外你会用到开发懒猫应用调式必须使用的开发助手。 https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.developer.tools --- # 需求整理 我本次打算开发的应用是一个可自定义的记忆闪卡的小应用，因为它前端应该比较简单，后台也刚好需要上一节提到的MySQL数据库，而且它也是我目前很需要的一个功能。 今天我不会开发完它，但是目前主要功能已经基本跑通了。 AI可以帮你编程，但产品思路不能完全靠它，或者说完全不能靠它，所以我手码了一个巨长的需求文档。（其实也不是很长，千把字，必须的功能和界面要求还是必须要详细说清。） 当然我没有直接就这么喂给AI，而是让它先梳理一下，再加上我后来想到的问题，最后统一合成一篇最终文档。  这一点上得承认，由于是站在了我这个“巨人”的肩膀上，AI最终还是比我写得好，而且一些技术点已经提前想到了。 ||| |---|---| 由于我在第一篇[《Vibe打金计划之序章: 系统提示词》](https://lazycat.cloud/playground/guideline/745)已经提到我分析了基本技术并喂给AI生成了系统提示词，再灌上一些单独的技术文档，所以其实AI已经连打包的技术也会了。 # 基础架构 我直接让它为我生成了相关的配置文件和启动脚本（虽然还不是很正确而引发了一些痛苦，但这是另一个话题了）  由于Refly目前不支持本地文件管理（MCP功能强化后可能可以） 所以与cursor或vscode中的AI不同，这里还是要手动一点点拷贝过去。 但是我已经懒到了建文件也不想自己动手的情况，所以我对它说： >为我建立一个shell脚本构建这个项目的文件结构，所有文件留为空文件，只写一行注释。另外在项目根目录下增加一个.gitignore文件，排除node依赖目录和.lpk文件  你猜怎么着？这么简单的问题它一秒搞定，我再一运行，算上拷贝保存运行也就是十几秒搞定。  而且避免了文件名或架构错误的问题，我直接粘贴就可以了。 --- # 分步开发 **很重要的一点**，让AI开发，一定要让它一步步来，先从简单的基础功能开始，再一个个模块地分拆和细化（和人类编程其实差不多，细嚼慢咽），不然它可能一下子全给你搞出来，结果就是相当难调试。 所以我在前面一步梳理需求的时候，就要求AI产出的需求文档中必须包含分几步开发的计划，这样再喂回给它的时候，这个计划就会一直保存在对话记录中，它（虽然还是会有点激进）就不会每次一鼓脑强力输出了压垮我脆弱的承受能力了。 >请认真阅读和分析这个需求文档，将其重新整理成一份逻辑更通顺，表达更加明确的需求文档。不需要编码，我将在检查表述正确之后才要求编码。 请包含开发顺序计划，先从简单基本的功能开始，一步步分模块测试确认，逐渐完善功能。 以上是我前一步让它整理需求的提示语。 结果就是它在需求文档里包含了详细的计划。  --- # 测试与同步信息 由于要求了分步开发，所以第一步我只要求它给我很基础的初步测试功能。 同时因为已经在之前的项目中纠结过了打包的路径和启动文件问题，这次顺畅了很多，基本上用了它给我的配置文件（但是需要手动修改），然后再做一些检查…… ……再用DevShell(下一篇说)装到懒猫里，同时再打开日志观察，只要启动脚本运行了，后台开始监听3000端口，我的最初目的就达到了。 ### 是的，没有几分钟，一个很简单的基础Demo就好了。  当然它也是有够简洁，连创建表单也是用系统对话框。  ## 所以先别急。 我得先把修改过的配置文件、以及开发需求和技术文档再喂回给它。  在聊天式编程而非co-polit模式时（别问我为什么不用co-polit，聊天式便宜甚至免费，~~而算力舱居然还没发货！~~），同步结果和信息非常重要，可以避免AI健忘和产生幻觉。 所以我这里在提新的需求之前，先把之前的结果同步给了AI。 >简单测试成功，我把调试后的配置文件和细化的需求同步给你。 下面请先完善前端，把样式表和JS分离出来，将创建主题的输入从系统对话框改为页面表单，并编写主题显示页面 ## 继续细化 没想到Claude也是主动，直接又把下一步给我做好了一大段，于是，一个基本的应用就搭好了大约40%。   现在的进展是做出了基本的卡片翻转界面（这对AI太容易了），然后有基本的数据库处理，包括初始数据准备、新建主题、查看主题和卡片内容之类。 接下来要做的，就是按照同样的步调，一步步去完善它了。 同时，由于是第一个Vibe应用，我对它要求还是比较高，而且还有很多坑要踩，所以这一篇的开发就打算先写到这里。 因为坦率说，虽然说得很轻松，其实我还隐瞒了大量的反复修改抽卡和纠结过程，有的问题甚至纠结到一整晚的程度。所以下一篇我要先说说痛苦的调试过程。 但无论怎么说，经过这次测试，我认为分步开发的这个方法行得通，距离我的Vibe打金计划成功又进了一步。 说是40%，懂编程的人都知道，随着屎代码的堆积，往后的山路会越走越难，所以前方应该还是任重道远。毕竟很多大佬们其实都不看好AI编程,我一个外行要做好肯定要难得多。 但是，往好的一面想，等我一旦成功……颤抖吧老王~~~~🌚

懒猫微服进阶心得（十六）：解密OpenID Connect，如何自主注册懒猫SSO？

我们移植应用的时候经常希望集成懒猫微服的SSO，在打包LPK上架应用的时候，可以使用官方的配置文件进行集成。但是我们今天想要刨根问底，让他变得通用一些。如果我本地的app想要集成懒猫微服的SSO，是不是也有其他的办法呢，毕竟是底层也是通用的OpenID Connect协议，于是便有了这个文章。 https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.developer.tools 懒猫的SSO是如下配置 ``` - Issuer：https://name.heiyu.space/sys/oauth - HTTP 监听：0.0.0.0:8000（容器内部，没有映射到宿主机端口） - gRPC 监听：0.0.0.0:5557，开启了 reflection - 存储：SQLite3 内存模式（:memory:），意味着重启后所有数据丢失 - Connector：使用 authproxy 类型，名为 hportal - 没有配置任何 staticClients（OAuth client） - 在我的网络中，IP 为 172.18.0.2 - 没有端口映射到宿主机，应该是通过反向代理（路径 /sys/oauth）访问 ``` 懒猫微服的SSO服务运行在5557 端口，通过 docker 网络访问地址是 172.18.0.2:5557。 可以先使用grpcurl来连接测试： ``` ./grpcurl -plaintext 172.18.0.2:5557 list ``` 在这里下载GRPC： https://github.com/fullstorydev/grpcurl/releases > gRPC 是一个**跨语言、高性能**的远程过程调用（RPC）框架，它**强依赖 HTTP/2** 协议，并默认使用 **Protobuf** 作为二进制序列化协议。它的核心优势在于利用 HTTP/2 的**多路复用**和**头部压缩**提升了性能，通过二进制传输减少了带宽消耗，并且通过**强类型的接口定义**保证了跨语言调用的严谨性。” 然后使用grpcurl对懒猫微服的SSO的API进行操作，因为是OIDC，所以这一步骤主要一个Oauth的应用， 也就是注册App name，client_id，client_secret，以及 redirect_uris。存储用的是内存 SQLite，容器重启后所有 OAuth token、授权码、已注册的 client 都会丢失。当然如果你想持久化的话，也可以写到systemd启动脚本让系统自启动拉起来。 ``` ./grpcurl -plaintext -d '{"client":{"id":"my-app","secret":"my-app-secret","redirect_uris":["http://localhost:8080/auth/callback"],"name":"My App"}}' 172.18.0.2:5557 api.Dex/CreateClient ```  注册之后我们把这些信息放到authlib代码里面，把SSO串起来。 ``` from flask import Flask, redirect, url_for, session, jsonify from authlib.integrations.flask_client import OAuth from functools import wraps import os app = Flask(__name__) app.secret_key = os.urandom(24) oauth = OAuth(app) oauth.register( name='dex', client_id='my-app', client_secret='my-app-secret', server_metadata_url='https://aimax.heiyu.space/sys/oauth/.well-known/openid-configuration', client_kwargs={'scope': 'openid email profile'}, ) def login_required(f): @wraps(f) def decorated(*args, **kwargs): if 'user' not in session: return redirect(url_for('login')) return f(*args, **kwargs) return decorated @app.route('/') def index(): user = session.get('user') if user: return f'Hello, {user.get("email", user.get("name", "unknown"))}. <a href="/profile">Profile</a> | <a href="/logout">Logout</a>' return 'Welcome! Please <a href="/login">Login</a>.' @app.route('/login') def login(): return oauth.dex.authorize_redirect(url_for('authorize', _external=True)) @app.route('/auth/callback') def authorize(): token = oauth.dex.authorize_access_token() session['user'] = token.get('userinfo') session['token_info'] = { 'access_token': token.get('access_token'), 'id_token': token.get('id_token'), 'token_type': token.get('token_type'), 'expires_at': token.get('expires_at'), } return redirect(url_for('index')) @app.route('/profile') @login_required def profile(): return jsonify(userinfo=session['user'], token=session.get('token_info')) @app.route('/logout') def logout(): session.pop('user', None) return redirect(url_for('index')) if __name__ == '__main__': app.run(host='0.0.0.0', port=8080, debug=True) ``` 一开始出现这个认证，这个是懒猫域名自带的认证，是为了应用放在公网的上的强制用户名密码认证，所以不要把他当作是我们本次懒猫SSO的主角。  这个才是正式的OpenID Connect，点击Grant Access，然后就可以进行认证了。  登录之后我们可以查看profile信息，以及登录之后token，这样就抓到了OIDC的去全部信息：  如果之前注册的是 localhost，但 Flask 默认用127.0.0.1 。所以会收到Unregistered redirect_uri 的错误。所以吧域名改成localhost就好。  好了，以上就是如何超越系统注册，使用API建立自己的懒猫SSO应用了，这样我们就可以不必再依赖三方的IDP了。 Less is more。

如何使用 RcloneNg 备份 vaultwarden 数据目录到其他网盘

# 背景 目前懒猫微服的备份是不支持选择特定的应用备份，而我当前只需要备份的应用数据只有 `vaultwarden` 的数据，这怎么搞呢？ https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.vaultwarden # 思路 由于安全原因，懒猫的应用容器是无法访问其他应用的数据的，即 `/lzcsys/run/data/appvar/` 目录没有挂载到每个应用容器下的。那么我们如果需要在懒猫微服上用应用备份，比如这篇文章提到的 `RcloneNg` 应用，容器内是无法直接通过本地路径访问到 `vaultwarden` 的数据目录。 **那么我们换一个思路来考虑，懒猫微服支持开通 `ssh`，我们可以通过 `rclone` 的 `sftp`，就能访问到其他应用的数据目录了！** https://appstore.lazycat.cloud/#/shop/detail/ink.akawa.ety001.rcloneng # 实施 ## 开通 SSH 在懒猫客户端中，找到下面截图中的位置，开启 SSHD。  安装“懒猫开发者工具”。 https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.developer.tools 打开“懒猫开发者工具”，确保下图的样子（我忘记这里的 `public key` 是如何增加的了）。  ## 配置 RcloneNg ### 创建读取懒猫应用数据的配置 创建一个新的配置，在第一步的 “Select” 中选择 “SSH/SFTP”，  第二步中，“SSH Host” 中输入你的懒猫地址，`[你的懒猫名].heiyu.space`; “SSH Username” 中输入 `root`; “Raw PEM-encoded private key” 输入与你刚才添加的 `Public Key` 对应私钥，这里可以使用 `awk '{printf "%s\\n", $0}' < ~/.ssh/id_rsa` 命令来转换一下格式。  保存后，这样 `vaultwarden` 的数据就可以通过这个来读取了。 > 如果你的懒猫微服磁盘IO高，那么这里保存配置的时候会等的久一些。 ### 创建备份目的地的配置 根据你的情况，配置即可。我这里配置的是局域网下群晖，使用 SMB。  ## 测试 RcloneNg 首先登陆懒猫的终端： ``` ssh root@[你的懒猫名].heiyu.space ``` 进入终端后，再进入 `RcloneNg` 容器： ``` lzc-docker exec -it inkakawaety001rcloneng-rcloneng-1 /bin/ash ``` 测试 `vaultwarden` 数据是否可读: ``` rclone ls appdata:/lzcsys/run/data/appvar/cloud.lazycat.app.vaultwarden ``` 测试你的目的地是否可读: ``` rclone ls synology:NetBackup/LazyCat/AppDataBackup/cloud.lazycat.app.vaultwarden ``` ## 编写备份脚本 根据你的需求编写备份脚本，下面是我写的，仅作参考。 ``` #!/bin/ash # 配置参数 SRC="appdata:/lzcsys/run/data/appvar/cloud.lazycat.app.vaultwarden" DST_BASE="synology:NetBackup/LazyCat/AppDataBackup/cloud.lazycat.app.vaultwarden" TIMESTAMP=$(date +%Y%m%d_%H%M%S) BACKUP_DIR="${DST_BASE}/backups" # 创建备份目录（若不存在） rclone mkdir "${BACKUP_DIR}" # 执行备份 echo "[$(date)] 开始备份到 ${BACKUP_DIR}/${TIMESTAMP}..." rclone sync -P "${SRC}" "${BACKUP_DIR}/${TIMESTAMP}" # -------------- 移除错误的软链接操作 -------------- # （因 SMB 不支持 rclone link 创建软链接，故删除以下两行） # rclone rmdirs --ignore-errors "${CURRENT_LINK}" # rclone link "${BACKUP_DIR}/${TIMESTAMP}" "${CURRENT_LINK}" # -------------- 版本清理逻辑（保持不变）-------------- BACKUP_VERSIONS=$(rclone lsf "${BACKUP_DIR}" --dirs-only | sort) # 保留每天3个最新版本 for day in $(echo "${BACKUP_VERSIONS}" | cut -c1-8 | sort -u); do daily_versions=$(echo "${BACKUP_VERSIONS}" | grep "^${day}" | sort -r) echo "${daily_versions}" | tail -n +4 | while read -r old_version; do echo "[$(date)] 删除当天多余版本：${BACKUP_DIR}/${old_version}" rclone purge "${BACKUP_DIR}/${old_version}" done done # 保留每周除当天外，其余6天各1个最新版本 today=$(date +%Y%m%d) for day in $(echo "${BACKUP_VERSIONS}" | cut -c1-8 | sort -u | grep -v "^${today}"); do daily_versions=$(echo "${BACKUP_VERSIONS}" | grep "^${day}" | sort -r) echo "${daily_versions}" | tail -n +2 | while read -r old_version; do echo "[$(date)] 删除非当天多余版本：${BACKUP_DIR}/${old_version}" rclone purge "${BACKUP_DIR}/${old_version}" done done echo "[$(date)] 备份及清理完成" # 发送邮件通知 wget -qO- https://message-pusher.xxx.heiyu.space/push/ety001?title=vaultwarden已备份及清理完成&channel=email&token=xxxxxx ``` 这个备份脚本 `backup_vaultwarden.sh`，用来保证每天有3个最新版本的备份，每周除当天外，每天保留一份备份，最后结束的时候，还会发一封备份成功的邮件，使用的是应用商店安装的 `MessagePusher`。 https://appstore.lazycat.cloud/#/shop/detail/dev.beiyu.message-pusher 把 `backup_vaultwarden.sh` 脚本增加执行权限后，通过懒猫网盘上传到 `RcloneNg` 的 `应用目录/crontabs/perioidc/hourly` 目录下面，这样每小时会执行一次这个备份脚本。  如果你想要自定义计划任务，也可以把脚本放到 `应用目录/scripts` 目录下，然后修改 `应用目录/crontabs/config/root` 文件，在里面增加自己的计划任务，如下图：  # 总结 至此，我们实现了指定应用的应用数据目录的备份操作。

Bili Sync: 自动下载你的哔哩哔哩收藏夹视频

# 一、Bili Sync 介绍 https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.bili-sync bili-sync 是一款专为 NAS 用户编写的哔哩哔哩同步工具。 它的基本的工作原理是使用用户填写的凭据定期扫描视频合集、收藏夹等，获取到本地未下载过的内容并保存到本地，维持本地视频库与哔哩哔哩网站的同步。 下载的内容包括视频、封面、弹幕、标签与简介信息等，这些文件整体保持与 Emby、Jellyfin 等媒体服务器软件兼容的文件布局，使得目的文件夹可以直接被作为媒体库添加到这些软件中，无需干预自动识别。 # 二、使用方法 ## 2.1 获取应用 在懒猫应用商店直接安装即可，省去自己部署的麻烦  ## 2.2 应用配置 首次使用打开应用，右下角会出现如下报错弹窗，不用担心，这是正常的，因为还没有认证  这时打开你的 懒猫开发者工具或右键应用查看日志，会得到一个生成的 auth_token https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.developer.tools  打开应用，切换到设置页，输入 auth_token，点击认证即可，前端未认证时都需要此 token  这个token是可以自定义修改的，默认生成的比较难记，如果在其他比如浏览器或者手机等没有登录过的地方访问时，还需要再次输入，所以建议认证后在设置里修改这个 API 认证的 Token，可以当成密码使用。 ## 2.3 添加账号 这是比较关键的部分，如何设置你的 哔哩哔哩账号 呢？ 首先要获取哔哩哔哩账号的身份凭据，在应用设置页 “B站认证“ 标签下可以看到有SESSDATA，bili_jct，buvid3，dedeuserid 和 ac_time_value 这5项需要填写 下面来进行说明： 1.浏览器打开 bilibili 首页（登录你的账号） 2.按 F12 进入开发者工具，这里以 Chrome 浏览器为例 3.点击顶部的 Application（应用），再选择左侧 Cookies，点击https://www.bilibili.com/ 4.查看你B站的 Cookie 信息，如下  上下滚动，在其中分别找到名为 SESSDATA、bili_jct、buvid3 和 DedeUserID 的 Cookie，复制他们的值填写到应用“B站认证“设置中 5.在控制台（Console）输入 `window.localStorage.ac_time_value `，打印输出的就是 ac_time_value 的值  最终设置如下  填写完毕后保存配置 之后可以浏览自己的收藏夹、关注合集以及关注的up主，看看是否认证成功  ## 2.4 订阅视频 下面介绍如何订阅收藏夹 可以在左侧 “我创建的收藏夹” 中选择收藏夹进行订阅  点击订阅，需要填写本地保存路径  默认是以 “收藏夹” 开头，我们需要改成一个绝对路径，否则会失败 在本应用中可使用路径 /bilibili/<你自定义的收藏夹名称>，对应懒猫应用数据目录下 bilibili 文件夹  然后等待应用开始同步，下载的视频会保存在这个文件夹中   可以在左侧日志选项中查看应用同步视频日志 <br> <br> 参考文档： https://bili-sync.allwens.work/quick-start