解读Linux启动过程

转自:https://my.oschina.net/macwe/blog/1531024

解读Linux启动过程

 

1. 概述

本文解读一下从CPU加电自检到启动init进程的过程, 先通过下面这张图大致看一下Linux启动的整个过程。

本文的分析环境是GRUB 0.97 + Linux 2.6.18。

2. BIOS

CPU加电后首先工作在实模式并初始化CS:IP=FFFF:FFF0,BIOS的入口代码必须从该地址开始。BIOS完成相应的硬件检查并提供一系列中断服务例程,这些中断服务提供给系统软件访问硬件资源(比如磁盘、显示器等),最后选择一个启动盘加载第一个扇区(即:MBR,共512字节)数据到内存0x7C00处,并从这里开始执行指令(CS:IP=0000:7C00),对于笔者的电脑来说这就是GRUB的Stage1部分。

3. GRUB

GRUB的作用是bootloader,用来引导各种OS的。

3.1. Stage1

Stage1就是MBR,由BIOS把它从磁盘的0扇区加载到0x7c00处,大小固定位512字节,此时的CPU上下文如下:

eax=0011aa55 ebx=00000080 ecx=00000000 edx=00000080 esi=0000f4a0 edi=0000fff0
eip=00007c00 esp=00007800 ebp=00000000 iopl=0 nv up ei pl zr na po nc
cs=0000 ds=0000 es=0000 fs=0000 gs=0000 ss=0000 eflags=00000246
// 注: dl=启动磁盘号, 00H~7FH是软盘, 80H~FFH是硬盘。

因为只能是512字节,大小受限,它就干一件事,把Stage2的第一个512字节读取到0x8000,然后jmp到0x8000继续执行。

3.1.1. 读磁盘

磁盘扇区寻址有两种方式:

  • CHS方式:传统的方式,使用三元组(10位Cylinder, 8位Head, 6位Sector)来寻找扇区,最大只能找到(2^10) * (2^8) * (2^6) * 512 = 8GB的硬盘容量,现在的硬盘明显不够用了。
  • LBA方式:现在的方式,使用48位线性地址来寻找扇区,最大支持(2^48) * 512 = 128PB的硬盘空间。虽然机械上还是CHS的结构,不过磁盘的固件会自动完成LBA到CHS的转换。

因为CHS明显不适合现在的硬盘,所以LBA模式寻址是现在的PC的标配了吧!万一磁盘不支持LBA或者是软盘,需要我们手工转换成CHS模式。转换公式如下(就是三维空间定位一个点的问题):

磁道号C = LBA / 每磁道的扇区数SPT / 盘面总HPC
磁头号H = (LBA / 每磁道的扇区数SPT) mod HPC
扇区号S = (LBA mod SPT) + 1

判断是否支持LBA模式

/* check if LBA is supported */
movb	$0x41, %ah
movw	$0x55aa, %bx
int	$0x13

如果返回成功(CF=1)并且BX值是0xAA55表示支持LBA寻址(用Extensions方法)。

注意:3.5英寸软盘需要使用CHS方式寻址,它的CHS参数是80个柱面、2个磁头、每个磁道18个扇区,每扇区512字节,共1.44MB容量。

LBA模式读的功能号是AH=42h,DL参数是磁盘号,DS:SI参数是Disk Address Packet(DAP)结构体的内存地址,定义如下:

struct DAP {
    uint8_t sz; // 结构体大小
    uint8_t unused;
    uint16_t sector_cnt; // 需要都的扇区总数
    struct dst_addr { // 内存地址,读到这里
        uint16_t offset;
        uint16_t segment;
    };
    uint64_t lba_addr;  // 磁盘的LBA地址
};

参考:

  • https://en.wikipedia.org/wiki/Logical_block_addressing#CHS_conversion
  • https://en.wikipedia.org/wiki/INT_13H

3.2. Stage2

Stage2就是GRUB剩下的全部的代码了,包括BIOS中断服务的封装给C代码使用、键盘驱动、文件系统驱动、串口、网络驱动等等,它提供了一个小型的命令行环境,可以解析用户输入命令并执行对OS的启动。

3.2.1. start.S

首先Stage2的头512字节(start.S)被加载到0x8000,并在这里开始执行,此时的CPU上下文如下:

eax=00000000 ebx=00007000 ecx=00646165 edx=00000080 esi=00007c05 edi=0000fff0
eip=00008000 esp=00001ffe ebp=00000000 iopl=0 nv up ei pl zr na po nc
cs=0000 ds=0000 es=0800 fs=0000 gs=0000 ss=0000 eflags=00000246

start.S的工作是把Stage2的后续部分全部加载到内存中(从0x8200开始),有103KB大小。

3.2.2. asm.S

asm.S是0x8200处的代码,先看一下CPU上下文环境:

eax=00000e00 ebx=00000001 ecx=00646165 edx=00000080 esi=00008116 edi=000081e8
eip=00008200 esp=00001ffe ebp=000062d8 iopl=0 nv up ei pl zr na po nc
cs=0000 ds=0000 es=1ae0 fs=0000 gs=0000 ss=0000 eflags=00000246
3.2.2.1. 最开始的代码应该设置好段寄存器和栈
cli
/* set up %ds, %ss, and %es */
/* cs=0000 ds=0000 es=0000 fs=0000 gs=0000 ss=0000 */
xorw	%ax, %ax
movw	%ax, %ds
movw	%ax, %ss
movw	%ax, %es

/* set up the real mode/BIOS stack */
movl	$STACKOFF, %ebp
movl	%ebp, %esp
sti

此时:

cs=0000 ds=0000 es=0000 ss=0000 esp=00001ff0 ebp=00001ff0。
3.2.2.2. 保护模式和实模式

因为GRUB没有实现自己的中断服务,所以访问硬件资源还是使用BIOS的中断服务例程(实模式)。GRUB的命令行环境是工作在保护模式下的,所以当GRUB需要访问BIOS中断的时候需要切换回实模式,于是在GRUB执行过程中会有频繁的实模式和保护模式的互相切换操作,当切换回实模式后别忘了保存保护模式下的栈指针

(1) 实模式进入保护模式

/* transition to protected mode */
DATA32	call EXT_C(real_to_prot)

/* The ".code32" directive takes GAS out of 16-bit mode. */
.code32

下图是实模式到保护模式的切换步骤:

GRUB没有设置分页机制和新的中断,所以GRUB的保护模式访问的是物理内存且是不能使用INT指令,不过对于bootloader来说够用了。因为需要切换到保护模式栈,原来的返回地址要放到新的栈上,以保证能够正常ret:

ENTRY(real_to_prot)
	...
	/* put the return address in a known safe location */
	movl	(%esp), %eax
	movl	%eax, STACKOFF  ; 把返回地址保存起来备用

	/* get protected mode stack */
	movl	protstack, %eax
	movl	%eax, %esp
	movl	%eax, %ebp      ; 设置保护模式的栈

	/* get return address onto the right stack */
	movl	STACKOFF, %eax
	movl	%eax, (%esp)    ; 把返回地址重新放到栈上
	
	/* zero %eax */
	xorl	%eax, %eax

	/* return on the old (or initialized) stack! */
	ret                     ; 正常返回

(2) 保护模式切换回实模式

	/* enter real mode */
	call	EXT_C(prot_to_real)
	
	.code16

下图说明了保护模式切换回实模式的步骤:

保护模式的栈需要保存起来以便恢复现场,让C代码正确运行,实模式的栈每次都重置为STACKOFF即可,和(1)一样,也要设置好返回地址:

ENTRY(prot_to_real)
	...
	/* save the protected mode stack */
	movl	%esp, %eax
	movl	%eax, protstack  ; 把栈保存起来

	/* get the return address */
	movl	(%esp), %eax
	movl	%eax, STACKOFF   ; 返回地址放到实模式栈里

	/* set up new stack */
	movl	$STACKOFF, %eax  ; 设置实模式的栈
	movl	%eax, %esp
	movl	%eax, %ebp
	... 
3.2.2.3. 创建C运行时环境

C的运行环境主要包括栈、bss数据区、代码区。随着切换到保护模式,栈已经设置好了;随着Stage2从磁盘加载到内存,代码区和bss区都已经在内存了,最后还需要把bss区给初始化一下(清0),接下来即可愉快的执行C代码了。

3.2.2.4. 执行cmain()

先执行一个init_bios_info()获取BIOS的信息,比如被BIOS使用的内存空间(影响我们Linux映像加载的位置)、磁盘信息、ROM信息、APM信息,最后调用cmain()。 cmain()函数在stage2.c文件中,其中最主要的函数run_menu()是启动一个死循环来提供命令行解析执行环境。

3.2.2.5. load_image()

如果grub.cfg或者用户执行kenrel命令,会调用load_image()函数来将内核加载到内存中。至于如何加载linux镜像在Documentation的boot.txt和zero-page.txt有详细说明。

load_image()是一个非常长的函数,它要处理支持的各种内核镜像格式。Linux镜像vmlinuz文件头是struct linux_kernel_header结构体,该结构体里头说明了这个镜像使用的boot协议版本、实模式大小、加载标记位和需要GRUB填写的一些参数(比如:内核启动参数地址)。

  • 实模式部分:始终被加载到0x90000位置,并从0x90200开始执行(linux 0.11就这样做了)。
  • 保护模式部分:我们现在使用的内核比较大(大于512KB),叫做bzImage,加载到0x100000(高位地址,1MB)开始的位置,可以任意大小了。否则小内核zImage放在0x10000到mbi.mem_lower * 1024(一般是0x90000)区域。
3.2.2.6. linux_boot()

我们正常的启动过程调用的是big_linux_boot()函数,把实模式部分copy到0x90000后,设置其他段寄存器值位0x9000, 设置CS:IP=9020:0000开始执行(使用far jmp)。

至此GRUB的工作完成,接下来执行权交给Linux了。

4. setup.S

该文件在arch/i386/boot/setup.S,主要作用是收集硬件信息并进入保护模式head.S。初始的CPU上下文如下:

eax=00000000 ebx=00009000 ecx=00000000 edx=00000003 esi=002d8b54 edi=0009a000
eip=00000000 esp=00009000 ebp=00001ff0 iopl=0 nv up di pl zr na po nc
cs=9020 ds=9000 es=9000 fs=9000 gs=9000 ss=9000  eflags=00000046

4.1. 自身检查

先检查自己setup.S是否合法,主要是检查末尾的两个magic是否一致

# Setup signature -- must be last
setup_sig1:	.word	SIG1
setup_sig2:	.word	SIG2

4.2. 收集硬件信息

主要是通过BIOS中断来收集硬件信息。收集的信息包括内存大小、键盘、鼠标、显卡、硬盘、APM等等。收集的硬件信息保存在0x9000处:

# 设置ds = 0x9000,用来保存硬件信息
movw	%cs, %ax			# aka SETUPSEG
subw	$DELTA_INITSEG, %ax 		# aka INITSEG
movw	%ax, %ds

这里看一下如何获取内存大小,这样OS才能进行内存管理。这里用三种方法获取内存信息:

  1. e820h:请求中断INT 15H,AX=E820H时返回可用的物理内存信息,e820由此得名,参考http://www.uruk.org/orig-grub/mem64mb.html。由于内存的使用是不连续的,通过连续调用INT 15H得到所有可用的内存区域,每次查询得到的结果ES:DI是个struct address_range_descriptor结构体,返回的结果都是64位的,完全能够满足目前PC的需求了。
     struct address_range_descriptor {
     	uint32_t base_addr_low;   // 起始物理地址
     	uint32_t base_addr_high;
     	uint32_t length_low;      // 长度
     	uint32_t length_high;
     	uint8_t type;             // 1=OS可用的, 2=保留的,OS不可用
     };
    
  2. e801h:通过请求中断INT15h,AX=e801H返回结果,最高只能得到4GB内存结果。
  3. 88h:古老的办法,通过请求中断INT15h,AH=88H返回结果。最高只能得到16MB或者64MB的内存,现在的电脑不适用了。

扩展阅读:http://wiki.osdev.org/Detecting_Memory_(x86)#E820h

4.3. 启用A20

让CPU访问1MB以上的扩展内存,否则访问的是X mod 1MB的地址。下面列举三种开启A20的方法:

  1. 使用I/0端口92H,AL的将1-bit置1
     inb	$0x92, %al			# Configuration Port A
     orb	$0x02, %al			# "fast A20" version
     andb	$0xFE, %al			# don't accidentally reset
     outb	%al, $0x92
    
  2. 使用BIOS中断INT 0x15, AX=0x2401
     movw	$0x2401, %ax
     pushfl					# Be paranoid about flags
     int	$0x15
     popfl
    
  3. 使用键盘控制器
     movb	 $0xD1, %al			# command write
     outb	 %al, $0x64
     call	 empty_8042
    
     movb	 $0xDF, %al			# A20 on
     outb	 %al, $0x60
     call	 empty_8042
    

4.4. 进入保护模式

4.4.1. 临时的GDT和IDT

这里的IDT全部是0;Linux目前使用的GDT如下:

gdt:
	.fill GDT_ENTRY_BOOT_CS,8,0

	.word	0xFFFF				# 4Gb - (0x100000*0x1000 = 4Gb)
	.word	0				# base address = 0
	.word	0x9A00				# code read/exec
	.word	0x00CF				# granularity = 4096, 386
						#  (+5th nibble of limit)

	.word	0xFFFF				# 4Gb - (0x100000*0x1000 = 4Gb)
	.word	0				# base address = 0
	.word	0x9200				# data read/write
	.word	0x00CF				# granularity = 4096, 386
						#  (+5th nibble of limit)
gdt_end:

这里只定义了两个DPL为0的代码段和数据段,只给内核使用的。

4.4.1. 设置CR0.PE

这里使用lmsw指令,它和mov cr0, X是等价的

movw	$1, %ax				# protected mode (PE) bit
lmsw	%ax				# This is it!
jmp	flush_instr

4.5. 调转到head.S(CS:EIP=0x10:100000)

至此硬件信息就收集完成,这些收集到的硬件信息都保存在0x90000处,后续OS可以使用这些硬件信息来管理了。

5. head.S

该文件位于arch/i386/kernel/head.S,这个是内核保护模式的代码的起点,笔者电脑的位置在0x100000,此时CPU上下文是:

eax=00000001 ebx=00000000 ecx=0000ff03 edx=47530081 esi=00090000 edi=00090000
eip=00100000 esp=00008ffe ebp=00001ff0 iopl=0 nv up di pl nz na pe nc
cs=0010 ds=0018 es=0018 fs=0018 gs=0018 ss=0018               eflags=00000002

注:已经进入保护模式,CS的值是GDT表项的索引。

它的作用就是设置真正的分段机制和分页机制、启动多处理器、设置C运行环境,最后执行start_kernel()函数。

5.1. startup_32

5.1.1. 加载临时的分段机制

boot_gdt_table就是临时的GDT,其实和start.S的一样:

	lgdt boot_gdt_descr - __PAGE_OFFSET
	movl $(__BOOT_DS),%eax
	movl %eax,%ds
	movl %eax,%es
	movl %eax,%fs
	movl %eax,%gs

ENTRY(boot_gdt_table)
	.fill GDT_ENTRY_BOOT_CS,8,0
	.quad 0x00cf9a000000ffff	/* kernel 4GB code at 0x00000000 */
	.quad 0x00cf92000000ffff	/* kernel 4GB data at 0x00000000 */

5.1.2. 初始化内核bss区和内核启动参数

为了让C代码正常运行,bss区全部清0,启动参数需要移动到boot_params位置。

5.1.3. 启动临时分页机制

临时的页表,只要能够满足内核使用就行。页目录表是swapper_pg_dir,它是一个4096大小的内存区域,默认全是0。一般__PAGE_OFFSET=0xC0000000(3GB),这是要把物理地址0x00000000映射到0xc0000000的地址空间(内核地址空间)。下面是页目录表和页表的初始化代码:

page_pde_offset = (__PAGE_OFFSET >> 20); // 3072,页目录的偏移

	// 页目录表存放在pg0位置,arch/i386/kernel/vmlinux.lds中定义
	movl $(pg0 - __PAGE_OFFSET), %edi
	movl $(swapper_pg_dir - __PAGE_OFFSET), %edx  // edx是页目录表的地址
	movl $0x007, %eax			/* 0x007 = PRESENT+RW+USER */
10:
	// 创建一个页目录项
	leal 0x007(%edi),%ecx			/* Create PDE entry */
	movl %ecx,(%edx)			/* Store identity PDE entry */
	movl %ecx,page_pde_offset(%edx)		/* Store kernel PDE entry */
	addl $4,%edx   // 指向swapper_pg_dir的下一个项
	movl $1024, %ecx   // 每个页表1024个项目
11:
	stosl  // eax -> [edi]; edi = edi + 4
	addl $0x1000,%eax // 每次循环,下一个页目录项
	loop 11b
	/* End condition: we must map up to and including INIT_MAP_BEYOND_END */
	/* bytes beyond the end of our own page tables; the +0x007 is the attribute bits */
	leal (INIT_MAP_BEYOND_END+0x007)(%edi),%ebp  // 页表覆盖到这里就终止
	cmpl %ebp,%eax
	jb 10b
	movl %edi,(init_pg_tables_end - __PAGE_OFFSET)

下面是对上面代码的翻译(这样更有利于理解):

extern uint32_t *pg0;  // 初始值全0
extern uint32_t *swapper_pg_dir;  // 初始值全0

void init_page_tables()
{
	uint32_t PAGE_FLAGS = 0x007; // PRESENT+RW+USER
	uint32_t page_pde_offset = (_PAGE_OFFSET >> 20); // 3072
	uint32_t addr = 0 | PAGE_FLAGS;  // 内存地址+页表属性
	uint32_t *pg_dir_ptr = swapper_pg_dir; // 页目录表项指针
	uint32_t *pg0_ptr = pg0;  // 页表项指针
	
	for (;;) {
		// 设置页目录项,同时映射两个地址,让物理地址和虚拟地址都能访问,
		*pg_dir_ptr = pg0 | PAGE_FLAGS;     // 0, 1
		*(uint32_t *)((char *)pg_dir_ptr + page_pde_offset) = pg0 | PAGE_FLAGS;  // 768, 769
		pg_dir_ptr++;
		
		// 设置页表项目
		for (int i = 0; i < 1024; i++) {
			*pg0++ = addr;
			addr += 0x1000;
		}
		// 退出条件,实际上只映射了两个页目录就退出了(0,1,768, 769)
		if (pg0[INIT_MAP_BEYOND_END] | PAGE_FLAGS) >= addr) {
			init_pg_tables_end = pg0_ptr;
			return;
		}
	}	
};

5.1.4. 设置栈

/* Set up the stack pointer */
	lss stack_start,%esp

ENTRY(stack_start)
	.long init_thread_union+THREAD_SIZE
	.long __BOOT_DS

/* arch/i386/kernel/init_task.c
* Initial thread structure.
*
* We need to make sure that this is THREAD_SIZE aligned due to the
* way process stacks are handled. This is done by having a special
* "init_task" linker map entry..
*/
union thread_union init_thread_union 
	__attribute__((__section__(".data.init_task"))) =
		{ INIT_THREAD_INFO(init_task) };

内核最初使用的栈是init_task进程的,也就是0号进程的栈,这个进程是系统唯一一个静态定义而不是通过fork()产生的进程。

5.1.5. 设置真正的IDT和GDT

	lgdt cpu_gdt_descr   // 真正的GDT
	lidt idt_descr    //真正的IDT
	ljmp $(__KERNEL_CS),$1f   // 重置CS
1:	movl $(__KERNEL_DS),%eax	# reload all the segment registers
	movl %eax,%ss			# after changing gdt.  // 重置SS

	movl $(__USER_DS),%eax		# DS/ES contains default USER segment
	movl %eax,%ds
	movl %eax,%es

	xorl %eax,%eax			# Clear FS/GS and LDT
	movl %eax,%fs
	movl %eax,%gs
	lldt %ax
	cld			# gcc2 wants the direction flag cleared at all times
	// push一个假的返回地址以满足 start_kernel()函数return的要求
	pushl %eax		# fake return address  

对于IDT先全部初始化成ignore_int例程:

setup_idt:
	lea ignore_int,%edx
	movl $(__KERNEL_CS << 16),%eax
	movw %dx,%ax		/* selector = 0x0010 = cs */
	movw $0x8E00,%dx	/* interrupt gate - dpl=0, present */

	lea idt_table,%edi
	mov $256,%ecx
rp_sidt:
	movl %eax,(%edi)
	movl %edx,4(%edi)
	addl $8,%edi
	dec %ecx
	jne rp_sidt
	ret

ignore_int例程就干一件事,打印一个错误信息"Unknown interrupt or fault at EIP %p %p %p\n"

对于GDT我们最关心的__KERNEL_CS、__KERNEL_DS、__USER_CS、__USER_DS这4个段描述符:

.quad 0x00cf9a000000ffff	/* 0x60 kernel 4GB code at 0x00000000 */
.quad 0x00cf92000000ffff	/* 0x68 kernel 4GB data at 0x00000000 */
.quad 0x00cffa000000ffff	/* 0x73 user 4GB code at 0x00000000 */
.quad 0x00cff2000000ffff	/* 0x7b user 4GB data at 0x00000000 */

至此分段机制、分页机制、栈都设置好了,接下去可以开心的jmp start_kernel了。

