文章归档

终于解掉 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小时]了…

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

继续阅读~→

新装系统 Win8 与声卡那点纠结的记录

好吧我换系统了,因为换了个新硬盘神马的。然后就想着干脆装 Win8 吧。

装系统一切都好,什么都很正常很顺利那样,结果完了我想看番的时候发现…耳机没声音……
囧死了好吧。

长话短说,试过了网上提到的多种方法,有些是用了无解,有些是不适用我的情况。

我的声卡是 Reltek ALC 269 机子是华硕 N53Jf.

折腾一整天,重装三次系统之后,问题确定:Reltek 官方驱动与 Win8 不兼容。
是滴你没看错,最新版写着支持 Windows 8 的那个也不行,只有外放有声音耳机不行。

解决方案是装好系统过后静置,等系统自己联网下载微软的驱动。

真疼。[……]

继续阅读~→

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

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

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

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

继续阅读~→

自制 RSS 源抓取 osu! 用户动态

由于有一些暂时解决不了的问题,所以这个暂停,想尝试这样同步的请谨慎。。。

想把 osu! 的动态同步到 twitter 但是官方没有提供 RSS 源所以一直都很纠结,推上有人在做同步,问了一下拿到这样的链接:

RT @ReitsukiSion : @AstroProfundis @Filine_niang http://hcg.im/osu24.php?id=你的osu UID ,以後你們就這樣告訴別人吧

但是这个是每次成绩都抓取出来的,如果我连着打几十遍不就有几十条推了么?肯定会被骂的。。。
在官网的用户界面上有 Recent Activity 一栏其实很合我胃口,只有进入谱面前100或者解锁成就才会出现在这个地方[……]

继续阅读~→

搬家到 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 插件,但是还是无法正常。(需要注意下面的语句是建立在此插件启用的基础上的,停用插件后还是会出错)
[……]

继续阅读~→

个人常用 DNS 服务器集合

越发觉得应该建一个个人wiki了。。。

经常到处 Google DNS 服务器,终于烦了,做一个自己常用的地址列表放着。
注意这个不是推荐,只是自用的备忘,不定期更新。如果想看推荐请戳这里
格式为: DNS Server IP   Average ping*   TTL   Domain(Option)
* 测试用网络为河北联通ADSL, 基于单次 ping 命令测试

河北联通:
202.99.166.4   <1ms   253   cache-lf-1
202.99.160.68   <1ms   253   cache-lf-1
[……]

继续阅读~→

Apache + Nginx 压低内存的一点折腾

这篇日志注定很短。
现在使用的服务器是 ArchLinux + Apache 2.2.21 + Nginx 1.0.11 + MySQL 5.5.18 + PHP 5.3.8 的环境,详细的PHP探针可以在这里看到。
以上都是直接从Arch的原安装,然后一些组件是自己编译的,简单的方案在之前的这篇这篇日志中有提及。再加上ftp客户端和后台运行一个ntp进程,apache加载上mod_python组件,配置好了过后开机内存在72-75M,很满意。但是在运行一段时间(积累了一定量的网页请求)过后,内存就会直逼400,突发状况可以冲到接近500,就算空闲下来也有接近300,这个就有点不爽了。
于是折腾。

根据观察,处在前端的Nginx资源占用一直很小而且稳定,主要占用内存的就是若干httpd进程,那么就着手应对这个了。
在一番Google以及不断实验,重启若干次过后,找到了个人比较满意的配置方案如下~
[……]

继续阅读~→

暂时稳定 – ArchLinux 与 OpenVZ 与 kernel too old 之二

上回,这次采用了这篇文章中的办法来解决母机kernel过旧的问题。
编辑/etc/pacman.conf[testing]之前加上:

然后到/etc/pacman.d/mirrorlist设置为合适的源就行了,我用的是这个:

此时先不升级、不重启,编辑/etc/fstab添加:

当前最新版本的glibc-vps已经修复此bug,安装后可直接使用,无需特别设置(截止glibc-2.16.0-101_x86-64测试通过)。
[……]

继续阅读~→

继续折腾 – ArchLinux 与 OpenVZ 与 kernel too old

本馆从周五开始就无法访问了,嗯,乃木有猜错,瓦又开始折腾了……
因为给ThinkUp从0.16升级到0.17的时候数据库出了一点莫名其妙的问题所以不能用,于是干脆备份数据然后重新来过。反正我是一直想用ArchLinux+LNMPA的组合的,因为老是弄不好才用的Debian+LNMP救急。然后备份的时候发现ThinkUp的数据库居然有220+M小吃惊了一下。
然后就重装VPS的系统咯,然后装了Ubuntu觉得不爽,还是弄成了Arch。因为之前一直因为母机内核版本的问题没办法直接用Arch的源来更新,一旦更新就:

然后系统崩溃只能重装。网上找到的许多解决办法都有各种各样的问题,最后自行找到了一个折中的妥协方案。
通过搜索,找到了一个存档了每天的Arch源的网站,然后又因为我的VPS母机kernel貌似是2.6.18,经过测试找到了不会引发上述错误的最新的源。
[……]

继续阅读~→