Friday, November 21, 2014

Mapping a VMWARE SCSI device to its Linux OS device

In VMWARE, you can see your SCSI channel and ID number in the Virtual Machine's Properties window under "Hardware": 



Once you have this information, you can then start determining where it is being used by your system either as /dev/ or an LVM physical volume.

Check the attached SCSI devices on linux:

[root@<server> ~]# cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: NECVMWar Model: VMware IDE CDR10 Rev: 1.00
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0
  Type:   Direct-Access                    ANSI  SCSI revision: 02
Host: scsi2 Channel: 00 Id: 01 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0
  Type:   Direct-Access                    ANSI  SCSI revision: 02
Host: scsi2 Channel: 00 Id: 02 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0
  Type:   Direct-Access                    ANSI  SCSI revision: 02
Host: scsi2 Channel: 00 Id: 03 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0
  Type:   Direct-Access                    ANSI  SCSI revision: 02


And finally you can co-relate that with the OS's own mapping:

[root@<server> ~]# ll /sys/bus/scsi/drivers/sd/2\:0\:3\:0/block/
total 0
drwxr-xr-x. 8 root root 0 Nov 19 15:10 sdd


This means that the SCSI device on Channel 00 ID 03 maps to /dev/sdd

Monday, May 26, 2014

Zabbix agent and Selinux

UPDATED (Aug 1, 2017 - yes very late): RedHat released an errata in October 2014 which resolves this problem: https://access.redhat.com/errata/RHBA-2014:1568

-- Original Post --

Recently, certain versions of SeLinux and the Zabbix Agent are having a  hard time working together.  Some of the Zabbix discovery processes are failing as they are being blocked by SeLinux.

More details are available at RedHat:
https://bugzilla.redhat.com/show_bug.cgi?id=1032691

Since I use both systems quite a bit, I needed to find a simple solution rather quickly.  (I probably wouldn't recommend this solution for extremely high security systems.  On the other hand, it does allow me to monitor systems which need to be continously available.)  I added the Zabbix process type to the SeLinux permissive list.  This can be done very easily by issuing the following commands:

First, you will need to be certain you know which process type zabbix-agent is running as on your system:

$ sudo ps -eZ | grep zabbix
...
unconfined_u:system_r:zabbix_agent_t:s0 7848 ? 00:00:00 zabbix_agentd
...

Next, we will add this type to the permissive list:

$ sudo semanage permissive -a zabbix_agent_t

Finally, we can check that we did this correctly:

$ sudo semanage permissive -l
...
Customized Permissive Types

zabbix_agent_t


You will have seen a list of all the permissive types go by and finally the customized premissive types - with yours in it.

Once Zabbix or RedHat issues a fix, you can remove the permissive type by running the same command with the -d option instead of -a.

$ sudo semanage permissive -d zabbix_agent_t

Hopefully a proper solution will be available soon.  Interestingly, just after posting this, I found that another blogger had a published almost exactly the same article:
http://inboundtraffic.net/selinux-permissive-domain/

Oh well - two similar articles can't hurt.