itshow: 十一月 2010

2010年11月26日星期五

IBM刀片机箱管理模块日志信息收集

刀片管理模块（MM或者AMM）位于刀片机箱背面的右上方。

连接网线的一头到管理模块的 Remote managementand console (Ethernet) 口。另一头连接到笔记本的网口。笔记本网口的 IP 配置为 192.168.70.100/24。

在笔记本上，打开 IE 浏览器，输入管理模块的默认IP地址，192.168.70.125，默认用户名USERID，密码PASSW0RD。数字0而不是字母O。即可进入界面。

MM和AMM左边的内容栏可能不同。

如下界面，需要直接保存成.MTH格式的网页文件：

1、Monitor下面的：

System Status、Event Log、LEDs、Fule Gauge、Hardware VPD、Firmware VPD。

2、Blade Tasks下面的：

Power Restart、Configuration、Serial Over Lan。

3、I/O Module Tasks下面的：

Admin/PowerRestart、Configuration（其中每个模块还有各自的子界面，也都要保存下来）。

4、MM Control下面的：

General Information、Network Interfaces。

5、Service Tools下面的（仅AMM）：

Service Data、AMM Status。

除此之外，还需要保存成文本格式的：

位于Monitor下面的Event Log页面的右下角，点Save Log as Text File，并保存。

位于Service Tools下面的Service Data页面的右下角，点Save Service Data，并保存。

2010年11月21日星期日

[root@f51:Standby] config # reboot
Broadcast message from root (pts/0) (Mon Nov 22 15:12:46 2010):
The system is going down for reboot NOW!
[root@f51:Standby] config # date
Mon Nov 22 15:15:58 CST 2010

ping监控"Request timed out"数量如下：
Reply from 1.1.1.1: bytes=32 time<1ms TTL=255
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 1.1.1.1: bytes=32 time<1ms TTL=255

2010年11月14日星期日

一则vpn故障造成业务中断的处理过程

    客户报障描述：vpn接入系统出故障，接到N多报拆。具体为能通过ping激活vpn拨号，系统能自动弹出登陆对话框，不会报用户名和密码错误，但Netscreen-Remote客户端就是不会出现VPN成功连接后的黄色小钥匙，造成业务中断。
排障过程：让客户提供一个vpn测试帐号，发现报障情况属实。查看Netscreen-Remote Log Viewer中的日志，如下：
09:59:03.375 My Connections\ - Initiating IKE Phase 1 (IP ADDR=1.1.1.1)
09:59:03.406 My Connections\ - SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID, VID, VID, VID)
09:59:03.546 My Connections\ - RECEIVED<<< ISAKMP OAK AG (SA, VID, VID, VID, VID, KE, NON, ID, HASH, VID, NAT-D, NAT-D)
09:59:03.546 My Connections\ - Peer is NAT-T capable
09:59:03.546 My Connections\ - NAT is detected for Client
09:59:03.562 My Connections\ - SENDING>>>> ISAKMP OAK AG *(HASH, NAT-D, NAT-D, NOTIFY:STATUS_INITIAL_CONTACT)
09:59:03.562 My Connections\ - Established IKE SA09:59:03.562    MY COOKIE de ce 78 0 81 58 21 bc
09:59:03.562    HIS COOKIE 7a ff b1 c1 c7 37 c1 31
09:59:03.656 My Connections\ - RECEIVED<<< ISAKMP OAK TRANS *(HASH, ATTR)
09:59:09.343 My Connections\ - RECEIVED<<< ISAKMP OAK TRANS *(Retransmission)
09:59:15.343 My Connections\ - RECEIVED<<< ISAKMP OAK TRANS *(Retransmission)
09:59:18.015 My Connections\ - SENDING>>>> ISAKMP OAK TRANS *(HASH, ATTR)
09:59:18.109 My Connections\ - RECEIVED<<< ISAKMP OAK TRANS *(HASH, ATTR)
09:59:18.109 My Connections\ - Received Private IP Address = IP ADDR=11.2.1.234
09:59:18.109 My Connections\ - SENDING>>>> ISAKMP OAK TRANS *(HASH, ATTR)
09:59:18.203 My Connections\ - RECEIVED<<< ISAKMP OAK TRANS *(HASH, ATTR)
09:59:18.203 My Connections\ - SENDING>>>> ISAKMP OAK TRANS *(HASH, ATTR)
09:59:18.203 My Connections\ - Initiating IKE Phase 2 with Client IDs (message id: BF484846)09:59:18.203   Initiator = IP ADDR=11.2.1.234, prot = 0 port = 0
09:59:18.203   Responder = IP SUBNET/MASK=192.168.1.0/255.255.255.0, prot = 0 port = 0
09:59:18.203 My Connections\ - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID)
09:59:24.890
09:59:33.875 My Connections\ - QM re-keying timed out (message id: BF484846). Retry count: 1
09:59:33.875 My Connections\ - SENDING>>>> ISAKMP OAK QM *(Retransmission)
09:59:46.890
09:59:48.875 My Connections\ - QM re-keying timed out (message id: BF484846). Retry count: 2
09:59:48.875 My Connections\ - SENDING>>>> ISAKMP OAK QM *(Retransmission)
10:00:03.875 My Connections\ - QM re-keying timed out (message id: BF484846). Retry count: 310:00:03.875 My Connections\ - SENDING>>>> ISAKMP OAK QM *(Retransmission)
10:00:08.890
10:00:18.875 My Connections\ - Exceeded 3 re-keying attempts (message id: BF484846)
从日志中可看出IKE Phase 1已成功完成（红色加显），IKE Phase 2未完成（蓝色加显）。
接下来查看VPN服务器中相关的event，如下：
2008-02-20 09:56:11 system info 00536 IKE<121.201.217.55> Phase 2 msg ID
                                       <a29ebdc9>: Negotiations have failed.