6. start_kernel

该函数在linux/init/main.c文件里。我们可以认为start_kernel是0号进程init_task的入口函数,0号进程代表整个linux内核且每个CPU有一个。 这个函数开始做一系列的内核功能初始化,我们重点看rest_init()函数。

6.1.rest_init

这是start_kernel的最后一行,它启动一个内核线程运行init函数后就什么事情也不做了(死循环,始终交出CPU使用权)。

static void noinline rest_init(void)
{
	kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND); // 启动init
	……
	/* Call into cpu_idle with preempt disabled */
	cpu_idle();  // 0号进程什么事也不做
}

6.2. init()

该函数的末尾fork了”/bin/init”进程。这样1号进程init就启动了,接下去就交给init进程去做应用层该做的事情了!

// 以下进程启动后父进程都是0号进程
if (ramdisk_execute_command) {
	run_init_process(ramdisk_execute_command);
	printk(KERN_WARNING "Failed to execute %s\n",
			ramdisk_execute_command);
}

/*
 * We try each of these until one succeeds.
 *
 * The Bourne shell can be used instead of init if we are 
 * trying to recover a really broken machine.
 */
if (execute_command) {
	run_init_process(execute_command);
	printk(KERN_WARNING "Failed to execute %s.  Attempting "
				"defaults...\n", execute_command);
}
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");

附录1. 启动多核CPU

以上解读的内容只在0号CPU上执行,如果是多CPU的环境,还要初始化其他的CPU。多CPU启动的起点是start_kernel()->rest_init()>init()->smp_init()。而smp_init()函数给每个CPU上调用cpu_up()do_boot_cpu()函数,每个CPU都要再走一遍head.S的流程,然后启动自己的idle进程(内核态0号进程)。

附录2. x64的不同

i386和x64的启动代码主要区别在head.S中。

  • 页表格式不同,i386使用两级页表,x64使用4级页表。
  • 多了兼容32位的代码段和数据段__USER32_CS、__USER32_DS和__KERNEL32_CS
  • x64段寄存器用法和i386的不同:x64下面CS、DS、ES、SS不用了,始终为0。而FS、GS寄存器的用法倒像是实模式下的,主要考虑是保留两个作为基地址好让线性地址计算方便。FS:XX = MSR_FS_BASE + XXGS:XX = MSR_GS_BASE + XX, 不是段描述符索引了(像实模式的分段)。

J2EE框架 Spring

J2EE框架 Spring 推荐

J2EE框架 面向方面AOP/IoC Web框架
Apache
Java
跨平台

Spring Framework 是一个开源的Java/Java EE全功能栈(full-stack)的应用程序框架,以Apache许可证形式发布,也有.NET平台上的移植版本。该框架基于 Expert One-on-One Java EE Design and Development(ISBN 0-7645-4385-7)一书中的代码,最初由 Rod Johnson 和 Juergen Hoeller等开发。Spring Framework 提供了一个简易的开发方式,这种开发方式,将避免那些可能致使底层代码变得繁杂混乱的大量的属性文件和帮助类。

Spring 中包含的关键特性:

  • 强大的基于 JavaBeans 的采用控制翻转(Inversion of Control,IoC)原则的配置管理,使得应用程序的组建更加快捷简易。
  • 一个可用于从 applet 到 Java EE 等不同运行环境的核心 Bean 工厂。
  • 数据库事务的一般化抽象层,允许宣告式(Declarative)事务管理器,简化事务的划分使之与底层无关。
  • 内建的针对 JTA 和 单个 JDBC 数据源的一般化策略,使 Spring 的事务支持不要求 Java EE 环境,这与一般的 JTA 或者 EJB CMT 相反。
  • JDBC 抽象层提供了有针对性的异常等级(不再从SQL异常中提取原始代码), 简化了错误处理, 大大减少了程序员的编码量. 再次利用JDBC时,你无需再写出另一个 ‘终止’ (finally) 模块. 并且面向JDBC的异常与Spring 通用数据访问对象 (Data Access Object) 异常等级相一致.
  • 以资源容器,DAO 实现和事务策略等形式与 Hibernate,JDO 和 iBATIS SQL Maps 集成。利用众多的翻转控制方便特性来全面支持, 解决了许多典型的Hibernate集成问题. 所有这些全部遵从Spring通用事务处理和通用数据访问对象异常等级规范.
  • 灵活的基于核心 Spring 功能的 MVC 网页应用程序框架。开发者通过策略接口将拥有对该框架的高度控制,因而该框架将适应于多种呈现(View)技术,例如 JSP,FreeMarker,Velocity,Tiles,iText 以及 POI。值得注意的是,Spring 中间层可以轻易地结合于任何基于 MVC 框架的网页层,例如 Struts,WebWork,或 Tapestry。
  • 提供诸如事务管理等服务的面向方面编程框架。

在设计应用程序Model时,MVC 模式(例如Struts)通常难于给出一个简洁明了的框架结构。Spring却具有能够让这部分工作变得简单的能力。程序开发员们可以使用Spring的 JDBC 抽象层重新设计那些复杂的框架结构。

IceGrid应用配置[转]

1.  概述1.1 配置目标

本文档是描述Ice中间件中的IceGrid服务的应用配置,通过使用IceGrid服务来实现:

1.  服务器端服务分布式部署。

2.  服务器端服务按需激活。

3.  服务器端服务多节点负载均衡。

4.  注册服务主/从热备(Master/Slaves)

5.  集成IceBox服务

1.2 实验环境

1.  硬件:hp服务器,3台

2.  操作环境:Red Hat 5

3.  服务器程序:ServerApp.jar

4.  说明:实际应用中,服务器节点可任意扩充、操作系统可被更换、服务器程序可用实际项目的服务程序替换,本文档所描述的配置方式具有通用性,适用但不局限于当前实验环境。

1.3 局限

本文档不详细描述IceGrid服务的运行机制和实现原理,不详细介绍服务器端和客户端程序的实现,主要描述IceGrid服务应用的配置步骤、主要配置项及验证配置结果等。

2.  配置过程

2.1  服务器端配置

配置步骤:

1.  创建主注册服务(Master)的配置文件config_master.grid,文件名称可以任意

2.  创建从注册服务(Slave)的配置文件 config_slave.grid, 文件名称可以任意

3.  创建各节点服务的配置文件config.node,文件名称可以任意

4.  创建分布式应用配置文件app.xml,文件名称可以任意,但格式最好定义成xml

5.  运行Ice提供的工具,启动我们的分布式应用,主要有如下两个工具:icegridnode和icegridadmin。详细启动过程如下:

1) icegridnode–Ice.Config=config_master.grid  启动主注册服务

2) icegridnode–Ice.Config=config_slave.grid  启动从注册服务

3) icegridadmin–Ice.Config= config_master.grid -e “application add app.xml”   部署分布式服务

icegridadmin –Ice.Config= config_master.grid-e “application update app.xml”  重新部署分布式服务

4) icegridnode–Ice.Config=config.node  将各节点注册到注册服务的注册表中

配置文件清单:

假设有n个节点(n > 0), 其中从注册服务有x个,(x > 0)

config_master.grid   ———- 主注册服务配置文件 ———  1份

config_slave.grid   ———– 从注册服务配置文件 ———  x份

config.node  —————– 节点配置文件  ————–  n份

app.xml ———————- 部署配置文件  ————–  1份

通常情况下,由于注册服务占用资源很少,所以一般都会和一个节点集成在一起,并且可以和节点服务在一个进程中运行。因此,如果假设服务部署到n个服务器,通常情况下配置文件清单如下:

config_master.grid– 主注册服务配置文件 — 1份  — 主注册服务信息+节点信息

config_slave.grid— 从注册服务配置文件 — x份  — 从注册服务信息+节点信息

config.node——— 节点配置文件 —- n-1-x份  — 节点信息

app.xml————- 部署配置文件 ——– 1份  — 部署信息

其中app.xml要和config_master.grid放在一台服务器上,下面的各章节将详细介绍各配置文件。

2.1.1  主注册服务配置

config_master.grid的内容:

#

# The IceGrid InstanceName

#

IceGrid.InstanceName=IceGridRDDataSource    # 1

 

#

# The IceGridlocator proxy.

#

Ice.Default.Locator=IceGridRDDataSource/Locator:default-h 10.0.5.201 -p 12000:default -h 10.0.5.202-p 12000         #2

 

#

# IceGridregistry configuration.

#

IceGrid.Registry.Client.Endpoints=default-p 12000   #3

IceGrid.Registry.Server.Endpoints=default    #4

IceGrid.Registry.Internal.Endpoints=default   #5

IceGrid.Registry.Data=master      #6

IceGrid.Registry.PermissionsVerifier=IceGridRDDataSource/NullPermissionsVerifier     #7

IceGrid.Registry.AdminPermissionsVerifier=IceGridRDDataSource/NullPermissionsVerifier#8

IceGrid.Registry.SSLPermissionsVerifier=IceGridRDDataSource/NullSSLPermissionsVerifier#9

IceGrid.Registry.AdminSSLPermissionsVerifier=IceGridRDDataSource/NullSSLPermissionsVerifier    #10

 

#

# IceGrid SQLconfiguration if using SQL database.

#

#Ice.Plugin.DB=IceGridSqlDB:createSqlDB     #11

#IceGrid.SQL.DatabaseType=QSQLITE      #12

#IceGrid.SQL.DatabaseName=register/Registry.db       #13

#

 

#

#Ice Error andStandard output Set

#

#Ice.StdErr=master/stderr.txt                  #14

#Ice.StdOut= master/stdout.txt    #15

 

#

#Trace Registryproperties

#

Ice.ProgramName=Master     #16

IceGrid.Registry.Trace.Node=3        #17

IceGrid.Registry.Trace.Replica=3    #18

 

#

# IceGrid nodeconfiguration.

#

IceGrid.Node.Name=node_1                              #19

IceGrid.Node.Endpoints=default                         #20

IceGrid.Node.Data=node_1               #21

IceGrid.Node.CollocateRegistry=1                      #22

#IceGrid.Node.Output=node_1            #23

#IceGrid.Node.RedirectErrToOut=1         #24

 

# Traceproperties.

#

IceGrid.Node.Trace.Activator=1             #25

#IceGrid.Node.Trace.Adapter=2             #26

#IceGrid.Node.Trace.Server=3              #27

 

#

# Dummy usernameand password for icegridadmin.

#

IceGridAdmin.Username=mygrid           #28

IceGridAdmin.Password=mygrid            #29

配置项说明:

#1 为这个应用实例指定一个唯一的标识

# 2  注册服务的端点信息(主注册服务和所有的从注册服务),节点注册时要用到

# 3  客户端访问注册服务器的端点信息

# 4  服务访问注册服务器的端点信息,通常是default

