The Mirages

以前在公司吃加班餐，总喜欢坐在朝西的一个高脚凳上吃，向西看去，群山被夕阳笼罩着，橘红橘红的。感觉这些山都被融化了一样。这种感觉真是让人向往，我不知道加入我被这夕阳笼罩的时候会是怎样。要是每天都生活在这样的场景是多好啊。
坐在300路上，这个北京最著名的公交车上，每天下班都是由东往西开着，上车时候还是夕阳笼罩，等下车的时候是夕阳伴随着橘红色的路灯。回家的路总是走的特别快。
在上海的，经常下班的时候还是天亮的，但是从地铁出来的时候天色已经黑了，也没有那么高可以远眺。在上海都是建筑森林，你根本不可能远眺。

习惯了windows上vmware server，这个东西是免费的，还是挺好用的。看了下发现vmware sever还有linux版本的。下载了vmware server2.0版本的。汗，直接下载的是tar包的，以为也是用

1

./configure && make && make install

来安装的。不过解压开来发现还是给你了一个安装脚本，是一个perl的脚本。5800多行的perl脚本，还好执行效率很高。
全部都是默认安装。安装完成后直接打vmware就可以启动了，不想用https登录，那就用 http://xxxx:8222 登录就可以了。第一次用web登录的，以前windows下都不是web方式的。这里的用户是root，如果你是默认安装的话，密码就是系统的root帐户的秘钥。
安装完成后要进行2个设置，一个是add datastore,这个最好是你自己目录下的分区。还有一个是要安装firefox插件:vmware remote console plug-in。这些设置完成后就跟普通版本的vmware相同方式使用了。
哈哈，下了个gentoo dvd版本用着，真是不错。
linux版本的vmware居然还提供了卸载脚本，真是贴心阿：vmware-uninstall.pl

在urchin显示的内容优化–最常见内容中默认是不带有域名的。例如
www.abc.com/test.html这里就只显示test.html，而万一我有test.abc.com/test.html那我就搞不清楚到底哪个是www子域名下的，哪个是test子域名下的。为了解决问题查看了urchin的帮助文档，居然还有现成的。
https://secure.urchin.com/helpwiki/cn/How_do_I_track_all_of_the_subdomains_for_my_site_in_separate_profiles%3F

 Filter Type: Custom filter > Advanced Field A: cs_host (Raw) Extract A: (.*) Field B: Request_Stem (Auto) Extract B: (.*) Output To: Request_Stem (Auto) Constructor: /$A1$B1 

但是实际使用中却始终无法正常显示出来。为了解决这个问题无奈只好一个个查看urchin各个字段的解释。在http://www.google.com/support/urchin45/bin/answer.py?answer=28623&topic=7396你可以看到所有字段的解释

因为既然urchin能够获取主机名，那这里肯定也是可以显示的。最后解决问题的方法是：

 Filter Type: Custom filter > Advanced Field A: utm_request_hostname (AUTO) Extract A: (.*) Field B: Request_Stem (Auto) Extract B: (.*) Output To: Request_Stem (Auto) Constructor: $A1$B1 

然后必填字段A 选择是，必填字段B选择否，覆盖输出字段选择是，区分大小写选择否。

在linux中我們可以設置密碼最短為多少，只需要修改/etc/login.defs文件中的PASS_MIN_LEN 參數就可以了。
但是最近我發現了另外一個問題，我明明設置了10幾位的密碼，但是最終系統登錄的時候只是查看前面的8位。查找了半天原因，原來是/etc/pam.d/system-auth的問題。
在老的版本默認password居然是使用shadow進行驗證的。而它所使用的算法是DES加密算法，這是一種64位加密算法，只能識別到前面八位。修改方法就是把system-auth修改成如下形式：

 #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session \[success=1 default=ignore\] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so 

這個修改完成后理論上是立刻生效的。但是我在實際使用過程中發現還是要把所有密碼重新設置一遍才會生效。
其實也可以通過修改/etc/pam.d/login來解決的，但是很多pam其實最終都是調用的system-auth的，所以修改system-auth還是一個比較好的方式。

最近由於升級服務並且涉及到域名的更改，架構也同時進行升級。
首先碰到的一個問題，用戶在輸入老的域名比如www.abc.com，雖然我在DNS上做了CNAME, www IN CNAME www.cba.com.
但是用戶在輸入www.abc.com后在流覽器地址欄中還是原來的www.abc.com，雖然也能正常訪問新網站，但是這樣用戶體驗并不特別好。
所以在用戶輸入www.abc.com按回車后直接在流覽器地址欄中變為www.cba.com。這樣應該是讓用戶更接受新的域名。在這之前我一般都是通過程序文件來執行的，但是這裡都是JSP

