Saturday, September 24, 2011

Static Route - Windows Multihome Question ( two network cards)

Static Route - Windows Multihome Question ( two network cards)

Warning - Multiple default gateways are intended to provide redundancy to a single network(such as an intranet or internet). They will not fumction properly when the gateways are on two separate, disjoint networks(such as one on your intranet and one on the internet). Do you want to save this configuration?

Note: only machines on the same LAN can ping each other, but machines on cross LAN / different LAN can't cannot ping. ( I used WireShark to analyze capture the packet. I saw echo request ( type 8 ), but not echo reply (type 0) at all. The packet seems being dropped drop.

Windows Multihome Question ( two network cards)

Hello:

I have an issue with Win 2003 server, network Load balancing, and Routing.

Set the Scene:

2 unique machines. Running Win 2003 Server and Cold Fusion. We had an

internal network and a DMZ

The machines have unique internal IP addresses on a /24 network.

The machine are NLB to a single IP in the DMZ.

The problem we have has to do with multihoming. We'd like to be able to

manage the machines remotely, which does require a default gateway on the

private side.

And of course the machines havea gateway on the DMZ side for HTP replies to

find their way out.

Currently we have a CFMHTTP request that is sent out thru the DMZ, and it

fails more or 90% of the time. However when we remove the gateway from either

the DMZ side or the private side, the request goes out, with no issue.

Is ther a way around this? Can Windows be coaxed into having 2 gateways on

two separate networks? Note that the only path between the networks is on the

machine itself. The networks are isolated for security reasons.

Thanx




You only use one Gateway and it must go on the External (DMZ) side. In the

Internal side you handle the routes to other internal subnets by using the

OS's Routing Table to create Static Routes.

To add a Persistent Routes to windows server 2003:
cmd> route ADD -p 192.168.200.0 MASK 255.255.255.0 192.168.100.11 METRIC 3

Verify the result:
cmd> route print

Friday, September 23, 2011

freebsd rxvt-unicode 安裝與設定

freebsd rxvt-unicode 安裝與設定
2009年3月24日星期二 by Anati
用過X11的人應該知道xterm這個終端機,但是也知道它非常的不好用,這裡推薦大家使用rxvt這個功能比xterm強,而且又是輕量級的終端機,而它的unicode版的rxvt稱為urxvt,以下介紹一下設定檔的部份

1、安裝urxvt
# cd /usr/ports/x11/rxvt-unicode
# make install clean

2、設定urxvt
-tr 背景透明(配合-sh使用)
-fade 沒有focus的時候的亮度0~100
-fadecolor 沒有foucs的時候的顏色
-tint 背景色調(要-tr啟動)
-sh 背景明亮0~100黑100~200亮(配合-tr使用)
-icon 指定檔案當icon
-bg 背景色
-fg 前景色(文字色)
-cr 游標色
-pr 滑鼠指標的前景色
-pr2 滑鼠指標的背景色
-bd 邊框色
-fn 設定字型(預設吃XFT)
-vb 關掉vbell
+sb 關掉scroll
-sr 把scroll移到右邊
-sl 歷史記錄筆數
-b 外邊框大小
-w 內邊框大小
-im 指定輸入法
-imlocale 用來開啟輸入法的語系
-imfont 輸入法字型設定
-ch 啟動的根路徑

3、我的設定
記錄1000筆、不開聲音、沒有捲軸、沒有邊框、文字白色、背景黑色、游標白色、沒有focus的時候暗度30%
EX: urxvt -sl 1000 -vb +sb -b 0 -fg #EEEEEE -bg #000000 -cr #EEEEEE -fade 30

記錄1000筆、不開聲音、沒有捲軸、沒有邊框、文字白色、背景透明、透明暗度20%、沒有focus的時候暗度30%
EX: urxvt -sl 1000 -vb +sb -b 0 -fg #EEEEEE -tr -sh 20 -fade 30

Reference:
http://hsian-studio.blogspot.com/2009/03/freebsd-rxvt-unicode.html

irssi 簡單教學

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Clockwork Box on 4/18/09

相信IRC是個還滿古老的東西,但是卻非常的有效,本來我完全不知道和很多好朋友在同一個頻道聊天的樂趣,接觸之後我發現我真的非常的喜歡,介紹給大家認識一下

首先先安裝軟體irssi
# cd /usr/ports/chinese/irssi
# make install clean

裝好之後,直接使用irssi就可以啟動這個irc的軟體,而設定檔的部份,第一次進之後離開,就會自動出現在你的家目錄裡的.irssi/config,如果你的環境是UTF-8的話,那應該沒有什麼太大的問題,而我的是Big5編碼,為了和windows相容的關係,首先我們先從config下手
# vim ~/.irssi/config
servers = ( #要連的主機
{
address = "irc.oftc.net";
chatnet = "oftc"; #伺服器
port = "6667";
autoconnect = "yes"; #是否啟動時自動連上
} #用,分開可以設定很多組,因為可以同時連上很多irc server
);

chatnets = { #設定加入伺服器的時候的命令
oftc = { type = "IRC"; };
};

channels = ( #加入頻道時候的命令
{ name = "#yzugeek"; chatnet = "oftc"; autojoin = "yes"; }
);
接下來是命令的alias喜歡的可以在這裡新增自己常用的
aliases = {
J = "join"; #加入某個channel
WJOIN = "join -window";
WQUERY = "query -window";
LEAVE = "part";
BYE = "quit"; #斷線,離開irssi
EXIT = "quit";
SIGNOFF = "quit";
DESCRIBE = "action";
DATE = "time"; #看目前的時間
HOST = "userhost";
LAST = "lastlog"; #列出到目前為止的記錄
SAY = "msg *";
WI = "whois"; #看某個人的訊資
WII = "whois $0 $0";
WW = "whowas";
W = "who"; #看目前channel上每個人的資訊
N = "names"; #看目前channel上有那些人
M = "msg"; #傳送私人資訊給某人
T = "topic"; #若是op的話可以修改channel的標題
C = "clear";
CL = "clear"; #清除銀目
K = "kick"; #若是op的話可以踢人
KB = "kickban";
KN = "knockout";
BANS = "ban";
B = "ban";
MUB = "unban *";
UB = "unban";
IG = "ignore";
UNIG = "unignore";
SB = "scrollback";
UMODE = "mode $N";
WC = "window close"; #關閉目前channel的聊天視窗
WN = "window new hide";
SV = "say Irssi $J ($V) - http://irssi.org/";
GOTO = "sb goto";
CHAT = "dcc chat";
RUN = "SCRIPT LOAD";
CALC = "exec - if which bc &>/dev/null\\; then echo '$*' | bc | awk '{print \"$*=\"$$1}'\\; else echo bc was not found\\; fi";
SBAR = "STATUSBAR";
INVITELIST = "mode $C +I";
Q = "QUERY"; #開啟和某人的私人聊天視窗
"MANUAL-WINDOWS" = "set use_status_window off;set autocreate_windows off;set autocreate_query_level none;set autoclose_windows off;set re
EXEMPTLIST = "mode $C +e";
ATAG = "WINDOW SERVER";
};
statusbar的部份我不討論,因為我用目前的樣式就行了,有興趣的可以自己改一改畫面,或是直接把官網的themes來用也是可以的
settings = { #irssi的設定
core = {
recode_autodetect_utf8 = "yes"; #自動偵測頻道是不是utf8
recode_transliterate = "yes"; #直接轉換
recode_fallback = "Big5"; #設定轉換為Big5
recode_out_default_charset = "UTF-8"; #輸出uft8
real_name = "Clockwork Box"; #在channel上全名
user_name = "clockwork";
nick = "clockwork"; #在channel上使用的nick
};
"fe-common/core" = { term_charset = "Big5"; }; #我們輸入的字元集
"fe-text" = { actlist_sort = "refnum"; };
};


以上大概是整個irssi的設定檔了,設好之後,啟動就可以直接殺進channel裡面,這裡我設定我常去的channel是#yzugeek,還有很多其它的指令你可以使用/help來查尋,不過一堆用不到的,常用的還是那幾個。