# 5  内部访问端点信息,通常是default,节点用这个端口和注册服务通信

# 6  注册服务的数据目录的路径

# 7  设定防火墙安全代理,从而控制客户端访问注册表时可用的权限

# 8  设定防火墙安全代理,从而控制注册表管理者可用的权限

# 9  设定SSL安全代理,从而设定客户端访问注册表时的SSL安全访问机制

# 10  设定SSL安全代理,从而设定注册表管理者的SSL安全访问机制

# 11  指定Ice对象序列化的机制,如果不设置,默认用Freeze机制

# 12  指定使用数据库的类型

#13  指定使用数据库的名称

#14  指定标准错误输出文件

#15  指定标准输出文件

#16  指定主注册服务的名称

#17  指定主注册服务跟踪节点信息的级别(0~3),默认为0

#18  指定主/从热备注册服务的跟踪级别(0~3),默认为0

# 19  定义节点的名称,必须唯一

# 20 节点被访问的端口信息,注册服务使用这个端点和节点通信,通常设为default

# 21  节点的数据目录的路径

# 22  定义节点是否和注册服务并置在一起,设为1时并置,设为0时不并置

# 23  节点标准输出信息重定向蹈的目录路径,会自动生成输出文件

# 24  节点上的服务程序的标准错误重定向到标准输出

# 25  激活器跟踪级别,通常有0,1,2,3级,默认是0

# 26  对象适配器跟踪级别,通常有0,1,2,3级,默认是0

# 27  服务跟踪级别,通常有0,1,2,3级,默认是0

# 28  IceGrid管理器登录该应用的用户名

# 29  IceGrid管理器登录该应用的密码

未涉及的属性还有一些,如果需要请参考官方文档。

2.1.2  从注册服务配置

config_slave.grid的内容:

 

#

# The IceGridlocator proxy.

#

Ice.Default.Locator=IceGridRDDataSource/Locator:default-h 10.0.2.241 -p 12000:default -h 10.0.2.242-p 12000         #1

 

#

# IceGridregistry configuration.

#

IceGrid.Registry.Client.Endpoints=default-p 12000   #2

IceGrid.Registry.Server.Endpoints=default    #3

IceGrid.Registry.Internal.Endpoints=default   #4

IceGrid.Registry.Data=slave_1        #5

IceGrid.Registry.ReplicaName=slave_1   #6

IceGrid.Registry.PermissionsVerifier=IceGridRDDataSource/NullPermissionsVerifier     #7

IceGrid.Registry.AdminPermissionsVerifier=IceGridRDDataSource/NullPermissionsVerifier#8

IceGrid.Registry.SSLPermissionsVerifier=IceGridRDDataSource/NullSSLPermissionsVerifier#9

IceGrid.Registry.AdminSSLPermissionsVerifier=IceGridRDDataSource/NullSSLPermissionsVerifier    #10

 

#

# IceGrid SQLconfiguration if using SQL database.

#

#Ice.Plugin.DB=IceGridSqlDB:createSqlDB     #11

#IceGrid.SQL.DatabaseType=QSQLITE      #12

#IceGrid.SQL.DatabaseName=register/Registry.db       #13

#

 

#

#Ice Error andStandard output Set

#

#Ice.StdErr=slave_1/stderr.txt                 #14

#Ice.StdOut=slave_1/stdout.txt     #15

 

#

#Trace Registryproperties

#

Ice.ProgramName=Slave_1     #16

IceGrid.Registry.Trace.Node=3        #17

IceGrid.Registry.Trace.Replica=3    #18

 

#

# IceGrid nodeconfiguration.

#

IceGrid.Node.Name=node_2                              #19

IceGrid.Node.Endpoints=default                         #20

IceGrid.Node.Data=node_2               #21

IceGrid.Node.CollocateRegistry=1                      #22

#IceGrid.Node.Output=node_2            #23

#IceGrid.Node.RedirectErrToOut=1         #24

 

# Traceproperties.

#

IceGrid.Node.Trace.Activator=1             #25

#IceGrid.Node.Trace.Adapter=2             #26

#IceGrid.Node.Trace.Server=3              #27

 

#

# Dummy usernameand password for icegridadmin.

#

IceGridAdmin.Username=mygrid           #28

IceGridAdmin.Password=mygrid            #29

配置项说明:

其实这个文件和主注册配置文件基本一样,差别只有一点:

1.       没有指定应用实例名,因为在主注册服务中已经有了定义

2.       多了第6行,IceGrid.Registry.ReplicaName=slave_1,指定从注册服务的名称

其它的基本就没有差别了,大部分属性项在config_master.grid里面都有定义,为了方便阅读,下面也将用到的各项给出说明:

# 1  注册服务的端点信息(主注册服务和所有的从注册服务),节点注册时要用到

# 2  客户端访问注册服务器的端点信息

# 3  服务访问注册服务器的端点信息,通常是default

#4  内部访问端点信息,通常是default,节点用这个端口和注册服务通信

# 5  注册服务的数据目录的路径

# 6  指定从注册服务的名称

# 7  设定防火墙安全代理,从而控制客户端访问注册表时可用的权限

#8  设定防火墙安全代理,从而控制注册表管理者可用的权限

# 9  设定SSL安全代理,从而设定客户端访问注册表时的SSL安全访问机制

#10  设定SSL安全代理,从而设定注册表管理者的SSL安全访问机制

# 11  指定Ice对象序列化的机制,如果不设置,默认用Freeze机制

# 12  指定使用数据库的类型

#13  指定使用数据库的名称

#14  指定标准错误输出文件

#15  指定标准输出文件

#16  指定从注册服务运行时程序名称

#17  指定从注册服务跟踪节点信息的级别(0~3),默认为0

#18  指定主/从热备注册服务的跟踪级别(0~3),默认为0

# 19  定义节点的名称,必须唯一

# 20  节点被访问的端口信息,注册服务使用这个端点和节点通信,通常设为default

# 21  节点的数据目录的路径

# 22  定义节点是否和注册服务并置在一起,设为1时并置,设为0时不并置

# 23  节点标准输出信息重定向蹈的目录路径,会自动生成输出文件

# 24  节点上的服务程序的标准错误重定向到标准输出

# 25  激活器跟踪级别,通常有0,1,2,3级,默认是0

# 26  对象适配器跟踪级别,通常有0,1,2,3级,默认是0

# 27  服务跟踪级别,通常有0,1,2,3级,默认是0

# 28  IceGrid管理器登录该应用的用户名

# 29  IceGrid管理器登录该应用的密码

2.1.3  应用部署配置

app.xml配置文件内容:

1<icegrid>

2  <application name=“RTDSSystem”>

3    <server-template id=“RTDSSystemServer”>

4      <parameter name=“index”/>

5      <server id=“RTDSSystemServer-${index}”exe=Java                                          activation=“on-demand”>

6        <adapter name=“RTDataSysytem” endpoints=“tcp”                                          replica-group=“ReplicatedRTDataSysytemAdp”/>

7        <option>-jar</option>

8        <option>ServerApp.jar</option>

9      </server>

10    </server-template>

11

12    <replica-group id=“ReplicatedRTDataSysytemAdp”>

13      <load-balancing type=“round-robin”/>

14      <object identity=“RTDataSource”                                                      type=“::RTDataSystem::RTDataSource”/>

15    </replica-group>

16

17    <node name=“node_1”>

18      <server-instance template=“RTDSSystemServer” index=“1”/>

19      <server-instance template=“RTDSSystemServer” index=“11”/>

20      <server-instance template=“RTDSSystemServer” index=“111”/>

21    </node>

22    <node name=“node_2”>

23      <server-instance template=“RTDSSystemServer” index=“2”/>

24      <!–server-instancetemplate=”RTDSSystemServer” index=”22″/–>

25      <!–server-instancetemplate=”RTDSSystemServer” index=”222″/–>

26    </node>

27    <node name=“node_3”>

28      <server-instance template=“RTDSSystemServer” index=“3”/>

29      <!–server-instancetemplate=”RTDSSystemServer” index=”33″/–>

30      <!–server-instancetemplate=”RTDSSystemServer” index=”333″/–>

31    </node>

32  </application>

33</icegrid>

配置文件结构分析:

IceGrid里,部署是一个在注册服务中表述一个应用(Application)的过程,而部署配置文件就是来描述这些配置信息的文件,这个配置文件是用xml标记性语言来描述的。通常一个部署应该包含如下信息:

1.  应用标签(application),name属性定义这个应用的名字

2.  服务(server), 一个逻辑上的服务器,能够通过exe命令而启动的一个服务程序。activation属性,是设置服务的启动方式,on-demand是最常用的方式,另外还有always等启动方式;option标签是exe执行命令命令行的参数;

3.  适配器(adpter),定义服务器端的适配器。

name属性唯一标志这个适配器;

endpoints属性指定端点信息;

replica-group属性标示该适配器是个可复制组集群,并指定这个可复制组的名称;

register-process属性定义了是否这个节点是否可以被icegrid关闭;

4.  节点(node),它应该代表了一个物理上的节点。

name属性指定节点的名字,并且是唯一的。

5.  可复制组(replica-group),一组对象适配器的集合。

id属性唯一标识一个可复制组;

load-balancing子项中type属性指定负载均衡策略,icegrid提供了四种负载均衡策略: Random (随机方式)

       Adaptive(适配方式)

       Round Robin(最近最少使用)

       Ordered(顺序方式)

object子项定义适配器绑定的服务对象信息。其中identity属性指定对象的标识,type属性指定了对象的层次结构类型。这两个属性都可以唯一的标识一个服务对象。

6.  服务模板(server-temple),服务模板是对服务的一个抽象,避免了重复定义。这样,在节点中描述服务时只需要实例化它的服务模板就可以了。

id属性唯一标识一个服务模板;

parameter子项定义服务模板的参数,可包含多个,主要实例化服务时用;

server子项就是上面2中的服务定义;

另外还有一些特殊的服务模板,比如:icebox服务模板,它的定义和通用的服务模板的定义不太一样。

解析app.xml文件:

通过对配置文件结构的分析,来解析一下app.xml。

第1行,标识这是一个icegrid的配置文件;

第2行,标识应用的名称为RTDSSystem,这个名称是唯一的;

第3~10行,定义了一个服务模板RTDSSystemServer,并有一个参数index;

          其中5~9定义了这个模板包含的服务定义,第6行是这个服务包含的对象适配器

          的定义;

第12~15行,是对可复制组的定义,包括服务对象的定义和负载均衡策略;

第17~21行,是对节点node_1的定义,指定了节点的名称,包含的服务(3个服务);

第22~26行,是对节点node_2的定义

第27~31行,是对节点node_3的定义

最后两行是闭合标签,至此一个icegrid的分布式部署配置文件就完成了。

