Fingki 's Blog

Eclispe自動提示功能設置如下：

第一步：

windows－>preferences->java->Editor->Code   Assist   中

將auto－activetion中的Enable auto-activetion選項要勾選上

這里面有個時間的設定是為提示代碼設定的顯示時間。你可以根據自己的情況設定。

第二步：

window->Preferences->Java->Editor->Content Assist->Advanced   上面的選項卡Select the proposal kinds contained in the 'default' content assist list: 中把 Other Java Proposals 選項打上勾就可以了。

另注：也可以直接恢復成默認設置。

1、單步調試快捷鍵
以debug方式運行java程序后
（F8）直接執行程序。遇到斷點時暫停；
（F5）單步執行程序，遇到方法時進入；
（F6）單步執行程序，遇到方法時跳過；
（F7）單步執行程序，從當前方法跳出。

2、改變變量的值
右擊變量，在彈出的菜單中選擇[change variable value]，彈出修改畫面。
改變其值后，按下ok；這時，變量的值就改為修改后的值了。
3、檢查代碼段是否正確
選擇一句或一段代碼，右鍵單擊在彈出的菜單中選擇Inspect項，
此時，代碼的執行結果將顯示在Expressions窗口中。

要安裝exchange2003，首先要安裝域控，整理安裝過程如下：
1，安裝DNS服務
    如果在安裝Windows Server 2003過程中，沒有選擇DNS組件，默認情況下是不被安裝的，我們就需要手動去添加它。這里我們需要用到Windows Server 2003的安裝光盤。
    添加方法如下:
    “開始—設置—控制面板—添加刪除程序”，
    然后再點擊“添加/刪除Windows組件”
    選中“網絡服務”
    默認情況下所有的網絡服務都會被添加，可以點擊下面的“詳細信息”進行自定義安裝，由于在這里只需要DNS，所以把其它的全都去掉了，以后需要的時候再安裝

    然后就是點“確定”，一直點“下一步”就可以完成整個DNS的安裝。在整個安裝過程中請保證Windows Server 2003安裝光盤位于光驅中，否則會出現找不到文件的提示，那就需要手動定位了。

2，Active Directory安裝
    安裝完DNS以后，就可以進行提升操作了，先點擊“開始—運行”，輸入“Dcpromo”，然后回車就可以看到“Active Directory安裝向導”
    安裝過程按照提示輸入相應內容就可以了，
    但是，當到 “DNS 注冊診斷”這一步時，可能出現診斷失敗，第一次部署時總會出現上面那個DNS注冊診斷出錯的畫面，主要是因為雖然安裝了DNS，但由于并沒有配置它，網絡上還沒有可用的DNS服務器，所以才會出現響應超時的現像，所以在這里要選擇:“在這臺計算機上安裝并配置DNS，并將這臺DNS服務器設為這臺計算機的首選DNS服務器”。
    安裝完成后提示重啟，
    然后來看一下安裝了AD后和沒有安裝的時候有些什么區別，首先第一感覺就是關機和開機的速度明顯變慢了，
    再看一下登陸界面:在“登錄到”選項中選擇剛配置的域名，登錄。
3，檢查是否成功
    進入系統后，右鍵點擊“我的電腦”選“屬性”，點“計算機”
    如果已經登錄上了指定域，
    這臺服務器就被成功提升為域控制器了。

由于最近的項目中要用到kerberos and spnego protocol,查了一些資料,結合網上的資料和對它一定的理解,整理如下,以備后查.(如有不對之處,肯請高手指教)
kerberos是一個很重要的網絡認證協議,它實現了在一個非安全的網絡環境中,一個實體向另一個實體證實自己的身份,從而以安全的方式進行交流.kerberos protocol已經被廣泛應用于各種應用中,最為典型的莫過于windows中的kerberos認證,它在spnego protocol之下,為windows域用戶登錄提供安全保障.
首先相關名詞:
Long term key:就是長期保持不變的key.
Master key:就是Long term key經過Hash運算得到的Hash code.
Short term key:就是只在一定時間內有效的key.有時也叫Session key.
原則上Long term key 是不能在網絡上傳輸的,因為很可能Long term key在傳輸過程中被人截獲,一旦它被截獲,原則上只要有足夠的時間,就可以被破解.另外,對于一個帳戶而言,密碼僅限于該用戶知道,對于domain的Administrator也應該保密,但由于密碼是用戶向Administrator證明身份的憑據,所以要基于用戶的密碼生成來的信息來證明用戶的身份,通常做法是對密碼進行Hash運算,生成Hash code,這個Hash code就是我們說的Master key.因為Hash Algorithm具有不可逆,同時保證了密碼與Master key一一對應的特性,保證了密碼的保密性,也保證了Master key可以代表密碼作為用戶身份的憑證.而作為 Short term key,用來加密在網絡上傳輸的數據,由于它只在一定時間內有效,即使被人截獲,等到被破解時,這個key早就過期了.
Client 服務請求者
Server 服務提供者
KDC kerberos distribution certer.在整個認證過程中作為client和server共同信認的第三方.
以windows2003中的Domain為例,Domain Controller扮演著kdc的角色.

下面我來介紹一下這kerberos協議如何實現認證的.
前提:client和server都在kdc上已注冊.
第一步 Authentication Service Exchange
第二步 Ticket Granting Service Exchange
第三步 Client/Server Exchange
  首先Client向kdc申請server服務,kdc查看server服務是受保護的服務,所以要驗證client的身份,這就是第一步,kdc驗證client的身份(Authentication Service Exchange).當kdc核實client的身份正確后,會給client一個證明,用這個證明我們可以得到訪問server服務的許可證(Ticket),所以我們把這個證明叫做TGT(Ticket Granting Ticket).
當client得到TGT后,用TGT來向kdc索要訪問server服務的通行證(Ticket),這就是第二步Ticket Granting Service Exchange.
當client得到通行證(Ticket)后,就與server交互,向server出示通行證(Ticket),即第三步Client/Server Exchange,從可得到server的服務.
以上三步的具體實現要復雜得多,簡單介紹如下:
1． Authentication Service Exchange

通過這個Sub-protocol，KDC（確切地說是KDC中的Authentication Service）實現對Client身份的確認，并頒發給該Client一個TGT。具體過程如

下：

Client向KDC的Authentication Service發送Authentication Service Request（KRB_AS_REQ）, 為了確保KRB_AS_REQ僅限于自己和KDC知道，

Client使用自己的Master Key對KRB_AS_REQ的主體部分進行加密（KDC可以通過Domain 的Account Database獲得該Client的Master Key）。

KRB_AS_REQ的大體包含以下的內容：

Pre-authentication data：包含用以證明自己身份的信息。說白了，就是證明自己知道自己聲稱的那個account的Password。一般地，它的內容是

一個被Client的Master key加密過的Timestamp。
Client name & realm: 簡單地說就是Domain name\Client Server Name：注意這里的Server Name并不是Client真正要訪問的Server的名稱，而我們也說

了TGT是和Server無關的（Client只能使用Ticket，而不是TGT去訪問Server）。這里的Server Name實際上是KDC的Ticket Granting Service的Server Name。
AS（Authentication Service）通過它接收到的KRB_AS_REQ驗證發送方的是否是在Client name & realm中聲稱的那個人，也就是說要驗證發送放是

否知道Client的Password。所以AS只需從Account Database中提取Client對應的Master Key對Pre-authentication data進行解密，如果是一個合法

的Timestamp，則可以證明發送放提供的是正確無誤的密碼。驗證通過之后，AS將一份Authentication Service Response（KRB_AS_REP

）發送給Client。KRB_AS_REQ主要包含兩個部分：本Client的Master Key加密過的Session Key（

SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大體又包含以下的內容

：

Session Key: SKDC-Client：Logon Session Key
Client name & realm: 簡單地說就是Domain

name\Client
End time: TGT到期的時間。
Client通過自己的Master Key對第一部分解密獲得Session Key（SKDC-Client：Logon Session Key）之后，攜帶著TGT便可以進入下一步：TGS（

Ticket Granting Service）Exchange。

2． TGS（Ticket Granting Service）Exchange

TGS（Ticket Granting Service）Exchange通過Client向KDC中的TGS（Ticket Granting Service）發送Ticket Granting Service Request

（KRB_TGS_REQ）開始。KRB_TGS_REQ大體包含以下的內容：

TGT：Client通過AS Exchange獲得的Ticket

Granting Ticket，TGT被KDC的Master Key進行加

密。
Authenticator：用以證明當初TGT的擁有者是否就是自己，所以它必須以TGT的辦法方和自己的Session Key（SKDC-Client：Logon Session Key

）來進行加密。
Client name & realm: 簡單地說就是Domain name\Client。
Server name & realm: 簡單地說就是Domain name\Server，這回是Client試圖訪問的那個Server。
TGS收到KRB_TGS_REQ在發給Client真正的Ticket之前，先得整個Client提供的那個TGT是否是AS頒發給它的。于是它不得不通過Client提供的

Authenticator來證明。但是Authentication是通過Logon Session Key（SKDC-Client）進行加密的，而自己并沒有保存這個Session Key。所以

TGS先得通過自己的Master Key對Client提供的TGT進行解密，從而獲得這個Logon Session Key（SKDC-Client），再通過這個Logon Session

Key（SKDC-Client）解密Authenticator進行驗證。驗證通過向對方發送Ticket Granting Service Response（KRB_TGS_REP）。這個KRB_TGS_REP有

兩部分組成：使用Logon Session Key（SKDC-Client）加密過用于Client和Server的Session Key（SServer-Client）和使用Server的Master

Key進行加密的Ticket。該Ticket大體包含以下一些內容：

Session Key：SServer-Client。
Client name & realm: 簡單地說就是Domain name\Client。
End time: Ticket的到期時間。
Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后獲得Session Key（SServer-Client）。有了Session Key和

Ticket，Client就可以之間和Server進行交互，而無須在通過KDC作中間人了。所以我們說Kerberos是一種高效的認證方式，它可以直接通

過Client和Server雙方來完成，不像Windows NT 4下的NTLM認證方式，每次認證都要通過一個雙方信任的第3方來完成。

我們現在來看看 Client如果使用Ticket和Server怎樣進行交互的，這個階段通過我們的第3個Sub-protocol來完成：CS（Client/Server ）

Exchange。

3． CS（Client/Server ）Exchange

Client通過TGSExchange獲得Client和Server的Session Key（SServer-Client），隨后創建用于證明自己就是Ticket的真正所有者的Authenticator，并使用Session Key（SServer-Client）進行加密。最后將這個被加密過的Authenticator和Ticket作為Application Service Request（KRB_AP_REQ）發

送給Server。除了上述兩項內容之外，KRB_AP_REQ還包含一個Flag用于表示Client是否需要進行雙向驗證（Mutual Authentication）。

Server接收到KRB_AP_REQ之后，通過自己的Master Key解密Ticket，從而獲得Session Key（SServer-Client）。通過Session Key（SServer

-Client）解密Authenticator，進而驗證對方的身份。驗證成功，讓Client訪問需要訪問的資源，否則直接拒絕對方的請求。

對于需要進行雙向驗證，Server從Authenticator提取Timestamp，使用Session Key（SServer-Client）進行加密，并將其發送給Client用于

Client驗證Server的身份。

想要更深入的理解kerberos,請參考官方網站

http://web.mit.edu/Kerberos/

做SSL以來，一直在使用keytool，下面把它用法整理如下，以備以后查看。
1，產生一個密鑰對
        keytool -genkey -alias mykeypair -keypass mykeypairpwd
    過程如下：
        liqingfeng@liqingfeng:~/WORK_APP/keytooltest$ keytool -genkey -alias mykeypair -keypass mykeypairpwd
        輸入keystore密碼：  123456
        您的名字與姓氏是什么？
          [Unknown]：  fingki
        您的組織單位名稱是什么？
          [Unknown]：  server
        您的組織名稱是什么？
          [Unknown]：  server
        您所在的城市或區域名稱是什么？
          [Unknown]：  bj
        您所在的州或省份名稱是什么？
          [Unknown]：  bj
        該單位的兩字母國家代碼是什么
          [Unknown]：  CN
        CN=fingki, OU=server, O=server, L=bj, ST=bj, C=CN 正確嗎？
          [否]：  y

        liqingfeng@liqingfeng:~/WORK_APP/keytooltest$
    這樣將產生一個keypair,同時產生一個keystore.默認名是.keystore,存放到user-home目錄
    假如你想修改密碼,可以用:keytool -keypasswd -alias mykeypair -keypass mykeypairpwd -new newpass

2，產生一個密鑰對，存放在指定的keystore中（加上-keystore 參數）
    keytool -genkey -alias mykeypair -keypass mykeypairpwd -keystore mykeystore
    過程與上面的相同。
    執行完后，在當前目錄下產生一個名為mykeystore的keystore，里面有一個別名為mykeypair的keypair。