※另外這裡要介紹的,就是如何使用irssi
一進來irssi如果你沒有設過上面的東西的話,你要先連上server之後在join到一個channel才可以開始聊天,假設我今天要加入irc.oftc.net裡面的#yzugeek的話先開啟irssi之後輸入
/connect irc.oftc.net
之後會跑阿跑的停了之後就連上了,接著
/join #yzugeek
這個樣子就進了channel了,很簡單吧!
之後你會看到像是這樣的東西
[14:41] [@clockwork(+i)] [2:oftc/#yzugeek(+nt)]
@ - 表示你是個OP就是具有管理權限的人,也可以踢人
2 - 表示你在視窗2,視窗1通常是連上server的資訊,或是相關資訊的output
oftc - 表示目前在這台oftc server上面
#yzugeek - 表示目前你在這個#yzugeek的channel裡面
+i or +nt - 表示你的權限和這個頻道的權限

後面你可能會看到這樣的東西
1 2 3 4 5 6 ....
這個表示是視窗的意思,可以用alt+1 or 2 or 3 ....來切換,或是使用ctrl+n or p來切換
視窗1通常是連上irc server的資訊
視窗2之後都是一般頻道的視窗了,在裡面就可以和別人聊天

※玩irc該了解的大小事
1、聊天的時候如果只是針對某個人講的話,請先打他的nick:之後接要打的資訊
2、如果私人的事,請用/q or /msg私人視窗聊天,一樣用alt+??可以切過去
3、如果要離開還是要做什麼事,請用/me 去睡覺,告訴別人你的情況
4、下命令可以使用alias比較方便,如開私人視窗用/q xxxx比/query xxxx好打
5、善用tab來補齊你的命令,比較方便
6、當有1 2 3 4 5 6 ...的數字在statusbar上出現,表示那個視窗有人聊天
7、如果數字是紅色的話,表示有人叫你的名字
8、如果不知道怎麼用使用的話先用/help輸出所有命令到1視窗去,之後去看看用什麼
9、用/help command來查尋命令的功能
10、不想和別人聊的話,就可以用/wc把視窗關閉
11、想要離開irssi的話用/bye離開
12、善用screen+irssi來掛機(screen說明也在blog中,請找自己找)

以上大概是簡單的設定了,這裡提供一些別人的說明,可以參考看看
http://irssi.org/documentation 這是官網的說明
http://lzy-blah.blogspot.com/2007/08/screen-irssi-irc-q.html 更仔細的說明

 
 

Things you can do from here:

 
 

Freebsd UTF-8 環境

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Clockwork Box on 4/18/09

目前的unix like系統像是freebsd ubuntu ...都走上utf8的編碼,因為在utf8編碼上可以支援更多的語系,但是要怎麼將整個使用環境改成utf8編碼可以透過以下的方式。

1、設定登入語系
可以用locale -a |grep zh來查,我用的是zh_TW.UTF-8
vim ~/.login_conf
加入
me:\
:lang=zh_TW.UTF-8:


設好之後重新登入,使用locale來看應該就是zh_TW.UTF-8了

2、設定vim編輯器
vim ~/.vimrc
加入
"file encoding
set fileencodings=utf-8,big5
set fileencoding=utf-8


fileencodings是說vim透過順序解碼,如果成功就使用
fileencoding是說vim建立文件的時候使用utf8編碼

3、設定irssi聊天工具
vim ~/.irssi/config
修改settings部份
settings = {
core = {
recode_fallback = "UTF-8"; #本端使用utf8
recode_out_default_charset = "UTF-8"; #輸出使用utf8
recode_transliterate = "yes";
real_name = "xxxxx";
user_name = "xxxxx";
nick = "xxxxxx";
};
"fe-common/core" = { term_charset = "UTF-8"; }; #用utf8字元集
"fe-text" = { actlist_sort = "refnum"; };
};


4、設定screen工具
在編譯screen的時候請加入cjk的支援,如果沒有加入的話先去重編一次。screen很聰明會自動看你設定的LC_ALL為什麼編碼來開啟編碼方式,所以其實不用太需要去設定,但是會出現一種問題,就是你make config的時候銀目會花掉,這是因為cjk的關系也就是寬字元顯示的關系,所以我會在screen裡面先關掉cjk,因為預設為utf8時它就會自動啟動。
vim ~/.screenrc
加入
cjkwidth off


當有需要顯示像是日文或是韓文時,請手動開啟cjk,請用ctrl+a, :cjkwidth on來開啟
※請注意開啟cjk的時候不論你用的是putty還是pietty全都要和screen一致才行

5、設定pietty或putty
選項 > 字元編碼 > Unicode UTF-8
選項 > 亞洲語系修正 > 取消 亞洲寬字元 (這個就是cjk了)
※所以如果在screen裡面有開cjkwidth on的話,記得這裡就要勾選亞洲寬字元,但是平常如果沒有在看bbs沒有一堆外星文字的話,是不用特別去開cjk的。
※請配合screen所設定的cjk要一致。

6、WinScp檔案傳輸
可以透過設定winscp自動幫忙轉換windows和freebsd兩邊的編碼

開啟login時,選Environment裡面有Server environment的第二個下拉選項
UTF-8 encoding for filenames: 選ON,之後記得存檔

※這裡提醒一下,winscp只有管理檔名的轉換問題,內容編碼為何,它是不理的,所以如果你用vim寫的話,那裡面的編碼已經是utf8了,所以下載回來,需要使用支援utf8編碼的軟體來開,否則會是乩碼。


關於編碼的觀念
==============================================================
對於不論是big5或是utf-8都好,它都是一種編碼的方式,其實要看每個程式是否有支援編碼的部份,像檔名的話,就是由putty或是pietty來顯示編碼,而如果是文件內的資料的話,用vim來開那就是由vim來決定編碼的方式,所以要設定utf8的話,並不是只要設定一個部份而己,其實每個程式都要設定,像是screen和putty就有很大的關係,必須要相互配合。

編碼是編碼,顯示是顯示,今天使用了utf-8編碼,代表你打的每個字都是由utf-8當成內碼來表示,而我們看到的中文字顯示的出來,表示這個軟體它支援轉換utf-8這種編碼的方式,一次只能選擇一種編碼方式,所以不可能檔案裡面又是用big5編碼或是又用utf-8編碼。

不過現在越來越多opensource的軟體越來越強了,只要設定了LC_ALL的部份,它就會自動偵測且自動切換編碼了,是真的非常的方便。

 
 

Things you can do from here:

 
 

freebsd上安裝scim中文輸入法

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Clockwork Box on 5/27/09

在unix like的系統中,輸入法總是讓人家最煩腦的部份,因為設定的東西實在太多了,這裡討論的是不是底層架構的部份,只單純講解如何在freebsd上面安裝中文輸法引擎和加入一個無蝦米輸入法。

1、安裝scim的table(輸入法)
雖然有套件可以裝全語系的scim,叫scim-tables,但是會裝了一堆用不到的輸入法,我覺得沒有必要,所以我用另一個方法安裝,如果要裝scim-tables的人可以安裝
# cd /usr/ports/chinese/scim-tables/
# make install clean
如果像我一樣只要裝無蝦米就好,其它的都不要的話,請依我的方式安裝
# cd /usr/ports/textproc/scim-table-imengine (安裝輸入法表引擎)
# make install clean
裝好之後就有一個輸入法表的引擎了,可以自己新增像無蝦米這樣的輸入法。

2、安裝各種輸入法(無蝦米)
要安裝無蝦米要先下載無蝦米的表格還有它的圖片,你可以在這裡下載
# fetch http://moon.cse.yzu.edu.tw/~s932361/bsd/bsd_scim.tgz
# tar zxvf liu_scim.tgz
裡面有兩個檔案分別cp到它要放的目錄
# cp liu5.bin /usr/local/share/scim/tables
# cp liu5.png /usr/local/share/scim/icons
這樣就安裝完scim還有加入了無蝦米的輸入法了,如果你想用新酷音輸入法,當成注音輸入法的話,也非常的簡單,只要安裝scim-chewing套件就行了
# /usr/ports/chinese/scim-chewing
# make install clean
這樣就裝完了新酷音輸入法了,你就有兩套可以使用的輸入法,一套是無蝦米,另一套就是注音

3、啟動scim
透過以上的方式我們己經裝好我們的輸入法引擎,並且加入了兩種輸入法,那我們該怎麼在x11下啟動scim,那就要設定.xinitrc(X11啟動的時候的設定檔)
vim .xinitrc
export XMODIFIERS='@im=SCIM' (吃XIM的程式使用scim輸入法平台)
exec scim -d & (啟動scim當成deamon)
存檔之後就可以啟動X了

※特別注意,scim必須要以utf8的環境才可以啟動,所以你的系統如果還是全是big5的環境的話,那你必須在.xinitrc裡面改成
exec env LC_CTYPE="zh_TW.UTF-8" scim -d &
才可以順利啟動scim,不過以目前的趨勢來說,unix lik的系統已經走向全面utf8化了,所以最好整個系統都設成utf8的語系

 
 

Things you can do from here:

 
 

VIM進階設定

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Clockwork Box on 10/7/09

最近去coscup2009才發現原來有把vim用到神領域的人,真有超佩服他的,所以最近又在玩vim的一些功能,以下是我的一些心得分享。

* 編碼的設定

我的環境是zh_TW.UTF-8那如果別人給我一個big5編碼的檔不就不能開了,不過vim會做轉碼的動作,所以可以放心。

在.vimrc裡面加入
set fencs=utf-8,big5 "vim開檔自動判斷檔案編碼先從utf-8開始
set fenc=utf-8 "建立新檔的時候以什麼編碼建立
set enc=utf-8 "vim所使用的內部編碼

簡單來說三個例子

1、檔案編碼為utf-8

開啟vim的時候由fencs所指定的清單來判斷檔案的內部編碼,此時判斷為utf-8,而它與我們vim的內部編碼相同都是utf-8,所以直接就可以正確顯示。

2、檔案編碼為big5

開啟vim的時候由fencs所指定的清單來判斷檔案的內部編碼,此時判斷為big5,而它與我們vim的內部編碼不同,我們內部編碼是utf-8,所以vim會呼叫iconv把讀出來的big5轉換成utf-8編碼,就可以正確顯示,而如果我們修改完內容寫回檔案的時候,vim又會將utf-8自動轉換成big5寫回檔案。

3、開新檔案

由於設定fenc=utf-8所以檔案在建立的時候就會以utf-8來編碼,雖然不設定的話,預設vim會讀取目前locale所使用的語系來建立檔案,但是如果常常語系改來改去的話,常常建立的檔案自己都不知道是什麼編碼,所以加入這個設定。

* 視窗分割

vim可以把一個視窗分割成幾個視窗,可以縱切也可以橫切,通常我使用縱切的話分割成左右兩個畫面,這樣可以同時開兩個程式碼而且可以對照著看內容,非常的方便。

ctrl+w, v 切割垂直分割
ctrl+w, n 切割水平分割
ctrl+w, q 關閉分割
ctrl+w, - 縮小分割大小
ctrl+w, + 放大分割大小
ctrl+w, = 平均分割大小
ctrl+w, 方向鍵 移動聚焦視窗

* 在程式碼中加速移動(必學)

※注意:要在normal mode下
[{ or [( 找左邊界第一個出現的{ or (
]} or ]) 找右邊界第一個出現的} or )
f@ or f" 向右找第一個出現匹配的符號或字元
$ 移到行尾,等於END
^ 移到行首,等於HOME
H 移到畫面最上方
M 移到畫面中間
L 移到畫面最下方
c$ 修改到行尾
d% 移除到行尾
dw 移除一個單字
d^ 移除到行首
% 找最近的() or {}

範圍選取技

※以下看到的"|"是「或」的意思
v | c | d + i | a + { | [ | " | '

v: visual
c: change
d: delete
i: inner object
a: an object
{},[],"",'': region

va{ 選取最小範圍的{}部份
vi{ 選取最小範圍的{}部份(但不包含{})
di" 移除最小範圍的""部份(但不包含"")
ci( 修改最小範圍的()部份(但不包含())
va{= 選取最小範圍的{}部份並排列整齊

* vim plugins

vim官網有非常多的plugin可以用,如果興趣可以自己上去慢慢找

NERD_tree.vim 目錄列表插件
taglist.vim 函式列表插件(需安裝ctags)

要加入plugin先在家目錄下面建立.vim/plugin目錄
> mkdir -p ~/.vim/plugin
之後把下載的plugin解壓縮之後都放到plugin目錄下面就行了,之後看一下它所附上的說明檔, 看要怎麼來設定使用這個插件,之後在加入對映的快速鍵來啟動插件。

> vim .vimrc 加入
"ctags command set for bsd
let Tlist_Ctags_Cmd = "/usr/local/bin/exctags"
"functional mapping
nmap <F1> :NERDTreeToggle<CR>
nmap <F2> :TlistToggle<CR>

我把F1, F2對映到這些plugin的啟動上面

* 總結

vim是個非常強大的編輯器,其實用起來像在打電動,所有很多的連續技,如果熟練的話,那麼寫程式或是編寫文件會大大的縮短時間,使工作更有效率。

* 附上投影片
Vim Hacks
View more documents from c9s.


 
 

Things you can do from here:

 
 

freebsd snapshot and iso mount

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Clockwork Box on 10/16/09

在freebsd提供了一個很好用的備份功能就是可以快速的把目前這個分區的資料照下來,之後在慢慢備份,而原本的服務還可以運作,這真的非常的方便。

注意:檔案系統快照只能用在獨立的「檔案系統」

* 對檔案系統做快照

/dev/ad4s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad4s1e on /Backup (ufs, local, soft-updates)
/dev/ad4s1d on /Document (ufs, local, soft-updates)

# mksnap_ffs /Backup /Backup/test.snap

* 將快照掛載並觀看作檔案備份

# mdconfig -a -f /Backup/test.snap -u 0 (載入到/dev/md0的裝置)
# mount -r /dev/md0 /mnt (把載入到md0掛到/mnt下,因為快照不可修改,所以要用唯讀)

* 移除快照檔

# umount /mnt (先卸載裝置)
# mdconfig -d -u 0 (釋放md0裝置在memory中的佔用)
# rm -rf /Backup/test.snap

* 掛載iso檔

# mdconfig -a -f xxx.iso -u 0 (載入到/dev/md0的裝置)
# mount_cd9660 /dev/md0 /mnt

* 卸載iso檔

# umount /mnt
# mdconfig -d -u 0

可以使用mdconfig -l指令來看看目前是否有此md裝置存在。


 
 

Things you can do from here:

 
 

系統的備份

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Clockwork Box on 11/10/09

天有不測風雲,可能天災也可能人禍,基本的系統一張光碟或是一塊軟碟片加上網路即可輕鬆搞定,但是最花時間的重要設定及使用者資料要重建可是件不小的工程,如果平時能將重要檔案及使用者資料備份起來,就可以省去很多的復原的時間。

在 FreeBSD 中已經內建好一些和備份有關的指令,例如:tar , dump , restore , dd , cpio , pax , ...... 至於要使用哪個工具則視個人喜好及需求囉!我個人習慣用 tar 來備份像 /etc , /usr/local/etc , ...... 等以目錄或檔案為主的設定檔,如果像使用者的資料 (/home) 及信箱 (/var/mail) 是放在單獨的 partition 則是利用 dump 備份及用 restore 來還原。

下面就來看看如何用 tar 及 dump 完成基本的備份工作。

1.tar

tar (tape archive) 原本是設計用來將文件打包到磁帶中的,我們也可以將檔案或是目錄打包成一個單一的檔案,必要時再用同一個程式來將資料全部還原或是只解開部份的資料,正因為它可以備份檔案或目錄,深受大家的愛用。

常用參數:

* 指定動作 :
-c create,新增一個備份檔
-t list,顯示備份檔中的檔案清單
-x extract,解開備份檔中的檔案

* 指定檔案:
-f file,讀/寫指定的檔案

* 壓縮方式:
-z gzip,備份的東西要用 gzip 壓縮/解壓縮
-y bzip,備份的東西要用 bzip 壓縮/解壓縮,也可以用 -j

* 其它:
-p permissions,保留原來的權限
-v verbose,備份的內容要顯示在畫面
-C (大寫 C),cd 先切換目錄

由於 tar 的功能非常的多,指令可用的選項令人眼花瞭亂,下面只示範最常用的,有興趣再自己用 man tar 好好的研究囉!

1.1 以 tar 打包要備份的資料

如果沒有什麼特殊需求,利用 tar 備份檔案只要用到 -c (新增) ,-p (保留權限設定),-f (指定檔名),頂多再加個 -v 看一下打包的過程。

例如:
tar -cpvf /home/backup/etc.tar /etc

上例將 /etc 目錄中所有的檔案打包到 /home/backup/etc.tar 中。

也可以同時備份多個目錄,將要打包的清單(以空白分隔)接在最後面即可。下面的例子將 /etc , /usr/local/etc 打包在 etc.tar 中:

tar -cpvf /home/backup/etc.tar /etc /usr/local/etc

我們也可以使用:

tar -czpvf /home/backup/etc.tgz /etc

和前面的例子比較,多了個參數 z ,也就是將 tar 打包完的檔案再利用 gzip 壓縮,所以新產生有經過壓縮處理的備份檔我們也將檔名命名為 etc.tgz (.tgz 結尾),也有人用 .tar.gz ,端看個人習慣。

咦~好奇的人可能會想到 FreeBSD 的 packages 檔名好像叫 *.tgz 或 *.tbz,和 tar , gzip , bzip 有沒有關啊?有興趣可以找個 FreeBSD 的 package ,用 tar 來打開包裝看看哦!!

另外,比較一下這兩個同樣是備份 /usr/local/etc 的指令有何不同?

tar -czvf /home/backup/local.etc.1.tgz /usr/local/etc
tar -czvf /home/backup/local.etc.2.tgz -C /usr/local etc

由於 tar 預設在備份時會儲存檔案的路徑 (但是自動去掉開頭的第一個斜線) ,也就是 /usr/local/etc/rc.d 在 local.etc.1.tgz 中會變成 usr/local/etc/rc.d,如果我們連 usr/local 都不想要,打包時可以利用 -C (大寫字母) 這個參數來控制路徑的保留層次,像前面第二個例子加了 -C /usr/local ,tar 會先切換至 /usr/local 目錄才備份 etc,所以在 local.etc.2.tgz 中 /usr/local/etc/rc.d 變成 etc/rc.d 儲存起來。


1.2 查看 tar 打包的檔案

要查看以 tar 打包的檔案只要利用 -t 這個動作參數即可。

例如:

tar -tvf /home/backup/etc.tar

上例會將 /home/backup/etc.tar 中的檔案清單顯示出來。

如果備份時有用 gzip 壓縮過則可以加上 -z :

tar -tzvf /home/backup/etc.tgz

如果備份時用 bzip 壓縮過則加上 -y 或是 -j:

tar -tyvf /home/backup/etc.tbz

1.3 解開 tar 打包的檔案

要解開 tar 封裝的檔案是利用 -x 這個動作參數,再搭配 -z , -y (-j) 解壓縮。如果想保留原來的權限設定則要記得使用 -p,至於要不要使用 -C (大寫字母) 則要看當初在打包時有沒有使用及自己想要放置的路徑而定,最容易犯的毛病大多是解錯路徑,所以在使用 -x 解開時一定要記得先用 -t 查看一下當初是怎麼打包的,最保險的方法是先解到一個暫存的地方,再將需要的檔案複製/搬移到目的地。

將 /home/backup/etc.tgz 中的東西在目前所在的目錄解開:

tar -xzvf /home/backup/etc.tgz

將 /home/backup/etc.tgz 中的東西在 /home 中解開:

tar -xzvf /home/backup/etc.tgz -C /home

將 /home/backup/etc.tgz 中的東西在 /home 中解開,並保留原始的權限:

tar -xzpvf /home/backup/etc.tgz -C /home

1.4 只解開 tar 打包的部份檔案

只解出 /home/backup/etc.tgz 中的 etc/group , etc/master.passwd 兩個檔案:

tar -xzvf /home/backup/etc.tgz etc/group etc/master.passwd

將 /home/backup/etc.tgz 中凡是叫 etc/rc* 通通解開,其它的不要:

tar -xzvf /home/backup/etc.tgz 'etc/rc*'

將 /home/backup/etc.tgz 中的檔案解開,但是 rc.d 目錄中的東西不要:

tar -xzvf /home/backup/etc.tgz --exclude='rc.d/*'

以上提到的方法也可以應用在打包時 (-c) 及查看清單時 (-t) 。


1-5 利用 tar 直接複製整個目錄到另一個目錄中

利用 tar 和 pipe 的技巧,可以做整個目錄直接複製,不過這個方法並不保證完整哦,畢竟它的方式不若 dump + restore 完備。

假設我想把 /usr 中所有的東西複製到 /mnt/usr 中,就執行底下的指令:

tar cf - /usr | (cd /mnt ; tar xvfBp -)

2. dump 及 restore

前面提過的 tar 可以針對目錄或檔案來備份,而 dump 則是以 block 為處理單位,針對整個檔案系統(分割區)來備份,可以更完整的保持系統的原貌不會有所缺漏,以 dump 備份的資料可以用 restore 再還原回來。

2.1 以 dump 將整個 partition 備份至一個檔案

使用過 Norton ghost 的人應該知道裡面有個選項是將 MS Windows 或 Linux 系統的某個分割備份到映像檔中,下面則是利用 dump 做類似的動作,將某個分割區備份至一個檔案。

假設 /home 是一個單獨的分割區 (/dev/ad0s1h),而 /backup 是一個空間夠大的目錄,我們可以執行:

# dump -0uaf /backup/home.dump /home

上面的例子以 level 0 將 /home 所在的分割區備份至 /backup/home.dump 中。

參數說明:

* -0 以 level 0 備份,也就是完整備份,level 可以為 0~9,level 1 則只備份 level 0 後有異動的部份。
* -u update,備份完成後自動更新 /etc/dumpdates 的內容(記錄分割區代號、level、備份日期)。
* -a auto-size,略過可儲存空間大小的檢查。
* -f file,將備份的資料輸出到後面參數指定的檔案,也可以是一個硬體(device file)或是標準輸出 (-)。

2.2 以 restore 還原檔案

以 dump 備份的分割區我們可以用 restore 將檔案還原出來,就像利用 ghost 把映像檔再寫入 partition 一樣,不過 restore 也可以只解出部份檔案。不過在使用 restore 要注意的是,restore 並不會幫我們將 partition 做格式式,而且,它是將內容解在目前所在的目錄,所以要記得先做好格式化並切換到要還原的目錄。

例如想把 /home dump 完的備份 ( /backup/home.dump ) 還原到 /mnt/new (/dev/ad1s1e) 這個 partition 中,如果 /dev/ad1s1e 已經格式化好,而且已經 mount 到 /mnt/new ,就可以執行以下指令:

# cd /mnt/new
# restore -rf /backup/home.dump

完成後,/mnt/new 就可以看到原來 /home 的中的資料。

如果只想還原備份中的部份檔案怎麼辦呢?

restore 提供 -i 的參數來進行交談式的還原,我們可以利用這個方法來指定要還原的部份,例如,只想由 /home 的備份檔 home.dump 中還原 /home/gsyan , /home/students 的資料,我們可以執行:

# restore -if /backup/home.dump

出現 restore > 的提示符號後,我們就可以下指令,例如:輸入問號 (?) 即可列出可用的指令,

restore > ?
Available commands are:
ls [arg] - list directory
cd arg - change directory
pwd - print current directory
add [arg] - add `arg' to list of files to be extracted
delete [arg] - delete `arg' from list of files to be extracted
extract - extract requested files
setmodes - set modes of requested directories
quit - immediately exit program
what - list dump header information
verbose - toggle verbose flag (useful with ``ls'')
help or `?' - print this list
If no `arg' is supplied, the current directory is used

為了達到範例的目標,我們要用 add 來新增要還原的檔案清單,用 extract 執行還原,下面是還原出 /home/gsyan 及 /home/studens 至目前分割區的步驟,黑體字的部份是自行輸入的部份:

restore > add gsyan students
restore > extract
You have not read any tapes yet.
If you are extracting just a few files, start with the last volume
and work towards the first; restore can quickly skip tapes that
have no further files to extract. Otherwise, begin with volume 1.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
restore >

要結束只要輸入 quit 按 Enter 鍵即可跳出 restore 。

2.3 以 dump 及 restore 做 partition 對 partition 的對拷

將分割區 dump 給標準輸出,再讓 restore 由標準輸入還原在新的 partition 就能達到 partition 對 partition 對拷的目的,底下是進行對拷的流程:

1. 切好新的 partition
2. 以 newfs 將 partition format 好
3. 將新的 partition mount 好
4. 切換至新的 partition 中
5. 以 dump & restore 進行備份及還原

 ※ 1-2 的步驟可以執行 /stand/sysinstall ,然後選取 Configure 利用裡面的 Fdisk 和 Label 進行分割及格式化

例如:想要將 /home (/dev/ad0s1h) 上的所有資料備份到新硬碟上的 partition (/dev/ad2s1h),執行:

# newfs /dev/ad2s1h (如果已經格式化過則可省略)
# mount /dev/ad2s1h /mnt (如果已經 mount 好則可省略)
# cd /mnt
# dump -0uaf - /home | restore -rf -
# cd /
# umount /mnt

特別注意 dump 及 restore 並沒有指定檔名,而都用了一個減號 ( - ),對 dump 來說,是將 partition 的資料一個 block 一個 block 的送向標準輸出,而 restore 則是由標準輸入讀入並還原。

2.4 以 dump & restore 備份整顆硬碟

如果想將整顆硬碟的資料拷至另一顆新硬碟,以最笨的方法就是先用 /stand/sysinstall 將新硬碟切割好,再利用 dump & restore 把各 partitions 一一對拷即可,程序如下:

1. 將新硬碟接好後,以重新開機。

2. 執行 /stand/sysintall
* 選取 Configure
* 選取 Fdisk 切給 FreeBSD 用的 partions
* 選取 Label 進入 Disklabel Editor
* 注意:在設定 disklabel 時 mount point 要先照原來的架構設定
* 在存檔前先移到各 partition 後按 M 修改 mount point 至 /mnt 下的暫存目錄,不然可能會有錯誤
* 按 W 存檔並開始 format New H.D. (newfs)

3. 離開 sysinstall

4. umount -A 解除所有 mount 上來的 filesystem

5. mount -a 重新掛上系統預設的 filesystem

6. 開始備份各 partition

7. 將新硬碟的 / (例如:/dev/da1s1a) 掛上來

mount /dev/da1s1a /mnt

8. 將新硬碟 /etc/fstab 中的 /dev/xxx 改成合適的

ee /mnt/etc/fstab

2.5 dump + ssh 進行異地備份

dump 和 restore 其實有相對應的 rdump 和 rrestore 可進行遠端的備份及還原,不過 r 系統的指令的安全性較需考量,我們可以利用 ssh 來進行較安全的連線。

假設現在想把名為 mail 上掛在 /home 的這個 partition 異地備份至名為 bkserver 主機上的 /backup 目錄 ,我們可以進行以下程序來備份。

* 準備工作
o 在 bkserver 上準備一個備份登入用的專用帳號,假設就叫 bk 好了!!
o 檢查 bkserver 備份專用的目錄 /backup 是否可被備份專用帳號 ( bk ) 寫入。
o 在 mail 上因為要執行 dump 必須是 root ,所以屆時必須由 root 執行 ssh 遠端登入 bkserver,所以要為 mail 上 root 以 ssh-keygen 準備登入用的 "公開金鑰" 。
o 將 root@mail 的公開金鑰置入 bkserver 上帳號 (bk) HOME 的 .ssh/authorized_keys 中。
* 進行備份

準備工作中比較麻煩的部份應該遠端登入用的金鑰,製作流程如下:
2.5.1 連線測試

我們先在 mail 上以 root 的身份登入 mail,然後遠端登入 bkserver (假設在 bkserver 上已經建好 bk 這個帳號)

# ssh bk@bkserver

如果是第一次連線,應該會出現下面的問題詢問是否儲存遠端主機的識別資料,類似下面:

The authenticity of host 'bkserver.test.edu.tw (192.168.1.5)' can't be established.
DSA key fingerprint is 2b:cc:89:80:bc:77:45:83:47:ae:b6:29:51:f5:15:33.
Are you sure you want to continue connecting (yes/no)?

輸入 yes 即可,ssh 會將資料存入 ~/.ssh/know_hosts ,下次就不會有同樣的問題。

接著輸入 bk 的登入密碼,如果成功登入就完成連線測試,輸入 exit 登出,準備進行登入用金鑰的製作。

2.5.2 製作金鑰

我們希望在進行遠端備份能夠不用輸入密碼自動登入遠端主機執行備份儲存的工作,所以要先在 mail 上用 ssh-keygen 來產生 ssh 登入用的金鑰對。

先確認已經在本機 ( mail ) 上用執行 dump 指令的 root 帳號登入哦!然後由 root 執行:

ssh-keygen -d

接著應該會出現以下的對話:

Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
a6:62:05:95:92:79:2a:71:2d:73:3b:7d:0e:e7:39:26 root@mail.test.edu.tw

如果希望登入時不用輸入密碼直接登入,只要通通按 Enter 回所有問題即可。

執行完會在 /root/.ssh 中產生 id_dsa 和 id_dsa.pub ,後面那個就是我們要放在 bkserver 裡 bk 帳號下的金鑰。

接著我們要把 /root/.ssh/id_dsa.pub 複製到遠端主機 (bkserver) 裡備份專用帳號 (bk) 個人目錄的.ssh/authorized_keys 中。

如果 bkserver 的 ~bk/.ssh/authorized_keys 不存在,我們直接把前面在 mail 上 root 帳號產生的 id_dsa.pub 上傳過去即可,在 mail 上以 root 執行:

scp ~/.ssh/id_dsa.pub bk@bkserver:.ssh/authorized_keys

不過要記得先幫 bk 建好 .ssh 的目錄哦!不然會發生錯誤。

如果 authorized_keys 早已存在,我們可以先將 id_dsa.pub 傳到 bkserver 上,然後再將 id_dsa.pub 中的內容貼到 ~bk/.ssh/authorized_keys 新的一行。

如果前面的步驟完成了,我們在 mail 以 root 執行 ssh bk@bkserver 應該就可以不用輸入密碼遠端登入囉!

2.5.3 遠端備份

做好前面的準備工作後,我們就可以在 mail 上將某個 partition 備份到位於遠端的 bkserver 上了。

例如:

# dump -0uaf - /home | ssh -c blowfish bk@bkserver dd of=/backup/mail.home.dump

上面的例子在 mail 上執行,將掛在 mail /home 的 partition 備份起來,並以 bk 帳號遠端登入 bkserver 儲存在 bkserver 的 /backup/mail.home.dump 裡。

如果想省一些空間則可以順便用 gzip 壓縮後再傳給 bkserver,指令改為:

# dump -0uaf - /home | gzip -2 | ssh -c blowfish bk@bkserver \
dd of=/backup/mail.home.dump


 
 

Things you can do from here:

 
 

rsync 同步資料

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Anati on 1/18/10

最近發現一個超好用的工具,對於兩台電腦資料同步的時候超級好用,本來都使用sftp或是scp在那邊貼來貼去,檔案改變的時候又要清楚改了什麼,要同步乾脆就砍掉重貼,有了rsync之後透過ssh的連線一下就搞定了。

* 安裝rsync
由ports來裝
# cd /usr/ports/net/rsync
# make install clean
透過package來裝
# pkg_add -r rsync

* 使用rsync

本端使用
> rsync -av src/ dist/

本端使用目的資料夾同步來源資料夾
> rsync -av --delete src/ dist/

透過ssh遠端使用 (兩台機器同時都要安裝rsync)
> rsync -av -e "ssh -p 1234" src/ clockwork@clockwork.cse.tw:~/Desktop/dist/
※透過ssh開啟1234埠建立連線,如果目的端沒有dist資料夾的話會自動建立

透過ssh遠端同步
> rsync -av --delete -e "ssh -p 1234" src/ clockwork@clockwork.cse.tw:~/Desktop/dist/

* 特別注意
如果目的資料夾不存在的話會自動建立,因此討論以下幾個案例
1. rsync -av src dist 會建立出dist/src/xxxx
2. rsync -av src/ dist 會建立出dist/xxxx
3. rsync -av src dist/ 會建立出dist/src/xxxx
4. rsync -av src/ dist/ 會建立出dist/xxxx


 
 

Things you can do from here:

 
 

mimetype 應用程式關聯設定

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Anati on 1/31/10

在使用桌面系統的時候常常因為安裝了許多程式而造成開啟軟體與檔案之間關聯出現問題,這是因為系統的應用程式關聯不正確。

* 以下的路徑的檔案和文件開啟有相關聯
/usr/local/share/applications/*.desktop (系統存放所有應用程式的程序配置)
~/.local/share/applications/*.desktop (用戶存放所有應用程式的程序配置)
/usr/local/share/applications/mimeinfo.cache
(**非常重要,啟動相關會參考此檔來決定mimetype的對應關係,此為系統域的設定檔)
~/.local/share/applications/mimeinfo.cache
(**非常重要,啟動相關會參考此檔來決定mimetype的對應關係,此為個人域的設定檔)

如果當軟體安裝之後沒有更新mimeinfo.cache的話,可以透過指令來強制更新
# update-desktop-database (預設更新系統層級的應用程式關聯,需root權限)
> update-desktop-database ~/.local/share/applications (更新用戶層級的關聯)

* 自訂檔案開啟關聯
假如我想由vim來開啟任何一個文字型態的檔案,可以自己寫一個vim.desktop
> vim ~/.local/share/applications/vim.desktop
[Desktop Entry]
Encoding=UTF-8
Type=Application
NoDisplay=true
Name=vim
Exec=urxvt -fn 'xft:AR PL New Sung:size=10' -vb +sb -b 10 -fg '#eeeeee' -bg '#101010' -e vim %f
MimeType=text/plain

※我開啟的不是gvim而是在console下執行的vim,所以必須要由term來喚起,我所用的是urxvt,在MimeType那裡看到就是由freedesktop所分類的mimetype,以後遇到這個檔案就會由vim來開啟
> update-desktop-database ~/.local/share/applications (更新mimeinfo.cache)

* defaults.list
在上以的目錄裡面可能會放現還有一個defaults.list這種檔,其實它與mimeinfo.cache是一樣的,主是要給gnome桌面環境使用的,對於KDE或是自己手動建立的桌面環境而言它沒有任何功用


 
 

Things you can do from here:

 
 

single-user mode 救援模式

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Anati on 3/12/10

當系統被改壞的時候,或是無法進根檔案系統的時候,就需要使用single-user mode了,進入之後在對改錯的地方修正,重開機就OK了

系統重啟時如果有選單的話,直接選4就可以進入single-user mode了,如果像我連選單都不開的話,就需要在帶入核心 前按下任意鍵,此時就會有個OK的提示符號出現,可以使用 help看一下提供什麼功能,如果要進入single-user mode 的話直接輸入

OK> boot -s

以上輸入完畢之後,系統就開始由單使用者方式進入系統,而檔案系統都是使用read-only方式掛載,此時就可以修正需要修正的地方了。

通常進入拿到的shell是B shell其難用無比,所以我通常都會第一時間執行tcsh

# /bin/tcsh

之後就可以始對錯誤的地方修正了 ,如果需要檢查和修正檔案系統的話可以使用

# fsck -y /dev/da4s1a
# fsck -y /dev/da4s1d

然而如果因為在/etc下錯砍了不知道什麼檔以造成系統無法啟動的話,除了在單人模式把設定檔修正以外,如果實在太多,而且也不知道有那些的話,可以拼一下用升級系統方式直接升級設定檔,如此一來遺失的設定檔可以補回

# cd /usr/src
# mergemaster

系統就會比對少的檔就會叫你安裝了, 如此一來就可以補齊檔案,如果src裡面的原始檔已經和此次建立的不同的話,那等救回來開機進去之後,要把整個系統都升級,因為你已經用了新的設定檔,但是整個系統都還是舊的。


 
 

Things you can do from here:

 
 

256 colors

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Anati on 3/4/10

在unix系統上,本來只有16色的,不過漸漸的,許多的應用程式都支援256色了,像是常用的xterm, urxvt, screen等都支援256色表示,此篇來介紹一下如何打造一個256色的環境。

1. xterm, rxvt-unicode, screen 支援256色
要達成預期的效果,當然是軟體需要重新編譯進加上支援256色的設定,如果你已安裝了,可以透過portupgrade使用-m的參數將256色支援的選項傳給ports來重新編譯。

軟體已安裝的人請用以下的指令
# portupgrade -ufv x11/xterm -m WITH_256_COLOR=yes
# portupgrade -ufv x11/rxvt-unicode -m WITH_XTERM_COLOR=yes
# cd /usr/ports/sysutils/screen && make config (選取256色支援)
# portupgrade -ufv sysutils/screen

未安裝的人請用以下的指令由ports安裝
# cd /usr/ports/x11/xterm && make WITH_256_COLOR=yes install clean
# cd /usr/ports/x11/rxvt-unicode && make WITH_XTERM_COLOR=yes install clean
# cd /usr/ports/sysutils/screen && make config (選取256色支援) && make install clean

2. 完成軟體支援之後先測試一下是不是可以正常支援256色了
下載 http://www.frexx.de/xterm-256-notes/data/256colors2.pl 是個perl程式
# perl ./256color2.pl 如果有支援的話,那應該會出現256種顏色

3. 之後就可以開始使用256種顏色了
可以參考以下兩個網頁的教學
http://www.frexx.de/xterm-256-notes/
http://www.pixelbeat.org/docs/terminal_colours/
使用256色的指令碼就像使用ansii color 16色一樣是由一些跳脫字元表示
\033[38;5;0~255m 設定前景色
\033[48;5;0~255m 設定背景色

以上適用於程式做printf出來使用,如果使用要使用在prompt或是用在motd的話需要在文字中直接寫入跳脫字元,以vim為例,要插入跳脫字元\033為先按下ctrl+v之後按下ESC鍵,即可輸入\033跳脫字元,而在編輯器中看到大概會是這樣
^[[38;5;0~255m 要上色的文字 ^[[m

如我的prompt就使用了256色來表示


 
 

Things you can do from here:

 
 

Bind9 dns server

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Anati on 5/20/11

在bsd中如果要架設dns server是非常方便的事情,因為內建就有bind9,因此險只要經過一些動作就可以輕鬆架設dns,不過這裡不解釋dns的架構與學理的討論

通常dns最少都會有兩台為了防止查不到的情況,因此這裡以master/slave架構來介紹這兩台機器如何共同運作,假設機器有140.114.3.83與140.114.6.93兩台來說

* 140.114.3.83 master 設定bind9

# cd /etc/namedb/
# cp named.conf named.conf.back (先備份起來,免得改壞了)
# vim named.conf

// listen-on {127.0.0.1;}; (要註解掉,因為預設只允許本機查詢)
include "named.conf.my_config" (將自己做出來的設定檔用include方法加入)

# cd /etc/namedb/working/
# vim named.conf.my_config (因為在named.conf裡面有指定directory的關系所以要放在working目錄下才讀的到)

zone "arkbsd.org" {
type master;
file "master.arkbsd.org";
allow-transfer {
140.114.6.93; (允許的slave機器)
};
};

# cd /etc/namedb/working/
# vim master.arkbsd.org (開始要寫zone檔了)

$TTL 86400
@ IN SOA dns1.arkbsd.org. femc7488.gmail.com. (
2011052001 ; serial
8H ; refresh (8 hours)
2H ; retry (2 hours)
1W ; expire (1 week)
1D ; negative cache (1 day)
)
IN A 140.114.3.83 ; arkbsd.org 正解ip
IN NS dns1.arkbsd.org. ; master dns1
IN NS dns2.arkbsd.org. ; slave dns2
dns1 IN A 140.114.3.83 ; dns1.arkbsd.org 正解ip
dns2 IN A 140.114.6.93
www IN CNAME arkbsd.org. ; www.arkbsd.org為arkbsd.org的alias
ftp IN CNAME arkbsd.org.
aria IN A 220.134.30.214
tifa IN A 140.114.6.93
movie IN A 114.34.131.23
locker IN A 140.114.6.114


# echo 'named_enable="YES"' >> /etc/rc.conf
# /etc/rc.d/named start (之後可以看一下在/var/log/message中有沒有錯誤)

* 140.114.6.93 slave 設定bind9

# cd /etc/named/
# cp named.conf named.conf.back (一樣先備份)
# vim named.conf

// listen-on {127.0.0.1;}; (要註解掉,因為預設只允許本機查詢)
include "named.conf.my_config" (將自己做出來的設定檔用include方法加入)

# cd /etc/namedb/working/
# vim named.conf.my_config (因為在named.conf裡面有指定directory的關系所以要放在working目錄下才讀的到)

zone "arkbsd.org" {
type slave;
file "slave.arkbsd.org";
masters {
140.114.3.83;
};
};

在slave機器中不需要編輯slave.arkbsd.org的zone檔,因為它會由master來提供

# echo 'named_enable="YES"' >> /etc/rc.conf
# /etc/rc.d/named start (之後可以看一下在/var/log/message中有沒有錯誤)

* 設定完後的工作

當設定完當然要看看有沒有正常運作,我們可以透過dig這個命令來查看看是不是可以查的到
# dig arkbsd.org @127.0.0.1
# dig www.arkbsd.org @127.0.0.1
# dig -t ns arkbsd.org @127.0.0.1
# dig dns1.arkbsd.org @127.0.0.1
# dig dns2.arkbsd.org @127.0.0.1

另外如果正常運作的話 slave中的zone檔會自動透過同步路產生,也可以檢查一下是否存在
# cd /etc/named/working/ (看看在6.93那台上有沒有存在slave.arkbsd.org)

如果一切都正常的話,就可以將dns代管那邊改為自管,並將dns指向dns1, dns2
之後過一段時間我們可以使用
# dig arkbsd.org @168.95.1.1
查詢結果如果有正確指向我們要的機器的ip的話就代表成功了,如果簡單的dns只需要正解的功能,而反解的話需要上層的設定,除非自己有一個網段下的ip否則可以不用設


 
 

Things you can do from here:

 
 

Homebrew: 新一代 OSX 套件管理工具

身為一個 programmer,總是需要在 Mac 上裝一些開放源碼程式,除了自己下載、編譯( ./configure && make && make install) 之外,通常最方便的選項就是用套件管理工具來處理安裝、升級跟移除。

Homebrew 之前,最常見的就是 MacPortsFink 了,我自己本來是用 MacPorts,它有個討厭的特點就是它不依賴系統內已經安裝好的套件,完全自成一局 (當然,這也算是一種 isolation 優點,如果你不爽的時候只要砍掉 /opt 就移掉了)。所以常常為了裝個小套件,就還要安裝一堆它依賴的套件(例如:重複裝一套你系統裡已經有的 Perl,crazy!),十分耗費時間跟空間,而且到最後我也搞不清楚它裝了一大堆我不知道拿來幹什麼用的套件。

Homebrew 則盡量依賴系統內已經有的套件、它的套件 formula 是用簡單的 Ruby 寫的,所以你可以 fork Homebrew repository 自行修改維護、它自己用 Git 管理自己,升級十分方便。

安裝及使用方式

1. 要先安裝有 Xcode,你才能編譯東西。
2. 下載執行 http://gist.github.com/323731

安裝好之後,就有以下指令可以使用

brew search 搜尋套件
brew info 查詢套件資訊
brew list 已經裝了哪些套件
brew update 更新 homebrew 自己
brew install 安裝套件

例如,我馬上就安裝了 wget 跟 git 這兩個是我最基本要用的工具,一下就搞定了,cool!

brew install wget
brew install git

參考資料

homebrew — Mac OS X 下新的软件包管理工具
Homebrew: OS X’s Missing Package Manager
http://ihower.tw/blog/archives/4308/comment-page-1#comment-60142

Vimcasts free screencasts about Vim

Vimcasts publishes free screencasts about Vim, the text editor. Vim has been around in one form or another for over 20 years. The learning curve is famously difficult, but those who manage to climb it insist that nothing can match Vim's modal editing model for speed and efficiency.

http://vimcasts.org/

Thursday, September 22, 2011

vim edited files, then use utf-8 encoding as default when svn commit

Move the original svn binary to svn.orig:
# mv /usr/local/bin/svn /usr/local/bin/svn.orig

Create a svn binary wrapper script:
# vi /usr/local/bin/svn
#!/bin/sh

### initialize
svnarg=""

### use encoding utf-8 as default if run "svn ci" or "svn commit".
if [ "$1" != "help" ]; then
  for myarg in "$@"; do
    if [ "${myarg}" = "commit" ] || [ "${myarg}" = "ci" ]; then
      svnarg="--encoding utf-8"
      break
    fi
  done
fi

### wrapper script to set umask to 027 on subversion binaries
### Note: the meaning of each umask:
### umask 002 // File permission 644. Owner can read/write. Group and Others can only read.
### umask 007 // File permission 660. Owner and Group can read/write. Others can not read or write.
### umask 027 // File permission 640. Owner can read/write. Group can read. Others can not read or write.
umask 027

### svn command
/usr/local/bin/svn.orig ${svnarg} "$@"

Try to "svn commit" a file:
# svn commit --message "svn log message: Hello World!"

or shortcut
# svn ci --message "svn log message: Hello World!"

My ~/.vimrc setting:
# cat ~/.vimrc
" let vim correctly load these ecnoding files
set fileencodings=utf-8,big5,euc-jp,gbk,euc-kr,utf-bom,iso8859-1
" file default encoding utf-8
set encoding=utf-8

For ~/.cshrc setting:
# cat ~/.cshrc
setenv LC_ALL en_US.UTF-8
setenv LANG en_US.UTF-8

setenv TERM screen-256color

For ~/.bashrc setting:
### utf-8 mode
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

To see a list of the available locales:
# locale -a

To see current locale setting:
# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Wednesday, September 21, 2011

freebsd pkg_info

 
 

Sent to you by Danny via Google Reader:

 
 

via Hsian Studio by Anati on 11/11/10

pkg_info是freebsd一個非常重要的指令,拿來查詢目前安裝的軟體,雖然man文件寫的很清楚,不過常用的幾個功能記錄一下

1. 查詢某一套件
> pkg_info -Ex gtk

2. 查詢套件相依
> pkg_info -rx py26-gtk

3. 查詢套件被相依
> pkg_info -rx py26-gtk

4. 查詢套件安裝資訊
> pkg_info -Dx virtualbox-ose

5. 查詢套件包含的檔案
> pkg_info -Lx virtualbox-ose

6. 查詢套件的說明
> pkg_info -dx pkg_tree

7. 查詢套件屬於那個ports
> pkg_info -ox virtual

8. 查詢某檔案屬於那個套件
> pkg_info -W libglx.so

9. 查詢某個ports安裝後為那個套件
> pkg_info -O ports-mgmt/pkg_tree

當然光有pkg_info工具不夠,所以通常大概會裝幾個關於管理的工具如
1. pkg_tree 了解套件之間相依性
2. portupgrade 裡面的集合的工具如pkg_deinstall pkgdb ....
3. bsdadminscripts 裡面集合的pkg_libchk ...


 
 

Things you can do from here:

 
 

FastCGI with a PHP opcode cache benchmarks

 
 

Sent to you by Danny via Google Reader:

 
 

via Brandon's Blog by Brandon on 7/28/09

In my previous post, I described how to implement FastCGI with a PHP opcode cache on an Apache webserver. My primary motivation for moving to FastCGI was to take advantage of the extra security provided by FastCGI with suEXEC over mod_php. In this post, I'll compare the two environments and provide a few benchmark results.

Benchmark Setup

To compare mod_php to FastCGI with a PHP opcode cache, I used the ab tool on my desktop running PHP 5.3.0, mod_fastcgi 2.4.6 and Apache 2.2.11 on Gentoo linux. Apache had a limited number of modules enabled (actions alias authz_host dav deflate dir expires filter headers log_config mime rewrite setenvif status vhost_alias). The hardware consisted of a Intel Core2 Quad Q6600 (2 x 4MB L2 cache) with 2GB of RAM.

I chose to benchmark against the main page of a stock WordPress 2.8.2 install with no plugins enabled. I chose WordPress because it's extremely easy to set up and many people are familiar with it. I've read that WordPress is very liberal with queries to the database (especially when plugins are involved). Without database queries, I would expect to see a bigger difference between results with an opcode cache and results without one. That being said, most PHP applications today make database queries as part of a typical request and thus I think these results are realistic of what you might experience on your server.

I executed the following command:

$ ab -n 1000 -c 30 http://localhost/

in four different environments:

  • mod_php with a 30MB APC opcode cache (Apache MPM prefork)
  • mod_php without an opcode cache (Apache MPM prefork)
  • mod_fastcgi, suEXEC with a 30MB APC opcode cache (Apache MPM worker)
  • mod_fastcgi, suEXEC without an opcode cache (Apache MPM worker)

Between each benchmark, I reconfigured and restarted the server. I then loaded the main page in a web browser to prime the APC cache.

Benchmark Results

Requests
Graph displaying requests per second of each benchmark scenario

Requests per second

The graph above shows that mod_php and FastCGI behaved very similar in terms of requests per second. Using an opcode cache increased the request rate by almost 3 times in both scenarios. As I mentioned earlier, I'd expect to see an even bigger increase with fewer database queries.

I saw similar results when increasing the number of requests to 10,000, or changing the concurrency level. I never saw any failed requests. I was happy to see there wasn't a significant performance difference moving from mod_php to FastCGI.

Memory Usage
Graph displaying memory usage of each benchmark scenario

Memory usage

The graph above shows the approximate memory usage for each of the 4 benchmarking scenarios. This data was gathered by running the ps_mem.py script immediately after the ab tool completed. This script outputs the private and shared memory usage for each program running on the system. Because I ran my benchmarks in isolation, with nothing else accessing the host, these results should be pretty accurate.

The results surprised me. From the graph you can see that disabling the opcode cache resulted in more memory usage. I think this is misleading. Typically, Linux keeps memory resident until it is needed by another process. I believe the increased memory usage for the non-opcode cache scenarios is actually discarded memory that the Linux kernel hasn't reclaimed. Since each process is having to recompile the PHP script on each request, you see a lot more built up memory reported as private but most likely free to be reused. I suspect running this on a low memory server would yield slightly different results.

You can clearly see the difference in memory usage for the Apache processes (green in the graph) between FastCGI and mod_php. The FastCGI Apache processes are much leaner. Since Apache doesn't need the PHP bloat, it can serve static content much more effectively and quickly.

The scenarios with an opcode cache each used a similar amount of RAM. There is a catch to these results however: I only benchmarked a single user. In a shared environment, each user gets their own PHP instance and opcode cache. With mod_php, all users share the same. Thus I would expect every user to roughly double the RAM used in a FastCGI scenario, while mod_php memory usage would stay relatively constant. This increased memory usage is the main trade-off when going with FastCGI.

Raw Results

For those who want even more detail, below are the raw results from my benchmark tests:

mod_php without an opcode cache:

 This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/  Benchmarking localhost (be patient)  Server Software:        Apache Server Hostname:        localhost Server Port:            80  Document Path:          / Document Length:        5474 bytes  Concurrency Level:      30 Time taken for tests:   28.507 seconds Complete requests:      1000 Failed requests:        0 Write errors:           0 Total transferred:      5717000 bytes HTML transferred:       5474000 bytes Requests per second:    35.08 [#/sec] (mean) Time per request:       855.200 [ms] (mean) Time per request:       28.507 [ms] (mean, across all concurrent requests) Transfer rate:          195.85 [Kbytes/sec] received  Connection Times (ms)               min  mean[+/-sd] median   max Connect:        0    0   0.2      0       2 Processing:   138  849 214.5    842    1608 Waiting:      138  848 214.3    842    1601 Total:        139  849 214.4    843    1608  Percentage of the requests served within a certain time (ms)   50%    843   66%    911   75%    975   80%   1004   90%   1112   95%   1230   98%   1355   99%   1426  100%   1608 (longest request) 

mod_php with opcode cache:

 This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/  Benchmarking localhost (be patient)  Server Software:        Apache Server Hostname:        localhost Server Port:            80  Document Path:          / Document Length:        5474 bytes  Concurrency Level:      30 Time taken for tests:   10.784 seconds Complete requests:      1000 Failed requests:        0 Write errors:           0 Total transferred:      5717000 bytes HTML transferred:       5474000 bytes Requests per second:    92.73 [#/sec] (mean) Time per request:       323.530 [ms] (mean) Time per request:       10.784 [ms] (mean, across all concurrent requests) Transfer rate:          517.70 [Kbytes/sec] received  Connection Times (ms)               min  mean[+/-sd] median   max Connect:        0    0   0.2      0       2 Processing:    66  319  62.9    316     580 Waiting:       66  318  62.9    316     580 Total:         67  319  62.8    316     580  Percentage of the requests served within a certain time (ms)   50%    316   66%    339   75%    354   80%    364   90%    395   95%    424   98%    464   99%    482  100%    580 (longest request) 

FastCGI without an opcode cache:

 This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/  Benchmarking localhost (be patient)  Server Software:        Apache Server Hostname:        localhost Server Port:            80  Document Path:          / Document Length:        5474 bytes  Concurrency Level:      30 Time taken for tests:   28.170 seconds Complete requests:      1000 Failed requests:        0 Write errors:           0 Total transferred:      5695000 bytes HTML transferred:       5474000 bytes Requests per second:    35.50 [#/sec] (mean) Time per request:       845.104 [ms] (mean) Time per request:       28.170 [ms] (mean, across all concurrent requests) Transfer rate:          197.43 [Kbytes/sec] received  Connection Times (ms)               min  mean[+/-sd] median   max Connect:        0    0   0.2      0       2 Processing:   105  832  82.9    832    1004 Waiting:      105  832  82.9    832    1004 Total:        107  832  82.8    832    1004  Percentage of the requests served within a certain time (ms)   50%    832   66%    856   75%    873   80%    882   90%    908   95%    927   98%    954   99%    971  100%   1004 (longest request) 

FastCGI with opcode cache:

 This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/  Benchmarking localhost (be patient)  Server Software:        Apache Server Hostname:        localhost Server Port:            80  Document Path:          / Document Length:        5474 bytes  Concurrency Level:      30 Time taken for tests:   10.917 seconds Complete requests:      1000 Failed requests:        0 Write errors:           0 Total transferred:      5695000 bytes HTML transferred:       5474000 bytes Requests per second:    91.60 [#/sec] (mean) Time per request:       327.509 [ms] (mean) Time per request:       10.917 [ms] (mean, across all concurrent requests) Transfer rate:          509.44 [Kbytes/sec] received  Connection Times (ms)               min  mean[+/-sd] median   max Connect:        0    0   0.2      0       2 Processing:    46  323  36.6    325     426 Waiting:       46  323  36.6    325     426 Total:         47  323  36.5    325     426  Percentage of the requests served within a certain time (ms)   50%    325   66%    335   75%    342   80%    346   90%    359   95%    368   98%    383   99%    389  100%    426 (longest request) 

Memory Usage (in MB):

Benchmark Apache PHP Total
private shared total private shared total
mod_php, no cache 202.3 7.7 210 210
mod_php, with cache 45.3 15.5 60.8 60.8
FastCGI, no cache 9.2 3.3 12.5 68.3 5.0 73.3 85.8
FastCGI, with cache 9.2 3.6 12.8 23.4 13.8 37.2 50

Conclusion

I run my blog on a Linode VPS with a very limited amount of RAM. I also host other applications and a few friends' sites on this same server. Thus, I am very concerned about memory usage. Still, the security advantages provided by FastCGI far outweigh the increased RAM usage.

I hope you have seen that the performance of FastCGI with an opcode cache is just as good as with mod_php. It's also evident how important an opcode cache is to running PHP scripts.

If you have any thoughts about these benchmarks, or the performance of FastCGI vs mod_php, feel free to leave a comment or question below!


 
 

Things you can do from here:

 
 

FastCGI with a PHP APC Opcode Cache

 
 

Sent to you by Danny via Google Reader:

 
 

via Brandon's Blog by Brandon on 7/6/09

Hosting PHP web applications in a shared environment usually involves a choice between two exclusive options: host a fast application by using a persistent opcode cache, or host an application that your shared neighbors can't snoop around or destroy. In this post I discuss a way to get the best of both worlds, by combining FastCGI with a single opcode cache per user.

This is a long post, ready to jump right in? Skip the history!

The evolution of mod_php to FastCGI

In the early days of all-you-can eat shared hosting, administrators served PHP via mod_php. mod_php loads the PHP interpreter into every web server process during server startup, thus alleviating the expense of starting an interpreter each time a script executes. This allowed executing PHP scripts relatively fast.

mod_php came with a few drawbacks:

  • Every server process, even those serving static files such as images and CSS scripts, contained the PHP interpreter. This caused a lot of bloat in the web server's memory footprint. It also eliminated the ability to use mutil-threaded web servers as many PHP extensions are not thread safe.
  • Every PHP script ran as the same user as the web server. While web servers typically run as a non-privileged user such as nobody, multiple mutually untrusting shared accounts could easily access, disrupt or destroy each other by executing a PHP script.

FastCGI loads the PHP interpreter into a separate process. This process is still persistent across connections, but, using a mechanism such as suEXEC, can run as a different user. Static files can be served by a lightweight multi-threaded web server process while PHP scripts are served by a single-threaded FastCGI process. What's more, if PHP crashes, it doesn't bring down the entire web server.

In the shared hosting context, each user's PHP scripts are executed with the user's credentials. This leads to a more secure environment for both the host and the shared user.

The opcode cache

One of the easiest and most effective things you can do to speed up your PHP scripts is to enable an opcode cache such as APC, XCache or eAccelerator. An opcode cache caches the compiled state of PHP scripts in shared memory. Thus each time a PHP script is run, the server doesn't have to waste time compiling the source code. Opcode caches can speed up execution of scripts by up to 5 times and decrease server load.

In my opinion running PHP on a webserver without an opcode cache is like restarting your car's engine at every stop sign. You can still get where you're going but it's going to take longer and put a lot more wear and tear on your engine. An opcode cache is so important that APC is going to be included in the core of PHP 6.

An opcode cache requires that the PHP interpreter process persist between connections. Both mod_php and FastCGI satisfy this requirement. An opcode cache requires RAM, a precious commodity on a shared hosting server. By default, each cache allocates 30MB of shared memory. This can be easily configured up or down depending on the scripts you are running.

Combining FastCGI with an opcode cache

So if we agree that FastCGI and opcode caches are good (a must IMHO), why do most shared hosting providers only enable one? The answer is two-fold:

  1. RAM. Each opcode cache is typically 30MB. Each PHP process gets its own opcode cache. Each user must run its own PHP process for security. Thus each user requires at least 30MB of RAM on top of the RAM required for the PHP interpreter (a lot). All you can eat shared hosting companies typically oversell their servers. Overselling usually works when it comes to bandwidth, I/O and CPU time, however overselling RAM is harder. Remember the PHP processes stay in memory between connections. So a small site only getting a 100 hits a day still hogs the same amount of RAM as a busy site. This breaks the overselling model.
  2. FastCGI. In a typical configuration, FastCGI spawns many separate PHP processes per user. Each PHP process needs its own opcode cache. Instead of maintaining one opcode cache (per user), the server maintains multiple caches. This reduces the effectiveness of the cache and increases the strain on server resources.

Solving problem #1 is hard. Some have suggested a single cache that can be shared across multiple processes and users and still provide assurance that different users cannot mess with each other. This blog post is not about #1. There are many reasons to use unlimited shared hosting providers. Opcode caches are not one.

This blog post is about how to solve problem #2. The goal is to have a reasonable system that utilizes suEXEC, FastCGI and the APC opcode cache. Each user should have one and only one opcode cache. The administrator should be able to adjust the size of the cache for each individual user based on their needs (and monthly fee). Finally, the solution should decrease script load time and increase server performance while maintaining security and privacy between accounts.

mod_fastcgi vs mod_fcgid

I run Apache on my server. Many people suggest running a more lightweight server such as lighttpd. One day I may switch, but for now I've tuned my Apache server to be as fast as I need.

There are two modules to implement FastCGI on Apache – mod_fastcgi and the newer mod_fcgid. Both are binary compatible with each other and do basically the same thing. mod_fcgid sports better control over spawning processes and error detection. mod_fastcgi has been around longer. Both support suEXEC, and both separate PHP from Apache, thus allowing Apache to run threaded workers if desired.

As I mentioned in the combining FastCGI with an opcode cache section, the typical behavior of FastCGI is to spawn multiple PHP interpreters. The FastCGI process monitors each child process, kicking out processes with errors, restarting failed processes and sending incoming requests to the least busy child. This is usually the preferred behavior, and mod_fcgid implements it particularly well.

Opcode caches throw a wrench in this however, because of their inability to share the cache across FastCGI processes. Hopefully one day this will be remedied. Luckily, in the meantime, PHP is capable of playing "process manager" and a single PHP process can spawn several children to handle requests. This way the parent PHP process can instantiate the opcode cache and its children can share it. You'll see this later when we set the PHP_FCGI_CHILDREN environment variable.

Both mod_fcgid and mod_fastcgi can be told to limit the number of PHP processes to 1 per user. The PHP process can then be told how many children to spawn. Unfortunately mod_fcgid will only send one request per child process. The fact that PHP spawns its own children is ignored by mod_fcgid. If we use mod_fcgid with our setup, we can only handle one concurrent PHP request. This is not good. A long running request could easily block multiple smaller requests.

mod_fastcgi will send multiple simultaneous requests to a single PHP process if the PHP process has children that can handle it. This is the reason we must use mod_fastcgi to achieve our goal of one cache per user.

Implementation

This section describes the steps I took to enable suEXEC FastCGI with a single APC opcode cache per user on Apache 2.2. These instructions may vary by Linux distribution and are not intended to be a cut-and-paste howto. I use Gentoo, so most steps will be geared towards a Gentoo install but the general idea should work on any distribution.

1. Install php-cgi and disable mod_php

The PHP interpreter can run in three different modes: as an Apache module, as a CGI binary or as a command line command. Typically, separate binaries are built for the CGI and CLI modes, php-cgi and php respectively. On Gentoo, each mode is associated with a USE flag: apache2 for mod_php, cgi for a CGI binary, and cli for command-line PHP. The cgi USE flag must be enabled. If it isn't, add it to /etc/make.conf or /etc/portage/package.use and recompile PHP. On other distributions, search for a php-cgi binary.

You will want to disable mod_php (if it was enabled) before implementing FastCGI. This can be done by commenting out the appropriate LoadModule line in your Apache configuration file:

# LoadModule php5_module modules/libphp5.so

On Gentoo, this can be easily done by removing PHP5 from the APACHE2_OPTS variable in /etc/conf.d/apache2.

2. Install and enable mod_fastcgi Apache module

We already discussed why we must use mod_fastcgi instead of mod_fcgid. On Gentoo, installing mod_fastcgi can easily be done by running:

$ sudo emerge mod_fastcgi

For other distributions, try installing a mod_fastcgi package or see the FastCGI Installation Notes.

Make sure your Apache conf file contains the line:

LoadModule fastcgi_module modules/mod_fastcgi.so

On Gentoo, this line is found in /etc/apache/modules.d/20_mod_fastcgi.conf. mod_fastcgi is enabled by adding FASTCGI to the APACHE2_OPTS variable in /etc/conf.d/apache2.

3. Install and configure the APC Opcode Cache

To install APC on Gentoo, simply run:

$ sudo emerge pecl-apc

For other distributions, see the Alternative PHP Cache installation instructions.

Once installed, look for the apc.ini file in your php extension configuration directory (e.g. /etc/php/cgi-php5/ext-active). The default apc.ini works with one exception. You need to comment out apc.shm_size="30" (line 5 below). Commenting this line will enable us to set it per user later.

My apc.ini file looks like:

 extension=apc.so apc.enabled="1" apc.shm_segments="1" ;commenting this out allows you to set it in each fastcgi process ;apc.shm_size="30" apc.num_files_hint="1024" apc.ttl="7200" apc.user_ttl="7200" apc.gc_ttl="3600" apc.cache_by_default="1" ;apc.filters="" apc.mmap_file_mask="/tmp/apcphp5.XXXXXX" apc.slam_defense="0" apc.file_update_protection="2" apc.enable_cli="0" apc.max_file_size="1M" apc.stat="1" apc.write_lock="1" apc.report_autofilter="0" apc.include_once_override="0" apc.rfc1867="0" apc.rfc1867_prefix="upload_" apc.rfc1867_name="APC_UPLOAD_PROGRESS" apc.rfc1867_freq="0" apc.localcache="0" apc.localcache.size="512" apc.coredump_unmap="0" 

4. Install/enable Apache suEXEC

Apache 2.2 contains built-in support for executing CGI programs as a different user id and group id than the webserver. This support must be compiled into Apache. On Gentoo, use the suexec USE flag and recompile apache. On other distributions, see Configuring & Installing suEXEC.

5. Create wrapper scripts

The Apache suEXEC security model requires that the CGI binary meet some pretty stringent requirements concerning file ownership and permissions. Rather than copying the php-cgi binary for each user, we create multiple wrapper scripts around the php-cgi binary. These wrapper scripts allow us to set options on a per-user basis.

I keep my wrapper scripts in /var/www/bin, though you may keep yours wherever you want. Each user has a directory in /var/www/bin, for example:

$ ls -l /var/www/bin
dr-xr-xr-x 2 bob bob 104 Jun 24 13:56 bob/
dr-xr-xr-x 2 sue sue 104 Jun 24 13:56 sue/
dr-xr-xr-x 2 joe joe 104 Jun 24 13:53 joe/

Inside each user's bin directory is a single wrapper script, php-fastcgi:

$ ls -l /var/www/bin/bob/
-r-xr-x‐‐‐ 1 bob bob 145 Jun 24 13:56 php-fastcgi

I've shown the ls -l output to show the file and directory ownership and permissions. These are important, and Apache suEXEC will not work correctly if the owner and permissions are not correct.

The contents of the php-fastcgi file in each user's bin directory (see below for an explanation):

 #!/bin/sh  PHP_FCGI_CHILDREN=5 export PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=500 export PHP_FCGI_MAX_REQUESTS  umask 0022 exec /usr/bin/php-cgi -d apc.shm_size=25 

PHP_FCGI_CHILDREN
This variable tells PHP how many child processes it should spawn. As we discussed earlier, our PHP process will act as "process manager" and pass incoming requests to its children. The parent will maintain a single opcode cache which each child will share. The PHP_FCGI_CHILDREN variable tells PHP how many children to spawn. Another way to think of this is the number of concurrent PHP requests that can be handled per user.

PHP_FCGI_MAX_REQUESTS
PHP is known for memory leaks in long running processes. This variable causes each child process to be restarted once it has served a given number of requests (e.g. 500). Only the child process is restarted, the parent process remains. Since the parent process maintains the opcode cache, the opcode cache persists.

umask 0022
This sets the umask the PHP binary will run under. Some people may prefer a stricter umask such as 0077, however I've found 0022 works best as it allows the Apache server running as nobody to read static files written earlier by a suEXEC'd PHP process. Some PHP applications (WordPress plugins) do not do a good job with permissions, and a strict umask can cause applications to fail.

exec /usr/bin/php-cgi -d apc.shm_size=25
This line calls the php-cgi binary and modifies the APC cache size. It is possible to configure this to use a separate php.ini file instead of setting configuration parameters on the command line, however I like the ability to share a single php.ini file.

6. Edit global Apache settings

There are two sets of settings you must configure in Apache: those that affect all users and those that affect a specific user. This section describes global settings that affect all users.

I like to keep my global settings in my /etc/apache/modules.d/20_mod_fastcgi.conf file, but these can go in any part of your http.conf file. Most of the time you do not want this in a VirtualHost section. My global mod_fastcgi settings look like this (see below for an explanation):

 <IfDefine FASTCGI> LoadModule fastcgi_module modules/mod_fastcgi.so  FastCgiConfig -idle-timeout 20 -maxClassProcesses 1 FastCgiWrapper On  AddHandler php5-fcgi .php Action php5-fcgi /cgi-bin/php-fastcgi  <Location "/cgi-bin/php-fastcgi">    Order Deny,Allow    Deny from All    Allow from env=REDIRECT_STATUS    Options ExecCGI    SetHandler fastcgi-script </Location>  </IfDefine> 

FastCgiConfig
The FastCgiConfig configuration directive sets parameters for all dynamic FastCGI processes. The idle-timeout causes FastCGI to abort a request if there is no activity for more than 20 seconds. The maxClassProcesses option is very important: it tells FastCGI to only spawn one php-cgi process regardless of how many requests are pending. Remember that our PHP process will spawn its own children, so FastCGI only needs to spawn one. Until this APC bug is fixed, this is necessary to allow sharing the APC cache among children.

FastCgiWrapper
The FastCgiWrapper configuration directive is needed to allow suEXEC to work.

AddHandler / Action
The AddHandler and Action configuration directives tell Apache to handle all files ending in .php with the php-fastcgi script in cgi-bin. In the next step, you'll see how we alias this cgi-bin directory for each individual user.

Location
The Location directive tells Apache how to handle requests to /cgi-bin/php-fastcgi. The Allow from env=REDIRECT_STATUS on line 13 prevents users from executing this script directly. With this line, the only way to execute php-fastcgi is by requesting a file ending in .php.

7. Edit per-user Apache settings

On my host, every virtual host is associated with one user. And every user has exactly one opcode cache. A single user can have multiple virtual hosts, but these virtual hosts share the same opcode cache.

For each virtual host, I add the following lines, customized for the user associated with that virtual host:

 <VirtualHost *:80> ServerName www.sue.bltweb.net ... <IfModule mod_fastcgi.c>    SuexecUserGroup sue sue    Alias /cgi-bin/ /var/www/bin/sue/ </IfModule> ... </VirtualHost> 

When combined with the global apache settings and the wrapper scripts, this will launch the php-cgi binary using suEXEC to execute as the appropriate user and group whenever a .php file is requested.

There are several different ways to call the FastCGI binary. On my hosts, users don't have access to their cgi-bin directory. The /var/www/bin directory is not accessible by ordinary users. This doesn't have to be the case, the cgi-bin directory could be stored in the user's directory. It is important to note that allowing the user to modify php.ini values allows them to modify their opcode cache size, which could have severe repercussions on RAM usage.

Pros and Cons

The implementation described above is only one of many ways to implement FastCGI and APC. In my opinion, it is the best way to meet my goals, but in this section I'll try to outline some of the advantages and disadvantages of my setup.

Advantages
  • Different users can have different APC cache sizes
  • Multiple concurrent PHP requests can be handled simultaneously
  • RAM usage is predictable as a product of the number of users on the host
  • Server is better secured against attacks from the inside since PHP processes run as the user who owns the script
  • Resource usage can be monitored since each user has a separate PHP process
  • A PHP crash doesn't mean an Apache crash. If a PHP process crashes it is restarted automatically.
Disadvantages
  • The process manager built into mod_fastcgi isn't used. One of the motivations behind mod_fcgid was to improve upon the process manager in mod_fastcgi.
  • The newer mod_fcgid cannot be used as it will only send one request at a time to the PHP process, thus multiple requests can't be handled simultaneously
  • Maintaining separate opcode caches per user uses a considerably larger amount of RAM than a single opcode cache used with mod_php
  • Users cannot alter php.ini files
  • If a PHP script crashes it has potential to take down all of the PHP requests currently being processed for that user

Performance

In my next post I'll try to cover RAM usage, performance, benchmarks, compatibility and best practices. This post is already way too long; I'm surprised you are even still reading it!

Stay tuned for more information on using FastCGI with a PHP APC opcode cache. In the meantime let me know what you think of this approach. Have you tried it? Know of a better way? Found any bugs or problems? Leave a comment below!


 
 

Things you can do from here: