cssh在打开多窗口后， 会有个重排窗口使之不重叠的功能， 之前在gnome下用很正常， 但现在换到KDE， 却发现重排后依然没变化，乱且重叠了。搜了下，还真没找到啥解决方法， 想想cssh是perl写的， 就硬着头皮看看， 希望能解决这个小问题

稍微看了下函数， 发现有个与窗口重排有关的send_resizemove， 从函数名应该可以猜到它的作用。 整个cssh中， 只有一处地方调用了这函数. 大概在1367行。

        logmsg( 2, "Moving $server window" );
        send_resizemove(
            $servers{$server}{wid},
            $current_x, $current_y,
            $config{internal_terminal_width},    #该参数指定了重排时窗口的新宽度
            $config{internal_terminal_height}    #该参数指定了重排时窗口的新高度
        );

我修改了代码中最后两个参数， 并打开logmsg的调试信息， 希望能找到无法重排及重新调整窗口大小的问题。 写死了新的窗口大小， 但出来的结果却是只有最后一个窗口会改变大小， 其他窗口都没变化， 这倒很有意思， 不是send_resizemove无法起作用， 而是无法在全部窗口起作用。

Tiling top left going bot right
x:5 y:5, r:0 c:0
Moving 15.238.122.15  window
Moving window 65011726 to x:5 y:5 (size x:488 y:242)
x:498 y:5, r:0 c:1
Moving 15.238.122.16  window
Moving window 88080398 to x:498 y:5 (size x:488 y:242)
x:991 y:5, r:0 c:2
Moving 15.238.122.17  window
Moving window 75497486 to x:991 y:5 (size x:488 y:242)
x:1484 y:5, r:0 c:3
Moving 15.238.122.18  window
Moving window 62914574 to x:1484 y:5 (size x:488 y:242)
x:1977 y:5, r:0 c:4
Moving 115.238.122.19  window
Moving window 83886094 to x:1977 y:5 (size x:488 y:242)
x:2470 y:5, r:0 c:5
Moving 15.238.122.20  window
Moving window 92274702 to x:2470 y:5 (size x:488 y:242)
x:5 y:252, r:1 c:0
Moving 15.238.122.22  window
Moving window 77594638 to x:5 y:252 (size x:488 y:242)
x:498 y:252, r:1 c:1
Moving 15.238.122.23  window
Moving window 67108878 to x:498 y:252 (size x:488 y:242)
x:991 y:252, r:1 c:2
Moving 15.238.122.24  window
Moving window 69206030 to x:991 y:252 (size x:488 y:242)
x:1484 y:252, r:1 c:3
Moving 15.238.122.25  window
Moving window 73400334 to x:1484 y:252 (size x:488 y:242)
x:1977 y:252, r:1 c:4
Moving 15.238.122.26  window
Moving window 71303182 to x:1977 y:252 (size x:488 y:242)
x:2470 y:252, r:1 c:5
Moving 15.238.122.27  window
Moving window 81788942 to x:2470 y:252 (size x:488 y:242)
x:5 y:499, r:2 c:0
Moving 15.238.122.29  window
Moving window 79691790 to x:5 y:499 (size x:488 y:242)
x:498 y:499, r:2 c:1
Moving 15.238.122.20  window
Moving window 94371854 to x:498 y:499 (size x:488 y:242)
x:991 y:499, r:2 c:2
Moving 15.238.122.21  window
Moving window 90177550 to x:991 y:499 (size x:488 y:242)
x:1484 y:499, r:2 c:3
Moving 15.238.122.22  window
Moving window 96469006 to x:1484 y:499 (size x:488 y:242)
x:1977 y:499, r:2 c:4
Moving 15.238.122.23  window
Moving window 85983246 to x:1977 y:499 (size x:488 y:242)
x:2470 y:499, r:2 c:5
Moving 15.238.122.24  window
Moving window 111149070 to x:2470 y:499 (size x:488 y:242)
Setting focus on 15.238.122.24
Setting focus on 15.238.122.23
Setting focus on 15.238.122.22
Setting focus on 15.238.122.21
Setting focus on 15.238.122.20
Setting focus on 15.238.122.29
Setting focus on 15.238.122.27
Setting focus on 15.238.122.26
Setting focus on 15.238.122.15
Setting focus on 15.238.122.24
Setting focus on 15.238.122.23
Setting focus on 15.238.122.22
Setting focus on 15.238.122.20
Setting focus on 15.238.122.19
Setting focus on 15.238.122.18
Setting focus on 15.238.122.17
Setting focus on 15.238.122.16
Setting focus on 15.238.122.15
Sending console to front