文件，對於這個實在不擅長了，所以想直接用nginx來進行實現了。結果還真是成了。
在nginx的location部份添加以下內容就可以了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

 if ( $host ~* (.*).(abc).(com)) { set $domain $1; rewrite ^(.*) http://$domain.cba.com$1 permanent; } 
```  
解釋一下 (.*)表示任何二級域名，abc.com表示原來的域名。.表示轉移為.這個標點符號。 set $domain $1， 這個$domain表示是二級域名的變量，$1表示abc.com後面接著的地址。rewrite部份就十分好理解了。需要更進一步學習就只能看[http://wiki.nginx.org/NginxHttpRewriteModule](http://wiki.nginx.org/NginxHttpRewriteModule)  
  
  
由於使用nginx作為代理轉發器，所以對nginx的upstream和proxy也更多了瞭解。在upsteam中我們可以設置多個機器的不同權重以及失效的時間。但是在實際測試中發現，由於後端機器不夠穩定，出現404或者503，502這種情況，這個時候Nginx也會轉發到這個機器上，這樣用戶體驗會非常不好。  
放狗找了下，還真給找到了解決方法。  
在location部份加上  
```c
 proxy_next_upstream error timeout invalid_header http_500 http_503 http_404; 
```  
這樣一句。這樣後端一台機器出現500，503，404等錯誤的時候也就會  
  
轉發到其他機器上了。這樣用戶體驗就會更好一點。  
  
nginx還有一個需要手動添加的模塊NginxHttpUpstreamFairModule，這個需要自己編譯的時候通過--add-module=來手動添加進來。這個模塊的作用其實可以把用戶的請求發送到後  
  
端負載最輕的機器上。只需要在upstream中這樣修改就行：  
```c
 upstream www { fair; server 10.2.9.99:9090 weight=1; server 10.2.8.227:8080 weight=5; } 

上个月，带鱼陈建来北京公干，于是我两在呷哺呷哺小吃了一下，一下子又回到了10多年前的时光。发现自己对于那个时光居然还有详细的记录，今日有空就特地贴出来一下。

记得报名那天天气不错，似乎大家都是早早的来到了学校，可能是都想见见新同学到底长什么样子。办好手续就来到了寝室，号码不错很好记“111”。进去一 看，好像人都到齐了一样，铺好床铺，就由陈建带头聊开了。印象里寝室里第一个有深刻记忆的就是他了。数了数都到了6个人了，还缺一个嘛。聊了好久也没见这 个高人到来。大家估计他可能不来读了。这个人就是潘伟。寝室里扫荡了一下居然还搜出一副乒乓球拍，大家一合计就去那时候的汇海大厦买了一只还是两只乒乓球 就来到学校里开打了。由于大家都是南汇的，所以说话就特别亲切的。一路上是有说有笑有打有闹。终于打好乒乓球回到寝室看到了神秘的潘伟同学。第二个有深刻 记忆的人就是潘伟了。不仅仅是他迟到，还有就是那副让我感觉很好笑的眼镜。晚上吃过晚饭，不知道是谁提议要夜游卫校，这次出了“风头”的就是陈涛了。在卫 校试验楼的第一声惨叫就是来自这位老兄了。看到身体标本也没这样夸张的啊。大家活动了一天也都累了，于是都躺床上聊天呢。聊天内容我记得不清楚了，而且我 是很早就睡着了，所以我什么都不知道了哦。不知道哪位老兄那天晚上失眠的就来说说好了。

接 下来第一个星期每天除了开会就是玩了。开学第一个星期就这样过去了，这期间又对申晓青和陶德峰熟悉了。这个是因为打乒乓球的缘故，晓青打乒乓只会老爷球， 不过也不是一般的老爷球，他也经常打的像陶德峰这样的高手疲于奔命。打乒乓球最高手的就是陶德峰了，真TMD是高手高手高高手，经常是我们6个人打他一 个。好像这里还少了个人哦，这个人要下篇，本来想放这里的，但是感觉放那篇里更能突出一下。

现在看来，卫校的伙食还是不错的，至 少从性价比上来看，价格便宜量又足。哪像现在吃8两饭跟在卫校吃半斤差不多。真TMD是半斤8两。寝室里吃饭最快就要属黄涛同学了，每次我还刚吃了1/4 了，他就全部消灭干净了。此人真不懂得细嚼慢咽的道理。不过现在在大学里他吃饭就不怎么快了。记得有段时间吃饭的时候经常用饭卡来作弊。一张饭卡两个人 刷，爽~~~~~ 不过这其中要属黄平华技术最差劲了，每次我都有种他要被抓的感觉。别看孙东兵那副老实巴交的样子，其实这个他是高手中的高手，经常可以装的若无其事的样 子。最夸张一次就是寝室9人用2张饭卡去买早饭，当然受害对象是老卡罗斯。不知道时候食堂的汤就要收费了，导致的结果就是那时侯8个人喝一碗汤就，可能那 个汤拿手里太烫了的缘故。导致的结果就是每次吃饭我都会浪费一些，实在是干的吃不下去了。

除了前面已经说过的乒乓球，卫校里面值得玩的地 方可真不多了。也就一个所谓的足球场和篮球场。也不清楚什么时候寝室里有了个足球，好像是班级里买的。于是只要操场是干的，那上面总有我们的身影。渐渐地 大家也都买好了自己的球衣。放一起简直就是多国部队。黄涛的克罗地亚，潘伟的曼联，我的荷兰。还有几位简直就是来收集球衣的。陶德峰的球衣我居然能经常在 我的床上发现诶，你说他的球衣多不多啊。每天我们都玩的很疯狂。记得有几天我们都是早上4：30起床去大操场上疯玩。四对四或者三对三也很好玩。那时候总 有跑不完的体力，不像现在，哎………… 我们寝室踢球感觉晓青最厉害，要技术有技术，要速度有速度，不过弱点也明显，大家也都看到了，身体太单薄了。陶德峰和黄涛是那种技术型的，相对而言陶德峰 跑的更快点，而黄涛则更有大局观。剩下我和潘伟还有黄平华就是属于捣浆糊的一类。还少个人吧，对了就是陈建和陈涛啊。

陈涛是个牛人啊，用我们老师的说法就是“原来我也是棵咸菜啊！”这人学什么都快。所以他实力在我们三人之上也不奇怪。陈建没办法了，由于一些原因也只好做守门员了，不过我们也经常换守门员当，谁累了就去当守门员。孙东兵我感觉最大的特点就是身大

一个是使用bind的view功能。
这个首先就需要定义一个ACL列表，然后在name.conf中include一下就可以了。Acl定义的格式如下：

 acl "company"{ 1.1.1.1/32; 2.2.2.2/32; }; 

每行定义记得用分号结尾就行。

下面这个是named.conf的配置。View也就是这里进行配置完成的。记得所有的zone必须在view中。

 options { directory "/usr/local/bind/var"; }; include "/usr/local/bind/var/company_acl.conf"; view "view_company"{ match-clients { company; }; #这里的company就是你前面acl中定义的acl名字 zone "abc.com" { type master; file "abc.com.company"; allow-update { none; }; }; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "empty"; }; }; view "view_any"{ match-clients { any; }; zone "abc.com" { type master; file "abc.com.ns"; allow-update { none; }; }; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "empty"; }; }; 

这些定义完成之后就是添加zone记录了。
下面这个是view_company的实例，其他类似就成。

我们经常可以发现某个shell程序手动运行的是完全正常的，但是放到crontab中却没有定时运行。这个时候我们可以查看下/var/log/cron这个日志文件看看你的应用程序是否被准时调用了。
如果在日志文件中我们没有发现这个应用程序执行的相关日志，那估计你是在crontab中把shell程序路径给写错了。这个时候你就得检查一下路径问题了。
还有一种情况是发现日志当中也有执行的信息，但是我们找不到运行之后的结果。这个时候我一般碰到的就是环境变量的问题。
解决环境变量问题首先可以输入export看下自己的环境变量，如果这里没有，那可以在shell程序头部增加```c

source /etc/profile

最近由于涉及到得shell程序比较多，这些shell本来是在crontab中能够正常执行的，但是在系统重装后这些程序却都不执行了。而系统的环境变量是相同的，这让我想到了是不是crontab自己有一个环境变量。  
搜索了一遍果然发现crontab自己的环境变量设置。```c

vim /etc/crontab
``` 文件中我们就可以看到PATH的设置，这个就是crontab自己的环境变量了。汗死啊！

对于后端是同一端口多域名转发的nginx proxy。在nginx中的默认proxy是只能对后面real server做端口转发的，而不能做域名转发。
这个是因为默认

1

proxy_set_header Host $proxy_host; 

这样就等于前端输入域名后到nginx这里直接转换成IP进行转发了。
于是我们需要修改proxy_set_header的参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

proxy_set_header Host $http_host;
```  
例如下面一个举例。下面这个例子中backend1权重为5，其他默认为1，最大失效次数3次，如果30秒内没有响应就认为是失效了。  
```c
 upstream lb { 
   server backend1.test.com weight=5; 
   server backend2.test.com:8080 max_fails=3 fail_timeout=30s; 
   server unix:/tmp/test3; 
   } 
   server { 
     listen 80; 
     server_name lb.test.com; 
     location / { 
       proxy_store off; 
       proxy_redirect off; 
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
       proxy_set_header X-Real-IP $remote_addr; 
       proxy_set_header Host $http_host; 
       proxy_pass http://lb; 
       } 
  }