Varnish Cache 升级到3.0后配置文件的改动 

早在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的控制台,
[[email protected] ~]# 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,不知道是做神马用的~
[ ] ( 2951 次浏览 ) 永久链接 ( 3 / 2030 )
深入了解 GNU/Linux下的权限Umask 

经常玩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


是不是短了很多?呵呵~
[ ] ( 1893 次浏览 ) 永久链接 ( 3.1 / 1957 )
还是Crontab 的那些事 

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

这到底是肿么了?

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

所以,我的crontab 脚本变成了这样:

[[email protected] ~]# 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身份去备份试试看~ 我把命令改成这样:

[[email protected] ~]# 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,脚本如下:

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

果然,这次成功了~见下:

[[email protected] ~]# 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,这才是我想要的~

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

[[email protected] ~]# 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/*
[ ] ( 1669 次浏览 ) 永久链接 ( 3.1 / 2203 )
Crontab 不起作用原因之排查 

前段时间,由于对数据的重视程度的增加,我曾启用了crontab 以在每晚0点时对数据库进行整体备份。

今天,我无意中打开了存放数据库备份文件的目录,可是里面却什么也没有~这是怎么回事??

难道crontab 没有起作用?

难道是我的命令格式写错了?首先,我去查看了下crontab的格式,前面是时、分、月、日、周,后面是具体shell命令。我的如下:
[[email protected] ~]# crontab -l
0 0 * * * mysqldump -A -C -u dumper | bzip2 -9 > /home/ftp/xzx/sql/mysql_`date +%s`.sql.bz2

0 0 * * * chmod go-rwx /home/ftp/xzx/sql/*
应该说不存在问题。

难道是我的crontab 服务没有启动??不会吧~
[[email protected] ~]# ps -e | grep cron
20364 ? 00:00:00 crond

很显然,已经启动了~

那是尼玛神马问题呢?我以"crontab not work" 为关键字在谷歌上搜索了一下,得到了一些提示。

首先,看看位于/etc下的cron.deny文件里面,是不是有我的用户名 root.
我看了下,木有~ 该文件为空。

接着,我索性把/etc下所有crontab相关的配置文件都找了出来,

[[email protected] ~]# find /etc -name "cron*"
/etc/cron.d
/etc/cron.monthly
/etc/rc.d/init.d/crond
/etc/cron.daily
/etc/sysconfig/crond
/etc/pam.d/crond
/etc/cron.hourly
/etc/cron.deny
/etc/crontab
/etc/cron.weekly

看到cron.hourly/daily/weekly/monthly/ 我内牛满面~

当我打开 /etc/crontab 的时候,有一行配置惊醒了我,那就是 PATH 这行,原来crontab 默认不使用 /usr/local/bin 、/usr/local/sbin 这些作为PATH,

果断查看mysqldump 所在 :
[[email protected] ~]# which mysqldump
/usr/local/bin/mysqldump

囧rz.

原来这么多天,crontab一直在报 "command not found"....

修改后的crontab:

[[email protected] ~]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
MAILTO=root
HOME=/

# run-parts
#23 * * * * root run-parts /etc/cron.hourly
#50 0 * * * root run-parts /etc/cron.daily
#31 5 * * 0 root run-parts /etc/cron.weekly
#11 0 27 * * root run-parts /etc/cron.monthly


当然,还有种解决方案,就是写绝对路径~
[ ] ( 1501 次浏览 ) 永久链接 ( 2.9 / 2088 )
更换 AVD版本后测试Android 程序出现的错误 

最近在写一个小的Android程序的时候,由于之前是2.3的AVD,更换为2.2后,启动debug,AVD报错了~ 如下:


[2011-06-19 16:49:52 - HelloAndroid] Re-installation failed due to different application signatures.
[2011-06-19 16:49:52 - HelloAndroid] You must perform a full uninstall of the application. WARNING: This will remove the application data!
[2011-06-19 16:49:52 - HelloAndroid] Please execute 'adb uninstall org.xzx.helloandroid' in a shell.
[2011-06-19 16:49:52 - HelloAndroid] Launch canceled!


怎么都运行不了~看来得自己手动卸载,重装了~
得先找到 adb 的所在。

which adb,无果.查找一下,终于在 /usr/local/android-sdk-linux_x86/platform-tools/ 目录下找到了它,晕~这不是我安装android SDK 的地方么~

进入到 /usr/local/android-sdk-linux_x86/platform-tools/ 下,运行:
./adb uninstall xxx.xxx.xxx #具体为程序包名
即可。

再启动debug,一切OK了~

[2011-06-19 16:57:06 - HelloAndroid] Uploading HelloAndroid.apk onto device '040395381401C005'
[2011-06-19 16:57:06 - HelloAndroid] Installing HelloAndroid.apk...
[2011-06-19 16:57:13 - HelloAndroid] Success!

[ ] ( 1792 次浏览 ) 永久链接 ( 3 / 1892 )

<< <上一页 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 下一页> >>