Linux on 个人技术随想

有趣的rm -rf

Tue, 08 Jul 2025 14:00:00 +0800

root@enabling-clam:~/testdir# echo "foolish rm" > "-rf" && ls -la
total 8
-rw-r--r-- 1 root root 11 Jul  8 06:37 -rf
drwxr-xr-x 1 root root 32 Jul  8 06:37 .
drwx------ 1 root root 52 Jul  8 06:35 ..
drwxr-xr-x 1 root root 14 Jul  8 06:36 mydir1
-rw-r--r-- 1 root root  6 Jul  8 06:36 myfile1

root@enabling-clam:~/testdir# rm * && ls -la
total 4
-rw-r--r-- 1 root root 11 Jul  8 06:37 -rf
drwxr-xr-x 1 root root  6 Jul  8 06:37 .
drwx------ 1 root root 52 Jul  8 06:35 ..

一段有趣的Bash命令记录

root@enabling-clam:~# mkdir testdir && cd testdir && ls -la
total 0
drwxr-xr-x 1 root root  0 Jul  8 06:35 .
drwx------ 1 root root 52 Jul  8 06:35 ..

root@enabling-clam:~/testdir# mkdir mydir1 && echo "Test1" > myfile1 && echo "Test2" > mydir1/myfile2 && ls -la
total 4
drwxr-xr-x 1 root root 26 Jul  8 06:36 .
drwx------ 1 root root 52 Jul  8 06:35 ..
drwxr-xr-x 1 root root 14 Jul  8 06:36 mydir1
-rw-r--r-- 1 root root  6 Jul  8 06:36 myfile1

root@enabling-clam:~/testdir# echo "foolish rm" > "-rf" && ls -la
total 8
-rw-r--r-- 1 root root 11 Jul  8 06:37 -rf
drwxr-xr-x 1 root root 32 Jul  8 06:37 .
drwx------ 1 root root 52 Jul  8 06:35 ..
drwxr-xr-x 1 root root 14 Jul  8 06:36 mydir1
-rw-r--r-- 1 root root  6 Jul  8 06:36 myfile1

root@enabling-clam:~/testdir# rm * && ls -la
total 4
-rw-r--r-- 1 root root 11 Jul  8 06:37 -rf
drwxr-xr-x 1 root root  6 Jul  8 06:37 .
drwx------ 1 root root 52 Jul  8 06:35 ..

root@enabling-clam:~/testdir# rm -rf && ls -la
total 4
-rw-r--r-- 1 root root 11 Jul  8 06:37 -rf
drwxr-xr-x 1 root root  6 Jul  8 06:37 .
drwx------ 1 root root 52 Jul  8 06:35 ..

root@enabling-clam:~/testdir# rm "-rf" && ls -la
total 4
-rw-r--r-- 1 root root 11 Jul  8 06:37 -rf
drwxr-xr-x 1 root root  6 Jul  8 06:37 .
drwx------ 1 root root 52 Jul  8 06:35 ..

root@enabling-clam:~/testdir# rm "./-rf" && ls -la
total 0
drwxr-xr-x 1 root root  0 Jul  8 06:38 .
drwx------ 1 root root 52 Jul  8 06:35 ..
root@enabling-clam:~/testdir#

为什么？

这两个问题本质上都与 Bash 的 Shell展开有关。

文件名展开

先看 rm * 一句命令，为什么这一行命令看起来像被解析成了 rm -rf mydir1 myfile1？

原因很简单：文件名通配符 * 遵照 Bash 的文件名展开机制，在真正执行 rm 命令前就被处理完毕。

After word splitting, … Bash scans each word for the characters *, ?, and [ … then the word is regarded as a pattern, and replaced with a sorted list of filenames matching the pattern

也就是说，rm 命令接收到的，是经过 Bash 展开后的文件名列表，在上面的例子中就等价于：

`1`	`rm -rf mydir1 myfile1`

双引号处理

我们还注意到，rm "-rf" 一句命令并没能成功移除 -rf 文件。明明我们已经试着用引号告诉 rm 这是一个整体，为什么还会失败呢？

在 Bash 中，经过参数展开、文件名展开等处理的命令在传递给程序前，还会最终经过引号移除。

引号移除发生在所有展开操作的最后，所有未经引号或转移保护的斜杠、单双引号都会被移除。

这也就是说，对于上面的例子，双引号对 -rf 的保护仍然局限在 Shell 处理阶段，保护其中字符的字面值，阻止空格分词。

然而，稍后 rm 命令收到的仍然是 -rf 字符串，并在稍后将其解析为 -r 和 -f 两个 option，最后还是没能将其作为要删除的文件名称进行处理。

解决方案与启示

想要正确删除 -rf 文件，有以下两种方法：

# Same as Example
rm ./-rf

# Another Example
rm -- -rf

上面两个例子都不需要给 -rf 加引号。

对于第一种写法，其提供给 rm 的参数首字符为点号 . ，以避免被 rm 当作短横线参数 - 处理。
第二种写法中，-- 通常约定表示“选项到此结束”，位于 -- 后面的参数，即使以 - 开头，也应该被视为操作数而非选项。

Shell 层安全 != 命令语义安全

利用BTRFS快照实现快速Linux环境切换

Sun, 26 Jan 2025 16:00:00 +0800

对于喜欢折腾的人来说，经常会遇到环境玩崩的情况，在Linux下更是一件常事。而如果每次都要重装系统，其实又非常不方便，也没必要。

在BTRFS文件系统逐步稳定并可用的今天，如果我们将根文件系统迁移到了BTRFS，或许，我们可以借助BTRFS快照功能，实现Linux环境的无痛切换与还原？

思路

为了方便，我们假设一个非常无聊的例子：

希望在一个分区内，安装一个Debian系统
在Debian系统上，分别安装配置GNOME和KDE两个桌面环境
实现两个桌面环境的根文件系统互不干扰，可按需分别启动

需要说明的是，这套配置里，我们假设包括/usr, /etc等路径均没有分配独立的挂载点，否则那就太麻烦啦！/home是否独立挂载取决于环境隔离的程度。

仔细一想，想要实现上述功能的思路是非常简单的：

在BTRFS文件系统上安装一个基础操作系统
对基础操作系统进行快照
根据基础快照，创建两组新的读写快照（子卷），在两个子卷内分别安装GNOME和KDE环境，并按需切换

其实，以Debian为例，如果在安装系统时指定了根文件系统为BTRFS文件系统，Debian安装程序会贴心地为我们创建一个@rootfs子卷，而后每次启动电脑时，实际上都是将@rootfs子卷挂载成/节点。因此，以上步骤的前两步都已被自动完成。

似乎，我们只要解决第三步就行？但麻烦的也在这第三步。

GRUB的麻烦

回忆一下，Linux是如何确定自动挂载文件系统配置的？第一个想到的一定是/etc/fstab文件。

还是以Debian的为例，默认情况下，如果设置根文件系统为BTRFS，在/etc/fstab文件里面，我们可以找到类似于以下定义：

1
2

# / was on /dev/sda1 during installation
UUID=12345678-1234-1234-5678-123456789012 /               btrfs   defaults,subvol=@rootfs 0       0

显然，这一句的意思是，将硬盘上的@rootfs子卷，挂载到/路径上。

那么接下来，我们似乎只要创建一个@rootfs的快照子卷，然后修改上面的fstab文件，把subvol=后面替换成新子卷名称，就可以实现快速切换了？

一开始我也是这么认为的，直到我安装完KDE桌面重启后，对着仍然黑麻麻的屏幕两眼发黑，我才意识到不对劲。

让我们瞄一眼/boot/grub/grub.cfg文件：

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-12345678-1234-1234-5678-123456789012' {
        # ......
        insmod btrfs
        # ......
        echo    'Loading Linux 6.1.0-30-amd64 ...'
        linux   /@rootfs/boot/vmlinuz-6.1.0-30-amd64 root=UUID=12345678-1234-1234-5678-123456789012 ro rootflags=subvol=@rootfs  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /@rootfs/boot/initrd.img-6.1.0-30-amd64
}

