Browsed by
Category: 学习

学海无涯

xrdp的小问题

xrdp的小问题

目标系统是 Debian, 采用 xrdp 远程登录窗体界面,总是在显示登录时黑屏。查了很久一直没有结论,后来就干脆用 vnc 算了。

今天在查其他问题时,无意间翻查到文件 “/usr/share/doc/xrdp/README.Debian”, 里面提示需要修改“/etc/X11/Xwrapper.config”文件,将

allowed_users=console

修改为

allowed_users=anybody

重启后,果然可以通过xrdp正常登录了! 只是比较奇怪,为什么 Debian 系统不将默认值修改为 anybody?是没人维护的原因吗? 那为啥又在 readme 文件中单独说明呢?

另外,由于 Raspberry Pi 也是基于 Debian 系统,因此 Pi 中做同样的修改,也可以通过 xrdp 正常登录。

xrdp 读取 “/etc/ssl/private/ssl-cert-snakeoil.key” 进行加密,但是这个文件默认只有 “ssl-cert” 组的成员才可以读取,因此还需要将 xrdp 用户加入该组:

sudo adduser xrdp ssl-cert
NAME、CNAME 格式

NAME、CNAME 格式

总体而言, 早期 DNS 协议是个比较简单的协议。受限于 UDP 大小和数据量, 基于 UDP 的 DNS 协议限制了包大小,并且采用二进制编码方式力求减少数据量占用。

二进制编码方式相比文本方式(例如HTTP、SIP、SMTP等)最明显的缺点就是不直观,再用一些技巧减少数据量,DNS 协议在定义、实现方面总显得有些弯弯绕绕。

比如 NAME、CNAME 等结构的编码。

本文记录了这些古怪的编码方式,方便以后查找,并帮助后续的开发者不会被代码给绕晕。作为我个人来说,还是尽快忘记这些吧。


方式一:纯压缩编码方式

这种方式应用很普遍,以“0xc0”标记开始,加上一个字节的 offset,进行消息包内的寻址即可。如下图所示:

DNS offset 编码
offset 方式编码

其中, 0x0c 就是偏移量。


方式二:直接编码方式

这种方式比较直接,占用数据量也相对大一些,将域名完整信息存在数据包中。如下图所示:

直接编码
直接编码方式

需要说明的是:并不是直接将所有字符存进去就 OK 了。对于域名数据,以“.”符号分割成几个单元,每个单元数据采用 “length + value” 方式进行编码,最后以0x00结束编码。以上述数据为例:

08 6e 73 69 6e 61 69 6d 67 04 67 73 6c 62 08 73
69 6e 61 65 64 67 65 03 63 6f 6d 00

比如,第一个 0x08,说明后面的“nsinaimg”(即 6e 73 69 6e 61 69 6d 67)长度;然后是 0x04,说明后面的“gslb”(即67 73 6c 62)长度……其他单元类推。


方式三: 混合编码方式

这种方式其实就是综合了上述两种方式。以直接编码方式开始,然后以压缩(偏移)编码方式结尾。如下图所示:

混合编码方式
混合编码方式

对图中的数据码流描述如下:

03 6b 6c 6e 04 67 72 69 64 c0 38

0x03 描述了“kln”(即 6b 6c 6e)的长度,0x04 描述了“grid”(即 67 72 69 64)的长度,而域名的后续部分,通过“c0 38”编码可以知道:需要偏移0x38字节获取。

SSH 配置证书登录

SSH 配置证书登录

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 信息进行证书鉴权。

修改 /etc/ssh/sshd_config 文件

PasswordAuthentication no

然后重启 sshd 即可:

sudo systemctl restart sshd

之后,客户端如果采用密码鉴权方式登录,或者粗暴破解,将被无情拒绝。

如果有多个客户端需要登录服务器,则需要各自生成证书,并将公钥上传到服务器,并添加到 authorized_keys 文件中即可。

Cloudflare 返回的DNS结果

Cloudflare 返回的DNS结果

最近查一个客户遇到的 SIP 呼叫问题,发现在检查 DNS 记录时有问题,没有正确获取 DNS 记录。切换了几个 DNS 服务器测试,只有 Cloudflare DNS 服务器(1.1.1.x 系列) 返回的DNS记录会触发问题。

