checkquorum.wdmd: add integration script with wdmd
 

On 10/10/2012 6:26 AM, Dietmar Maurer wrote:
>> +# rpm based distros
>> +[ -d /etc/sysconfig ] &&
>> + [ -f /etc/sysconfig/checkquorum ] &&
>> + . /etc/sysconfig/checkquorum
>> +
>> +# deb based distros
>> +[ ! -d /etc/sysconfig ] &&
>> + [ -f /etc/default/checkquorum ] &&
>> + . /etc/default/checkquorum
>> +
>
> FYI: Some RAID tool vendors delivers utilities for debian which creates directory '/etc/sysconfig'
> on debian boxes, so that test is not reliable.
>
>

This might be a controversial argument.

Debian policy (1) define the use of /etc/default as "should" (2), for
conffile such as this one. On the other side it does not explicitly
forbid the use of sysconfig.

sysconfig is not found anywhere in Debian default archive because
packages to use the formal *should* policy.

If third-party applications don´t follow Debian packaging guidelines, it
is possible that they might break other components as well.

Of course we can argue on the definition of "should" forever and ever :)

As upstream we follow basic guidelines, distribution packagers and
porters should (pun intended ;)) make sure to provide us with porting
patches (that´s also part of the Debian Maintainer duty).

Fabio

1) http://www.debian.org/doc/debian-policy/ch-opersys.html
Section 9.3.2

"To ease the burden on the system administrator, such configurable values
should not be placed directly in the script.
Instead, they should be placed in a file in /etc/default, ...."

2) http://www.thefreedictionary.com/should
should (shd)
aux.v. Past tense of shall
1. Used to express obligation or duty
....

checkquorum.wdmd: add integration script with wdmd
 

On 10/10/2012 6:33 AM, Dietmar Maurer wrote:
> Will you add some documentaion how to use those scripts?

Yes our documentation overlord is preparing an upstream wiki page for
it. It will be ready before a release.

>
> Seems those scripts does not check if the node is joined to the fence domain?
>

It doesn´t really need to.

I´ll put this in the easiest way as possible:

- real fencing == murder
there can only be one killer in the cluster at a time
fence domain coordinates who can/should be killed by who

- checkquorum.wdmd == suicide
there are N nodes in the cluster that can decide to commit suicide
without really caring about what others are doing.
this can run without any fencing configuration at all.

Anyway examples and all, setups, limitations.. all in the doc as soon as
it´s ready. Be a bit patience :)

Fabio

checkquorum.wdmd: add integration script with wdmd
 

> On 10/10/2012 6:26 AM, Dietmar Maurer wrote:
> >> +# rpm based distros
> >> +[ -d /etc/sysconfig ] &&
> >> + [ -f /etc/sysconfig/checkquorum ] &&
> >> + . /etc/sysconfig/checkquorum
> >> +
> >> +# deb based distros
> >> +[ ! -d /etc/sysconfig ] &&
> >> + [ -f /etc/default/checkquorum ] &&
> >> + . /etc/default/checkquorum
> >> +
> >
> > FYI: Some RAID tool vendors delivers utilities for debian which creates
> directory '/etc/sysconfig'
> > on debian boxes, so that test is not reliable.
> >
> >
>
> This might be a controversial argument.

I just though there are better tests to see if you run on debian, for example:

[ -f /etc/debian_version && -d /etc/default ]

checkquorum.wdmd: add integration script with wdmd
 

> Anyway examples and all, setups, limitations.. all in the doc as soon as it´s
> ready. Be a bit patience :)

Ok (I am just curios) - many thanks for you fast answers!

- Dietmar

checkquorum.wdmd: add integration script with wdmd
 

On 10/10/2012 10:06 AM, Dietmar Maurer wrote:
>> On 10/10/2012 6:26 AM, Dietmar Maurer wrote:
>>>> +# rpm based distros
>>>> +[ -d /etc/sysconfig ] &&
>>>> + [ -f /etc/sysconfig/checkquorum ] &&
>>>> + . /etc/sysconfig/checkquorum
>>>> +
>>>> +# deb based distros
>>>> +[ ! -d /etc/sysconfig ] &&
>>>> + [ -f /etc/default/checkquorum ] &&
>>>> + . /etc/default/checkquorum
>>>> +
>>>
>>> FYI: Some RAID tool vendors delivers utilities for debian which creates
>> directory '/etc/sysconfig'
>>> on debian boxes, so that test is not reliable.
>>>
>>>
>>
>> This might be a controversial argument.
>
> I just though there are better tests to see if you run on debian, for example:
>
> [ -f /etc/debian_version && -d /etc/default ]
>

that doesn´t scale well for debian derivates that don´t ship
debian_version :) (see ubuntu & co..)

You can´t even use something like "which dpkg" since the tool is
available on rpm based distributions... or viceversa.. there is rpm for
Debian & derivates.

hardcoding all distributions is not optimal either, as they might change
policy by version....

Fabio

checkquorum.wdmd: add integration script with wdmd
 

> > [ -f /etc/debian_version && -d /etc/default ]
> >
>
> that doesn´t scale well for debian derivates that don´t ship debian_version :)
> (see ubuntu & co..)
>
> You can´t even use something like "which dpkg" since the tool is available on
> rpm based distributions... or viceversa.. there is rpm for Debian & derivates.
>
> hardcoding all distributions is not optimal either, as they might change policy
> by version....

OK, I can see the problem now.

- Dietmar

checkquorum.wdmd: add integration script with wdmd
 

Am 10.10.2012 10:11, schrieb Fabio M. Di Nitto:
> [snip]
> that doesn´t scale well for debian derivates that don´t ship
> debian_version :) (see ubuntu & co..)
>
> You can´t even use something like "which dpkg" since the tool is
> available on rpm based distributions... or viceversa.. there is rpm for
> Debian & derivates.
>
> hardcoding all distributions is not optimal either, as they might change
> policy by version....
>
> Fabio
>

What about 'lsb_release'? Is that executable available on all platforms?

Heiko

checkquorum.wdmd: add integration script with wdmd
 

On 10/10/2012 1:04 PM, Heiko Nardmann wrote:
> Am 10.10.2012 10:11, schrieb Fabio M. Di Nitto:
>> [snip]
>> that doesn´t scale well for debian derivates that don´t ship
>> debian_version :) (see ubuntu & co..)
>>
>> You can´t even use something like "which dpkg" since the tool is
>> available on rpm based distributions... or viceversa.. there is rpm for
>> Debian & derivates.
>>
>> hardcoding all distributions is not optimal either, as they might change
>> policy by version....
>>
>> Fabio
>>
>
> What about 'lsb_release'? Is that executable available on all platforms?


Not installed by default, it´s generally shipped with $distro-lsb
metapackage that pulls in half gazillions dependencies.

I doubt it would solve anything since you still need to parse the
output. It´s really no different than hardcoding /etc/$distro_release,
actually with a few GB of extra packages ;)

Fabio