本周我所使用的web server —— Hiawatha 发布了7.6的版本,重写了关于防止SQL注入方面的模块，官方推荐升级标记为低。考虑到稳定性，我决定还是跟进，因为hiawatha 并不常更新。

还有就是我所使用的缓存服务器varnish 也放出了3.0.1的测试版 RC1,考虑到前一版本的varnishadm 有点问题，我也打算更新到该版本。

最后就是nginx 发布了1.1.1的光棍版，本来我用1.0.4版用的好好的，唯一不爽的就是时区总是不对。我怀疑是在编译安装时被定义死了，所以我便打算重新编译一个版本，看看能不能修复这个问题。

首先，停掉相关所有服务。
killall hiawatha
killall nginx
killall varnishd

删除所有旧程序，备份配置文件。

现在，开始安装新版本。首先是hiawatha.
下载源码包（http://www.hiawatha-webserver.org/files/hiawatha-7.6.tar.gz），解压，进入目录：

我的configure:
[root@PowerPC hiawatha-7.6]# ./configure \
> --prefix=/usr/local/hiawatha \
> --exec-prefix=/usr/local \
> --sysconfdir=/etc/sysconfig \
> --localstatedir=/var \
> --disable-largefile \
> --enable-chroot \
> --enable-command \
> --disable-ipv6 \
> --disable-monitor \
> --disable-ssl

检查依赖，没有问题，接下来make && make install安装.一切顺利。之后，覆盖掉新生成的配置文件即可。

便可以启动hiawatha服务器了。

接来下是nginx,下载源码包(http://nginx.org/download/nginx-1.1.1.tar.gz)，解压，进入目录：

我的configure:
[root@PowerPC nginx-1.1.1]# ./configure \
> --prefix=/usr/local/nginx \
> --sbin-path=/usr/local/sbin/nginx \
> --conf-path=/etc/sysconfig/nginx/nginx.conf \
> --error-log-path=/var/log/nginx/error.log \
> --pid-path=/var/run/nginx.pid \
> --lock-path=/tmp/nginx.lock \
> --user=http \
> --group=web \
> --with-select_module \
> --with-poll_module \
> --with-http_image_filter_module \
> --with-http_dav_module \
> --with-http_flv_module \
> --with-http_gzip_static_module \
> --without-http_ssi_module \
> --without-http_auth_basic_module \
> --without-http_geo_module \
> --without-http_rewrite_module \
> --without-http_proxy_module \
> --without-http_fastcgi_module \
> --without-http_uwsgi_module \
> --without-http_scgi_module \
> --http-log-path=/var/log/nginx/access.log \
> --http-client-body-temp-path=/tmp/nginx/request \
> --without-mail_pop3_module \
> --without-mail_imap_module \
> --without-mail_smtp_module \
> --without-pcre

检查依赖，没有任何问题。之后configure给出了编译概况，见下：

Configuration summary
  + PCRE library is disabled
  + OpenSSL library is not used
  + md5: using system crypto library
  + sha1 library is not used
  + using system zlib library

  nginx path prefix: "/usr/local/nginx"
  nginx binary file: "/usr/local/sbin/nginx"
  nginx configuration prefix: "/etc/sysconfig/nginx"
  nginx configuration file: "/etc/sysconfig/nginx/nginx.conf"
  nginx pid file: "/var/run/nginx.pid"
  nginx error log file: "/var/log/nginx/error.log"
  nginx http access log file: "/var/log/nginx/access.log"
  nginx http client request body temporary files: "/tmp/nginx/request"

确认一下，没有任何问题，make && make install 编译安装至指定目录。然后在恢复下配置文件，即 nginx.conf 文件。便可以启动nginx 服务器了~

最后就是varnish cache 了，下载源码包(http://repo.varnish-cache.org/source/varnish-3.0.1-rc1.tar.gz)，解压，进入目录：

我的configure:
[root@PowerPC varnish-3.0.1-rc1]# ./configure \
> --prefix=/usr/local/varnish \
> --exec-prefix=/usr/local \
> --sysconfdir=/etc/sysconfig \
> --localstatedir=/var \
> --disable-largefile

检查依赖，没有问题，之后便编译安装 make && make install.完了之后就是恢复下之前备份的配置文件,即 default.vcl 文件.

一切OK后。便可以启动varnish 服务器了。

试了一下，所有网站访问正常。唯一的问题……就是nginx，肿么时区还是UTC？为神马？？晕了~

我的VPS是在美国的，所以默认时区当然不可能是中国标准时间(CST)，我也一直没改。不过这几天，我发现了问题，就是我的nginx是使用的我系统的默认时区(UTC),而我是使用nginx做我的ftp用户目录文件的展示的，也就是说，我上传文件的时间和用户在nginx上看到的时间是不吻合的，之间相差了8个小时~

这的确很坑爹~我决定把时区改回来。在CentOS下，有tzselect命令可以改。直接运行即可：
[root@PowerPC ~]# tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent or ocean.
1) Africa
2) Americas
3) Antarctica
4) Arctic Ocean
5) Asia
6) Atlantic Ocean
7) Australia
8) Europe
9) Indian Ocean
10) Pacific Ocean
11) none - I want to specify the time zone using the Posix TZ format.
##选择所在洲
#? 5
Please select a country.
1) Afghanistan 18) Israel 35) Palestine
2) Armenia 19) Japan 36) Philippines
3) Azerbaijan 20) Jordan 37) Qatar
4) Bahrain 21) Kazakhstan 38) Russia
5) Bangladesh 22) Korea (North) 39) Saudi Arabia
6) Bhutan 23) Korea (South) 40) Singapore
7) Brunei 24) Kuwait 41) Sri Lanka
8) Cambodia 25) Kyrgyzstan 42) Syria
9) China 26) Laos 43) Taiwan
10) Cyprus 27) Lebanon 44) Tajikistan
11) East Timor 28) Macau 45) Thailand
12) Georgia 29) Malaysia 46) Turkmenistan
13) Hong Kong 30) Mongolia 47) United Arab Emirates
14) India 31) Myanmar (Burma) 48) Uzbekistan
15) Indonesia 32) Nepal 49) Vietnam
16) Iran 33) Oman 50) Yemen
17) Iraq 34) Pakistan
##选择所在国家
#? 9
Please select one of the following time zone regions.
1) east China - Beijing, Guangdong, Shanghai, etc.
2) Heilongjiang (except Mohe), Jilin
3) central China - Sichuan, Yunnan, Guangxi, Shaanxi, Guizhou, etc.
4) most of Tibet & Xinjiang
5) west Tibet & Xinjiang
##选择所在城市区域
#? 1

