心站日志 | 心种子技术站 - MindSeed
type: channel
link: https://tech.mindseed.cn/
description: 心种子的技术日志站点，主要记录日常建站过程中遇到的各类问题，包括MediaWiki、WordPress、Limesurvey等开源系统的点滴教程。
items: 提问的智慧
items: 一个人的维基站
items: 解决上传文件时出现“413 Request Entity Too Large”错误
items: CloudFlare的又一问题，阿里云的DCDN成败参半
items: 如何管理MediaWiki命名空间
items: 在Linux中使用Trojan代理（vpn）
items: 虚拟机黑群晖“联机失败/已联结”
items: 在群晖NAS上安装git客户端
items: 在群晖NAS上通过Hyper Backup备份网站
items: CloudFlare接管阿里云域名管理后，邮箱出错
items: 暂时放弃雷池，改用CloudFlare
items: 雷池Waf手动上传证书后无法更新

提问的智慧
type: item
date: 2021-04-11T09:48:00+08:00
description: 本文转载自https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md，实在是觉得太经典了。声明许多项目在他们的使用协助/说明网页中链接了本指南，这么做很好，我们也鼓励大家都这么做。但如果你是负责管理这个项目网页的人，请在超链接附近的显著位置上注明：本指南不提供此项目的实际支持服务！我们已经深刻领教到少了上述声明所带来的痛苦。因为少了这点声明，我们不停地被一些白痴纠缠。这些白痴认为既然我们发布了这本指南，那么我们就有责任解决世上所有的技术问题。如果你因寻求某些帮助而阅读本指南，并在离开时还觉得可以从本文作者这里得到直接帮助，那你就是我们之前说的那些白痴之一。别问我们问题，我们只会忽略你。我们在这本指南中是教你如何从那些真正懂得你所遇到软件或硬件问题的人取得协助，而 99% 的情况下那不会是我们。除非你确定本指南的作者之一刚好是你所遇到的问题领域的专家，否则请不要打扰我们，这样大家都会开心一点。简介在黑客的世界里，当你拋出一个技术问题时，最终是否能得到有用的回答，往往取决于你所提问和追问的方式。本指南将教你如何正确的提问以获得你满意的答案。不只是黑客，现在开源（Open Source）软件已经相当盛行，你常常也可以由其他有经验的使用者身上得到好答案，这是件好事；使用者比起黑客来，往往对那些新手常遇到的问题更宽容一些。然而，将有经验的使用者视为黑客，并采用本指南所提的方法与他们沟通，同样也是能从他们身上得到满意回答的最有效方式。首先你应该明白，黑客们喜爱有挑战性的问题，或者能激发他们思维的好问题。如果我们并非如此，那我们也不会成为你想询问的对象。如果你给了我们一个值得反复咀嚼玩味的好问题，我们自会对你感激不尽。好问题是激励，是厚礼。好问题可以提高我们的理解力，而且通常会暴露我们以前从没意识到或者思考过的问题。对黑客而言，"好问题！"是诚挚的大力称赞。尽管如此，黑客们有着蔑视或傲慢面对简单问题的坏名声，这有时让我们看起来对新手、无知者似乎较有敌意，但其实不是那样的。我们不讳言我们对那些不愿思考、或者在发问前不做他们该做的事的人的蔑视。那些人是时间杀手 —— 他们只想索取，从不付出，消耗我们可用在更有趣的问题或更值得回答的人身上的时间。我们称这样的人为 失败者（撸瑟） （由于历史原因，我们有时把它拼作 lusers）。我们意识到许多人只是想使用我们写的软件，他们对学习技术细节没有兴趣。对大多数人而言，电脑只是种工具，是种达到目的的手段而已。他们有自己的生活并且有更要紧的事要做。我们了解这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣。尽管如此，我们回答问题的风格是指向那些真正对此有兴趣并愿意主动参与解决问题的人，这一点不会变，也不该变。如果连这都变了，我们就是在降低做自己最擅长的事情上的效率。我们（在很大程度上）是自愿的，从繁忙的生活中抽出时间来解答疑惑，而且时常被提问淹没。所以我们无情的滤掉一些话题，特别是拋弃那些看起来像失败者的家伙，以便更高效的利用时间来回答赢家（winner）的问题。如果你厌恶我们的态度，高高在上，或过于傲慢，不妨也设身处地想想。我们并没有要求你向我们屈服 —— 事实上，我们大多数人非常乐意与你平等地交流，只要你付出小小努力来满足基本要求，我们就会欢迎你加入我们的文化。但让我们帮助那些不愿意帮助自己的人是没有效率的。无知没有关系，但装白痴就是不行。所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质 —— 机敏、有想法、善于观察、乐于主动参与解决问题。如果你做不到这些使你与众不同的事情，我们建议你花点钱找家商业公司签个技术支持服务合同，而不是要求黑客个人无偿地帮助你。如果你决定向我们求助，当然你也不希望被视为失败者，更不愿成为失败者中的一员。能立刻得到快速并有效答案的最好方法，就是像赢家那样提问 —— 聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。（欢迎对本指南提出改进意见。你可以 email 你的建议至 esr@thyrsus.com 或 respond-auto@linuxmafia.com。然而请注意，本文并非网络礼节的通用指南，而我们通常会拒绝无助于在技术论坛得到有用答案的建议）。在提问之前在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情：尝试在你准备提问的论坛的旧文章中搜索答案。尝试上网搜索以找到答案。尝试阅读手册以找到答案。尝试阅读常见问题文件（FAQ）以找到答案。尝试自己检查或试验以找到答案。向你身边的强者朋友打听以找到答案。如果你是程序开发者，请尝试阅读源代码以找到答案。当你提出问题的时候，请…