部署配置文件的扩展:

app.xml中对服务模板、适配器、服务对象等的配置都是一个,事实上这些可以在文件中定义多个,比如可以有多个服务模板,一个服务里可以有多个适配器,可以有多个可复制组,一个节点里可以有多个不同类型的服务等。

另外,app.xml可以包含其它的xml。

2.1.4  节点配置

config.grid文件的内容:

#

# The IceGridlocator proxy.

#

Ice.Default.Locator=IceGridRDDataSource/Locator:default-h 10.0.2.241 -p 12000:default -h 10.0.2.242-p 12000         #1

 

#

# IceGrid nodeconfiguration.

#

IceGrid.Node.Name=node_2                  #2

IceGrid.Node.Endpoints=default              #3

IceGrid.Node.Data=node_2                       #4

IceGrid.Node.Output=node_2             #5

IceGrid.Node.RedirectErrToOut=1           #6

 

# Trace properties.

#

IceGrid.Node.Trace.Activator=1             #7

#IceGrid.Node.Trace.Adapter=2             #8

#IceGrid.Node.Trace.Server=3              #9

配置项说明:

事实上,这个文件里面的配置项,在config_slave.grid中都有描述,但这里也列出来,方便阅读。

#1   注册服务的端点信息(主注册服务和所有的从注册服务),节点注册时要用到

#2   定义节点的名称,必须唯一

#3   节点被访问的端口信息,注册服务使用这个端点和节点通信,通常设为default

#4   节点的数据目录的路径

#5   节点标准输出信息重定向的目录路径,会自动生成输出文件

#6 节点上的服务程序的标准错误重定向到标准输出

#7   激活器跟踪级别,通常有0,1,2,3级,默认是0

#8   对象适配器跟踪级别,通常有0,1,2,3级,默认是0

#9   服务跟踪级别,通常有0,1,2,3级,默认是0

2.2     客户端配置

客户端的配置很简单,和分布式相关的配置就一项,添加如下:

#

# The IceGridlocator proxy.

#

Ice.Default.Locator=IceGridRDDataSource/Locator:default-h 10.0.2.241 -p 12000:default -h 10.0.2.242-p 12000 #注册服务的端点信息(主注册服务和所有的从注册服务),用于定位

3. 结果验证

3.1  程序方式

1. 启动服务器

1) icegridnode–Ice.Config=config_master.grid  启动主注册服务和节点1

2) icegridnode–Ice.Config=config_slave.grid   启动从注册服务和节点2

3) icegridadmin–Ice.Config=config_master.grid -e “application add app.xml”   部署分布式服务

4) icegridnode–Ice.Config=config.node 启动节点3

2. 启动客户端,进行多次远程调用,根据执行情况就可以判断服务器端是否配置成功。

3.2  工具方式

用Ice官方提供的可视化管理工具IceGridGUI.jar来验证和管理icegrid的部署。

打开dos窗口,在命令行下进入C:\Program Files\ZeroC\Ice-3.4.1\bin目录下,然后运行“java –jar IceGridGUI.jar”,弹出IceGrid Admin的主界面

1. 高级应用配置

4.1  集成IceBox

在文档《IceBox开发和配置》(当前是1.0版)中,介绍了一个IceBox服务程序的开发方法和单独应用中配置和管理的过程。在实际的应用中,IceBox服务通常集成到IceGrid中,并通过IceGrid进行激活和部署。

本章节中IceBox服务是集成在IceGrid中,并通过IceGrid进行部署,所以IceBox服务的配置信息不再同《IceBox开发和配置》中一样在config.icebox中描述,而是直接配置在部署文件app.xml中。那也就是说,IceGrid集成IceBox服务,只需要在app.xml文件中添加Icebox服务相关的配置信息就可以了。事实上,有关Ice所有的配置信息(除IceGrid自身的配置信息),都可以添加到app.xml中,并通过icegrid部署后生效。

下面各节详细描述IceBox服务的集成过程。

4.1.1  IceBox服务程序编写

请参考文档《IceBox开发和配置》,这里不再详述。由于IceBox服务相关的配置信息都放在了app.xml中,并且服务是通过IceGrid按需激活的,因此这里程序代码略有调整。下面列出IceBox服务的实现代码:

文件名:ServerService.java

import main.java.DataSource;

import IceBox.Service;

public class ServerService implements IceBox.Service {

    /**

    * @param name 配置文件中的service名称

    * @param communicator对象,由IceBox.ServiceManager负责创建和销毁。

    *          可能同时被其他服务共享使用(由配置文件决定),object Adapter的名

    *          称必须是唯一的;

    * @param args  配置文件中的参数列表

    * @Override

     **/

    public void start(String name,Ice.Communicator communicator,

                      String[] args){

       //创建objectAdapter,名称有配置文件决定

       Adapter =communicator.createObjectAdapter(

                            “RTDataSystem-“+name);

       //创建servant

       StringRTDataSourceIdentity = communicator.getProperties().

                                  getProperty(“RTDataSource.Identity”);

       DataSourceobjDataSrc = new DataSource(“dataSource”);

        Adapter.add(objDataSrc,

           communicator.stringToIdentity(RTDataSourceIdentity));

        Adapter.activate();

    }

    /**

     *

    * @param args

    * @Override

     *

    **/

    public void stop()

    {

       Adapter.destroy();

    }

    private Ice.ObjectAdapter Adapter;

}

4.1.2  IceGrid集成IceBox服务

IceGrid集成IceBox只和部署文件(app.xml)有关,IceBox服务(service)的粒度和普通的server是一样的,因此IceBoxservice的部署和普通的server非常类似,它同样有模板、服务(service)和实例化的概念,可以将IceBox service理解为一个特殊的server。

为了能更清楚的描述这个集成配置的过程,在IceGrid配置的基础上,添加IceBox服务。具体目标如下:

1.      集成ServerService服务(service),并且ServerService服务(service)使用的服务对象和之前server的服务对象使用同一个(type–::RTDataSystem::RTDataSource)

2.      在节点1(node_1)上添加IceBox服务功能(IceBox-Node1),这个IceBox服务包含了5个ServerService服务;同样的在节点2(node_2)上也添加一个IceBox服务功能(IceBox-Node2),也包含了5个ServerService服务

3.      这些IceBox服务中分布的多个服务(service)和之前已经存在的服务(server)一起通过IceGrid实现负载均衡

为了实现上述的功能,需要添加IceBox服务的相关配置,首先看一下此时app.xml的变化,变化和添加部分用浅灰阴影标出。

app.xml

<?xml version=”1.0″encoding=”UTF-8″ ?>

<icegrid>

<applicationname=”RTDSSystem“>

<server-templateid=”RTDSSystemServer“>

<parameter name=”index“/>

<server id=”RTDSSystemServer-${index}” exe=”java“activation=”on-demand“>

<adapter name=”RTDataSysytem“endpoints=”tcp

replica-group=”RTDataSystemGroup“/>

<option>jar</option>

<option>ServerApp.jar</option>

</server>

</server-template>

 

<!— begin服务模板定义–>

1   <service-templateid=”RTDSystemService“>

2       <parameter name=”name“/>

3       <service name=”${name}” entry=”ServerService“>

4           <description>A simple service named after ${name}</description>

5           <properties>

6             <property name=”RTDataSource.Identity” value=”RTDataSource“/>

7           </properties>

8           <adapter name=”RTDataSystem-${name}” endpoints=”tcp

id=”RTDataSystem-${name}” replica-group=”RTDataSystemGroup

server-lifetime=”false“/>

11      </service>

12  </service-template>

<!– end服务模板定义–>

 

<replica-groupid=”RTDataSystemGroup“>

<load-balancingtype=”round-robin“/>

<!–load-balancingtype=”ordered” /–>

<!–load-balancingtype=”adaptive” /–>

<!–load-balancingtype=”random” n-replicas=”0″/–>

<object identity=”RTDataSource” type=”::RTDataSystem::RTDataSource“/>

</replica-group>

 

 

<node name=”node_1“>

<server-instancetemplate=”RTDSSystemServer” index=”1“/>

<server-instancetemplate=”RTDSSystemServer” index=”11“/>

<server-instancetemplate=”RTDSSystemServer” index=”111“/>

<!— begin IceBox服务配置 IceBox-Node1–>

1     <icebox id=”IceBox-Node1” activation=”on-demand“exe=”java”>

2        <description>Asample IceBox server IceBox-Node1</description>

3        <option>IceBox.Server</option>

4        <properties>

5           <property name=”IceBox.InstanceName” value=”${server}“/>

6           <property name=”Ice.Admin.Endpoints” value=”tcp -h 10.0.2.241“/>

7           <property name=”IceBox.Trace.ServiceObserver” value=”1“/>

8        </properties>

9        <service-instance template=”RTDSystemService” name=”one“/>

10       <service-instancetemplate=”RTDSystemService” name=”two“/>

11       <service-instancetemplate=”RTDSystemService” name=”three“/>

12       <service-instancetemplate=”RTDSystemService” name=”four“/>

13       <service-instancetemplate=”RTDSystemService” name=”five“/>

14     </icebox>

<!— end IceBox服务配置 IceBox-Node1–>

</node>

<node name=”node_2“>

<server-instancetemplate=”RTDSSystemServer” index=”2“/>

<server-instancetemplate=”RTDSSystemServer” index=”22“/>

<server-instancetemplate=”RTDSSystemServer” index=”222“/>

<!— begin IceBox服务配置 IceBox-Node2–>

1     <icebox id=”IceBox-Node2” activation=”on-demand“exe=”java“>

2        <description>Asample IceBox server IceBox-Node2</description>

3        <option>IceBox.Server</option>

4        <properties>

5           <property name=”IceBox.InstanceName” value=”${server}“/>

6           <property name=”Ice.Admin.Endpoints” value=”tcp -h 10.0.2.242“/>

7           <property name=”IceBox.Trace.ServiceObserver” value=”1“/>

8        </properties>

9        <service-instancetemplate=”RTDSystemService” name=”2-one”/>

10       <service-instancetemplate=”RTDSystemService” name=”2-two“/>

11       <service-instancetemplate=”RTDSystemService” name=”2-three“/>

12       <service-instancetemplate=”RTDSystemService” name=”2-four“/>

13       <service-instancetemplate=”RTDSystemService” name=”2-five“/>

14     </icebox>

<!— begin IceBox服务配置 IceBox-Node2–>

</node>

<node name=”node_3“>

<server-instancetemplate=”RTDSSystemServer” index=”3“/>

</node>

</application>

</icegrid>

app.xml中增加的IceBox服务相关的配置部分如下:

n  服务摸板(Service Template):

可以对比一下servertemplate的定义,两者基本上没有什么区别,最大的不同是

Server template中server是指定一个可执行的程序,而service中指定的是动态加载

