最小化权限的ssh账号-只能使用TCP转发

建立只能使用ssh“转发”功能的系统账户

为了满足“翻墙”的需要，在国外的Linux主机上（比如 DreamHost ）上建个可 ssh登录的用户，使用 ssh 的 Tunnel 来作代理是十分常见的方法。

但是主人往往又想最小化用户权限，以避免对系统造成影响。最简单的办法就是，禁止用户登录。

其实 ssh 可以连接到 sshd 但是不执行远程命令（默认是启动用户设定的 shell ），使用 -N 参数即可。

在服务器上建一个 username ：
添加用户：useradd -s /bin/false  username，将用户的shell设置成/bin/false。这样用户就无法与系统进行交互。
设置密码：passwd username

小技巧：
也可以使用 /usr/bin/passwd 作为用户的 shell ，这样用户就可以通过登录而来自主修改密码。需要注意的是，需要将 /usr/bin/passwd 这一行写进 /etc/shells文件。
sshd 认证通后之后，会检查设定的 shell 是否登记在 /etc/shells 文件中，若已经登记，则fork自己，然后fork出来的子进程再exec 设定的 shell 。而 ssh 的 -N 参数，则是告诉 sshd 不需要执行 shell。

建立Tunnel：

ssh -D 1080 -qfnN    username@hostname

输入密码即可使用（也可以用key认证）。

Windows的话，可以使用plink.exe或者MyEnTunnel（MyEnTunnel 本质上也是使用plink.exe来建立Tunnel）。

此时账号username 可以通过sshd的认证使用 TcpForwarding ，但是不能运行 shell，不能与系统交互。刚好可以用来为朋友提供国外的代理翻墙。

参数详解：
-D 1080 建立动态Tunnel，监听在本地1080端口。
-q  安静模式。
-f   ssh在后台运行，即认证之后，ssh退居后台。
-n  将 stdio 重定向到 /dev/null，与-f配合使用。
-N  不运行远程程序。即通知 sshd 不运行设定的 shell。

Linux系统上的Watchdog实现

为了满足“高可用性”的需求，人们设计了”watchdog”，俗称“看门狗”。

“Watchdog” 在实现上可以是硬件电路也可以是软件定时器，能够在系统出现故障时自动重新启动系统。

硬件
搜索 “watchdog card”和“看门狗卡”，可以找相关的信息，常见的是PCI接口和USB接口，体积很小。

软件
有很多相关的软件用来做“看门狗”。

Linux 自带了一个 watchdog 的实现，用于监视系统的运行，包括一个内核 watchdog module 和一个用户空间的 watchdog 程序。

内核 watchdog 模块通过 /dev/watchdog 这个字符设备与用户空间通信。用户空间程序一旦打开 /dev/watchdog 设备，就会导致在内核中启动一个 1分钟的定时器，此后，用户空间程序需要保证在 1分钟之内向这个设备写入数据，每次写操作会导致重新设定定时器。如果用户空间程序在 1分钟之内没有写操作，定时器到期会导致一次系统 reboot 操作。

用户空间程序可通过关闭 /dev/watchdog 来停止内核中的定时器。

用户空间的 watchdog 守护进程：
在用户空间，还有一个叫做 watchdog 的守护进程，它可以定期对系统进行检测，包括：

* Is the process table full?
* Is there enough free memory?
* Are some files accessible?
* Have some files changed within a given interval?
* Is the average work load too high?
* Has a file table overflow occurred?
* Is a process still running? The process is specified by a pid file.
* Do some IP addresses answer to ping?
* Do network interfaces receive traffic?
* Is the temperature too high? (Temperature data not always available.)
* Execute a user defined command to do arbitrary tests.

如果某项检测失败，则可能导致一次　soft reboot （模拟一次　shutdown　命令的执行），它还可以通过 /dev/watchdog 来触发内核 watchdog 的运行。

内核级”watchdog”与用户空间的”watchdog”的主要区别是，内核态的”watchdgo”抗干扰能力强，运行稳定。

参考：
http://baike.baidu.com/view/280158.htm
http://www.ibm.com/developerworks/cn/linux/l-cn-watchdog/index.html
http://www.oschina.net/p/watchdog
http://www.linuxidc.com/Linux/2008-05/12747.htm
http://blog.chinaunix.net/u1/40912/showart_354070.html

使用header标识服务器

当你在维护集群时，你会发现很难定位服务器。比如我们的 LVS 结构下的后端 RS 出现意外的问题的时候，怎么去定位它？

最终我们使用的方法是在 RS 上配置、增加一个额外的 header ( 我们的 RS 上运行的是 Web 服务 )，比如：

我在我的每台 web 上都做了如下配置
<IfModule mod_headers.c>
# Device ID, A(apache) N (Nginx) L(Lighttpd) S(Squid) V(Varnish), CPU x sum, RAM(G), DISK(G), bandwidth, CNC/TEL/EDU, City
Header Append Node “H01-A1-3.4Gx4-4G-100G-100M-CNC1-CQ1″
</IfModule>

这样，通过 Firebug ，我就可以很容易地定位服务器，从而快速的定位故障之所在。

大小写转换

将文件file.txt的小写字母转换成大写

1. 使用tr
cat file.txt | tr a-z A-Z
2. 使用sed
sed ‘y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/’  file.txt

sed的 y/source/dest/   Transliterate  the  characters  in  the  pattern space which appear in source to the corresponding character in dest.

使用RCS管理配置文件

时下是SVN和Git大行其道的时候，RCS出现的频率很小。

RCS，全称 Revision Control System ，一种版本控制系统，用于保存配置文件、Shell脚本和其他任何操作过的文本文件的多个修订版本。与SVN、Git、以及CVS不同的是，RCS不支持C/S结构，RCS的所有内容都保存在本地文件系统中。因此，RCS，不适合多人协作（于是出了SVN、Git这样的版本控制系统），相反的却非常适合管理员(甚至是多位管理员)来管理配置文件。假如你有很多机器要管理，那么另当别论！

RCS将所有修订版本都保存在文件当前目录下名为RCS/的目录中，假如该目录不存在，则保存在与文件相同的目录里。为了不使当前目录看上去很凌乱，建议使用RCS目录。

以Apache配置为例：

1. 创建仓库
mkdir /etc/httpd/conf/RCS
2. 将配置文件httpd.conf初始化到仓库中
ci -i /etc/httpd/conf/httpd.conf
/etc/httpd/conf/RCS/httpd.conf,v <– /etc/httpd/conf/httpd.conf
enter description, terminated with single ‘.’ or end of file:
NOTE: This is NOT the log message!
>> Apache Configuration Files
>> .
initial revision: 1.1
done
ci -i 进行“登入和初始化”，为RCS提供文件的第一份完好的副本。RCS提示输入初始化说明，然后从当前目录中删除该文件。
3. 登出文件
co /etc/httpd/conf/httpd.conf
/etc/httpd/conf/RCS/httpd.conf,v –> /etc/httpd/conf/httpd.conf
revision 1.1
done
在RCS初始化文件文件后，登出该文件。
4. 操作配置文件
锁定文件，以防操作时其他用户对访文件进行更新。实际上，RCS是使用文件权限来控制“锁”的，比如co httpd.conf的时候，httpd.conf的文件权限被设置成444，于是不能编辑，当co -l httpd.conf时，权限被设置成 644，于是可以编辑，当ci -u httpd.conf，文件权限又被设置成444。
co -l /etc/httpd/conf/httpd.conf
/etc/httpd/conf/RCS/httpd.conf,v –> /etc/httpd/conf/httpd.conf
revision 1.1 (locked)
done
现在可以随意修改了。
5. 提交文件
完成编辑工作后，重新登入并用ci -u 解锁
ci -u /etc/httpd/conf/httpd.conf
/etc/httpd/conf/RCS/httpd.conf,v <– /etc/httpd/conf/httpd.conf
new revision: 1.2; previous revision: 1.1
enter log message, terminated with single ‘.’ or end of file:
>> unload negotiation_module and negotiation_module
>> .
done
请务必使用有意义的日志！
6. 查看文件修改了哪些内容
比如我加载了mod_logio模块：
rcsdiff /etc/httpd/conf/httpd.conf
===================================================================
RCS file: RCS/httpd.conf,v
retrieving revision 1.2
diff -r1.2 httpd.conf
167c167
< #LoadModule logio_module modules/mod_logio.so
---
> LoadModule logio_module modules/mod_logio.so
也可以查看两个不同版本之间的差别
rcsdiff -r1.1 -r1.2 httpd.conf
7. 查看修订log
rlog /etc/httpd/conf/httpd.conf
8. 登出某个版本
co -l -r1.1 /etc/httpd/conf/httpd.conf
9. 常见问题( Troubleshooting)
常见的是在登入或者登出的时候出现问题，那可能是在某些节点忘记了 -l （在co中）或 -u（在ci中）选项。通常可以先制作备份，然后再次登出该文件并复回原来的位置：
cd /etc/httpd/conf
cp httpd.conf httpd.conf.bk
co -l httpd.conf
cp httpd.conf.bk httpd.conf
ci -u httpd.conf

6.参考：
《Linux Server Hacks》
http://www.juyimeng.com/httpd-conf-version-control.html

使用parted为超大磁盘建立GPT格式的分区表

安装CentOS 5.3 时，遇到的问题：
硬件环境：Dell R710，6块SATA 1T容量、7.2k转的磁盘，6i RAID卡。

问题：将前5块盘做的RAID5，共4T左右的存储容量。将第六块盘做的全局热备。

安装CentOS5.3时提示：

Your boot partition is on a disk using the GPT partitioning Scheme but this machines cannot boot using GPT.

解决方法：
1. 通过RAID卡为系统/boot分区建立单独的小容量设备sda，将/dev/sda使用MBR格式的分区表建立分区；将其他空间分配到设备sdb上，使用parted建立GPT格式分区（fdisk不支持GPT格式）。

2. 根据下表，对Linux系统启动过程的分析，判断应该是CentOS 5.3的grub版本过低，从而不支持从GPT分区引导系统，为grub打上 gpt patch 应该同样能解决问题。

MBR格式的分区表，有一定的局限性，比如：最大分区不超过2T,一个MBR只能记录四个主分区（扩展分区+逻辑分区，为扩展解决方案）。
当分区大于2T时，需要使用GPT格式的分区表。

使用parted:
1. 建立分区表
mklabel / mktable  LABEL-TYPE   create a new disklabel (partition table)
注意该操作会破坏分区表，谨慎操作！
LABEL-TYPE 支持以下几种类型(man parted)：
bsd”, “dvh”, “gpt”, “loop”, “mac”, “msdos”, “pc98″ or “sun”.
2. 建立分区
mkpart PART-TYPE [FS-TYPE] START END     make a partition
mkpartfs PART-TYPE FS-TYPE START END     make a partition with a file system
3. 建立文件系统
mkfs NUMBER FS-TYPE     make a FS-TYPE file system on partititon NUMBER
支持以下几种类型(man parted) fat16″, “fat32″, “ext2″, “linux-swap”  or  “reiserfs”。不支持的文件系统，可以在退出parted之后，使用mkfs来建立。
4. 命名分区
name NUMBER NAME         name partition NUMBER as NAME
例：name 1 /boot
5. 设置分区标志(比如Boot Flag)
toggle [NUMBER [FLAG]]    toggle the state of FLAG on partition NUMBER
toggle 1 boot
toggle 使用类似开关一样的方式设置FLAG，执行一次，修改一次状态。比如当前状态为空时，toggle 1 boot 是将第1个分区设置成boot，再执行一次toggle 1 boot时，boot FLAG被去掉。
也可以使用set 1 boot on/off 来设置。
6.其他命令
help 输出帮助信息
print 输出当前分区信息

参考：
http://baike.baidu.com/view/10817.html
http://www.ixdba.net/article/c0/1999.html
http://en.wikipedia.org/wiki/GUID_Partition_Table

parted的用法
http://oss.org.cn/ossdocs/gnu_linux/redhat/rhl-cg-zh_CN-9/ch-disk-storage.html

查找后门程序

每个进程都会有一个PID，而每一个PID都会在/proc目录下有一个相应的目录，这是Linux（当前内核2.6）系统的实现。

一般后门程序，在ps等进程查看工具里找不到，因为这些常用工具甚至系统库在系统被入侵之后基本上已经被动过手脚（网上流传着大量的rootkit。假如是内核级的木马，那么该方法就无效了）。

因为修改系统内核相对复杂（假如内核被修改过，或者是内核级的木马，就更难发现了），所以在/proc下，基本上还都可以找到木马的痕迹。

思路：
在/proc中存在的进程ID，在 ps 中查看不到（被隐藏），必有问题。

str_pids=`ps -A | awk ‘{print $1}’`
for i in /proc/[0-9]* ; do
        if  echo $str_pids | grep -q `basename $i` ; then
                :
            else
                echo “Rootkit’s PID: `basename $i`”
        fi
done
unset str_pids i

讨论：

检查系统(Linux)是不是被黑，其复杂程度主要取决于入侵者“扫尾工作”是否做得充足。对于一次做足功课的入侵来说，要想剔除干净，将是一件分精密、痛苦的事情，通常这种情况，需要用专业的第三方的工具（有开源的，比如tripwire，比如aide）来做这件事情。

而专业的工具，部署、使用相对比较麻烦，也并非所有的管理员都能熟练使用。

实际上Linux系统本身已经提供了一套“校验”机制，在检查系统上的程序没有被修改。比如rpm包管理系统提供的 -V 功能：

rpm -Va

即可校验系统上所有的包，输出与安装时被修改过的文件及相关信息。但是rpm系统也可能被破坏了，比如被修改过。

修改Apache的Max open files限制

相信绝大多数人，都是直接对 /etc/security/limits.conf  文件进行的修改，添加类似下面的两行：

*     soft         nofile           10240
*     hard       nofile           10240

这样也能达到效果。但是经验告诉我，能在局部修改，就不要动全局——因为我们不好评估全局会对哪些应用造成影响（就修改nofile参数一事来说，目前还没有发现修改全局对系统的明显影响，但是理论上可以肯定，将全局的限制放宽，意味着使系统容易受到“资源耗尽”类的攻击，然而在我的工作经历中，还没有遇到一例类似事故发生过），所以我建议将这些局部性的修改放到各自的启动脚本里。

在apachectl脚本里，有这样的语句：

#
# Set this variable to a command that increases the maximum
# number of file descriptors allowed per child process. This is
# critical for configurations that use many file descriptors,
# such as mass vhosting, or a multithreaded server.
ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`”
# ——————–                              ——————–
# ||||||||||||||||||||   END CONFIGURATION SECTION  ||||||||||||||||||||

# Set the maximum number of file descriptors allowed per child process.
if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
    $ULIMIT_MAX_FILES
fi

所以，我推荐直接修改apachectl，在ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`” 之前，设定nofile的“硬限制”，如下：

# number of file descriptors allowed per child process. This is
# critical for configurations that use many file descriptors,
# such as mass vhosting, or a multithreaded server.
ulimit -H -n 5000
ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`”
# ——————–                              ——————–
# ||||||||||||||||||||   END CONFIGURATION SECTION  ||||||||||||||||||||

# Set the maximum number of file descriptors allowed per child process.
if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
    $ULIMIT_MAX_FILES
fi

这样修改的好处在于，只有Apache的“nofile”受到影响，不影响其它。
原公司的所有应用的管理脚本中（apachectl、nginxctl），都进行了修改，并且使用”isystem”（自己写的一套脚本、小程序的集合）进行统一管理，以至于到后来，我几乎已经忘掉了这些事情，但是系统仍然运行良好，没有再出过 “too many open files” 的问题。

注意：修改过nofile的hard限制以后，需要先stop，再start，httpd进程的限制才能使用新改的参数。

查看当前运行中的进程的limit信息，可以利用/proc（当前Linux内存为2.6），比如apache的一个进程号是10232：

cat /proc/10232/limits

initrd的作用

initrd 的英文含义是 boot loader initialized RAM disk，就是由 boot loader 初始化的内存盘。在 linux内核启动前， boot loader 会将存储介质中的 initrd 文件加载到内存，内核启动时会在访问真正的根文件系统前先访问该内存中的 initrd 文件系统。在 boot loader 配置了 initrd 的情况下，内核启动被分成了两个阶段，第一阶段先执行 initrd 文件系统中的”某个文件”，完成加载驱动模块等任务，第二阶段才会执行真正的根文件系统中的 /sbin/init 进程。这里提到的”某个文件”，Linux2.6 内核会同以前版本内核的不同，所以这里暂时使用了”某个文件”这个称呼。对于2.4的内核，“某个文件”是指linuxrc；对于2.6的内核，“某个文件”是指init。第一阶段启动的目的是为第二阶段的启动扫清一切障爱，最主要的是加载根文件系统存储介质的驱动模块。我们知道根文件系统可以存储在包括IDE、SCSI、USB在内的多种介质上，如果将这些设备的驱动都编译进内核，可以想象内核会多么庞大、臃肿。

Initrd 的用途主要有以下四种：
1. linux 发行版的必备部件
linux 发行版必须适应各种不同的硬件架构，将所有的驱动编译进内核是不现实的，initrd 技术是解决该问题的关键技术。Linux 发行版在内核中只编译了基本的硬件驱动，在安装过程中通过检测系统硬件，生成包含安装系统硬件驱动的 initrd，无非是一种即可行又灵活的解决方案。
2. livecd 的必备部件
同 linux 发行版相比，livecd 可能会面对更加复杂的硬件环境，所以也必须使用 initrd。
3. 制作 Linux usb 启动盘必须使用 initrd
usb 设备是启动比较慢的设备，从驱动加载到设备真正可用大概需要几秒钟时间。如果将 usb 驱动编译进内核，内核通常不能成功访问 usb 设备中的文件系统。因为在内核访问 usb 设备时， usb 设备通常没有初始化完毕。所以常规的做法是，在 initrd 中加载 usb 驱动，然后休眠几秒中，等待 usb设备初始化完毕后再挂载 usb 设备中的文件系统。
4. 在 linuxrc 脚本中可以很方便地启用个性化 bootsplash。

2.6的内核使用gzip压缩的cpio格式的文件。
分析一下 initrd 的内容：
.
|– bin
| |– dmraid （discover, configure and activate software (ATA)RAID）
| |– insmod （simple program to insert a module into the Linux Kernel）
| |– kpartx  （Create device maps from partition tables）
| |– modprobe -> /sbin/nash
| `– nash      （script interpretor to interpret linuxrc images ）
|– dev
| |– console
| | ……
| `– zero
|– etc
|– init
|– lib
| |– ata_piix.ko
| |– dm-log.ko
| |– dm-mem-cache.ko
| |– dm-message.ko
| |– dm-mod.ko
| |– dm-raid45.ko
| |– dm-region_hash.ko
| |– ehci-hcd.ko
| |– ext3.ko
| |– firmware
| |– jbd.ko
| |– libata.ko
| |– megaraid_mbox.ko
| |– megaraid_mm.ko
| |– ohci-hcd.ko
| |– scsi_mod.ko
| |– sd_mod.ko
| |– shpchp.ko
| `– uhci-hcd.ko
|– proc
|– sbin -> bin
|– sys
`– sysroot

/init的内容：
#!/bin/nash
#以下指令多为nash的内置命令
#挂载/proc文件系统
mount -t proc /proc /proc
#setquiet，nash内置命令，作用是关闭输出
setquiet
echo Mounting proc filesystem
echo Mounting sysfs filesystem
#挂载/sys系统系统
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
#建立原始设备
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/urandom c 1 9
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/rtc c 10 135
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/ttyS3 c 4 67
echo Setting up hotplug.
hotplug
echo Creating block device nodes.
mkblkdevs
#加载USB相关模块，驱动键盘、鼠标等USB设备
echo “Loading ehci-hcd.ko module”
insmod /lib/ehci-hcd.ko
echo “Loading ohci-hcd.ko module”
insmod /lib/ohci-hcd.ko
echo “Loading uhci-hcd.ko module”
insmod /lib/uhci-hcd.ko
mount -t usbfs /proc/bus/usb /proc/bus/usb
#驱动磁盘设备、文件系统
echo “Loading jbd.ko module”
insmod /lib/jbd.ko
echo “Loading ext3.ko module”
insmod /lib/ext3.ko
echo “Loading megaraid_mm.ko module”
insmod /lib/megaraid_mm.ko
echo “Loading scsi_mod.ko module”
insmod /lib/scsi_mod.ko
echo “Loading sd_mod.ko module”
insmod /lib/sd_mod.ko
echo “Loading megaraid_mbox.ko module”
insmod /lib/megaraid_mbox.ko
echo “Loading shpchp.ko module”
insmod /lib/shpchp.ko
echo “Loading libata.ko module”
insmod /lib/libata.ko
echo “Loading ata_piix.ko module”
insmod /lib/ata_piix.ko
echo “Loading dm-mem-cache.ko module”
insmod /lib/dm-mem-cache.ko
echo “Loading dm-mod.ko module”
insmod /lib/dm-mod.ko
echo “Loading dm-log.ko module”
insmod /lib/dm-log.ko
echo “Loading dm-region_hash.ko module”
insmod /lib/dm-region_hash.ko
echo “Loading dm-message.ko module”
insmod /lib/dm-message.ko
echo “Loading dm-raid45.ko module”
insmod /lib/dm-raid45.ko
echo Waiting for driver initialization.
stabilized –hash –interval 1000 /proc/scsi/scsi
mkblkdevs
echo Scanning and configuring dmraid supported devices
resume LABEL=SWAP-sda5
echo Creating root device.
mkrootdev -t ext3 -o defaults,ro sda3
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.
setuproot
echo Switching to new root and running init.
#应该是根据启动时传递给内核的参数（bootparam）
switchroot

引用：
Linux2.6 内核的 Initrd 机制解析
http://www.ibm.com/developerworks/cn/linux/l-k26initrd/

ARM Linux启动过程

1. 引 言
Linux 最初是由瑞典赫尔辛基大学的学生 Linus Torvalds在1991 年开发出来的，之后在 GNU的支持下，Linux 获得了巨大的发展。虽然 Linux 在桌面 PC 机上的普及程度远不及微软的 Windows 操作系统，但它的发展速度之快、用户数量的日益增多，也是微软所不能轻视的。而近些年来 Linux 在嵌入式领域的迅猛发展，更是给 Linux 注入了新的活力。
一个嵌入式 Linux 系统从软件角度看可以分为四个部分：引导加载程序（bootloader）， Linux 内核，文件系统，应用程序。
其中 bootloader是系统启动或复位以后执行的第一段代码，它主要用来初始化处理器及外设，然后调用 Linux 内核。Linux 内核在完成系统的初始化之后需要挂载某个文件系统做为根文件系统（Root Filesystem）。根文件系统是 Linux 系统的核心组成部分，它可以做为Linux 系统中文件和数据的存储区域，通常它还包括系统配置文件和运行应用软件所需要的库。应用程序可以说是嵌入式系统的“灵魂”，它所实现的功能通常就是设计该嵌入式系统所要达到的目标。如果没有应用程序的支持，任何硬件上设计精良的嵌入式系统都没有实用意义。
从以上分析我们可以看出 bootloader 和 Linux 内核在嵌入式系统中的关系和作用。Bootloader在运行过程中虽然具有初始化系统和执行用户输入的命令等作用，但它最根本的功能就是为了启动 Linux 内核。在嵌入式系统开发的过程中，很大一部分精力都是花在bootloader 和 Linux 内核的开发或移植上。如果能清楚的了解 bootloader 执行流程和 Linux的启动过程，将有助于明确开发过程中所需的工作，从而加速嵌入式系统的开发过程。而这正是本文的所要研究的内容。
2. Bootloader
2.1 Bootloader的概念和作用Bootloader是嵌入式系统的引导加载程序，它是系统上电后运行的第一段程序，其作用类似于 PC 机上的 BIOS。在完成对系统的初始化任务之后，它会将非易失存储器（通常是 Flash或 DOC 等）中的Linux 内核拷贝到 RAM 中去，然后跳转到内核的第一条指令处继续执行，从而启动 Linux 内核。由此可见，bootloader 和 Linux 内核有着密不可分的联系，要想清楚的了解 Linux内核的启动过程，我们必须先得认识 bootloader的执行过程，这样才能对嵌入式系统的整个启过程有清晰的掌握。
2.2 Bootloader的执行过程不同的处理器上电或复位后执行的第一条指令地址并不相同，对于 ARM 处理器来说，该地址为 0×00000000。对于一般的嵌入式系统，通常把 Flash 等非易失存储器映射到这个地址处，而 bootloader就位于该存储器的最前端，所以系统上电或复位后执行的第一段程序便是 bootloader。而因为存储 bootloader的存储器不同，bootloader的执行过程也并不相同，下面将具体分析。
嵌入式系统中广泛采用的非易失存储器通常是 Flash，而 Flash 又分为 Nor Flash 和Nand Flash 两种。 它们之间的不同在于： Nor Flash 支持芯片内执行（XIP， eXecute In Place），这样代码可以在Flash上直接执行而不必拷贝到RAM中去执行。而Nand Flash并不支持XIP，所以要想执行 Nand Flash 上的代码，必须先将其拷贝到 RAM中去，然后跳到 RAM 中去执行。实际应用中的 bootloader根据所需功能的不同可以设计得很复杂，除完成基本的初始化系统和调用 Linux 内核等基本任务外，还可以执行很多用户输入的命令，比如设置 Linux 启动参数，给 Flash 分区等；也可以设计得很简单，只完成最基本的功能。但为了能达到启动Linux 内核的目的，所有的 bootloader都必须具备以下功能[2] ：

1) 初始化 RAM
因为 Linux 内核一般都会在 RAM 中运行，所以在调用 Linux 内核之前 bootloader 必须设置和初始化 RAM，为调用 Linux内核做好准备。初始化 RAM 的任务包括设置 CPU 的控制寄存器参数，以便能正常使用 RAM 以及检测RAM 大小等。
2) 初始化串口串口在 Linux 的启动过程中有着非常重要的作用，它是 Linux内核和用户交互的方式之一。Linux 在启动过程中可以将信息通过串口输出，这样便可清楚的了解 Linux 的启动过程。虽然它并不是 bootloader 必须要完成的工作，但是通过串口输出信息是调试 bootloader 和Linux 内核的强有力的工具，所以一般的 bootloader 都会在执行过程中初始化一个串口做为调试端口。
3) 检测处理器类型
Bootloader在调用 Linux内核前必须检测系统的处理器类型，并将其保存到某个常量中提供给 Linux 内核。Linux 内核在启动过程中会根据该处理器类型调用相应的初始化程序。
4) 设置 Linux启动参数
Bootloader在执行过程中必须设置和初始化 Linux 的内核启动参数。目前传递启动参数主要采用两种方式：即通过 struct param_struct 和struct tag（标记列表，tagged list）两种结构传递。struct param_struct 是一种比较老的参数传递方式，在 2.4 版本以前的内核中使用较多。从 2.4 版本以后 Linux 内核基本上采用标记列表的方式。但为了保持和以前版本的兼容，它仍支持 struct param_struct 参数传递方式，只不过在内核启动过程中它将被转换成标记列表方式。
标记列表方式是种比较新的参数传递方式，它必须以 ATAG_CORE 开始，并以ATAG_NONE 结尾。中间可以根据需要加入其他列表。Linux内核在启动过程中会根据该启动参数进行相应的初始化工作。

5) 调用 Linux内核映像
Bootloader完成的最后一项工作便是调用 Linux内核。如果 Linux 内核存放在 Flash 中，并且可直接在上面运行（这里的 Flash 指 Nor Flash），那么可直接跳转到内核中去执行。但由于在 Flash 中执行代码会有种种限制，而且速度也远不及 RAM 快，所以一般的嵌入式系统都是将 Linux内核拷贝到 RAM 中，然后跳转到 RAM 中去执行。不论哪种情况，在跳到 Linux 内核执行之前 CUP的寄存器必须满足以下条件：r0＝0，r1＝处理器类型，r2＝标记列表在 RAM中的地址。

3. Linux内核的启动过程
在 bootloader将 Linux 内核映像拷贝到 RAM 以后，可以通过下例代码启动 Linux 内核：call_linux(0, machine_type, kernel_params_base)。
其中，machine_tpye 是 bootloader检测出来的处理器类型， kernel_params_base 是启动参数在 RAM 的地址。通过这种方式将 Linux 启动需要的参数从 bootloader传递到内核。Linux 内核有两种映像：一种是非压缩内核，叫 Image，另一种是它的压缩版本，叫zImage。根据内核映像的不同，Linux 内核的启动在开始阶段也有所不同。zImage 是 Image经过压缩形成的，所以它的大小比 Image 小。但为了能使用 zImage，必须在它的开头加上解压缩的代码，将 zImage 解压缩之后才能执行，因此它的执行速度比 Image 要慢。但考虑到嵌入式系统的存储空容量一般比较小，采用 zImage 可以占用较少的存储空间，因此牺牲一点能上的代价也是值得的。所以一般的嵌入式系统均采用压缩内核的方式。
对于 ARM 系列处理器来说，zImage 的入口程序即为 arch/arm/boot/compressed/head.S。它依次完成以下工作：开启 MMU 和 Cache，调用 decompress_kernel()解压内核，最后通过调用 call_kernel()进入非压缩内核 Image 的启动。下面将具体分析在此之后 Linux 内核的启动过程。
3.1 Linux内核入口
Linux 非压缩内核的入口位于文件/arch/arm/kernel/head-armv.S 中的 stext 段。该段的基地址就是压缩内核解压后的跳转地址。如果系统中加载的内核是非压缩的 Image，那么bootloader将内核从 Flash中拷贝到 RAM 后将直接跳到该地址处，从而启动 Linux 内核。不同体系结构的 Linux 系统的入口文件是不同的，而且因为该文件与具体体系结构有关，所以一般均用汇编语言编写[3]。对基于 ARM 处理的 Linux 系统来说，该文件就是head-armv.S。该程序通过查找处理器内核类型和处理器类型调用相应的初始化函数，再建立页表，最后跳转到 start_kernel()函数开始内核的初始化工作。
检测处理器内核类型是在汇编子函数__lookup_processor_type中完成的。通过以下代码可实现对它的调用：bl __lookup_processor_type。__lookup_processor_type调用结束返回原程序时，会将返回结果保存到寄存器中。其中r8 保存了页表的标志位，r9 保存了处理器的 ID 号，r10 保存了与处理器相关的 struproc_info_list 结构地址。
检测处理器类型是在汇编子函数 __lookup_architecture_type 中完成的。与__lookup_processor_type类似，它通过代码：“bl __lookup_processor_type”来实现对它的调用。该函数返回时，会将返回结构保存在 r5、r6 和 r7 三个寄存器中。其中 r5 保存了 RAM 的起始基地址，r6 保存了 I/O基地址，r7 保存了 I/O的页表偏移地址。当检测处理器内核和处理器类型结束后，将调用__create_page_tables 子函数来建立页表，它所要做的工作就是将 RAM 基地址开始的 4M 空间的物理地址映射到 0xC0000000 开始的虚拟地址处。对笔者的 S3C2410 开发板而言，RAM 连接到物理地址 0×30000000 处，当调用 __create_page_tables 结束后 0×30000000 ～ 0×30400000 物理地址将映射到0xC0000000～0xC0400000 虚拟地址处。
当所有的初始化结束之后，使用如下代码来跳到 C 程序的入口函数 start_kernel()处，开始之后的内核初始化工作：
b SYMBOL_NAME(start_kernel)
3.2 start_kernel函数
start_kernel是所有 Linux 平台进入系统内核初始化后的入口函数，它主要完成剩余的与硬件平台相关的初始化工作，在进行一系列与内核相关的初始化后，调用第一个用户进程－init 进程并等待用户进程的执行，这样整个 Linux 内核便启动完毕。该函数所做的具体工作有[4][5] ：
1) 调用 setup_arch()函数进行与体系结构相关的第一个初始化工作；
对不同的体系结构来说该函数有不同的定义。对于 ARM 平台而言，该函数定义在arch/arm/kernel/Setup.c。它首先通过检测出来的处理器类型进行处理器内核的初始化，然后通过 bootmem_init()函数根据系统定义的 meminfo 结构进行内存结构的初始化，最后调用paging_init()开启 MMU，创建内核页表，映射所有的物理内存和 IO空间。
2) 创建异常向量表和初始化中断处理函数；
3) 初始化系统核心进程调度器和时钟中断处理机制；
4) 初始化串口控制台（serial-console）；
ARM-Linux 在初始化过程中一般都会初始化一个串口做为内核的控制台，这样内核在启动过程中就可以通过串口输出信息以便开发者或用户了解系统的启动进程。
5) 创建和初始化系统 cache，为各种内存调用机制提供缓存，包括;动态内存分配，虚拟文件系统（VirtualFile System）及页缓存。
6) 初始化内存管理，检测内存大小及被内核占用的内存情况；
7) 初始化系统的进程间通信机制（IPC）；
当以上所有的初始化工作结束后，start_kernel()函数会调用 rest_init()函数来进行最后的初始化，包括创建系统的第一个进程－init 进程来结束内核的启动。Init 进程首先进行一系列的硬件初始化，然后通过命令行传递过来的参数挂载根文件系统。最后 init 进程会执行用 户传递过来的“init＝”启动参数执行用户指定的命令，或者执行以下几个进程之一：
execve(“/sbin/init”,argv_init,envp_init);
execve(“/etc/init”,argv_init,envp_init);
execve(“/bin/init”,argv_init,envp_init);
execve(“/bin/sh”,argv_init,envp_init)。
当所有的初始化工作结束后，cpu_idle()函数会被调用来使系统处于闲置（idle）状态并等待用户程序的执行。至此，整个 Linux 内核启动完毕。
4. 结论
Linux 内核是一个非常庞大的工程，经过十多年的发展，它已从从最初的几百 KB 大小发展到现在的几百兆。清晰的了解它执行的每一个过程是件非常困难的事。但是在嵌入式开发过程中，我们并不需要十分清楚 linux 的内部工作机制，只要适当修改 linux 内核中那些与硬件相关的部分，就可以将 linux 移植到其它目标平台上。通过对 linux 的启动过程的分 析，我们可以看出哪些是和硬件相关的，哪些是 linux 内核内部已实现的功能，这样在移植linux 的过程中便有所针对。而 linux内核的分层设计将使 linux 的移植变得更加容易。

Linux的启动过程

整个开机流程是

(1)载入BIOS的硬件信息，并取得第一个开机装置的代号
(2)读取第一个开机装置的MBR的boot Loader (grub)的开机信息
(3)载入OS Kernel信息，解压Kernel，尝试驱动硬件
(4)Kernel执行init程序并获得run-lebel信息(如3或5)
(5)init执行/etc/rc.d/rc.sysinit
(6)启动内核外挂模块(/etc/modprobe.conf)
(7)init执行run-level的各种Scripts，启动服务
(8)init执行/etc/rc.d/rc.local
(9)执行/bin/login，等待用户Login
(10)Login后进入Shell

Linux启动过程综述
http://www.ibm.com/developerworks/cn/linux/kernel/startup/
剖析Linux系统启动过程
http://www.5dmail.net/html/2004-11-29/20041129102711.htm
Linux 初始 RAM 磁盘（initrd）概述
http://www.ibm.com/developerworks/cn/linux/l-initrd.html
Linux2.6 内核的 Initrd 机制解析
http://www.ibm.com/developerworks/cn/linux/l-k26initrd/
Linux启动过程详解
http://roclinux.cn/?p=1301
深入理解linux启动过程
http://opens.itpub.net/post/21577/191312

权限引起的crond不装载配置

/etc/cron.d下的配置文件不被装载故障处理心得：

vixie-cron-4.1-76（crond）在 启动时 和 运行的过程中，会在整分钟（0秒的时刻）检查/etc/cron.d目录下的文件，假如权限、格式正确，则装载，并安排相应的任务。

假如某配置文件权限不对，那么则会跳过对该文件的检查，就是说即使将权限设置成正确的644，那么也不会被加载，需要手动reload配置：/etc/init.d/crond reload（或者再将文件改名——相当于加载新的权限正确的配置文件）。

而格式错误引起的配置无效，修改正确之后则不需要重新装载！

为最小化安装的Debian系统安装编译环境

Debian的最小化安装非常节省空间，Debian的哲学是用到什么再安装，不像RedHat，把你可能用到的都给你装上。

最小化安装的Debain不能用来编译安装软件，因为它不包含编译代码所需的工具。
一般安装上下面的组件之后，即可：

apt-get install build-essential

重置软件包的权限

系统环境：CentOS Linux 5.3

有时候误操作，会使文件系统的权限混乱，这是系统所不允许的。

那么，误操作之后怎么恢复到原来的状况呢（指文件权限相关的）？

重新安装软件包（yum reinstall xxxx ）不失为一种方法，但是不够聪明。其实官方提供的有现成的解决方法：使用 RPM 包管理器。

1. 查找到需要恢复的文件
#rpm -Va | grep “M”

2. 确定哪些包需要重设权限
# rpm -Va | grep “M” | awk ‘{print $2}’ | xargs rpm -qf | sort -u

3. 重置这些包的权限
# rpm -Va | grep “M” | awk ‘{print $2}’ | xargs rpm -qf | sort -u | xargs rpm –setperms

重点儿是 rpm 的 –setperms 开关，其中还有四个可选选项：
-a 表示所有已安装软件包
-f 后跟文件，表示包含此文件的已安装的软件包
-p 后跟包文件，重置用这个包安装的文件的权限。
-g 后跟组名，按组重置权限。
直接跟包的名字，重置包的权限。

RPM校验软件包时发现的一个问题：
rpm -Va 时有时（reinstall了软件包或者重置的软件包的权限）会出现类似下面这样的提示信息：
prelink: /usr/lib/libnl.so.1.0-pre5: at least one of file’s dependencies has changed since prelinking

这便引出了另一个问题，prelink。
解决的办法是：prelink /usr/lib/libnl.so.1.0-pre5

在 /etc/cron.daily/下，有一个关于prelink的脚本prelink，每天会执行一次。

修改Linux系统时区

1. 查看当前时区
cat /etc/sysconfig/clock

2. 修改设置时区
tzselect

3. 复制相应的时区文件，替换系统默认时区
#cp /usr/share/zoneinfo/$主时区/$次时区 /etc/localtime
对于中国服务器：
#cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

Linux实现双线双IP的方法

实现双线（接口）双IP，一般基于两种需求：

1. 允分利用多接口，提高服务器的网络吞吐能力。在两个网卡上分别接上网络，分别配置一个IP地址，想像着可以突破服务器本身网卡速度的限制。比如下载服务器，接两根网线，配置两个IP，于是便有了两个网卡上的带宽可以使用。

2. 经典的双线双IP，借助于“智能DNS系统”，解决网通、电信网络之间访问的网络瓶颈。

想象很美好，但是实际上，并不是那么容易实现的。

一般情况下，一台主机的网络参数里有一个“默认网关”。所谓默认网关的意义就是：凡是路由表中没有明确指明应该发往哪里（接口）的数据包，通通发往“默认网关”（接口）。

那么，当有两个接口（需要分别配置一个IP）的时候，该怎么配置“默认网关”呢？姑且先不管能不能配上两个“默认网关”，对于系统来说，系统是不是会犯迷糊？“两个默认网关，我到底将包发往哪儿？”

所以，并不是想当然的，给系统的两个接口上配置两个IP，然后就可以想当然的实现“双IP了”。

在Windows 2003上，是不允许配两个不在同一网络（IP不在同一子网——可以简单的认为不在同一网段）的两个默认网关的。并且Windows 2003的双接口双默认网关配置是用来提供网络链路冗余的。

实现双线双IP的最常用的方式，是配一个默认网关，另一个接口不配置默认网关，使用添加静态路由的方式使用第二个接口。其实整个网络上的数据包转发都是由“路由表”决定的。正确的理解路由表，就不会想当然的认为可以随意的配置多接口了。

使用静态路由的方式，显然不够方便。假如是电信、网通的双线，那么将会要维护大量的路由表信息，几乎是不可维护的。

Linux提供了一个“Advanced IP routing and network device configuration tools”，iproute，系统自带，网方网址：http://linux-net.osdl.org/index.php/Iproute2。

使用iproute解决问题的思路是：从哪个接口进，就从哪个接口出。

举例说明：

系统环境：CentOS Linux

网络环境： 两个IP地址，192.168.2.10和192.168.3.10，掩码是255.255.255.0，这两个子网的网关地址分别是192.168.2.1和192.168.3.1。

1. 为网卡eth0配置ip地址192.168.2.10，为网卡eth1配置ip地址为192.168.3.10

配置文件为：
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth1

2. 配置默认网关为任意一个，比如192.168.2.1。这个默认网关，决定了系统主动去使用网络时，使用的接口。

配置文件：/etc/sysconfig/network

3. 编辑路由表

修改/etc/iproute2/rt_tables，添加内容：

252   net2
251  net3

#添加原路返回路由
ip route flush table net2
ip route add default via 192.168.2.1 dev eth0 src 192.168.2.10 table net2
ip rule add from 192.168.2.10 table net2

ip route flush table net3
ip route add default via 192.168.3.1 dev eth1 src 192.168.3.10 table net3
ip rule add from 192.168.3.10 table net3

4. 第3步中的设置路由的命令需要系统启动后自动运行，需要写进/etc/rc.local中。

挂载Windows共享到Linux系统

首先，需要samba的客户端软件包：samba-client。

比如将 \\192.168.0.61\editors 挂载到 /mnt/editors

mount.cifs //192.168.0.61/editors /mnt/editors -o user=editors,pass=xxxxxx

自动挂载NFS、CIFS

系统重启后常常出现nfs没有被挂载，不管是配置在/etc/fstab里，还是将挂载命令写在/etc/rc.local里。

总是有原因的，可是我不能反复的重启系统试验，于是不得不绕过这个问题，于是想到了autofs。

参考：http://doc.chinahtml.com/Manual/rhl-cg-zh_CN-9/s1-nfs-mount.html

比如我有两个目录需要挂载远程的nfs：

/srv/data1

/srv/data2

对应的远程的nfs:

192.168.1.200:/srv/data1

192.168.1.201:/srv/data2

那么，我需要在 /etc/auto.master里添加这么一行：

/srv                /etc/auto.nfs.srv

然后建立 /etc/auto.nfs.srv，写入如下两行：

data1    -rw,nolock,noatime      192.168.1.200:/srv/data1
data2    -rw,nolock,noatime      192.168.1.201:/srv/data2

但是需要说明的是：

1. 我的系统是CentOS 5.3

2. 需要将autofs设置成开机自动启动：chkconfig autofs on,并启动autofs服务：/etc/init.d/autofs start

3. 使用autofs时，本地的/srv目录下面应该是空的，就是说data1目录和data2目录也不存在。当系统试图访问/srv/data1这个目录时autod daemon会自挂载nfs到/srv/data1目录，那时/srv下原来的存在的所有目录、文件将不能被访问。

那么也捎带着自动挂载一下windows的共享吧：

在/etc/auto.master里加入下面一行：

/mnt/smb                        /etc/auto.smb.mnt

在/etc/auto.smb.mnt时加入下面一行：

editors  -fstype=cifs,username=editors,password=xxxxxx  ://192.168.0.61/editors

需要说明的是，这里的//192.168.0.61前面的冒号，是不能省的。

CentOS自动升级问题

CentOS的yum-updatesd服务是可以自动更新系统的，只用稍微调整一个配置文件/etc/yum/yum-updatesd.conf：
[main]
# how often to check for new updates (in seconds)
run_interval = 3600# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
#emit_via = dbus
emit_via = email
email_from = yum-updatesd@MO01H36
email_to = caoyuwei@xxxx.com

# should we listen via dbus to give out update information/check for
# new updates
dbus_listener = yes

# automatically install updates
do_update = yes

# automatically download updates
do_download = yes

# automatically download deps of updates
do_download_deps = yes

最终解决方法是：yum clean all
然后便可以 yum update了，yum-updated也会自动更新系统。

感慨一下团队的力量。这个解决办法是神仙发现的，哈，我们总是能遇到这样的惊喜！

nginx的http session管理

http session，基本上可以认为就是我们平常所理解的完成GET或者POST请求的HTTP应用的TCP Session。

从自已的使用经验、以及归纳、总结网上各类关于Nginx的文章，个人觉得Nginx最擅长的是对静态内容提供HTTP服务，以及Session管理（HTTP任务管理）。Nginx使用了epoll的模式来管理TCP session，所以，性能高，系统资源消耗低。

实事上，Nginx提供动态内容需要通过FastCGI方式（也支持内置的对perl的支持），当觉得Nginx慢时，实际上是FastCGI慢（而FastCGI慢，大多数时候，又是因为数据库读写慢—-高并发的请求导致的阻塞属于不常见的原因之一，比如在遭遇DDos攻击的时候）。

大量的并发FastCGI请求，会使FastCGI管理器应接不暇（暂不去管后台数据库的因素，我们要解决的是FastCGI任务调度慢的情况），从而引起阻塞，引发系统上的“撞车效应”。所以瓶颈在FastCGI处理。

不少关于使用Nginx做负载均衡的例子，实际上就是利用Nginx的 session 管理能力。将处理较慢、花时间较多的FastCGI处理任务分发到多台系统上，这样可以提高系统的负载能力，提高系统发生阻塞的阈值。

Nginx的upstream模块，对“负载均衡”提供了良好的支持，详见：

http://wiki.nginx.org/NginxHttpUpstreamModule

例：
upstream app_group1 {
server 192.168.1.111:9000 weight=5 ;
server 192.168.1.112:9000 weight=5 ;
server 192.168.1.113:9000 weight=3 ;
server 192.168.1.114:9000 weight=5 ;
}

…………

location ~ \.php$ {
fastcgi_pass   app_group_01;
fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME  $fastcgi_script_name;
include        extra/fastcgi_params.conf;
}

之前，是将Nginx分别放在四台FastCGI服务器上，然后使用LVS来作负载调度，运行良好。为了给系统构架分层，使架构清晰，更易于管理和扩展，降低维护难度，试着使用Nginx来调度负载。

一个较明显的效果是四个FastCGI的系统负载下降（原来有Nginx运行在同一系统上）。

Nginx系统的负载很低，活动连接1.7k左右，负载系统不超过1，用掉不到50M的物理内存。相对于LVS复杂的实施以及背后的管理成本，Nginx在低于100M流量的应用中相当有优势。