这并不是说 Cloudflare 的DNS记录有错误,而是我们自己实现的 DNS 库没有考虑到该记录的不同寻常之处。Cloudflare 的返回结果确实有点与众不同。

下图是Google DNS 以及 Ali DNS 返回的DNS结果,请注意其中的 Name 字段的内容(0xC0 0x0C)

Google DNS 结果
Google / Ali DNS 返回结果

很明显,这种DNS结果采用了 compress 方式,通过 offset 来获取真正的Name。图中的 0x0C 实际就是偏移量,指向了包中的另一处地址。Compress 方式最直接的好处就是节省了包大小。

而 Cloudflare 的 DNS 结果如下图所示,直接将域名包含在 Name 中,以 0x03 标注开始,以 0x00 表示字符串结束。不再需要偏移指向其他地址。

Cloudflare 的 DNS 记录
Cloudflare DNS 返回的结果

这种方法的好处是够直接,不再需要跳转获取真实的域名信息。当然坏处是增加了数据包的大小。

我们测试了网络上大部分的 DNS 服务器,目前仅发现 Cloudflare 采取了这种方式,其他服务器都是采用 compress 方式。

站在“人”的体验角度,似乎 Cloudflare 更合理一些。但是要注意,compress 方式更符合计算机的处理,毕竟前面的 Queries 部分已经解析过 Name 了,没必要再解析一次。另一方面,直接 offset 寻址,也远远快于再一次通过判断0x00来解析Name 字符串。

因此我个人认为 Cloudflare 的处理方式,即拖慢了速度,又增加了数据包消耗。当然,以目前计算机的处理能力以及网络速度,这些都是浮云。我们的解决方式也是淡定地接受这个结果,并修改 DNS 库进行适配即可。

在本次查问题中,测试了网上公布的香港 DNS 服务器,全部拒绝了来自大陆 IP 地址的 DNS 请求,真有意思。

推荐一个lua的小插件

推荐一个lua的小插件

以前一直用Geany编辑器编写Lua程序。其实这个工具很垃圾,只是别的工具更垃圾。要求也不高,无非就是变量、函数等跳转、列表,工程范围内查找,基本的编辑功能即可,不要求调试功能。

平时写脚本一般都是采用visual studio code,很棒的工具,就简单编辑功能而言,vsc 做得相当好。因此也试图尝试 vsc 的插件,看看能否满足上述编写Lua脚本的要求。

看到 vsc 推荐作者sumneko 的插件,名字居然就叫 Lua,如下图所示。简单试了一下,感觉不错,符合上述各项需求,值得推荐。

Lua 插件
Lua 插件
升级php7

升级php7

这是一个升级的季节……

前两天刚升级完Git,感觉可以稍微轻松一下。今天收到email,WordPress 升级了! 升级也就算了,关键是进入管理界面时,扑面而来一个提示:“WordPress has detected that your site is running on an insecure version of PHP” ,这意思是:您的php版本太老了,该升级了!

查了一下当前Debian 9默认的php版本:V5.6.40,似乎不算太老啊。顺手又查了一下该系统中最新的php版本,已经是V7.0.33版本。V7的版本应该足够WordPress 使用,于是决定升级php来解决这个提示问题。

PHP毕竟是世界上最好的语言,各种插件都已经相应升级好了,都有PHP7对应的版本,因此事情就简单了,使用以下命令,直接安装即可:

sudo apt install libapache2-mod-php7.0 php7.0-fpm php7.0-gd php7.0-curl php7.0-mbstring php7.0-mcrypt php7.0-json php7.0-mysql php7.0-opcache php7.0-readline php7.0-xml php7.0-xmlrpc php7.0-zip php7.0-bz2 php-imagick

升级完php及apache的模块后,需要设置 Apache 使用最新的php7版本。也很简单,重新设置相应的模块并重启 Apache 即可:

sudo a2dismod php5
sudo a2enmod php7.0
sudo a2enmod proxy_fcgi
sudo a2enconf php7.0-fpm
sudo systemctl restart apache2
从HG迁移库到Git

