Bug 692571

Looks like it's dying during the initial start up attempt, and then the subsequent parse errors may just be symptoms of it being already dead.

Mar 31 11:04:56 grant-01 qarshd[2152]: Running cmdline: service cman start 2>&1
Mar 31 11:04:56 grant-01 corosync[2190]:   [MAIN  ] Corosync Cluster Engine ('1.2.3'): started and ready to provide service.
Mar 31 11:04:56 grant-01 corosync[2190]:   [MAIN  ] Corosync built-in features: nss dbus rdma snmp
Mar 31 11:04:56 grant-01 corosync[2190]:   [MAIN  ] Successfully read config from /etc/cluster/cluster.conf
Mar 31 11:04:56 grant-01 corosync[2190]:   [MAIN  ] Successfully parsed cman config
Mar 31 11:04:56 grant-01 corosync[2190]:   [TOTEM ] Initializing transport (UDP/IP Multicast).
Mar 31 11:04:56 grant-01 corosync[2190]:   [TOTEM ] Initializing transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0).
Mar 31 11:04:56 grant-01 corosync[2190]:   [TOTEM ] The network interface [10.15.89.151] is now up.
Mar 31 11:04:57 grant-01 corosync[2190]:   [QUORUM] Using quorum provider quorum_cman
Mar 31 11:04:57 grant-01 corosync[2190]:   [SERV  ] Service engine loaded: corosync cluster quorum service v0.1
Mar 31 11:04:57 grant-01 corosync[2190]:   [CMAN  ] CMAN 3.0.12 (built Mar 22 2011 05:32:49) started
Mar 31 11:04:57 grant-01 corosync[2190]:   [SERV  ] Service engine loaded: corosync CMAN membership service 2.90
Mar 31 11:04:57 grant-01 corosync[2190]:   [SERV  ] Service engine loaded: openais checkpoint service B.01.01
Mar 31 11:04:57 grant-01 corosync[2190]:   [SERV  ] Service engine loaded: corosync extended virtual synchrony service
Mar 31 11:04:57 grant-01 corosync[2190]:   [SERV  ] Service engine loaded: corosync configuration service
Mar 31 11:04:57 grant-01 corosync[2190]:   [SERV  ] Service engine loaded: corosync cluster closed process group service v1.01
Mar 31 11:04:57 grant-01 corosync[2190]:   [SERV  ] Service engine loaded: corosync cluster config database access v1.01
Mar 31 11:04:57 grant-01 corosync[2190]:   [SERV  ] Service engine loaded: corosync profile loading service
Mar 31 11:04:57 grant-01 corosync[2190]:   [QUORUM] Using quorum provider quorum_cman
Mar 31 11:04:57 grant-01 corosync[2190]:   [SERV  ] Service engine loaded: corosync cluster quorum service v0.1
Mar 31 11:04:57 grant-01 corosync[2190]:   [MAIN  ] Compatibility mode set to whitetank.  Using V1 and V2 of the synchronization engine.
Mar 31 11:04:57 grant-01 corosync[2190]:   [TOTEM ] A processor joined or left the membership and a new membership was formed.
Mar 31 11:04:57 grant-01 corosync[2190]:   [QUORUM] Members[1]: 1
Mar 31 11:04:57 grant-01 corosync[2190]:   [QUORUM] Members[1]: 1
Mar 31 11:04:57 grant-01 corosync[2190]:   [CPG   ] downlist received left_list: 0
Mar 31 11:04:57 grant-01 corosync[2190]:   [CPG   ] chosen downlist from node r(0) ip(10.15.89.151)
Mar 31 11:04:57 grant-01 corosync[2190]:   [MAIN  ] Completed service synchronization, ready to provide service.
Mar 31 11:04:57 grant-01 corosync[2190]:   [TOTEM ] A processor joined or left the membership and a new membership was formed.
Mar 31 11:04:57 grant-01 corosync[2190]:   [CMAN  ] quorum regained, resuming activity
Mar 31 11:04:57 grant-01 corosync[2190]:   [QUORUM] This node is within the primary component and will provide service.
Mar 31 11:04:57 grant-01 corosync[2190]:   [QUORUM] Members[2]: 1 2
Mar 31 11:04:57 grant-01 corosync[2190]:   [QUORUM] Members[2]: 1 2
Mar 31 11:04:57 grant-01 corosync[2190]:   [CPG   ] downlist received left_list: 0
Mar 31 11:04:57 grant-01 corosync[2190]:   [CPG   ] downlist received left_list: 0
Mar 31 11:04:57 grant-01 corosync[2190]:   [CPG   ] chosen downlist from node r(0) ip(10.15.89.151)
Mar 31 11:04:57 grant-01 corosync[2190]:   [MAIN  ] Completed service synchronization, ready to provide service.
Mar 31 11:04:59 grant-01 corosync[2190]:   [TOTEM ] A processor joined or left the membership and a new membership was formed.
Mar 31 11:04:59 grant-01 corosync[2190]:   [QUORUM] Members[3]: 1 2 3
Mar 31 11:04:59 grant-01 corosync[2190]:   [QUORUM] Members[3]: 1 2 3
Mar 31 11:04:59 grant-01 corosync[2190]:   [TOTEM ] Retransmit List: 16
Mar 31 11:04:59 grant-01 corosync[2190]:   [CPG   ] downlist received left_list: 0
Mar 31 11:04:59 grant-01 corosync[2190]:   [CPG   ] downlist received left_list: 0
Mar 31 11:04:59 grant-01 corosync[2190]:   [CPG   ] downlist received left_list: 0
Mar 31 11:04:59 grant-01 corosync[2190]:   [CPG   ] chosen downlist from node r(0) ip(10.15.89.151)
Mar 31 11:04:59 grant-01 corosync[2190]:   [TOTEM ] Retransmit List: 1f
Mar 31 11:04:59 grant-01 corosync[2190]:   [MAIN  ] Completed service synchronization, ready to provide service.
Mar 31 11:05:00 grant-01 fenced[2246]: fenced 3.0.12 started
Mar 31 11:05:01 grant-01 dlm_controld[2265]: dlm_controld 3.0.12 started
Mar 31 11:05:03 grant-01 gfs_controld[2323]: gfs_controld 3.0.12 started
Mar 31 11:05:03 grant-01 abrt[2342]: saved core dump of pid 2190 (/usr/sbin/corosync) to /var/spool/abrt/ccpp-1301587503-2190.new/coredump (51826688 bytes)
Mar 31 11:05:03 grant-01 abrtd: Directory 'ccpp-1301587503-2190' creation detected
Mar 31 11:05:03 grant-01 fenced[2246]: cluster is down, exiting
Mar 31 11:05:03 grant-01 dlm_controld[2265]: cluster is down, exiting
Mar 31 11:05:03 grant-01 dlm_controld[2265]: daemon cpg_dispatch error 2
Mar 31 11:05:03 grant-01 abrtd: Registered Database plugin 'SQLite3'
Mar 31 11:05:03 grant-01 xinetd[1785]: EXIT: qarsh status=0 pid=2152 duration=7(sec)
Mar 31 11:05:04 grant-01 abrtd: New crash /var/spool/abrt/ccpp-1301587503-2190, processing
Mar 31 11:05:05 grant-01 gfs_controld[2323]: daemon cpg_initialize error 6
Mar 31 11:05:05 grant-01 kernel: dlm: closing connection to node 3
Mar 31 11:05:05 grant-01 kernel: dlm: closing connection to node 2
Mar 31 11:05:05 grant-01 kernel: dlm: closing connection to node 1