这是cssh的调试信息中与窗口重排相关的部分， 最后的Setting focus 提示了我， 当前是重排所有窗口后， 再把焦点逐个定位到每个窗口(相当于鼠标点中的窗口状态)， 是否在KDE下没有做这一步就无法调整大小? 根据Setting focus， 我找到了cssh中 相关的代码

    # Now remap in right order to get overlaps correct
    if ( $config{window_tiling_direction} =~ /right/i ) {
        foreach my $server ( reverse(@hosts) ) {
            logmsg( 2, "Setting focus on $server" );
            $xdisplay->req( 'MapWindow', $servers{$server}{wid} );

            # flush every time and wait a moment (The WMs are so slow...)
            $xdisplay->flush();
            select( undef, undef, undef, 0.1 );    # sleep for a mo
        }
    }
    else {
        foreach my $server (@hosts) {
            logmsg( 2, "Setting focus on $server" );
            $xdisplay->req( 'MapWindow', $servers{$server}{wid} );

            # flush every time and wait a moment (The WMs are so slow...)
            $xdisplay->flush();
            select( undef, undef, undef, 0.1 );    # sleep for a mo
        }
    }

不难看出， ‘$xdisplay->req( ‘MapWindow’, $servers{$server}{wid} );’ 这一句就是我要的， $servers{$server}{wid} 就是窗口的ID, 依葫芦画瓢， 我加了这么一句到send_resizemove的函数调用之前

       logmsg( 2, "Moving $server window" );
       $xdisplay->req( 'MapWindow', $servers{$server}{wid} );
        send_resizemove(
            $servers{$server}{wid},
            $current_x, $current_y,
            $config{internal_terminal_width},    #该参数指定了重排时窗口的新宽度
            $config{internal_terminal_height}    #该参数指定了重排时窗口的新高度
        );

很幸运的， 确实如我所想， 终于能在KDE下正确重排窗口了！！

1.重定向输入输出，目标是文件word

[n]<word    默认n为0
[n]>word    默认n为1
[n]>|word   默认n为1    noclobber选项有关，直接例子就明白它的用处了
[n]>>word   默认n为1

igi@igi-debian:~$ rm -f testfile
igi@igi-debian:~$ touch testfile
igi@igi-debian:~$ cat testfile
igi@igi-debian:~$ set -o noclobber
igi@igi-debian:~$ echo 2 >testfile
bash: testfile: cannot overwrite existing file
igi@igi-debian:~$ echo 2 >| testfile
igi@igi-debian:~$ cat testfile
2

2.重定向标准错误和标准输出到指定文件描述符

&>word      更通用
>&word
>word 2>&1

追加输出

&>>word     没有>>&word的表达方法
>>word 2>&1

3.Here Documents

 <<[-]word
   here-document
delimiter
-符号将删除所有行开头的tab符

4.Here Strings

<<<word

5.复制文件描述符

[n]<&word   默认n为0，如果为数字，必须得为打开的文件描述符
[n]<&-      关闭文件描述符

[n]>&word   默认n为1，如果为数字，必须得为打开的文件描述符
[n]>&-      关闭文件描述符

6.移动文件描述符

[n]<&digit- 默认n为0
[n]>&digit- 默认n为1

7.以读写方式打开文件描述符

[n]<>word   文件不在时会被创建

如果要深刻理解重定向，先要明白以下2点
1.shell(bash或者csh等)负责重定向，对于程序或者函数，这一切都是透明的，它只管输入输出，至于从哪输入哪输出，是shell解释器负责
2.shell命令解析过程中，在实际执行命令前，IO重定向先设置好

我们来看以下的例子

1.’echo 1 a1 >a2′ 与 ‘echo 1 >a2 a1′

igi@igi-debian:~$ echo 1 a1 >a2
igi@igi-debian:~$ cat a2
1 a1
igi@igi-debian:~$ rm a2
igi@igi-debian:~$ echo 1 >a2 a1
igi@igi-debian:~$ cat a2
1 a1

IO重定向是在命令执行前设置好，所以上面两种情况，最后的效果一样，bash先把输出重定向到a2文件，再执行’echo 1 a1′

2.’ls nothisfile >res 2>&1′ 与 ‘ls nothisfile 2>&1 >res’

igi@igi-debian:~/rtest$ ls nothisfile
ls: cannot access nothisfile: No such file or directory
igi@igi-debian:~/rtest$ ls nothisfile >res 2>&1
igi@igi-debian:~/rtest$ cat res
ls: cannot access nothisfile: No such file or directory
igi@igi-debian:~/rtest$ ls nothisfile 2>&1 >res
ls: cannot access nothisfile: No such file or directory
igi@igi-debian:~/rtest$ cat res
igi@igi-debian:~/rtest$ ls -1
a
b
c
res
igi@igi-debian:~/rtest$ ls -1 2>&1 >res
igi@igi-debian:~/rtest$ cat res
a
b
c
res

‘ls nothisfile >res 2>&1′，文件描述符1被重定向到文件res(本来是标准输出)，然后再把文件描述符2重定向到文件描述符1(此时是文件描述符1指向文件res)，最后执行”ls nothisfile”，产生错误，被送往文件描述符2，最后流向文件res。
‘ls nothisfile 2>&1 >res’，文件描述符2被重定向到文件描述符1(即标准输出：屏幕)，然后再把文件描述符1重定向到文件res，结果是文件描述符2被重定向到标准输出，文件描述符1被重定向到文件res，最后执行”ls nothisfile”产生的错误就被送往屏幕。

3.’ls nothisfile a >&word’ 与 ‘ls nothisfile a >&123456′

igi@igi-debian:~/test/shell$ ls -1
a
igi@igi-debian:~/test/shell$ cat a
this is a
igi@igi-debian:~/test/shell$ ls nothisfile a >&word
igi@igi-debian:~/test/shell$ cat word
ls: cannot access nothisfile: No such file or directory
a
igi@igi-debian:~/test/shell$ ls nothisfile a >&123456
-bash: 123456: Bad file descriptor
igi@igi-debian:~/test/shell$ cat 123456
cat: 123456: No such file or directory

>&这个重定向符号，在前面有提到，“重定向标准错误和标准输出到指定文件描述符“ 和 “复制文件描述符“ 都有这个符号, 实际上“重定向标准错误和标准输出到指定文件描述符“ 是 “复制文件描述符“ 的一种特别情况， 即当 [n]>&word 的n省略 且 word不是数字时， 会重定向标准错误和标准输出 到指定文件。
“ls nothisfile a >&word” , 由于word不是纯数字， bash解析成 ”重定向标准错误和标准输出到指定文件描述符“， 效果相当于 ” ls nothisfile a >word 2>&1″
“ls nothisfile a >&123456″, 由于123456是纯数字， bash解析成 “复制文件描述符”, 相当于 ” ls nothisfile a 1>&123456″ , 但由于 “ 复制文件描述符 “规定　“如果为数字，必须得为打开的文件描述符”
所以发生了错误。

4.’ls a 1>&-’ 与 ‘ ls a >&1- ‘

igi@igi-debian:~/test/shell$ ls
a
igi@igi-debian:~/test/shell$ cat a
this is a
igi@igi-debian:~/test/shell$ ls a >&1-
a
igi@igi-debian:~/test/shell$ ls a 1>&-
ls: write error: Bad file descriptor

“ ls a >&1- “，　>&1-属于“移动文件描述符” 提到的 “[n]>&digit-”, 用文件描述符digit替换掉文件描述符n, n描述符被关闭.n默认为1. “ls a >&1-”, 相当与 ” ls a 1>&1- “, 把文件描述符1替换掉原
文件描述符1, 然后关闭原文件描述符1, 没发生变化, 输出依然被送到屏幕
” ls a 1>&- “, >&- 属于 “复制文件描述符” 提到的”关闭文件描述符”, ” ls a 1>&- “, 关闭了文件描述符1, 在运行” ls a”, 由于输出默认都送到文件描述符1, 而它被关闭, 报”错误的文件描述符”

5.’ls a nothisfile 1>&2-’ 与 ‘ ls a nothisfile 1<&2- '

igi@igi-debian:~/test/shell$ ls -1
a
igi@igi-debian:~/test/shell$ ls a nothisfile 1<&2-
a
igi@igi-debian:~/test/shell$ ls a nothisfile 1>&2-
a
igi@igi-debian:~/test/shell$ exec 3<>test
igi@igi-debian:~/test/shell$ ls a nothisfile 1>&3-
ls: cannot access nothisfile: No such file or directory
igi@igi-debian:~/test/shell$ cat test
a
igi@igi-debian:~/test/shell$

‘ 1>&2- ‘ 与 ‘ 1<&2- ' 是一个效果的, [n]>&digit- 和 [n]<&digit- 这两个移动文件描述符的操作, 都是移动digit 到 n , 区别在n没有指定时, <&digit- 等于 0<&digit-, 而 >&digit- 等于 1>&digit-
移动文件描述符, 就是把描诉符digit的指向给描述符n, 然后关了digit. 例子中的exec很好的解释移动文件描述符的行为, 文件描述符3被定向到文件test, 然后1>&3-, 会使得1也定向到3所定向的文件test, 然后文件描诉符3被关闭, 效果就是标准输出被定向到test文件.

apt-get remove的行为我们很好理解，就是删除某个包的同时，删除依赖于它的包
例如： A 依赖于 B, B 依赖于 C
apt-get remove 删除B的同时，将删除A(很好理解，A依赖于B，B被删了，A也就无法正常运行了)

先说明下apt-get autoremove与aptitude remove是一样的效果的, 我们先了解下这两者的瓜葛

apt-get一开始并没有记录auto-install的信息
在apt(0.6.44.2exp1)此版本时(06年)，apt-get增加了类似于aptitude的auto-install记录(/var/lib/apt/extended_states).
此后，aptitude在版本0.4.5.1(07年)转向使用apt-get的auto-install记录，而抛弃了自己原先的记录方式
再随后apt-get在版本0.7.7(07年)增加了autoremove的选项

依赖关系是一个复杂而交错的链条，我们把举几个例子来看看它们的行为

以下图中， 绿色圆是为了满足依赖关系而apt-get或aptitude自动安装上的包
蓝色圆是管理员使用apt-get install 或 aptitude install
指定安装的包，简称为手动安装的包