2008-02-20 09:56:11 system info 00536 Rejected an IKE packet on ethernet1/1
                                       from 121.201.217.55:500 to
                                       1.1.1.1:500 with cookies
                                       462e118477c5ab9c and 99453c6c6b16eb87
                                       because the VPN does not have an
                                       application SA configured.
2008-02-20 09:56:11 system info 00536 IKE<121.201.217.55> Phase 2: No policy
                                       exists for the proxy ID received:
                                       local ID (<192.168.1.0>/<255.255.255.0>,
                                       <0>, <0>) remote ID (<11.2.1.234>/
                                       <255.255.255.255>, <0>, <0>).
2008-02-20 09:56:11 system info 00536 IKE<121.201.217.55> Phase 2 msg ID
                                       <a29ebdc9>: Responded to the peer's
                                       first message.
2008-02-20 09:56:11 system info 00536 IKE<121.201.217.55>: XAuth login was
                                       passed for gateway <VPN_Gateway>,
                                       username <testuser>, retry: 0, Client
                                       IP Addr<11.2.1.234>, IPPool name:
                                       <VPN_POOL>, Session-Timeout:<0s>,
                                       Idle-Timeout:<0s>.
2008-02-20 09:56:00 system info 00536 IKE<121.201.217.55>: Received initial
                                       contact notification and removed Phase
                                       1 SAs.
2008-02-20 09:56:00 system info 00536 IKE<121.201.217.55> Phase 1: Completed
                                       Aggressive mode negotiations with a
                                       <28800>-second lifetime.
2008-02-20 09:56:00 system info 00536 IKE<121.201.217.55> Phase 1: Completed
                                       for user <testuser>.
2008-02-20 09:56:00 system info 00536 IKE<121.201.217.55>: Received initial
                                       contact notification and removed Phase
                                       2 SAs.
2008-02-20 09:56:00 system info 00536 IKE<121.201.217.55>: Received a
                                       notification message for DOI <1>
                                       <24578> <INITIAL-CONTACT>.
2008-02-20 09:56:00 system info 00536 IKE<121.201.217.55> Phase 1: IKE
                                       responder has detected NAT in front of
                                       the remote device.
2008-02-20 09:56:00 system info 00536 IKE<121.201.217.55> Phase 1: Responder
                                       starts AGGRESSIVE mode negotiations.
从VPN服务器日志中可查看到更为详细的说明，从日志中可看出IKE Phase 1已成功完成（红色加显），IKE Phase 2未完成（蓝色加显），并对Phase 2未完成原因进行了描述。
VPN-SERVER-> get policy
Total regular policies 1, Default deny.
    ID From     To       Src-address   Dst-address Service      Action State   ASTLCB
     1 dialup Trust    Dial-Up VPN appserver    appservice    Tunnel enabled ---X-X
从上面可知，系统中只有一条policy，状态为启用（enabled）。同时也可知道这是一个拨号型VPN。查看VPN服务器中的Dst-address跟Netscreen-Remote客户端中的Remote Party Identity and Addressing设置是否相同：
VPN-SERVER-> get address trust name appserver
Name                 Address/Prefix-length           Flag Comments
appserver            192.168.1.0/24                  0200

从上面可知，VPN服务器Dst-address与Netscreen-Remote中的Remote Party Identity and Addressing设置的完全匹配。接着来查看VPN服务器Policy中的Service：
VPN-SERVER-> get service appservice
Name:       appservice
Category:   other          ID: 0   Flag: User-defined
Transport    Src port     Dst port   ICMPtype,code Timeout(min) Application
tcp           0/65535        80/80                        30
tcp           0/65535    1222/1223                        30
tcp           0/65535    2233/2234                        30
tcp           0/65535    2344/2345                        30
tcp           0/65535        23/23                        30
可以发现，放开的服务中并没有ping（ICMP type：8，code：0），增加ping：
VPN-SERVER->set service "appservice" + icmp type 8 code 0
故障解决，业务恢复正常。难道Juniper Netscreen配置xauth vpn时，一定要放开ping服务才能成功建立vpn连接？请高手指教。
最后说明平台版本：
客户端：Netscreen Remote 8.0.0（Build 14）
VPN服务器：Netscreen ISG-1000 （Software Version: 5.3.0r10.0, Type: Firewall+VPN）

Juniper NetsScreen设备ScreenOS升级指南

分两种情况：
1、设备已装载ScreenOS
2、设备未装载ScreenOS
一、设备已装载ScreenOS
此时又可分两种方法：
1、WebUI
1）下载最新版本的ScreenOS firmware；
2）打开web浏览器，以具有读写权限的管理员身份登陆到NetScreen设备；
3）备份已有的配置：Configuration > Update > Config File，单击Save to File，选择本地保存路径，单击Save；
4）Configuration > Update > ScreenOS/Keys > Firmware Update(ScreenOS)，所下图所示：

5）点击 Browse 浏览到本地新版本ScreenOS存放的路径或者输入其路径；
6）点击Apply；
7）点击OK继续，NetScreen设备将自动启动，当升级完成后将看到登陆界面；
8）登陆NetScreen设备，验证NetScreen设备是否升级到新版本。
2、CLI
1）下载最新版本的ScreenOS firmware；
2）通过telnet/ssh以具有读写权限的管理员身份登陆到NetScreen设备；
3）启动TFTP Server，检查TFTP应用是否正常，同时把ScreenOS firmware放置到TFTP Server相应目录中；
4）保存已有配置，在CLI命令行模式下输入：save config to tftp ip_address filename
5）在CLI命令行模式下输入：save soft from tftp ip_address filename to flash
ip_address：TFTP Server的IP地址；
filename：ScreenOS image文件名。
6）当upgrade完成后，必须重启NetScreen设备，输入reset回车，选择yes；
7）等待几分钟，NetScreen设备重启完成后重新登陆到Netscreen设备；
8）输入get system回车查看是否升级到新版本。
二、设备未装载ScreenOS
因设备未装载ScreenOS，只能通过Boot/Diag模式来升级ScreenOS，步骤如下：
1、用console配置线把PC的com口和NetScreen设备的console口连起来；
2、开启终端程序（如Windows自带的超级终端），reset或power up NetScreen设备；
3、在NetScreen设备启动过程中，当系统提示：
   Hit any key to run loader
   Hit any key to run loader
   Hit any key to run loader
可按任意键进入到Boot/Diag模式。
4、将会看到以下信息：
   Self IP address - enter an IP address that is on the same subnet as the TFTP server
   TFTP IP address - enter the IP address of the TFTP server
   Boot File name - enter the file name of the ScreenOS version to be upgraded to根据提示输入正确的参数。
