Mailing List Archive

Hi, guys!

Any reaction, please?


On Tue, Dec 3, 2013 at 12:53 PM, Timur I. Bakeyev <timur@com.bat.ru> wrote:

> Hi, all!
>
> Recent Debian(and Ubuntu?) started to use tmpfs based /run directory for
> the PID files, some of the RA scripts fail to check/store PID files, if
> they been kept in subdirectories of the {/var}/run directory.
>
> By first glance I could spot at least at least named, zabbixserver,
> mysql, mysql-proxy and lxc scripts, which store their PIDs in such
> subdirectories. Also, apache2 may have to deal with that, I'm not sure.
>
> I've raised an issue:
>
> https://github.com/ClusterLabs/resource-agents/issues/351
>
> Maybe corresponding maintainers/interested developers could take a look
> onto that.
>
> As of myself I've experienced failure of the RA named in the Debian wheezy
> environment, so had to patch RA named accordingly:
>
> https://github.com/ClusterLabs/resource-agents/issues/350
>
> Serge, please have a look and comment/commit if appropriate :)
>
> With best regards,
> Timur Bakeyev.
>

On Tue, Dec 17, 2013 at 02:39:52AM +0100, Timur I. Bakeyev wrote:
> Hi, guys!
>
> Any reaction, please?