一个人的维基站
type: item
date: 2023-03-01T10:37:00+08:00
description: 2015年，我突发奇想要弄一个网站，为的是方便自己做知识管理。至此，折腾之路开启……我以为找到方法、找到工具就能管理好知识，而这恰恰是我这么多年进步不大的思维误区——过分迷信“工欲善其事必先利其器”和“磨刀不误砍柴工”，而忘了自己磨刀是为砍柴的（磨刀磨出个工匠也行 ::aru:speechless:: ）。如果你对故事（个人的絮叨）不感兴趣可以直接跳到后面的章节。序曲最初，我试过自己设计网站页面，从互联网档案馆中甚至能看到最初简陋的首页。学习了一段时间的php后我放弃了。然后是WordPress，我再一次地重复了上面的老路，企图自己开发一个适合自己的插件，结局可想而知。再然后就到了MediaWiki，还是没怎么吸取教训，唯一有进步的可能就是终于学会总结了。2023年2月，站点条目一千七百多，近八成都是图书信息方面的，还有部分是从维基搬运过来的，自己创建的只有零星几条。作为一个没什么学术背景和编程能力的人来说，一个人搞维基是极其痛苦的，甚至有点自不量力的意味。借用灰机WIKI的学习地图来说，玩维基的三大问题：维基内容建设（内容向）、前端样式设计（美术向）和数据整理（编程向），基本上我——都不擅长。图片来源：https://www.huijiwiki.com/wiki/帮助:学习地图弯路选用MediaWiki时的设想很简单，把维基百科里跟心理学有关的内容搬运过来。白嫖谁不会啊？况且它的导出导入又那么好用。可真到实行的时候才发现问题远没有想象的简单，俄罗斯套娃般的模板但凡缺少一个，页面就各种红字报错。所以要么把所有的模板一并导入，要么就得修改搬运来的条目。前者我已经试过了，除非全部靠搬运，但凡自己开始编写，抄的模板能让人晕头转向——同样功能的模板可能因为不同人使用又重写了一遍还改了名，加之各种的重定向，还有在英文模板上套个中文翻译的壳，以及各种配套的Lua模块和CSS样式表。一旦开始自己写条目，面对成百上千的模板，无从下手很正常，最终还是要把所有模板都大致梳理一遍，明白目的和原理。其间之痛苦，相信很多新手维基站长都品尝过。最最不幸的可能这个新手站长还有那么点点完美倾向，那个场面……说到底，模板也只是为条目服务的，真正核心的也就那么几个，所以完全可以先从常用模板（比如信息框）下手，有针对地搬运，该合并的合并，该修改的修改，上千个模板也就只剩下几十个了。可惜这道理我用了两三年才明白。这里分享一个个人的经验，你可以先从搬运维基百科的帮助以及项目（Wikipedia:开头）内容入手，一则熟悉整个维基的格式要求、编辑方式等，另一方面可以通过逐步添加模板的方式进行学习，维基百科的模板说明通常还是比较清楚的，哪些适合自己的站点而哪些不适合也能做到心中有数。另外还有一个惨痛的教训，就是抄模板一定要“专一”，也就是内容如果从维基百科上来的，模板也最好用它的，千万不要因为其他站点同名的模板更漂亮就轻易转换阵营（我就常常同时浏览好几个维基站点，然后这儿抄一点，那儿抄一点），到最后显示效果一塌糊涂你都不知道问题出在哪里。毕竟各家的模板可能有各家的不同代码和样式表。说实话，维基百科的模板很多看上去虽然老土，还动不动就要配合Lua模块，但你要真领会了精髓，改漂亮点还是比较现实的。还有，一定记得备注从哪里抄来的。自从维基百科国内被禁之后，大部分人（包括我）可能都没有真正体验过维基写作，既不清楚方针原则，也不明白方式方法，而更要命的是我总希望跳过这些学习而进入到直接生产过程。走弯路也就不足为奇了。老路等我明白没有内容光有架子也不行的道理时，又过去了很久。百科注重的还是条目数量和质量——糊弄数量还是比较容易的，各种搬运肯定最方便（也别太指望维基百科，中文词条大量缺失，英文词条直接照搬也没用）；但是最怕的还是没有质量的胡抄乱写，岂不是违背了维基本身的意义？所以我终于痛下决心，企图通过边学习边完善条目的方式进行，权当将MediaWiki当笔记工具了（貌似我终于想起来我要砍柴来着）——而这又再一次地证明了我的自不量力。本以为新的开始会在眼前徐徐铺开，我能走上一条康庄大道。结果死性不改的我，还是走歪了。面对我浩如烟海的书，我竟不知从何下手。刷知乎、刷豆瓣，收集各种书单，然后……我花了大把时间搞了一套图书信息的模板，也花了大把时间录入了很多图书信息，甚至考虑增加藏书的功能。总而言之，我还是没能好好看书。我还是在“利其器”，只是砍刀变成了斧子——貌似磨刀真的比砍柴轻松。反馈陆陆续续创建了些图书的条目之后，我开始向百度、谷歌和必应提交站点信息，检验收录效果。而事实也证明，收录效果还是有一点的。这也是为什么我一直就在忙着弄图书条目的另一个原因，因为建条目最方便（虽然豆瓣上的信息已经很全了，不过还是有很多错误和缺失的，比如书籍目录）。没准哪一天还指着它们提高搜索权重呢~不过我内心并不…