比如：
Serial Number [0052062002000203]: READ ONLY
HW Version Number [1010]: READ ONLY
Self MAC Address [0010-db20-4e80]: READ ONLY
Boot File Name [ns5xt.5.0.0r8.0]: ns5xt.5.0.0r9.0
Self IP Address [10.100.31.178]: 172.19.50.254
TFTP IP Address [10.100.31.176]: 172.19.50.1295、输入正确的参数回车后，系统将显示以下类似信息：
   Save Boot Info (56 bytes) ... Done
Loading file "ns5xt.5.0.0r9.0"...
>
rtatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatat
atatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatat
atatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatat
atatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatat
6、当收到Loaded successfully信息后，系统会提示：
   Program to on-board flash?（y/[n]）
输入y回车。
7、当flash载入完成后，系统会提示：
Run downloaded program? （y/[n]）
输入y回车，系统开始载入ScreeOS启动。

Juniper ISG-1000产品关键特性介绍

Juniper ISG-1000整机前面板：

前面板中包括：
* LED指示灯
* 管理、console和modem接口
* 四个10/100/1000 Mbps接口（电口）
* 两个可拆除、可更换接口模块插槽
* 一个CF卡插槽
* 一个风扇挡板
其中两个可拆除/可更换接口模块插槽支持以下几种模块：
1.4端口/8端口 100 Mbps接口模块，如下图所示：

2. 2端口 10/100/1000 Mbps接口模块，如下图所示：

3. 2端口 Mini-GBIC接口连接模块，如下图所示：

几个关键特性：
1. Juniper ISG-1000满配最大可支持20个端口（16个10/100 Mbps+4个10/100/1000 Mbps）；
2. 在同一台Juniper ISG-1000只能使用一块10/100/1000 Mbps接口模块和一块Mini-GBIC接口连接模块；
3. Juniper ISG-1000没有固定的HA接口，每台设备可定义两个HA接口，需要注意的是：10/100/1000 Mbps接口和Mini-GBIC接口不能混合使用作为HA接口；
4. Juniper ISG-1000内置一个10/100 Mbps MGT接口，缺省配有一个管理IP：192.168.1.1/24。可供管理员通过CLI（telnet）或WebUI来配置管理Juniper ISG-1000，MGT接口不具有跟其它接口通讯能力；
5. Juniper ISG-1000接口序号尊从由下自上，从左到右的规则，如下图所示：

6. Juniper ISG-1000 所有接口模块均不支持热插拨，因此，在拆除/添加模块时切记先关闭电源。

Cisco 2610路由器enable密码恢复

因特权模式密码丢失，无法进入路由器配置。对路由器密码进行了恢复。路由器版本信息如下（这里主要是记下路由器当前的寄存器值：0x2102）：

关掉路由器电源后再打开，在60秒内按Ctrl+Break组合键，便会进入恢复模式：rommon>，在此模式下输入：confreg 0x2142和reset，如下图所示：
路由器重启后会提示是事进入初始化配置对话向导，选择：no，如下图所示：
最后路由器进入到用户模式：Router>，此时输入enable可直接进入特权模式，无须输入特权密码。进入到特权模式后可通过enable password password 修改密码，同时把路由器寄存器值修改为原先值：0x2102，最后输入reload重启路由器。如下图所示：
路由器重启后即可使用新密码进入特权配置模式。
注：若需保留路由器原有配置，在修改密码之前执行命令：copy startup-config running-config。

在F5 BIG-IP中添加静态路由

无法查看这则摘要。请点击此处查看博文。

linux/unix平台下sqlplus 按Backspace键删除时出现^H的处理方法

在linux/unix平台的sqplus中，输出字符后按Backspace键删除时，会出现^H，这对习惯了按Backspace键删除的用户来说，感觉非常别扭，虽然可以通过Ctrl+Backspace组合键实现删除功能。故障现象如下：

可通过stty命令修改终端配置来实现Backspace删除功能。如下：
[oracle@RHEL5 ~]$ id
uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),503(asadmin)
[oracle@RHEL5 ~]$ stty erase ^h
若要恢复Ctrl+Backspace组合键删除功能，可执行以下命令：
[oracle@RHEL5 ~]$ id
uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),503(asadmin)
[oracle@RHEL5 ~]$ stty erase ^?
同时可通过stty -a查看所有的终端设置：
[oracle@RHEL5 ~]$ id
uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),503(asadmin)
[oracle@RHEL5 ~]$ stty -aspeed 38400 baud; rows 42; columns 132; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

