Webinoly的娘化形象

依然是趁热打铁，之前一直也想画各种软件的拟人娘化形象，
索性就画了喜爱的Webinoly的娘化形象！

因为Webinoly是运维管理的用途，
所以设计元素便以管理员的形象靠拢。
像是年龄在25-28岁的大姐姐、给人沉稳信赖这样的感觉……
但相较于那些千禧年代的老前辈（比如各种面板）
Webinoly又有一种年轻的外貌。

额，也许有一种工具包的设计会更好？
因为随时会使用常用的工具模板部署简单的网站。
（那这样的话不就是科学搜查官嘛！！）

来源

本文以Webinoly提供的LNMP环境，记录安装BookStack的过程。

目前，安装BookStack要求的配置是：

• 命令行访问权限 并安装 gnupg git unzip curl 软件包
• PHP 版本>= 8.2
  • 需要在命令行执行php命令的权限
  • 要求开启的PHP扩展：gd, dom, iconv, mbstring, mysqlnd, openssl, pdo, pdo_mysql, tokenizer, xml, zip
  • 可选扩展：ldap （用于 LDAP 身份验证），exif （用于图像处理）
  • 对于PHP MySQL数据库驱动，首选 nd (Native Driver) 扩展，否则使用默认 mysql 驱动扩展。
• MySQL 版本>= 8.0 或MariaDB 版本>= 10.6
  • 用于存储 BookStack 内容和数据
  • 建议单独创建拥有所有权限的单个数据库
• Git 用于下载与更新
• Composer 版本>= v2.2.0 用于安装和管理依赖项
• 兼容 PHP 的 Web 服务器 例如 Nginx

创建网站

先通过Webinoly的site命令创建PHP网站、及其对应目录与数据库。顺带配置SSL证书：

site domain.ltd -php -mysql
site domain.ltd -ssl=on 
# 可选：自定义证书参数 -ssl-crt=[证书位置] -ssl-key=[证书私钥位置]

手动安装

前往 /var/www/domain.ltd/ 目录，克隆BookStack的Git存储库：

cd /var/www/domain.ltd/ 
git clone https://source.bookstackapp.com/bookstack.git --branch release --single-branch bookstack

进入bookstack目录，执行Composer安装：

cd ./bookstack
composer install --no-dev

基本配置

基于.env.example 模板复制，创建 .env 配置文件，填入网址和数据库信息：

# Application URL
APP_URL=https://example.com

# Database details
DB_HOST=localhost
DB_DATABASE=database_database
DB_USERNAME=database_username
DB_PASSWORD=database_user_password

后续可通过命令 php artisan bookstack:update-url 更新应用网址也就是APP_URL：

随后在终端执行生成应用密钥的命令：

php artisan key:generate

配置Nginx

下文的Nginx配置，以book.lan域名并以HTTP（仅80端口）访问为例：