解决上传文件时出现“413 Request Entity Too Large”错误
type: item
date: 2025-11-09T13:12:29+08:00
description: 今天在MediaWiki中上传一张稍大的图像时出现了“413 Request Entity Too Large”错误。虽然以前也上传过大图片，但用的是OneinStack一键脚本，所以一直没有出过错。之所以出现该问题，其实就在于没有对Nginx默认的request body大小进行调整，所以打开配置文件nginx.conf，在http、server或location块中，添加或修改以下参数：client_max_body_size 10M; # 根据需求调整大小（如10MB） 然后重新加载nginx的配置，问题解决。关于其他文件上传的限制，请参见《修改网站的文件上传限制》一文。

CloudFlare的又一问题，阿里云的DCDN成败参半
type: item
date: 2025-11-02T15:39:00+08:00
description: 就在刚才，发了一篇关于CloudFlare接管后邮箱设置问题的文章，贴了两张图，结果一张顺利上传并显示，另一张则没有成功。因为边写边设置，也不知道是配置出了问题，还是CloudFlare和阿里云的DCDN配合不好，总之情况就是这么个情况。打开OSS的文件列表，能显示的图片已经存在，而另一张却不在列表中。在网上搜索了半天，没能找到合适的答案，在阿里云上提交工单，给出的解决方案也并不让人满意，让我还是在CloudFlare设置上想想办法。放弃CloudFlare转换成阿里云的DNS记录，之前的问题仍然存在，上传的图片只有名称但却没有真正上传到OSS中，这也就意味着之前的判断是错误的，原因不在CloudFlare，而在阿里云的设置中。由于主站和子站使用不同的系统也有不同的OSS配置，目前来看最顺利的反而是心百科（使用MediaWiki），图像上传和显示都正常。一则它单独使用一台服务器，其他站点都共用另一台服务器；二则只有MediaWiki使用OSS是没有回源功能的，因为它使用的AWS插件并不支持这么做。所以无论我如何将参数调整成一致都可能是无用功。还有一点是，BookStack在后台清理图像时会出现524错误，也无法生成sitmaps.xml文件，这些很难说是跟CloudFlare一点关系都没有。好吧，先解决图片回源的问题。从网上有限的资料中找到一个，是关于源站SNI的，之前阿里工单中也同样提到这个。SNI（Server Name Indication）是对SSL/TLS协议的扩展，允许服务器在单个IP地址上承载多个SSL证书，可解决一个HTTPS服务器拥有多个域名但是无法预知客户端到底请求的是哪一个域名的服务问题。开启SNI后，在CDN节点向源站发起TLS握手请求时，源站会根据TLS握手请求中携带的SNI信息来确认被请求的业务域名，返回正确的SSL证书给CDN节点。如今出问题的这几个网站，就是单个IP上有多个子域名，而且每一个网站都开启了强制跳转HTTPS，所以如果想使用HTTPS不开SNI就有可能会在HTTP和HTTPS之间强制来回跳转而找不到真正的源站，最终无法回源。选择OSS的Bucket对象，在数据管理->镜像回源中创建或修改规则，勾选携带SNI选项。记得在DCDN中的回源设置中，创建默认回源SNI。上述方法在BookStack和WordPress中正常了，但在Typecho中还是存在问题，会报“424 Failed Dependency”错误。半夜提交阿里云工单，结果第二天早上的时候，图片恢复正常了。不过另一张同一时间上传的还是一样存在问题。工程师还是建议我去Cloudflare看一下，是否是因为waf将回源给拦截了。隔一天之后，BookStack站点和Typecho两个站点又都不行了，而WordPress那个无论我怎么修改设置，上传文件都一点问题没有。而且就算我在Cloudflare中将OSS的代理打开，上传图片也一点问题都没有。不过真要说有问题就是，即便是我把图片删除后，本地和OSS上都没有了，由于Cloudflare的缓存关系，在浏览器中能够浏览。参考资料https://blog.xgblack.cn/alioss-image-back-to-the-source-failure-solution/