例子1:
1. C 依赖于或推荐B软件包(apt-get和aptitude在安装软件时除了安装必要的依赖包，默认也会安装Recommends关系的包)
2. B 依赖于或推荐A, A被其他手动安装的包依赖

apt-get remove C         将删除C, 同时提示你用apt-get autoremove去清除B
apt-get autoremove C     将删除B, C
aptitude remove C        将删除B, C

我的理解: 删除C, 那么B这个包既是自动安装的,且没有其他手动安装的包依赖于它,
则可以判定B也是没必要的

例子2:
1. 在例子1的基础上, D 依赖于或者推荐B, 且D没有被其他手动安装的包依赖
这样的情况一般出现在用apt-get remove 某个手动安装的包之后.

apt-get remove C         将删除C, 同时提示你用apt-get autoremove去清除B,D
apt-get autoremove C     将删除B, C, D
aptitude remove C        将删除B, C, D

apt-get remove C         将删除C
apt-get autoremove C     将删除C
aptitude remove C        将删除C

apt-get remove C         将删除C, 同时提示你用apt-get autoremove去清除B
apt-get autoremove C     将删除B, C
aptitude remove C        将删除B, C

现象: test帐号使用key无法登录某ssh服务器, 而同机器下的test2帐号却可以登录, 两个帐号都可以通过密码登录

在排查了所有配置错误的可能后, 初步怀疑test帐号的权限设置出问题

test@client:~$ ls -l ~/.ssh/
-rw------- 1 test test   1675 2010-03-25 15:15 id_rsa

test@server:~$ ls -l ~/.ssh/
-rw-r--r-- 1 test test    396 2010-03-25 15:15 authorized_keys

查看了客户端及服务器端的.ssh目录下的公钥与私钥权限, 可以看出, 并没有问题
私钥必须是600权限, 而公钥至少是644或者更严格的权限, 这都符合, 但依然无法登录

test@server:~$ ls -la ~ | grep -w .ssh
drwxr-xr-x  2 test  test  4.0K 12-23 16:59 .ssh

查看了服务器端的.ssh目录权限, 是755, 也是没问题的, ssh服务器要求在使用key登录时.ssh目录的权限必须是其他用户不可写。
一开始实在想不明为啥test2帐号使用key可以登录,test帐号使用key无法登录, ssh_config和sshd_config在检查了多遍后确实没有问题, 最后在服务器端对比两个帐号的不同时, 发现了可疑的地方

$ls -l /home/
drwxrwxrwx   3 test test 4096 2009-12-31 17:31 test
drwxr-xr-x   6 test2 test2 4096 2010-03-23 15:59 test2

两个帐号的home目录权限不同, test帐号是777, test2帐号是755, 会不会是这里不同导致的? 在服务器端把test目录修改成777后, 解决问题

为啥home目录的权限也会影响ssh的key登录?

ssh服务器的key方式登录对权限要求严格。对于客户端: 私钥必须为600权限或者更严格权限(400), 一旦其他用户可读, 私钥就不起作用(如640), 表现为系统认为不存在私钥
对于服务器端: 要求必须公钥其他用户不可写, 一旦其他用户可写(如660), 就无法用key登录, 表现为:Permission denied (publickey).
同时要求.ssh目录其他用户不可写,一旦其他用户可写(如770), 就无法使用key登录, 表现为:Permission denied (publickey).

但为什么home目录的可写也影响到ssh使用key登录?

我们知道linux下目录也是文件, 目录其他用户可写,代表其他用户可以删除目录里的所有文件或子目录,重命名目录下的所有文件或子目录.
home目录的可写,表示其他用户对.ssh子目录也有改写的权限(删除或重命令),也就导致ssh判断.ssh为其他用户可写, 拒绝使用key登录

import sys
from django.core.management import setup_environ
sys.path.append('/test/web_site/')
import settings
setup_environ(settings)
from mysql.models import *

通过这样，后台其他程序就可以直接通过django与数据库打交道，处理日志的守护进程也是这么做的，但随着运行时间的加长，我发现进程所占用的内存越来越大. 内存泄漏~! 我的程序逻辑并不复杂，唯一有内存泄漏的可能也就是不断重复执行的一个循环，几行代码，但我看了好久也没发现有问题的地方. 而且python的内存管理机制相当自动化，极少有出现内存无法释放的问题，常见的range(n)和交叉引用导致的内存不回收的情况，代码中并没有采用. 这让我十分疑惑

只能硬着头皮调试，几行代码，我就没用啥高级的调试方法，直接一行行的注释掉来观察，最后发现是django的数据库API导致的.如

from mysql.models import test_log as logtable
p=logtable(times=valuedic['times']，ipadd=valuedic['ipadd'])
p.save()

在p.save()，把数据插入数据库后，这一部分的内存就不会释放了，加上del p 或者p = None都无济于事. 搜来搜去也没发现其他人有遇到类似的问题，幸福的是最后我还是在一篇e文中找到了点线索

