與
Linux中斷息息相關的一個重要概念是Linux中斷分為兩個半部：上半部（tophalf）和下半部(bottom half)。上半部的功能是"登記中斷"，當一個中斷發生時，它進行相應地硬件讀寫后就把中斷例程的下半部掛到該設備的下半部執行隊列中去。因此，上半部 執行的速度就會很快，可以服務更多的中斷請求。但是，僅有"登記中斷"是遠遠不夠的，因為中斷的事件可能很復雜。因此，Linux引入了一個下半部，來完 成中斷事件的絕大多數使命。下半部和上半部最大的不同是下半部是可中斷的，而上半部是不可中斷的，下半部幾乎做了中斷處理程序所有的事情，而且可以被新的 中斷打斷！下半部則相對來說并不是非常緊急的，通常還是比較耗時的，因此由系統自行安排運行時機，不在中斷服務上下文中執行。
Linux實現下半部的機制主要有tasklet和工作隊列。 Tasklet基于Linux softirq，其使用相當簡單，我們只需要定義tasklet及其處理函數并將二者關聯：
void my_tasklet_func(unsigned long); //定義一個處理函數：
DECLARE_TASKLET(my_tasklet,my_tasklet_func,data); //定義一個tasklet結構my_tasklet，與
my_tasklet_func(data)函數相關聯
然后，在需要調度tasklet的時候引用一個簡單的API就能使系統在適當的時候進行調度運行：
tasklet_schedule(&my_tasklet);
此外，Linux還提供了另外一些其它的控制tasklet調度與運行的API：
DECLARE_TASKLET_DISABLED(name,function,data); //與DECLARE_TASKLET類似，但等待tasklet被使能
tasklet_enable(struct tasklet_struct *); //使能tasklet
tasklet_disble(struct tasklet_struct *); //禁用tasklet
tasklet_init(struct tasklet_struct *,void (*func)(unsigned long),unsigned long); //類似
DECLARE_TASKLET()
tasklet_kill(struct tasklet_struct *); // 清除指定tasklet的可調度位，即不允許調度該tasklet
我們先來看一個tasklet的運行實例，這個實例沒有任何實際意義，僅僅為了演示。它的功能是：在globalvar被寫入一次后，就調度一個tasklet，函數中輸出"tasklet is executing"：
#include … //定義與綁定tasklet函數 void test_tasklet_action(unsigned long t); DECLARE_TASKLET(test_tasklet, test_tasklet_action, 0); void test_tasklet_action(unsigned long t) { printk("tasklet is executing\n"); } … ssize_t globalvar_write(struct file *filp, const char *buf, size_t len, loff_t *off) { … if (copy_from_user(&global_var, buf, sizeof(int))) { return - EFAULT; } //調度tasklet執行 tasklet_schedule(&test_tasklet); return sizeof(int); } |
下半部分的任務就是執行與中斷處理密切相關但中斷處理程序本身不執行的工作。在Linux2.6的內核中存在三種不同形式的下半部實現機制：軟中斷，tasklet和工作隊列。
下面將比較三種機制的差別與聯系。
軟中斷： 1、軟中斷是在編譯期間靜態分配的。
2、最多可以有32個軟中斷。
3、軟中斷不會搶占另外一個軟中斷，唯一可以搶占軟中斷的是中斷處理程序。
4、可以并發運行在多個CPU上（即使同一類型的也可以）。所以軟中斷必須設計為可重入的函數（允許多個CPU同時操作），
因此也需要使用自旋鎖來保護其數據結構。
5、目前只有兩個子系直接使用軟中斷：網絡和SCSI。
6、執行時間有：從硬件中斷代碼返回時、在ksoftirqd內核線程中和某些顯示檢查并執行軟中斷的代碼中。
tasklet： 1、tasklet是使用兩類軟中斷實現的：HI_SOFTIRQ和TASKLET_SOFTIRQ。
2、可以動態增加減少，沒有數量限制。
3、同一類tasklet不能并發執行。
4、不同類型可以并發執行。
5、大部分情況使用tasklet。
工作隊列： 1、由內核線程去執行，換句話說總在進程上下文執行。
2、可以睡眠，阻塞。
碰巧用到Proto,算是筆記吧算是筆記吧，
windows :
1,兩個文件：proto.exe, protobuf-java-2.4.1.jar
2,建立一個工程TestPb，在下面建立一個proto文件件，用來存放【。proto】文件
3，將proto,exe放在工程下，
4，建立一個msg.proto文件：
option java_package = "com.protobuftest.protobuf"; option java_outer_classname = "PersonProbuf"; message Person { required string name = 1; required int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; message CountryInfo { required string name = 1; required string code = 2; optional int32 number = 3; } } message AddressBook { repeated Person person = 1; } |
5，生成
java文件：在proto.exe目錄下：protoc --java_out=./src ./proto/msg.proto
6,copy個測試示例了
新建一個文件TestPb.java
*********************************************************** package com.protobuftest.protobuf; import java.util.List; import com.google.protobuf.InvalidProtocolBufferException; import com.protobuftest.protobuf.PersonProbuf; import com.protobuftest.protobuf.PersonProbuf.Person; import com.protobuftest.protobuf.PersonProbuf.Person.PhoneNumber; public class TestPb { /** * @param args */ public static void main(String[] args) { // TODO Auto-generated method stub PersonProbuf.Person.Builder builder = PersonProbuf.Person.newBuilder(); builder.setEmail("kkk@email.com"); builder.setId(1); builder.setName("TestName"); builder.addPhone(PersonProbuf.Person.PhoneNumber.newBuilder().setNumber("131111111").setType(PersonProbuf.Person.PhoneType.MOBILE)); builder.addPhone(PersonProbuf.Person.PhoneNumber.newBuilder().setNumber("011111").setType(PersonProbuf.Person.PhoneType.HOME)); Person person = builder.build(); byte[] buf = person.toByteArray(); try { Person person2 = PersonProbuf.Person.parseFrom(buf); System.out.println(person2.getName() + ", " + person2.getEmail()); List<PhoneNumber> lstPhones = person2.getPhoneList(); for (PhoneNumber phoneNumber : lstPhones) { System.out.println(phoneNumber.getNumber()); } } catch (InvalidProtocolBufferException e) { // TODO Auto-generated catch block e.printStackTrace(); } System.out.println(buf); } } |
***********************************************
*******************************
生成java文件:PersonProbuf.java
*******************************
工程文件結構：
很多
測試人員很有興趣, 管理高層是怎么看待測試團隊? 作者問了一群有資深的測試人員和測試經理, 得到以下的答案:
What is the point?
Necessary evil
Ad hoc
Why so much time?
Too slow
Overstaffed
Too many excuses
Testing should find everything
Quality gatekeeper
Find bugs too late
Testing less value than other disciplines
作者認為由這些答案, 可以知道可能很多高階主管是不太了解測試到底在做什么.
測試人員必須要對自己的
工作成果, 設定較高的期待. 因為使用者和資深管理者, 會期望測試人員需要找到所有的bugs. 這種期待是不可能, 也不切實際的.
如果有太多的bugs被產生在系統中, 其中一種解決的方法, 就是藉由大量的測試和修復bugs, 來維持質量. 但是, 可能較好的方法, 是想辦法去了解客戶要什么, 產生較好的requirement, 或者一開始便產生較有質量的程序代碼.
測試并是不要做質量的把關者, 測試的目的不應該只是去保證受測系統的質量, 而是要去衡量其質量
最后作者和大家分享這兩句話, 很值得大家思考一下:
1. The purpose of testing is not to ensure the quality of the software, but rather to measure its quality
2. Testing is just one facet of the quality solution. Responsibility for the quality of the product must reside in the entire team
最新做的一個項目，被
測試組猛烈攻擊，暴露了不少問題。其中一個問題印象深刻！
測試使用了WebInspect這個掃描工具，掃描了整個網站，包括后臺。結果我們的
數據庫里被灌入大量的垃圾數據，并修改了原有的數據?？傊瑧K不忍睹！
后來，我們發現我們后臺的一個簡單的檢查是否登錄的方法有問題:在判定未登錄時，使用php header()跳轉頁面，沒有在這個方法執行后退出執行。這樣的話，頁面跳轉，但在header()下面的代碼依然會執行。
現總結下php header()使用時注意的問題：
1、location和“:”號間不能有空格，否則會出錯。
2、在用header前不能有任何的輸出。
3、header后的PHP代碼還會被執行。記得加exit() 或者die 退出。
另外，后臺登錄地址注意安全，不讓他人輕易猜到！
據悉，
黑盒測試方法是現今
移動測試最多的測試方式。這意味著手動測試將貫穿整個軟件發布周期的前前后后。但是手動測試還存在問題，理由有幾點：它大大減慢了開發過程，給錯誤的發生留下很多余地，最終會降低團隊在短時間內發布高質量軟件的信心。
ThreadingTest（下面簡稱TT）是一款國產化的
白盒測試工具，100%Java語法支持，最高支持Java1.7版本（小型有安卓
游戲測試、大型如liferay網站的測試），TT都能通過簡單的插裝，自動建立
測試用例與程序源代碼之間的邏輯關系，又通過自動化的生成 CallGraph、ControlFlow 等視圖，讓以往的移動黑盒測試轉變成透明化的白盒測試。
TT率先將引入的測試示波器概念，在實際測試的過程中，可以實時的看到從程序中各種邏輯體執行的速率、頻率等信息，測試人員可以從傳統的對被測應用的黑盒子測試（僅能看到功能的反饋無法看到程序內部的反饋）進而轉換成為類似于對于硬件測試的示波器一樣，能夠對整個測試過程的關鍵測試數據進行實時的分析和查看。
二、 如何打破測試和開發之間的對立關系，提倡需求變更？
據悉，以往軟件需求變更會給項目帶來巨大的風險，會導致項目的成本費用增加、開發周期延長、產品質量下降及團隊
工作效率下降等不良后果，因而需求變更在
軟件開發項目中應該盡量避免，但是在現今IT行業高速發展的情況下，為了達到市場的需求，頻繁的需求變更是迫在眉睫的，這也是開發和測試對立的主要焦點。
TT采用正向追溯和反向追溯的功能，自動化的展示連接代碼和被測功能模塊的關系，來引導開發與測試合作完成100%覆蓋率測試。
1. 正向追溯：在TT中開發工程師可以通過雙向追溯界面，觀看到測試工程師執行用例經過的代碼細節、運行的次數、模塊的覆蓋率等，這樣能高效的進行開發工程師和測試工程師之間的互動，當覆蓋率不全或出現BUG時，也為開發快速定位和修復缺陷提供依據。
2. 反向追溯：在TT中測試工程師可以通過雙向追溯界面，觀看到某一些代碼到底和哪些功能點有關，當進行需求變更時，測試人員能快速的定位到那些被修改的代碼
所對應影響的功能，而不是盲目的進行整個工程的反復測試，這為縮短測試時間和提高產品質量提供了便捷的路徑，并為測試人員自身的理解提供了一個便捷的平臺。
三、 是否有一款移動測試工具支持多語言、多平臺、多應用，并且支持移動模擬器和真機的雙重測試？
據悉，現今市場上的測試工具多數以國外軟件為主，在使用和享受服務過程中，會產生功能繁瑣、平臺不同、售后服務等問題。
1． TT采用傻瓜式的操作方式，引導測試工程師逐步的提升測試質量。
2． TT程序具有跨平臺技術特性，已經推出windows版本，可以輕松的擴展到linux，mac os等環境下運行。
3． TT 支持移動模擬器和真機的雙重測試，讓測試人員在真機上也能進行正規化的白盒測試。
Informatica
測試數據管理解決方案可幫助 IT 組織創建功能完整、安全的
數據庫應用程序測試數據子集。 支持數據庫應用程序的 IT 組織常常會制作生產環境的多個副本來用于開發、測試和培訓。 然而，隨著生產數據庫的增大，制作這些副本將會用掉成本高昂的存儲空間和系統資源，同時會讓公司陷入因數據泄露而導致財務損失的風險。 借助 Informatica 測試數據管理解決方案，公司可以避免：
過高的數據管理成本
未能有效遵守隱私法規
由數據泄露而導致的聲譽、客戶和收入損失
借助測試數據管理降低成本和風險
Informatica 測試數據管理解決方案無需使用生產數據的完整集合，因此可以讓貴公司：
縮短開發周期：使用較小的測試數據集合，通過測試數據管理縮短開發周期
降低 IT 成本：實施測試數據管理時使用較小的數據集合，這樣所需的存儲和系統資源也較少
支持合規性：屏蔽的數據符合所需的測試質量級別，這是成功測試數據管理的關鍵，同時確保數據隱私
快速部署：通過使用預打包或自定義的子集化和屏蔽政策進行測試數據管理，可以快速創建安全的數據子集，同時保持參考完整性
借助測試數據管理提高質量和安全性
Informatica 測試數據管理解決方案創建安全的測試數據管理子集，同時將成本、風險和開發時間降到最少。 通過實現測試數據管理子集和屏蔽操作的自動化，該解決方案允許您的 IT 團隊專注于其它開發活動。 測試數據管理甚至于可縮小您測試和開發環境的規模，這樣您便可以將回收的存儲空間重新分配于其它方面。
借助測試數據管理提高生產率和靈活性
Informatica 測試數據管理解決方案還可以重復地復制生產數據，以為測試數據管理創建安全、最新的非生產環境。 測試數據管理的子集政策可以包括任何規則組合，例如數據的使用年限、部門或國家、數據范圍或值。 適用于
Oracle Applications 或 SAP 等應用程序的預打包測試數據管理政策進一步簡化了開發和測試。
1、創建qunit.html 文件添加由官方提供的cdn 加載
測試框架
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>QUnit Example</title> <link rel="stylesheet" > </head> <body> <div id="qunit"></div> <div id="qunit-fixture"></div> <script src="http://code.jquery.com/qunit/qunit-1.15.0.js"></script> <script src="project.js"></script> <script src="tests.js"></script> </body> </html> |
最后面引入的 project.js 就是待測試的文件
最后面引入的 tests.js 就是
測試用例的文件
2、測試用例的編寫
先寫一個待測試例子，這是一個判斷是否是偶數的方法
//project.js function isEven(val) { return val % 2 === 0; } |
3、編寫測試
//tests.js<br>test('isEven()', function() { ok(isEven(0), 'Zero is an even number'); ok(isEven(2), 'So is two'); ok(isEven(-4), 'So is negative four'); ok(!isEven(1), 'One is not an even number'); ok(!isEven(-7), 'Neither is negative seven'); }) |
IT行業發展到現在，安全問題已經變得至關重要，從最近的“棱鏡門”事件中，折射出了很多安全問題，信息安全問題已變得刻不容緩，而做為運維人員，就必須了解一些安全運維準則，同時，要保護自己所負責的業務，首先要站在攻擊者的角度思考問題，修補任何潛在的威脅和漏洞。
下面通過一個案例介紹下當一個服務器被rootkit入侵后的處理思路和處理過程，rootkit
攻擊是Linux系統下最常見的攻擊手段和攻擊方式。
1、受攻擊現象
這是一臺客戶的門戶網站服務器，托管在電信機房，客戶接到電信的通知：由于此服務器持續對外發送數據包，導致100M帶寬耗盡，于是電信就切斷了此服務器的網絡。此服務器是Centos5.5版本，對外開放了80、22端口。
從客戶那里了解到，網站的訪問量并不大，所以帶寬占用也不會太高，而耗盡100M的帶寬是絕對不可能的，那么極有可能是服務器遭受了流量攻擊，于是登錄服務器做詳細的檢測。
2、初步分析
在電信人員的配合下通過交換機對該服務器的網絡流量進行了檢測，發現該主機確實存在對外80端口的掃描流量，于是登錄系統通過“netstat –an”命令對系統開啟的端口進行檢查，可奇怪的是，沒有發現任何與80端口相關的網絡連接。接著使用“ps –ef”、“top”等命令也沒有發現任何可疑的進程。于是懷疑系統是否被植入了rootkit。
為了證明系統是否被植入了rootkit，我們將網站服務器下的ps、top等命令與之前備份的同版本可信
操作系統命令做了md5sum校驗，結果發現網站服務器下的這兩個命令確實被修改過，由此斷定，此服務器已經被入侵并且安裝了rootkit級別的后門程序。
3、斷網分析系統
由于服務器不停向外發包，因此，首先要做的就是將此服務器斷開網絡，然后分析系統日志，尋找攻擊源。但是系統命令已經被替換掉了，如果繼續在該系統上執行操作將變得不可信，這里可以通過兩種方法來避免這種情況，第一種方法是將此服務器的硬盤取下來掛載到另外一臺安全的主機上進行分析，另一種方式就是從一個同版本可信操作系統下拷貝所有命令到這個入侵服務器下某個路徑，然后在執行命令的時候指定此命令的完整路徑即可，這里采用第二種方法。
我們首先查看了系統的登錄日志，查看是否有可疑登錄信息，執行如下命令：
more /var/log/secure |grep Accepted
通過對命令輸出的查看，有一條日志引起了我們的懷疑：
Oct 3 03:10:25 webserver sshd[20701]: Accepted password for mail from 62.17.163.186 port 53349 ssh2
這條日志顯示在10月3號的凌晨3點10分，有個mail帳號從62.17.163.186這個IP成功登錄了系統，mail是系統的內置帳號，默認情況下是無法執行登錄操作的，而62.17.163.186這個IP，經過查證，是來自愛爾蘭的一個地址。從mail帳號登錄的時間來看，早于此網站服務器遭受攻擊的時間。
接著查看一下系統密碼文件/etc/shadow，又發現可疑信息：
mail:$1$kCEd3yD6$W1evaY5BMPQIqfTwTVJiX1:15400:0:99999:7:::
很明顯，mail帳號已經被設置了密碼，并且被修改為可遠程登錄，之所以使用mail帳號，猜想可能是因為入侵者想留下一個隱蔽的帳號，以方便日后再次登錄系統。
然后繼續查看其他系統日志，如/var/log/messages、/var/log/wtmp均為空文件，可見，入侵者已經清理了系統日志文件，至于為何沒有清空/var/log/secure文件，就不得而知了。
4、尋找攻擊源
到目前為止，我們所知道的情況是，有個mail帳號曾經登錄過系統，但是為何會導致此網站服務器持續對外發送數據包呢？必須要找到對應的攻擊源，通過替換到此服務器上的ps命令查看系統目前運行的進程，又發現了新的可疑：
nobody 22765 1 6 Sep29 ? 4-00:11:58 .t
這個.t程序是什么呢，繼續執行top命令，結果如下：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22765 nobody 15 0 1740m 1362m 1228 S 98.3 91.5 2892:19 .t
從輸出可知，這個t程序已經運行了4天左右，運行這個程序的是nobody用戶，并且這個t程序消耗了大量的內存和cpu，這也是之前客戶反映的網站服務器異常緩慢的原因，從這個輸出，我們得到了t程序的進程PID為22765，接下來根據PID查找下執行程序的路徑在哪里：
進入內存目錄，查看對應PID目錄下exe文件的信息：
[root@webserver ~]# /mnt/bin/ls -al /proc/22765/exe
lrwxrwxrwx 1 root root 0 Sep 29 22:09 /proc/22765/exe -> /var/tmp/…/apa/t
這樣就找到了進程對應的完整程序執行路徑，這個路徑很隱蔽，由于/var/tmp目錄默認情況下任何用戶可讀性，而入侵者就是利用這個漏洞在/var/tmp目錄下創建了一個“…”的目錄，而在這個目錄下隱藏著攻擊的程序源，進入/var/tmp/…/目錄，發現了一些列入侵者放置的rootkit文件，列表如下：
[root@webserver ...]#/mnt/bin/ls -al drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 apa -rw-r--r-- 1 nobody nobody 0 Sep 29 22:09 apa.tgz drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 caca drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 haha -rw-r--r-- 1 nobody nobody 0Sep 29 22:10 kk.tar.gz -rwxr-xr-x 1 nobody nobody 0 Sep 29 22:10 login -rw-r--r-- 1 nobody nobody 0 Sep 29 22:10 login.tgz -rwxr-xr-x 1 nobody nobody 0 Sep 29 22:10 z |
通過對這些文件的分析，基本判斷這就是我們要找的程序攻擊源，其中：
1）、z程序是用來清除系統日志等相關信息的，例如執行：
./z 62.17.163.186
這條命令執行后，系統中所有與62.17.163.186有關的日志將全部被清除掉。
2）、在apa目錄下有個后門程序t，這個就是之前在系統中看到的，運行此程序后，此程序會自動去讀apa目錄下的ip這個文件，而ip這個文件記錄了各種ip地址信息，猜想這個t程序應該是去掃描ip文件中記錄的所有ip信息，進而獲取遠程主機的權限，可見這個網站服務器已經是入侵者的一個肉雞了。
3）、haha目錄里面放置的就是用來替換系統相關命令的程序，也就是這個目錄下的程序使我們無法看到操作系統的異常情況。
4）、login程序就是用來替換系統登錄程序的木馬程序，此程序還可以記錄登錄帳號和密碼。
5、查找攻擊原因
到這里為止，服務器上遭受的攻擊已經基本清晰了，但是入侵者是如何侵入這臺服務器的呢？這個問題很重要，一定要找到入侵的根源，才能從根本上封堵漏洞。
為了弄清楚入侵者是如何進入服務器的，需要了解下此服務器的軟件環境，這臺服務器是一個基于java的web服務器，安裝的軟件有apache2.0.63、tomcat5.5，apache和tomcat之間通過mod_jk模塊進行集成，apache對外開放80端口，由于tomcat沒有對外開放端口，所以將問題集中到apache上面。
通過查看apache的配置發現，apache僅僅處理些靜態資源請求，而網頁也以靜態頁面居多，所以通過網頁方式入侵系統可能性不大，既然漏洞可能來自于apache，那么嘗試查看apache日志，也許能發現一些可疑的訪問痕跡，通過查看access.log文件，發現了如下信息：
62.17.163.186 - - [29/Sep/2013:22:17:06 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;echo;ps+-aux%00 HTTP/1.0" 200 12333 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"
62.17.163.186 - - [29/Sep/213:22:17:35 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;echo;cd+/var/tmp/.../haha;ls+-a%00 HTTP/1.0" 200 1626 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"
至此，發現了漏洞的根源，原來是awstats.pl腳本中configdir的一個漏洞，通過了解此服務器的應用，客戶確實是通過一個Awstats的開源插件來做網頁訪問統計，通過這個漏洞，攻擊者可以直接在瀏覽器上操作服務器，例如查看進程、創建目錄等。通過上面第二條日志可以看出，攻擊者正常瀏覽器執行切換到/var/tmp/.../haha目錄的操作。
這個腳本漏洞挺可怕的，不過在Awstats官網也早已給出了修補的方法，對于這個漏洞，修復方法很簡單，打開awstats.pl文件，找到如下信息：
if ($QueryString =~ /configdir=([^&]+)/i)
{
$DirConfig=&DecodeEncodedString("$1");
}
修改為如下即可：
if ($QueryString =~ /configdir=([^&]+)/i)
{
$DirConfig=&DecodeEncodedString("$1");
$DirConfig=~tr/a-z0-9_\-\/\./a-z0-9_\-\/\./cd;
}
6、揭開謎團
通過上面逐步分析和介紹，此服務遭受入侵的原因和過程已經非常清楚了，大致過程如下：
?。?）攻擊者通過Awstats腳本awstats.pl文件的漏洞進入了系統，在/var/tmp目錄下創建了隱藏目錄，然后將rootkit后門文件傳到這個路徑下。
?。?）攻擊者通過植入后門程序，獲取了系統超級用戶權限，進而控制了這臺服務器，通過這臺服務器向外發包。
?。?）攻擊者的IP地址62.17.163.186可能是通過代理過來的，也可能是攻擊者控制的其他肉雞服務器。
（4）攻擊者為了永久控制這臺機器，修改了系統默認帳號mail的信息，將mail帳號變為可登錄，并且設置了mail帳號的密碼。
?。?）攻擊者在完成攻擊后，通過后門程序自動清理了系統訪問日志，毀滅了證據。
通過對這個入侵過程的分析，發現入侵者的手段還是非常簡單和普遍的，雖然入侵者刪除了系統的一些日志，但是還是留下了很多可查的蹤跡，其實還可以查看用戶下的.bash_history文件，這個文件是用戶操作命令的歷史記錄。
7、如何恢復網站
由于系統已經文件被更改和替換，此系統已經變得完全不可信，因此建議備份網站數據，重新安裝系統，基本步驟如下：
（1）安裝穩定版本的操作系統，刪除系統默認的并且不需要的用戶。
（2）系統登錄方式改為公鑰認證方式，避開密碼認證的缺陷。
?。?）安裝更高版本的apache和最新穩定版本的Awstats程序。
?。?）使用Linux下的Tcp_Wrappers防火墻，限制ssh登錄的源地址。
集算器支持包括
數據庫在內的多種異構數據源。這里，我們通過例子來看一下集算器訪問數據庫的方法。
集算器可以連接數據庫的jdbc驅動，也可以通過jdbc-odbc橋連接數據庫。由于版權的原因，使用集算器的程序員需要自行準備數據庫的jdbc或者odbc驅動。Jdbc驅動jar包準備好之后，需要放入集算器IDE安裝目錄的/common/jdbc中，例如：C:\Program Files (x86)\MicroInsight\common\jdbc目錄中。
集算器集成開發環境的ODBC配置界面如下：
集算器的集成開發環境提供了多種數據庫的jdbc配置提示，包括：SQLserver、
Oracle、DB2、Sybase、Access、mysql、hsql、teradata、postgres等。如果需要連接的數據庫不在這個范圍內，可以使用other類型來添加。配置界面如下：
驅動jar包放好，配置完成之后，在IDE中就可以很方便的連接數據庫，取出表中的數據：
上圖中A1單元格連接上了一個名為demo的hsql數據庫，A2單元使用
sql語句查詢了employee表，作為集算器的序表存入了A2單元格這個變量中，arg1是外部傳入的參數。A3單元格關閉了數據庫連接，A4單元格對外返回查詢結果。集算器的集成開發環境右下角紅框中可以顯示demo數據庫的表名、字段名，可以方便程序員書寫sql語句。
和集算器提供的其他函數一樣，query函數包含選項和參數。如果寫成query@1(“select * from employee”)，@1是表示使用了1選項，查看函數說明可知，是僅僅返回sql語句取出的第一條記錄。而括號中是參數，上圖的括號中是一條sql語句的字符串，沒有其他參數，也就是說其他所有的參數都使用了默認值。
上圖中的集算器網格程序可以集成到Java應用中，作為集算器jdbc驅動被Java程序調用，具體方法是：
1、 準備dfx文件。
2、 部署集算器jar包。
將調用集算器程序所必須的jar包放入Java應用的classpath中。如果是
web應用，可以放在WEB-INF/lib目錄下。這些jar包都位于集算器IDE的安裝目錄\esProc\lib下，包括：
dm.jar 集算器計算引擎及JDBC驅動包
poi-3.7-20101029.jar 處理對Excel文件的讀寫
log4j_128.jar 處理日志
icu4j_3_4_5.jar 處理國際化
dom4j-1.6.1.jar 解析配置文件
3、 部署數據庫驅動jar包。
將集算器連接數據庫所需要的數據庫jdbc驅動包也放入Java應用的classpath中。例如：demo數據庫的hsql.jar。
4、 配置dfxConfig.xml、config.xml文件。
config.xml文件中包含了集算器的基本配置信息，如注冊碼、尋址路徑、主目錄、數據源配置等，可以在集算器安裝目錄的esProc\config路徑下找到，其中存儲的信息與集算器的選項頁面中設定相同。dfxConfig.xml可以在安裝目錄esProc\classes中找到。這里介紹集算器連接數據庫的部分配置，其他配置參見集算器教程。
1）配置數據源的方式之一：直接配置數據庫數據源連接參數。
config.xml文件：
<DBList> <!-- 數據源名稱，必須與dfx文件中的數據源名稱一致 --> <DBname="demo"> <propertyname="url" value="jdbc:hsqldb:hsql://127.0.0.1/demo"/> <propertyname="driver" value="org.hsqldb.jdbcDriver"/> <propertyname="type" value="HSQL"/> <propertyname="user" value="sa"/> <propertyname="password" value=""/> <propertyname="batchSize" value="1000"/> <!-- 是否自動連接。如果設定為true，則可以直接使用db.query()函數來訪問數據庫；如果為false，則不會自動連接，使用前必須用connect(db)語句連接。 --> <propertyname="autoConnect" value="true"/> <property name="useSchema"value="false"/> <propertyname="addTilde" value="false"/> </DB> </DBList> |
2）配置數據源的方式之二：在Java應用中配置連接池和jndi，在dfxConfig.xml文件中指定jndi名稱。
dfxConfig.xml文件：
<jndi-ds-configs> <!-- jndi前綴 --> <jndi-prefix>java:comp/env</jndi-prefix> <!-- 數據源名稱，必須與dfx文件中的數據源名稱一致 --> <jndi-ds-config> <name>demo</name> <dbType>HSQL</dbType> <dbCharset>ISO-8859-1</dbCharset> <clientCharset>ISO-8859-1</clientCharset> <needTranContent>false</needTranContent> <needTranSentence>false</needTranSentence> <!-- 是否自動連接。如果設定為true，則可以直接使用db.query()函數來訪問數據庫；如果為false，則不會自動連接，使用前必須用connect(db)語句連接。 --> <autoConnect>true</autoConnect> </jndi-ds-config> </jndi-ds-configs> |
需要說明的是：
配置文件的名稱必須為config.xml和dfxConfig.xml，不能改變。
在配置數據庫連接信息時，要注意不能循環調用，不能將集算器JDBC本身作為數據源在配置中使用。
如果兩種方式都配置了同名的數據源，就以config.xml中的為準。
5、 部署dfxConfig.xml、config.xml和test.dfx文件。
將dfxConfig.xml、config.xml放入Java應用的類路徑下（classpath），也可以直接打包到dm.jar中。
將test.dfx文件放到Java應用的類路徑下，也可以放到dfxConfig.xml文件的<paths/>節點指定的絕對路徑中。
6、 在java程序中調用test.dfx。
如果集算器 JDBC的連接串中使用了...?config=...；即用該.xml文件中的配置，忽略config.xml中的定義；連接串中無config參數時則用默認配置。
例如：con=DriverManager.getConnection("jdbc:esproc:local://?config=myconfig.xml");則使用myconfig.xml中的定義。
樣例代碼如下：
public voidtestDataServer(){ Connection con = null; com.esproc.jdbc.InternalCStatementst; com.esproc.jdbc.InternalCStatement st2; try{ //建立連接 Class.forName("com.esproc.jdbc.InternalDriver"); con=DriverManager.getConnection("jdbc:esproc:local://"); //調用存儲過程，其中test是dfx的文件名 st =(com.esproc.jdbc.InternalCStatement)con.prepareCall("calltest(?)"); //設置參數 st.setObject(1,"3"); //下面的語句和上面的調用方法效果相同 st =(com.esproc.jdbc.InternalCStatement)con.prepareCall("calltest(3)"); //執行存儲過程 st.execute(); //獲取結果集 ResultSet set =st.getResultSet(); } catch(Exception e){ System.out.println(e); } finally{ //關閉連接 if(con!=null) { try { con.close(); } catch(Exception e){ System.out.println(e); } } } } |
嵌入式
數據庫是輕量級的，獨立的庫，沒有服務器組件，無需管理，一個小的代碼尺寸，以及有限的資源需求。目前有幾種嵌入式數據庫，你可以在
移動應用程序中使用。讓我們來看看這些最流行的數據庫。
數據庫
數據類型存儲
License支持平臺
BerkeleyDBrelational, objects, key-value pairs, documentsAGPL 3.0
Android, iOS
Couchbase LitedocumentsApache 2.0Android, iOS
LevelDBkey-value pairsNew BSDAndroid, iOS
SQLiterelationalPublic DomainAndroid, iOS,
Windows Phone, Blackberry
UnQLitekey-value pairs, documentsBSD 2-ClauseAndroid, iOS, Windows Phone
1. Berkeley DB
Berkeley DB 是由美國 Sleepycat Software 公司開發的一套開放源代碼的嵌入式數據庫管理系統（已被
Oracle 收購），它為應用程序提供可伸縮的、高性能的、有事務保護功能的數據管理服務。
Berkeley DB（BDB）是一個高效的嵌入式數據庫編程庫，C語言、C++、Java、Perl、
Python、Tcl 以及其他很多語言都有其對應的 API。Berkeley DB 可以保存任意類型的鍵/值對（Key/Value Pair），而且可以為一個鍵保存多個數據。Berkeley DB 支持讓數千的并發線程同時操作數據庫，支持最大 256TB 的數據，廣泛用于各種
操作系統，其中包括大多數類 Unix 操作系統、Windows 操作系統以及實時操作系統。
2. Couchbase Lite
Couchbase Lite 是一個為滿足在線和離線的移動應用所開發的超輕量的，可靠的，并且安全的 JSON 數據庫。即使在最不確定的網絡條件下，亦可以給您的移動應用提供富有成效的和可靠的信譽。除此之外，’同步門戶’功能亦可以提供協作， 社交互動或者是用戶的更新。
3. LevelDB
LevelDB 是
Google 開源出的一個 Key/Value 存儲引擎，它采用 C++ 編寫的，支持高并發訪問和寫入，特別適合對于高寫入業務環境。
對于 LevelDB 的概覽可以參考數據分析與處理之二（Leveldb 實現原理）對 LevelDB 的一個描述，本文的圖解更多的是 LevelDB 的一個實現層的糾纏，版本為 LevelDB 1.7.02。
LevelDB 存儲主要分為 SSTable 和 MemTable，前者為不可變且存儲于持久設備上，后者位于內存上并且可變(在 LevelDB 中有兩個 MemTable，一個為當前寫入 MemTable，另一個為等待持久化的不可變 MemTable)。首先來看 SSTable 的實現層分析。
4. SQLite
SQLite 是一個開源的嵌入式關系數據庫，實現自包容、零配置、支持事務的
SQL 數據庫引擎。 其特點是高度便攜、使用方便、結構緊湊、高效、可靠。 與其他數據庫管理系統不同，SQLite 的安裝和運行非常簡單，在大多數情況下 - 只要確保 SQLite 的二進制文件存在即可開始創建、連接和使用數據庫。如果您正在尋找一個嵌入式數據庫項目或解決方案，SQLite 是絕對值得考慮。
5. UnQLite
UnQLite 是，由 Symisc Systems 公司出品的一個嵌入式C語言軟件庫，它實現了一個自包含、無服務器、零配置、事務化的NoSQL 數據庫引擎。UnQLite是一個文檔存儲數據庫，類似于 MongoDB、Redis、CouchDB 等。同時，也是一個標準的 Key/Value 存儲，與 BerkeleyDB 和 LevelDB 等類似。
UnQLite 是一個嵌入式NoSQL（鍵/值存儲和文檔存儲）數據庫引擎。不同于其他絕大多數 NoSQL 數據庫，UnQLite 沒有一個獨立的服務器進程。UnQLite 直接讀/寫普通的磁盤文件。包含多個數據集的一個完整的數據庫，存儲在單一的磁盤文件中。數據庫文件格式是跨平臺的，可以在32位和64位系統或大端和小端架構之間，自由拷貝一個數據庫