FYI - comment #1 happened after upgrading to 1.2.3-33. comment #0 occurred with 1.2.3-31.

There have been no changes on our side and disabling selinux makes the world
work again.

Corey can provide a collection of audit.log from the nodes.

It appears that the issue is similar to one that has been filed recently in
fedora regarding /dev/dlm, but it needs to be double checked because I am no
selinux expert.

Once dlm_controld starts, everything goes south (at least based on cman init
startup sequence).

Could you attach the AVC messages?

I think this is caused because the /dev/dlm labels are wrong.

If you change the context I think this will work

# semanage fcontext -a -t dlm_control_device_t '/dev/dlm.*'
# restorecon -R -v /dev/dlm*

Miroslav this is the default labeling we now have in Fedora, can you put this into RHEL6,1

Actually this fix looks like it is in selinux-policy-3.7.19-80.el6

Preview is available on http://people.redhat.com/dwalsh/SELinux/RHEL6

type=AVC msg=audit(1301684886.261:50088): avc:  denied  { write } for  pid=6538 comm="cman_tool" name="cman_client" dev=dm-0 ino=1178785 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1301684886.261:50088): arch=c000003e syscall=42 success=no exit=-13 a0=3 a1=7fff1eb64a40 a2=6e a3=7fff1eb647c0 items=0 ppid=6518 pid=6538 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="cman_tool" exe="/usr/sbin/cman_tool" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=AVC msg=audit(1301684886.357:50089): avc:  denied  { write } for  pid=6541 comm="cman_tool" name="cman_admin" dev=dm-0 ino=1178786 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1301684886.357:50089): arch=c000003e syscall=42 success=no exit=-13 a0=3 a1=7fffa310cb00 a2=6e a3=7fffa310c880 items=0 ppid=6518 pid=6541 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="cman_tool" exe="/usr/sbin/cman_tool" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=AVC msg=audit(1301684886.471:50090): avc:  denied  { read } for  pid=6552 comm="corosync" name="corosync.log" dev=dm-0 ino=1178782 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=SYSCALL msg=audit(1301684886.471:50090): arch=c000003e syscall=2 success=no exit=-13 a0=18b9210 a1=442 a2=1b6 a3=0 items=0 ppid=6541 pid=6552 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="corosync" exe="/usr/sbin/corosync" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=AVC msg=audit(1301684889.430:50091): avc:  denied  { write } for  pid=6570 comm="cman_tool" name="cman_client" dev=dm-0 ino=1178785 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1301684889.430:50091): arch=c000003e syscall=42 success=no exit=-13 a0=3 a1=7fff7e39a850 a2=6e a3=7fff7e39a5d0 items=0 ppid=6518 pid=6570 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="cman_tool" exe="/usr/sbin/cman_tool" subj=unconfined_u:system_r:corosync_t:s0 key=(null)