好吧……事实上根文件系统的子卷名称，是写入到了GRUB配置文件里的。在GRUB引导时，会按照/boot/grub/grub.cfg的配置查找子卷，然后加载该子卷中的系统。

而要修改GRUB配置，似乎就有点麻烦了。如果手动修改配置，需要在每次安装完驱动或更新内核后再手动调整一遍配置，极其麻烦且容易疏漏。而如果希望自动修改，又暂时没有好主意。

重命名子卷

修改GRUB配置的路子走不通，系统默认引导@rootfs子卷的行为有点难修改。既然如此，为什么我们不通过替换@rootfs子卷的方式，狸猫换太子呢！

安装基本系统

首先正常安装Debian基本系统，在配置分区的时候，为/挂载点分配一个BTRFS文件系统。

进行基础配置

安装完系统后，重启进入基本系统，进行必要的配置，安装一些在不同环境下都用得上的包。也就是准备一个基本系统的过程啦！

拍摄基础快照

重启进LiveCD，挂载BTRFS分区整个卷：

1
2

mount /dev/sda1 /mnt
cd /mnt

我们给系统子卷@rootfs创建一个快照@sysbase（名字可以随意起），用于记录此刻基本系统的状态：

`1`	`btrfs subvolume snapshot @rootfs @sysbase`

如果希望基本系统内容不变，可以增加一个选项-r，以创建一个只读快照。

配置环境1

接着，重启电脑，按需要配置第一个环境，例如安装GNOME桌面等。

配置环境2

之后，如果我们想要从基本系统开始重新配置一个新环境，我们需要再次进入LiveCD，挂载BTRFS分区完整卷到/mnt下。

这回，我们需要把环境1，也就是现在的@rootfs先移到一边，也就是重命名一下。

`1`	`mv @rootfs @gnome-env`

现在，我们的硬盘上似乎只有两个子卷了：

1
2
3

/mnt/
├── @gnome-env
└── @sysbase

我们现在想让系统回到基本系统，也就是回到@sysbase的状态。怎么做呢？我们可以，给@sysbase再创建一个快照，让这个快照成为新的@rootfs：

`1`	`btrfs subvolume snapshot @sysbase @rootfs`

接着重启电脑，我们就回到了基本系统状态，此时我们对系统的修改，就变成了我们的环境2。

还要更多环境！

如果还需要更多环境，只需要像配置环境2时一样，将当前@rootfs重命名一下，再从基本系统，或者任何一个其他快照，创建一个新的@rootfs快照，重启电脑，就可以创建新环境了。

而如果我们希望在环境之间切换，也非常简单，同样地，将当前@rootfs重命名为其他名字，再将想要切换的快照重命名成@rootfs，或者创建一个新@rootfs快照都行。

如果我们玩坏了环境，也不用完全重装系统，只需要将不想要的环境子卷删除，btrfs subvolume delete @broken-env，再选择一个好的环境为@rootfs即可。非常灵活！

💾几分钟能了解BTRFS吗？💾

Thu, 28 Nov 2024 16:00:00 +0800

安装相关组件

`1`	`sudo apt install btrfs-progs`

创建普通文件系统

`1`	`sudo mkfs.btrfs -L MyDisk /dev/sdxy`

创建RAID文件系统

`1`	`sudo mkfs.btrfs -f -d raid1 -m raid1 /dev/sdc1 /dev/sdd2`

-f: 强制执行，即无视指定分区上现存的文件系统。
-d raid1: 指定数据块存储模式。具体请参考官方手册RAID功能介绍。
-m raid1: 指定Metadata块存储模式。具体请参考官方手册RAID功能介绍。

在后面指定跨盘卷使用到的块设备即可。

设置卷名

`1`	`sudo btrfs filesystem label /dev/sdc1 MyData`

子卷(Subvolume)

创建子卷：

1
2

# 假设主卷已经挂载到/mnt/mydata
sudo btrfs subvolume create /mnt/mydata/@mysubvol

命令行挂载子卷：

`1`	`sudo mount -o subvol=@mysubvol UUID=abcd1234-5678-90ab-cdef-1234567890ab /some/place/`

访问子卷内容：

# 可以挂载后访问：
sudo mount -o subvol=... UUID=... /some/place/
cd /some/place/

# 当然还可以直接从卷根挂载点访问
cd /mnt/mydata/@mysubvol

快速问答

Q: 子卷是啥？

A: 就理解成BTRFS文件系统下，一个可以独立挂载，独立快照，独立操作的子文件夹吧。（尽管内部实现显然不是这样）

Q: 为啥子卷名称前面有个@符号？

A: 似乎是约定俗成，换成其他符号也行，不用也行。参阅Re: btrfs subvolume naming scheme.

Q: fstab中如何使用子卷？

A: 看下文。

挂载(fstab)

BTRFS文件系统的挂载和其他文件系统别无二致。

在使用块设备挂载RAID卷时，只需要指定其中一个块设备，就可以完成挂载。

不过，在/etc/fstab中设置挂载点，尤其是跨盘卷时，建议使用UUID进行挂载。

查看UUID:

# Recommended
sudo btrfs filesystem show

# OR
sudo blkid

# OR
ls -lha /dev/disk/by-uuid/

注意我们需要的是整个BTRFS卷的UUID，在RAID中不是某个单一块设备的PARTUUID。

接着编辑/etc/fstab:

最简单的：

`1`	`UUID=abcd1234-5678-90ab-cdef-1234567890ab /mnt/mydata btrfs defaults 0 0`

RAID也是一样：

`1`	`UUID=abcd1234-5678-90ab-cdef-1234567890ab /mnt/mydata btrfs defaults 0 0`

挂载子卷（注意这里使用的UUID仍然是主卷的UUID，不要与PARTUUID混淆）：

`1`	`UUID=abcd1234-5678-90ab-cdef-1234567890ab /media/mysubvol/ btrfs defaults,subvol=@mysubvol 0 0`

我喜欢的外挂硬盘挂载选项，可以在硬盘缺失时自动跳过检查：

`1`	`UUID=abcd1234-5678-90ab-cdef-1234567890ab /media/mysubvol/ btrfs defaults,subvol=@mysubvol,nofail,x-systemd.automount,x-systemd.device-timeout=3 0 0`

查看磁盘空间占用

需要注意，系统的du命令输出中，BTRFS的空间统计信息并不总是准确的。

`1`	`sudo btrfs filesystem df /mnt/mydata`

全盘检错

BTRFS的一大特色就是自动化的错误检测。

在BTRFS的Checksum Tree里，保存着整个文件系统中包括Metadata块与数据块的Checksum，而在每次读取这些数据时，BTRFS会自动进行校验，进而发现硬盘数据存在的错误。

不过，有时我们还希望主动执行检查，校验硬盘上的数据是否发生了损坏。那么我们可以这么做：

`1`	`sudo btrfs scrub start /mnt/mydata`

上面一条命令将会启动一个后台检查任务，检查整个文件系统存在的错误。对于RAID系统，检查会在多块磁盘上并行进行。

如果发现了数据错误且配置了RAID等数据冗余，BTRFS将会自动尝试从好数据中恢复损坏的数据。如果只是想查错，不希望BTRFS自动纠错，可以用-r参数指定只读模式运行。

开始检查后，可以用以下命令读取检查进度与报告：

`1`	`sudo btrfs scrub status /mnt/mydata`

查询读写错误发生次数

`1`	`sudo btrfs device stats /mnt/mydata`

龙芯小试 —— 龙芯3A3000主机简单配置与Debian系统安装

Sat, 19 Mar 2022 10:53:24 +0800

前言

前几天在咸鱼上买到了一块龙芯的电脑主板，CPU型号是龙芯(Loongson) 3A3000，芯片组似乎是780E。回来装系统的时候遇到了不少麻烦，这里记录一下，如果能帮到后来者，那自然是最好不过。

系统选择

实际上，我仍然推荐有条件的用户，使用龙芯官方适配的操作系统Loongnix，因为这是龙芯优化过的系统。

只不过，因为mips64el架构上的Loongnix是基于Fedora发行版的，且版本古老。我个人习惯的环境是Debian，只有LoongArch上的Loongnix才是基于Debian制作的。况且，Loongnix默认带一个GUI，连服务器版都带，我不是很喜欢先装后卸，因此我还是希望安装一个相对干净的Debian系统上去。

龙芯3A3000基于mips架构，具体到Debian上，属于mips64el架构（MIPS 64-bit little-endian mode, MIPS 64位小端序），请记住这个代号，因为我们后面会反复用到。

关于Debian的系统代号选择，在本文编写时，最新的Debain系统是Debian 11 Bullseye，使用的系统内核是Linux 5.10. 但我们目前会使用上一个版本，也就是Debain 10 Buster，具体原因下面会说明。

下面我们讨论的方法，基于狗剩百科:Debian 系发行版安装指南，并做一些自己经验的额外补充。

条件限制和实现方式

安装方式的选择

在平时x86计算机上，安装Debian的方法，首选当然是直接从Debian CD源中下载安装镜像，将镜像刻录到U盘上，引导镜像中的安装程序完成安装。这样当然是最简单的。

然而，根据我的简单测试，似乎Debian CD源中的ISO镜像，并不能顺利地在我手头上这块主板中引导。

📝 失败的Debian安装程序引导测试

这一段是我尝试在龙芯上引导Debian安装镜像时的失败操作，或许是该镜像不具备在龙芯电脑上引导的能力，也有可能是我本身操作方法不正确。因此我将这一过程记录在此，如有谬误，还请批评指正。如果您希望参考本文进行Debian系统的安装，请略过这一段。

下载Debian CD中的安装镜像debian-11.2.0-mips64el-netinst.iso

使用dd命令，将其刻录到U盘上: dd if=debian-11.2.0-mips64el-netinst.iso of=/dev/sdb bs=8M，（其中/dev/sdb是我的U盘设备）

将U盘插入龙芯电脑，启动，提示找不到LiveCD中的一个文件。

根据上述表现，个人猜测电脑已经成功读取并加载了U盘上的引导程序，但不知为何无法加载U盘上的后续文件，无法进入安装程序。

此外，目前我个人还暂时无法确定这块龙芯主板究竟是BIOS/CSM引导模式还是EFI引导模式。BIOS设定中无对应选项可调整。

在龙芯提供的Loongnix镜像中，存在一个EFI文件夹，且引导该Loongnix镜像时，在GRUB Shell中执行echo $grub_platform，回显结果为efi。且在Loongnix LiveCD系统中，grub-install命令提示安装的平台为MIPS下的EFI平台。

但进入该LiveCD系统后，使用Loongnix的安装程序尝试安装系统时，如果磁盘为GPT分区表，会提示当前计算机运行在BIOS/CSM模式下，需要创建额外分区才能继续安装。采用MS-DOS分区表则无此问题，安装时不需要创建ESP分区也可完成安装并正常引导本地磁盘系统。这也是我电脑目前的状态。

