现在，只要在.bashrc里面加上这么一行：

export HISTTIMEFORMAT=”%F %T “

那么你的所有执行过的历史命令都会记录该命令被执行的时间：

dhh@T400:~$ tail .bash_history
#1322122049
ssh he
#1322122087
ssh pms
#1322123436
ssh op
#1322123716
ssh pms
#1322127848
history
dhh@T400:~$

现在让我们来看看效果：

dhh@T400:~$ history | head
14 2011-11-18 11:34:59 ls -lh
15 2011-11-18 11:35:01 clear
16 2011-11-18 11:35:03 ls -lh
17 2011-11-18 11:41:21 cd work/
18 2011-11-18 11:41:21 ls
19 2011-11-18 11:41:24 cd svn
20 2011-11-18 11:41:24 ls
21 2011-11-18 11:41:26 cd dev
22 2011-11-18 11:41:26 ls
23 2011-11-18 11:41:29 cd build_util/
dhh@T400:~$

是不是很酷？更可贵的是，它很有用。

label hd
menu label ^h) Boot to Local Hard Disk
localboot 0×80

改成：

label hd
menu label ^h) Boot to Local Hard Disk
kernel chain.c32
append hd0 0

chain.c32在syslinux里面有。

最终网络安装的效果图如下：

admin@storage-01:/# sg_inq /dev/rdsk/c1t5000C50025E2DB7Fd0 | grep serial
Unit serial number: 9WM31YEM0000C0000JMK
admin@storage-01:/#

由于这个命令是用scsi协议直接和硬盘打交道，所以只要服务器可以直接访问到硬盘，就可以查询到硬盘的序列号。譬如某生产线上用DataON DNS1400的JBOD，你无法通过cfgadm，iostat -En，也无法通过format的inquery来查询到序列号，这种情况下可以通过sg3utils里面的sg_inq来查询到硬盘的序列号。

Note: 我看到的其中一个小问题是：RAID5中一个写操作需要后台2次读2次写这个说法只是其中一种可能。严格意义上来说，RAID5会根据现有的数据和需要写入的数据大小来确定如何写入数据，譬如full strip write就不需要这种2次读2次写的操作。摘录wikipedia的原话：“RAID 5 implementations suffer from poor performance when faced with a workload which includes many writes which are smaller than the capacity of a single stripe.” 注意，这里有限定语句：which are smaller than the capacity of a single stripe.

参考文献：
[1] http://www.symantec.com/connect/articles/getting-hang-iops
[2] http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5_performance
[3] http://blogs.oracle.com/bonwick/entry/raid_z

cfengine失败的原因，是由于域名反向解析出错。

从跟踪结果来看，我们的bind转发到网通的DNS 218.108.248.228， 而网通的域名服务器其对下列IP地址的反向解析有奇怪的结果[1]，正常的结果应 该如[2]所示。 因此，对于网通这样诡异的运营商，自己的域名服务器还是必要的。

hz-307:/etc/bind# host -l wasu.vobile | grep 192.168 | awk '{print $4}' | while read k; do host $k; done | grep FAIL | sed 's/Host \(.*\).in-addr.*/\1/g' | awk -F. '{print $4,$3,$2,$1}' | sed 's/ /./g' | sort | uniq -c
      3 192.168.x.106
      2 192.168.x.113
      1 192.168.x.115
      1 192.168.x.116
      1 192.168.x.50
      2 192.168.x.71
hz-307:/etc/bind#

附：

故障现象：

hz-050:~# cfagent -q
cfengine:hz-050: Couldn't look up address v6 for : Temporary failure in name resolution
cfengine:hz-050: Id-authentication for hz-050.vobileinc.com failed
cfengine:hz-050:/var/lib/cfengine2/inputs/update.conf:42: Warning: actionsequence is empty
cfengine:hz-050:/var/lib/cfengine2/inputs/update.conf:42: Warning: perhaps cfagent.conf/update.conf have not yet been set up?
hz-050:~#

故障相关代码：

proto.c
   if ((err=getnameinfo((struct sockaddr *)&myaddr,len,dnsname,CF_MAXVARSIZE,NULL,0,0)) != 0)
      {
      snprintf(OUTPUT,CF_BUFSIZE,"Couldn't look up address v6 for %s: %s\n",dnsname,gai_strerror(err));
      CfLog(cferror,OUTPUT,"");
      return false;
      }

ltrace相关信息，可以看到返回值是-3：

getnameinfo(0xbfaae4a8, 16, "", 1024, NULL, 0, 0) = -3
gai_strerror(-3)                                 = "Temporary failure in name resolu"...
snprintf("Couldn't look up address v6 for "..., 4096, "Couldn't look up address v6 for "...) = 71

头文件相关信息，对应到可读的错误信息：