3，檢查一個keystore中的內容
        keytool -list -v -alias mykeypair -keystore mykeystore
        參數    -v指明要列出詳細信息
                -alias指明列出指定的別名為mykeypair的keypair信息（不指定則列出所有）
                -keystore指明要列出名字為mykeystore的keystore中的信息
    過程如下：
        liqingfeng@liqingfeng:~/WORK_APP/keytooltest$ keytool -list -v -keystore mykeystore
        輸入keystore密碼：  123456

        Keystore 類型： jks
        Keystore 提供者： SUN

        您的 keystore 包含 1 輸入

        別名名稱： mykeypair
        創建日期： 2008-4-16
        輸入類型：KeyEntry
        認證鏈長度： 1
        認證 [1]:
        Owner: CN=fingki, OU=server, O=server, L=bj, ST=bj, C=CN
        發照者： CN=fingki, OU=server, O=server, L=bj, ST=bj, C=CN
        序號： 48058c3c
        有效期間： Wed Apr 16 13:18:52 GMT+08:00 2008 至： Tue Jul 15 13:18:52 GMT+08:00 2008
        認證指紋：
             MD5：  FD:C3:97:DC:84:A0:D8:B2:08:6F:26:7F:31:33:C3:05
             SHA1： A3:21:6F:C6:FB:5F:F5:2D:03:DA:71:8C:D3:67:9D:1C:E1:27:A5:11


        *******************************************
        *******************************************


        liqingfeng@liqingfeng:~/WORK_APP/keytooltest$    
 4，Keystore的產生:
    當使用-genkey 或-import或-identitydb命令添加數據到一個keystore,而當這個keystore不存在時,產生一個keystore.默認名是.keystore,存放到user-home目錄.
    當用-keystore指定時,將產生指定的keystore.
5，Keystore的實現:
    Keytool 類位于java.security包下,提供一個非常好的接口去取得和修改一個keystore中的信息. 目前有兩個命令行:keytool和jarsinger,一個GUI工具Policy 可以實現keystore.由于keystore是公開的,用戶可以用它寫一些額外的安全應用程序.
    Keystore還有一個sun公司提供的內在實現.它把keystore作為一個文件來實現.利用了一個keystore類型(格式)"JKS".它用單獨的密碼保護每一個私有鑰匙.也用可能不同的密碼保護整個keystore的完整性.
    支持的算法和鑰匙大小:
    keytool允許用戶指定鑰匙對和注冊密碼服務供應者所提供的簽名算法.缺省的鑰匙對產生算法是"DSA".假如私有鑰匙是"DSA"類型,缺省簽名算法是"SHA1withDSA",假如私有鑰匙是"RSA"類型,缺省算法是"MD5withRSA".
    當產生一個DSA鑰匙對,鑰匙必須在512-1024位之間.對任何算法的缺省鑰匙大小是1024位.
6，關于證書
    一個證書是一個實體的數字簽名,還包含這個實體的公共鑰匙值.
        公共鑰匙 :是一個詳細的實體的數字關聯,并有意讓所有想同這個實體發生信任關系的其他實體知道.公共鑰匙用來檢驗簽名;
        數字簽名:是實體信息用實體的私有鑰匙簽名（加密）后的數據.這條數據可以用這個實體的公共鑰匙來檢驗簽名（解密）出實體信息以鑒別實體的身份;       
        簽名:用實體私有鑰匙加密某些消息，從而得到加密數據;
        私有鑰匙:是一些數字,私有和公共鑰匙存在所有用公共鑰匙加密的系統的鑰匙對中.公共鑰匙用來加密數據，私有鑰匙用來計算簽名.公鑰加密的消息只能用私鑰解密，私鑰簽名的消息只能用公鑰檢驗簽名。
        實體:一個實體可以是一個人,一個組織,一個程序,一臺計算機,一個商業,一個銀行,或其他你想信任的東西. 
    實際上，我們用［1］中的命令已經生成了一個自簽名的證書，沒有指定的參數都使用的是默認值。
    我們也可以用如下命令生成一個自簽名的證書：
        keytool -genkey -dname "CN=fingki,OU=server,O=server,L=bj,ST=bj,C=CN" -alias myCA -keyalg RSA -keysize 1024 -keystore myCALib -keypass 654321 -storepass 123456 -validity 3650
        這條命令將生成一個別名為myCA的自簽名證書，證書的keypair的密碼為654321，證書中實體信息為 "CN=fingki,OU=server,O=server,L=bj,ST=bj,C=CN"，存儲在名為myCALib的keystore中（如果沒有將自動生成一個），這個keystore的密碼為123456，密鑰對產生的算法指定為RSA，有效期為10年。