的组件入口。以下解释上述配置中的服务模板的定义:

第1行指定定义模板的id,唯一标志一个服务模板,第12是闭合标签;

第2行定义了一个参数name,默认值是“name”;

第3~11行定义了模板中使用的服务(service),并在该service中指定了名称、

入口、描述信息、配置属性,定义了一个对象适配器;

第4行,是该服务的描述信息;

第5~7行,是属性定义列表,这里定义了一个属性RTDataSource.Identity,并

指定其值为RTDataSource;

第8行,定义了一个对象适配器,指定了其name、endpoints、id、replica-group

等属性信息,这个基本上和server中adapter的定义没有什么区别

 

以上内容就是service模板的定义。

n  IceBox服务(IceBox-Node1):

                 icebox服务的定义被包含在分布的服务器节点中,主要包括三部分的信息:

1.      IceBox服务的启动配置信息

2.      IceBox的属性配置信息

3.      Service服务实例化列表

下面解释这块内容:

第1~3行,指定了IceBox服务的名称,启动方式,启动执行程序等

第4~8行,指定了IceBox服务的属性配置列表,这里定义了IceBox服务的实

例名称、管理器访问端点以及service被跟踪的级别

第9~13行,实例化了5个service服务

至此,一个包含了5个serverservice服务的IceBox服务被集成在node1中。

n  IceBox服务(IceBox-Node2)

同IceBox服务(IceBox-Node1)中描述,只是具体value有所不同,这里不再解释。

  4.1.3  测试验证

验证方式同第3章,这里不再赘述。部署完成后,就可以通过IceGridGUI.jar程序来进行管理

来源:http://blog.csdn.net/educast/article/details/9414789

struts2 upgrade 2.3 to 2.5 migration 升级向导

Dependencies

Update Struts dependencies to 2.5.

Remove the following plugin dependencies because they were dropped and aren’t supported anymore.

  • Dojo Plugin
  • Codebehind Plugin
  • JSF Plugin
  • Struts1 Plugin

StrutsPrepareAndExecuteFilter

The org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter was moved to org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.

In web.xml replace this:

<filter>
    <filter-name>struts2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>

with that:

<filter>
    <filter-name>struts2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>

There were other package changes, please read Version Notes 2.5 for more details.

DTD

Struts DTD was updated to 2.5 version.

In struts.xml replace 2.3 DTD version:

<!DOCTYPE struts PUBLIC
        "-//Apache Software Foundation//DTD Struts Configuration 2.3//EN"

with 2.5:

<!DOCTYPE struts PUBLIC
        "-//Apache Software Foundation//DTD Struts Configuration 2.5//EN"

Tags attributes

The id attribute was replaced with var attribute in the following tags.

  • <s:action>
  • <s:append>
  • <s:bean>
  • <s:date>
  • <s:generator>
  • <s:iterator>
  • <s:merge>
  • <s:number>
  • <s:set>
  • <s:sort>
  • <s:subset>
  • <s:text>
  • <s:url>

If you have something like that in your code:

<s:url id="url" action="login">

change it to:

<s:url var="url" action="login">

The <s:set> tag name attribute is replaced with var attribute.

From:

<s:set id="str1" value="'string1 value'" />
<s:set name="str2" value="'string2 value'" />

to:

<s:set var="str1" value="'string1 value'" />
<s:set var="str2" value="'string2 value'" />

Also escape attribute was renamed to escapeHtml attribute.

From:

<s:property escape="true" var="someProperty"/>

to:

<s:property escapeHtml="true" var="someProperty"/>

Div tag

The <s:div> tag was dropped.

Replace <s:div> with plain HTML <div> tag.

Field names

If you have field names which starts with single lower case letter, for example:

private String sTrng;
public String getSTrng() {...}
public void setSTrng(String str) {...}

change accessors to getsTrng and setsTrng.

Or better yet, change field names to not contain single lower case letter:

private String strng;
public String getStrng() {...}
public void setStrng(String str) {...}

For additional info see WW-3909.

Tiles

Depending on from which version of struts you upgrade and whether you used tiles-plugin or tiles3-plugin you may need to do different steps.

Struts 2.5 just provides a tiles-plugin which uses Tiles3. So support for Tiles2 has been dropped as well as the name tiles3-plugin.

Now the only maven dependency looks like this:

maven dependecy for tiles-plugin
<dependency>
    <groupId>org.apache.struts</groupId>
    <artifactId>struts2-tiles-plugin</artifactId>
    <version>${struts2.version}</version>
</dependency>

You may need to update DTD in your tiles.xml files to Tiles3:

tiles3 dtd
<!DOCTYPE tiles-definitions PUBLIC
       "-//Apache Software Foundation//DTD Tiles Configuration 3.0//EN"

A Listener in web.xml is required. It is not necessary to configure paths to tiles.xml files here as they are picked up automatically.

StrutsTilesListener in web.xml
<listener>
  <listener-class>org.apache.struts2.tiles.StrutsTilesListener</listener-class>
</listener>

Optionally you may remove TilesDefinitions from XML and annotate actions instead. See Tiles Plugin for more details.

Temp/Work directory of ApplicationServer/ServletContainer

Users reported it was necessary for them to remove temp/work directory of their ApplicationServer/ServletContainer. Likely to force server to recompile JSPs.

来源:https://cwiki.apache.org/confluence/display/WW/Struts%202.3%20to%202.5%20migration

WordPress错误:无法安装这个包。PCLZIP_ERR_MISSING_FILE (-4) : Missing archive file

WordPress更新或是上传插件或主题错误时出现“无法安装这个包。PCLZIP_ERR_MISSING_FILE (-4) : Missing archive file”错误在某些配置不够完善的主机中可能会出现这种情况。这是因为空间中temp目录没有设置访问权限的问题,需要空间商为你设置目录访问权限,一般这种要求他们是不会理的,所以我们只能改变WordPress的上传临时目录。

解决方法如下

1. 通过网站FTP打开WordPress根目录下的 wp-config.php 文件,找到如下代码:

/** WordPress 目录的绝对路径。 */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

2. 在下面增加如下代码即可:

/** 指定WordPress的临时目录 */
define('WP_TEMP_DIR', ABSPATH . 'wp-content/temp');

3. 最后在 /wp-content/ 文件夹下新建个一个名为 temp 的文件夹,然后再重新上传或者更新下载插件和主题就可以了。

最好叫 temp 权限和系统中一致为777

Go 1.8 正式发布,编译时间比 Go 1.7 提高约 15%

今天Go 团队很高兴地宣布Go 1.8发布了。现已提供下载。整个标准库有了显著的性能提升和变化。该版本主要的更新内容如下:

  • Go 1.7中为64位x86引入的编译器后端现在用于所有体系结构,这些体系结构将会有显著的性能改进。例如,我们的基准程序所需的CPU时间在32位ARM系统上减少了20-30%。在此版本中,64位x86系统还有一些性能改进,编译器和链接器更快了,编译时间应该比Go 1.7提高约15%。但是在这一领域还有很长的路要走:我们希望在未来版本中实现更快的编译速度。
  • 垃圾收集暂停时间明显更短,通常在100微秒以下,有时候甚至低至10微秒。
  • HTTP服务器添加对 HTTP/2 Push的支持,允许服务器抢先发送响应到客户端。这对于通过消除往返行程来最小化网络延迟非常有用。HTTP服务器现在还支持正常关机了,允许服务器通过在服务所有正在运行的请求之后关闭,而最小化停机时间。
  • 上下文(添加到Go 1.7中的标准库)提供了取消和超时机制。Go 1.8在标准库中添加了更多对上下文的支持,包括数据库/ sql和net包以及net / http包中的Server.Shutdown。
  • 现在使用新添加的Slice函数在排序包中对切片进行排序更简单。例如,要通过“名称”字段对结构体片段进行排序:
sort.Slice(s,func(i,j intbool {return s [i] .Name <s [j] .Name})

更多新版本的添加、改进和修复内容,以及上面列出的改进的详细信息请查看Go 1.8发行说明。

为了庆祝发布,世界各地的Go用户组都在本周举办发布会,这已经成为Go社区的一个传统,所以如果你错过了这一次,那么请在 GO 1.9 发布前留意。

via:https://blog.golang.org/go1.8

Java 9进入第一轮问题修复阶段

来源:infoq.com  作者:Abraham Marín Pérez ,译者 尚剑

Java 9功能特性正式完成,这意味着第一个问题修复阶段已经开始。HTTP/2客户端没有在截止日期前完成,现已降级为孵化器功能。由于现在的目标是在7月准备好可发布的Java 9,所以目前不太可能添加任何新的JEP。

InfoQ此前的报道中提到,第一轮问题修复阶段,或者说“启动Rampdown”阶段的目的是解决P1至P3级别的问题。其中,根据Java平台的首席架构师Mark Reinhold提出的流程,问题修复应该优先考虑Java 9中的新问题,而不是影响Java 9但已经存在于Java 8或更早版本Java中的问题,之所以这么做,可能是因为相对于新的问题,公众更容易忍受已经存在的问题。Reinhold提供的缺陷列表显式地过滤掉了只与文档、演示和测试相关的缺陷,这似乎表明了他们对用户体验的关注。在撰写本文时,该列表中有194个缺陷。

这一阶段还包括一个规定,如果有正当理由,可以留下一些未解决的P1至P2级别的问题。希望推迟其解决方案的问题所有者必须在错误报告中指出其请求的原因(复杂性、风险、时间不足等),然后相关区域负责人、小组负责人和JDK 9 Project 负责人将分析这些数据并同意或拒绝延期。在写这篇文章的时候,这个列表中暂时还没有推迟请求,但以后可能会出现。

这个Rampdown阶段在特定的扩展功能完成阶段之后进行,以给予一些JEP完成的时间。HTTP/2客户端以及增强弃用、jlink、和新的HotSpot编译系统都是在2016年7月出现风险的功能。其中,HTTP/2 Client是唯一一个没有最终做出来的功能,转而成为孵化器功能。这意味着,尽管HTTP/2 Client将包含在Java 9中,但默认情况下不可访问:该功能将被打包在前缀为jdk.incubator.的模块下,开发人员必须显式地使用–add-mod标记才能访问该功能。然而,如果开发人员选择这样做,他们将需要考虑到孵化器功能不是标准API的一部分,因此该功能可能随时被修改。

阅读英文原文Java 9 Enters First Bug Fixing Round

Linux Kernel 3.18 LTS 终止支持 请升至 4.9 或 4.4 分支

在发布最后一个维护版本更新之后,Linux 稳定版内核维护者 Greg Kroah-Hartman 宣布 Linux Kernel 3.18 分支走到了生命的尽头。而 3.18 LTS 原计划于今年 1 月终止支持。

Linux Kernel 3.18.48 LTS 是该分支的最后版本,根据短日志显示该版本共计调整了 50 个文件,插入 159 处删除 351 处。升级网络堆栈的同时改善了 Bluetooth, Bridge, IPv4, IPv6, CAIF 和 Netfilter,并升级了 USB, SCSI, ATA, media, GPU, ATM, HID, MTD, SPI 和网络(有线和无线)驱动。新发布的 3.18.48 还修正了 3.18.47 和 3.18.27 中的一个 bug。

LTS 版通常会提供大约两年的支持时间,3.18 是在 2014 年 12 月发布的。如果你当前还在使用该内核分支,那么现在你应该升级至更新的 LTS 版本,例如 Linux Kernel 4.9 或者 4.4,这两个版本要比 3.18 更加的安全和强悍。不过 Linux Kernel 3.18 主要被 Google 和其他供应商应用于一些 Android 设备、部分 Chromebook 上,Kroah-Hartman 建议用户拒绝购买仍然使用 3.18 LTS 的供应商的设备。如果无法升级内核开发者也提供了一些建议。

“如果你在使用 Linux Kernel 3.18 中有困难,那么我可以给你提供一些帮助。首先,你需要和硬件供应商反馈,要求尽快升级否则不再购买他们的产品。如果供应商还是不升级,请致信我们让我们出面和厂商进行沟通,出现这个问题的肯定不止你一个人。”

来源:http://www.oschina.net/news/81799/linux-kernel-3-18-48-released

喝酒与开发,新年了还是喝酒庆祝一下好了

新的一年了,还是喝酒庆祝一下好了。

大家喝的是啤酒。这时你入座了。
你给自己倒了杯可乐,这叫低配置。
你给自已倒了杯啤酒,这叫标准配置。
你给自己倒了杯茶水,这茶的颜色还跟啤酒一样,这叫木马。
你给自己倒了杯可乐,还滴了几滴醋,不仅颜色跟啤酒一样,而且不冒热气还有泡泡,这叫超级木马。
你的同事给你倒了杯白酒,这叫推荐配置。

人到齐了,酒席开始了。
你先一个人喝了一小口,这叫单元测试。
你跟旁边的人说哥们咱们随意,这叫交叉测试。
但是他说不行,这杯要干了,这叫压力测试。
于是你说那就大家一起来吧,这叫内部测试。
这个时候boss向全场举杯了,这叫公开测试。

菜过三巡,你就不跟他们客气了。
你向对面的人敬酒,这叫p2p.
你向对面的人敬酒,他回敬你,你又再敬他……,这叫tcp.
你向一桌人挨个敬酒,这叫令牌环。
你说只要是兄弟就干了这杯,这叫广播。
可是你的上司jj听了不高兴了,只有兄弟么,罚酒三杯。这叫炸弹。
可是你的下级mm听了不高兴了,我喝一口,你喝一杯,这叫恶意攻击。
有一个人过来向这桌敬酒,你说不行你先过了我这关,这叫防火墙。
你的小弟们过来敬你酒,这叫一对多。
你是boss,所有人过来敬你酒,这叫服务器。

酒是一样的,可是喝法是不同的。
你喝了一杯,boss喝了一口,这叫c#。
你喝了一杯,mm喝了一口,这叫vb。
你喝了一杯,你大哥喝了半杯,这叫c++。
你喝了半杯,你小弟喝了一杯,这叫汇编。
你喝了一杯,你的搭档也喝了一杯,这叫c。

酒是一样的,可是喝酒的人是不同的。
你越喝脸越红,这叫频繁分配释放资源。
你越喝脸越白,这叫资源不释放。
你已经醉了,却说我还能喝,叫做资源额度不足。
你明明能喝,却说我已经醉了,叫做资源保留。
你喝一段时间就上厕所,这叫cache。

酒过三巡,你也该活动活动了。
你一桌一桌的走,这叫轮巡。
你突然看到某一桌的漂亮mm,走了过去,这叫优先级。
你去了坐下来就不打算走了,这叫死循环。
你的老大举杯邀你过去,你只好过去,这叫启动事件。
你向一桌敬酒,他们说不行不行我们都喝白的,于是你也喝白的,这叫本地化。
你向boss敬酒,可是boss被围了起来,你只能站在外圈,这叫排队。
你终于到了内圈,小心翼翼的向前一步,这叫访问临界区。
你拍着boss的肩膀说哥们咱们喝一杯,这叫越界。
你不知喝了几圈了,只会说两个字,干了,这叫udp。
可是还有人拿着酒瓶跑过来说,刚才都没跟你喝,这叫丢包。

喝酒喝到最后的结果都一样
你突然跑向厕所,这叫捕获异常。
你在厕所吐了,反而觉得状态不错,这叫清空内存。
你在台面上吐了,觉得很惭愧,这叫程序异常。
你在boss面前吐了,觉得很害怕,这叫系统崩溃。
你吐到了boss身上,只能索性晕倒了,这叫硬件休克。

喝挂了,宕机

响应了国家号召不喝高度酒,都把白酒换成了白葡萄酒,这叫最佳实践

不喝不准走,这叫锁,喝了才让走,这叫解锁

边喝边吐是不是叫溢出呢?

边喝边尿叫多线程?

来源:https://my.oschina.net/xxiaobian/blog/818235

Firebug 宣布不再维护,讲不出再见!

Firebug 在其官方网站上宣布 —— “Firebug 扩展不再进行开发或维护,我们邀请您使用 Firefox 的内置开发工具以代替”。

Firebug 是 Firefox 下的一款开发类插件,现属于 Firefox 的五星级强力推荐插件之一。它集 HTML 查看和编辑、Javascript 控制台、网络状况监视器于一体,是开发 JavaScript、CSS、HTML 和 Ajax 的得力助手。Firebug 如同一把精巧的瑞士军刀,从各个不同的角度剖析 Web 页面内部的细节层面,给 Web 开发者带来很大的便利。

来自:http://getfirebug.com/

WordPress 4.7 “Vaughan”发布,内容管理系统

WordPress 开发团队发布了 WordPress 4.7 正式版 —“Vaughan” 。取名“Vaughan”以纪念传奇的爵士乐歌手Sarah“Sassy”Vaughan。现在可以更新了。新版带来全新的默认主题,定制器加入了新功能,REST API 内容端点,更多开发者工具。

更新如下:

  • 新的主题 — Twenty Seventeen。全新的默认主题可让您的网站通过引人入胜的精选图片和视频头部生动呈现。

  • WordPress 4.7 为自定义程序添加了新功能,帮助您完成主题的初始设置,在一个不间断的工作流程中对所有更改进行非破坏性实时预览。
  • WordPress 4.7 带来了针对帖子、评论、条款、用户,元和设置的 REST API 端点。

来源

下载地址:https://wordpress.org/download/

php-fpm添加service服务

Nginx通过FastCGI运行PHP比Apache包含PHP环境有明显的优势,最近有消息称,PHP5.4将很有可能把PHP-FPM补丁包含在内核里,nginx服务器平台上运行PHP将更加轻松,下面我们就来看一篇php-fpm平滑启动并配置服务例子。

我的PHP是源码安装的。php-fpm在PHP 5.3.2以后的版本不支持以前的php-fpm (start|restart|stop|reload) ,那么如果将php-fpm配置成服务,并添加平滑启动/重启。

配置php-fpm.conf(vi  php-7.1.0/etc/php-fpm.conf),将pid(;pid = run/php-fpm.pid)前的;去掉。

因为编译安装php的,所以会在php目录生成很多二进制文件,找到init.d.php-fpm,拷贝到init.d下。

cp  php-7.1.0/sapi/fpm/init.d.php-fpm /etc/init.d/php-fpm

设置权限,并添加服务

chmod +x /etc/init.d/php-fpm
chkconfig –add php-fpm

以后可以使用如下命令管理php-fpm了

service php-fpm status

service php-fpm start
service php-fpm restart
service php-fpm reload

service php-fpm stop

打造你的php安全程序第一步:禁止掉不安全的php函数(php.ini)

为了使php程序更安全,很多站长都选择了禁用一些比较敏感的函数,那影响php安全的函数到底有哪些呢,下面我们列出了一些:
1、phpinfo()
功能描述:输出 PHP 环境信息以及相关的模块、WEB 环境等信息。
危险等级:中
2、passthru()
功能描述:允许执行一个外部程序并回显输出,类似于 exec()。
危险等级:高
3、exec()
功能描述:允许执行一个外部程序(如 UNIX Shell 或 CMD 命令等)。
危险等级:高
4、system()
功能描述:允许执行一个外部程序并回显输出,类似于 passthru()。
危险等级:高
5、chroot()
功能描述:可改变当前 PHP 进程的工作根目录,仅当系统支持 CLI 模式
PHP 时才能工作,且该函数不适用于 Windows 系统。
危险等级:高
6、scandir()
功能描述:列出指定路径中的文件和目录。
危险等级:中
7、chgrp()
功能描述:改变文件或目录所属的用户组。
危险等级:高
8、chown()
功能描述:改变文件或目录的所有者。
危险等级:高
9、shell_exec()
功能描述:通过 Shell 执行命令,并将执行结果作为字符串返回。
危险等级:高
10、proc_open()
功能描述:执行一个命令并打开文件指针用于读取以及写入。
危险等级:高
11、proc_get_status()
功能描述:获取使用 proc_open() 所打开进程的信息。
危险等级:高
12、error_log()
功能描述:将错误信息发送到指定位置(文件)。
安全备注:在某些版本的 PHP 中,可使用 error_log() 绕过 PHP safe mode,
执行任意命令。
危险等级:低
13、ini_alter()
功能描述:是 ini_set() 函数的一个别名函数,功能与 ini_set() 相同。
具体参见 ini_set()。
危险等级:高
14、ini_set()
功能描述:可用于修改、设置 PHP 环境配置参数。
危险等级:高
15、ini_restore()
功能描述:可用于恢复 PHP 环境配置参数到其初始值。
危险等级:高
16、dl()
功能描述:在 PHP 进行运行过程当中(而非启动时)加载一个 PHP 外部模块。
危险等级:高
17、pfsockopen()
功能描述:建立一个 Internet 或 UNIX 域的 socket 持久连接。
危险等级:高
18、syslog()
功能描述:可调用 UNIX 系统的系统层 syslog() 函数。
危险等级:中
19、readlink()
功能描述:返回符号连接指向的目标文件内容。
危险等级:中
20、symlink()
功能描述:在 UNIX 系统中建立一个符号链接。
危险等级:高
21、popen()
功能描述:可通过 popen() 的参数传递一条命令,并对 popen() 所打开的文件进行执行。
危险等级:高
22、stream_socket_server()
功能描述:建立一个 Internet 或 UNIX 服务器连接。
危险等级:中
23、putenv()
功能描述:用于在 PHP 运行时改变系统字符集环境。在低于 5.2.6 版本的 PHP 中,可利用该函数
修改系统字符集环境后,利用 sendmail 指令发送特殊参数执行系统 SHELL 命令。
危险等级:高

禁用方法如下:
打开/etc/php.ini文件,
查找到 disable_functions ,添加需禁用的函数名,如下:
phpinfo,eval,passthru,exec,system,chroot,scandir,chgrp,chown,shell_exec,proc_open,proc_get_status

看过这些函数,站长们应该去检查一下自己的php.ini 看看这些函数是否禁用了。

当然禁止了这些可能会引起安全因素的php函数。你还必须在php.ini里,进一步把php的错误给关闭,这样才更加有针对性的排除你的php被别人利用错误信息进行攻击。
在php.ini里把
display_error = On
改为:
display_error = Off 即可;

WordPress元老Alex King逝世 与癌症抗争两年半

wordpress alex king

WordPress初期开发者Alex King

北京时间9月29日下午消息,WordPress初期开发者Alex King昨天夜间在家中逝世。Alex King于2013年1月被诊断出癌症,与癌症抗争了两年半。

Alex King在WordPress生态系统中有着巨大的影响力,他参与了从该网站前身b2到现在的WordPress的重建,也参与构建了WordPress 第一个客户端,还建立了第一家针对WordPress的咨询机构。他为大量WordPress功能的开发奠定了基础,甚至包括如今广泛使用的“一键分享” 图标的原型。

8月24日,Alex King在博客上公布了他的遗愿,希望其他人写下对他以及他工作成就的印象,并提交给他的妻子。(李林)

Beanstalkd 使用

一、安装

1、官网

https://kr.github.io/beanstalkd/

2、安装

yum install beanstalkd --enablerepo=epel

3、启动

/usr/bin/beanstalkd -l 0.0.0.0 -p 11300 -b /var/lib/beanstalkd/binlog -F

-b 开启binlog,断电后重启会自动恢复任务。

二、基本概念

1、Beanstalkd设计里面的核心概念:

  • job :一个需要异步处理的任务,是 Beanstalkd 中的基本单元,需要放在一个 tube 中。
  • tube :一个有名的任务队列,用来存储统一类型的 job,是 producer 和 consumer 操作的对象。
  • producer :Job 的生产者,通过 put 命令来将一个 job 放到一个 tube 中。
  • consumer :Job的消费者,通过 reserve/release/bury/delete 命令来获取 job 或改变 job 的状态。

2、job 的生命周期

Beanstalkd job life circle

当producer直接put一个job时,job就处于READY状态,等待consumer来处理,如果选择延迟put,job就先到 DELAYED状态,等待时间过后才迁移到READY状态。consumer获取了当前READY的job后,该job的状态就迁移到RESERVED, 这样其他的consumer就不能再操作该job。

当consumer完成该job后,可以选择delete, release或者bury操作;delete之后,job从系统消亡,之后不能再获取;release操作可以重新把该job状态迁移回READY(也 可以延迟该状态迁移操作),使其他的consumer可以继续获取和执行该job;有意思的是bury操作,可以把该job休眠,等到需要的时候,再将休 眠的job kick回READY状态,也可以delete BURIED状态的job。

正是有这些操作和状态,才可以基于此做出很多意思的应用,比如要实现一个循环队列,就可以将RESERVED状态的 job休眠掉,等没有READY状态的job时再将BURIED状态的job一次性kick回READY状态。

  • READY – 需要立即处理的任务,当延时 (DELAYED) 任务到期后会自动成为当前任务;
  • DELAYED – 延迟执行的任务, 当消费者处理任务后, 可以用将消息再次放回 DELAYED 队列延迟执行;
  • RESERVED – 已经被消费者获取, 正在执行的任务。Beanstalkd 负责检查任务是否在 TTR(time-to-run) 内完成;
  • BURIED – 保留的任务: 任务不会被执行,也不会消失,除非有人把它 “踢” 回队列;
  • DELETED – 消息被彻底删除。Beanstalkd 不再维持这些消息。

3、一些特性

优先级

任务 (job) 可以有 0~2^32 个优先级, 0 代表最高优先级,默认优先级为1024。

持久化

可以通过binlog将job及其状态记录到文件里面,在Beanstalkd下次启动时可以通过读取binlog来恢复之前的job及状态。

分布式容错

分布式设计和Memcached类似,beanstalkd各个server之间并不知道彼此的存在,都是通过client来实现分布式以及根据tube名称去特定server获取job。

超时控制

为了防止某个consumer长时间占用任务但不能处理的情况,Beanstalkd为reserve操作设置了timeout时间,如果该consumer不能在指定时间内完成job,job将被迁移回READY状态,供其他consumer执行。

三、Client Libraries For PHP

项目地址: https://github.com/pda/pheanstalk/

1、Producer 示例:向队列中添加job

$pheanstalk = new Pheanstalk_Pheanstalk('127.0.0.1');

$pheanstalk ->useTube('tubeName') ->put($jobData);

2、Consumer 示例:从队列中取出job

$job = $pheanstalk ->watch('tubeName') ->ignore('default') ->reserve();

echo $job->getData();

$pheanstalk->delete($job);

3、检查服务状态

$isAlive = $pheanstalk->getConnection()->isServiceListening(); //返回 true 或 false

4、获取某一 tube 的数据

try{
    $tubeStatus = $pheanstalk->statsTube('tubeName');
} catch (Exception $e){
    if($e->getMessage()=='Server reported NOT_FOUND'){     //tube 不存在
        $current_jobs_ready = 0;
    }
}

四、其他

1、PHP 版控制台

https://github.com/ptrofimov/beanstalk_console

2、Chrome 插件

https://chrome.google.com/webstore/detail/beanstalkd-dashboard/dakkekjnlffnecpmdiamebeooimjnipm

原文:segmentfault.com

10个令人惊讶的NodeJS开源项目

在几年的时间里,NodeJS逐渐发展成一个成熟的开发平台,吸引了许多开发者。有许多大型高流量网站都采用NodeJS进行开发,像PayPal,此外,开发人员还可以使用它来开发一些快速移动Web框架。

除了Web应用外,NodeJS也被应用在许多方面,本文盘点了NodeJS在其它方面所开发的十大令人神奇的项目,这些项目涉及到应用程序监控、媒体流、远程控制、桌面和移动应用等等。

  1.NodeOS

NodeOS是采用NodeJS开发的一款友好的操作系统,该操作系统是完全建立在Linux内核之上的,并且采用shell和NPM进行包管理,采用 NodeJS不仅可以很好地进行包管理,还可以很好的管理脚本、接口等。目前,Docker和Vagrant都是采用NodeOS的首个版本进行构建的。

 

  2.Noduino

许多硬件黑客希望通过Web页面即可控制他们的Arduino,Noduino就是这样的一个项目,一个简单灵活的JavaScript和NodeJS 框架,通过使用HTML5、Socket.IO和NodeJS的Web应用来控制Arduino。目前,该项目刚刚启动,支持一些常用功能,比如从 Arduino中捕获事件(例如点击按钮)等。

  3.Node-WebKit

Node-Webkit是一个基于Chromium与NodeJS的应用程序运行器,允许开发者使用Web技术编写桌面应用。它是NodeJS与WebKit技术的融合,提供一个跨Windows、Linux平台的客户端应用开发的底层框架。

跨平台开发并非易事,其中一种方式便是使用Web技术和Node-Webkit开发桌面应用来代替那些庞大且笨重的开发框架。

  4.PDFKit

PDFKit是采用NodeJS开发的一款PDF文档生成库,它使用一个“HTML5 canvas-like API”来创建矢量图形和字体嵌入,并且支持许多标准的PDF功能,如文件的安全性、表的创建、文本换行、项目符号、高亮提示、注释等PDF功能。

注意,PDFKit是一款PDF生成工具,而不是一个文档转换系统。如果你想对现有的PDF文档进行操作,你可以使用另一个NodeJS项目—— Scissors

  5.Log.io

Log.io是一个基于NodeJS开发的实时日志监控项目,在浏览器里访问。需要注意的是,Log.io只监视日志变动并不存储日志,不过这个没关系,只要知道日志存储在哪个机器上。

Log.io使用 Socket.io库发 送活动报告的,和其他的监控工具一样,Log.io也采用服务器-客户端的模式。Log.io由两部分组成:server和 harveste,server运行在机器 A(服务器)上监视和纪录其他机器发来的日志消息;log harvester 运行在机器 B(客户端)上用来监听和收集机器 B上的日志改动,并将改动发送给机器 A,每个需要纪录日志的机器都需要一个harvester。

  6.NodecastLeapcast

受谷歌Chromecast技术的启发,开发者使用NodeJS开发出不少Chromecast仿真应用。如Nodecast或Leapcast。在 PC上运行Nodecast或Leapcast,启动移动设备,选择一个支持Chromecast的应用程序,然后你就可以把移动广播上的内容映射到电脑 上了,把电脑当成一个流媒体使用。

在这两个应用中,Nodecast比较简单些,但相应的功能也比较少,它仅经过了YouTube和Google Music的测试( DEMO)。注意,大家不要把Nodecast与 Nodecast库混淆,后者使用DIAL发现协议提供链接设备(类似Chromecast)。

  7.Nexe

Nexe是一款小巧却非常实用的NodeJS工具,它可以为NodeJS应用创建单一可执行的文件,并且无需安装运行时,这样,一些非技术终端的用户就 无需变动NodeJS应用的所有依赖程序。如果你想发布一个NodeJS应用程序,并且没有GUI,Nexe则是您的最佳选择。目前该应用程序的一个弊端 是不能在Windows平台上工作,只适用于Linux和Mac OS X平台,并且它也不支持本地NodeJS模块。

  8.Hyro

Hyro是使用NodeJS开发的一款实时HTML5编辑器,如下图所示,左边显示HTML源码,右边显示内容。语法高亮由 CodeMirror提供。Hyro并不打算成为一款成熟的Web IDE,更像是一款轻量级的HTML或CSS记事本。

  9.Haroopad

Haroopad是一款Linux上的markdown编辑器,使用Chromium作为UI,支持Windows、Mac OS X和Linux。主题样式丰富,语法标亮支持54种编程语言。 如下图所示,一边是代码编辑窗口,一边是预览窗口,可以实时更新。其邮件导出功能可以将文档发送到Tumblr和Evernote。

  10.TiddlyWiki5

TiddlyWiki是一款交互式的wiki,非常灵活,它也可以在浏览器里作为单一的HTML文件或者是一款功能强大的NodeJS应用程序。

TiddlyWiki5是全新设计的5.0版本,它可以直接集成NodeJS解锁一系列的功能,但在单机模式下是不可用的。目前,TiddlyWiki5仍处于测试阶段。

来自: InfoWorld