与
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这个扫描工具，扫描了整个网站，包括后台。结果我们的
数据库里被灌入大量的垃圾数据，并修改了原有的数据。总之，惨不忍睹！
后来，我们发现我们后台的一个简单的检查是否登录的方法有问题:在判定未登录时，使用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" href="//code.jquery.com/qunit/qunit-1.15.0.css"> </head> <body> <div id="qunit"></div> <div id="qunit-fixture"></div> <script src="//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、揭开谜团
通过上面逐步分析和介绍，此服务遭受入侵的原因和过程已经非常清楚了，大致过程如下：
（1）攻击者通过Awstats脚本awstats.pl文件的漏洞进入了系统，在/var/tmp目录下创建了隐藏目录，然后将rootkit后门文件传到这个路径下。
（2）攻击者通过植入后门程序，获取了系统超级用户权限，进而控制了这台服务器，通过这台服务器向外发包。
（3）攻击者的IP地址62.17.163.186可能是通过代理过来的，也可能是攻击者控制的其他肉鸡服务器。
（4）攻击者为了永久控制这台机器，修改了系统默认帐号mail的信息，将mail帐号变为可登录，并且设置了mail帐号的密码。
（5）攻击者在完成攻击后，通过后门程序自动清理了系统访问日志，毁灭了证据。
通过对这个入侵过程的分析，发现入侵者的手段还是非常简单和普遍的，虽然入侵者删除了系统的一些日志，但是还是留下了很多可查的踪迹，其实还可以查看用户下的.bash_history文件，这个文件是用户操作命令的历史记录。
7、如何恢复网站
由于系统已经文件被更改和替换，此系统已经变得完全不可信，因此建议备份网站数据，重新安装系统，基本步骤如下：
（1）安装稳定版本的操作系统，删除系统默认的并且不需要的用户。
（2）系统登录方式改为公钥认证方式，避开密码认证的缺陷。
（3）安装更高版本的apache和最新稳定版本的Awstats程序。
（4）使用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位系统或大端和小端架构之间，自由拷贝一个数据库