/usr/include/netdb.h
# define EAI_AGAIN        -3    /* Temporary failure in name resolution.  */

[1]

hz-307:/etc/bind# dig -x 192.168.x.116 @218.108.248.228
;; Got bad packet: bad label type
120 bytes
8e 62 81 83 00 01 00 00 00 01 00 00 03 31 31 36
02 31 36 03 31 36 38 03 31 39 32 07 69 6e 2d 61
64 64 72 04 61 72 70 61 00 00 0c 00 01 c0 14 00
06 00 01 00 00 03 f3 00 3f 0d 68 69 64 64 65 6e
2d 6d 61 73 74 65 72 05 68 7a 6d 61 6e 03 6e 65
74 00 03 64 6e 73 08 63 68 69 6e 61 68 63 6e 03
63 6f 6d 00 77 ce 51 a7 00 00 0e 10 00 00 07 08
00 09 3a 80 00 00 0e 10

[2]

hz-307:/etc/bind# dig -x 192.168.x.11 @218.108.248.228

; <<>> DiG 9.6-ESV-R3 <<>> -x 192.168.x.11 @218.108.248.228
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18589
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;11.x.168.192.in-addr.arpa.    IN    PTR

;; AUTHORITY SECTION:
168.192.in-addr.arpa.    8746    IN    SOA    prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800

;; Query time: 24 msec
;; SERVER: 218.108.248.228#53(218.108.248.228)
;; WHEN: Mon Jul 11 19:58:22 2011
;; MSG SIZE  rcvd: 121

hz-307:/etc/bind#

因素1：光盘的物理结构

光盘光滑的一面是光驱去读取的那一面，一般有比较厚的基底，另外一面，由外到内是：印刷层（有图案），保护层，反射层，对CD而言，印刷层和保护层比较薄。

因素2：光盘的特性

光盘染料记忆层怕见光

那么，如果光滑的那一面向下，只要不是刮的太深，可能会影响读取速度，或者需要加强激光强度来读取，同时，对光盘染料记忆层有保护

如果印刷层向下，那么如果刮伤了反射层，数据就彻底完了。这个对CD特别严重。

综上所述，光盘应该是光面朝下放置。

Raid类型以及资源

Dell中的Raid卡都是基于lsi的芯片，详细的可以通过lspci -v[1]来识别。

对于lsi的Raid卡，可以通过网上资料找到详细的分类和说明[2]。 在开工之前，务必详细阅读该文档，弄清楚Raid卡的类型。

lsi厂商工具

对基于lsi的Raid卡，可以通过mpt-stat(开源)，lsiutil，megacli来监控，也可以通过Dell官方提供的管理工具来管理。

对Debian，有现成的Debian源可以安装上面的几个工具[3]。

对solaris，也可以下载到相应的软件[4][5]，mpt-stat可能没有。

如果只是要检查和操作Raid卡，lsiutil和megacli就已经是足够了。

Dell的Raid管理工具

Dell 官方提供了一套完整的管理工具[6]，但是对于Debian，并没有官方支持。Debian爱好者这套管理工具进行了重新打包， 这里有一个比较详尽的安装文档[7]，对于该管理工具，有比较详尽的文档可以参考[8].

硬盘状态监控

光光有工具还是不够的，我们需要把这些集成到监控里面，已经有人专门为此进行了开发，并且撰写了详细的文档[9]，通过这些方法，我们可以通过snmp或者nagios nrpe来监控系统的健康状态。建议通过nrpe来完成监控。

具体效果如下:

srv:~# /usr/lib/nagios/plugins/check_nrpe -H srv01 -c check_openmanage
OK – System: ‘PowerEdge R710′, SN: ‘XXXXX’, 8 GB ram (4 dimms), 1 logical drives, 6 physical drives
srv:~#

如果有DRAC卡，还可以通过DRAC的报警功能来对系统状态进行及时报警，这个是最简单的。

[1] http://www.google.com/search?q=pciutils , Debian package pciutils

[2] http://hwraid.le-vert.net/wiki/LSI

[3] http://hwraid.le-vert.net/wiki/DebianPackages

[4] http://www.lsi.com/DistributionSystem/User/AssetMgr.aspx?asset=51101

[5] http://tinyurl.com/megacli-solaris

[6] http://linux.dell.com/repo/hardware/

[7] http://john.parnefjord.se/node/39

[8] http://support.dell.com/support/edocs/software/svradmin/

[9] http://folk.uio.no/trondham/software/check_openmanage.html

sudo apt-get install libdvdread4

sudo /usr/share/doc/libdvdread4/install-css.sh

打开文件管理器，进入/media，右击目录，选择Copy Disk，选择保存为image。然后就等拷贝完成啦。

可以用vlc打开拷贝出来的iso文件。