Probably best to add a helper to ocf-functions, say,
# require_run_dir <mode> user:group path
require_run_dir()
{
local mode=$1 owner=$2 path=$3
local $varrun=@@__varrun_or_whatever_autofoo_calls_it__@@
case $path in
$varrun/*) : nothing ;;
*)
path=$varrun/$path ;;
esac
test -d $path && return 0
[ $(id -u) = 0 ] || return 1

# (or some helper function mkdir_p, in case we doubt -p is available...)
mkdir -p $path && chown $owner $path && chmod $mode $path
}


Then use that early in the various resource agents,
maybe where the defaults are defined.

Yes?

Lars Ellenberg

> > Hi, all!
> >
> > Recent Debian(and Ubuntu?) started to use tmpfs based /run directory for
> > the PID files, some of the RA scripts fail to check/store PID files, if
> > they been kept in subdirectories of the {/var}/run directory.
> >
> > By first glance I could spot at least at least named, zabbixserver,
> > mysql, mysql-proxy and lxc scripts, which store their PIDs in such
> > subdirectories. Also, apache2 may have to deal with that, I'm not sure.
> >
> > I've raised an issue:
> >
> > https://github.com/ClusterLabs/resource-agents/issues/351
> >
> > Maybe corresponding maintainers/interested developers could take a look
> > onto that.
> >
> > As of myself I've experienced failure of the RA named in the Debian wheezy
> > environment, so had to patch RA named accordingly:
> >
> > https://github.com/ClusterLabs/resource-agents/issues/350
> >
> > Serge, please have a look and comment/commit if appropriate :)
> >
> > With best regards,
> > Timur Bakeyev.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Hi, Lars!

On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg
<lars.ellenberg@linbit.com>wrote:

> On Tue, Dec 17, 2013 at 02:39:52AM +0100, Timur I. Bakeyev wrote:
> > Hi, guys!
> >
> > Any reaction, please?
>
> Probably best to add a helper to ocf-functions, say,
> # require_run_dir <mode> user:group path
> require_run_dir()
> {
> local mode=$1 owner=$2 path=$3
> local $varrun=@@__varrun_or_whatever_autofoo_calls_it__@@
> case $path in
> $varrun/*) : nothing ;;
> *)
> path=$varrun/$path ;;
> esac
> test -d $path && return 0
> [ $(id -u) = 0 ] || return 1
>
> # (or some helper function mkdir_p, in case we doubt -p is
> available...)
> mkdir -p $path && chown $owner $path && chmod $mode $path
> }
>
>
> Then use that early in the various resource agents,
> maybe where the defaults are defined.
>
> Yes?
>


That would be even better! There are few more RAs that would benefit from
that.

I'd only invert the parameters, as path is mandatory, permissions are
semi-optional and owner, as in 99% we run as root - optional. And I'd put
some meaningful defaults for the later two parameters:

local path=$1 mode=$2 owner=$3
: ${mode:=0755}
: ${owner:=root}

Also, as 'path' is usually is smth. like '/var/run/named' or
'/var/run/zabbix' I'm afraid that switch will do nothing in any case.

need a bit more magic, smth. like:

if [ -n "${path##$varrun}" ]

or alike.

With best regards,
Timur.

Lars -

I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if it
doesn't present? The goal is to cover the case when /run , or any other
directory, is used instead of /var/run




On Tue, Dec 17, 2013 at 1:48 PM, Timur I. Bakeyev <timur@com.bat.ru> wrote:

> Hi, Lars!
>
> On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg <lars.ellenberg@linbit.com
> > wrote:
>
>> On Tue, Dec 17, 2013 at 02:39:52AM +0100, Timur I. Bakeyev wrote:
>> > Hi, guys!
>> >
>> > Any reaction, please?
>>
>> Probably best to add a helper to ocf-functions, say,
>> # require_run_dir <mode> user:group path
>> require_run_dir()
>> {
>> local mode=$1 owner=$2 path=$3
>> local $varrun=@@__varrun_or_whatever_autofoo_calls_it__@@
>> case $path in
>> $varrun/*) : nothing ;;
>> *)
>> path=$varrun/$path ;;
>> esac
>> test -d $path && return 0
>> [ $(id -u) = 0 ] || return 1
>>
>> # (or some helper function mkdir_p, in case we doubt -p is
>> available...)
>> mkdir -p $path && chown $owner $path && chmod $mode $path
>> }
>>
>>
>> Then use that early in the various resource agents,
>> maybe where the defaults are defined.
>>
>> Yes?
>>
>
>
> That would be even better! There are few more RAs that would benefit from
> that.
>
> I'd only invert the parameters, as path is mandatory, permissions are
> semi-optional and owner, as in 99% we run as root - optional. And I'd put
> some meaningful defaults for the later two parameters:
>
> local path=$1 mode=$2 owner=$3
> : ${mode:=0755}
> : ${owner:=root}
>
> Also, as 'path' is usually is smth. like '/var/run/named' or
> '/var/run/zabbix' I'm afraid that switch will do nothing in any case.
>
> need a bit more magic, smth. like:
>
> if [ -n "${path##$varrun}" ]
>
> or alike.
>
> With best regards,
> Timur.
>
>
>
>
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
>


--
Serge Dubrouski.

On Wed, Dec 18, 2013 at 06:08:44AM -0700, Serge Dubrouski wrote:
> Lars -
>
> I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if it
> doesn't present? The goal is to cover the case when /run , or any other
> directory, is used instead of /var/run


Intention was to not hardcode paths in the resource agents,
when those paths may depend on build-time configuration of the software
they are supposed to control.

You'd only do "require_run_dir httpd",
and that would create /var/run/httpd, /run/httpd/,
/usr/local/whatever-I-told-autofoo-at-build-time/httpd
appropriately.

But in case the prefix is already there, do not double the prefix.

This is to avoid distribution (version) specific resource agents,
or the transition of all resource agents to "*.in".

If that makes sense.

Lars

> On Tue, Dec 17, 2013 at 1:48 PM, Timur I. Bakeyev <timur@com.bat.ru> wrote:
>
> > Hi, Lars!
> >
> > On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg <lars.ellenberg@linbit.com
> > > wrote:
> >
> >> On Tue, Dec 17, 2013 at 02:39:52AM +0100, Timur I. Bakeyev wrote:
> >> > Hi, guys!
> >> >
> >> > Any reaction, please?
> >>
> >> Probably best to add a helper to ocf-functions, say,
> >> # require_run_dir <mode> user:group path
> >> require_run_dir()
> >> {
> >> local mode=$1 owner=$2 path=$3
> >> local $varrun=@@__varrun_or_whatever_autofoo_calls_it__@@
> >> case $path in
> >> $varrun/*) : nothing ;;
> >> *)
> >> path=$varrun/$path ;;
> >> esac
> >> test -d $path && return 0
> >> [ $(id -u) = 0 ] || return 1
> >>
> >> # (or some helper function mkdir_p, in case we doubt -p is
> >> available...)
> >> mkdir -p $path && chown $owner $path && chmod $mode $path
> >> }
> >>
> >>
> >> Then use that early in the various resource agents,
> >> maybe where the defaults are defined.
> >>
> >> Yes?
> >>
> >
> >
> > That would be even better! There are few more RAs that would benefit from
> > that.
> >
> > I'd only invert the parameters, as path is mandatory, permissions are
> > semi-optional and owner, as in 99% we run as root - optional. And I'd put
> > some meaningful defaults for the later two parameters:
> >
> > local path=$1 mode=$2 owner=$3
> > : ${mode:=0755}
> > : ${owner:=root}
> >
> > Also, as 'path' is usually is smth. like '/var/run/named' or
> > '/var/run/zabbix' I'm afraid that switch will do nothing in any case.
> >
> > need a bit more magic, smth. like:
> >
> > if [ -n "${path##$varrun}" ]
> >
> > or alike.
> >
> > With best regards,
> > Timur.
> >
> >
> >
> >
> >
> > _______________________________________________________
> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
> >
> >
>
>
> --
> Serge Dubrouski.

> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/


--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On Wed, Dec 18, 2013 at 2:08 PM, Serge Dubrouski <sergeyfd@gmail.com> wrote:

> Lars -
>
> I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if
> it doesn't present? The goal is to cover the case when /run , or any other
> directory, is used instead of /var/run
>


/run is used instead of /var/run, and /var/run is a symlink to /run. Within
a distribution RUNDIR is, kind of, hardcoded, no matter what is it.

So real question is to distinct usage of the plain RUNDIR and sub-directory
under it, as later one requires some special handling on memory based file
systems.


With regards,
Timur Bakeyev.




> On Tue, Dec 17, 2013 at 1:48 PM, Timur I. Bakeyev <timur@com.bat.ru>wrote:
>
>> Hi, Lars!
>>
>> On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg <
>> lars.ellenberg@linbit.com> wrote:
>>
>>> On Tue, Dec 17, 2013 at 02:39:52AM +0100, Timur I. Bakeyev wrote:
>>> > Hi, guys!
>>> >
>>> > Any reaction, please?
>>>
>>> Probably best to add a helper to ocf-functions, say,
>>> # require_run_dir <mode> user:group path
>>> require_run_dir()
>>> {
>>> local mode=$1 owner=$2 path=$3
>>> local $varrun=@@__varrun_or_whatever_autofoo_calls_it__@@
>>> case $path in
>>> $varrun/*) : nothing ;;
>>> *)
>>> path=$varrun/$path ;;
>>> esac
>>> test -d $path && return 0
>>> [ $(id -u) = 0 ] || return 1
>>>
>>> # (or some helper function mkdir_p, in case we doubt -p is
>>> available...)
>>> mkdir -p $path && chown $owner $path && chmod $mode $path
>>> }
>>>
>>>
>>> Then use that early in the various resource agents,
>>> maybe where the defaults are defined.
>>>
>>> Yes?
>>>
>>
>>
>> That would be even better! There are few more RAs that would benefit from
>> that.
>>
>> I'd only invert the parameters, as path is mandatory, permissions are
>> semi-optional and owner, as in 99% we run as root - optional. And I'd put
>> some meaningful defaults for the later two parameters:
>>
>> local path=$1 mode=$2 owner=$3
>> : ${mode:=0755}
>> : ${owner:=root}
>>
>> Also, as 'path' is usually is smth. like '/var/run/named' or
>> '/var/run/zabbix' I'm afraid that switch will do nothing in any case.
>>
>> need a bit more magic, smth. like:
>>
>> if [ -n "${path##$varrun}" ]
>>
>> or alike.
>>
>> With best regards,
>> Timur.
>>
>>
>>
>>
>>
>> _______________________________________________________
>> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> Home Page: http://linux-ha.org/
>>
>>
>
>
> --
> Serge Dubrouski.
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
>

Hi, Lars!

On Fri, Dec 20, 2013 at 10:25 AM, Lars Ellenberg
<lars.ellenberg@linbit.com>wrote:

> On Wed, Dec 18, 2013 at 06:08:44AM -0700, Serge Dubrouski wrote:
> > Lars -
> >
> > I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if
> it
> > doesn't present? The goal is to cover the case when /run , or any other
> > directory, is used instead of /var/run
>
>
> Intention was to not hardcode paths in the resource agents,
> when those paths may depend on build-time configuration of the software
> they are supposed to control.
>
> You'd only do "require_run_dir httpd",
> and that would create /var/run/httpd, /run/httpd/,
> /usr/local/whatever-I-told-autofoo-at-build-time/httpd
> appropriately.
>
> But in case the prefix is already there, do not double the prefix.
>
> This is to avoid distribution (version) specific resource agents,
> or the transition of all resource agents to "*.in".
>
> If that makes sense.
>


It does make a lot of sense. I just think that case switch wouldn't do what
is intended. Can you comment my previous mail?

With regards,
Timur Bakeyev.



> > On Tue, Dec 17, 2013 at 1:48 PM, Timur I. Bakeyev <timur@com.bat.ru>
> wrote:
> >
> > > Hi, Lars!
> > >
> > > On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg <
> lars.ellenberg@linbit.com
> > > > wrote:
> > >
> > >> On Tue, Dec 17, 2013 at 02:39:52AM +0100, Timur I. Bakeyev wrote:
> > >> > Hi, guys!
> > >> >
> > >> > Any reaction, please?
> > >>
> > >> Probably best to add a helper to ocf-functions, say,
> > >> # require_run_dir <mode> user:group path
> > >> require_run_dir()
> > >> {
> > >> local mode=$1 owner=$2 path=$3
> > >> local $varrun=@@__varrun_or_whatever_autofoo_calls_it__@@
> > >> case $path in
> > >> $varrun/*) : nothing ;;
> > >> *)
> > >> path=$varrun/$path ;;
> > >> esac
> > >> test -d $path && return 0
> > >> [ $(id -u) = 0 ] || return 1
> > >>
> > >> # (or some helper function mkdir_p, in case we doubt -p is
> > >> available...)
> > >> mkdir -p $path && chown $owner $path && chmod $mode $path
> > >> }
> > >>
> > >>
> > >> Then use that early in the various resource agents,
> > >> maybe where the defaults are defined.
> > >>
> > >> Yes?
> > >>
> > >
> > >
> > > That would be even better! There are few more RAs that would benefit
> from
> > > that.
> > >
> > > I'd only invert the parameters, as path is mandatory, permissions are
> > > semi-optional and owner, as in 99% we run as root - optional. And I'd
> put
> > > some meaningful defaults for the later two parameters:
> > >
> > > local path=$1 mode=$2 owner=$3
> > > : ${mode:=0755}
> > > : ${owner:=root}
> > >
> > > Also, as 'path' is usually is smth. like '/var/run/named' or
> > > '/var/run/zabbix' I'm afraid that switch will do nothing in any case.
> > >
> > > need a bit more magic, smth. like:
> > >
> > > if [ -n "${path##$varrun}" ]
> > >
> > > or alike.
> > >
> > > With best regards,
> > > Timur.
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________________
> > > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > > Home Page: http://linux-ha.org/
> > >
> > >
> >
> >
> > --
> > Serge Dubrouski.
>
> > _______________________________________________________
> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
>
>
> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
>
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>

On Fri, Dec 20, 2013 at 12:20:26PM +0100, Timur I. Bakeyev wrote:
> On Wed, Dec 18, 2013 at 2:08 PM, Serge Dubrouski <sergeyfd@gmail.com> wrote:
>
> > Lars -
> >
> > I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if
> > it doesn't present? The goal is to cover the case when /run , or any other
> > directory, is used instead of /var/run

Ignore for a moment that I used the variable name "varrun".

> /run is used instead of /var/run, and /var/run is a symlink to /run. Within
> a distribution RUNDIR is, kind of, hardcoded, no matter what is it.

That's why I used the @@__autofoo_notation__@@ and I'm too lazy to look
up what the correct name between @@ @@ would be; last time I checked,
people where still discussing --rundir, --varrundir, --runstatedir and
others.

Anyways, that's supposed to be the "distribution wide hardcoded default",
and that would be replaced by autofoo/configure at build time of this
package.

I think we have it already in ocf-directories.in as
: ${HA_VARRUN:=@localstatedir@/run/}
and we probably should change that to
: ${HA_RUNSTATEDIR:=@runstatedir@}
(or HA_RUNDIR:=@rundir@; whatever will be the proper autofoo name for it)
and keep the alias
HA_VARRUN=$HA_RUNSTATEDIR

And now, assume that this variable, despite the name,
has a value of /run on those distributions that use /run,
and /var/run on those that use that,
and $home/var/run or $prefix/var/run when people install locally
(not that that'd make much sense for resoruce-agents...)


Ok?

> So real question is to distinct usage of the plain RUNDIR and sub-directory
> under it, as later one requires some special handling on memory based file
> systems.
>
>
> With regards,
> Timur Bakeyev.
>
>
>
>
> > On Tue, Dec 17, 2013 at 1:48 PM, Timur I. Bakeyev <timur@com.bat.ru>wrote:
> >
> >> Hi, Lars!
> >>
> >> On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg <
> >> lars.ellenberg@linbit.com> wrote:
> >>
> >>> On Tue, Dec 17, 2013 at 02:39:52AM +0100, Timur I. Bakeyev wrote:
> >>> > Hi, guys!
> >>> >
> >>> > Any reaction, please?
> >>>
> >>> Probably best to add a helper to ocf-functions, say,
> >>> # require_run_dir <mode> user:group path
> >>> require_run_dir()
> >>> {
> >>> local mode=$1 owner=$2 path=$3
> >>> local $varrun=@@__varrun_or_whatever_autofoo_calls_it__@@
> >>> case $path in
> >>> $varrun/*) : nothing ;;
> >>> *)
> >>> path=$varrun/$path ;;
> >>> esac
> >>> test -d $path && return 0
> >>> [ $(id -u) = 0 ] || return 1
> >>>
> >>> # (or some helper function mkdir_p, in case we doubt -p is
> >>> available...)
> >>> mkdir -p $path && chown $owner $path && chmod $mode $path
> >>> }
> >>>
> >>>
> >>> Then use that early in the various resource agents,
> >>> maybe where the defaults are defined.
> >>>
> >>> Yes?
> >>>
> >>
> >>
> >> That would be even better! There are few more RAs that would benefit from
> >> that.
> >>
> >> I'd only invert the parameters, as path is mandatory, permissions are
> >> semi-optional and owner, as in 99% we run as root - optional. And I'd put
> >> some meaningful defaults for the later two parameters:
> >>
> >> local path=$1 mode=$2 owner=$3
> >> : ${mode:=0755}
> >> : ${owner:=root}
> >>
> >> Also, as 'path' is usually is smth. like '/var/run/named' or
> >> '/var/run/zabbix' I'm afraid that switch will do nothing in any case.
> >>
> >> need a bit more magic, smth. like:
> >>
> >> if [ -n "${path##$varrun}" ]
> >>
> >> or alike.
> >>
> >> With best regards,
> >> Timur.
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________________
> >> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >> Home Page: http://linux-ha.org/
> >>
> >>
> >
> >
> > --
> > Serge Dubrouski.
> >
> > _______________________________________________________
> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
> >
> >

> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/


--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/