The following information has been given:

China
east China - Beijing, Guangdong, Shanghai, etc.

Therefore TZ='Asia/Shanghai' will be used.
Local time is now: Sat Aug 13 19:32:00 CST 2011.
Universal Time is now: Sat Aug 13 11:32:00 UTC 2011.
Is the above information OK?
1) Yes
2) No
##确认修改
#? 1

You can make this change permanent for yourself by appending the line
TZ='Asia/Shanghai'; export TZ
to the file '.profile' in your home directory; then log out and log in again.

Here is that TZ value again, this time on standard output so that you
can use the /usr/bin/tzselect command in shell scripts:
Asia/Shanghai

至此，时区修改完成。

不过我打印了下"date"好像还是没有即时生效？！
又查了下，看来只好手动改了~

首先，删除位于/etc 下的localtime 文件。
rm -rf /etc/localtime

之后，创建一个同名的软连接到/usr/share/zoneinfo/Asia 下的Shanghai文件。
ls -s /etc/localtime /usr/share/zoneinfo/Asia/Shanghai

即可。

查看效果：
[root@PowerPC ~]# ls /etc/local* -lh
lrwxrwxrwx 1 root root 33 Aug 13 19:41 /etc/localtime -> /usr/share/zoneinfo/Asia/Shanghai
[root@PowerPC ~]# date
Sun Aug 21 17:14:19 CST 2011
[root@PowerPC ~]# date -u
Sun Aug 21 09:14:21 UTC 2011
[root@PowerPC ~]#

看，这样一来，时区立马生效了~

不过，系统的时区是改过来了，nginx的时区好像还是UTC.这是肿么回事？

难道要重启生效？ killall nginx 杀死nginx进程
再启动，问题依旧。