I'm seeing this issue with the latest selinux-policy.

[root@taft-01 ~]# rpm -q selinux-policy
selinux-policy-3.7.19-80.el6.noarch

How sure are we that this is selinux? I'm able to reproduce this even in
permissive mode.

[root@taft-01 ~]# 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...                                        [  OK  ]
   Waiting for quorum... cman_tool: Cannot open connection to cman, is it
running ?
                                                           [FAILED]
[root@taft-01 ~]# getenforce
Permissive

Corey,
could you turn on full auditing using 

# echo "-w /etc/shadow -p w" >> /etc/audit/audit.rules
# service auditd restart

and then try to re-test it and add AVC msgs in permissive mode. I would like to know where corosync.log, cman_admin, cman_client objects are located.

Also what does

# ls -lZ /var/run/cman*

[root@taft-01 ~]# 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...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]

[root@taft-01 ~]# ls -lZ /var/run/cman*
srw-------. root root unconfined_u:object_r:corosync_var_run_t:s0 /var/run/cman_admin
srw-rw----. root root unconfined_u:object_r:corosync_var_run_t:s0 /var/run/cman_client
-rw-r--r--. root root unconfined_u:object_r:initrc_var_run_t:s0 /var/run/cman.pid

type=AVC msg=audit(1301958789.590:45): avc:  denied  { read } for  pid=2119 comm="fenced" name="fenced.log" dev=dm-0 ino=921008 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=SYSCALL msg=audit(1301958789.590:45): arch=c000003e syscall=2 success=yes exit=4 a0=34fc002dc0 a1=442 a2=1b6 a3=0 items=1 ppid=1 pid=2119 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="fenced" exe="/usr/sbin/fenced" subj=unconfined_u:system_r:fenced_t:s0 key=(null)
type=CWD msg=audit(1301958789.590:45):  cwd="/"
type=PATH msg=audit(1301958789.590:45): item=0 name="/var/log/cluster/fenced.log" inode=921008 dev=fd:00 mode=0100666 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_log_t:s0
type=AVC msg=audit(1301958789.745:46): avc:  denied  { read } for  pid=2139 comm="dlm_controld" name="dlm_controld.log" dev=dm-0 ino=921010 scontext=unconfined_u:system_r:dlm_controld_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=SYSCALL msg=audit(1301958789.745:46): arch=c000003e syscall=2 success=yes exit=4 a0=34fc002dc0 a1=442 a2=1b6 a3=0 items=1 ppid=1 pid=2139 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="dlm_controld" exe="/usr/sbin/dlm_controld" subj=unconfined_u:system_r:dlm_controld_t:s0 key=(null)
type=CWD msg=audit(1301958789.745:46):  cwd="/"
type=PATH msg=audit(1301958789.745:46): item=0 name="/var/log/cluster/dlm_controld.log" inode=921010 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_log_t:s0
type=AVC msg=audit(1301958790.838:47): avc:  denied  { read } for  pid=2194 comm="gfs_controld" name="gfs_controld.log" dev=dm-0 ino=921011 scontext=unconfined_u:system_r:gfs_controld_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=SYSCALL msg=audit(1301958790.838:47): arch=c000003e syscall=2 success=yes exit=4 a0=34fc002dc0 a1=442 a2=1b6 a3=0 items=1 ppid=1 pid=2194 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="gfs_controld" exe="/usr/sbin/gfs_controld" subj=unconfined_u:system_r:gfs_controld_t:s0 key=(null)
type=CWD msg=audit(1301958790.838:47):  cwd="/"
type=PATH msg=audit(1301958790.838:47): item=0 name="/var/log/cluster/gfs_controld.log" inode=921011 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_log_t:s0

