Re: [Linux-HA] exportfs with multiple client ACLs
On 5/25/12 5:07 PM, Seth Galitzer wrote: > We have been using NIS netgroups to specify export options based on host > membership as specified in the /etc/netgroup file. Some exports may > have multiple exports specs based on their netgroups, eg one group > should have root-quashing enabled whereas another should not. If I'm > using /etc/exports, I just add another line onto the spec. With > pacemaker, this is not possible, so the suggestion I received was to > simply add multiple exportfs resources to accomplish this. What I am > finding is that I am getting erratic behavior in that export options > seem to be randomly getting overridden. So hosts that should not be > getting root-squashed still are. From my testing, it does not seem to > be a matter of "last one wins". If the root-squashed resource is > running at all, whether started before or after the non-root-squashed > resource, then all hosts are root-squashed. > > Is anybody else trying to do something like this? If so, how do you > specify multiple export rules for different hosts or host groups? I'm > using the ocf:heartbeat:exportfs service. Is this ignoring netgroup > specs for some reason, or is there something else going on here? My > /etc/nsswitch.conf looks correct, as far as NIS goes. > > I'm running pacemaker 1.1.7 from official packages on debain wheezy. > Kernel version is 3.2.0 and nfsd is 1.2.5, also from official packages. > > Any advice is appreciated. I can provide crm dumps and other configs if > needed. > > Thanks. > Seth > I haven't had that problem, though I don't think I use as many multiple host specs as you do. Here's a quick check: After all your exportfs resources are running, look at the output of the "exportfs" command on the node running the resources. Is the result what you expect? ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
[Linux-HA] exportfs with multiple client ACLs
We have been using NIS netgroups to specify export options based on host membership as specified in the /etc/netgroup file. Some exports may have multiple exports specs based on their netgroups, eg one group should have root-quashing enabled whereas another should not. If I'm using /etc/exports, I just add another line onto the spec. With pacemaker, this is not possible, so the suggestion I received was to simply add multiple exportfs resources to accomplish this. What I am finding is that I am getting erratic behavior in that export options seem to be randomly getting overridden. So hosts that should not be getting root-squashed still are. From my testing, it does not seem to be a matter of "last one wins". If the root-squashed resource is running at all, whether started before or after the non-root-squashed resource, then all hosts are root-squashed. Is anybody else trying to do something like this? If so, how do you specify multiple export rules for different hosts or host groups? I'm using the ocf:heartbeat:exportfs service. Is this ignoring netgroup specs for some reason, or is there something else going on here? My /etc/nsswitch.conf looks correct, as far as NIS goes. I'm running pacemaker 1.1.7 from official packages on debain wheezy. Kernel version is 3.2.0 and nfsd is 1.2.5, also from official packages. Any advice is appreciated. I can provide crm dumps and other configs if needed. Thanks. Seth -- Seth Galitzer Systems Coordinator Computing and Information Sciences Kansas State University http://www.cis.ksu.edu/~sgsax sg...@ksu.edu 785-532-7790 ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
[Linux-HA] announcement: resource-agents stable release 3.9.3
Hello, We've tagged on May 25th a new stable resource-agents release (3.9.3) in the upstream repository. Big thanks go to all contributors! Needless to say, without you this release would not be possible. Some highlights: - rgmanager/vm.sh: Added support for doing tunneled migrations - new resource agents: asterisk, dhcpd, named, pound, rsyslog, slapd, varnish - mysql: improve replication support - pgsql: support for replication - Raid1: support for multiple MD arrays - SAPInstance/SAPDatabase: use saphostagent and support for more databases - several new ocft test cases The full list of changes for the linux-ha RA set is available in ChangeLog. Please upgrade at the earliest opportunity. Best, The resource-agents maintainers ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
Re: [Linux-HA] corosync/pacemaker cluster failed
On Fri, May 25, 2012 at 10:46:10AM +1000, Andrew Beekhof wrote: > On Fri, May 25, 2012 at 10:39 AM, Tracy Reed wrote: > > On Fri, May 25, 2012 at 02:01:18AM +0200, Lars Ellenberg spake thusly: > >> Something is broken with your IPaddr2 script. > >> Relevant package would be resource-agents. > >> > >> I suggest you simply > >> wget > >> https://raw.github.com/ClusterLabs/resource-agents/master/heartbeat/IPaddr2 > >> and pastebin > >> diff -u /usr/lib/ocf/resource.d//heartbeat/IPaddr2 ./IPaddr2 > > > > I did the diff and pasted it here: > > > > http://pastebin.ca/2153805 > > > > It looks like RedHat has done some patching which makes the diff ugly. > > I really doubt we've patched it at all. There is no reason for them > to do so yet. > More likely its just an older version that upstream has further > polished since we grabbed a tarball. Right. That's why I also expected you to post your resoruce-agents *version* ;-) In fact I suspect it is the HEAD of the RHEL6 branch https://raw.github.com/ClusterLabs/resource-agents/RHEL6/heartbeat/IPaddr2 > > But I > > don't see any obvious typos or corruption. > > > >> Or replace yours with the current one. > > > > I would hesitate to do that given that RH has patched it. Other RH > > provided/patched code might depend on their patches to IPAddr2. I very much doubt that, as that would break each and every script out there some admin may have crafted over the years... Just try it. If it works better, great. If not, copy back the old one that is currently annying you ;-) > >> Maybe just upgrade resource-agents? > >> > >> Though, if the script is broken in that way (syntax error), > >> it should never work, and not even start, usually. > > > > Indeed. My theory is that line 332 which contains: > > > > exit $OCF_ERR_CONFIGURED > > > > which is an unquoted variable and maybe something weird got into that > > variable > > which caused a syntax error. I don't think so. > > I'm not sure which esac the error refers to > > though. Me neither. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
Re: [Linux-HA] 8.3.7 Version Advice
On Thu, May 24, 2012 at 09:33:37PM -0300, Net Warrior wrote: > El 05/24/2012 08:32 PM, Lars Ellenberg escribió: > > On Thu, May 24, 2012 at 01:56:37PM -0300, Net Warrior wrote: > >> Hi there list. > >> > >> I'm about to implement some work with DRBD but there is no posibillity to > >> upgrade the kernel to a newer one, the installations will be performed over > >> RHEL6 with kernel 2.6.33, so , following the table on DRBD weeb page, I try > > RHEL6 kernel is 2.6.32 (plus RH patches), not 33. > > > > You can build any DRBD version against that kernel, and use that. > > Of course we would provide you with suitable module packages, > > if you prefer that. > > > >> to use the kernel that matches the DRBD version. > >> > >> My questions is, is 8.3.7 stable enought, based on your experience, any > >> advice about know bugs , issues? > > As for "enough", only you can decide what is good "enough" for you. > > No way to avoid to make that decision yourself. > > > > Known bugs: quite a few. See the changelog. > > > > > > So you are willing to build and use your own 2.6.33 on a RHEL6, > > but not considering using a more recent DRBD module? > > > > Why would you do that. > > > Thanks for your answer. > > Ok, my bad, kernel 2.6.32, that's right. > > As long as I know, the module kernel was introduced from 2.6.36 and In fact, 2.6.33. That's why I suspected you wanted that version ;-) > above, so, lower kernels lack the drbd device modue support, so, I undertood > I could not install or build any DRBD version on those kernels. > > If you say that I can make any build on that kernel, ( 2.6.32 ), DRBD > 8.4 included, If you do your setup now, and then won't be able to change it, I'd recommend to stay with 8.3.13. > I'll really appreciate your guidance on that, if there are any > already built rpm packages, the better, just cuz you mention you can > provide suitable packages :D Linbit customers have the convenience of yum repos: http://packages.linbit.com/rhel6/ Others have to search the web (there are modules in centos and similar), or build themselves (not that complicated, make rpm usually does the trick). -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
