I’m working on Oracle database migration project where customer have chosen commodity x86 hardware with RHEL6 and EMC storage.
I’ve done many similar installations in the past and I always used the native MPIO in Linux (DM-Multipath) to load balance and failover I/O paths. This time however I’ve got EMC PowerPath doing the load balance and failover and got the native MPIO disabled. From my point of view it’s the same, whether I’ll be using /dev/emcpower* or /dev/mapper/* it’s the same. Obviously PowerPath has some advantages over the native MPIO which I really can’t tell yet. That’s a good paper from EMC giving a comparison between the native MPIO in different operating systems.
As mentioned before the aggregated logical names (pseudo names) with EMC PowerPath could be found under /dev/emcpowerX. I partitioned the disks with GPT tables and aligned the first partition to match the storage sector size. Also added to following line to udev rules to make sure my devices will get the proper permissions:
ACTION=="add", KERNEL=="emcpowerr1", OWNER:="oracle", GROUP:="dba", MODE="0600"
I restarted the server and then later udev to make sure ownership and permissions were picked up correctly. Upon running asmca to create ASM with the first disk group I got the following errors:
Configuring ASM failed with the following message: One or more disk group(s) creation failed as below: Disk Group DATA01 creation failed with the following message: ORA-15018: diskgroup cannot be created ORA-15031: disk specification '/dev/emcpowerr1' matches no disks ORA-15025: could not open disk "/dev/emcpowerr1" ORA-15056: additional error message
Well that’s strange, I’m sure the file had to correct permissions. However listing the file proved that it didn’t have the correct permissions. I repeated the process several times and always got the same result, you can use simple touch command to get the same result:
[root@testdb ~]# ls -al /dev/emcpowerr1 brw-rw---- 1 oracle dba 120, 241 Jan 23 12:35 /dev/emcpowerr1 [root@testdb ~]# touch /dev/emcpowerr1 [root@testdb ~]# ls -al /dev/emcpowerr1 brw-rw---- 1 root root 120, 241 Jan 23 12:35 /dev/emcpowerr1
Something was changing the ownership of the file and I didn’t know what. Well you’ll be no less surprised than I was to find that linux has a similar auditing framework as the Oracle database.
Auditctl will allow you to audit any file for any syscall run against it. In my case I would like to know which process is changing the ownership of my device file. Another helpful command is ausyscall whic allows you to map syscall names and numbers. In other words I would like to know what is the chmod syscall number on a 64bit platform (it does matter):
[root@testdb ~]# ausyscall x86_64 chmod --exact 90
Then I would like to set up auditing for all chmod calls against my device file:
[root@testdb ~]# auditctl -a exit,always -F path=/dev/emcpowerr1 -F arch=b64 -S chmod [root@testdb ~]# touch /dev/emcpowerr1 [root@testdb ~]# tail -f /var/log/audit/audit.log type=SYSCALL msg=audit(1422016631.416:4208): arch=c000003e syscall=90 success=yes exit=0 a0=7f3cfbd36960 a1=61b0 a2=7fff5c59b830 a3=0 items=1 ppid=60056 pid=63212 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="udevd" exe="/sbin/udevd" key=(null) type=CWD msg=audit(1422016631.416:4208): cwd="/" type=PATH msg=audit(1422016631.416:4208): item=0 name="/dev/emcpowerr1" inode=28418 dev=00:05 mode=060660 ouid=54321 ogid=54322 rdev=78:f1 nametype=NORMAL [root@testdb ~]# auditctl -D No rules
Gotcha! So it was udev changing the permissions but why ?
I spent half day going through logs and tracing udev but couldn’t find anything.
At the end of the day I found an article by RHEL on which they had exactly the same problem. The solution was to have “add|change” into the ACTION directive instead of only “add”.
So here is the rule you need to have in order for UDEV to set a persistent ownership/permission on EMC PowerPath device files in RHEL 6:
[root@testdb ~]# cat /etc/udev/rules.d/99-oracle-asm.rules ACTION=="add|change", KERNEL=="emcpowerr1", OWNER:="oracle", GROUP:="dba", MODE="0600"
Hope it helps and you don’t have to spent half day as I did.