原文地址:http://blog.webfaction.com/tips-to-keep-your-django-mod-python-memory-usage-down

文中第一条就提到:Make sure that you set DEBUG to False in settings.py，在DEBUG模式下，所有的SQL查询都会被保存在内存中.
我顿时想起，由于我整个项目还在调试阶段，这个DEBUG变量是设置为True的

DEBUG设置为False后，内存泄漏的问题就不复存在了

可我整个项目还需要调试，不能就这么简单的关闭DEBUG模式，怎么办? 我一开始想在后台模块import settings后再重新设置DEBUG变量

import sys
from django.core.management import setup_environ
sys.path.append('/test/web_site/')
import settings
settings.DEBUG = False
setup_environ(settings)
from mysql.models import *

可经过测试，这样做并无法生效，怎么回事? 原来setup_environ时把整个模块都传过去了，这样的方法行不通.

最后我用了折衷的方法， copy一份settings，等项目完工后，再把原settings的DEBUG关闭就可以了

import sys
from django.core.management import setup_environ
sys.path.append('/test/web_site/')
import settings_for_db as settings
setup_environ(settings)
from mysql.models import *

之所以标题用引号，因为这只是一个DEBUG模式下django的特性，不是真正的内存泄漏.

记得一开始的学校那个服务器跑的是win 2003，用xlight提供ftp服务，为了便于管理，给系统装上了cygwin。在一开始摸索中，尝试过lftp脚本去同步镜像源，但lftp必须所有文件都扫描一次，长时间的空闲连接就被服务器踢掉了。后来才知道普遍的做法是用rsync去同步，在debian网站上提供了一个写的比较完善的rsync脚本。 该脚本提供了文件锁,进程锁等完善的处理，稍微修改就非常合适用来同步各镜像源

空间需求

对于镜像服务器，基本上是IO密集型， 对磁盘空间需求很大，如果只需要提供常用的i386,amd64两种架构的软件包及常用版本

fedora需要300G左右
ubuntu需要250G左右
debian需要250G左右
gentoo需要100G左右
archlinux需要50G左右
centos需要150G左右
cygwin需要10G左右

除此之外,还需要预留一定空间以保证不被新发布的版本或者大软件包塞爆硬盘。

同步选择

一般来说，除非你服务器的空间几乎无限，不然就得考虑排除没必要的架构和版本。以debian为例
debian现有alpha、amd64、arm、armel、hppa、hurd-i386、i386、ia64、m68k、mipsel、mips、powerpc、s390、sh and sparc这么多架构的软件包，还有source代码包
debian现有oldstable，stable，testing，unstable，还有experimental版本的
如此多的架构和版本，我们要根据需要进行排除，rsync的exclude选项可以很好的完成这个任务，有时遇到服务器端有问题的文件或者目录,也可以通过exclude选项跳过去。

确定好需要同步的架构及版本后，就需要找寻合适的同步对象，一个发行版一般都有许多个镜像源，但只有部分提供rsync服务，在各自的官方网站一般都可以找到这些列表或者搭建镜像的帮助。镜像源之间是有一定的等级的，一般会有一个总的最高级别的服务器(简称根服务器)，所有新的软件包会现出现在它上面,然后它下级的镜像源再来它这里同步，然后还有下下级的镜像源来同步。如果能直接同步根服务器，那是最好的，因为你能最快获得新的软件包，但由于各种原因，根服务器不一定对所有用户都开放rsync同步服务，而是只允许特定ip列表才能访问其rsync服务(大部分发行版是这么作的)。一般来说，主要是根据访问速度及对方服务器的软件包的滞后程度来选择同步对象，国内开放rsync的开源镜像不多，周边地区速度不错的有台湾和日本的服务器，其他地方的速度就一般

同步策略

根据需要写好rsync脚本后，就需要添加crontab，以保持自动更新，推荐做法是一天更新几次，部分小源可以一天更新一次，如果只想一天更新一次，可以把时间放在深夜，一般规律都是凌晨5,6点访问量最小，在这段时间附近开始更新可以避开负载高峰。

其他

debian系的源，源目录都有pool目录，它存放所有软件包，如果使用了debian的同步脚本，或者在rsync同步时分两步,先同步这个目录,同步完成后再同步其他目录，这样就可以有效的避免服务器同步时其他人访问会有一定几率出错的问题，还有rsync的delete-after及delay-update选项，都可以避免未完成的更新对用户造成影响

贴下我稍微修改及注释的debian那个同步脚本

#! /bin/sh
set -e

# 此脚本由 http://www.debian.org/mirror/anonftpsync 修改而来
# 需要原脚本可以自行下载
# CVS: cvs.debian.org:/cvs/webwml - webwml/english/mirror/anonftpsync
# Version: $Id: anonftpsync,v 1.43 2008-06-15 18:16:04 spaillar Exp $ 

#增加mirror名变量，方便修改log名、lock名、mail信息
MIRROR="opensuse"