Created attachment 489940 [details]
cman init script patch

Corey,
your cluster log files are mislabeled. Not sure why. Did you run cluster services directly without using the cman service script?

Execute

# restorecon -R -v /var/log/cluster


The next issue is with the cman init script which contains

pidof /usr/sbin/corosync > /var/run/cman.pid

This causes "cmain.pid" is labeled as initrc_var_run_t. So I need to add label to policy and the attached patch is needed for cman init script.

You can test it using

# semanage fcontext -a -t corosync_var_run_t "/var/run/cman.pid"

and apply the patch. Then try to start cluster services again.

(In reply to comment #12)
> Corey,
> your cluster log files are mislabeled. Not sure why. Did you run cluster
> services directly without using the cman service script?
> 
> Execute
> 
> # restorecon -R -v /var/log/cluster

I did to debug and try to understand what was happening.

The old dir is /var/log/cluster.old and it should be labeled correctly.

Corey,
could you try to just relabel your logs files

# restorecon -R -v /var/log/cluster

and I believe it will work for you.

That worked.

[root@grant-01 ~]# getenforce
Enforcing

[root@grant-01 ~]# 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... Can't determine address family of nodename
Unable to get the configuration
corosync died: Could not read cluster configuration Check cluster logs for details
                                                           [FAILED]

[root@grant-01 ~]# restorecon -R -v /var/log/cluster
restorecon reset /var/log/cluster/gfs_controld.log context system_u:object_r:var_log_t:s0->system_u:object_r:gfs_controld_var_log_t:s0
restorecon reset /var/log/cluster/fenced.log context system_u:object_r:var_log_t:s0->system_u:object_r:fenced_var_log_t:s0
restorecon reset /var/log/cluster/dlm_controld.log context system_u:object_r:var_log_t:s0->system_u:object_r:dlm_controld_var_log_t:s0
restorecon reset /var/log/cluster/corosync.log context system_u:object_r:var_log_t:s0->system_u:object_r:corosync_var_log_t:s0

[root@grant-01 ~]# 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...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]

Is /var/log/cluster owned by any package?

rpm -qf /var/log/cluster

Is some application destroying and recreating this directory?

[root@buzz-05 log]# rpm -qf /var/log/cluster
cman-3.0.12-41.el6.x86_64
corosync-1.2.3-34.el6.x86_64

I doubt the directory is being recreated

(In reply to comment #17)
> [root@buzz-05 log]# rpm -qf /var/log/cluster
> cman-3.0.12-41.el6.x86_64
> corosync-1.2.3-34.el6.x86_64
> 
> I doubt the directory is being recreated

Me too. I believe cluster services were started by hand.

(In reply to comment #18)

> Me too. I believe cluster services were started by hand.

I looked through all of the comments and Corey is always using the service script.

is /var/log/cluster being ghosted?  Or is it actually owned by cman or corosync package?  IE Did it get created during the install.

Could someone remove the dir and then do a 

yum reinstall corocync cman

And see if the directory gets created with the right context?

If you remove the directory and do a service corosync start, does it get created with the correct context?  service cman start?

Looks like the directory is owned by two packages. cman requires corosync so we could probably drop the double ownership if needed.

[root@buzz-05 ~]# rpm -ql corosync | grep log
/var/log/cluster
[root@buzz-05 ~]# rpm -ql cman | grep log
/etc/logrotate.d/cman
/var/log/cluster

Checking the install process...

[root@dash-01 ~]# ls -lZd /var/log/cluster
ls: cannot access /var/log/cluster: No such file or directory
[root@dash-01 ~]# yum install -y corosync
...
Installed:
  corosync.x86_64 0:1.2.3-33.el6

Dependency Installed:
  corosynclib.x86_64 0:1.2.3-33.el6

Complete!
[root@dash-01 ~]# ls -lZd /var/log/cluster
drwx------. root root system_u:object_r:var_log_t:s0   /var/log/cluster
[root@dash-01 ~]# rmdir /var/log/cluster
[root@dash-01 ~]# yum install -y cman
...
Installed:
  cman.x86_64 0:3.0.12-41.el6

Dependency Installed:
  clusterlib.x86_64 0:3.0.12-41.el6      modcluster.x86_64 0:0.16.2-10.el6
  openais.x86_64 0:1.1.1-7.el6           openaislib.x86_64 0:1.1.1-7.el6

Complete!
[root@dash-01 ~]# ls -lZd /var/log/cluster
drwxr-xr-x. root root system_u:object_r:var_log_t:s0   /var/log/cluster


The directory does not get created with service start, in fact, the service will not start without the directory.

(In reply to comment #16)
> Is /var/log/cluster owned by any package?
> 
> rpm -qf /var/log/cluster
> 
> Is some application destroying and recreating this directory?

No, as I wrote in comment #13, I did it manually to move the old logs out of the way and recreated (always manually). The old log dir was moved to logs/cluster.old and still has the correct labelling.

(In reply to comment #22)
> Looks like the directory is owned by two packages. cman requires corosync so we
> could probably drop the double ownership if needed.

We could, but it's going to have to wait that F14 is EOL before I do the change upstream and it's not really an issue since rpm allows referencing the same dir more than once. The most important bit is that the dir is not created by any script and that it is owned by its users.

My mistake /var/log/cluster looks like it should be labeled var_log_t, it is the subdirs that were created with the wrong context.

This still exists in the latest tree/rpm and continues to block cluster testing.

type=AVC msg=audit(1302211468.251:51): avc:  denied  { read } for  pid=1970 comm="corosync" name="corosync.log" dev=dm-0 ino=132258 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file

[root@taft-01 ~]# uname -ar
Linux taft-01 2.6.32-130.el6.x86_64 #1 SMP Tue Apr 5 19:58:31 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

[root@taft-01 ~]# rpm -q corosync
corosync-1.2.3-34.el6.x86_64
[root@taft-01 ~]# rpm -q selinux-policy
selinux-policy-3.7.19-82.el6.noarch

What are you exactly doing?

Miroslav,

Try these steps to reproduce the issue:
rm -f /var/log/cluster/*
service cman start

It is supposed to be working and it works for me

# ls -lZ /var/log/cluster/
-rw-r--r--. root root unconfined_u:object_r:corosync_var_log_t:s0 corosync.log
-rw-r--r--. root root unconfined_u:object_r:dlm_controld_var_log_t:s0 dlm_controld.log
-rw-rw-rw-. root root unconfined_u:object_r:fenced_var_log_t:s0 fenced.log
-rw-r--r--. root root unconfined_u:object_r:gfs_controld_var_log_t:s0 gfs_controld.log

# rm -f /var/log/cluster/*
# service cman start
# ls -lZ /var/log/cluster/
-rw-r--r--. root root unconfined_u:object_r:corosync_var_log_t:s0 corosync.log
-rw-r--r--. root root unconfined_u:object_r:dlm_controld_var_log_t:s0 dlm_controld.log
-rw-rw-rw-. root root unconfined_u:object_r:fenced_var_log_t:s0 fenced.log
-rw-r--r--. root root unconfined_u:object_r:gfs_controld_var_log_t:s0 gfs_controld.log

I don't see any AVCs with 3.7.19-82.el6 policy. The automated test contains all cluster services which I found and succeeds in enforcing mode.

Following sequence of commands does not bring any AVCs on those machines I'm using now:
rm -f /var/log/cluster/*
service cman start

These machines were provided today by beaker/inventory (RHEL6.1-20110407.n.0).

This may be an issue with our qarshd policy not getting installed correctly.  It automatically rebuilds at install and with -80 it was choking on ftp_initrc_domtrans and seunshare_domtrans.

make: Entering directory `/usr/share/doc/qarsh-selinux-1.26'
Loading targeted modules: qarshd
libsepol.print_missing_requirements: qarshd's global requirements were not met: type/attribute seunshare_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
/usr/sbin/semodule:  Failed!
make: *** [tmp/loaded] Error 1
make: Leaving directory `/usr/share/doc/qarsh-selinux-1.26'

Nate,
ftp_initrc_domtrans declaration issue is fixed -82 and seunshare_domtrans declaration issue will be fixed in -83 release. I have been talking about that with Jaroslav.

I am moving back to ON_QA.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0526.html