最近在开发和测试对 TLSv1.3 的支持，过程颇为困扰，主要有两个问题：（1）测试服务器采用自签名证书，某些终端程序无法跳过对服务器证书的验证步骤，因此实际无法在实验环境进行测试；（2）开发过程中，我们希望了解协议交互的每个步骤的细节，而绝大部分工具默认并不提供足够详细的输出信息，增加了开发过程中的困难。
直到我们使用了 curl，这个工具实在太棒了！
如果需要输出详细信息，则使用“-v”参数。
如果需要跳过证书验证，则使用“-k”参数。
比如，我们测试 HTTPd（IP地址为 192.168.3.2），直接使用以下命令即可：
curl -v -k "https://192.168.3.2"
采用 postfix 发送邮件，默认没有采用 TLS 加密传输，对方的服务器有可能会提示告警（例如 gmail）。另外，邮件传输采用明文，如果不加密，也存在被人窥视的风险。因此建议修改 postfix 的配置，默认采用 TLS 加密。当然，这需要对方的服务器也支持加密，目前绝大多数邮件服务器都支持 TLS 传输。
修改 /etc/postfix/main.cf 文件，增加以下一行配置即可：
smtp_tls_security_level = may修改了配置文件，使用命令重启 postfix：
sudo systemctl restart postfix
最近工作需要安装了一台运行 Debian 11 系统的电脑，不知道是不是很久没安装 Debian 系统的原因，惊讶地发现 root 用户的路径少了很多，比如 /sbin, /usr/sbin 路径等。这些路径都是一些系统管理员级命令所在，不清楚什么原因没有加入 root 的默认路径。
不想影响其他用户，因此只要单纯修改 root 用户 HOME 目录下的”.bashrc”文件，在该文件尾加入以下语句即可：
export PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin家里有台 Raspberry Pi3， 日常做点小任务，比如做 samba 服务器当 NAS、做 web 的功能测试、学习点 Linux 知识等，基本都是一些负荷不大的任务。不过由于我是死忠的 GUI 党， 因此总是喜欢进入 Pi 那个巨丑无比的界面里进行操作，这也导致 Pi3 的内存会逐渐显得有些捉襟见肘，时间长了，就不得不使用 swap 。这可能会有损 microSD 卡的寿命，因此希望 Pi 能定时清理、释放内存。
网上搜了搜，也比较简单，而且效果比较明显。简要记录一下：
在 /etc/cron.daily 目录下，创建一个 gilson-clearcache 文件，内容如下：
#!/bin/sh
sync
echo 3 > /proc/sys/vm/drop_caches将这个文件设置为可执行文件即可：
sudo chmod +x ./gilson-clearcache
设置为可执行文件后，可以手工执行一下，可以看到 “free -m” 显示的结果里，“buff/cache available”等项有明显的改善。
不过考虑到 Pi3 可怜的 1GB 内存，这种内存回收方面的改善，估计不能从根本上解决问题，上 Pi4 （2GB或者4GB）或许更好。后续继续观察一下，如果实在不行，就换 Pi4 或者等 Pi5 吧。
最近有一台 HP ELite 笔记本退役了，其实配置还不错，500GB SSD 硬盘、16GB内存，看着挺轻薄，本来还打算用来替换自己平时使用的笔记本，后来发现有些不爽：（1）触控板有点飘 （2）有个键被我不小心按坏了，也许本来就坏了 （3）屏幕时不时出现横线、甚至出现闪烁，很不舒服。
食之无味、弃之可惜。忽然想到可以安装 Debian 做家庭服务器用，上述缺点就无关紧要了。安装了最新的 Debian 10， 然后修改成 Debian（sid），过程很顺利。非常棒！以至于我甚至打算直接 VNC， 或者用 VSCode 登录上去做一些开发工作。
因为是当服务器用，因此一直都是合盖，然后扔角落里默默工作。接着又发现一个问题：过一段时间后，WiFi 网络老是断开，无法远程登录，需要重新开盖然后登录。琢磨着大概是系统休眠了，检查 syslog 信息，发现以下信息：
NetworkManager: sleep: wake requested (sleeping: yes enabled: yes) NetworkManager: state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') NetworkManager: NetworkManager state is now ASLEEP
看来确实休眠了。搜索网络，查到一篇 Ubuntu 停止休眠的文章（请点击此处），考虑到 Ubuntu 和 Debian 本质没什么区别，操作也是有效的。
关闭休眠功能，请使用以下命令：
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
当然，如果后悔了，需要重新打开休眠功能，可以使用以下命令（未验证）：
sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target
SSHd 配置采取了一些安全措施，比如：修改端口、禁止 root 远程登录（这里）、启动 fail2ban 防止恶意登录（这里），等等。目前看这些措施基本满足了日常的维护管理需求。
通常还会采取证书登录方式，禁止密码鉴权登录。不过以往考虑到密码方式更方便，因此没有动力去修改。时间就这么过去了……
最近登录服务器检查日志， 惊讶地发现 fail2ban 每日的日志居然有十几M之多，全是各类奇葩以各种方式尝试登录 SSH。虽然 fail2ban 工作得很好，但是万一出现了 bug 呢？ 万一哪个变态就是锲而不舍、经年累月地尝试登录呢？应该下狠手，让老铁们彻底绝望，因此决定禁止密码方式登录，要求采用证书登录。
配置不复杂，涉及客户端生成证书密钥，以及将公钥上传到服务器等。主要参考 Linode 的两篇配置文档（这里和这里）。 以下是详细步骤：
客户端也是 Linux 系统，因此相当简单：
ssh-keygen -b 4096
该命令在当前用户的 .ssh 目录下创建了两个文件： id_rsa 以及 id_rsa.pub 。
其中 “id_rsa.pub” 是当前用户的公钥文件，将其上传到服务器上，然后添加进 ~/.ssh/authorized_keys 文件中：
cat id_rsa.pub >> ~/.ssh/authorized_keys
添加完成后，服务器上的 id_rsa.pub 文件不用再保留，删除即可。要注意，authorized_keys 文件应该设置为别人不允许访问，确保足够的安全性。例如设置文件权限为600：
chmod 600 authorized_keys
当 SSH 客户端登录时， SSHd 默认读取该用户的 authorized_keys 信息进行证书鉴权。
PasswordAuthentication no
然后重启 sshd 即可：
sudo systemctl restart sshd
之后，客户端如果采用密码鉴权方式登录，或者粗暴破解，将被无情拒绝。
如果有多个客户端需要登录服务器，则需要各自生成证书，并将公钥上传到服务器，并添加到 authorized_keys 文件中即可。
Linux的发行版本有如过江之鲫数不胜数，我已经厌倦了这些发行版。生命很短暂，时间很宝贵，没有必要把时间浪费在各种“碉堡了”的发行版上。作为一名软件开发人员，我觉得严肃对待Debian和Ubuntu已经足够了。
然而最近我尝试了一个新的发行版本：Neon。这是个相对比较新的发行版本，与众不同之处在于：Neon是KDE组织的官方发行版本！作为一名KDE粉丝，听闻居然有KDE官方发行版本，还是很让人激动的。另外一个吊诡之处在于：Neon是基于Ubuntu的版本！同时作为一名Debian/Ubuntu粉丝，当然就更加激动，实在是甚合我意啊！
以往说起KDE，往往想起openSUSE。openSUSE社区也往往自居正统KDE发行版本。KDE 社区居然会选择Ubuntu作为基础版本，这事挺有意思，感觉可能和Kubuntu有点关系。
简单试用了一段时间，非常棒！Neon实在是个短小精干的版本，启动后系统内存占用居然低于500M，该有的都有，不该有的基本都没有，运行很稳定，KDE 桌面效率也很高，完全可以洗刷对KDE的各种误解。
Neon，你值得拥有！
因为需要访问公司远程网络，而考虑到国内特殊的网络环境，通常在windows系统下都是使用putty创建本地socks5代理，在firefox中设置该代理访问internet。
但是在linux下，默认采用以下命令时，居然只能使用socks4代理：
ssh -D 6666 myname@mycompany.com
如果需要使用socks5代理，则需要明确指定本地的IP地址，命令如下：
ssh -D 127.0.0.1:6666 myname@mycompany.com
其实用netstat检查前一个命令的结果，能看到正确绑定了任意地址的6666端口，而后一个命令只是明确绑定在本地循环地址上。两者应该都能成功进行socks5代理才对。
不知道这是ssh的bug，还是firefox的bug？ 简单搜索了一下，似乎也没有人提到这点。
自从将T430安装上Ubuntu 16.04版本后，一直有个问题：2.4G WiFi网络连接没有问题，5G WiFi则可以连接，但是分配不到IP地址，也就无法真正访问网络。还以为是Ubuntu的驱动有问题，内心里又一次鄙视了Ubuntu。
偶然看到一点Linux的网络知识，可以检查当前的频点。随手查了一下，结果如下：
yxh@t430:~$ iwlist chan wlp3s0 32 channels in total; available frequencies : Channel 01 : 2.412 GHz Channel 02 : 2.417 GHz Channel 03 : 2.422 GHz Channel 04 : 2.427 GHz Channel 05 : 2.432 GHz Channel 06 : 2.437 GHz Channel 07 : 2.442 GHz Channel 08 : 2.447 GHz Channel 09 : 2.452 GHz Channel 10 : 2.457 GHz Channel 11 : 2.462 GHz Channel 12 : 2.467 GHz Channel 13 : 2.472 GHz Channel 36 : 5.18 GHz Channel 40 : 5.2 GHz Channel 44 : 5.22 GHz Channel 48 : 5.24 GHz Channel 52 : 5.26 GHz Channel 56 : 5.28 GHz Channel 60 : 5.3 GHz Channel 64 : 5.32 GHz Channel 100 : 5.5 GHz Channel 104 : 5.52 GHz Channel 108 : 5.54 GHz Channel 112 : 5.56 GHz Channel 116 : 5.58 GHz Channel 120 : 5.6 GHz Channel 124 : 5.62 GHz Channel 128 : 5.64 GHz Channel 132 : 5.66 GHz Channel 136 : 5.68 GHz Channel 140 : 5.7 GHz Current Frequency:2.422 GHz (Channel 3)
好吧，很显然Ubuntu这次背锅了。在5G的频点中，不包含中国区的频点（通常在148以后）。修改路由器的配置，将区域设置为“United state”并设置相应的频点，重启路由器，Ubuntu就可以连接5G WiFi并正常访问网络了。
这台T430是老婆公司退下来的，可以确认肯定是面向大陆地区销售的产品。内置的5G WiFi居然不支持中国的频点，Lenovo果然是美帝良心企业。
今天C家发布了17.04版本，在VirtualBox里安装并简单地测试了一下。和以前的版本一样，这个临时性版本没有太大的改变，没有特别的惊喜。考虑到前几天C家老板的申明，18.04版本后就放弃Unity和MIR了，当前这个版本就显得尤其鸡肋。个人觉得如果不是狂热的U粉，就不需要花时间去用这个版本。
下面这个截图仅作为纪念。
说到C家放弃Unity这事，我感觉非常可惜。Linux系统的各种DE都很烂，与windows和macOS差距巨大，Unity/MIR可能是仅存的希望。有C家做支持，看起来有可能实现追赶。很可惜，现在已经完全不可能。Unity在融合环境方面实在浪费太多资源和时间了。
顺带鄙视某些言必称“命令行”的Linux二货，他们永远不会明白：人类发明GUI界面是有原因的。
另一个让我无法理解的是，C家居然转向Gnome3？ 老板是怒极攻心，丧失理智了吗？ 好歹换成KDE也行啊。