从HG迁移库到Git

迁移工作比较简单,参考BitBucket推荐的一篇blog,基本操作与该博主的描述一致,部分有些差异。

以下操作基于Debian系统。

首先安装mercurial-git,这个工具会自动将原hg库的信息提交给新的Git库,会保留以前commit的comment内容,这点尤为重要。如果不关心以前的comment,就没啥好说了,直接将整个代码提交给Git就完事了。

sudo apt install mercurial-git

接着需要让 HG 知道有 mercurial-git 这个扩展,并能操作Git库。 修改~/.hgrc文件,添加以下内容即可:

[extensions]
hgext.git=

如果希望将HG的branch也转化成Git中的branch,则需要做一些稍显古怪的操作。请注意:HG中的branch不对应Git的branch!我不太清楚是HG的问题,还是 mercurial-git 这个工具的问题,需要为每个分支设置bookmark,然后根据这些bookmark转换成Git中的branch。

例如,将HG库中的default、mss_v36、mss_v36_dev三个分支,分别对应Git库中的master、mss_v36_hg 以及 mss_v36_dev_hg 分支:

hg bookmark -r default master
hg bookmark -r mss_v36 mss_v36_hg
hg bookmark -r mss_v36_dev mss_v36_dev_hg

然后,直接推送到Git的远端库即可:

hg push git+ssh://git@bitbucket.org:my_account/my_apps.git
Git入门基础知识

Git入门基础知识

多年开发工作以来,前前后后用过很多个版本管理工具,从最早的VSS(微软的工具,现在大概没人知道这是个什么东东了),到SVN、ClearCase、mercurial(hg),现在终于要过渡到Git了。

其实我们最近这些年一直用着hg,感觉挺好的,非常满意,没有打算换其他工具。无奈BitBucket发邮件通知,明年要切换到Git(详情请点击这里),考虑到年底事可能会比较多,乘着现在还不太忙,赶紧先学习,抓紧时间迁移。

HG和Git的基本原理和操作是相通的,都是分布式的版本管理工具。具体在某些细节上,确实有些差异。比如HG的commit操作,实际上相当于Git的add+commit两步操作。Git多了本地缓冲区的概念,在branch部分,HG和Git有很大差异。Git的本地branch和远端branch可以不一致,需要建立映射关联,而HG本地branch和远端branch总是一致的。Git当然更灵活些,而从管理角度考虑,我更喜欢HG的处理方式。

HG的branch不能被删除,只能被关闭,而Git的branch可以被删除!我觉得这是两者最大的一个差异。显然,Git更鼓励频繁地操作branch。这点我更喜欢Git,实际工作中,定位问题、出临时版本,都可以应用一些临时的branch,事后删除,版本库也干净很多。

网上的学习资料很多,我觉得廖雪峰写的教程非常详细、易懂,推荐给大家,请点击此处

在windows系统中,直接下载、安装SourceTree即可,而在Debian系统中,使用以下命令直接安装Git:

sudo apt install git

SourceTree 使用方便、直观,如果平时是工作在windows系统,用这个工具就挺好。像我很大一部分时间是工作在Debian系统上,因此掌握一些Git的命令行操作就比较重要,好在不太多,并且和HG相差不大。

以下记录一些常见的操作:

全局配置

ssh-keygen -t rsa -C "git@demo.com"

BitBucket的Git支持 SSH 和 HTTPS 两种传输方式,推荐采用SSH,并且采用证书接入,这样有两点好处:(1)防止其他人登录。账号、密码鉴权方式比较容易泄密,而SSH证书在本地保存,只要别人不能轻易获取你的密钥文件,就无法从其他计算机上登录Git服务器。(2)每次登录、操作无需输入账户密码,能省点时间吧。

上述命令就是创建SSH密钥,默认在~/.ssh 目录下创建两个文件:id_rsa以及id_rsa.pub。id_rsa.pub中记录公钥,将其内容拷贝出来,保存在BitBucket账户中即可。

git config --global user.name "git"
git config --global user.email "git@demo.com"

配置全局用户名。这个不是Git账号的登录名,只是在每次提交代码时,系统用这些参数做一些描述性信息,比如显示改动的用户是谁,诸如此类。

