WebLogic 10.3安装与配置 (Linux)[下]
§2.4 创建受管服务器的域
参考《WebLogic 10.3 for Win32》－《创建受管服务器的Domain和Server》。
§2.5 配置和启动节点管理器
§2.5.1 直接运行
$ cd /bea/wlserver_10.3/server/bin
$ ./startNodeManager.sh
§2.5.2 配置节点管理器作为Daemon
在/etc/rc.d/rc3.d添加一个启动节点管理器的文件。该文件核心内容是启动节点管理器，即：
su - weblogic -c "nohup /bea/wlserver_10.3/server/bin/startNodeManager &"
这样，Linux启动后时自动启动节点管理器。
Runlevel
The term runlevel refers to a mode of operation in one of the computer operating systems that implement Unix System V-style initialization. Conventionally, seven runlevels exist, numbered from zero to six; though up to ten, from zero to nine, may be used. S is sometimes used as a synonym for one of the levels.
In standard practice, when a computer enters runlevel zero, it halts, and when it enters runlevel six, it reboots. The intermediate runlevels (1-5) differ in terms of which drives are mounted, and which network services are started. Lower run levels are useful for maintenance or emergency repairs, since they usually don't offer any network services at all. The particular details of runlevel configuration differ widely among operating systems, and slightly among system administrators.
The runlevel system replaced the traditional /etc/rc script used in Version 7 Unix.
Standard runlevels
Standard runlevels
ID Name Description
0 Halt Shuts down the system.
S Single-User Mode Does not configure network interfaces or start daemons.[1]
6 Reboot Reboots the system.
1 = Almost all systems use runlevel 1 for this purpose. This mode is intended to provide a safe environment to perform system maintenance. Originally this runlevel provided a single terminal (console) interface running a root login shell. The increasing trend towards physical access to the computer during the boot process has led to changes in this area.
Linux
The Linux operating system can make use of runlevels through the programs of the sysvinit project. After the Linux kernel has booted, the init program reads the /etc/inittab file to determine the behavior for each runlevel. Unless the user specifies another value as a kernel boot parameter, the system will attempt to enter (start) the default runlevel.
Typical Linux runlevels
Most Linux distributions, in addition to the standard runlevels, define the following additional runlevels:
Typical Linux runlevels
ID Name Description
1 Single-User Mode Does not: configure network interfaces, start daemons, or allow non-root logins.[2]
2 Multi-User Mode Does not: configure network interfaces or start daemons.[3]
3 Multi-User Mode with Networking Starts the system normally.[4]
4 Unused/User defined for special purposes
5 X11 As runlevel 3 + display manager.
^ = The additional behavior of this runlevel varies greatly. All distributions provide at least one virtual terminal. Some distributions start a login shell as the superuser; some require correctly entering the superuser's password first; others provide a login prompt, allowing any user access.
^ = In some cases, runlevels 2 and 3 function identically; offering a Multi-User Mode with Networking.
Debian Linux
Debian, as well as most of the distributions based on it, like early Ubuntu, does not make any distinction between runlevels 2 to 5.
Debian Linux runlevels
ID Description
0 Halt
1 Single user mode
2-5 Full multi-user with console logins and display manager if installed
6 Reboot
sidux
sidux, a Debian Sid based distribution (current 20081110). This is the list for sidux operating system runlevels, please note that it does differ from debian stable runlevels.
sidux Linux runlevels
ID Description
0 init 0 powers off the PC, halt
1 init 1 single user mode
2 init 2 Multi-User mode without network, and/or to stop or not enter X,
3 init 3 Multi-User mode with network not running the X Window System, and/or to stop or not enter X
4 init 4 to stop or not enter X
5 init 5 Multi-User mode with network running the X Window System, and/or to start X
6 init 6 Reboot
Ubuntu
Ubuntu 6.10 (Edgy Eft) and later contain Upstart as a replacement for the traditional init-process, but they still use the traditional init scripts and Upstart's SysV-rc compatibility tools to start most services and emulate runlevels.
Red Hat Linux and Fedora
Red Hat as well as most of its derivatives (such as CentOS) uses runlevels like this:
Red Hat Linux/Fedora runlevels
ID Description
0 Halt
1 Single user
2 Full multi-user with network enabled but most network services disabled
3 Full multi-user, console logins only
4 Not used/User definable
5 Full multi-user, with display manager as well as console logins
6 Reboot
Which services are started in which runlevels can be managed with the chkconfig tool, which keeps its configuration settings under /etc/rc.d/. /sbin/chkconfig --list lists all the services controlled by chkconfig and whether they are on/off for each runlevel. Setting a service A controlled by chkconfig, for levels X, Y and Z is as simple as /sbin/chkconfig --level XYZ A
SUSE Linux
SUSE uses a similar setup to Red Hat:
SUSE Linux runlevels
ID Description
0 Halt
1 Single-user
2 Full multi-user with no networking
3 Full multi-user without display manager
4 Not used/User definable
5 Full multi-user with display manager
6 Reboot
The services that run under a specific runlevel can be modified with YaST | System Services (runlevel) or with chkconfig command like the Red Hat based distributions.
Slackware Linux
Slackware Linux uses runlevel 1 for maintenance, as on other Linux distributions; runlevels 2, 3 and 5 identically configured for a console (with all services active); and runlevel 4 adds the X Window System.
Slackware Linux runlevels
ID Description
0 Halt
1 Single-user
2 Full multi-user NO display manager
3 Full multi-user NO display manager
4 Full multi-user with display manager
5 Not used/User definable
6 Reboot
Gentoo Linux
Gentoo Linux runlevels
ID Description
0 Halt
1 Single-user
2 Multi-user, no network
3 Full multi-user with display manager
4 Aliased for runlevel 3 (Full multi-user with display manager)
6 Reboot
System V Releases 3 and 4
System V runlevels
ID Description
0 Shut down system, power-off if hardware supports it (only available from the console)
1 Single-user mode, all filesystems unmounted but root, all processes except console processes killed
2 Multi-user mode
3 Multi-user mode with RFS (and NFS in release 4) filesystems exported
4 Multi-user, user-defined
5 Halt the operating system, go to firmware
6 Halt the system, reboot to default runlevel
s, S Identical to 1 (Single-user mode, all filesystems unmounted but root, all processes except console processes killed) except current terminal acts as the system console
Solaris
Solaris runlevels
ID Description
0 Operating system halted; (SPARC only) drop to OpenBoot prompt
S Single-user with only root filesystem mounted (as read-only)
1 Single-user mode with all local filesystems mounted (read-write)
2 Multi-user with most daemons started.
3 multi-user, identical to 2 (runlevel 3 runs both /sbin/rc2 and /sbin/rc3), with filesystems exported, plus some other network services started.
4 Alternative multi-user, user-defined
5 Shut down, power-off if hardware supports it
6 Reboot
HP-UX
HP-UX runlevels
ID Description
0 System halted
S Single-user, booted to system console only, with only root filesystem mounted (as read-only)
s Single user, identical to S except the current terminal acts as the system console
1 Single-user with local filesystems mounted (read-write)
2 Multi-user with most daemons started and Common Desktop Environment launched
3 Multi-user, nearly identical to runlevel 2 with NFS exported
4 Multi-user with VUE started instead of CDE
5, 6 user-defined
AIX
AIX does not follow the System V R4 (SVR4) run level specification, with run levels from 0 to 9 available, as well as from a to c. 0 and 1 are reserved, 2 is the default normal multi-user mode and run levels from 3 to 9 are free to be defined by the administrator. Run levels from a to c allow the execution of processes in that run level without killing processes started in another.
AIX runlevels
ID Name Description
0 reserved
1 reserved
2 Normal multiuser mode default mode
第三章 配置和管理
§3.1 配置单向SSL认证
WebLogic启用SSL连接需部署服务器证书、CA证书链、信任证书链。WebLogic安装完成后，在\wlserver_10.3\server \lib目录下会自动创建DemoIdentity.jks（密码DemoIdentityKeyStorePass
§3.1.1 创建Server存储库
§3.1.1.1 创建Server私钥
使用JDK自带的keytool工具创建Server私钥。命令如下：
keytool -genkey -alias AdminServer -keyalg RSA -keysize 1024 -keystore AdminServer.jks
该命令会询问存储库的密码和证书信息以及私钥保护密码。大致内容如下：
输入keystore密码：
再次输入新密码:
您的名字与姓氏是什么？
[Unknown]： AdminServer
您的组织单位名称是什么？
[Unknown]： Enterprise
您的组织名称是什么？
[Unknown]： WJZhiFu
您所在的城市或区域名称是什么？
[Unknown]： BeiJing
您所在的州或省份名称是什么？
[Unknown]： BJ
该单位的两字母国家代码是什么
[Unknown]： CN
CN=AdminServer, OU=Enterprice, O=WJZhiFu, L=BeiJing, ST=BJ, C=CN 正确吗？
[否]： y
输入的主密码
（如果和 keystore 密码相同，按回车）：
再次输入新密码:
填写时应注意：
CN域应和Server域名一致，不应使用Server的ip地址；
OU域应按颁发的证书类型划分为多个单元；如：Server、Enterprise、Person，可以使用编码；
O域应为公司的英文名称；
L域应为城市的英文名称；
ST域应为省的英文名称；
C域应为国家代码CN；
存储库的密码和私钥密码应不同。
§3.1.1.2 生成Server的证书申请文件
keytool -certreq -alias AdminServer -sigalg "MD5withRSA" -file AdminServer.csr -keystore AdminServer.jks
§3.1.1.3 认证证书申请
提交上步生成的AdminServer.csr证书申请文件提交给证书颁发机构进行认证。本例中使用openssl认证该证书申请，命令如下：
openssl ca -in AdminServer.csr -out AdminServer.crt -config openssl.cfg
§3.1.1.4 导入证书文件
从CA获取到认证的证书文件后，使用keytool将该证书文件导入到存储库。Keytool导入证书时，会自动检查证书的合法性，确认该证书是信任的 CA签署的。默认情况下，我们的CA证书没有包含在Java信任的CA清单中，因此先需要将我们的CA添加到Java的信任CA清单中。命令如下：
keytool -import -file ca.crt -keystore D:\bea\jdk160_05\jre\lib\security\cacerts
注意：请确认您使用的keytool的JDK位置，Java信任CA清单存储库即为该JDK的jre/lib/security/cacerts文件。
添加CA证书完成后，将该文件复制到WebLogic的server/lib目录，覆盖当前的cacerts文件，然后执行如下命令导入Server的证书文件。
keytool -import -trustcacerts -alias AdminServer -file AdminServer.crt -keystore AdminServer.jks
导入完成后，复制AdminServer.jks存储库到WebLogic的server/lib。至此，Server证书存储库准备就绪。
§3.1.2 创建CA证书存储库
从CA处下载CA证书文件。CA证书文件一般有两种形式，一是单独的CA证书文件，二是.p7b证书链文件。
§3.1.2.1 导入独立的CA证书文件
keytool可以导入DER格式（二进制）和PEM格式（BASE64编码格式，-----BEGIN CERTIFICATE-----打头，-----END CERTIFICATE-----结束）。命令如下：
keytool -importcert -file ca.crt -trustcacerts -alias "WJZHIFU CA" -
keystore WJZhiFuCA.jks
导入完成后，复制CA证书存储库到WebLogic的server/lib。
§3.1.2.2 导入p7b的CA证书文件
P7b文件不能直接导入到存储库，应使用openssl工具将p7b文件转换为每证书一个der文件，然后参考上节导入各个文件。
转换p7b文件的命令如下：
openssl pkcs7 -in ca.p7b -out ca.txt -outform PEM -inform DEA -print_certs
编辑ca.txt文件，将每个-----BEGIN CERTIFICATE-----打头，-----END CERTIFICATE-----结束的证书内容分别复制到一个文件中，然后顺序导入各个文件。导入完成后，导入完成后，复制CA证书存储库到 WebLogic的server/lib。
§3.1.3 部署证书文件
（1） 启动WebLogic服务器，使用管理员登录到控制台；
（2） 编辑EnvironmentServer的配置。本例编辑AdminServer；
（3） 编辑Server的Keystore属性；
Keystore选择为：Custom Identity and Custom Trust；
Custom Identity Keystore: 添加Server证书存储库全路径名；
Custom Identity Keystore Type: JKS
填写该Server存储库的密码；
Custom Trust Keystore: 填写CA证书存储库的全路径名；
Custom Trust Keystore Type: JKS
填写该CA存储库的密码；
Save
（4） 编辑Server的SSL配置；
Identity and Trust Locations: KeyStores
PrivateKey Alias: 填写为Server存储库私钥的别名，即AdminServer；
填写Server存储库私钥的密码；
Save。
至此，单向认证（客户端认证服务器）的SSL配置完成。
§3.2 配置双向SSL认证
比照WebLogic服务器单向SSL认证的配置，完成服务器端的SSL配置，然后编辑ServerSSLAdvance配置。
TwoWayClientCert：ClientCerts Requested and Enforced；
Inbound Certificate Validation: Builtin SSL Validation And Cert Path Validators；
Outbound Certificate Validation: Builtin SSL Validation And Cert Path Validators；
Save
启用Server双向认证后，如果客户端没有相应的证书，则无法连接服务器。
§3.3 WebLogic集群配置
本集群由三台计算机组成，AdminServer、Server1、Server2。AdminServer负责集群管理与部署，Server1和 Server2组成集群提供对外服务。
§3.3.1 准备证书文件
为AdminServer、Server1、Server2、Server1 NodeManager、Server2 NodeManager各准备一张Server证书，并参考“WebLogic Server双向SSL认证的配置”节，将这些证书和CA证书制作成如下文件：
文件名 证书组成 说明
ServerAdmin.jks AdminServer私钥
AdminServer证书 CN=AdminServer
Server1.jks Server1私钥
Server1证书 CN=server1.wjzhifu.com
Machine1.jks Machine1节点管理器私钥
Machine1节点管理器证书 CN=machine1
Server2.jks Server2私钥
Server2证书
Server2节点私钥
Server2节点证书 CN=server2.wjzhifu.com
Machine2.jks Machine2节点管理器私钥
Machine2节点管理器证书 CN=machine2
ServerCA.jks CA证书 CN=CA
注意：各证书的私钥密码应各不相同以提高安全性。
创建上述文件完成后，将ServerAdmin +ServerCA复制到管理服务器的wlserver_10.3\server\lib目录，Server1 + Machine1 + ServerCA复制到Server1的wlserver_10.3\server\lib目录，Server2 + Machine2 + ServerCA复制到Server2的wlserver_10.3\server\lib目录。
§3.3.2 创建管理服务器和受管服务器的域
参考“创建管理服务器的域”和“创建受管服务器的域”章节，分别为管理服务器和每个Server创建域，并为AdminServer配置双向的SSL。创建域时应注意各机器域名、管理账号、密码均应相同。
创建各服务器的域完成后，启动管理服务器，并按下列步骤添加机器、Server、配置集群。
§3.3.2.1 启动管理服务器
§3.3.2.2 启动管理员终端，并登录
§3.3.2.3 添加受管计算机
（1） 创建计算机；
（2） 编辑新建计算机的 NodeManager属性；
（3） 保存并生效；
§3.3.2.4 添加受管服务器
（1） 添加新Server并激活集群模式；
（2） 创建新的集群；
（3） 编辑新Server的属性，指定计算机；
（4） 保存并生效；
（5） 重启管理服务器。