How to determine if a VG has cluster bit set?

[Ralph Grothe]

Hi,

I need to check this in the configuration
block of a plugin script I write.
Unfortunately, this part of the script is
run with lowered privileges after they have
been dropped even when started as root.

As a workaround I first thought to parse the package control scripts by collecting them over a glob similar to

@pkg_ctls = glob '/etc/cmcluster/*/*.cntl';

But then I realized that for some strange reason they were not readable by others so that
parsing them would fail.
The same is true for /etc/lvmtab,
and reading /etc/mnttab would only yield open VGs on the current cluster node but not cluster wide.

Any other ideas?

[Eric SAUBIGNAC]

Bonjour Ralph,

Not a very great idea, but /sbin/vgdisplay is accessible for everybody. So a vgdisplay on a vg activated in exclusive mode (that is with cluster bit set) should output the information ?

Hope this help

Eric

[Ralph Grothe]

Bonsoir Eric (soir il est ici),

yes, I could parse for exclusive from

/usr/sbin/vgdisplay 2>/dev/null|grep -E 'VG (Name|Status)'

But this would only catch those currently active on the executing host.
This would catch about a third of the cluster VGs at least.

[Peter Nikitka]

Hi Ralph,

perhaps a two-step strategy could help:
1) You could export relevant information for non-privileged users in your control script to a file (readable by the lower-privileged user, residing on the active node).
- Every time a cluster change is done, this information would be refreshed.
- You could export some raw information only
2
The real processing/formatting of the output data could be done later by other scripts, reading this file and by a non-privileged user.

mfG Peter

[Geoff Wild]

I would have thought using cmquerycl -v -c cluster -l lvm

would show that - but it shows all vg's....

Rgds...Geoff

[Eric SAUBIGNAC]

Evening also here and I will leave in a few minutes ;-)

An other idea, but I have no HP-UX box with MCSG to test it : with proper security rules configured in the cluster, I think there is a way to use commands like cmgetconf. I don't remember exactly how output looks like but I guess the VG configured in the cluster file will be shown ?

Bonne soirée :-)

Eric

[Wouter Jagers]

Also, when you'd do a vgdisplay on all the volume groups you find in /dev and some are open exclusively on another node, vgdisplay will tell you this in an error message. Hence, that VG is cluster aware.

Cheers,
Wout

[Ralph Grothe]

Hello Guys,

Wouter,
unfortunately the error message for hit inactive VGs doesn't indicate the reason for their inactive state on this node
(e.g. because they might be active, exclusive on another cluster node).
Thus, it could also be that the listed VGs on stderr are ordinary non cluster shared VGs
that are for whatever reason elsewise inactive.

$ /usr/sbin/vgdisplay >/dev/null
vgdisplay: Volume group not activated.
vgdisplay: Cannot display volume group "/dev/vg25".
vgdisplay: Volume group not activated.
vgdisplay: Cannot display volume group "/dev/vg31".
vgdisplay: Volume group not activated.
vgdisplay: Cannot display volume group "/dev/vg32".
vgdisplay: Volume group not activated.
vgdisplay: Cannot display volume group "/dev/vg33".
vgdisplay: Volume group not activated.
vgdisplay: Cannot display volume group "/dev/vg34".
vgdisplay: Volume group not activated.
vgdisplay: Cannot display volume group "/dev/vg35".
vgdisplay: Volume group not activated.
vgdisplay: Cannot display volume group "/dev/vg36".
vgdisplay: Volume group not activated.
vgdisplay: Cannot display volume group "/dev/vg37".
vgdisplay: Volume group not activated.
vgdisplay: Cannot display volume group "/dev/vg38".


Eric,
yes, newer SG releases offer access control policies so that members of the least privileged USER_ROLE MONITOR could run cmgetconf (and other non-intrusive cm* commands).
However, we still have some clusters that are pre-releases that lack this feature (ok sudo, is always an option)
But even if, the cmgetconf command blocks far too long (for a monitoring process) because the cluster scan may take that long.
Therefore I would prefer a mere read of the cluster config binary through cmviewconf.
But then the only VG related info that cmviewconf dumps refers to the VG that contains the lock PV.

# cmviewconf|grep -i vg
first lock vg name: /dev/vg37
second lock vg name: (not configured)


Peter,
yes I think I will finally do something similar to what you have suggested.
Or elevate permissions on cluster package control script files to read to be able to parse the LV array assignments therein,
under the assumption that these files are in sync over all cluster nodes.


Does anyone know of a hack how to read the LVM meta data from the raw devs directly to arrive at the cluster bit?
I know this is possible with dd on Linux LVM.

[Eric SAUBIGNAC]

Bonjour Ralph,


You can try to activate inactive VG with standard "-a y". If it has cluster bit set, you will have an explicit error message.

Of course you can try to dump lvm structure with dd. I tried to find some informations relative to lvm structure under /usr/include but found nothing. Maybe someone knows ?

But in both cases you need root privileges : you must be root to use vgchange and disk special files are owned by root.

Eric