# WebinolyNginxServerStart
server {
	listen 80;
	listen [::]:80;

	server_name book.lan;

	access_log /var/log/nginx/book.lan.access.log we_log;
	error_log /var/log/nginx/book.lan.error.log;

	root /var/www/book.lan/bookstack/public;

	index index.php index.html index.htm;

	include common/auth.conf;

	# WebinolyCustom
	  location / {
	    try_files $uri $uri/ /index.php?$query_string;
	  }
  
	  location ~ \.php$ {
	    include fastcgi_params;
	    fastcgi_pass unix:/run/php/php-fpm.sock;
	  }
	# WebinolyCustomEnd

	#include common/phpx.conf;
	include common/locations.conf;
	include common/header.conf;
	include /var/www/book.lan/*-nginx.conf;
	include /etc/nginx/conf.d/*.conf.srv;
}

分析：

Webinoly默认的php配置 include common/phpx.conf;
不适用Bookstack要求的query_string，需要将其注释而不调用。

官方文档位于 location ~ \.php$ { 部分的配置行： include snippets/fastcgi-php.conf;
也不适用于目前Webinoly安装的配置（没有这个目录与文件）， 不然会无法调用PHP FastCGI导致白屏。

取而代之的是：include fastcgi_params;
后者文件实际位置位于nginx目录根。

使用

此时打开浏览器即可使用 Bookstack ，创建并登入账号……

来源

把服务器那档子事情处理一些之后，
就准备把Webinoly的命令手册翻译一下了。

上一次翻译一个项目也是23年，我翻译了一个Aria的远程下载器AWGG…… 那时候还在用旧圈名。

话说回来Webinoly最近更新了网站主题和LOGO，咦？怎么没有繁体中文版了？访问 zh 页面只有得到410，看起来好像是撤了，不清楚是不是有瓜葛，只有Wayback Machine还有一份 主页存档 。

有这个想法还得是2024年Alex翻译了繁体中文版本之后（而且直接用zh我觉得很想吐槽），不过当时动笔也只是用OneNote还没拷完下了一份英文原版，然后一直搁置至今。

现在有了Obsidian这个工具，就用了Obsidian Web Clipper来保存。说起来Obsidian这金刚石也在我电脑呆了一年多没用，实际上手感觉真的很好用。虽然跟OneNote那种自由笔记+绘图功能的模式没法比，但不得不说OneNote在笔记这方面也老了。加上之后打算用MkDocs或是其他Markdown的Wiki网站生成器，Obsidian自然是首选。

关于翻译流程呢，还是是先翻译文章内容：
用谷歌和Deepl辅以人工上下文润色，再重新审阅修复一些翻译出现的问题，根据上下文替换专有和习惯词汇（例如子文件夹原文是folder但在中文网管环境、用目录更容易理解）。
不得不说谷歌翻译的质量其实可以，只有某些地方会出现无法理解甚至出现俄语的BUG……

其实可能可以用AI，但一方面画师身份不允许我这样搞，
其次AI目前还是顾及不到这种小众文档，全文直接翻译的话感觉质量很差。换句话说，谷歌翻译实质上还是神经模型的AI，只是拷贝粘贴变成出力不讨好的人工操作，
但即便如此费力，对我来说也算是重新回顾了一遍文档上的各种功能。

而且软件文档这种东西，果然还是用过的人翻译比较靠谱，
问题实际上不是AI翻译质量、而是AI是否在用过的前提下理解Webinoly程序的功能。AI味和普通机翻味一样，实际上是译者不负责任的表现，如果译者用心润色的话，那么机器翻译的效果其实不会那么糟糕。

不过复制粘贴确实很累，左边窗口放Obsidian、右边放谷歌跟Deepl浏览器窗口。

半夜坐台式机面前端坐滑鼠标相当累，但实际上用触屏笔记本就能改善很多。我爱YOGA！（虽然现在我用的是戴尔的YOGA，就像吉普车可以指代各种越野SUV）。

翻译进度

Webinoly主要有五个指令手册，大部分指令基本放在一个页面下，
截止本文撰写时，现在翻译的进度在Webinolys这一页。

当然，还有一篇Full Example Tutorial。
不过目前的打算是先把五章翻译完就传第一版。

至少先方便查阅基本指令。

因为我还得研究用哪个Wiki比较适合Obsidian的链接功能。
实在不行用WordPress也不是不可行。

基于mkdocs搭建的景の域开发手册现已上线！
可以通过 vsdn.v1sta.xyz 的Webinoly导航栏目访问翻译手册。

来源

起初以为是依赖问题，于是在本地搭建的虚拟机建立测试站点，问题依旧复现。

在终端机界面，使用webinoly的 log 指令，
可对特定网站查阅访问日志：

log h5ai.lan -error

若提示没有syslog日志，可以先执行系统更新： sudo apt update && sudo apt -y upgrade

通过查看日志可见，问题出在PHP的函数 putenv 没有开启。
同时putenv也是此前安装社交网站known所需的。
在新版的Webinoly中，一些函数因安全问题被默认禁用。

一般情况的解决办法很简单，修改 /etc/php/版本号/fpm/php.ini 文件，编辑 disable_functions 去除即可。大约在323行：

不过直接编辑php.ini对Webinoly在恢复配置备份的时候并不适用。

事实上， /opt/webinoly/webinoly.conf 配置文件也有关于php禁用函数的配置：

注释436行，去掉putenv的字样，然后重设php（这个reset的含义类似于BIOS，并不是恢复出厂）

webinoly -server-reset=php

搞定。

来源

其实我很早之前就了解到Known了，大概是2022年左右，那会我还在联邦宇宙寻找推特替代品（原主时间线）。没想到拖到26年才在PVE装虚拟机研究起来。另外i3 7100会不会性能有点差？

因为是PHP的缘故，加上有Webinoly的标准化PHP+MySQL模板参照，所以安装难度还算是可以，把包传上去或者用GitHub+compose安装均可，再把生成的MySQL数据库信息填进去就安上了。棘手的部分主要在于Nginx重写规则以及修改php.ini去打开一个弃用的不安全选项。

毕竟Known是一个将近10多年前的老软件了，即使正式版也发布于2019年。安全起见，我只在内网尝试，在CVE也能看到XSS漏洞报道。因此真的在公网搭建发布还是要在心里窦量一下子。

Known原生支持IndieWeb的各项标准，虽然在Fediverse和Bluesky两大新锐派面前IndieWeb的老标准显得稍有过时，不过也离不开IndieWeb标准的启发。即便如此，Known因为兼容IndieWeb还是有三方客户端API接口的支持。

至少从老手机就安装的IndiePass经过四年时间沉寂终于派上用场，IndiePass也支持Mastodon、Pleroma还有Pixelfed，可以把IndiePass理解为一个早期Twitter风格的三方app，不过可能是兼容性问题导致Known的主站Feed显示不出来，只能发帖。IndiePass这种MD1.0设计的老软件现今也被称为古董了。

Known与外界（外部站点）的通讯方式似乎是Birdgy插件，这是一个非营利性的在线服务，通过Bridgy在社交网络上发布网站的链接帖子，Birdgy从这帖子查看回复、并复制内容转告到网站评论，总体而言相当于信使来回跑。并不是真正具有跨界功能的去中心化网络。

Known我曾想过一个中文译名为「知世」，谐音知识（Knowledge），也是源自于「魔卡少女樱」的人物；但就字面意思「知晓世界」而言，Known的功能其实完全称不上这个名号就是。

Known还有一个特别的功能是收藏夹发帖，把后台的一个JavaScript快捷方式拖进浏览器收藏夹，在上网的时候选中内容拖至这个快捷方式，就可以把内容共享到Known，这个功能在Nextcloud也有类似实现（不过我好久没用Nextcloud了）

打不中就没有意义！

对于社交网络也是如此，没有人来用的话也不好玩。不过Known看起来似乎没有联邦宇宙的跨站浏览信息流，而Known设计之初也是为了个人和小型组织发布内容的「独立轻博客平台」，远远不算联邦的定义。

Known倒是支持从WordPress或者Blogger等xml信息导入文章，但除了作为个人博客之外，我能想到的用途就是学校社团小组专门用来建立公告板网站了。毕竟看样子没有不登陆Known就直接回复的功能。

所以现在来看的话，Known这东西给我感觉更像是……Web2.0版的腾讯频道？Tumblr社区？

亦或许是人人网？也不对。

但现在对我来说最重要的问题是社交是否还存在意义。人人网的没落，实际上是因为那些人步入中年不再社交。

现在新一代的网民大部分只有机会接触到手机，并不了解早年Web2.0及之前的互联网结构，被app驯化而不是被电脑浏览器驯化。这使得我生来与同龄人存在文化隔阂，却又作为这种桥梁。

咳咳，可能说的有点偏题了。

所以也许只是为了满足我的孤岛欲罢了。恰好搭建Known是一个不错的研究案例。。

过会整理好发下安装教程。另外是时候切换到Obsidian了。

1月23日更新：

其实感觉Known更像是昔日的WordPress P2/O2，后者是一种实时资讯模式的WP团队网站解决方案，颇有SharePoint门户的样子。

对于现在的人来说，可以理解为一个大号的腾讯频道/Tumblr社区，而小团体相当于微缩版的企业环境。

嗯……我又有点想试试P2和SharePoint了……研究老技术真的合适吗？

来源

简单说一下要点就是：直接在wp-config.php编辑站点目录的define编码项目。

前置条件：

• 一个真正的域名，可创建SSL证书
  
• 可以映射端口转发的路由器、未被运营商封锁的端口，未被系统占用的端口
  

1.创建网站

在内网的Webinoly可以首先用site命令使用域名创建普通的WordPress网站，端口号80（开启SSL则为443），在局域网访问的情况下，域名的端口号其实应该能够直接连接，若是没有则修改客户机系统的hosts也能达到直连访问的目的。

此时也可以顺带申请一下SSL证书，不过由于公网端口封堵，因此只可选择dns txt验证方式：

sudo site domain.ltd -ssl=on -manual=dns

2.配置WordPress

随后根据正常步骤访问域名配置WordPress，之后要额外安装一个WordPress插件 —— Make Paths Relative ，
这个插件顾名思义，可以将WP网站转换为相对链接的结构。

如有需要，还可在设置页面添加域名信息：（包括「域名:端口」形式）

3.编辑Nginx端口配置

编辑Webinoly服务主机上的域名主机配置 sites-available/domian.ltd.conf ，在需要访问的Server部分添加需要监听的端口，或是复制一份现有80或443的Server配置，将端口号改为自定义的端口：

# WebinolyNginxServerStart

Server {
listen 443 ssl;
listen [::]:443 ssl;
listen [::]:443 quic;
listen 443 quic;
listen [::]:2000 ssl;
listen 2000 ssl;
listen [::]:2000 quic;
listen 2000 quic;
server_name domain.ltd;

……

4.编辑WordPress的wp-config.php硬配置

寻找到自定义编辑行，添加如下代码。原理是硬配置网站链接为根部分（这可能会导致网页分享插件发生空白错乱）

/* Add any custom values between this line and the "stop editing" line. */
define('WP_SITEURL','/');
define('WP_HOME','/')

注意事项

可以通过浏览器的开发者工具查看页面资源（如CSS与JS）指向的服务器目录位置，
这样就可以看到资源究竟是从HTTP/HTTPS的标准端口加载，还是从自定义的端口号加载了。

若是无法打开网页的话，可以尝试用浏览器的隐私模式查看。手机LTE（或有WWAN连接的笔记本）也是个不错的公网测试环境。

直接在浏览器输入域名并不能直接跳转到端口号，这个功能需要DNS管理侧跳转实现，不是所有DNS服务商都提供这一功能，对于私人用途也没有必要。

Webinoly自带黑洞模板，理论上直接从IP+端口号无法访问，只有从域名+端口访问才能显示网页。
至于运营商侧是否因此探测或者禁止……并不可测。因地区而异吧，本文不会探讨法律风险。
不过安全起见仍然建议使用HTTPS协议。
另家宽不建议开启爬虫探测，必要时开启整站HTTPAUTH也并非不可。

最后，测试完毕后，切勿忘记将临时修改的自定义hosts，将其复原回来！开发愉快~

来源

我不太想在VPS上再运行一些带数据库的Web服务，除非用SQLite，所以选择了Dokuwiki，虽然最后发现并不太合适（可能还不如用Typecho+SQLite，奈何Typecho没有我比较喜好的主题）

安装

这次还是使用我喜爱的Webinoly运维脚本配置，和上次搭建Blessing Skin的过程类似，一行site命令，使用标准的php模板并配置SSL证书，一气呵成：

site [domain.ltd] -php -ssl=on

打开 Dokuwiki 的官网下载页面，可以选择自定义最小化的编译版本，仅保留需要的插件和语言：

然后点击下载，会自动转到下载页面，下载编译的压缩包，并提示如果没有自动下载则点击链接，复制这个链接即为wget下载链接。注意有下载时限，过一段时间后会过期，因此我也无法提供下载链接。

使用 tar -xvzf 解压后获得名为 dokuwiki 的目录，将其替换默认的 htdocs目录（也可以在nginx配置文件改成 dokuwiki ），并递归设置目录所有者为www-data以取得权限。

tar -xvzf dokuwiki-*.tgz
chown -R www-data:www-data ./htdocs
nginx -s reload

此时已经可以在浏览器中访问了，在域名后面输入 install.php 就能够访问安装器页面，出于安全原因，这个安装器只能在全新的Dokuwiki使用一次，配置以后还需要移走 install.php 以阻止访问。

URL重写

参考Dokuwiki上的Rewrite页。可以通过URL重写移除链接中的doku.php字样，需要在配置页 > 高级设置中设定userewrite项为 .htaccess(2)，以及打开canonical 完全标准的URL。

虽然userewrite表述为.htaccess，但并不是Apache HTTP Server特有的重写配置，同样也支持IIS、Nginx等多个其他的Web服务器。在此附上启用Nginx重写功能的片段，顺便设置敏感目录的阻止访问。

location / { try_files $uri $uri/ @dokuwiki; }
 
location @dokuwiki {
        rewrite ^/_media/(.*) /lib/exe/fetch.php?media=$1 last;
        rewrite ^/_detail/(.*) /lib/exe/detail.php?media=$1 last;
        rewrite ^/_export/([^/]+)/(.*) /doku.php?do=export_$1&id=$2 last;
        rewrite ^/(.*) /doku.php?id=$1&$args last;
    }
 
    location ~ \.php$ {
        if (!-f $request_filename) { return 404; }
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param REDIRECT_STATUS 200;
        fastcgi_pass 127.0.0.1:9000;
    }
    
location ~ /(data|conf|bin|inc|vendor)/ {
    deny all;
}

需注意的是，第一行的 location 配置与 Webinoly自带的 common/phpx.conf 相冲突，需要在站点Nginx主配置注释include后者以识别 @dokuwiki 。

这时URL重写便已经配置好了，如同WP的伪静态一样简单。

主题

Dokuwiki可以安装很多模板主题 (Template) ，它们以Wikipedia的风格居多，也有少数现代扁平化的设计。我比较喜欢 SprintDoc 模板，是德国人开发的，基于Material设计语言，简单而优雅，而且有著浓厚的德国工业文件的风格。

在扩展管理器中搜索 SprintDoc 就可以直接下载，然后去配置页启用template，当然也可以自己下载上传压缩包安装。

结尾

最后，我还是放弃了使用Dokuwiki，研究了一会发现，Dokuwiki的结构并不是很适合我。

尽管Dokuwiki是一种纯文件架构（Flat-file CMS）的程序，比较类似的是Grav CMS，但是并不代表从服务器下载文件就能直接所见即所得，除非直接离线存储整个网页。

Dokuwiki特有的synatx格式与富文本编辑器也不太好用，虽说有插件支持Markdown，但不是文件格式存储，依然没什么优势。

其次，Dokuwiki对于英语/拉丁语以外的语言体系的支持并不算好，虽然并不是完全不支持亚洲语系，但是URL只能设定为英文。分类的功能也不太好用，不像Mediawiki的几个站点。

最初的初衷只是为了想要记录一些服务端、客户端区分的MC模组，然而本来就有先人在mcmod百科上记载了，而且也被很多支持BMCLAPI的启动器所引用，我为何不直接写文笔记附上mcmod.cn的链接呢？

可能还是担忧突然一夜之间内容消失的重创。

虽然对一个小服务器没什么影响……我还是用OneNote吧。其实，支持metaweblog发布到WP功能的旧版Word更适合记录啊。

来源

不过后续可能会分享更多的文件、图片等，NGINX自带的索引列表过于简陋，索性尝试一下热门的h5ai吧。于是，我基于h5ai搭建了本站的资源存放箱（File Cabinet）共享文件。

并且考虑到SFTP的速度很慢，实在不想上传几个文件还要打开WinSCP之类的运维工具，顺便也搭建了一个WebDAV服务端，用于管理上传的文件。后续再更新

在此之前我使用的是SSHFS-Win，就是下图这个，它可以在资源管理器（Explorer）挂载目录，类似于RaiDrive之类的第三方软件，不过它是自由免费的开源软件。奈何SFTP的文件传输效率还是太低了些……

安装h5ai

h5ai是一个基于PHP开发的文件共享索引程序，由德国人Lars Jung，全称是 HTML5 Apache Index，本是取代Apache自带的静态文件索引功能，不过也可以支持其他的Web服务器。

h5ai · modern HTTP web server index for Apache httpd, lighttpd, nginx and Cherokee · larsjung.de

modern HTTP web server index for Apache httpd, lighttpd, nginx and Cherokee

larsjung.de

h5ai很好安装，打开上面的项目主页，可以看到一个大大的版本号下载按钮，右键复制按钮的链接，通过wget就可以下载到服务器上。目前最新的版本号是0.30.0，用cd命令转到文件共享的虚拟主机（vhost）网站目录内下载并解压。

cd /var/www/[domain.ltd]/htdocs
wget https://release.larsjung.de/h5ai/h5ai-0.30.0.zip
unzip h5ai-0.30.0.zip

解压后会出现一个名为 _h5ai的文件夹，这是h5ai的程序目录，不过默认是隐藏的，下文会提到如何隐藏前缀文件。

然后编辑虚拟主机的配置文件，添加_h5ai路径的index.php索引程序：

root /var/www/[domain.ltd]/htdocs;

index index.php index.html /_h5ai/public/index.php;

location ~ .*\.(zip|ini|jar)?$ { 
     allow all; 
} 
...

由于我使用的Webinoly有安全模板限制，默认不能通过直链访问一些压缩包和可执行文件后缀的静态资源，因此也添加了特定的文件后缀赦免。

此时在浏览器中输入文件站的域名，在后方加入 /_h5ai/public/index.php/ 访问h5ai的自检（探针）页面，默认无密码就可以进入，编辑option文件添加访问密码。

根据自检页面的指示设定文件和目录的权限、安装需要的扩展等等。

一切就绪以后，h5ai就可以正常运行了。

配置h5ai

如果想达到上图域主的效果，还需要设定h5ai的配置。

h5ai的主要配置文件位于 _h5ai/private/conf/options.json ，可以设定的配置非常多，在此仅列出我主要修改的几项：

"view": {
    "binaryPrefix": false,
    "disableSidebar": false,
    "fallbackMode": false,
    "fastBrowsing": true,
    "fonts": ["Ubuntu", "Roboto", "Helvetica", "Arial", "sans-serif"],
    "fontsMono": ["Ubuntu Mono", "Monaco", "Lucida Sans Typewriter", "monospace"],
    "hidden": ["^\\.", "^_h5ai", "icon.ico"],
    "hideFolders": false,
    "hideIf403": true,
    "hideParentFolder": false,
    "maxIconSize": 40,
    "modes": ["details", "grid", "icons"],
    "modeToggle": false,
    "setParentFolderLabels": true,
    "sizes": [20, 40, 60, 80, 100, 140, 180, 220, 260, 300],
    "theme": "comity",
    "unmanaged": ["index.html", "index.htm", "index.php"],
    "unmanagedInNewWindow": false
},

这里可以设置UI的显示模式、字体、隐藏文件、主题等等，比如hidden设置隐藏文件可以使用正则、也可以单独匹配文件名，这里我添加了 icon.ico 图标文件。

语言设置

"l10n": {
        "enabled": true,
        "lang": "zh-Hans",
        "useBrowserLang": true
 },

修改 lang 为简体中文 (zh-Hans) ，默认为英语 (en)。不过h5ai本身亦内置多种语言，useBrowserLang 可根据用户端浏览器自动切换显示的语言。

修改谷歌镜像

h5ai的界面默认使用Google Fonts，可以灵活更换字体，但在国内也可能会出现打不开的现象，好在可以替换成其他链接：

"resources": {
        "scripts": [],
        "styles": [
            "//fonts.googleapis.com/css?family=Ubuntu:300,400,700%7CUbuntu+Mono:400,700"
        ]
},

在 styles 中填写自定义字体的URL，使用Google Fonts的话可以把Ubuntu Mono换成其他的字体名称；

以及将 fonts.googleapis.com 替换为国内可用的字体镜像，比如 fonts.loli.net 的，这个是老生常谈了。

添加MD文件备注

还是在 options.json 中，找到 custom 开头，修改 enable 为 true ，可开启文件页眉/页脚备注，支持Markdown和HTML格式。

"custom": {
"enabled": true,
"stopSearchingAtRoot": true
},

随后可在文件目录中添加 _h5ai.header.md(.html) 和 _h5ai.footer.md(.html) 文件

修改根目录标题

h5ai默认根目录标题显示为当前的域名，可以在 _h5ai/public/js/scripts.js 文件中修改自定义名称

找到PHP域名函数 ("/"===t?f.getDomain():n.name)

替换为自定义字符串 ("/"===t?'资源存放箱':n.name)

修改网页标题

网页标题 (Title) 位于 _h5ai/private/php/pages/index.php 文件中，以 <title> <title/> 开头/结尾的HTML代码：

<title>index - powered by h5ai v0.30.0 (https://larsjung.de/h5ai/)<title/> 

此代码即为网页显示的标题，默认显示h5ai的版本、版权信息，可以将其替换成要显示的自定义文字。

需要在 options.json 关闭面包屑导航的动态标题功能。

域主顺便用Rclone搭建了额外的WebDAV文件传输和管理服务，天色已晚，待我吃完饭后，放到下篇再写……

嗯……如果在自己的服务器架设Jekyll、Hugo或Grav之类的Markdown博客引擎，也许可以用H5ai作为图床和视频站……

来源

考虑到和朋友们玩MC，肯定要搭建一套用户管理系统。

此前用过LittleSkin，久仰Blessing Skin大名，了解到了内建Yggdrasil API的三方实现，通过插件搭配HMCL启动器可以很好地实现私服登录+皮肤应用，便决定先搭建一个Blessing Skin了。

Blessing Skin是标准的PHP程序，数据库程序支持MariaDB/MySQL、PostgreSQL和SQLite3，一般的私人小服用SQLite数据库就可以了，可随网站的目录一同备份/迁移，相当方便。

这意味着它不需要特别高的权限要求，只要有PHP环境，几乎就可以安装运行了。

（*题外：WordPress也在核心层开始支持SQLite数据库实现了，能节省很多资源占用，感觉是个不错的趋势）

前置设置

这次还是用Webinoly安装，不过就没用FRP内网穿透了（其实并不占什么性能，装在哪里都能运行）

Blessing Skin需要开启以下PHP扩展

• OpenSSL >= 1.1.1 (TLS 1.3)
• PDO
• Mbstring
• Tokenizer
• GD
• XML
• Ctype
• JSON
• fileinfo
• zip

打开Webinoly的opt配置目录，使用编辑器修改 /opt/webinoly/templates/source/php.ini 文件，搜索extension关键词，逐一去掉注释（可以用WinSCP直接编辑）

extension=fileinfo
extension=gd
extension=mbstring
extension=exif
extension=openssl
extension=pdo_sqlite
extension=sqlite3

然后重新设置php并检查扩展（只是以templates的source配置覆盖）

sudo webinoly -server-reset=php
php -m

由于默认情况下PHP没有安装SQLite3的驱动，需要从apt安装，再通过php -m命令查询是否开启 pdo_sqlite3 模块。

sudo apt-get install php-sqlite3
php -m

如果安装以后没有查询到，可能需要在apt的php-sqlite添加版本号（如：php-8.1-sqlite3）

创建站点

使用site命令创建php站点并添加ssl证书

sudo site example.com -php
sudo site example.com -ssl-on -ssl-key=/path/cert.key -ssl-crt=/path/cert.crt -ssl-ocsp=/path/cert.pem

SSL配置可参考Webinoly的官方文档：

Site Management for NGINX Server with Webinoly

Create site HTML PHP MySQL WordPress Reverse Proxy with NGINX server FastCGI Cache Redis optimization SSL Certificates Lets Encrypt

webinoly.com

然后去GitHub查看最新版本，找到 blessing-skin-server-xxx.zip 名称的Release压缩包下载链接

Release 6.0.2 · bs-community/blessing-skin-server · GitHub

Web application brings your custom skins back in offline Minecraft servers. – Release 6.0.2 · bs-community/blessing-skin-server

github.com

使用任意一种方式（手动下载上传或者curl解压）将Blessing Skin运行文件放到 /var/www/example.com/htdocs/ 目录

顺便提前创建好需要使用的SQLite的数据库，位置随意，但下文会用到

touch ./sql.db3

打开网站的Nginx配置文件 /etc/nginx/sites-enabled/[example.com]，找到root行编辑运行目录：

root /var/www/example.com/htdocs/public;

然后打开域名 example.com/setup 打开安装向导，根据向导填写

选择SQLite，数据库地址填写localhost，在数据库名称填写刚刚创建的SQLite数据库文件路径。

然后填写管理员的信息，不出差错的话，应该就可以正常使用了~

插件配置

雄心勃勃打开插件市场，下载Yggdrasil API的插件……怎么打不开？？

插件市场无法打开 / Unable to load plugin market / Undefined array key “packages” · Issue #454 · bs-community/blessing-skin-server · GitHub

Blessing Skin 版本 6.0.2 PHP 版本 8.1 出现问题时所使用的浏览器 Chrome, Microsoft Edge 您正在使用的 Web Server Nginx 您正在使用宝塔吗？ 是 出现了什么问题？ 更新为6.0.2后插件市场无法正常打开 错误日志 Undefined array key “packages” 详细信息 [1] app/Http/Controllers/MarketController.php#L91 [2] app/Htt…

github.com

好吧，看来需要配置一下插件更新源……很可惜官方列表上的源我一个都用不了（虽然我的OpenSSL版本并没有问题）

再打开刚才的网站目录，编辑 .env 文件（嗯……这个文件是隐藏的点文件，它的文件名就叫 .env）

在末尾加入下列代码：

PLUGINS_REGISTRY=https://bs-plugin.mcskin.cn/plugins-dist/registry_{lang}.json

再去访问后台的话应该可以加载了，不过偶尔还是有抽风的现象，因地区网络环境而异吧

批量导入

*同名插件，取自自带说明

在 Blessing Skin 安装的网站根目录下执行此命令：

php artisan texture:import {uploader} {directory}

其中 uploader 参数为指定材质的上传者，值为上传者的 UID； directory 参数为材质文件所在目录。

此外，还可以指定 --cape 参数表示该目录下的 所有 材质文件为披风文件； 可指定 --gbk 参数来进行文件名编码转换，如果您的系统是 Windows 系统并遇到乱码问题，可以尝试这个选项。

来源

这次发一下搭建FRP穿透内网WP博客的记录……

关于FRP的简短介绍，详见之前搭建FRP的日记：搭建FRP服务端的一次吃瓜日记

初次实践

我的内网Web服务器是一个PVE中运行的虚拟机，使用Webinoly搭建基于Nginx的vhost虚拟主机；FRP的客户端frpc在OpenWRT的虚拟机安装运行；在公网的VPS搭建FRP服务端frps和Webinoly（只安装Nginx服务）

*实际上PVE在整个穿透过程中的存在感极低，去掉虚拟化不过就是同一局域网段下的两台机器，甚至完全可以把frpc和Nginx放在一起部署……

最开始我在内网的Webinoly部署了SSL证书，frps直接设置为443端口的https隧道转发到公网VPS，在内网Nginx网站conf的端口访问打开proxy_protocol协议透传IP访问

这样SSL由内网Nginx处理，FRP仅处理流量的转发工作。连接流程是这样的：

访客 → 公网frps https (443) → 内网frpc 转发 Nginx https (443 SSL)

这么做有两个弊端，不能走Cloudflare的CDN或其他服务器中转，只要加上CDN就无法访问了；此外公网VPS的IP访问也是暴露的（不能设置SSL reject handshake (444) 黑洞），不算非常安全。

后面我尝试了在公网VPS加上用Webinoly搭建的Nginx，将frp的https端口设置为8443，然后再对frp转发反向代理，实现443的端口复用（这样就可以设置黑洞了）

访客 → 公网Nginx https (443) 转发 frps https (8443) → 内网 frpc 转发 Nginx https (443 SSL)

然而这样就出现502或者无限重定向的问题了，原因是https证书的请求头（headers）改变了，相当于中间人介入，无论使用CF还是直连都不可行。而且网上很多Nginx复用frp的教程都是转发http的。

用TCP模式+upstream上游监听理论上能解决问题，然而由于我的内网Nginx服务端的IP访问配置了SSL黑洞，也就是上文提到基于域名判断的vhost模式，这个方案还是行不通。

正因为https的转发问题，让我熬夜研究了整整两天，差点猝死（）

更换思路

既然不能直接转发内网https协议处理，那就换成转发内网http的流量经由Nginx端口复用，让公网VPS上的Nginx处理SSL？这样还能用Webinoly的certbot管理证书更新。实际搭建好以后还可以打开CDN，完全可以用CF的15年证书。

此时流程变成了这样：

访客 → （CF CDN）公网Nginx https (443 SSL) 转发 frps http (8080) → 内网frpc 转发 Nginx http (80)

*frp隧道之间可通过tls加密安全传输流量

那么配置方式就变成了，在公网的VPS用Webinoly新建网站并配置SSL，而内网的Webinoly关闭SSL，保持http协议访问。即为https2http模式。

在公网Nginx的网站conf配置加入以下代码（Webinoly配置的Nginx是在#WebinolyCustomStart行下面）

location / {
      proxy_pass http://127.0.0.1:8080;
      proxy_ssl_server_name on;
      proxy_ssl_session_reuse off;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_redirect http:// $scheme://;
      proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
}

内网的Nginx网站配置，直接在80后面添加 proxy_protocol 就可以：

# WebinolyNginxServerStart
server {
	listen 80 proxy_protocol;
	listen [::]:80 proxy_protocol;

如果用的是Webinoly还需要注释默认的全局locations和headers配置链接：

#include common/locations.conf;
#include common/headers.conf;

但如果要穿透基于WordPress的博客、获得访客的真实IP，还是需要做一些微小的工作滴（否则连评论的IP记录都会变成192.168.*.*或者127.0.0.1的本地地址）

在wp-config添加一些代码，让WP在数据库层面启用https跳转资源和FRP穿透与CDN的标头转发记录：

/* Add any custom values between this line and the "stop editing" line. */

if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on';

if( !empty($_SERVER['HTTP_X_FORWARDED_FOR']) ) {
    $get_HTTP_X_FORWARDED_FOR = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
    $_SERVER['REMOTE_ADDR'] = trim($get_HTTP_X_FORWARDED_FOR[0]);
}

这时候再访问站点的主页，资源文件，如CSS样式都能够正常访问了。

实际搭建好以后感觉速度变慢了好多，毕竟家宽只有30M的上行（而且有时候我回家用RDP的话还会抢占带宽），境内外来回转去延迟也不如DDNS的说

嘛，好处是降低了租用服务器的成本，这三年的VPS反倒涨价了不少，也不送快照备份了……

来源

部署方式

这次为了节省成本，我将这个WP主机部署在家里的一台PVE虚拟机上面，然后通过FRP穿透到国外的VPS上访问。

为何不直接用DDNS？虽然家里的宽带没有封锁443的https端口，显然还是考虑到国内运营商的法规风险，而穿透到外边的VPS，服务性质就完全不一样了。WP博客不太追求很高的网络性能，FRP穿透之VPS，足矣。

搭建LNMP

搭建LNMP服务用的是 Webinoly ，这是一种开源的LNMP一键包，配置非常简单，终端输入以下脚本安装：

wget -qO weby qrok.es/wy && sudo bash weby

类似国内的一些LNMP一键包，不过相对于那些自编译的一键包，Webinoly使用的是PPA作源、对WordPress原生支持、可以设置http验证和源站黑洞，设置完以后可以卸载Webinoly本体的脚本、保留PPA的LNMP服务，在安全性也比许多面板服务优秀许多；

相对于同类的WordOps和容器化的EasyEngine，Webinoly自由度和易用性都更高一些。不过缺点也不是没有，一个是只支持Ubuntu，其次没有本地的帮助手册，如果倒了可能就消失不见。

具体的命令记录先咕了，后续有空再填Webinoly的一些坑……

记得最开始用的宝塔面板，用着用着，那是经常有舒克开着轰炸机扫我的服务器（冷知识：贝塔在郑渊洁小说的一个曾用名就是宝塔）

折腾主题：Back to the 2014

好吧，WordPress最重要的是记录为主，不过到手我对如今版本开箱即用的全区块主题化不算特别满意，逐换为上一个博客的主题：自用魔改的Mateo，一个Material Design 谷歌质感风格的主题，尽力模仿了Blogger

后面还是觉得这个主题不太好看，作为个人的日记本不错，但不太适合做类似社团的博客空间。WP的Twenty年号系列主题，在2019的区块化之前的几个主题都还算不错的样子。

先试了一下我最熟悉的2017，还是和上一个主题问题一样，后面尝试其他的20系主题，最后选定了Twenty Fourteen (2014) ：这个主题支持3.1引入的文章形式，对于多媒体和日志有更好的样式，简而言之完全可以当作一个没有时间线的微博/推特/Tumblr/QQ空间使用。

但是有一个严重的问题：2014默认是不居中的，导致在大屏上显示过于靠左了，其次默认的配色锁定在了早苗绿（）所以，就这样魔改又熬了三四天的时间，在此放上我自定义的CSS代码

//整页居中
.site {
margin: 0 auto;
}

/* 立体卡片阴影 */

@media screen and (min-width: 592px){
.site-content .has-post-thumbnail .entry-header {
    box-shadow: 0px -25px 36px -20px #0000005F!important;
}
}

/* 侧边菜单渐变 */

.secondary-navigation li:hover > a, .secondary-navigation li.focus > a, .secondary-navigation ul ul {
    background-color: #00e8e8;
    background: linear-gradient(90deg, #00e8e8 20%, #ffffff00 100%);
}

/* 分类标题 */

.archive-title, .page-title {
	font-size: 2rem;
	font-weight: 300;
}

/* 彩蛋 */

.site-info {
background: rgb(163,163,163);
background: linear-gradient(180deg, 
	rgba(0,0,0,1) 1%,
	rgba(200,200,200,1) 2%,
	rgba(126,126,126,1) 5%, rgba(64,64,64,1) 50%, rgba(25,25,25,1) 50%, rgba(0,0,0,1) 100%);
}

配色可以用一个插件解决：Fourteen Colors ，根据这个插件的描述，其实插件调用的是2014主题本来的颜色选择功能，但不知道什么原因最终被砍了，好在2014还有一些保留的主题代码，得以通过这个插件进行调整。

在Steam上也有打CSGO水友识得WordPress，我真的感到欣慰，虽然不如手搓，我说那不就是Hugo或者Gatsby嘛（也许一样是技术出身？（w）

下篇再更新AJAX刷新、音乐播放器的设置……

来源