RSYNC="/usr/bin/rsync"
TO="/home/mirror/opensuse"
RSYNC_HOST="rsync.opensuse.org"
RSYNC_DIR="opensuse-hotstuff-160gb"
LOGDIR="/home/mirror.scripts/log"

# ARCH_EXCLUDE 控制需要排除的架构的包
# 对于Debian,以下是包含的架构
# alpha, amd64, arm, armel, hppa, hurd-i386, i386, ia64, m68k, mipsel, mips, powerpc, s390, sh and sparc
# 一个比较特殊的值: source
# 它将排除源代码包
# 例子
# ARCH_EXCLUDE="alpha arm armel hppa hurd-i386 ia64 m68k mipsel mips s390 sparc"
#对于opensuse:
#这里应该是: x86_64 i586 i686 noarch source
ARCH_EXCLUDE=

# EXCLUDE变量将排除更多需要排除的包,非得以不建议使用这个变量
# The following example would exclude mostly everything:
#EXCLUDE="\
#  --exclude stable/ --exclude testing/ --exclude unstable/ \
#  --exclude source/ \
#  --exclude *.orig.tar.gz --exclude *.diff.gz --exclude *.dsc \
#  --exclude /contrib/ --exclude /non-free/ \
# "
EXCLUDE=

#mail地址
#同步完成后把log发到指定邮箱,需要修改exim配置
MAILTO=

# LOCK_TIMEOUT是一个时间锁,以分钟为单位,默认锁6小时,即360分钟.
# 脚本运行时将创建lock文件,以保证同时间内只有一个rsync再运行
# 不同同步脚本的lock不能互相影响,以不同文件名区分.
LOCK_TIMEOUT=360

# RSYNC代理设置,一般不需要设置
# RSYNC_PROXY="IP:PORT"
# export RSYNC_PROXY=$RSYNC_PROXY

# 帐号密码设置
# . ftpsync.conf
# export RSYNC_PASSWORD
# RSYNC_HOST=$RSYNC_USER@$RSYNC_HOST

# 检查各个重要变量是否为空
if [ -z "$TO" ] || [ -z "$RSYNC_HOST" ] || [ -z "$RSYNC_DIR" ] || [ -z "$LOGDIR" ] || [ -z "$RSYNC" ]; then
    echo "One of the following variables seems to be empty:"
    echo "TO, RSYNC_HOST, RSYNC_DIR or LOGDIR"
    exit 2
fi

#hostname变量,也可以手工指定
HOSTNAME=hostname -f
# HOSTNAME=mirror.domain.tld

#LOCK文件,绝对路径,建议放在统一目录,便于管理
LOCK="/home/mirror.scripts/lock/$MIRROR-Archive-Update-in-Progress-${HOSTNAME}"

# 临时目录,由rsync --delay-updates 参数决定
# 必须保留,以避免错误,同步时所有新下载的都自动存放在临时目录
TMP_EXCLUDE="--exclude .~tmp~/"

# 架构排除变量的展开语句
#以下是原脚本的,只适用debian系的部分发行版
#for ARCH in $ARCH_EXCLUDE; do
#   EXCLUDE=$EXCLUDE"\
#       --exclude binary-$ARCH/ \
#       --exclude disks-$ARCH/ \
#       --exclude installer-$ARCH/ \
#       --exclude Contents-$ARCH.gz \
#       --exclude Contents-$ARCH.diff/ \
#       --exclude arch-$ARCH.files \
#       --exclude arch-$ARCH.list.gz \
#       --exclude *_$ARCH.deb \
#       --exclude *_$ARCH.udeb "
#   if [ "$ARCH" = "source" ]; then
#       SOURCE_EXCLUDE="\
#       --exclude source/ \
#       --exclude *.tar.gz \
#       --exclude *.diff.gz \
#       --exclude *.dsc "
#   fi
#done
#以下是为opensuse专门修改的
for ARCH in $ARCH_EXCLUDE; do
    EXCLUDE=$EXCLUDE"\
        --exclude *.$ARCH.rpm"
    if [ "$ARCH" = "source" ]; then
        SOURCE_EXCLUDE="\
        --exclude source/"
    fi
done

#日志文件
LOGFILE=$LOGDIR/$MIRROR-mirror.log
# 可以使用下面的命名方式
# LOGFILE=$LOGDIR/$(echo $RSYNC_DIR | tr / _)-mirror.log
# LOGFILE=$LOGDIR/${RSYNC_DIR/\//_}-mirror.log

cd $HOME
umask 002

# 在第一次运行时创建trace文件,记录每次同步的时间记录
# 只在Debian的镜像中发现有此文件,其他发行版一般不需要
#if [ ! -d "${TO}/project/trace/" ]; then
#  mkdir -p ${TO}/project/trace
#fi

# 判断是否有同一脚本的rsync在运行,可以避免上一同步还没完而起多一个同步进程
if [ -f "$LOCK" ]; then
# Note: this requires the findutils find; for other finds, adjust as necessary
  if [ "find $LOCK -maxdepth 1 -cmin -$LOCK_TIMEOUT" = "" ]; then
# Note: this requires the procps ps; for other ps', adjust as necessary
    if ps ax | grep '[r]'sync | grep -q $RSYNC_HOST; then
      echo "stale lock found, but a rsync is still running, aiee!"
      exit 1
    else
      echo "stale lock found (not accessed in the last $LOCK_TIMEOUT minutes), forcing update!"
      rm -f $LOCK
    fi
  else
    echo "current lock file exists, unable to start rsync!"
    exit 1
  fi
fi

#生成lock
touch $LOCK

# 在部分非debian系统,需要用0代替exit
# 捕捉退出信号,以删除lock
# 脚本结尾也有一句同样效果的,这里起保证异常退出时能删除lock的作用
# 单rsync错误，还是顺序执行到最后的rm,然后再触发这里的trap
# 保证的是父进程的异常退出
trap "rm -f $LOCK" exit

# 我根据需要加的,可在手工运行脚本时,捕捉ctrl+c
# 这样能再按下ctrl+c后继续保存log及删除lock文件
trap "" 2

set +e

# 我根据需要加的,写个时间进log,方便查
date +["Start "%F" "%T] >> $LOGFILE

# debian的原脚本把rsync分两步,先同步poor的内容
# 其他发行版不需要这么做
# timeout参数能在出现io错误时自动结速脚本,而不卡住
# delay-updates参数:先把下载的数据放tmp目录,同步完再移到正确位置
# 必须加此参数,可以避免未同步完的不完整包被用户下载导致错误
# 对于第一次同步，建议增加--size-only及--ignore-existing，以增加同步速度(在经常断开的情况下)
# 对于想删除不需要的exclude文件情况，可以增加--delete-excluded及--force(force用来强制删除空的不必要目录)
$RSYNC --recursive -p --links --hard-links --times \
     --progress \
     --verbose \
     --delay-updates --delete-after \
     --timeout=3600 \
     $TMP_EXCLUDE $EXCLUDE $SOURCE_EXCLUDE \
     $RSYNC_HOST::$RSYNC_DIR $TO/ >> $LOGFILE 2>&1

#chtime.sh用来记录源正常完成更新的时间
if [ $? -eq 0 ]
then
    /home/mirror.scripts/bin/chtime.sh opensuse >> $LOGFILE 2>&1
fi

#写时间进trace文件,非debian系统不需要
#LANG=C date -u > "${TO}/project/trace/${HOSTNAME}"

#写结束时间进log
date +["End "%F" "%T] >> $LOGFILE

#寄送邮件
if [ -n "$MAILTO" ]; then
    mail -s "$MIRROR archive synced" $MAILTO < $LOGFILE
fi

#保存log
savelog $LOGFILE >/dev/null

#最后删除lock文件
rm $LOCK

以下是整个事情的经过

在检查一批新加兼容内存服务器时，　遇到一个错误，不断的刷到屏幕上，而没有加新内存的服务器却正常，首先怀疑新加内存不兼容，报的错误如下

Jan 8 10:17:08 xxx kernel: [506809.272631] EDAC i5000 MC0: FATAL ERRORS Found!!! 1st FATAL Err Reg= 0x4
Jan 8 10:17:08 xxx kernel: [506809.272668] EDAC i5000 MC0: >Tmid Thermal event with intelligent throttling disabled
Jan 8 10:17:08 xxx kernel: [506809.272722] EDAC MC0: UE row 3，channel-a= 0 channel-b= 1 labels "-": (Branch=0 DRAM-Bank=2 RDWR=Write RAS=9879 CAS=0 FATAL Err=0x4)
Jan 8 10:17:09 xxx kernel: [506811.737687] EDAC i5000 MC0: FATAL ERRORS Found!!! 1st FATAL Err Reg= 0x4
Jan 8 10:17:09 xxx kernel: [506811.737724] EDAC i5000 MC0: >Tmid Thermal event with intelligent throttling disabled
Jan 8 10:17:09 xxx kernel: [506811.737778] EDAC MC0: UE row 1，channel-a= 0 channel-b= 1 labels "-": (Branch=0 DRAM-Bank=0 RDWR=Read RAS=11057 CAS=0 FATAL Err=0x4)

故障分析

EDAC是内核监控ECC内存状态的模块
i5000是Intel内存控制器
这个错误信息从字面理解是温度过高，而智能调节也没打开产生的告警，在Intel的资料里有提到此信息
第208页，3.22.1
http://www.intel.com/Assets/PDF/datasheet/313071.pdf

故障可能原因

1.新内存散热性能不佳产生报警
2.新内存与BIOS不兼容，触发了EDAC模块与BIOS的冲突

故障解决方法

1.最好就是换掉有问题的内存
2.如果实在负载不高，那也可以考虑下屏蔽这个报警，不过这个只是让它不报警，实际问题依然存在，依然存在风险
由于EDAC只是起监控功能，且BIOS本身也有自己的内存监控，可通过屏蔽EDAC来屏蔽这个错误

在/etc/modprobe.conf添加以下字段
blacklist i5000_edac

