解决mv命令导致的cman启动失败问题

  参考资料：https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=667703

                    http://www.qingsword.com/qing/1086.html

  今天使用cman来管理集群，在启动时报错，错误信息如下：

[root@CentOS____102 ~]# service cman start
Starting cluster: 
   Checking if cluster has been disabled at boot...        [  OK  ]
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman... I/O warning : failed to load external entity "/etc/cluster/cluster.conf"

Unable to get the configuration
I/O warning : failed to load external entity "/etc/cluster/cluster.conf"
corosync [MAIN  ] Corosync Cluster Engine ('1.4.1'): started and ready to provide service.
corosync [MAIN  ] Corosync built-in features: nss dbus rdma snmp
corosync [MAIN  ] Unable to read config from /etc/cluster/cluster.conf
corosync [MAIN  ] Corosync Cluster Engine exiting with status 8 at main.c:1695.
corosync died: Could not read cluster configuration Check cluster logs for details
                                                           [FAILED]
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
[root@CentOS____102 ~]#

  产生问题的原因是corosync无法读取配置文件/etc/cluster/cluster.conf，文件属性如下所示：

[root@CentOS____102 ~]# ls -l /etc/cluster/cluster.conf 
-rw-r--r--. 1 root root 995 Oct 30 16:30 /etc/cluster/cluster.conf

  这个文件权限在机器A（192.168.56.101）是没有问题的，出问题的是机器B（192.168.56.102）。

  机器B上的文件是使用scp命令从机器A上先拷贝到机器B的/root目录下，然后使用mv命令移到/etc/cluster目录的。之所以出现这样的问题，是因为在机器B上文件是/root目录下创建的，在使用mv命令移动这个文件的时候会加上admin_home_t label，如下所示：

 [root@CentOS____102 ~]# ls -Z /etc/cluster/cluster.conf 
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 /etc/cluster/cluster.conf

  因为这个label的存在，SELinux会阻止corosync读取这个文件，admin_home_t表示这个文件是root用户目录下的文件。之所以打不开是因为cluster.conf文件的SELinux配置信息是继承原来那个目录的，与/etc/cluster目录不同。查看SELinux的日志信息(日志文件位置为/var/log/audit/audit.log)，可以看到下面的内容：

22109 type=AVC msg=audit(1383121897.046:28821): avc:  denied  { getattr } for  pid=2645 comm="corosync" path="/etc/cluster/cluster.conf" dev=sda2 ino=1311842 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

  正确的SELinux配置信息是scontext对应的内容，它描述了corosync进程的SELinux上下文，其中unconfined_u表示的是SELinux用户，这里的就是没有限制特定的用户。system_r表示corosync是一个进程，corosync_t是它的类型（或者叫域），每个进程或文件都有一个类型。cluster.conf的SELinux上下文由tcontext描述，第一个字段表示没有限制特定的用户，第二个字段表示她是一个目录或文件，第三个字段则是它的类型，这个类型只有root用户才可以访问。

  现在知道了问题原因，要解决这个问题见就很简单了。最容易想到的方法就是关闭SELinux。如果不想关闭SELinux，可以使用下面的命令恢复原来的文件标签，如下所示：

[root@CentOS____102 ~]# restorecon -v /etc/cluster/cluster.conf 
restorecon reset /etc/cluster/cluster.conf context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:cluster_conf_t:s0

  恢复后再使用ls -Z命令查看文件的信息，和机器A上的一样。修改后重新启动cman服务正常。