文章归档

使用 Orange Pi One 和 GPS 搭建1级时间源

我一直有一种自建基础服务的兴趣,自从当初机缘巧合混到一个开发者邮箱之后,就一直在尝试自建 NTP 服务,海外已经放了好几台 VPS 到 pool.ntp.org 里面了,但国内条件有限,并没有什么好办法。于是就想到了自建一个。

1. 背景知识

整个 NTP 分发网络的结构是一种近似树状的分层结构,每一级叫做一个 “Stratum”, 其中 Stratum-0 是可靠的参考时间源,比如原子钟、GPS或无线电授时信号源等,所有0级时间源构成了整个 NTP 网络中的参考时钟;在逻辑上,所有0级时间源作为一个整体提供了全世界的标准时钟。不过因为0级时间源本身实际上只是某种形式的时钟信号发生装置,所以它们并不直接对外提供授时服务,而是连接[……]

继续阅读~→

终于解掉 nginx 在 SSL 下 400 的错误,蠢死了

这个问题持续了得有超过一年了,症状很简单,配置了 https 访问之后,使用 IPv6 访问的时候会报 400 Bad Request 错误,强制使用 IPv4 或者强行指定 https 协议都能解决。说到这里应该很明显了对吧,首先就应该想到是不是 80 端口上也开着 ssl 来着。但这个讨厌的地方在于用 IPv4 就一切正常了,我一直没想那么多……就因为这我的博客很长时间都没办法强制 https 访问,不然 IPv6 过来的用户没法看。

前两天搞着搞着调另一个什么反向代理相关的设置的时候,顺手开了 debug 日志,然后就想顺便测一把,结果一不小心就找到了原因_(:зゝ∠)_

长话短说,问题的根本原因是普通 http 协议和加密的 https 协议配置在了一个 server{} 块内。并不是说不支持这样搞,而是这样配置过后服务器的行为会和分开配置成两个有所不同。
[……]

继续阅读~→

Apache + Varnish + nginx 获取正确的客户端IP

貌似现在只要我更新博客就说明又在没事瞎折腾了… =.=
很久以前就遇到过这个问题,或者不如说实际上就是因为无法正确获取客户端IP才让我一直用的 Apache + nginx 的构架。今天折腾一下午 + 一晚上总算是把这个问题(还算)圆满地解决掉了。

首先是参考这篇文章配置好整个服务器构架,后端使用 Apache httpd 来处理 PHP, 中间用 Varnish 做缓存,前端使用 Tengine 作为 web 服务器,所以来自客户端的请求的处理流程是:

Client -> Tengine:80 -> Varnish:8090 ->(Miss)-> httpd:81

然后问题就来了,处在最后面的 httpd 拿不到正确的客户端IP地址,总是显示为127.0.0.1. 这个问题有趣在于,一直以来我都是使用了 mod_rpaf 来获取 X-Forwarded-For 中的客户端IP的,而如果我去掉中间那一层 Varnish 直接让 Tengine/nginx 反向代理给 httpd 的话,IP地址是能够正确获取的,更进一步实验表明,在只有一次代理的情况下一切都是正常的,当代理变成了两层,无论两层代理的顺序如何,都会出现这个问题。

中间各种股沟各种查文档就[此处省略6小时]了…

基本上有两个比较主要的原因。
[……]

继续阅读~→

从 MySQL 迁移到 MariaDB

“Because Oracle is Oracle is Oracle()”[?]

ArchLinux 昨天宣布将使用 MariaDB 作为 MySQL 的默认提供包,openSUSE 已经在新近发布的12.3版中默认使用 MariaDB, 连 Fedora 也正在考虑更换为 MariaDB.

于是我决定把我的所有服务器从 MySQL 迁移到 MariaDB.

对 Arch 用户来说很简单,照着官方新闻里面的来就是了:

而对于 openSUSE 就更傻瓜式了,毕竟是默认的嘛: zypper in mariadb 一句就够。

至于 Debian/Ubuntu 用户就要稍微复杂一些,不过整个过程还是很流畅的:
[……]

继续阅读~→

解决一个 embrr 不能翻页的 PHP 配置问题

唔…大致说来就是最近在折腾着把停止更新的 embr 给升级到 Twitter REST API v1.1, 然后今天参考黄飘飘的改动把 fav 相关的两个地方弄上了自动翻页。

因为 api 更新的关系,不能用原来的页码作为参数,只能用推文的 id 来做界定了,不过操作起来倒是比想象的还要简单就是了。修改好过后传到 appfog 上木有任何问题,但放到我自己的服务器上面过后发现翻页不能了…
开始还以为是 nginx 配置不对,但看了半天找不到问题,于是考虑是不是 PHP 的问题…

简单找了一下,发现问题在于生成的翻页链接上,因为推文 id 被作为参数传到链接里面,而生成的链接变成了类似于 /favor.php?max_id=2.9972877531744E+13 这样的形式…科学计数法耶…
[……]

继续阅读~→

慎用 Afraid.org 提供的免费 DNS 服务

