Bug 1334170

Marking with conditional NAK. It's not clear if the tcp listener feature is new.
Git diff does not tell much and manpages do not mention such feature.

In order to provide ACK we will need the following:

1) Unit test results OR usage and config example
    - needed to plan correct testing

2) Documentation
    - if tcp listener capability is new we need to have it documented well for end users

3) Feature specification
    - ideally a use case for the feature

(In reply to Roman Bednář from comment #2)
> Marking with conditional NAK. It's not clear if the tcp listener feature is
> new.
> Git diff does not tell much and manpages do not mention such feature.

tcp is documented in fence_virt.conf

Roman,

Can you take a look at the documentation for the tcp listener (it's in the fence_virt.conf man page in the fence-virtd package starting on line 118).  It also has some information on how it is configured.

Ok, adding QA ack.

Ryan, do we have any update on this bug?

test procedure:

wget http://download.eng.bos.redhat.com/brewroot/packages/fence-virt/0.3.2/5.el7/i686/fence-virt-{,debuginfo-}0.3.2-5.el7.i686.rpm

wget http://download.eng.bos.redhat.com/brewroot/packages/fence-virt/0.3.2/5.el7/i686/fence-virtd-{,libvirt-,multicast-,tcp-}0.3.2-5.el7.i686.rpm

yum install -y fence-*.rpm

mkdir /etc/cluster/

echo redhat > /etc/cluster/fence_xvm.key

chmod a+r /etc/cluster/fence_xvm.key

chmod a+rx /etc/cluster/

sed -i -e s/multicast/tcp/ -e s/225.0.0.12/192.168.23.1/ /etc/fence_virt.conf 

sed -i 's@$FENCE_VIRTD_ARGS@$FENCE_VIRTD_ARGS -p /tmp/fence_virtd_stack.pid@' /usr/lib/systemd/system/fence_virtd.service

# If virtual machines are run as a different user, e.g. on a tripleo-quickstart deploy of OSP9
# sed -i -e s/system/session/ /etc/fence_virt.conf 
# echo "User=stack" >> /usr/lib/systemd/system/fence_virtd.service

systemctl enable fence_virtd.service

service fence_virtd start

fence-virt -T 192.168.23.1 -o list

Example output:

ceph_0                           76fc81e6-4fe9-4486-b03a-e8ae401c3421 on
ceph_1                           a80d43b4-e1db-4801-ba47-b6c0a35c1706 on
ceph_2                           69dbe3f2-03d6-4933-8471-b429f7d76ad1 on
compute_0                        1762c0ef-46ac-4f84-90a9-52f2af2b7dec on
control_0                        725820be-33ee-4630-9bfc-3f4124291df5 on
control_1                        92baf1f6-03be-4786-a9fa-142d3198f599 on
control_2                        af0f9f3c-a573-40d2-93b3-5ef2327274cd on
undercloud                       5c71b883-9761-4e78-bd4f-c5e8e4df1a71 on


For some reason it only worked if I ran the following as stack instead of using systemd:

   /usr/sbin/fence_virtd -w -p /tmp/fence_virtd_stack.pid -F -d99

But thats not really relevant to this bug.


Full log from the server side:

[stack@haa-08 ~]$ /usr/sbin/fence_virtd -w -p /tmp/fence_virtd_stack.pid -F -d99
Using /tmp/fence_virtd_stack.pid
Background mode disabled
Debugging threshold is now 99
backends {
	libvirt {
		uri = "qemu:///session";
	}

}

listeners {
	tcp {
		interface = "virbr0";
		address = "192.168.23.1";
		key_file = "/etc/cluster/fence_xvm.key";
	}

}

fence_virtd {
	debug = "99";
	backend = "libvirt";
	listener = "tcp";
}

Backend plugin: libvirt
Listener plugin: tcp
Searching /usr/lib/fence-virt for plugins...
Searching for plugins in /usr/lib/fence-virt
Loading plugin from /usr/lib/fence-virt/tcp.so
Failed to map backend_plugin_version
Registered listener plugin tcp 0.1
Loading plugin from /usr/lib/fence-virt/libvirt.so
Registered backend plugin libvirt 0.1
Loading plugin from /usr/lib/fence-virt/multicast.so
Failed to map backend_plugin_version
Registered listener plugin multicast 1.2
3 plugins found
Available backends:
    libvirt 0.1
Available listeners:
    tcp 0.1
    multicast 1.2
Debugging threshold is now 99
Using qemu:///session
Debugging threshold is now 99
Got /etc/cluster/fence_xvm.key for key_file
Got 192.168.23.1 for address
Reading in key file /etc/cluster/fence_xvm.key into 0x821602c (4096 max size)
Stopped reading @ 7 bytes
Actual key length = 7 bytes
ipv4_listen: Setting up ipv4 listen socket
ipv4_listen: Success; fd = 8
Accepted client...
Request 5 seqno 354639 domain 
Plain TCP request
Request 5 seqno 354639 target 
libvirt_devstatus ---
Sending response to caller...
Accepted client...
Request 5 seqno 397958 domain 
Plain TCP request
Request 5 seqno 397958 target 
libvirt_devstatus ---
Sending response to caller...
Accepted client...
Request 6 seqno 780593 domain 
Plain TCP request
Request 6 seqno 780593 target 
libvirt_hostlist
Sending 76fc81e6-4fe9-4486-b03a-e8ae401c3421
Sending a80d43b4-e1db-4801-ba47-b6c0a35c1706
Sending 69dbe3f2-03d6-4933-8471-b429f7d76ad1
Sending 1762c0ef-46ac-4f84-90a9-52f2af2b7dec
Sending 725820be-33ee-4630-9bfc-3f4124291df5
Sending 92baf1f6-03be-4786-a9fa-142d3198f599
Sending af0f9f3c-a573-40d2-93b3-5ef2327274cd
Sending 5c71b883-9761-4e78-bd4f-c5e8e4df1a71
Sending terminator packet
Sending response to caller...

Ah, thats why:

type=AVC msg=audit(1475718963.199:5271506): avc:  denied  { search } for  pid=76426 comm="fence_virtd" name="stack" dev="dm-2" ino=1073750528 scontext=system_u:system_r:fenced_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
type=SYSCALL msg=audit(1475718963.199:5271506): arch=40000003 syscall=195 success=no exit=-13 a0=81a9128 a1=ffb91ecc a2=f7597000 a3=81a9128 items=0 ppid=1 pid=76426 auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=4294967295 comm="fence_virtd" exe="/usr/sbin/fence_virtd" subj=system_u:system_r:fenced_t:s0 key=(null)

That is my understanding too

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2089