如何启用AIX IP转发功能

如何让一台AIX主机具有网关功能呢，可通过以下命令实现：
no -o ipforwarding=1
系统缺省是关闭的，如下：
AIX5.3:/#no -a | grep forwarding
ip6forwarding = 0
ipforwarding = 0
说明：ipforwarding=1只支持静路由，若需要支持动态路由（RIP/OSPF/BGP），可启用routed or gated，但性能不太好。

设置系统（Linux）对ping没有反应

操作系统平台：
[root@RHEL5 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5 (Tikanga)
设置之前测试：

通过以下命令设置系统对ping没有反应：
[root@RHEL5 ~]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
[root@RHEL5 ~]# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
设置后立即生效，不间断测试如下：

AIX系统/dev/null文件误删后的恢

    /dev/null是个特殊的字符型设备文件，它是个虚拟的设备，可以形象的理解为一个无底黑洞，吞噬万物的黑洞，且永远填不满。对系统非常重要，不需要保存的信息都可以丢到/dev/null。
AIX5.3:/#ls -l /dev/null
crw-rw-rw-   1 root     system        2, 2 Jul 31 11:49 /dev/null
由ls -l命令结果可知，/dev/null属于字符设备文件（c代表character），权限为666，属主为root，属system组，主设备/次设备（major/minor）号均为2。
惹/dev/null被误删后，可通过以下方式恢复：

1、创建/dev/null文件AIX5.3:/#rm /dev/null
AIX5.3:/#ls -l /dev/null
ls: 0653-341 The file /dev/null does not exist.
AIX5.3:/#mknod /dev/null c 2 2
AIX5.3:/#ls -l /dev/null
crw-r--r--   1 root     system        2, 2 Jul 31 14:08 /dev/null

2、设置/dev/null文件权限AIX5.3:/#chmod 666 /dev/nullAIX5.3:/#ls -l /dev/null
crw-rw-rw-   1 root     system        2, 2 Jul 31 14:08 /dev/null
此时/dev/null文件已成功恢复。

2010年11月10日星期三

RHEL Server 5 PV管理实践系列之三--pvmove（搬迁数据）

当发现系统中某块硬盘有问题后，需要及时把数据转移到新硬盘中。在转移数据时，不要求卸载文件系统，但建议在数据转移前进行备份，以防转移进程中意外导致数据丢失。
pvmove用来实现数据转移，根据数据量的多少，它可能要使用大量的时间，并可降低逻辑卷的性能，因此要在系统不太忙时操作。
备注：新硬盘容量一定在大于旧硬盘中的数据容量，并且新旧硬盘必须在同一个VG中，如下所示：

现在假定/dev/hdb2这块“盘”存在故障，需要将数据转移到新“盘”/dev/hdb1中。首先把/dev/hdb1加入到oldvg中，如下：

为了模拟需要，现在/dev/hdb2上创建了一个LV：/dev/oldvg/lvol0，并创建为ext3文件系统挂载到/tmp/dvd上，并在上面创建了一个测试文件：

利用pvmove命令转移数据（所需时间视数据量大小而定），如下：

把块“盘”/dev/hdb2从oldvg中剔出（剔出后可以把这块“坏”盘从主机中拨出），如下所示：

查验：

RHEL Server 5 VG管理实践系列之七--删除VG

前提：被删除的VG不能有LV。删除一个含有LV的VG会报以下错误：

可通过以下命令查看testvg中包含的那个LV：

利用lvremove把此LV从testvg中删除：

最后通过vgremove命令删除testvg：

验证testvg是否被成功删除：

如何限制或者修改/dev/shm大小

在红帽企业版Linux的应用程序如果遵循POSIX或者使用GLIBC（2.2和更高版本），通常使用/dev/shm作共享内存（shm_open，shm_unlink)。/dev/shm是一个临时文件系统（tmpfs），可以从/etc/fstab中mount。因此，支持标准的参数例如"size"，可以用来增加或者减少在/dev/shm上的tmpfs大小.（默认的，它的大小是系统RAM的一半）。
例如：为了将/dev/shm的大小增加到1GB，修改/etc/fstab的这行：默认的：