首先要明确的是 freedns.afraid.org 是一个非常优秀和好用的免费 DNS 服务商,我自己用了超过两年,现在也还有几个不怎么好的域名在上面。
这家的优点是:界面简单明了、解析记录种类较全、新记录生效极快以及服务稳定。

那我为啥要说慎用呢?因为昨天我终于搞清楚了一个以前一直没在意的功能的含义…

对于所有注册用户,可以免费添加若干域名到 afraid 的解析系统当中,设置解析记录等等。但是,免费用户会被强行开启一个功能叫做 shared:public. 付费用户才可以设置为 shared:private.
因为并不影响使用,我一直都没有在意这个功能到底是啥,直到昨天才发现,将共享设置为公开意味着整个系统中的全部注册用户都可以使用这个域名

没图我说个丁丁?
freedns
那个 litgh 是我,别的么…你认识吗?
[……]

继续阅读~→

使用 Trac + git + cherokee 搭建私有版本库

基本还是弄着玩的…前提显然是有一台vps嗯嗯…

Trac 是一个专为软件开发设计的集问题追踪和 wiki 系统于一体的网页软件,git 是一个灵活而强大的版本控制工具,而 cherokee 则是一款简单好用的 web 服务器,当然,三者都是开源的。另外,这里选用 cherokee 而不是 nginx 或者 apache 这一类更为主流的服务器是因为 cherokee 的网站和默认页面比较好看所以想干脆来装逼一下这种事情我是不可能在教程里面说的。
为了搞好这个我折腾了一天,翻看了好多文档和教程,试了多种方法,最后是用的文档上没有提到的一种组合。之所以这样是因为按照文档进行设置一直不成功…

我所用的系统是 Ub[……]

继续阅读~→

在两台 VPS 之间实现自动异地备份

就是记录一下设置 Wiki 的自动备份,在 Wiki 所在的 VPS 上定时对资料目录打包,然后从备份用 VPS 把打包好的文件传输过去。

之前遭遇过多次 VPS 挂掉而数据灭失的惨剧,最近一次就是幸苦写了十多个页面之后的个人 Wiki… 然后到现在都还木有把那些内容全部给补回来…虽然说现在使用了几乎不用考虑升级(也就大大减少了手贱的几率)的 Slackware 系统,但是以防万一还是做个异地备份的好。

异地备份重于泰山

为了方便设置备份时间和文件传输的安全性考虑,我把所有参与备份的服务器设置为了同一时区,并且使用 scp 命令来通过 SSH 完成文件传输。至于备份的脚本,设置为使用 cron 任务定期执行。

我的个人 Wiki 放在一台跑着 Slackware 13.37 的低配 VPS 上面,用的是 MoinMoin Wiki 系统,所有数据都保存在文件系统中而不需要数据库,所以只要给 Moin 文件夹打包就可以备份全部内容了。
[……]

继续阅读~→

在 CentOS 5 下默认使用 Python 2.6

出于某些原因,某台低配VPS上面只能使用 CentOS 5.8 系统,但是 el5 系列的 python 版本只更新到了 2.4.3 而需要运行的应用建议使用 2.6.x 系列,所以设法更新python版本。
找了好几处不同的网站,最后综合起来达到了想要的效果:非编译安装 python 2.6 并通过 yum 管理,同时系统全局默认使用 2.6 版本替代 2.4.3

对于刚安装好的vps来说,当然要更新系统至最新。然后我们来更新python.
python是一个系统级的依赖包,没有办法卸掉(要不然很多东西都不能用了),于是只能用第三方提供的二进制包了,这里我用的是 Fedora 维护的 EPEL 源,同时还需添加 RPMForge 源以满足依赖关系。
[……]

继续阅读~→

搬家到 Linode & nginx 重定向设置

博客搬家到了 Linode 的东京结点上,操作系统依然使用的是配置服务器最顺手的 ArchLinux 但服务器构架从之前小内存机器上仔细调教过的 MySQL + Apache httpd 变成了复杂一些但可以充分压榨服务器性能的 MySQL + Apache httpd -> varnish -> nginx 也即通常所说的 LNMPA 再加一个 varnish 这样。数据库和文件等的迁移都很顺利,因为是先修改我的本地dns缓存指向新主机,调试好过后才真正修改的dns记录,所以实现了博客不下线地转移。

迁移完成立刻就发现了一个问题:首页无限重定向。
这个倒是不难办,把原来所用的 nginx 虚拟主机配置文件中一些针对不同文件类型做的配置全部去掉,只保留了反向代理给 varnish 的语句,首页正常打开,后台也正常。经测试插件配置、启停、增删都没有问题。

很快就发现,博客的重定向不正确,也就是 WordPress 后台中的固定链接设置无法生效,访问自定义链接的页面打开的是首页。
安装了 Permalink Fix & Disable Canonical Redirects Pack 插件,但是还是无法正常。(需要注意下面的语句是建立在此插件启用的基础上的,停用插件后还是会出错)
[……]

继续阅读~→

怪蜀黍神马的到这里就禁止通行了哟/
Merry