如何管理MediaWiki命名空间
type: item
date: 2025-10-31T09:35:00+08:00
description: 什么是命名空间以及如何在MediaWiki中管理它们为了使MediaWiki更便于页面管理，所有页面根据其在网站上的目的和功能都可以按照命名空间的方式进行分组。也就是说，每个页面都属于一个命名空间。例如，所有常规内容页面（也称为文章、条目或词条）都是主（Main）命名空间的一部分，而所有个人用户页面都存储在用户（User）命名空间中。而“心理学”即可以放入主（Main）命名空间中（属于一个条目），也可以放入用户（User）命名空间中（某个用户名叫心理学），也可以放入Project命名空间中（网站名叫心理学），甚至放入某个自定义的命名空间。正是通过这些不同的命名空间，网站可以区分同一个名称的不同功能和显示内容。那么MediaWiki有哪些默认命名空间？又该如何创建自定义命名空间以及如何进行其他设置呢？默认命名空间MediaWiki内置18个命名空间。其中有两个命名空间（属于系统级别的，具体见下文）是用户无法修改的，这意味着用户无法新建和编辑其页面。而其他16个命名空间中的页面可以新增也可以编辑，且都是成对设置。也就是说，总共有8个通用命名空间以及它们对应的讨论命名空间。每个命名空间都有一个用于标识的ID号和常量名。常量名为大写，它们都以NS_开头，后跟命名空间的名称。默认命名空间的ID号和常量名在Defines.php文件中定义。该文件位于MediaWiki根目录下的includes文件夹中。当想要对命名空间的选项进行一些更改时，需要使用到ID号。下面将列出并描述每个默认命名空间以及每个命名空间的ID号（括号中是该命名空间的常量名），其中部分命名空间支持中文。-2 （NS_MEDIA） - Media命名空间。这是两个虚拟命名空间之一，用户无法修改。该命名空间的目的是提供上传文件的直接链接。-1 （NS_SPECIAL） - 特殊（Special）命名空间是另一个虚拟命名空间，其中包含用户无法编辑的页面，所有工具和统计信息的页面都属于该命名空间。可以通过单击“工具”菜单中的“特殊页面”按钮来访问和使用这些页面。0 （NS_MAIN） - 主（Main）命名空间。顾名思义，这是用于大部分页面的命名空间，即网站用户创建和编辑的条目页面。它也是唯一一个在URL中不需要输入前缀的命名空间。这意味着，与其他命名空间中的页面不同，主命名空间中的页面在URL地址中直接显示名称。1 （NS_TALK） - 条目页面中进行讨论的讨论（Talk）命名空间。主命名空间中的每个页面都可以有一个讨论页面，用户可以在该页面上发布有关文章的评论。2 （NS_USER） - 用户（User）命名空间用于保存和显示个人用户信息。每个用户都可以创建自己的页面，其中包含该用户的用户名、个人信息或他们认为合适的任何其他信息。有关用户的详细信息，请查看《如何在MediaWiki中管理用户、用户组和权限》一文。3 （NS_USER_TALK） - 每个用户页面都可以有一个相关的讨论页面——即用户讨论（User_talk）命名空间，其他用户可以在该讨论页面上向特定用户发表评论。当用户打开站点并且该用户的讨论页已被其他人编辑（即已发表评论）时，所有页面的站点顶部都会显示一条消息。该消息在用户访问其讨论页后被删除。用户也可以开启相应的选项，然后通过电子邮件收到有关其用户讨论页更改的通知。4 （NS_PROJECT） - Project命名空间的用途是存储有关网站本身相关的页面。相对于与主（Main）命名空间区，它没有任何特殊选项或功能，只是为了方便区分和管理。默认情况下，它不包含任何页面，但在网站的页脚中，有指向可以创建的页面链接，其中包括关于、免责声明和隐私政策，这些页面都使用Project命名空间。请注意，在Project命名空间的前端上所使用的标签实际上可能不一定是Project。默认情况下是使用网站提供的wiki名称进行标识，在最初应用程序安装时就会要求填写wiki名称（默认项目名称与wiki名称相同，但可以设置为不同）。如果没有更改或编辑相应的选项，则项目命名空间实际上就是网站的名称。例如，如果已将网站名设置为“心百科”，则该Project命名空间的名称就是心百科（这也是该命名空间中页面URL所使用的前缀，如心百科的网站中，关于页面就是心百科:关于）。但请记住，在搜索或打开该命名空间中页面URL时，Project仍可用作前缀。它们将被重定向到实际名称（除非你将网站名设为Project）。如果我们使用心百科作为网站名，则可以使用wiki.mindseed/心百科:关于和wiki.mindseed/project:关于打开网站的关于页面。安装应用程序后，可以通过修改文件LocalSettings.php中的相应选项来更改站点名称和Project命名空间的名称（也称为元名称…