因此，我已经无法区分这台龙芯电脑运行在何种模式下，需要进一步考察。如果您有什么看法或观点，欢迎通过邮件同我交流，我的电子邮件地址在站内可找到。

有些难办的是，mips64el的Debian源，没有GRUB2软件包提供！ 这就意味着，我们需要借助其他方法，安装GRUB引导器 —— 如果没有GRUB引导器，我们是无法引导我们的系统的！

因此，我们需要另辟蹊径，分两步安装Debian系统：

安装龙芯的Loongnix系统到本地硬盘上。我选用的镜像是loongnix-20180930.iso。这一步骤主要目的是借助官方的安装程序，完成分区并将GRUB与Linux内核安装到本地硬盘。
重新进入LiveCD系统，删除本地硬盘中原有的根目录结构 （但需要保留/boot目录下的所有内容！因此建议在第一步安装Loongnix系统时，将/boot作为一个独立的分区，空间大约1GB）
使用debootstrap工具，创建Debian根文件系统，并在此基础上，进行修改。更多相关的信息可以阅读通过 Unix/Linux 系统来安装 Debian GNU/Linux。

总体而言，我们相当于借用了Loongnix系统提供的内核引导Debian系统。大部分情况下，这种方法没有问题，但也有一些情况下，系统中的部分程序要求Linux内核版本号高于一个指定版本。此时需要自行斟酌是否升级，升级到何版本。本文后面会讨论这一问题。

Debian大版本号的选择

不同Debian大版本号下，对应的Linux内核版本号也不同。原则上讲，我们使用的内核版本号应该接近Debian官方指定的内核版本号。在Debian软件源中，龙芯3代CPU使用的内核包名为linux-image-loongson-3。

Debian版本号	Debian代号	软件源中使用的内核版本号
9	stretch	4.9
10	buster	4.19
11	bullseye	5.10

此外，北京龙芯也有提供一些预编译的Debian格式内核包：https://mirrors.tuna.tsinghua.edu.cn/bjlx/pool/main/l/，我目前使用的是其提供的linux-4.19.0-loongson-3下的包。暂时不清楚北京龙芯提供的内核包相对于Debian提供的包是否有特别的优化，或其他区别。

选用Linux 4.19内核的前提下，Debian 10就成为了适配的最佳选择。

过段时间我会尝试下是否能直接用Debian 11 + Linux 5.10，届时会更新后续。

📝 备注

后续1: 2022年4月11日下午

根据我的简单测试，Debian维护者打包的Linux 5.10内核，虽然可以正常工作，但似乎和我手上这块780E主板有点不相兼容。

具体表现为，开机后风扇非常嘈杂，怀疑是有一部分功能没能成功移交给操作系统。过段时间再试试看吧。

安装流程

准备

🚨 注意

备份文件警告！

请务必在执行后续操作前，备份目标计算机上的所有重要文件！本人不会对您任何操作/误操作造成的损失负责！

一个空白U盘，用于刻录LiveCD镜像
Loongnix LiveCD镜像，我选用的版本为loongnix-20180930.iso（实际上这个版本有些不好用，因为其基于Fedora 21构建，软件包版本非常老，如果有新版本的Loongnix LiveCD在你的电脑上可用，完全可以替换）。
有效的网络连接（这要求第二步中的镜像可以正常驱动网卡）

同时，下面的操作几乎都是在root权限中完成的。

刻录LiveCD镜像并引导

我想这一步会是大伙比较熟悉的了。

`1`	`dd if=loongnix-20180930.iso of=/dev/sdX bs=8M`

of=/dev/sdX部分，请替换成你的U盘实际设备块，如/dev/sdb。不清楚的可以使用fdisk -l查看。

写入完成后，将U盘插到龙芯电脑上，开机并从U盘引导。

安装debootstrap

进入LiveCD环境后，首先配置好网络。接着安装debootstrap。可以使用命令dnf install debootstrap从Fedora源中下载安装。如果源中的工具太老不方便，也可以直接从Debian软件源中下载debootstrap的.deb包，使用tar与ar将其解压即可使用该程序（在Loongnix/Fedora上也可以！）

挂载目标分区

接下来，随便在根目录下创建一个新路径，例如/deb，用于挂载我们的本地磁盘分区。

接着，将本地磁盘上，已经安装有Loongnix的根目录分区，挂载到挂载点上。但此时先不需要挂载/boot分区。如果真的需要挂载boot，请在删除时选择忽略/boot下的所有文件！

挂载之后，删除该分区下的所有文件

下面的例子，我们假设本地磁盘上，/dev/sda1是/boot分区，/dev/sda2是/分区，/dev/sda3是swap分区。

1
2
3

mkdir /deb
mount /dev/sda2 /deb
rm -rf /deb/*

执行安装程序

接下来，我们要用debootstrap创建一个Debian根文件系统。

1
2

debootstrap --arch mips64el buster \
     /deb http://ftp.cn.debian.org/debian

最后的地址可以替换成你所在位置速度最快的Debian镜像地址。

如果debootstrap提示找不到一个名称中包含buster的配置文件，可能是当前使用的debootstrap工具版本太老（常见于使用Fedora源安装）。一种解决方法是下载新版的debootstrap工具，另一种是直接使用Debian的相对代号，如在本文编写时，Debian 10 Buster是上一个稳定版，则可以使用oldstable替代buster。同理，如果使用旧版的debootstrap安装Debian 11 Bullseye报错，也可以使用stable替代bullseye。

坐下来，等一等，喝杯咖啡，根文件系统就创建好了。

基础系统配置

为了让系统能跑起来，单有个根文件系统是完全不够的。

复制内核模块

虽然这么做不知道是否合适，可以考虑试试。

将Loongnix的内核模块，复制到目标Debian系统中。

`1`	`cp -r /lib/modules /deb/lib/`

fstab文件

/etc/fstab文件指定了系统启动时挂载文件目录的规则，需要仔细配置。

编写该文件，可以自己亲历亲为，仔细编写即可。但懒人有懒人的方法，不喜欢自己写这种配置文件，怕出错的话，也完全可以用ArchLinux团队提供的genfstab脚本，自动生成配置文件。方法也非常简单，可以去人家Github主页GitHub - archlinux/arch-install-scripts: Useful scripts for installing Arch Linux 直接下载源码包，make一下就好。或者，现在包括Debian在内的发行版仓库也包含了这个脚本的可执行文件，下载解压运行一气呵成。

使用genfstab，需要在LiveCD操作系统中运行，且需要在运行前将/boot分区挂载到Debian系统的/boot上，物归原主。如果有swap分区的话，也需要确认已经启用。

`1`	`mount /dev/sda1 /deb/boot`

确认无误后，就可以使用下面的命令生成fstab文件了。

`1`	`genfstab -U /deb > /deb/etc/fstab`

-U参数是指定使用UUID作为分区识别的标准。/deb是Debian根文件系统的挂载点，最后的重定向是将输出写入到目标系统的/etc/fstab中。

建议生成后自行检查一下文件是否符合预期。

chroot环境

还需要chroot进入Debian系统，对其进行一些配置。

`1`	`LANG=C.UTF-8 chroot /deb /bin/bash`

设置root口令

`1`	`passwd root`

安装常用软件包

或许下列软件包会提供一些提示，具体是否需要可以看您的需求。

locales: 使用英语以外的语言必须的软件包
vim/emacs/nano: 文本编辑器
openssh-server: SSH服务器，使用SSH登录系统的必须
build-essential: Debian下用于构建软件包的套件，包含了gcc/g++/make等工具
network-manager: Network Manager工具，可以自动配置网络

安装这些软件包只要用apt工具即可。如：

`1`	`apt install locales vim build-essential`

网络配置

网络配置是一件烦人的事情，人生或许应该用在更有意义的事情上。因此我个人喜欢用Netowork Manager自动接管网络配置。

`1`	`apt install network-manager`

还有什么比开机就能看到有线网络已连接，无线网络只需要一行命令就可连接，更令人开心的事情吗？

当然，如果你喜欢其他方法，如直接编辑/etc/network/interfaces，那也可以参考对应的教程。

此外，我们还需要配置hostname，也就是本机的主机名。

`1`	`echo myloong > /etc/hostname`

完成

我想上述配置已经可以让Debain系统跑起来了。退出chroot环境，重启电脑，记得拔掉U盘，没有意外的话，就可以进入Debian系统了。

如果电脑引导卡在Loongnix字样的引导动画，不妨尝试按下 Ctrl + Alt + F2 （F2~F8都可以试试），看能否见到熟悉的登录界面。

更换内核

如果你阅读到这里，看起来你已经进入了Debian系统，那么先恭喜你，你的Debian系统已经可以使用了！

但问题随之而来，如果你使用的Loongnix镜像和我相同，那你一定会发现，Loongnix使用的内核版本较老，可能是3.10附近的版本。而即便使用Fedora 28，其内核版本号也约为4.4~4.9左右的版本，和Debian官方的内核版本号是不匹配的。对于强迫症来说，这样的情况不太爽，我们得想想办法替换内核！

备份

然而，这样的操作注定是危险的，经常失败的，我想在进行下述操作前，需要先将系统备份一次。毕竟从debootstrap安装系统的流程终究繁琐，值得创建一个小小的备份帮助我们快速恢复。

具体备份的方法就不展开了。数据备份的责任在各位操作者本身！

安装新内核

安装新版本内核的方法有许多，Debian官方软件源中的会是一个选择。不过既然我没用过，那我也不具体展开介绍了。反正安装方法极为简单，apt install linux-image-loongson-3 linux-headers-loongson-3 linux-libc-dev就可以了。

我们接下来介绍怎么安装北京龙芯提供的4.19.0内核包。

下载地址位于https://mirrors.tuna.tsinghua.edu.cn/bjlx/pool/main/l/linux-4.19.0-loongson-3/，需要下载该地址下的三个文件：

可以考虑将三个文件下载到同一个文件夹中。随后进入该文件夹，执行

`1`	`dpkg -i *.deb`

即可安装三个软件包。

更新initramfs

首先安装initramfs-tools软件包

`1`	`apt install initramfs-tools`

执行下述命令，更新initramfs

`1`	`update-initramfs -k 4.19.0-loongson-3 -u -v`

这会在/boot下生成一个initrd.img-4.19.0-loongson-3文件。我们接下来配置GRUB引导项会使用到这一文件。

修改GRUB配置文件

最后一步，修改GRUB配置文件。

📝 失败的GRUB配置生成

这一部分我也不确定最佳做法是什么，因此还请熟悉GRUB的同学批评指正！

众所周知，在x86平台下，每次更新内核后，只需要使用grub-mkconfig命令，即可自动生成正确的GRUB配置文件。

尽管Debian MIPS64EL软件源不提供GRUB2软件包，但提供了grub-common软件包，其包含了grub-mkconfig命令。因此我尝试使用该程序为新内核创建引导菜单。就生成的结果看，其生成确实正常。

但在重启引导时，GRUB提示insmod命令无法找到。

这是很奇怪的事情，因为无论是原Loongnix生成的grub.cfg还是Debian生成的grub.cfg，都使用了insmod命令。

目前我尚未弄清楚造成该问题的原因，正在比较两配置文件的差异，还请大家批评指正。

这里，我们使用的方法是，直接修改原有的/boot/grub.cfg文件，将原先引导的3.x内核文件，改为新安装的4.19内核文件。

menuentry 'Loongnix GNU/Linux' --class loongnix --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinu$        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msd$
        else
          search --no-floppy --fs-uuid --set=root b6a3a91c-82b0-4ac6-ba62-19a9d4cf63c7
        fi
-        echo    'Loading Linux 3.10.84-20.fc21.loongson.3.mips64el ...'
-        linux   /vmlinuz-3.10.84-20.fc21.loongson.3.mips64el root=/dev/sda2 ro rhgb quiet loglevel=0 LANG=zh_CN.UTF-8
-        initrd /initramfs-3.10.84-20.fc21.loongson.3.mips64el.img
+        echo    'Loading Linux 4.19.0-loongson-3 ...'
+        linux   /vmlinuz-4.19.0-loongson-3 root=/dev/sda2 ro rhgb quiet loglevel=0 LANG=en_US.UTF-8
+        initrd /initrd.img-4.19.0-loongson-3
        boot
}

编辑后，保存该文件，重启，至少在我的电脑上，这种方法成功替换了系统内核。

目前我还没探索到更优雅地生成GRUB配置文件的方法，如果您有好的想法或见解，欢迎给我发邮件，敬请批评指正。

可能的改进方法

这部分主要是我暂时的改进想法，如果您是参考本文安装Debian系统，或许可以跳过这一段落了。

很明显，两种GRUB配置文件中，有部分insmod命令没有正常执行。

一种解决方法是，每次安装内核，都通过自己手动修改/boot/grub.cfg文件，达到引导新内核的目的，缺点是不优雅，容易出错。

另一种解决方法是，我们都知道，GRUB配置文件的生成是基于/etc/grub.d/下的模板文件的，那么可以考虑将Loongnix系统中的模板文件复制到Debian中，即可生成格式接近的配置文件，或许也可以解决问题。

但目前头疼的问题还有，Debian不提供MIPS64EL架构的GRUB2包，导致必须依赖Loongnix/Fedora安装GRUB主引导记录。我在尝试自行编译GRUB，具体测试情况可能得等下一篇博文更新了。

尾声

目前经过几天的使用，龙芯3A3000整体还是超过了我的预期的。基本上，3A3000接近于英特尔J1900水准。据说使用LoongArch架构的3A5000性能上了几个台阶，或许今后有机会可以试试看。

我会更期待，我们有更多的实干家出现。

使用WSL创建精简的Hexo写作环境

Wed, 29 Dec 2021 16:44:23 +0800

这篇文章将介绍一种方法，使用Windows Subsystem for Linux (WSL), Alpine Linux发行版, Git等工具，配置一个方便易用的的Hexo博客编写系统。

如果结合已有的网站服务器，还可以使用Git快速进行站点部署与更新。

前言

如您所见，这个网站的渲染生成器是Hexo。众所周知，Hexo是跑在Node.js上的玩意，但npm环境配置是出了名的复杂，甚至在我看来还不是那么优雅，略显混乱，在Windows上更是如此。

过去在Node.js上开发项目，总是避免不了和系统里的npm斗智斗勇，几番折腾，最后竟然无法正常地生成Hexo博客。实际上，也并不是没有考虑过切换博客生成后端，但迁移的成本同样存在，而且选择也较为有限。

不可否认，目前有许多优秀的Node.js管理系统，例如volta之类，但这些工具在Windows下支持也不能算好。而采用Linux作为主桌面？在目前还不能算特别方便。

所以，是否有一种方法，既能有效地管理npm，从而为Hexo创建一个隔离的环境，又能保证整体性能不差，还与Windows轻松兼容呢？

笔者认为，在2021年年底的当下，微软提供的Linux子系统，也就是WSL，是解决这一问题的比较优雅方法。它能满足上面的所有设计要求。以下是具体方法。

预备条件

启用了 Windows Subsystem for Linux 功能的 Windows 10+ 操作系统
Alpine Linux的MINI ROOT FILESYSTEM(最小根文件系统)压缩包，可以在downloads | Alpine Linux找到
其他必须工具，如git等

📝 备注

关于Alpine Linux
Alpine Linux是一个非常精简的Linux发行版，本文编写时，其最新版minirootfs的tar.gz包，仅2.6MB大小，可以在为我们提供尽可能的环境隔离同时，大幅度节省隔离环境所需的额外空间开销。

📝 备注

MINI ROOT FILESYSTEM的作用是?
用于我们手动导入Alpine Linux到WSL中，作为我们的Hexo环境。不过，目前微软商店里已经上架了Alpine WSL应用程序包，和手动导入效果类似，可供选择。如果选择从应用商店安装，请跳过下面导入Alpine Linux一节。

📝 备注

为什么使用Alpine Linux发行版?
Alpine Linux发行版体积比目前绝大多数其他通用的发行版（无论是Debian系还是CentOS系）都要小得多。先前，Alpine由于musl的原因，兼容性不如其他glibc发行版。但后来docker普及之后，许多软件都提供了运行于Alpine Linux的二进制文件。包括Visual Studio Code远程插件，也提供了Alpine Linux的支持。因此，就本文描述的任务而言，选用Alpine Linux是完全没有问题的。

当然，如果更喜欢使用其他发行版，也是完全没有问题的，操作流程和下文整体上还是相同的。注意一下部分命令的替换就好。

导入Alpine Linux

解开GZip包

这一步，我们要导入Alpine Linux系统作为一个WSL的发行版(Distro)。

首先下载Alpine Linux的.tar.gz包，然后用解压工具，解压出.tar包。记住/复制这个.tar包的路径。例如，D:\alpine-minirootfs-3.15.0-x86_64.tar。

⚠️ 警告

注意事项
只需要将压缩包的第一层.gz部分解开，得到里面的.tar包即可。不需要解开.tar包里面的文件系统。

建立目录并导入发行版

在你希望放置这个发行版相关系统文件的地方，创建一个文件夹，这里为了举例子，我们取D:\AlpineHexoBlog。这个路径不一定需要在C盘，可以在你想的合理的位置。名字也是随意的。

接着，我们输入下述命令。

`1`	`wsl --import AlpineHexo D:\AlpineHexoBlog D:\alpine-minirootfs-3.15.0-x86_64.tar --version 2`

这个命令的意思是，将我们解压得到的.tar包，作为一个Linux发行版，导入一个新的发行版，并将相关文件放置在D:\AlpineHexoBlog目录下，这个发行版的名称叫AlpineHexo(这个名字可以随意)，并指定使用WSL版本2（关于WSL1和2的差别，请自行参阅微软官方文档）。

这样，一个自定义的发行版就导入完成了。可以在普通命令行/Powershell里面输入wsl -d AlpineHexo(注意名称替换)进入该发行版的终端。如果电脑装有Windows Terminal，也可以在标签页启动列表中直接选择该发行版。

安装Hexo相关环境

切换到Alpine Linux终端，执行命令。

`1`	`apk add nodejs npm git`

等待安装完成。

安装Hexo

这部分的步骤和Hexo官方文档部分相同，因此直接放出命令如下：

`1`	`npm install -g hexo-cli`

创建博客资源主目录

参考Setup | Hexo。

`1`	`hexo init MyBlog`

上面命令中，MyBlog是可以自定义的文件夹名称，这个文件夹用于存储博客网站的源文件，如站点设置，博客文章原始文件等。在生成渲染网站时，hexo程序会根据这一目录里的配置生成静态网站，我们的大部分操作也都将在这个文件夹里完成。本文剩余部分中，这个目录将称为Hexo主文件夹。

如果输出如下所示，说明创建成功了。

1
2
3

INFO  Cloning hexo-starter https://github.com/hexojs/hexo-starter.git
INFO  Install dependencies
INFO  Start blogging with Hexo!

接着进入这个新文件夹，执行npm install。

1
2

cd MyBlog
npm install

这下，我们的站点就初始化完成了。我们可以任意对这个站点进行自定义，如主题自定义，撰写文章等。

(可选)使用Git管理站点内容历史记录

这就完了？不打算让博客内容管理更加自动化一些吗？比方说版本控制，自动部署等等。我们接下来就来介绍！

我们首先从使用Git管理站点内容历史记录开始说起。网站内容日新月异，因此有需要将我们的博客站点原始内容，如博客文章的原始Markdown文件，站点的配置文件，Node.js包依赖等，做一些历史备份。

还可以注意到，Hexo的站点文件，包括配置、文章等，实际上都可以被视为文本文件，因此Git就是负责管理版本历史的极佳选择。

以下方法不依赖于具体的Git云托管平台，因此不必纠结Github还是Gitee这种问题，原理都是一样的。

初始化Git仓库

进入Hexo主文件夹，并执行git init，这将在本地端创建一个初始Git仓库。

1
2

cd MyBlog
git init

接着，我们让git跟踪Hexo主文件夹内所有有用的文件，并进行第一次提交(commit)。其中-m参数后的是提交信息，内容任你填写。

1
2

git add .
git commit -m "Init commit."

推送到在线Git云托管平台

如果希望同步到在线的Git云托管平台，需要先自行在网页中创建一个空仓库，之后推送到该远程仓库中。这里以内网的一台Git服务器为例，创建的仓库地址为http://git.mysrv.in/dhao2001/MyBlog.git

1
2

git remote add origin http://git.mysrv.in/dhao2001/MyBlog.git
git push -u origin main

在另一个地方继续创作

下次，当重装了操作系统，或是更换了电脑，希望在另一个地方恢复相同的博客环境以及源文件，只需要这么做:

首先还是要搭好最基本的环境，也就是git, nodejs, npm。安装完成后克隆仓库到当前系统。

`1`	`git clone http://git.mysrv.in/dhao2001/MyBlog.git`

进入该文件夹，执行npm install，这将根据Hexo主文件夹里的package.json文件，安装所需的node.js包。

1
2

cd MyBlog
npm install

至此，在新环境中的博客编写环境已经准备就绪，就可以像在老地方一样创作和发布博客了。

(可选)使用Git进行页面部署

咦，怎么又是Git？上一节不是刚刚才讲过吗？

刚刚上一节的内容，主要是使用Git对博客的原始配置文件、原始代码、原始Markdown源文件进行管理。

而本节的内容是，使用Git工具，将本机上通过Hexo命令渲染生成的静态Html等站点资源文件，推送到远程服务器的指定Web目录内，供其他人通过Web服务器进行访问。

设置远程服务器

第一步，首先需要登录到博客网站主机，也就是部署在公网的Web服务器上。

接着，在服务器上安装git软件包。例如，如果使用的是Debian/Ubuntu系统，可以运行:

`1`	`sudo apt install git`

如果使用的是其他发行版，请参阅对应发行版的软件包安装手册。

设置Web服务器

📝 备注

关于Web服务器的选择

本教程以nginx作为Web服务器，若希望使用其他Web服务器如Apache，请自行调整以下步骤中Web服务器配置文件内容。

在/var/www下新建一个文件夹，用于存放博客网站的静态Html文件，这里以blog作为文件夹名称示例。

`1`	`mkdir -p /var/www/blog`

接下来修改nginx的站点配置文件(Debian/Ubuntu系统位于/etc/nginx/sites-enabled/下)，修改配置文件中的server块(当然，更建议新建一个server块，更方便区分和管理，详见其他教程)。

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/blog;

        index index.html;

        server_name _;

        location / {
                try_files $uri $uri/ =404;
        }
}

修改完配置文件后，重启nginx:

service nginx restart   # 使用系统服务管理重启nginx

# 如果上面的命令无效
nginx -s reload         # 使用nginx命令重新读取配置文件

以上配置足以满足Hexo这样的静态网站部署要求。此时，可以考虑在/var/www/blog/下新建一个测试用Html文件，测试能否正常访问网站。

设置git仓库用于传输博客网站资源

设置好Web服务器后，如何使用git，把本机生成好的Hexo站点静态文件，推送到远程Web服务器上的网站目录，也就是本例中的/var/www/blog去呢？

实际上，在服务器和本地机器之间传输文件有很多方法。为了方便，考虑Hexo提供的部署工具集合，我们可以继续使用Git工具完成这项任务。

使用Git传输网站资源主要分成两个过程：

第一步，先将本机生成的静态文件，通过Git传输到Web服务器上。
第二步，使用Git钩子，将传输到Web服务器上的网站资源，复制到/var/www/blog，供Web用户访问。

为了达到这一目标，需要按照以下方法，在本机和远程Web服务器上分别调整配置。

远程Web服务器的配置

首先，在远程Web服务器上，创建一个用户，用户名可以自拟。当然，考虑使用Git的习惯，甚至可以给这个用户起名为git，如本例接下来所示。

`1`	`adduser -s /bin/git-shell git`

⚠️ 警告

关于Git Shell

出于安全考虑，可以将git用户的默认shell指定为只有简单功能的git-shell，执行命令结束后就会退出。

注意，/bin/git-shell是Debian/Ubuntu系发行版的默认路径，新版本或其他发行版请务必确认git-shell的具体位置，并将/bin/git-shell替换成真实路径。

为了配置自动部署，建议使用密钥对进行认证。SSH密钥对可以在本机上使用ssh-keygen或putty等工具生成。

sudo -u git /bin/bash -i        # 以git用户身份进行下列操作
cd ~
mkdir .ssh
cd .ssh
vim authorized_keys             # 将公钥添加到authorized_keys中
chmod 600 authorized_keys

完成用户创建后，选择任意一处地方，创建一个git裸仓库，该仓库就是用于传输网站资源的git仓库。如果没有其他要求的话，git用户的家目录/home/git似乎就是一个不错的选择。

1
2

cd ~
git init -b main --bare myblog.git

为了在上传网站资源文件后，git可以自动帮我们将更新的资源文件，拷贝到/var/www/blog文件夹，我们需要在git仓库中创建一个post-receive钩子。

`1`	`vim myblog.git/hooks/post-receive`

添加如下内容：

1
2

#!/bin/sh
git --work-tree=/var/www/blog --git-dir=/home/git/myblog.git checkout -f

保存该文件，回到终端，赋予该文件可执行权限。

`1`	`chmod 744 myblog.git/hooks/post-receive`

也不要忘记将nginx网站根目录/var/www/blog所有权转移给用户git，否则将无法进行写入和更新操作！

`1`	`chown -R git:git /var/www/blog`

这样，远程Web服务器端的配置就完成了。

本机端的操作

这部分的配置也可以参考官方文档One-Command Deployment | Hexo。

回到本机上的WSL Hexo环境。首先切到Hexo主文件夹。

`1`	`cd MyBlog`

为了使用Git进行一键部署，我们需要安装Hexo的Git一键部署插件。

`1`	`npm install hexo-deployer-git --save`

在_config.yml最后deploy下添加一节。

deploy:
  - type: git
    repo: git@mysrv.in:myblog.git
    branch: main
    message:

记得把mysrv.in替换成你的远程Web服务器地址。如果有其他需求，如指定认证使用的私钥位置、端口等，可以参考我先前写的文章SSH配置主机别名及指定认证私钥路径，修改ssh_config文件实现。

完成以后，试试运行命令:

`1`	`hexo g -d`

然后再访问一下博客站点，是不是已经成功将Hexo内容部署上去了呢？

常见问题的解决

本机部署命令执行成功，但远程服务器上访问到的资源未更新

在调试网站并刷新时，建议使用Ctrl+F5快捷键强制刷新，这将强制浏览器重新请求网站文件，从而可以避免缓存对调试结果造成影响。

其次，检查网站目录/var/www/blog的内容是否已经更新，以及nginx配置文件正确性。

如果明明git推送成功，但却没更新到网站目录中，需要检查post-receive钩子内容是否正确，路径是否正确，权限是否正确。

在这里，post-receive钩子文件对以上用户（本例中为git）必须具备可执行权限。同时，nginx的站点文件夹（本例中为/var/www/blog）必须对git用户开放写入权限，对nginx用户www-data开放读取权限。

正确的权限是，权限8进制代码为744或755，所有者为git:git。可以通过下列命令指定。

如果不确定，可以以git用户身份尝试以下命令：

1
2
3

cd ~
chown git:git myblog.git/hooks/post-receive
chmod 744 myblog.git/hooks/post-receive

再以root身份执行以下命令：

1
2

sudo chown -R git:git /var/www/blog
sudo chmod -R 744 /var/www/blog

修改博客后更新资源时，发现生成的页面字母大小写异常

这是由于默认的Hexo Git插件对大小写不敏感导致的。需要修改<Hexo主目录>/.deploy_git/.git/下面的config文件，在[core]一节中添加一行ignorecase = false:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
+       ignorecase = false
[branch "master"]
        remote = git@mysrv.in:myblog.git
        merge = refs/heads/master

SSH配置主机别名及指定认证私钥路径

Sat, 04 Dec 2021 21:06:43 +0800

但有一个问题，有时候你可能拥有几个不同的SSH私钥（虽然没什么使用多个密钥对的必要性），或者私钥文件文件名不是默认的~/.ssh/id_rsa，应该怎么指定需要使用的私钥文件路径呢？

几种常见的情景如下所示，更多详细内容，和标准的定义，请参考ssh_config手册，或在终端中键入man ssh_config查看。

使用命令行登录SSH

第一种，就是我们最常见的登录SSH服务器的方式。当你在终端中输入如下命令。

`1`	`ssh myname@my.host.addr`

SSH客户端会连接到该服务器，并尝试使用默认路径（见上述手册，IdentityFile部分）下的私钥，进行认证。如果私钥不在默认路径下，也未显式指定私钥文件，而服务器要求必须使用私钥认证，则认证失败。

如果想显式指定私钥，可以使用-i参数，指定私钥文件。例如。

`1`	`ssh myname@myhost -i /path/to/mykey`

如果是连接SSH服务器啥的，这就够用了。但缺点很明显，每次登录，都必须显式指定私钥文件。而如果是git命令，则会因为没有-i参数支持，命令执行失败。怎么改进呢？我们看下面。

使用ssh_conifg文件

配置文件

实际上，关于一个SSH连接，一些行为是可以在配置文件中定义的。你可以针对不同的目标服务器，配置不同的连接行为。

对于Linux中的一个用户而言，SSH配置文件位于~/.ssh/config。对于整个系统而言，SSH配置文件位于/etc/ssh/ssh_config（注意区别/etc/ssh/sshd_config，sshd_config是SSH服务器进程的配置文件，不用于客户端。）

我们用一个~/.ssh/config的片段来说明。

Host myserver
    Hostname 192.168.1.123
    User root
    IdentityFile ~/mykey

上面这个配置文件非常好读懂。

最开始的Host，代表的是，你在ssh命令中，给定的host参数的值，常常就是你输入username@host中@后面那部分。如果匹配，则应用下面的规则。对于该Host的定义，在config文件中持续到下一个Host或者Match。

接下来是Hostname指定了你服务器的真实地址，可以是ip，当然也可以是域名。

User指定了登录的用户名。

IdentityFile指定了登录该Host使用的认证私钥文件路径。

使用

编写了配置文件，就可以使用了。现在，登录到你的服务器更加简单，只需要在终端中输入。

`1`	`ssh myserver`

就可以应用Host myserver块下的配置，自动使用指定的私钥文件进行认证。

Git

📝 备注

关于Git使用场景的提醒 虽然大抵是简单的触类旁通：上面用于Git的案例，不仅适用于Github，也适用于其他Git平台，甚至包括自己搭建的Git服务器，像本网站的生成部署脚本，就利用了这个方法达到一键部署的效果。

我们可以用上述方法，解决git命令没有-i参数的不便之处。以Github为例，我们只需要向~/.ssh/config添加如下一个段落。

1
2
3

Host github.com
    HostName github.com
    IdentityFile ~/mykey

这样，下次对远程仓库代码进行更改时候，就会使用你指定的SSH私钥了。