在决心踏入计算机的世界之后,我们总会勇敢踏步,朝着某个方向走去。也许那里是堵墙,也许墙上贴着前辈们的经验,只要有怀揣一颗热爱探索的心,总归能找到答案。
在发现属于自己的答案之前,没有一帆风顺的路。
章回体tl;dr展身手,从云上修到PE终得解决
微信收消息被问「在吗」,约定时间解决服务器问题 在现场先整理环境,细心排查终现端倪 说公网 IP 端口无法访问,实际是 Hexo 生成空页面 问意图是想搭建博客,随后推荐国外静态部署
npm 装包报权限问题,缓存文件夹需管理权限读写 更改缓存文件夹权限,全局包文件夹也有问题 WinGet 重装 Node.js,Win 11 未更新无此命令 下载目录无 Node 安装包,迅雷里找到得以安装 设置镜像源npm依旧慢,换pnpm遇中文路径乱码
家庭版无「用户和组管理」,难启用内置 Administrator 试直接新建管理员账户,改注册表键值继续下一步 改路径提示文件夹占用,准备进入 PE 修改 忽发觉 BitLocker 启用,上微软网站查恢复密钥 查微软账户无恢复密钥,关设备加密防硬盘锁死 进 BIOS 关安全启动,进PE改名顺扩容 C 盘 C/D 盘间隔 Ubuntu 系统,D 盘空间分不到 C 盘 进系统改环境变量,却发现大量路径零碎片段
国内服务器没有备案,本地整好换静态部署 GitHub 邮箱不公开,本地仓库无法 push 身份证件没在手边,不好注册 Netlify 账户 CF Pages部署静态博客,@ 解析尚需迁移 DNS 迁dns后成功部署,一杯奶茶聊表谢意 约定聚餐只得暂时离开,火速吃完回来再续鏖战 教授 Git 三步流程,总结经验然后离开
问题与推论之间模糊的界限
「在吗」起手
M 给我发了一条微信,询问我「在吗」。
我在,我在暑期留校,我在食堂为数不多开放的档口等还算能吃的饭。
M 讲「公网 IP + 端口号无法访问」。
我的脑海中冒出许多种想法:「会不会是家庭宽带想要从公网访问」「会不会是服务器防火墙没有放行端口」「会不会是自己写的服务没有侦听所有网卡」「会不会是低位端口在路途中被拦截了」……
我问了一连串问题。「哪里来的公网 IP?」「什么类型的服务?」「SSH 能否连接?」
- 「哪里来的公网 IP」:判断是否真的拿到了公网 IP。
- 「什么类型的服务」:判断是成品引擎还算自己写的后端代码。
- 「SSH 能否连接」:判断IP上的其他端口能否连接。
弄清问题
起到关键作用的是后来 M 发来一张宝塔面板的截图。
谢天谢地,我终于弄明白他讲的问题是「服务器上通过宝塔面板搭建的网站无法访问」了。
我问「访问报什么错」。
他讲「直接无法访问」。天哪。
几句聊天之后,饭已经好了。先吃饭吧。
在饭送进嘴边之前,我认真思考了一下,和 M 约定下午亲自找他看看,不然可能说不清、可能修不好、可能造成一些破坏性的影响。
清理环境
中午睡醒已经是两点多了,下午解决完手里部分要紧的事情已经是三点半了。我给 M 发了消息,前往几十步路之远的他所在的实验室。
M 把他的工位让给我,我坚持让他搬一张椅子坐下,而不是站在旁边。
电脑开了很多窗口。浏览器里有很多标签页。
我用 Windows 的虚拟桌面功能,把问题相关的窗口和标签页放在新桌面里。
错误推论
我先照着 M 的思路,检查了公网 IP、服务商提供的防火墙、宝塔面板内的防火墙,最后才打开了那个「无法访问」的服务器上的公网 IP 的 80 端口。
访问网址,我的面色有些许变化。
「你看,你说的这个公网 IP + 端口真的无法访问吗?」我问。
「是啊,就这样打不开。」他答。
纯白色的画面映照着我的脸,屏幕上没有任何报错信息。
「端口是通的,这个网页已经加载好了,」我这样讲,「是你给 Nginx 提供的首页是空的,而不是无法访问。」
表面问题与实际意图的距离
问题环境
我快速扫视服务器。同时简单问了一些信息。
Ubuntu 系统。实例名叫 Windows Server。
没有配置 SSH。宝塔面板的终端功能不能使用。通过服务商提供的网页终端执行命令。
国内服务器,没有备案。有域名。
宝塔面板的 Nginx 提示未安装。怪事。
真正需求
他想搭博客。
搭博客起步阶段不用买服务器,使用静态托管服务即可。
博客不像是抖音爆款视频,缺乏服务器续费支持或长期内容输出,很难让自己或他人获益。
所以选择静态部署服务吧,既能防止续费困难而使得热爱更新的博客蒙尘,也能简化流程,让尝鲜选手快速吃上自建博客的体验。
本地开发环境有些许 messy
博客本体
这个博客文件夹没有初始化为 Git 仓库,使用 hexo-deployer-git 将生成的静态页面部署到 GitHub 仓库。博客主题文件夹使用 git clone 命令克隆,这样做有几个问题:
- 博客源文件未部署到 GitHub,容易丢失。
- 更改内容后不仅需要提交 git,还需要执行 hexo deploy 命令。
- 未使用 git submodule 管理主题文件夹,不好使用在线部署功能。
npm 环境
在使用 npm 管理包的过程中,我留意到更新项目依赖的过程中报 EPERM 错误,经检查是普通用户没有写入 npm 缓存文件夹的权限。这种情况一般是有软件安装到分区根目录,导致全盘读写权限被修改。不过他的情况并非如此,而是照着网上的教程,使用管理员权限的命令行配置了全局包、缓存路径,不配还好,这一配,就是环境问题。
「对,因为 C 盘空间有点小。」他讲。
修改了全局包和缓存文件夹的权限后,安装包不报错了。不过明明他配置过 npmmirror 镜像源,但是下载依赖的速度特别慢。查不出原因,索性重装 Node.js 环境吧。
又报错了。{% emoji blobcat blobcatcaged %}
这台电脑虽然是 Windows 11,但是已经很久没更新了,不支持软件包安装程序提供的 winget 命令。从系统设置卸载吧。
环境蓄力中
折腾一番,准备重装 Node.js,听闻 Node.js 是最近才安装的,想必安装包还在本地,兜兜转转找一圈没找到。
「安装包在迅雷里。」他讲。
安装之后,由于
~/.npmrc
配置文件或是其他什么配置文件还在,下载慢的问题依旧,我也懒得换源了,直接用 pnpm 管理依赖吧。
可惜是用户文件夹名称是中文,pnpm 无法正常配置,路径变成了乱码。
从服务器修到电脑本体
中文用户文件夹名
「欸,这个刚装电脑不久就发现了,但是我一直不会改。」他继续讲。
「淘宝搜索“用户名中文改英文”,五到十块钱就能搞定。」我答,「既然遇到问题了,那就顺便改一下吧。」
当然,我也是当场上网查找的 修改教程 。
得,又报错了,家庭版没有管理选项。为了减少对环境的影响,也为了避免扩大环境维护的范围,我并未将家庭版系统升级到专业版。
内置的 Administrator 不好启用,我索性断网(为了新建离线账户)新建了另一个管理员账户。
切换账户依然占用
切换账户后,我在注册表里找到并修改了原用户的用户文件夹路径配置,对应修改文件夹名的时候发现文件夹被占用,在任务管理器里关闭了几个可疑进程后问题依旧。
没事,还能救。
只要从 U 盘启动 PE 系统,就可以直接修改用户文件夹名了。
穿过几个走廊,我从自己工位取出了 U 盘。它安装了 Ventoy,带有 PE、Windows 和 Linux 的安装镜像。它又要出山了。
盘符图标上的小锁
在重启到 PE 之前,需要做好完全准备——比如,解决掉分区图标上代表 BitLocker 的小锁,起码确保知道恢复密钥。
说起这个锁,来头可就大了:不少用户在不知情的情况下变动分区,触发了 BitLocker 安全机制,开机显示「输入恢复密钥以进行恢复」的提示。有的按照提示找到了恢复密钥,进入了系统;有的微软账户里并未同步 BitLocker 密钥,便永远地失去了电脑内的所有数据。
我喊 M 在手机上先行登录微软账户网站,检查恢复密钥。
M 的账户里没有 BitLocker 密钥。
还好先行查看了,不然如果一会触发了 BitLocker 的话要出大问题。
在“设备加密”设置里关闭了开关,看着解密进度条一点一点推进,我心力交瘁地瘫在 M 的工位上。
PE 启动
「来杯奶茶吧,想喝什么?」M 问。
「豆乳玉麒麟不错,怎样?」M 继续问。
我又陷入久远的沉思了。之前喝过一杯豆乳玉麒麟,也是帮人解决电脑问题的酬劳。
等设备加密完全关闭以后,我重启进入 BIOS 关闭了安全启动,又进入 U 盘启动 PE 系统,改好了文件夹名。
分区「栓」
「我看不少软件被手动移到 D 盘了,所以顺便给 C 盘扩个容吧,把 D 盘空间分给 C 盘,有助于减少使用者的空间焦虑。」边操作着,我的动作停滞了。
C 盘和 D 盘之间横亘着一个 S: 分区、Ubuntu 的 ESP 分区、Ext4 格式的根目录分区、家目录分区。
我心里默算了一下,C 盘和这几个分区的大小加起来,刚好是 200 GB。
经过询问和检查,S 盘并没有什么重要内容,迁移一部分文件到 D 盘后,便把 S 盘的十几 G 空间归还给 C 盘了。
PATH 被分解
重启后,观感正常,删除之前临时新建的管理员账户。
根据教程,检查环境变量里残余的旧用户名。
再次发现情况:PATH 里原中文用户名的部分是乱码,并且出现了多个意外的分号将原先的单个路径断成多个路径。情况新到我没有见过,也在网上搜不到类似现象。
稍微收拾一下吧,npm 不知道什么问题下载慢,但 pnpm 应该算能用了。
为了丝滑部署博客也是煞费苦心
部署博客的核心要点
把奶盖和黄豆粉倒入奶茶,轻轻摇匀,小口啜饮。
可以开始优雅的博客部署环节了。
删除通过
git clone
克隆的原主题文件夹,使用
git submodule add 主题.git themes/主题名
添加主题。这样便可以之间在 Git Push 时云 build,而不用
hexo deploy
。
同时,pnpm 下载包的体验十分顺畅,丝毫没有先前 npm 的凝滞感。
本地运行博客的观感正常。
Git submodule 的轻松实践
命令比较强劲,审慎使用,确保做好备份。
可以推送了。
阻止推送
奶茶中的冰已经失去了硬朗的外形。终端里留着 Git 推送被阻止的信息。好一个丝滑未半而中道遇阻啊。
经检查,M 在 GitHub 设置中启用了 阻止会暴露个人电子邮件地址的命令行推送 。
我关掉这个选项,试图让博客部署重新顺畅起来。
选择静态部署服务
我又喝了一口豆乳玉麒麟,豆乳玉麒麟的口感很丝滑,不愧是热门产品。
「有身份证、学生证或者驾驶证吗?GitHub 有没有绑定 QQ 邮箱之外的邮箱?」我问。
得到否定的答案,严格注册风控 Netlify 便不可选了。
我带他注册了 Cloudflare 账号,验证了邮箱。在 Pages 服务页面绑定了 GitHub 仓库,填写好了部署命令和输出目录。绑定了域名。
天哪,又卡住了。主域名(
@
)使用 Cloudflare Pages 服务时,需要使用 Cloudflare 的 DNS 服务器。
迁移 DNS
奶茶喝得太快,胃里感到了些许凉意。
打开腾讯云。扫码登录。查看域名。修改域名的 DNS 服务器。再次扫码验明身份。
在 Cloudflare 设置好解析记录,差不多算是完成了。
小炒菜
进度比预想中的慢了不少,之前和另外几个朋友约好一起拼的小炒菜到了。暂时和 M 分别一会,他还想听一听博客后续如何推送更新。
托着盒饭就着菜,我吃完了米饭。提上豆乳玉麒麟继续找 M 了。
Git 三部曲
简短地,我告诉他:
- 写博客文章,保存
-
如果修改配置需要参阅主题问题,修改后执行
hexo cl
清除缓存 -
通过
hexo s
在本地预览 - 通过「Git 三部曲」提交到 GitHub,触发云端博客更新
我演示了一遍,M 自己也做了一遍。会了。
我把仅剩几块冰的奶茶留在了他的垃圾袋里。
窗外的鸟儿向朝天空飞去,教学楼实验室工位上的大学生敲着键盘,也在计算机领域里迈步前进。
写在题外
写这篇文章的动机
可能有人认为我写这篇文章有些过于苛责博客新手,但写此文是经过深刻考虑的。
M 在 2023 年 6 月用 GitHub Pages 搭建了博客,当时博客里只有一篇 Hello World 和一篇正文只有几个字母的文章。除了在同年 11 月提交了空文件并设置了域名之外,没有任何的内容更新。
而 2024 年 7 月我帮助 M 修复“新博客无法访问”至今,他的博客里也没有任何文章。
我不愿让自己付出的努力落空为一个没有内容的博客网站 ,于是就写了这篇文章,希望能 把过程转化为可供参考的经验 ,帮助到真正愿意奉献到内容产出领域的人。
关于大学技术圈里刮起的博客之风
最近有不少同学先后搭建了属于自己的博客。 搭建博客是好事,分享内容是乐事,长期维护是难事。
博客之魂在于内容。表面形式之亮丽固然悦目,但内容之实才得以赏心。
关于系统环境配置
「少即是多」,配置环境前一定要审慎权衡。切莫引入非必要的配置,让问题更加复杂甚至扑朔迷离。
「把所有软件装在 D 盘」「配置文件的超级堆砌」「永久关闭系统、软件更新」都是不建议的做法。电子设备服务于人类,而我们不应再为「伪教程」规训教化。
就像对于「怎么充手机不伤电池」「空调多少度最省电」这些问题的态度一样,人应当顺从本心,不要为「如何配置」而配置。
以上。