在Linux中使用Trojan代理（vpn）
type: item
date: 2025-10-20T16:39:55+08:00
description: 因为在路由器中内置了clash，所以只要联上网就能畅通无阻地浏览各大网站。但总有外出的时候，如果是windows，使用Trojan-Qt5，设置简单占用资源又少，这么多年也一直没放弃它。但是linux就比较麻烦，可视化界面的应用比较少，比如ubuntu的应用商店中的shadowsocks-electron，虽然配置后测速通过，但就是不知道为什么不能打开网站。那就用命令行的trojan试试，反正也是偶尔才会用到。首先，下载源码并解压：wget https://github.com/trojan-gfw/trojan/releases/download/v1.16.0/trojan-1.16.0-linux-amd64.tar.xz tar xf trojan-1.16.0-linux-amd64.tar.xz -C /opt/ 然后复制一份客户端的配置模板：cd /opt/trojan cp examples/client.json-example client.json 修改配置文件中的基本设置："run_type": "client", // 运行类型 "local_addr": "127.0.0.1", // 本地监听地址 "local_port": 1080, // 本地监听端口 "remote_addr": "", // 服务端的ip或域名 "remote_port": 443, // 对应服务端的端口 "password": [ "passwd" // 对应服务端设置的密码 ], 如果没有ssl，可关闭验证，修改如下："verify": false, "verify_hostname": false, "cert": "", "sni": "", 其余保持不变。运行如下命令以验证配置是否成功：/opt/trojan/trojan -t /opt/trojan/client.json 正常情况下是不会有什么问题的，即便有也会生成相关日志。可以通过systemd进行管理，编写服务文件trojan.service（保存于/usr/lib/systemd/system/目录下），内容如下：[Unit] Description=trojan Documentation=man:trojan(1) https://trojan-gfw.github.io/trojan/config https://trojan-gfw.github.io/trojan/ After=network.target syslog.target [Service] Type=simple StandardError=journal User=nobody AmbientCapabilities=CAP_NET_BIND_SERVICE ExecStart=/usr/local/share/trojan/trojan -c /usr/local/share/trojan/client.json ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=60s [Install] WantedBy=multi-user.target 执行如下命令启动trojan服务：systemctl daemon-reload systemctl enable trojan systemctl start trojan 最后，在浏览器的网络设置中修改手动配置代理，具体如下：打开谷歌，顺利显示。

