- 2020-05-15
- 00:20
- 网站与服务端
x32 ABI 及相应 Docker 容器使用
x32 架构是怎么回事呢?x86、x86_64 架构相信大家都很熟悉,但是 x32 是怎么回事呢,下面就让小编带大家一起了解吧。x32 架构,其实就是 x86 和 x86_64 架构拼在一起,大家可能会很惊讶 x86 和 x86_64 架构怎么会拼在一起呢?但事实就是这样,小编也感到非常惊讶。x86 及 x86_64 的历史,以及 x32 ABI¶我们现在使用的个人计算机及服务器绝大多数都使用 x86_64 架构,该架构由 AMD 于 2000 年发布规范,2003 年发布第一块处理器。x86_64 是一个 64 位的架构,意味着在 x86_64 中,CPU 的每个寄存器都能保存 64 bit 的数据(即 8 个字节)。在 x86_64 流行之前,多数电脑都使用 Intel 处理器以及相应的 x86 架构 / 指令集,这是一个 32 位的架构,...
- 2020-04-23
- 16:02
- 网站与服务端
写一个简单的 Telegram 机器人
应 DN42 Telegram 群群友的要求,我打算给我的 Bird Looking Glass 加上 Telegram Bot 的支持,方便群友现场查询 Whois、测试网络通断、检查漏油路由泄漏源头等。这个 Bot 要能识别以斜线 / 开头的命令,然后对命令消息进行回复。我的 Looking Glass 使用 Go 语言写成,因此我一开始先查找了 Go 语言的 Telegram Bot API。但流行的 API 库无一例外都遵循了同样的请求结构:Telegram 服务器发送一个回调到自己的服务器;自己的程序处理请求,期间可能根据本地配置的 Token 向 Telegram 服务器多次主动请求;自己的程序最终主动请求 Telegram 服务器,发送回复信息。这套方案功能强大,但有点复杂,而多余的功能我根本用不上。我更希望使用 Telegram 官方提供的另一种方式,...
- 2020-03-13
- 20:23
- 网站与服务端
Docker 容器共享网络命名空间,集成 Bird 实现 Anycast 高可用
正好一年前,我在 DN42 网络内用 Docker 建立了 Anycast 服务。当时我的方法是,自定义容器的镜像,在其中安装一个 Bird,然后加入 OSPF 协议的配置文件来广播 Anycast 路由。但是随着时间推移,这套方案出现了以下问题:安装 Bird 本身是个较花时间的过程。我的 Bird 不是用 apt-get 装的,因为我的 Dockerfile 需要支持多种 CPU 架构,而 Debian 有些架构的软件源里没有 Bird。而又因为我的构建服务器是 AMD64 架构,使用 qemu-user-static 支持其它架构的镜像运行,为其它架构制作镜像、编译程序时就涉及到大量的指令集翻译,效率非常低。构建一个镜像在不同架构下的版本可能需要 2 小时以上,而安装应用本身的 apt-get 流程只需要几分钟。自己定制镜像也比较花时间。...
- 2020-01-17
- 23:45
- 网站与服务端
使用 PowerDNS 的 Lua 功能自建分地区解析 GeoDNS
之前,如果要为自己的网站自建权威 DNS 系统,那么(几乎)唯一的选择是 PowerDNS 加上它的 GeoIP 后端。但是 GeoIP 后端使用的是 YAML 格式的配置文件,不能与 MySQL 等数据库一同使用。这意味着必须手动配置一套跨服务器同步文件的系统,而不能使用更为成熟的数据库同步技术。不过,PowerDNS 在最新的 4.2 版本中加入了 Lua 记录的支持。Lua 是一种专门用于 “嵌入其它程序执行功能” 的编程语言,你或许曾经在 nginx 上看到过它(作为一个插件)。Lua 记录支持使得 PowerDNS 可以根据用户查询请求的不同来返回不同的回答,分地区解析 GeoDNS 功能也就可以实现了。更新 PowerDNS¶最新的 PowerDNS 4.2 版本没有加入 Debian 10 的软件仓库中,你需要从 Debian Unstable 的软件仓库下载。...
- 2020-01-13
- 22:31
- 网站与服务端
学校网络中自建 VLAN,低价实现高速私有内网
和全国大多数高校一样,我所在的大学以 “一人一账号” 的方式提供网络。通过有线网络或者 Wi-Fi 联网时,所有请求会被暂时重定向到一个登录界面(即 Captive Portal),输入用户名密码后才可以访问互联网。这个做法也是大多数公共场所(例如机场,咖啡厅)的标配,对于电脑、手机等设备也还算友好。但是一些不带显示屏的设备(例如树莓派,ESP8266 等)就难以访问网络了。对于树莓派、ESP8266 等可以运行自定义代码的系统,可以模拟提交表单来登录网络,但是一旦模拟提交表单的程序出现问题,你就得手动将设备取下来,连上自己的电脑上传新的登录程序,这一过程非常的麻烦。至于其余只能运行预定程序的智能设备就完全无法联网了。由于我并没有智能台灯等设备,本文暂时只考虑可以运行 Windows、macOS、Linux 三大操作系统之一的智能设备,...
- 2019-10-26
- 00:48
- 网站与服务端
与 Hexo 配合使用 Sass 和 Webpack
为何使用 Sass 和 Webpack¶Sass 是 CSS 的超集,在 CSS 的基础上扩展了大量的语法,支持规则嵌套、变量定义、include 等功能,也可以进行数学运算。主要功能可以在官方入门教程中查看。Sass 原先的文件格式扩展名是 sass,其结构类似 yaml,似乎不与传统 CSS 兼容;而目前 Sass 的文件格式是 scss,兼容 CSS 文件。我使用 Sass 的目的,一是更加清晰的 CSS 规则管理。例如,我有一些 CSS 规则希望只对网站顶栏生效,我就可以将它们全部放到一个代码块中方便管理:header { h1 { ... }}二是减少网页加载时的 CSS 代码量。虽然我的网站使用了 Bootstrap,但是我只使用了一小部分功能,即 Bootstrap 的栅格系统,导航栏和下拉菜单,其它大部分功能都没有使用,这部分 CSS 就不必加载。同时,...
- 2019-09-25
- 22:17
- 网站与服务端
开始使用 Hexo 静态网站生成器
什么是静态网站生成器 ¶我们常用的 WordPress、Typecho 等 CMS(内容管理系统)都是动态网站。当用户访问网页时,服务端运行使用 PHP、Python、Node.js 等语言的程序,根据用户的请求实时产生网页,将其返回给用户。而 Jekyll、Hexo、Hugo 等静态网站生成器采取的是另一种方法:提前预测用户的请求,一次性产生对应的 HTML 文件。这两种方式的主要优缺点如下:谁更占优动态网站静态网站动可以实现复杂的交互,根据用户的输入随时改变内容只能响应预定的输入,灵活性差动大多数 CMS 都会提供易用的管理后台,方便用户随时更新内容没有在线后台,需要在本地安装额外软件更新网站内容静安装脚本运行环境需要较复杂的配置服务端无需脚本运行环境,几乎无需服务端任何配置静实时产生网页需要较大的运算量(包括脚本运行、数据库查询),对服务器造成较大的压力服务端几乎无需计算,...
- 2019-09-16
- 22:20
- 网站与服务端
(自建 NTP)在 Tinker Board 上使用 PPS
在前一篇文章中,我使用 Tinker Board 和 ATGM336H GPS / 北斗模块自建了 NTP 服务器,以 GPS 作为时间基准。GPS 模块除了提供传统的串口输出 NMEA 语句之外,还额外提供了一个 PPS 信号,这个信号会每秒变化一次。原本 gpsd 需要不断解析 GPS 模块传来的 NMEA 语句,需要耗费不短的时间,并且容易被其它程序抢占运行时间,产生 delay(延迟)和 jitter(波动)。而 PPS 信号可以直接触发 CPU 的中断,运行一个简单的处理程序,让操作系统以高优先级处理,不会被其它程序影响。一般而言,在 Linux 中,PPS 由内核直接提供驱动支持。但是在前文中,由于 Tinker Board 的 Armbian Linux 内核没有提供 PPS 支持,所以我们没法直接开启。解决方法 1:重新编译内核 ¶如果内核没有对应支持,那就重新编译内核,...
- 2019-09-16
- 21:01
- 网站与服务端
自建基于 GPS 的 NTP 服务端
NTP 是什么 ¶NTP(Network Time Protocol)是目前使用最广泛的互联网时间同步协议。我们常用的 Windows、macOS、Linux 等都自带了 NTP 客户端,可以连接远程服务器获取当前的时间。例如,Windows 的 Internet 时间同步功能就是基于 NTP:(图片来自网络)Windows 默认会连接到 time.windows.com 这台由微软维护的 NTP 服务器同步时间。但是,默认的这台服务器在国内并不好用。这台服务器位于美国,到国内的延迟很大并且容易波动,因此 NTP 客户端也很难得出准确的时间。那么中国大陆有没有 NTP 服务器呢?有,但是不多:cn.pool.ntp.org 由 www.pool.ntp.org 维护的 NTP 服务器池项目,所有服务器由志愿者提供,在各个地区通过 DNS 负载均衡到不同的服务器上。...
- 2019-08-03
- 13:23
- 网站与服务端
使用 GPP 预处理 Dockerfile,实现 #include、#if 等功能
由于我有多种架构的设备运行 Docker(包括 x86_64 的电脑和服务器,ARM32v7 的 Tinker Board 和 ARM64v8 的树莓派 3B),我的每个 Docker 镜像都要构建多种版本。最初我给每个架构单独写一份 Dockerfile,但是很明显这样难以统一管理,在软件更新修改 Dockerfile 时经常漏改文件。之后,我用的是 Docker 的构建参数功能,即 --build-arg 参数,根据参数来调用不同的基础镜像、下载不同文件。但是这样还是有很大的局限性。首先,不同项目对不同架构的称呼是不一样的。例如,我们平时说的 x86 32 位架构,i386,就被 Go 以及众多使用 Go 的项目叫做 386。类似的,ARM32v7 也可以叫做 ARMHF,而 ARM64v8 有三种写法(ARM64v8,ARM64,AARCH64)。之前,...