难道要在配置文件指定？ 根据nginx官方wiki(地址：http://wiki.nginx.org/CoreModule#env)的说明，在nginx.conf 里加上一句：

# set timezone
env TZ=CST;

重启，还是不行。

在系统变量里添加$TZ为CST,
export TZ="CST"

重启，依旧不行~

杯具~

在以“nginx change timezone”为关键词搜索的时候，看到了nginx 更新日志里面有这么一行：

*) Feature: now nginx takes into account a time zone change while
reconfiguration on FreeBSD and Linux.

难不成nginx只会在编译时候才会读取系统时区？以后要改变时区只能重新编译？？？！！

至于你们信不信，反正我是不信~囧rz

针对这个问题，我已经在nginx的官方邮件列表提问了(地址见:http://mailman.nginx.org/pipermail/nginx/2011-August/028562.html),现在只有等官方的回答了~

早在N天前，我的varnish cache就升级到了最新的3.0版本，不过由于我的配置文件一直备份的，所以当我每次编译完新版本的varnish cache 后，新生成的配置文件default.vcl 总是被我删掉的。

不过，每次varnish升级，它的配置语言VCL的标准总是有变化，像这次 2.1 到 3.0 也不例外。

这也就导致了每次升级后，varnish可能会不能启动。用户就得去根据新标准去修改老配置文件了~

这次，2.1到3.0的更新，除了官方给出的不同之处外，
见：https://www.varnish-cache.org/docs/trunk/installation/upgrade.html#upgrading-from-varnish-2-1-to-3-0

最大的不同就是增加了"+"这个连接符，而我以前配置文件里连接字符的地方会全部报错，尤其是vcl_error 这个sub块。

为了方便启动，我之前把里面所有的变量都删掉了，直接打印给客户端"ERROR".不过考虑到这样实在是不方便用户排查原因。故而打算，写的更详细一点，就像以前一样~

于是我在varnish cache 的trac(地址：https://www.varnish-cache.org/trac/browser/bin/varnishd/default.vcl)上找到了最新版本3.0里面的vcl_error 写法，替换掉了我之前的那块.

我把两个都贴出来，以做比较~

之前(2.1)的写法：

sub vcl_error {
    set obj.http.Content-Type = "text/html; charset=utf-8";
    synthetic {"
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title>"} obj.status " " obj.response {"</title>
  </head>
  <body>
    <h1>Error "} obj.status " " obj.response {"</h1>
    <p>"} obj.response {"</p>
    <h3>Guru Meditation:</h3>
    <p>XID: "} req.xid {"</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>
"};
    return (deliver);
}

现在(3.0)的写法：

sub vcl_error {
    set obj.http.Content-Type = "text/html; charset=utf-8";
    set obj.http.Retry-After = "5";
    synthetic {"
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title>"} + obj.status + " " + obj.response + {"</title>
  </head>
  <body>
    <h1>Error "} + obj.status + " " + obj.response + {"</h1>
    <p>"} + obj.response + {"</p>
    <h3>Guru Meditation:</h3>
    <p>XID: "} + req.xid + {"</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>
"};
    return (deliver);
}

编辑完后，保存下。进入varnishadm的控制台，
[root@PowerPC ~]# varnishadm -T 127.0.0.1:2000
CLI connected to 127.0.0.1:2000
200
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,2.6.18-194.8.1.el5.028stab070.5,i686,-sfile,-smalloc,-hcritbit

Type 'help' for command list.
Type 'quit' to close CLI session.

varnish> stop #停止缓存服务器
200
#重新读取新配置文件
varnish> vcl.load one /etc/sysconfig/varnish/varnish/default.vcl
varnish> vcl.load one /etc/sysconfig/varnish/varnish/default.vcl
200
VCL compiled.
varnish> vcl.use one #使用新配置文件
varnish> vcl.use one
200

varnish> start #启动缓存服务器
varnish> start
200
varnish> quit
500
Closing CLI connection

至此，一切完成。
注：话说3.0还增加了vcl_init{} 和 vcl_fini{}两个sub,不知道是做神马用的~

经常玩GNU/Linux的人想必都对权限有一定的认识。因为有些文件/目录是不能或者是不应该被其他用户访问到的，有些文件是不能允许被执行的。这些都是出于对安全的考虑。

在GNU/Linux(其实BSD系列及其他类Unix系统也是)下,总共分为用户(User)、组(Group)、其他(Other)三类。

而它们都同时具有对文件的读取(Read)、写入(Write)以及执行(Execute)三种权限。

比如让一个文件变成只有该文件的所有者有读写权限，组用户有读的权限，其他的无任何权限时候，可以这么写：

chmod u+rw,g+r,o-rwx filename

不过，我个人觉得这个太长了。其实我们有更好的授权的办法，就是我们经常会用到的类似"777"、"775"、"664"之类的umask命令.

现在我就要好好谈谈这个Umask,很多人会知道"777"是最方便的，但是这"777"是怎么来的，包括我在内的一些人不是很清楚。

就像我前一段时间在和我的同事争"000"和"777"哪个权限更大。我当时就不太知道"0"在umask下的具体意思,或者说含义很模糊。所以我有必要搞清楚这一切。

Umask 代表 User Mask,是所有类Unix系统里对文件权限的一种8进制标记。从0到8各代表不同的权限模式。见下：

   0 – no permissions
   1 – execute only
   2 – write only
   3 – write and execute
   4 – read only
   5 – read and execute
   6 – read and write
   7 – read, write and execute

更多信息，参见：http://en.wikipedia.org/wiki/Umask#Octal_umasks

0代表没有权限，1代表可执行权限，2代表可写权限，4代表可读权限。

这是四个元标记。其他权限标记均来自它们四个的组合，比如有读写权限，即为2 + 4 = 6,如果再加上执行的权限的话，就是2 + 4 + 1 = 7。如果给所有人(包括用户，组，其他)完全控制的权限(即读、写、执行)的话，就是传说中的"777"。

这时候，再看之前的提出的所有者读写，组用户只读，其他禁止访问的授权，就简单了。
即

chmod 640 filename

是不是短了很多？呵呵~

继上次修复了crontab路径错误的问题后，我发现我的数据库备份文件夹下还是0个文件~

这到底是肿么了？

经过排查，我初步认为是我命令脚本里的"data +%s" 在作怪，因为有很多人说cron 里不支持 百分比"%" 这样的符号，需要进行转义(就像正则里一样~)。

所以，我的crontab 脚本变成了这样：

[root@PowerPC ~]# crontab -l
0 0 * * * root /usr/local/bin/mysqldump -A -C -u dumper | bzip2 -9 > /home/ftp/xzx/sql/mysql_`date +\%s`.sql.bz2

之后，为了方便调试，我把任务执行周期改为了一分钟一次。

果然，文件出现了~可是问题又来了，所有的数据包就是0字节。这是神马原因呢？

难道是因为权限不够？

我干脆用root身份去备份试试看~ 我把命令改成这样：

[root@PowerPC ~]# crontab -l
* * * * * root /usr/local/bin/mysqldump -A -C -uroot -pXXXXX | bzip2 -9 > /home/ftp/xzx/sql/mysql_`date +\%s`.sql.bz2

很遗憾，还是不行。依然0字节。

这个时候，我忽然觉得在命令前面加上root,重复去指定脚本执行用户可能是个错误。我删掉了root,当然也换回了默认备份数据库用户dumper,脚本如下：

[root@PowerPC ~]# crontab -l
* * * * * /usr/local/bin/mysqldump -A -C -u dumper | bzip2 -9 > /home/ftp/xzx/sql/mysql_`date +\%s`.sql.bz2

果然，这次成功了~见下：

[root@PowerPC ~]# ls /home/ftp/xzx/sql -lh
total 2.8M
-rw------- 1 root root 707K Aug 6 15:58 mysql_1312631881.sql.bz2
-rw------- 1 root root 707K Aug 6 15:59 mysql_1312631941.sql.bz2
-rw------- 1 root root 707K Aug 6 16:00 mysql_1312632001.sql.bz2
-rw------- 1 root root 707K Aug 6 16:01 mysql_1312632061.sql.bz2

恩，707Kb，这才是我想要的~

最终脚本如下,仅供参考：

[root@PowerPC ~]# crontab -l
0 0 * * * /usr/local/bin/mysqldump -A -C -u dumper | bzip2 -9 > /home/ftp/xzx/sql/mysql_`date +\%s`.sql.bz2

1 0 * * * chmod go-rwx /home/ftp/xzx/sql/*