虚拟机黑群晖“联机失败/已联结”
type: item
date: 2025-10-17T17:04:00+08:00
description: 因为要帮网友搞网站备份（见《在群晖NAS上通过Hyper Backup备份网站》一文），不得不把之前的黑群晖虚拟机翻出来。打开vmware，运行虚拟机。同时，打开Synology Assistant，搜索服务器，结果在状态栏中显示无法联机。IP地址应该是之前设置的，但我现在用的笔记本IP地址通常为192.168.50.x，跟原有的192.168.72.x不在一个网段中。首先，重新设置群晖的ip地址。选中服务器并点击设置按钮，出现Synology Assistant设置向导，点击下一步。输入用户名和密码，再次点击下一步。在网络设置界面中选择手动设置，并分别填入希望设置的IP等信息，点击完成。系统会检验该IP是否被占用，如果没有的话将会把上述设置写入群晖服务器，一切顺利的话，会弹出“网络设置完成”的对话框，并重新扫描服务器。通常情况，状态会显示已就绪。如果还是存在联机失败的话，可以考虑从以下两方面入手：1、尝试将虚拟机的网络设置有NAT改为桥接；2、禁用无关的网络适配器，比如VMware Network Adapter VMnet1之类的（见下图）重新搜索服务器，如果还是显示联机失败，可以多试几次，至少我一圈折腾下来终于连上了。

在群晖NAS上安装git客户端
type: item
date: 2025-10-17T14:28:12+08:00
description: 还是关于在群晖NAS上安装BookStack的后续，网友希望我能帮他把服务器端升级到最新版。老样子，还是现在虚拟机上先测试一下。打开黑群晖，然后连上SSH，进入BookStack的安装目录，按照官方文档的说明，在命令行中运行如下：git pull origin release 系统提示找不到git命令。虽说群晖属于linux系统，但它毕竟是定制化的，常用的apt或者apt-get、yum、akg等方法一律无法使用。而网上给出的解决方案有几种：一种是在套件中心中直接安装git，可惜我的DSM 7.2版中并没有这一项，只有git server；另一种是直接下载安装包手动安装（下载地址：https://synocommunity.com/package/git），但列表中没有7.2的选项，因此暂且放弃。还有另一种方法其实跟上述后者比较相似，但更加简便，步骤如下：以管理员身份登录NAS，然后转到主菜单→套件中心→设置。在“套件来源”选项卡中，单击“新增”，键入“SynoCommunity”作为“名称”，键入“https://packages.synocommunity.com/”作为“位置”，然后按“确定”进行验证。回到套件中心界面，此时在左侧会多出一个社群的链接，点击后在右侧会出现社群中的各种第三方套件，找到git并点击安装套件即可。回到控制台中，重新执行上述的命令行，运行成功。注意：如果安装git的是某一特定用户，使用其他用户运行该命令可能会提示“/bin/git: No such file or directory”错误，切换会安装用户即可。另外，安装git客户端之后在NAS的管理界面中是找不到的，也无法进行任何设置。