7，將證書導出到證書文件
    keytool -export -alias myCA -file myCA.cer -keystore myCALib -storepass 123456 -rfc
    使用該命令從名為myCALib的keystore中，把別名為myCA的證書導出到證書文件myCA.cer中。(其中-storepass指定keystore的密碼，-rfc指定以可查看編碼的方式輸出，可省略)。

8，通過證書文件查看證書信息
    keytool -printcert -file myCA.cer
9，密鑰庫中證書條目口令的修改
    Keytool -keypasswd -alias myCA -keypass 654321 -new newpass -storepass 123456 -keystore myCALib
10，刪除密鑰庫中的證書條目
    keytool -delete -alias myCA -keystore myCALib
11，把一個證書文件導入到指定的密鑰庫
    keytool -import -alias myCA -file myCA.cer -keystore truststore
    (如果沒有名為truststore的keystore，將自動創建,將會提示輸入keystore的密碼)
12，更改密鑰庫的密碼
    keytool -storepasswd -new 123456  -storepass 789012 -keystore truststore
    其中-storepass指定原密碼，-new指定新密碼。

具體安裝過程請參考 EJBCA官方說明:http://www.ejbca.org/installation.html
上面說的詳細,需要注意的就是下載合適的jce(Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files ),

    最近在研究域控制器方面的問題，看到一論壇上有關工作組和域的介紹很不錯，摘錄下來如下：
    工作組Work   Group  
 在一個網絡內，可能有成百上千臺電腦， 如果這些電腦不進行分組，都列在“網上鄰居”內，可想而知會有多么亂。為了解決這一問題，Windows   9x/NT/2000就引用了“工作組”這個概念，將不同的電腦一般按功能分別列入不同的組中，如財務部的電腦都列入“財務部”工作組中，人事部的電腦都 列入“人事部”工作組中。你要訪問某個部門的資源，就在“網上鄰居”里找到那個部門的工作組名，雙擊就可以看到那個部門的電腦了。  
  　　那么怎么加入工作組呢？其實很簡單，你只需要右擊你的Windows桌面上的“網上鄰居”，在彈出的菜單出選擇“屬性”，點擊“標識”，在“計算機名”一欄中添入你想好的名字，在“工作組”一欄中添入你想加入的工作組名稱。  
 如果你輸入的工作組名稱以前沒有，那么相當于新建一個工作組，當然只有你的電腦在里面。計算機名和工作組的長度不能超過15個英文字符，可以輸入漢字，但是不能超過7個。“計算機說明”是附加信息，不填也可以，但是最好填上一些這臺電腦主   人的信息，如“技術部主管”等。單擊[確定]按鈕后，Windows   98提示需要重新啟動，按要求重新啟動之后，再進入“網上鄰居”，就可以看到你所在工作組的成員了。  
  　　一般來說，同一個工作組內部成員相互交換信息的頻率最高，所以你一進入“網上鄰居”，首先看到的是你所在工作組的成員。如果要訪問其他工作組的成員，需要雙擊“整個網絡”，就會看到網絡上所有的工作組，雙擊工作組名稱，就會看到里面的成   員。  
  你也可以退出某個工作組，只要將工作組名稱改動即可。不過這樣在網上別人照樣可以訪問你的共享資源，只不過換了一個工作組而已。你可以隨便加入同一網 絡上的任何工作組，也可以離開一個工作組。“工作組”就像一個自由加入和退出的俱   樂   部一樣，它本身的作用僅僅是提供一個“房   間”，以方便網上計算機共享資源的瀏覽。
    域  
 在“域”模式下，至少有一臺服務器負責每一臺聯入網絡的電腦和用戶的驗證工作，相當于一個單位的門衛一樣，稱為“域控制器(Domain   Controller，簡寫為DC)”。“域控制器”中包含了由這個域的賬戶、密碼、 屬于這個域的計算機等信息構成的數據庫。當電腦聯入網絡時，域控制器首先要鑒別這臺電腦是否是屬于這個域的，用戶使用的登錄賬號是否存在、密碼是否正確。 如果以上信息不正確，域控制器就拒絕這個用戶從這臺電腦登錄。不能登錄，用戶就不能訪問服務器上有權限保護的資源，只能以對等網用戶的方式訪問 Windows共享出來的資源，這樣就一定程度上保護了網絡上的資源。    
   
 想把一臺電腦加入域，僅僅使它和服務器在“網上鄰居”能夠相互看到是遠遠不夠的，必須要由網絡管理員進行把這臺電腦加入域的相關操作。操作過程由服務器端設置和客戶端設置構成。    
   
  　　1、服務器端設置    
   
 以系統管理員身份在已經設置好Active   Directory(活動目錄)的Windows   2000   Server上登錄，點擊“開始/程序/ 管理工具/Active   Directory用戶和計算機”，在程序界面中右擊“computers”(計算機)，在彈出的菜單中單擊“新建/計算機”填入想要加入域的計算機名即 可。要加入域的計算機名最好為英文，否則系統會提示中文計算機名可能會引起一些問題。    
   
  　　2、客戶端設置    
   
  　　首先要確認計算機名稱是否正確，然后在桌面“網上鄰居”上右擊鼠標，點擊“屬性”出現網絡屬性設置窗口，確認“主網絡登錄”為“Microsoft網絡用戶”。    
   
  選中窗口上方的“Microsoft網絡用戶”(如果沒有此項，說明沒有安裝，點擊[添加]安裝“Microsoft網絡用戶”項)。點擊[屬性]按 鈕，出現“Microsoft網絡用戶屬性”對話框，選中“登錄到Windows   NT域”復選框，在“Windows   NT域”中輸入要登錄的域名。    
   
  　　Windows   98會提示需要重新啟動計算機，重新啟動后，會出現一個登錄對話框。在輸入正確的域用戶賬號、密碼以及登錄域之后，就可以使用Windows   2000   Server域中的資源了。請注意，這里的域用戶賬號和密碼，必須是網絡管理員為用戶建的那個賬號和密碼，而不是由本機用戶自己創建的賬號和密碼。如果沒 有將計算機加入域，或者登錄的域名、用戶名、密碼有一項不正確，就會出現錯誤信息。

     摘要: 這是MIT（MassachusettsInstituteofTechnology）為了幫助人們理解Kerberos的原理而寫的一篇對話集。里面有兩個虛構的人物：Athena和Euripides，通過Athena不斷的構思和Euripides不斷的尋找其中的漏洞，使大家明白了Kerberos協議的原理。 Athena:雅典娜，智慧與技藝的女神。 Euripides:歐里庇得斯,希臘的悲劇詩人。 ...  閱讀全文

    在linux下（我用的是ubuntu7），用新立得軟件包安裝好postgres數據庫和pgAdmin后，在pgAdmin中用默認的postgres用戶無法登錄。
    上網google了一下，沒找到解決方法，后一朋友告訴我要新建一個用戶才行，具體做法如下：
    1、在命令行下修改用戶postgres的密碼：sudo passwd postgres
       然后輸入你要設置的密碼
    2、在命令行下切換到postgres用戶：su postgres
       然后輸入剛才設置的密碼，登錄。
    3、在postgres用戶下創建新的超級用戶：createuser －P testuser
    具體過程如下：
        postgres@liqingfeng:/$ createuser -P testuser
        Enter password for new role:
        再輸入一遍:
        Shall the new role be a superuser? (y/n) y
        CREATE ROLE
    4、這樣就可以在pgAdmin在用新建的用戶testuser來登錄了。
    之后可以在pgAdmin中做你想做的一切。
    （關于createuser這個命令具體其他參數，可以在終端輸入：man createuser 來查看細節）

    今天用Eclipse中用ant運行build.xml腳本打包工程，突然ant不工作了，
    查看Eclipse的Error log，顯示
    Error logged from Ant UI:

	Exception Stack Trace:



java.net.SocketTimeoutException: Accept timed out



at java.net.PlainSocketImpl.socketAccept(Native Method)



at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)



at java.net.ServerSocket.implAccept(ServerSocket.java:448)



at java.net.ServerSocket.accept(ServerSocket.java:419)



查看build.xml文件無異常，讓我好是奇怪，明明昨天還是正常的呀。



后來查看一下Ant Home,發現只有四項，覺得有點不對勁，他細一看，居然指到了/home/fingki/eclipse/plugins/Axis2_service_Archiver_1.3.0/lib下，



重新指定一下Ant Home,運行ant，運行了。



后來研究才發現，原來之前剛裝了Axis2的plugins,Axis2_service_Archiver_1.3.0，這樣Eclipse重啟后優先把Ant Home指向那了，導致ant不工作了。



看來Axis2_service_Archiver_1.3.0這個plugins還是有些bug呀。



具體設置Ant Home如下：在Eclipse中－＞window－＞preferences－＞Ant－＞Runtime－＞Classpath，點擊Ant home按鈕，重新讓其指向eclipse中的ant的plugins文件夾處，



一般都在%Eclipse_home%/plugins/org.apache.ant_1.x.x。