不加载edac后，再测试内存，不报警，暂时表现正常，但不能排除依然存在内存过热等或不兼容情况对服务造成影响.

参考资料:
1.https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276444
2.http://forums.oracle.com/forums/thread.jspa?threadID=890202&tstart=0
3.https://bugzilla.novell.com/show_bug.cgi?id=418116
4.http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/edac/i5000_edac.c
5.http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.3/html/Release_Notes/sect-Release_Notes-Known_Issues.html
6.http://www.intel.com/Assets/PDF/datasheet/313071.pdf

以下是RH网站提供的方法
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.3/html/Release_Notes/sect-Release_Notes-Known_Issues.html

如果EDAC模块被加载，BIOS的内存报告功能将失效，因为EDAC模块清除了寄存器里的信息，导致BIOS获取不到有关内存错误的信息
如果想打开BIOS的内存报告功能，需要阻止EDAC模块的加载，把以下信息添加到/etc/modprobe.conf:
blacklist edac_mc
blacklist i5000_edac
blacklist i3000_edac
blacklist e752x_edac

出于方便移植的考虑，我抛弃了wordpress的默认数据库mysql，改用了sqlite，需要安装pdo-for-wordpress, 倒也简单，php5默认就有pdo模块，需要另外装的就是php5-sqlite吧。

折腾好了后，再捣鼓捣鼓主题和页面设置，我的blog就人模人样拉。不过总觉得慢，200ms的延时，但访问时apache进程总是有几秒钟处于D状态，我的vps倒也没什么负载，我怀疑是真实主机的io太高导致的，没办法，只能自己尽量提高自己blog的速度了。

搜了下，有个国人写的加速插件cos-html-cache，原理就是把生成一份静态html来提高速度吧，看起来不错，我就装上了，确实速度有些许提高，还是有点欣慰的。

以后就得多写写心得。

附：整个过程还是遇到不少小问题的
1.Warning: implode() [function.implode]: Invalid arguments passed in /wp-includes/post.php
发生在我定义新页面时，搜了下，还不少人遇到，也有别人提供的解决方法
编辑/wp-includes/post.php

把以下语句

$check_sql = "SELECT post_name FROM $wpdb->posts WHERE post_name = %s AND post_type IN ( '" . implode("', '", $wpdb->escape($hierarchical_post_types)) . "' ) AND ID != %d AND post_parent = %d LIMIT 1";

改为

$hierarchical_post_types_string = implode("', '", $hierarchical_post_types);
$hierarchical_post_types_string = addslashes($hierarchical_post_types_string);
$check_sql = "SELECT post_name FROM $wpdb->posts WHERE post_name = %s AND post_type IN ( '" . $hierarchical_post_types_string . "' ) AND ID != %d AND post_parent = %d LIMIT 1";

出自:http://wordpress-hacks.com/warning-implode-function-implode-invalid-arguments-passed-in-wp-includespost-php-on-line-1762.php

2..htaccess: RewriteEngine not allowed here

开启了伪静态urls后，访问时就出现500错误，看了下error-log,提示.htaccess: RewriteEngine not allowed here
先确定了Rewrite模块在apache加载了，后来还是搜到了答案，编辑apache配置，在对应的vhost中修改AllowOverride FileInfo

附上AllowOverride的文档

AllowOverride 指令
说明    确定允许存在于.htaccess文件中的指令类型
语法    AllowOverride All|None|directive-type [directive-type] ...
默认值  AllowOverride All
作用域  directory
状态    核心(C)
模块    core

当服务器发现一个.htaccess文件(由AccessFileName指定)时，它需要知道在这个文件中声明的哪些指令能覆盖在此之前指定的配置指令。
仅允许存在于<Directory>配置段
AllowOverride仅在不包含正则表达式的<Directory>配置段中才是有效的。在<Location>, <DirectoryMatch>, <Files>配置段中都是无效的。

如果此指令被设置为None ，那么.htaccess文件将被完全忽略。事实上，服务器根本不会读取.htaccess文件。

当此指令设置为 All时，所有具有".htaccess"作用域的指令都允许出现在.htaccess文件中。

directive-type可以是下列各组指令之一：

AuthConfig
    允许使用与认证授权相关的指令(AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, 等)。
FileInfo
    允许使用控制文档类型的指令(DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, mod_mime中的 Add* 和 Remove* 指令等等)、控制文档元数据的指令(Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName)、mod_rewrite中的指令(RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule)和mod_actions中的Action指令。
Indexes
    允许使用控制目录索引的指令(AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, 等)。
Limit
    允许使用控制主机访问的指令(Allow, Deny, Order)。
Options[=Option,...]
    允许使用控制指定目录功能的指令(Options和XBitHack)。可以在等号后面附加一个逗号分隔的(无空格的)Options选项列表，用来控制允许Options指令使用哪些选项。

例如以下指令只允许在.htaccess中使用AuthConfig和Indexes组的指令：

AllowOverride AuthConfig Indexes

不在这两组中的指令将会导致服务器产生一个内部错误。