在群晖NAS上通过Hyper Backup备份网站
type: item
date: 2025-10-17T12:15:28+08:00
description: 之前帮忙安装bookstack的网友又联系我，说是希望能够定期备份网站。因为他们的应用是安装在群晖NAS上（有兴趣的可以参看《在群晖NAS上安装BookStack（一）——使用Container Manager》《在群晖NAS上安装BookStack（二）——使用Web Staion套件》），所以使用传统的linux命令方式恐怕比较困难（登陆ssh后，无法使用crontab命令）。幸运的是，群晖自带的备份系统提供了一个更加简便的备份方始，以下操作通过虚拟机进行，系统为DSM 7.2。一、新建共享目录在开始前，我们需要先新建一个共享目录用于放置备份内容。打开File Station应用，点击右侧指令栏中的新增按钮，并选择创建共享文件夹。填写共享文件夹的名称（为方便管理可以添加适当的描述），并一路点击下一步。如果没有特殊的权限要求，则最终点击应用。二、安装套件Hyper Backup及备份设置进入NAS的应用中心，找到Hyper Backup并点击“安装套件”按钮。稍等片刻，打开该应用。点击左上角的加号标志，在“选择备份类型”界面中保持默认（即文件夹和套件选项），然后点击下一步。在“选择备份目的地”中选择“本地共享文件夹或USB”（这里只考虑本地备份），点击下一步。在“选择备份版本类型”中选择“单一版本”（多个版本和单一版本的文件保存方式有所不同，后者可以方便转移到任何其他设备或直接查看），点击下一步。在“备份目的地设置”中选择第一步中新创建的共享文件夹，然后点击下一步。“数据备份”界面中选择网站的安装目录，在本例中为web目录下的bookstack，点击下一步。在“应用程序备份”中选择数据库程序，在本例中为MariaDB 10，点击下一步。在“备份设置”中设置任务名称以及给备份目录起一个方便管理的名称（可以保持默认），并且根据自己的需要设置备份的周期和时间（这里保持默认）。其中有一项“保留目标端已备份文件”可以根据自己的需要进行勾选（一旦勾选，那么当源目标中的文件删除，如网站中某张图片被删，备份时仍保留该删除的文件，但会浪费一定的空间），点击下一步。最后是备份的摘要，如果没有问题就直接点击完成。即便是设置有问题，后面还是可以进行修改的，所以尽可放心。系统会提示是否立即备份，点击是。系统会回到主页面，并显示备份进度。根据备份内容的多少，时间不等。因为虚拟机上没什么内容，几分钟就搞定了。而那位网友的网站内容差不多有10个G左右，加之有其他应用在使用，所以整个备份时间还是很长的（在进行到100%的时候停留了十几分钟，一度以为系统出问题了）。打开备份目录，检验一下结果。其中@app目录是应用的备份（在本例中为MariaDB 10），web即网站文件。如果想修改备份设置，点击立即备份右侧菜单中的编辑即可。至此，整个备份的设置便已完成。三、备份还原还原的过程比较简单，基本上就是一路下一步即可（其中在数据还原和应用程序还原中需进行勾选）。这里还是简单记录一下。在还原数据库时，系统会提示应用将被禁用，是否确定继续，点击是。最后点击完成。系统会显示还原进度，在此过程中网站可能会打不开，因为数据库程序MariaDB被暂时禁用了。全部完成后，网站又还原到备份时的样子，所有删除或新增的内容均已恢复。

CloudFlare接管阿里云域名管理后，邮箱出错
type: item
date: 2025-09-14T11:45:00+08:00
description: 本来以为只要照搬阿里云的域名解析到CloudFlare就可以了，没想到发送测试邮件后竟然报错了。点击其中的帮助链接，说是MX解析错误。可我明明已经原样复制了阿里云的解析记录，怎么会不行呢？帮助文档中说的，可以使用：解析的域名记录类型优先级解析记录值@MX5mx1.qiye.aliyun.com@MX10mx2.qiye.aliyun.com@MX15mx3.qiye.aliyun.com当然它也提到可以使用另一种：解析的域名记录类型优先级解析记录值@MX5mxn.mxhichina.com@MX10mxw.mxhichina.com不过当初设置的时候第一种方式一直好用也就没想过换。登陆邮箱管理员账号，在企业定制->域名管理中，点击检查MX解析，如果一切正常应该出现如下的结果：从最初反馈的结果来看，少了一个TXT记录(DKIM)，顺带把MX记录也一起改了。等待几分钟后，发送测试邮件，一切正常。像这种多少年都不修改的解析记录，在重新配置时可能会出现状况，最好还是按照最新的来，阿里云自家知道兼容，但CloudFlare未必知道。另外，第三方邮件客户端（比如网易邮箱大师）中，POP3和SMTP的设置还是使用阿里云的地址为好，原本我使用了pop.mindseed.cn在这次重新托管后出错了，切换回阿里云的就好了。协议服务器地址服务器端口号（常规）服务器端口号（加密）POP3pop3.mxhichina.com110995IMAPimap.mxhichina.com143993SMTPsmtp.mxhichina.com25465