git config --global color.ui true

Git命令行采用彩色显示(无关紧要,只是个人的恶趣味)。

基本命令

git add xxx 将修改提交到缓冲区
git commit -m "1234"  将缓冲区提交到本地库
git restore <filename> 放弃本地的修改
git checkout -b xxx 创建本地分支xxx
git push --set-upstream origin xxx 将本地xxx分支推送到远程仓库
git checkout -b xxx --track origin/xxx 创建本地xxx分支,并关联到远程origin/xxx分支
git checkout xxx 切换到xxx分支

Branch相关命令

git branch 查询当前本地分支
git branch -a 查询所有本地和远端分支
git branch -r 查询远端分支
git merge xxx 将分支xxx合并到当前分支 
git branch -d xxx 删除本地分支xxx
git push origin -d xxx 删除远程分支xxx (注意:分支名不要带上 origin)
git remote prune origin 删除远程分支后,更新本地的远程信息
git pull 从远程仓库更新到本地仓库
git fetch --all 更新所有分支
git pull --all 拉取所有分支
git remote show origin 检查远程分支与本地分支的关系

Tag相关命令

git tag 查询所有的标签
git tag ttt 打一个标签ttt
git tag -a ttt -m "xxx" 打标签ttt,说明文字xxx
git show ttt 查看tag及其说明文字
git push origin ttt 推送标签到远程仓库
git push origin --tags 推送所有本地标签到远程仓库
git checkout tag_name 获取tag标签对应的代码(只是快照,无法更改)
git checkout -b branch_name tag_name 在tag基础上创建分支(可以进行修改)
git tag -d ttt 删除本地标签ttt (尚未推送到远程)
git push origin :refs/tags/ttt (删除远程库中的ttt标签)
Pi3的奇怪故障

Pi3的奇怪故障

最近遇到的奇怪问题,Pi3总是无故崩溃,然后需要掉电重启才可以。后来发现是:由于自己习惯登录图形界面,只要一VNC登录到Pi的桌面,Pi就崩溃。如果仅仅是远程SSH到Pi,则没有任何问题。

对Pi不太熟悉,简单看了一些log,也没找出所以然。只好做了以下步骤:

(1)卸载vnc4server,然后重新安装vnc4server。

sudo apt remove xrdp vnc4server tightvncserver
sudo apt purge tightvncserver xrdp
sudo apt install vnc4server tightvncserver xrdp

(2)运行“sudo raspi-config”,更新,然后选择第7项“Advanced Options”,接着选择“A5 Resolution”,设置成“1280*720”。

完成这些步骤后,同时关闭了蓝牙和无线,只保留有线连接, 似乎VNC到Pi就没有问题了。

迁移系统至SSD盘

迁移系统至SSD盘

日常工作是使用一台Thinkpad T430,有点年头了,感觉各方面都已经有些吃力。很早就想着将系统转到SSD盘上,但是又不想重装系统,毕竟是正在用的工作电脑,折腾不了那么多时间。

这事就这么搁置下来了……

近日在逛知乎的时候,发现了一篇文章(请点击此处),里面介绍了免费软件可以轻松迁移系统到SSD盘上。大喜之下,从京东购买了msata接口的金士顿 SSD 盘(UV500系列,请点击此处了解),同时从文章中下载了软件,准备进行迁移。

遗憾的事情发生了,文章提到的免费软件已经不支持迁移系统,需要付费才行。后来在网上发现了其中文版本“傲梅分区助手”(请点击此处),似乎是同一厂家的软件。中文版本需要关注公众号,然后从公众号拿到注册码, 免费 ,而且功能上可以迁移系统,耗时大约两小时左右。

过程稍稍有点折腾,不过如果是三星的SSD盘的话可能就省事,因为三星提供了免费系统迁移工具,当然只对三星的SSD盘有效。

迁移过程比想象中简单多了,以前的软件多数都是安装在系统默认的C盘,因此直接就迁移过去了,非常平顺。部分软件安装在其他盘符,在新系统中调整一下盘符,或者卸载部分软件再重新安装即可。

总之,工作量不太大,过程顺利,很满意。