2013年3月

error: unpacking of archive failed on file * MD5 sum mismatch

制作 RPM 压缩算法不一致。一个解决方法是创建一个脚本 /usr/bin/rpmbuild-md5,其内容如下:

 

[code]
#!/bin/bash
rpmbuild --define "_source_filedigest_algorithm 1" \
--define "_binary_filedigest_algorithm 1" \
--define "_binary_payload w9.gzdio" \
--define "_source_payload w9.gzdio" \
--define "_default_patch_fuzz 2" "$@"
[/code]

用 rpmbuild 的时候用 rpmbuild-md5 代替就行了

奇偶校验

信息是以比特流的方式传输的,类似01000001。在传输过程中,有可能会发生错误,比如,我们存储了

01000001,但是取出来却是01000000,即低位由0变成了1。为了检测到这种错误,我们可以通过“奇偶

校验”来实现。假如,我们存储的数据是一个字节,8个比特位,那我们就可以计算每个字节比特位是1的

个数,如果是偶数个1,那么,我们就把第九个位设为1,如果是奇数个1,那么就把第九个位设为0,这

样连续9个字节比特位为1的位数肯定是奇数。这中方法叫做“奇校验”,“偶校验”和此类似。当然,在实

际应用中,也可以把一个字节的前7位作为数据位,最后一个为作为校验位。

CRC 校验的基本过程

采用 CRC 校验时,发送方和接收方用同一个生成多项式 g(x) , g(x) 是一个 GF(2) 多项式,并且 g(x) 的首位和最后一位的系数必须为 1 。

CRC 的处理方法是:发送方用发送数据的二进制多项式 t(x) 除以 g(x) ,得到余数 y(x) 作为 CRC 校验码。校验时,以计算的校正结果是否为 0 为据,判断数据帧是否出错。设生成多项式是 r 阶的(最高位是 x^r )具体步骤如下面的描述。

发送方:

1 )在发送的 m 位数据的二进制多项式 t(x) 后添加 r 个 0 ,扩张到 m+ r 位,以容纳 r 位的校验码,追加 0 后的二进制多项式为  T(x) ;

2 )用 T(x) 除以生成多项式 g(x) ,得到 r 位的余数 y(x) ,它就是 CRC 校验码;

3 )把 y(x) 追加到 t(x) 后面,此时的数据 s(x) 就是包含了 CRC 校验码的待发送字符串;由于 s(x) = t(x) y(x) ,因此 s(x) 肯定能被 g(x) 除尽。

接收方:

1 )接收数据 n(x) ,这个 n(x) 就是包含了 CRC 校验码的 m+r 位数据;

2 )计算 n(x) 除以 g(x) ,如果余数为 0 则表示传输过程没有错误,否则表示有错误。从 n(x) 去掉尾部的 r 位数据,得到的就是原始数据。

CentOS Python2.4升级到Python2.7

应醒哥要求,挂几个python的程序,结果整了一个下午,本来python是2.4的,好像不支持requests

模块.我就升级到python2.7,结果yum又不能用了.下面是完整的解决方案.

Python升级


# yum install gcc gcc-c++.x86_64 compat-gcc-34-c++.x86_64 openssl-devel.x86_64 zlib*.x86_64
# wget http://www.python.org/ftp/python/2.7/Python-2.7.tar.bz2
# tar -xvjf Python-2.7.tar.bz2
# cd Python*
# ./configure --prefix=/opt/python27
# make
# make install
#vi ~/.bash_profile

replace PATH=$PATH:$HOME/bin
with PATH=$PATH:$HOME/bin:/opt/python27/bin

# source ~/.bash_profile
# echo "/opt/python27/lib" > /etc/ld.so.conf.d/python27.conf
# ldconfig

这时候Python已经升级好了,但是默认的Python版本还是2.4.3

# mv /usr/bin/python /usr/bin/python_backup
# ln -s /opt/python27/bin/python /usr/bin/
# python -V
Python 2.7
这个时候yum又不能用了
# vim /usr/bin/yum
#!/usr/bin/python
改成
#!/usr/bin/python2.4

这时候yum修复了,下面就是安装easy_install,pip和requests

# curl -O http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c11-py2.7.egg
# chmod 775 setuptools-0.6c11-py2.7.egg
# sh setuptools-0.6c11-py2.7.egg
# curl -O http://pypi.python.org/packages/source/p/pip/pip-1.0.tar.gz
# tar xvfz pip-1.0.tar.gz
# cd pip-1.0
# python setup.py install
# /opt/python27/bin/easy_install requests

nginx与squid 反向代理的区别

反向代理从传输上可以区分为同步模式和异步模式,apache的mod_proxy和squid都属于同步模式,nginx和lighttpd属于异步模式

同步模式是用户发起请求,请求立即被转到后端的服务器,于是在浏览器和后端服务器之间就建立了一个连接,在请求完成前这个连接是一直存在的。

而异步模式时,用户发起的请求会发送到nginx,nginx接收到所有的数据后在转发到后端的服务器,后端服务器处理完成后把数据返回给nginx,nginx在返回给用户。

由此可见如果用户发起的请求的数据比较大,或者用户端的网速比较慢,同步模式时后端服务器的连接数相对于异步模式会比较多,压力也比较大。

Nginx的cache比较适合处理大文件的,而squid的cache比较适合小文件的cache

Nginx ctrl+F5刷新

nginx添加ctrl+F5强制刷新功能配置

## Ctrl+F5 Cache Purge
if ($http_Cache_Control ~ "no-cache") {
# set $http_Cache_Control 'max-age=604800';
rewrite ^(.*)$ /purge$1 last;
}

git+github使用

1.在github上新建一个Repository,基本信息完成后记下git@github.com:xxx/xxx.git.
2.本地配置
用户名和邮件配置默认会在 ~/.gitconfig

#git config --global user.name "username"
#git config --global user.email wanghuafire@gmail.com

生成key,默认会在/root/.ssh/id_rsa.pub,把里面的所有内容都copy到github的accounting下面的ssh keys里面
#ssh-keygen -C 'wanghuafire@gmail.com' -t rsa

3.提交项目
#cd project_name
#git init
#git commit -m "test"
#git add .
#git remote add user_name git@github.com:xxx/xxx.git
#git push user_name master

user_name可以你自己指定

最初的时候我一直都是需要用户名和密码认证,提交失败,返回403,然后是error,可以修改在你项目目录下./git/config

url = https://github.com/xxx/xxx.git
==修改
url = git@github.com:xxx/xxx.git

然后在你github上git地址采用ssh提交就行了。

更新本地代码之后

#git status # 可以查看当前代码更新后状态,是否提交到仓库里了
#git add .
#git commit -m "test debug"
#git push user_name master

你就可以在github上面看得更改历史了

Nginx Purge清除缓存配置

在编译安装Nginx的时候加上了Purge模块,来清除缓存.

www.firefoxbug.net/index.html ==>> www.firefoxbug.net/purge/index.html就能清除.

但是之前配置过程中出现了404,但是缓存明明是存在的,就是Purge不了.后来更改Purge的配置就OK了

## Cache_proxy Purge
location ~ /purge(/.*) {
	allow all;
	proxy_cache_purge cache_one $host$1$is_args$args;
	#proxy_cache_purge cache_one $host;
	error_page 405 =200 /purge$1;
	}