暂时放弃雷池，改用CloudFlare
type: item
date: 2025-09-14T09:49:00+08:00
description: 雷池安装使用有好几个月了，虽然被爬虫搞死机的情况是少了，但流量也是一落千丈，为了确保前者就不得不开始BOT防护，而这却是导致后者的重要原因。毕竟误伤的可能性还是存在的，或者是点击页面就出现个雷池的加载页面还是挺让人恼火的，不知道的还以为点错网站了。忍无可忍的情况下还是打算先尝试一下CloudFlare，之前一直听说它是减速器，所以就没打算用它，现在被爬虫搞得服务器都快奔溃了，网站慢一点总好过网站打不开吧。登陆CloudFlare控制台，输入现有的网站域名后，使用快速扫描DNS记录（之后会返回扫描到的结果，也可以根据实际情况可以自行增删），然后点击继续按钮。为域名选择计划中选择free即可，之后返回扫描结果，暂时可以不用管，点击继续按钮。登陆域名服务商（比如阿里云），在域名基本信息中修改DNS记录，比如将dns2.hichina.com、dns3.hichina.com替换成fatima.ns.cloudflare.com、harley.ns.cloudflare.com（由CloudFlare提供）。回到CloudFlare控制台，过一段时间之后就会通知你现在已经可以由它接手了。此时在浏览器中输入域名，可能会提示ERR_SSL_VERSION_OR_CIPHER_MISMATCH错误，那是因为网站使用的仍然是之前由acme申请的证书，而非CloudFlare提供的SSL证书。点击SSL/TLS中的边缘证书，其中证书状态显示待验证（TXT），点击后将证书验证的TXT名称和TXT值复制到域名解析记录中（主机厂商的，比如阿里云，而不是CloudFlare的DNS解析）。一共有两个记录，一个主域名，一个通配符的（适合子域名）。稍等一段时间，待验证通过后，CloudFlare会自动申请证书。重新刷新网站，此时应该就可以正常浏览网页了。点击证书，颁发者变为Cloudflare TLS Issuing ECC CA 1。值得注意的是，如果之前使用了CDN，那么CloudFlare的DNS中如果没有添加CDN的记录，那么图片是无法显示的，此时就需要将这部分添加进去。如果有免费的域名邮箱，同样记得添加记录。好了，今天暂时就这样，明天再继续折腾。

雷池Waf手动上传证书后无法更新
type: item
date: 2025-08-25T09:33:52+08:00
description: 心百科的证书到期了，打开雷池的管理界面，在通用设置中尝试手动上传证书进行更新。但让人恼火的是，控制台中显示的证书有效期并没有随之更新。而此前类似操作却是可以的。径默认的证书保存在/data/safeline/resources/nginx/certs下，查看证书的修改日期确实是最新的，并且打开后与上传的证书内容一致，也就是说证书上传没有问题。尝试重新启动雷池，使用官方给出的命令如下：container_id=$(docker ps -n 1 --filter name=.*safeline-mgt.* --format '{{.ID}}') SAFELINE_PATH=$(docker inspect --format '{{index .Config.Labels "com.docker.compose.project.working_dir"}}' $container_id) cd $SAFELINE_PATH && docker compose down && docker compose up -d 证书信息仍然维持在过期状态，没有任何效果。雷池的升级日志中对于9.2.2的记录就是修复部分情况证书无法续期的问题，显然我的问题并没有得到有效解决。尝试卸载最新版的雷池，改装9.1.0-lts版。由于卸载后所有配置均被删除，只能重新创建应用。再次手动上传证书，结果还是显示证书过期。进行到这里，感觉只有等雷池的更新版本出来或许才可以解决问题。在技术群和论坛中都提交了问题，可惜迟迟没有回应。既然雷池方面没办法，那就从证书方面考虑了。在使用雷池前，所有证书都是通过网站服务器中的acme生成。在测试和配置雷池时，因为不确定是否能使用长久，所以所有的证书文件都是从网站服务器中下载后再手动上传到雷池中。每次升级证书同样是下载新证书再上传，直到这一次出现状况。既然手动上传的有问题，那就直接在雷池服务器中生成证书，然后直接替换掉原有的证书（比如/data/safeline/resources/nginx/certs目录下的cert_1.crt和cert_1.key，表示的是雷池第一个创建的应用）。根据acme的教程，使用DNS的方式生成证书，然后复制安装新证书，命令如下：acme.sh --install-cert -d example.com \ --key-file /data/safeline/resources/nginx/certs/cert_1.key \ --fullchain-file /data/safeline/resources/nginx/certs/cert_1.crt \ --reloadcmd "docker exec safeline-tengine nginx -s reload" 刷新雷池控制台，问题依旧。但过了一段时间之后，无意中再次刷新控制台，证书终于正常了。用群里网友的说法，用雷池还是有一定的玄学意味在的，所以整个过程中我并不确定到底是哪个环节使得问题最终得到了解决，只能说运气使然。