Re: [ClusterLabs] ocf scripts shell and local variables

[Dimitri Maziuk]

On 09/01/2016 10:12 AM, Dejan Muhamedagic wrote:

> There is no other way to tell the UNIX/Linux system which
> interpreter to use. Or am I missing something?

Yes: I'm not talking about how it works, I'm talking about how it
doesn't. You can tell the system which interpreter to use, but the
system doesn't have to listen.

So e.g. whoever suggested (Lars?) that on non-Linux platforms you sed
all the shebang lines to /usr/bin/bash or whatever -- that's not
guaranteed to work.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dejan Muhamedagic]

On Wed, Aug 31, 2016 at 10:39:22AM -0500, Dmitri Maziuk wrote:
> On 2016-08-31 03:59, Dejan Muhamedagic wrote:
> >On Tue, Aug 30, 2016 at 12:32:36PM -0500, Dimitri Maziuk wrote:
> 
> >>I expect you're being deliberately obtuse.
> >
> >Not sure why do you think that
> 
> Because the point I was trying to make was that having shebang line say
> #!/opt/swf/bin/bash
> does not guarantee the script will actually be interpreted by
> /opt/swf/bin/bash. For example
> 
> >When a file is sourced, the "#!" line has no special meaning
> >(apart from documenting purposes).
> 
> (sic) Or when
> 
> >I haven't read the code either, but it must be some of the
> >exec(2) system calls.
> 
> it's execl("/bin/sh", "/bin/sh", "/script/file") instead of execl(
> "script/file', ...) directly.
> 
> (As an aside, I suspect the feature where exec(2) will run the loader which
> will read the magic and load an appropriate binfmt* kernel module, may well
> also be portable between "most" systems, just like "local" is portable to
> "most" shell. I don't think posix specifies anything more than "executable
> image" and that on a strictly posix-compliant system execl( "/my/script.sh",
> ... ) will fail. I am so old that I have a vague recollection it *had to be*
> execl("/bin/sh", "/bin/sh", "/script/file") back when I learned it. But this
> going even further OT.)
> 
> My point, again, was that solutions involving shebang lines are great as
> long as you can guarantee those shebang lines are being used on all
> supported platforms at all times.

There is no other way to tell the UNIX/Linux system which
interpreter to use. Or am I missing something?

> Sourcing findif.sh from IPAddr2 is proof
> by counter-example that they aren't and you can't.

findif.sh or any other file which is to be sourced therefore
must be compatible with the greatest common denominator
(shellwise).

Thanks,

Dejan

> Dima
> 
> 
> ___
> Users mailing list: Users@clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Lars Ellenberg]

On Wed, Aug 31, 2016 at 12:29:59PM +0200, Dejan Muhamedagic wrote:
> > Also remember that sometimes we set a "local" variable in a function
> > and expect it to be visible in nested functions, but also set a new
> > value in a nested function and expect that value to be reflected
> > in the outer scope (up to the last "local").
> 
> I hope that this wasn't (ab)used much, it doesn't sound like it
> would be easy to follow.
> 
> > diff --git a/heartbeat/ocf-shellfuncs.in b/heartbeat/ocf-shellfuncs.in
> > index 6d9669d..4151630 100644
> > --- a/heartbeat/ocf-shellfuncs.in
> > +++ b/heartbeat/ocf-shellfuncs.in
> > @@ -920,3 +920,37 @@ ocf_is_true "$OCF_TRACE_RA" && ocf_start_trace
> >  if ocf_is_true "$HA_use_logd"; then
> > : ${HA_LOGD:=yes}
> >  fi
> > +
> > +# We use a lot of function local variables with the "local" keyword.
> > +# Which works fine with dash and bash,
> > +# but does not work with e.g. ksh.
> > +# Fail cleanly with a sane error message,
> > +# if the current shell does not feel compatible.
> > +
> > +__ocf_check_for_incompatible_shell_l2()
> > +{
> > +   [ $__ocf_check_for_incompatible_shell_k = v1 ] || return 1
> > +   local __ocf_check_for_incompatible_shell_k=v2
> > +   [ $__ocf_check_for_incompatible_shell_k = v2 ] || return 1
> > +   return 0
> > +}
> > +
> > +__ocf_check_for_incompatible_shell_l1()
> > +{
> > +   [ $__ocf_check_for_incompatible_shell_k = v0 ] || return 1
> 
> If there's no "local" and that in the function below fails, won't
> this produce a syntax error (due to __ocf_..._k being undefined)?

Which is ok with me, still return 1 ;-)

> > +   local __ocf_check_for_incompatible_shell_k=v1
> > +   __ocf_check_for_incompatible_shell_l2

This ^^ needs to be:
> > +   __ocf_check_for_incompatible_shell_l2 || return 1

> > +   [ $__ocf_check_for_incompatible_shell_k = v1 ] || return 1
> > +   return 0
> > +}
> > +
> > +__ocf_check_for_incompatible_shell()
> > +{
> > +   local __ocf_check_for_incompatible_shell_k=v0

Similarly, this:
> > +   __ocf_check_for_incompatible_shell_l1

should be
> > +   __ocf_check_for_incompatible_shell_l1 || return 1

> > +   [ $__ocf_check_for_incompatible_shell_k = v0 ] && return 0
> > +   ocf_exit_reason "Current shell seems to be incompatible. We suggest 
> > dash or bash (compatible)."
> > +   exit $OCF_ERR_GENERIC
> > +}
> > +
> > +__ocf_check_for_incompatible_shell
> 
> Looks good otherwise. If somebody's willing to test it on
> solaris...

There is a ksh93 for linux as well, and it appears to be very similar to
the one apparenly shipped with solaris. But yes, you are right ;-)

Lars


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dejan Muhamedagic]

On Tue, Aug 30, 2016 at 06:53:24PM +0200, Lars Ellenberg wrote:
> On Tue, Aug 30, 2016 at 06:15:49PM +0200, Dejan Muhamedagic wrote:
> > On Tue, Aug 30, 2016 at 10:08:00AM -0500, Dmitri Maziuk wrote:
> > > On 2016-08-30 03:44, Dejan Muhamedagic wrote:
> > > 
> > > >The kernel reads the shebang line and it is what defines the
> > > >interpreter which is to be invoked to run the script.
> > > 
> > > Yes, and does the kernel read when the script is source'd or executed via
> > > any of the mechanisms that have the executable specified in the call,
> > > explicitly or implicitly?
> > 
> > I suppose that it is explained in enough detail here:
> > 
> > https://en.wikipedia.org/wiki/Shebang_(Unix)
> > 
> > In particular:
> > 
> > https://en.wikipedia.org/wiki/Shebang_(Unix)#Magic_number
> > 
> > > >None of /bin/sh RA requires bash.
> > > 
> > > Yeah, only "local".
> > 
> > As already mentioned elsewhere in the thread, local is supported
> > in most shell implementations and without it we otherwise
> > wouldn't to be able to maintain software. Not sure where local
> > originates, but wouldn't bet that it's bash.
> 
> Let's just agree that as currently implemented,
> our collection of /bin/sh scripts won't run on ksh as shipped with
> solaris (while there likely are ksh derivatives in *BSD somewhere
> that would be mostly fine with them).

I can recall people running some of the BSD systems and they
didn't complain about resource-agents.

> And before this turns even more into a "yes, I'm that old, too" thread,

I guess that is in human nature.

> may I suggest to document that we expect a
> "dash compatible" /bin/sh, and that we expect scripts
> to have a bash shebang (or as appropriate) if they go beyond that.

That is how it has been in resource-agents: POSIX compatible with
the addition of "local". Anyway, every script must have a #! line
which states the right interpreter.

> Then check for incompatible shells in ocf-shellfuncs,
> and just exit early if we detect incompatibilities.
> 
> For a suggestion on checking for a proper "local" see below.
> (Add more checks later, if someone feels like it.)
> 
> Though, if someone rewrites not the current agents, but the "lib/ocf*"
> help stuff to be sourced by shell based agents in a way that would
> support RAs in all bash, dash, ash, ksh, whatever,
> and the result turns out not too much worse than what we have now,
> I'd have no problem with that...
> 
> Cheers,
> 
> Lars
> 
> 
> And for the "typeset" crowd,
> if you think s/local/typeset/ was all that was necessary
> to support function local variables in ksh, think again:
> 
> ksh -c '
>   function a {
>   echo "start of a: x=$x"
>   typeset x=a
>   echo "before b: x=$x"
>   b
>   echo "end of a: x=$x"
>   }
>   function b {
>   echo "start of b: x=$x ### HAHA guess this one was unexpected 
> to all but ksh users"
>   typeset x=b
>   echo "end of b: x=$x"
>   }
>   x=x
>   echo "before a: x=$x"
>   a
>   echo "after a: x=$x"
> '
> 
> Try the same with bash.

:)

> Also remember that sometimes we set a "local" variable in a function
> and expect it to be visible in nested functions, but also set a new
> value in a nested function and expect that value to be reflected
> in the outer scope (up to the last "local").

I hope that this wasn't (ab)used much, it doesn't sound like it
would be easy to follow.

> diff --git a/heartbeat/ocf-shellfuncs.in b/heartbeat/ocf-shellfuncs.in
> index 6d9669d..4151630 100644
> --- a/heartbeat/ocf-shellfuncs.in
> +++ b/heartbeat/ocf-shellfuncs.in
> @@ -920,3 +920,37 @@ ocf_is_true "$OCF_TRACE_RA" && ocf_start_trace
>  if ocf_is_true "$HA_use_logd"; then
>   : ${HA_LOGD:=yes}
>  fi
> +
> +# We use a lot of function local variables with the "local" keyword.
> +# Which works fine with dash and bash,
> +# but does not work with e.g. ksh.
> +# Fail cleanly with a sane error message,
> +# if the current shell does not feel compatible.
> +
> +__ocf_check_for_incompatible_shell_l2()
> +{
> + [ $__ocf_check_for_incompatible_shell_k = v1 ] || return 1
> + local __ocf_check_for_incompatible_shell_k=v2
> + [ $__ocf_check_for_incompatible_shell_k = v2 ] || return 1
> + return 0
> +}
> +
> +__ocf_check_for_incompatible_shell_l1()
> +{
> + [ $__ocf_check_for_incompatible_shell_k = v0 ] || return 1

If there's no "local" and that in the function below fails, won't
this produce a syntax error (due to __ocf_..._k being undefined)?

> + local __ocf_check_for_incompatible_shell_k=v1
> + __ocf_check_for_incompatible_shell_l2
> + [ $__ocf_check_for_incompatible_shell_k = v1 ] || return 1
> + return 0
> +}
> +
> +__ocf_check_for_incompatible_shell()
> +{
> + local __ocf_check_for_incompatible_shell_k=v0
> + __ocf_check_for_incompatible_shell_l1
> + [ $__ocf_check_for_incompatible_shell_k = v0 ] && return 0
> + 

Re: [ClusterLabs] ocf scripts shell and local variables

[Dejan Muhamedagic]

On Tue, Aug 30, 2016 at 12:32:36PM -0500, Dimitri Maziuk wrote:
> On 08/30/2016 11:15 AM, Dejan Muhamedagic wrote:
> 
> > I suppose that it is explained in enough detail here:
> > 
> > https://en.wikipedia.org/wiki/Shebang_(Unix)
> 
> I expect you're being deliberately obtuse.

Not sure why do you think that when I offer a perfectly good
document on how "#!" line is interpreted.

> It does not explain which program loader interprets line 1 of findif.sh:
> "#!/bin/sh" when it is invoked from line 69 of IPAddr2 RA:
> 
> . ${OCF_FUNCTIONS_DIR}/findif.sh

When a file is sourced, the "#!" line has no special meaning
(apart from documenting purposes).

> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/IPaddr2
> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/findif.sh
> 
> Similarly, I have not read the code so I don't know who invokes IPArrd2
> and how exactly they do it. If you tell me it makes the kernel look at
> the magic number and spawn whatever shell's specified there, I believe you.

I haven't read the code either, but it must be some of the
exec(2) system calls.

> > As already mentioned elsewhere in the thread, local is supported
> > in most shell implementations and without it we otherwise
> > wouldn't to be able to maintain software. Not sure where local
> > originates, but wouldn't bet that it's bash.
> 
> Well 2 out of 3 is "most", can't argue with that.

There are certainly more than 3.

Thanks,

Dejan

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dimitri Maziuk]

On 08/30/2016 11:15 AM, Dejan Muhamedagic wrote:

> I suppose that it is explained in enough detail here:
> 
> https://en.wikipedia.org/wiki/Shebang_(Unix)

I expect you're being deliberately obtuse.

It does not explain which program loader interprets line 1 of findif.sh:
"#!/bin/sh" when it is invoked from line 69 of IPAddr2 RA:

. ${OCF_FUNCTIONS_DIR}/findif.sh

https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/IPaddr2
https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/findif.sh

Similarly, I have not read the code so I don't know who invokes IPArrd2
and how exactly they do it. If you tell me it makes the kernel look at
the magic number and spawn whatever shell's specified there, I believe you.

> As already mentioned elsewhere in the thread, local is supported
> in most shell implementations and without it we otherwise
> wouldn't to be able to maintain software. Not sure where local
> originates, but wouldn't bet that it's bash.

Well 2 out of 3 is "most", can't argue with that.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Lars Ellenberg]

On Tue, Aug 30, 2016 at 06:15:49PM +0200, Dejan Muhamedagic wrote:
> On Tue, Aug 30, 2016 at 10:08:00AM -0500, Dmitri Maziuk wrote:
> > On 2016-08-30 03:44, Dejan Muhamedagic wrote:
> > 
> > >The kernel reads the shebang line and it is what defines the
> > >interpreter which is to be invoked to run the script.
> > 
> > Yes, and does the kernel read when the script is source'd or executed via
> > any of the mechanisms that have the executable specified in the call,
> > explicitly or implicitly?
> 
> I suppose that it is explained in enough detail here:
> 
> https://en.wikipedia.org/wiki/Shebang_(Unix)
> 
> In particular:
> 
> https://en.wikipedia.org/wiki/Shebang_(Unix)#Magic_number
> 
> > >None of /bin/sh RA requires bash.
> > 
> > Yeah, only "local".
> 
> As already mentioned elsewhere in the thread, local is supported
> in most shell implementations and without it we otherwise
> wouldn't to be able to maintain software. Not sure where local
> originates, but wouldn't bet that it's bash.

Let's just agree that as currently implemented,
our collection of /bin/sh scripts won't run on ksh as shipped with
solaris (while there likely are ksh derivatives in *BSD somewhere
that would be mostly fine with them).

And before this turns even more into a "yes, I'm that old, too" thread,
may I suggest to document that we expect a
"dash compatible" /bin/sh, and that we expect scripts
to have a bash shebang (or as appropriate) if they go beyond that.

Then check for incompatible shells in ocf-shellfuncs,
and just exit early if we detect incompatibilities.

For a suggestion on checking for a proper "local" see below.
(Add more checks later, if someone feels like it.)

Though, if someone rewrites not the current agents, but the "lib/ocf*"
help stuff to be sourced by shell based agents in a way that would
support RAs in all bash, dash, ash, ksh, whatever,
and the result turns out not too much worse than what we have now,
I'd have no problem with that...

Cheers,

Lars


And for the "typeset" crowd,
if you think s/local/typeset/ was all that was necessary
to support function local variables in ksh, think again:

ksh -c '
function a {
echo "start of a: x=$x"
typeset x=a
echo "before b: x=$x"
b
echo "end of a: x=$x"
}
function b {
echo "start of b: x=$x ### HAHA guess this one was unexpected 
to all but ksh users"
typeset x=b
echo "end of b: x=$x"
}
x=x
echo "before a: x=$x"
a
echo "after a: x=$x"
'

Try the same with bash.
Also remember that sometimes we set a "local" variable in a function
and expect it to be visible in nested functions, but also set a new
value in a nested function and expect that value to be reflected
in the outer scope (up to the last "local").




diff --git a/heartbeat/ocf-shellfuncs.in b/heartbeat/ocf-shellfuncs.in
index 6d9669d..4151630 100644
--- a/heartbeat/ocf-shellfuncs.in
+++ b/heartbeat/ocf-shellfuncs.in
@@ -920,3 +920,37 @@ ocf_is_true "$OCF_TRACE_RA" && ocf_start_trace
 if ocf_is_true "$HA_use_logd"; then
: ${HA_LOGD:=yes}
 fi
+
+# We use a lot of function local variables with the "local" keyword.
+# Which works fine with dash and bash,
+# but does not work with e.g. ksh.
+# Fail cleanly with a sane error message,
+# if the current shell does not feel compatible.
+
+__ocf_check_for_incompatible_shell_l2()
+{
+   [ $__ocf_check_for_incompatible_shell_k = v1 ] || return 1
+   local __ocf_check_for_incompatible_shell_k=v2
+   [ $__ocf_check_for_incompatible_shell_k = v2 ] || return 1
+   return 0
+}
+
+__ocf_check_for_incompatible_shell_l1()
+{
+   [ $__ocf_check_for_incompatible_shell_k = v0 ] || return 1
+   local __ocf_check_for_incompatible_shell_k=v1
+   __ocf_check_for_incompatible_shell_l2
+   [ $__ocf_check_for_incompatible_shell_k = v1 ] || return 1
+   return 0
+}
+
+__ocf_check_for_incompatible_shell()
+{
+   local __ocf_check_for_incompatible_shell_k=v0
+   __ocf_check_for_incompatible_shell_l1
+   [ $__ocf_check_for_incompatible_shell_k = v0 ] && return 0
+   ocf_exit_reason "Current shell seems to be incompatible. We suggest 
dash or bash (compatible)."
+   exit $OCF_ERR_GENERIC
+}
+
+__ocf_check_for_incompatible_shell


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dejan Muhamedagic]

On Tue, Aug 30, 2016 at 10:08:00AM -0500, Dmitri Maziuk wrote:
> On 2016-08-30 03:44, Dejan Muhamedagic wrote:
> 
> >The kernel reads the shebang line and it is what defines the
> >interpreter which is to be invoked to run the script.
> 
> Yes, and does the kernel read when the script is source'd or executed via
> any of the mechanisms that have the executable specified in the call,
> explicitly or implicitly?

I suppose that it is explained in enough detail here:

https://en.wikipedia.org/wiki/Shebang_(Unix)

In particular:

https://en.wikipedia.org/wiki/Shebang_(Unix)#Magic_number

> >None of /bin/sh RA requires bash.
> 
> Yeah, only "local".

As already mentioned elsewhere in the thread, local is supported
in most shell implementations and without it we otherwise
wouldn't to be able to maintain software. Not sure where local
originates, but wouldn't bet that it's bash.

Thanks,

Dejan

> Dima
> 
> 
> ___
> Users mailing list: Users@clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dmitri Maziuk]

On 2016-08-30 03:44, Dejan Muhamedagic wrote:


The kernel reads the shebang line and it is what defines the
interpreter which is to be invoked to run the script.


Yes, and does the kernel read when the script is source'd or executed 
via any of the mechanisms that have the executable specified in the 
call, explicitly or implicitly?



None of /bin/sh RA requires bash.


Yeah, only "local".

Dima


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Gabriele Bulfon]

illumos (and Solaris 11) delivers ksh93, that is fully Bourn compatible, but 
not with the bash extension of "local" variables, that is not Bourn shell. It 
is supported in ksh93 with the "typedef" operator, instead of "local".
This is used inside the "ocf-*" scripts.
Gabriele

Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Dejan Muhamedagic
A: gbul...@sonicle.com Cluster Labs - All topics related to open-source 
clustering welcomed
Data: 30 agosto 2016 12.20.19 CEST
Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
Hi,
On Mon, Aug 29, 2016 at 05:08:35PM +0200, Gabriele Bulfon wrote:
Sure, infact I can change all shebang to point to /bin/bash and it's ok.
The question is about current shebang /bin/sh which may go into trouble (as if 
one would point to a generic python but uses many specific features of a 
version of python).
Also, the question is about bash being a good option for RAs, being much more 
heavy.
I'd really suggest installing a smaller shell such as /bin/dash
and using that as /bin/sh. Isn't there a Bourne shell in Solaris?
If you modify the RAs it could be trouble on subsequent updates.
Thanks,
Dejan
Gabriele

Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Dejan Muhamedagic
A: kgail...@redhat.com Cluster Labs - All topics related to open-source 
clustering welcomed
Data: 29 agosto 2016 16.43.52 CEST
Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
Hi,
On Mon, Aug 29, 2016 at 08:47:43AM -0500, Ken Gaillot wrote:
On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:
Hi Ken,
I have been talking with the illumos guys about the shell problem.
They all agreed that ksh (and specially the ksh93 used in illumos) is
absolutely Bourne-compatible, and that the "local" variables used in the
ocf shells is not a Bourne syntax, but probably a bash specific.
This means that pointing the scripts to "#!/bin/sh" is portable as long
as the scripts are really Bourne-shell only syntax, as any Unix variant
may link whatever Bourne-shell they like.
In this case, it should point to "#!/bin/bash" or whatever shell the
script was written for.
Also, in this case, the starting point is not the ocf-* script, but the
original RA (IPaddr, but almost all of them).
What about making the code base of RA and ocf-* portable?
It may be just by changing them to point to bash, or with some kind of
configure modifier to be able to specify the shell to use.
Meanwhile, changing the scripts by hands into #!/bin/bash worked like a
charm, and I will start patching.
Gabriele
Interesting, I thought local was posix, but it's not. It seems everyone
but solaris implemented it:
http://stackoverflow.com/questions/18597697/posix-compliant-way-to-scope-variables-to-a-function-in-a-shell-script
Please open an issue at:
https://github.com/ClusterLabs/resource-agents/issues
The simplest solution would be to require #!/bin/bash for all RAs that
use local,
This issue was raised many times, but note that /bin/bash is a
shell not famous for being lean: it's great for interactive use,
but not so great if you need to run a number of scripts. The
complexity in bash, which is superfluous for our use case,
doesn't go well with the basic principles of HA clusters.
but I'm not sure that's fair to the distros that support
local in a non-bash default shell. Another possibility would be to
modify all RAs to avoid local entirely, by using unique variable
prefixes per function.
I doubt that we could do a moderately complex shell scripts
without capability of limiting the variables' scope and retaining
sanity at the same time.
Or, it may be possible to guard every instance of
local with a check for ksh, which would use typeset instead. Raising the
issue will allow some discussion of the possibilities.
Just to mention that this is the first time someone reported
running a shell which doesn't support local. Perhaps there's an
option that they install a shell which does.
Thanks,
Dejan

*Sonicle S.r.l. *: http://www.sonicle.com
*Music: *http://www.gabrielebulfon.com
*Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Ken Gaillot
A: gbul...@sonicle.com Cluster Labs - All topics related to open-source
clustering welcomed
Data: 26 agosto 2016 15.56.02 CEST
Oggetto: Re: ocf scr

Re: [ClusterLabs] ocf scripts shell and local variables

[Gabriele Bulfon]

Not RA, but ocf-* do, because of the "local" operator usage.

Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Dejan Muhamedagic
A: Cluster Labs - All topics related to open-source clustering welcomed
Data: 30 agosto 2016 10.44.49 CEST
Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
Hi,
On Mon, Aug 29, 2016 at 10:13:18AM -0500, Dmitri Maziuk wrote:
On 2016-08-29 04:06, Gabriele Bulfon wrote:
Thanks, though this does not work :)
Uhm... right. Too many languages, sorry: perl's system() will call the login
shell, system system() uses /bin/sh, and exec()s will run whatever the
programmer tells them to. The point is none of them cares what shell's in
shebang line AFAIK.
The kernel reads the shebang line and it is what defines the
interpreter which is to be invoked to run the script.
But anyway, you're correct; a lot of linux "shell" scripts are bash-only and
pacemaker RAs are no exception.
None of /bin/sh RA requires bash.
Thanks,
Dejan
Dima
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dejan Muhamedagic]

Hi,

On Mon, Aug 29, 2016 at 05:08:35PM +0200, Gabriele Bulfon wrote:
> Sure, infact I can change all shebang to point to /bin/bash and it's ok.
> The question is about current shebang /bin/sh which may go into trouble (as 
> if one would point to a generic python but uses many specific features of a 
> version of python).
> Also, the question is about bash being a good option for RAs, being much more 
> heavy.

I'd really suggest installing a smaller shell such as /bin/dash
and using that as /bin/sh. Isn't there a Bourne shell in Solaris?
If you modify the RAs it could be trouble on subsequent updates.

Thanks,

Dejan

> Gabriele
> 
> Sonicle S.r.l.
> :
> http://www.sonicle.com
> Music:
> http://www.gabrielebulfon.com
> Quantum Mechanics :
> http://www.cdbaby.com/cd/gabrielebulfon
> --
> Da: Dejan Muhamedagic
> A: kgail...@redhat.com Cluster Labs - All topics related to open-source 
> clustering welcomed
> Data: 29 agosto 2016 16.43.52 CEST
> Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
> Hi,
> On Mon, Aug 29, 2016 at 08:47:43AM -0500, Ken Gaillot wrote:
> On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:
> Hi Ken,
> I have been talking with the illumos guys about the shell problem.
> They all agreed that ksh (and specially the ksh93 used in illumos) is
> absolutely Bourne-compatible, and that the "local" variables used in the
> ocf shells is not a Bourne syntax, but probably a bash specific.
> This means that pointing the scripts to "#!/bin/sh" is portable as long
> as the scripts are really Bourne-shell only syntax, as any Unix variant
> may link whatever Bourne-shell they like.
> In this case, it should point to "#!/bin/bash" or whatever shell the
> script was written for.
> Also, in this case, the starting point is not the ocf-* script, but the
> original RA (IPaddr, but almost all of them).
> What about making the code base of RA and ocf-* portable?
> It may be just by changing them to point to bash, or with some kind of
> configure modifier to be able to specify the shell to use.
> Meanwhile, changing the scripts by hands into #!/bin/bash worked like a
> charm, and I will start patching.
> Gabriele
> Interesting, I thought local was posix, but it's not. It seems everyone
> but solaris implemented it:
> http://stackoverflow.com/questions/18597697/posix-compliant-way-to-scope-variables-to-a-function-in-a-shell-script
> Please open an issue at:
> https://github.com/ClusterLabs/resource-agents/issues
> The simplest solution would be to require #!/bin/bash for all RAs that
> use local,
> This issue was raised many times, but note that /bin/bash is a
> shell not famous for being lean: it's great for interactive use,
> but not so great if you need to run a number of scripts. The
> complexity in bash, which is superfluous for our use case,
> doesn't go well with the basic principles of HA clusters.
> but I'm not sure that's fair to the distros that support
> local in a non-bash default shell. Another possibility would be to
> modify all RAs to avoid local entirely, by using unique variable
> prefixes per function.
> I doubt that we could do a moderately complex shell scripts
> without capability of limiting the variables' scope and retaining
> sanity at the same time.
> Or, it may be possible to guard every instance of
> local with a check for ksh, which would use typeset instead. Raising the
> issue will allow some discussion of the possibilities.
> Just to mention that this is the first time someone reported
> running a shell which doesn't support local. Perhaps there's an
> option that they install a shell which does.
> Thanks,
> Dejan
> 
> *Sonicle S.r.l. *: http://www.sonicle.com
> *Music: *http://www.gabrielebulfon.com
> *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
> --
> Da: Ken Gaillot
> A: gbul...@sonicle.com Cluster Labs - All topics related to open-source
> clustering welcomed
> Data: 26 agosto 2016 15.56.02 CEST
> Oggetto: Re: ocf scripts shell and local variables
> On 08/26/2016 08:11 AM, Gabriele Bulfon wrote:
> I tried adding some debug in ocf-shellfuncs, showing env and ps
> -ef into
> the corosync.log
> I suspect it's always using ksh, because in the env output I
> produced I
> find this: KSH_VERSION=.sh.version
> This is normally not present in the environment, unless ksh is running
> the shell.
> The RAs typically start with #!/bin

Re: [ClusterLabs] ocf scripts shell and local variables

[Dejan Muhamedagic]

Hi,

On Mon, Aug 29, 2016 at 10:13:18AM -0500, Dmitri Maziuk wrote:
> On 2016-08-29 04:06, Gabriele Bulfon wrote:
> >Thanks, though this does not work :)
> 
> Uhm... right. Too many languages, sorry: perl's system() will call the login
> shell, system system() uses /bin/sh, and exec()s will run whatever the
> programmer tells them to. The point is none of them cares what shell's in
> shebang line AFAIK.

The kernel reads the shebang line and it is what defines the
interpreter which is to be invoked to run the script.

> But anyway, you're correct; a lot of linux "shell" scripts are bash-only and
> pacemaker RAs are no exception.

None of /bin/sh RA requires bash.

Thanks,

Dejan

> 
> Dima
> 
> 
> ___
> Users mailing list: Users@clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dejan Muhamedagic]

Hi,

On Tue, Aug 30, 2016 at 09:32:54AM +0200, Kristoffer Grönlund wrote:
> Jehan-Guillaume de Rorthais  writes:
> 
> > On Mon, 29 Aug 2016 10:02:28 -0500
> > Ken Gaillot  wrote:
> >
> >> On 08/29/2016 09:43 AM, Dejan Muhamedagic wrote:
> > ...
> >>> I doubt that we could do a moderately complex shell scripts
> >>> without capability of limiting the variables' scope and retaining
> >>> sanity at the same time.
> >> 
> >> This prefixing approach would definitely be ugly, and it would violate
> >> best practices on shells that do support local, but it should be feasible.
> >> 
> >> I'd argue that anything moderately complex should be converted to python
> >> (maybe after we have OCF 2.0, and some good python bindings ...).
> >
> > For what it worth, I already raised this discussion some month ago as we 
> > wrote
> > some perl modules equivalent to ocf-shellfuncs, ocf-returncodes and
> > ocf-directories. See: 
> >
> >   Subject: [ClusterLabs Developers] Perl Modules for resource agents (was:
> > Resource Agent language discussion) 
> >   Date: Thu, 26 Nov 2015 01:13:36 +0100
> >
> > I don't want to start a flameware about languages here, this is not about 
> > that.
> > Maybe it would be a good time to include various libraries for different
> > languages in official source? At least for ocf-directories which is quite
> > simple, but often tied to the configure options in various distro. We had to
> > make a ugly wrapper around the ocf-directories librairie on build time to
> > produce our OCF_Directories.pm module on various distros.
> >
> 
> I don't know Perl so I can't be very helpful reviewing it, but please do
> submit your Perl OCF library to resource-agents if you have one! I don't
> think anyone is opposed to including a Perl (or Python) API on
> principle, it's just a matter of someone actually sitting down to do the
> work putting it together.

Sure, I doubt that anybody would oppose that. Looking at the
amount of the existing supporting code, it is not going to be a
small feat.

***

This is off-topic and I really do hope not to start a discussion
about it so I'll keep it short: I often heard shell programming
being bashed up to the point that it should be banned. While it
is true that there are numerous scripts executed in a way leaving
much to be desired, the opposite is certainly possible too. Shell
does fit well a certain type of task and resource agents
(essentially more robust init scripts) belong to that realm.

Thanks,

Dejan


> Cheers,
> Kristoffer
> 
> -- 
> // Kristoffer Grönlund
> // kgronl...@suse.com
> 
> ___
> Users mailing list: Users@clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Kristoffer Grönlund]

Jehan-Guillaume de Rorthais  writes:

> On Mon, 29 Aug 2016 10:02:28 -0500
> Ken Gaillot  wrote:
>
>> On 08/29/2016 09:43 AM, Dejan Muhamedagic wrote:
> ...
>>> I doubt that we could do a moderately complex shell scripts
>>> without capability of limiting the variables' scope and retaining
>>> sanity at the same time.
>> 
>> This prefixing approach would definitely be ugly, and it would violate
>> best practices on shells that do support local, but it should be feasible.
>> 
>> I'd argue that anything moderately complex should be converted to python
>> (maybe after we have OCF 2.0, and some good python bindings ...).
>
> For what it worth, I already raised this discussion some month ago as we wrote
> some perl modules equivalent to ocf-shellfuncs, ocf-returncodes and
> ocf-directories. See: 
>
>   Subject: [ClusterLabs Developers] Perl Modules for resource agents (was:
> Resource Agent language discussion) 
>   Date: Thu, 26 Nov 2015 01:13:36 +0100
>
> I don't want to start a flameware about languages here, this is not about 
> that.
> Maybe it would be a good time to include various libraries for different
> languages in official source? At least for ocf-directories which is quite
> simple, but often tied to the configure options in various distro. We had to
> make a ugly wrapper around the ocf-directories librairie on build time to
> produce our OCF_Directories.pm module on various distros.
>

I don't know Perl so I can't be very helpful reviewing it, but please do
submit your Perl OCF library to resource-agents if you have one! I don't
think anyone is opposed to including a Perl (or Python) API on
principle, it's just a matter of someone actually sitting down to do the
work putting it together.

Cheers,
Kristoffer

-- 
// Kristoffer Grönlund
// kgronl...@suse.com

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dimitri Maziuk]

On 08/29/2016 03:27 PM, Vladislav Bogdanov wrote:

> Maybe #!/bin/ocfsh symlink provided by resource-agents package?

... and that's how lennartware ended up implementing its own syslog...

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Vladislav Bogdanov]

On August 29, 2016 11:07:39 PM GMT+03:00, Lars Ellenberg 
 wrote:
>On Mon, Aug 29, 2016 at 04:37:00PM +0200, Dejan Muhamedagic wrote:
>> Hi,
>> 
>> On Mon, Aug 29, 2016 at 02:58:11PM +0200, Gabriele Bulfon wrote:
>> > I think the main issue is the usage of the "local" operator in ocf*
>> > I'm not an expert on this operator (never used!), don't know how
>hard it is to replace it with a standard version.
>> 
>> Unfortunately, there's no command defined in POSIX which serves
>> the purpose of local, i.e. setting variables' scope. "local" is,
>> however, supported in almost all shells (including most versions
>> of ksh, but apparently not the one you run) and hence we
>> tolerated that in /bin/sh resource agents.
>
>local variables in shell:
>
>  dash (which we probably need to support) knows about "local",
>  and as far as I know, nothing else.
>
>  Some versions of dash treat "local a=A b=B"
>  different from "local a=A; local b=B;"
>
>  bash knows about typeset (which it considers obsolete),
>  declare (which is the replacement for typeset)
> and local (which is mostly, but not completely, identical to declare).
>
>  ksh can do function local variables with "typeset",
>  but only in functions defined with the function keyword,
>  NOT in functions that are defined with the "name()" syntax.
>
>function definitions in shell:
>
>  ksh treats "function x {}" and "x() {}" differently (see above)
>  bash knows both "function name {}" syntax, and "name() { }" syntax,
>  and treats them identically,
>  but dash only knows "name() {}" syntax. (at least in my version...)
>
>that's all broken.  always was.
>
>The result is that it is not possible to write shell scripts
>using functions with local variables that run in
>dash, bash and ksh.
>
>And no, I strongly do not think that we should "fall back" to the
>"art" of shell syntax and idioms that was force on you by the original"
>choose-your-brand-and-year-and-version shell, just because some
>"production systems" still have /bin/sh point to whatever it was
>their oldest ancestor system shipped with in the 19sixties...
>
>Maybe we should simply put some sanity check into
>ony of the first typically sourced helper "include" scripts,
>and bail out early with a sane message if it looks like it won't work?
>
>And also package all shell scripts with a shebang of
>/opt/bin/bash (or whatever) for non-linux systems?
>
>Lars
>
>
>___
>Users mailing list: Users@clusterlabs.org
>http://clusterlabs.org/mailman/listinfo/users
>
>Project Home: http://www.clusterlabs.org
>Getting started:
>http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>Bugs: http://bugs.clusterlabs.org

Maybe #!/bin/ocfsh symlink provided by resource-agents package?


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Lars Ellenberg]

On Mon, Aug 29, 2016 at 04:37:00PM +0200, Dejan Muhamedagic wrote:
> Hi,
> 
> On Mon, Aug 29, 2016 at 02:58:11PM +0200, Gabriele Bulfon wrote:
> > I think the main issue is the usage of the "local" operator in ocf*
> > I'm not an expert on this operator (never used!), don't know how hard it is 
> > to replace it with a standard version.
> 
> Unfortunately, there's no command defined in POSIX which serves
> the purpose of local, i.e. setting variables' scope. "local" is,
> however, supported in almost all shells (including most versions
> of ksh, but apparently not the one you run) and hence we
> tolerated that in /bin/sh resource agents.

local variables in shell:

  dash (which we probably need to support) knows about "local",
  and as far as I know, nothing else.

  Some versions of dash treat "local a=A b=B"
  different from "local a=A; local b=B;"

  bash knows about typeset (which it considers obsolete),
  declare (which is the replacement for typeset)
  and local (which is mostly, but not completely, identical to declare).

  ksh can do function local variables with "typeset",
  but only in functions defined with the function keyword,
  NOT in functions that are defined with the "name()" syntax.

function definitions in shell:

  ksh treats "function x {}" and "x() {}" differently (see above)
  bash knows both "function name {}" syntax, and "name() { }" syntax,
  and treats them identically,
  but dash only knows "name() {}" syntax. (at least in my version...)

that's all broken.  always was.

The result is that it is not possible to write shell scripts
using functions with local variables that run in
dash, bash and ksh.

And no, I strongly do not think that we should "fall back" to the
"art" of shell syntax and idioms that was force on you by the original"
choose-your-brand-and-year-and-version shell, just because some
"production systems" still have /bin/sh point to whatever it was
their oldest ancestor system shipped with in the 19sixties...

Maybe we should simply put some sanity check into
ony of the first typically sourced helper "include" scripts,
and bail out early with a sane message if it looks like it won't work?

And also package all shell scripts with a shebang of
/opt/bin/bash (or whatever) for non-linux systems?

Lars


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Jehan-Guillaume de Rorthais]

On Mon, 29 Aug 2016 10:02:28 -0500
Ken Gaillot  wrote:

> On 08/29/2016 09:43 AM, Dejan Muhamedagic wrote:
...
>> I doubt that we could do a moderately complex shell scripts
>> without capability of limiting the variables' scope and retaining
>> sanity at the same time.
> 
> This prefixing approach would definitely be ugly, and it would violate
> best practices on shells that do support local, but it should be feasible.
> 
> I'd argue that anything moderately complex should be converted to python
> (maybe after we have OCF 2.0, and some good python bindings ...).

For what it worth, I already raised this discussion some month ago as we wrote
some perl modules equivalent to ocf-shellfuncs, ocf-returncodes and
ocf-directories. See: 

  Subject: [ClusterLabs Developers] Perl Modules for resource agents (was:
Resource Agent language discussion) 
  Date: Thu, 26 Nov 2015 01:13:36 +0100

I don't want to start a flameware about languages here, this is not about that.
Maybe it would be a good time to include various libraries for different
languages in official source? At least for ocf-directories which is quite
simple, but often tied to the configure options in various distro. We had to
make a ugly wrapper around the ocf-directories librairie on build time to
produce our OCF_Directories.pm module on various distros.

Regards,

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dmitri Maziuk]

On 2016-08-29 04:06, Gabriele Bulfon wrote:

Thanks, though this does not work :)


Uhm... right. Too many languages, sorry: perl's system() will call the 
login shell, system system() uses /bin/sh, and exec()s will run whatever 
the programmer tells them to. The point is none of them cares what 
shell's in shebang line AFAIK.


But anyway, you're correct; a lot of linux "shell" scripts are bash-only 
and pacemaker RAs are no exception.


Dima


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Dejan Muhamedagic]

Hi,

On Mon, Aug 29, 2016 at 08:47:43AM -0500, Ken Gaillot wrote:
> On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:
> > Hi Ken,
> > 
> > I have been talking with the illumos guys about the shell problem.
> > They all agreed that ksh (and specially the ksh93 used in illumos) is
> > absolutely Bourne-compatible, and that the "local" variables used in the
> > ocf shells is not a Bourne syntax, but probably a bash specific.
> > This means that pointing the scripts to "#!/bin/sh" is portable as long
> > as the scripts are really Bourne-shell only syntax, as any Unix variant
> > may link whatever Bourne-shell they like.
> > In this case, it should point to "#!/bin/bash" or whatever shell the
> > script was written for.
> > Also, in this case, the starting point is not the ocf-* script, but the
> > original RA (IPaddr, but almost all of them).
> > 
> > What about making the code base of RA and ocf-* portable?
> > It may be just by changing them to point to bash, or with some kind of
> > configure modifier to be able to specify the shell to use.
> > 
> > Meanwhile, changing the scripts by hands into #!/bin/bash worked like a
> > charm, and I will start patching.
> > 
> > Gabriele
> 
> Interesting, I thought local was posix, but it's not. It seems everyone
> but solaris implemented it:
> 
> http://stackoverflow.com/questions/18597697/posix-compliant-way-to-scope-variables-to-a-function-in-a-shell-script
> 
> Please open an issue at:
> 
> https://github.com/ClusterLabs/resource-agents/issues
> 
> The simplest solution would be to require #!/bin/bash for all RAs that
> use local,

This issue was raised many times, but note that /bin/bash is a
shell not famous for being lean: it's great for interactive use,
but not so great if you need to run a number of scripts. The
complexity in bash, which is superfluous for our use case,
doesn't go well with the basic principles of HA clusters.

> but I'm not sure that's fair to the distros that support
> local in a non-bash default shell. Another possibility would be to
> modify all RAs to avoid local entirely, by using unique variable
> prefixes per function.

I doubt that we could do a moderately complex shell scripts
without capability of limiting the variables' scope and retaining
sanity at the same time.

> Or, it may be possible to guard every instance of
> local with a check for ksh, which would use typeset instead. Raising the
> issue will allow some discussion of the possibilities.

Just to mention that this is the first time someone reported
running a shell which doesn't support local. Perhaps there's an
option that they install a shell which does.

Thanks,

Dejan

> > 
> > 
> > *Sonicle S.r.l. *: http://www.sonicle.com 
> > *Music: *http://www.gabrielebulfon.com 
> > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
> > 
> > 
> > 
> > --
> > 
> > Da: Ken Gaillot 
> > A: gbul...@sonicle.com Cluster Labs - All topics related to open-source
> > clustering welcomed 
> > Data: 26 agosto 2016 15.56.02 CEST
> > Oggetto: Re: ocf scripts shell and local variables
> > 
> > On 08/26/2016 08:11 AM, Gabriele Bulfon wrote:
> > > I tried adding some debug in ocf-shellfuncs, showing env and ps
> > -ef into
> > > the corosync.log
> > > I suspect it's always using ksh, because in the env output I
> > produced I
> > > find this: KSH_VERSION=.sh.version
> > > This is normally not present in the environment, unless ksh is running
> > > the shell.
> > 
> > The RAs typically start with #!/bin/sh, so whatever that points to on
> > your system is what will be used.
> > 
> > > I also tried modifiying all ocf shells with "#!/usr/bin/bash" at the
> > > beginning, no way, same output.
> > 
> > You'd have to change the RA that includes them.
> > 
> > > Any idea how can I change the used shell to support "local" variables?
> > 
> > You can either edit the #!/bin/sh line at the top of each RA, or figure
> > out how to point /bin/sh to a Bourne-compatible shell. ksh isn't
> > Bourne-compatible, so I'd expect lots of #!/bin/sh scripts to fail with
> > it as the default shell.
> > 
> > > Gabriele
> > >
> > >
> > 
> > 
> > > *Sonicle S.r.l. *: http://www.sonicle.com 
> > > *Music: *http://www.gabrielebulfon.com
> > 
> > > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
> > >
> > >
> > 
> > >
> > >
> > > *Da:* Gabriele Bulfon 
> > > *A:* 

Re: [ClusterLabs] ocf scripts shell and local variables

[Dejan Muhamedagic]

Hi,

On Mon, Aug 29, 2016 at 02:58:11PM +0200, Gabriele Bulfon wrote:
> I think the main issue is the usage of the "local" operator in ocf*
> I'm not an expert on this operator (never used!), don't know how hard it is 
> to replace it with a standard version.

Unfortunately, there's no command defined in POSIX which serves
the purpose of local, i.e. setting variables' scope. "local" is,
however, supported in almost all shells (including most versions
of ksh, but apparently not the one you run) and hence we
tolerated that in /bin/sh resource agents.

Thanks,

Dejan

> Happy to contribute, it still the case
> Gabriele
> 
> Sonicle S.r.l.
> :
> http://www.sonicle.com
> Music:
> http://www.gabrielebulfon.com
> Quantum Mechanics :
> http://www.cdbaby.com/cd/gabrielebulfon
> --
> Da: Kristoffer Gr?nlund
> A: gbul...@sonicle.com Cluster Labs - All topics related to open-source 
> clustering welcomed
> kgail...@redhat.com Cluster Labs - All topics related to open-source 
> clustering welcomed
> Data: 29 agosto 2016 14.36.23 CEST
> Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
> Gabriele Bulfon
> writes:
> Hi Ken,
> I have been talking with the illumos guys about the shell problem.
> They all agreed that ksh (and specially the ksh93 used in illumos) is 
> absolutely Bourne-compatible, and that the "local" variables used in the ocf 
> shells is not a Bourne syntax, but probably a bash specific.
> This means that pointing the scripts to "#!/bin/sh" is portable as long as 
> the scripts are really Bourne-shell only syntax, as any Unix variant may link 
> whatever Bourne-shell they like.
> In this case, it should point to "#!/bin/bash" or whatever shell the script 
> was written for.
> Also, in this case, the starting point is not the ocf-* script, but the 
> original RA (IPaddr, but almost all of them).
> What about making the code base of RA and ocf-* portable?
> It may be just by changing them to point to bash, or with some kind of 
> configure modifier to be able to specify the shell to use.
> Meanwhile, changing the scripts by hands into #!/bin/bash worked like a 
> charm, and I will start patching.
> Gabriele
> Hi Gabriele,
> Yes, your observation is correct: The resource scripts are not fully
> POSIX compatible in this respect. We have been fixing these issues as
> they come up, but since we all use bash-like shells it has never become
> a pressing issue (IIRC Debian did have some of the same issues since
> /bin/sh there is dash, which is also not fully bash-compatible).
> It would be fantastic if you could file issues or submit patches at
> https://github.com/ClusterLabs/resource-agents for the resource agents
> where you still find these problems.
> Cheers,
> Kristoffer
> --
> // Kristoffer Gr?nlund
> // kgronl...@suse.com

> ___
> Users mailing list: Users@clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Klaus Wenninger]

On 08/29/2016 03:47 PM, Ken Gaillot wrote:
> On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:
>> Hi Ken,
>>
>> I have been talking with the illumos guys about the shell problem.
>> They all agreed that ksh (and specially the ksh93 used in illumos) is
>> absolutely Bourne-compatible, and that the "local" variables used in the
>> ocf shells is not a Bourne syntax, but probably a bash specific.
>> This means that pointing the scripts to "#!/bin/sh" is portable as long
>> as the scripts are really Bourne-shell only syntax, as any Unix variant
>> may link whatever Bourne-shell they like.
>> In this case, it should point to "#!/bin/bash" or whatever shell the
>> script was written for.
>> Also, in this case, the starting point is not the ocf-* script, but the
>> original RA (IPaddr, but almost all of them).
>>
>> What about making the code base of RA and ocf-* portable?
>> It may be just by changing them to point to bash, or with some kind of
>> configure modifier to be able to specify the shell to use.
>>
>> Meanwhile, changing the scripts by hands into #!/bin/bash worked like a
>> charm, and I will start patching.
>>
>> Gabriele
> Interesting, I thought local was posix, but it's not. It seems everyone
> but solaris implemented it:
>
> http://stackoverflow.com/questions/18597697/posix-compliant-way-to-scope-variables-to-a-function-in-a-shell-script
>
> Please open an issue at:
>
> https://github.com/ClusterLabs/resource-agents/issues
>
> The simplest solution would be to require #!/bin/bash for all RAs that
> use local, but I'm not sure that's fair to the distros that support
> local in a non-bash default shell. Another possibility would be to
> modify all RAs to avoid local entirely, by using unique variable
> prefixes per function. Or, it may be possible to guard every instance of
> local with a check for ksh, which would use typeset instead. Raising the
> issue will allow some discussion of the possibilities.

An issue that probably doesn't just hit us with RAs.
(e.g. tools/cibsecret.in - just the first grep result ...)
Thus we probably might raise it against pacemaker as well -
especially as current testing seems not to be too well suited to
detect it.

>
>> 
>> *Sonicle S.r.l. *: http://www.sonicle.com 
>> *Music: *http://www.gabrielebulfon.com 
>> *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
>>
>>
>>
>> --
>>
>> Da: Ken Gaillot 
>> A: gbul...@sonicle.com Cluster Labs - All topics related to open-source
>> clustering welcomed 
>> Data: 26 agosto 2016 15.56.02 CEST
>> Oggetto: Re: ocf scripts shell and local variables
>>
>> On 08/26/2016 08:11 AM, Gabriele Bulfon wrote:
>> > I tried adding some debug in ocf-shellfuncs, showing env and ps
>> -ef into
>> > the corosync.log
>> > I suspect it's always using ksh, because in the env output I
>> produced I
>> > find this: KSH_VERSION=.sh.version
>> > This is normally not present in the environment, unless ksh is running
>> > the shell.
>>
>> The RAs typically start with #!/bin/sh, so whatever that points to on
>> your system is what will be used.
>>
>> > I also tried modifiying all ocf shells with "#!/usr/bin/bash" at the
>> > beginning, no way, same output.
>>
>> You'd have to change the RA that includes them.
>>
>> > Any idea how can I change the used shell to support "local" variables?
>>
>> You can either edit the #!/bin/sh line at the top of each RA, or figure
>> out how to point /bin/sh to a Bourne-compatible shell. ksh isn't
>> Bourne-compatible, so I'd expect lots of #!/bin/sh scripts to fail with
>> it as the default shell.
>>
>> > Gabriele
>> >
>> >
>> 
>> 
>> > *Sonicle S.r.l. *: http://www.sonicle.com 
>> > *Music: *http://www.gabrielebulfon.com
>> 
>> > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
>> >
>> >
>> 
>> >
>> >
>> > *Da:* Gabriele Bulfon 
>> > *A:* kgail...@redhat.com Cluster Labs - All topics related to
>> > open-source clustering welcomed 
>> > *Data:* 26 agosto 2016 10.12.13 CEST
>> > *Oggetto:* Re: [ClusterLabs] ocf::heartbeat:IPaddr
>> >
>> >
>> > I looked around what you suggested, inside ocf-binaris and
>> > ocf-shellfuncs etc.
>> > So I found also these logs in corosync.log :
>> >
>> > Aug 25 17:50:33 [2250] crmd: notice: process_lrm_event:
>> > xstorage1-xstorage2_wan2_IP_start_0:22 [
>> > 

Re: [ClusterLabs] ocf scripts shell and local variables

[Ken Gaillot]

On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:
> Hi Ken,
> 
> I have been talking with the illumos guys about the shell problem.
> They all agreed that ksh (and specially the ksh93 used in illumos) is
> absolutely Bourne-compatible, and that the "local" variables used in the
> ocf shells is not a Bourne syntax, but probably a bash specific.
> This means that pointing the scripts to "#!/bin/sh" is portable as long
> as the scripts are really Bourne-shell only syntax, as any Unix variant
> may link whatever Bourne-shell they like.
> In this case, it should point to "#!/bin/bash" or whatever shell the
> script was written for.
> Also, in this case, the starting point is not the ocf-* script, but the
> original RA (IPaddr, but almost all of them).
> 
> What about making the code base of RA and ocf-* portable?
> It may be just by changing them to point to bash, or with some kind of
> configure modifier to be able to specify the shell to use.
> 
> Meanwhile, changing the scripts by hands into #!/bin/bash worked like a
> charm, and I will start patching.
> 
> Gabriele

Interesting, I thought local was posix, but it's not. It seems everyone
but solaris implemented it:

http://stackoverflow.com/questions/18597697/posix-compliant-way-to-scope-variables-to-a-function-in-a-shell-script

Please open an issue at:

https://github.com/ClusterLabs/resource-agents/issues

The simplest solution would be to require #!/bin/bash for all RAs that
use local, but I'm not sure that's fair to the distros that support
local in a non-bash default shell. Another possibility would be to
modify all RAs to avoid local entirely, by using unique variable
prefixes per function. Or, it may be possible to guard every instance of
local with a check for ksh, which would use typeset instead. Raising the
issue will allow some discussion of the possibilities.

> 
> 
> *Sonicle S.r.l. *: http://www.sonicle.com 
> *Music: *http://www.gabrielebulfon.com 
> *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
> 
> 
> 
> --
> 
> Da: Ken Gaillot 
> A: gbul...@sonicle.com Cluster Labs - All topics related to open-source
> clustering welcomed 
> Data: 26 agosto 2016 15.56.02 CEST
> Oggetto: Re: ocf scripts shell and local variables
> 
> On 08/26/2016 08:11 AM, Gabriele Bulfon wrote:
> > I tried adding some debug in ocf-shellfuncs, showing env and ps
> -ef into
> > the corosync.log
> > I suspect it's always using ksh, because in the env output I
> produced I
> > find this: KSH_VERSION=.sh.version
> > This is normally not present in the environment, unless ksh is running
> > the shell.
> 
> The RAs typically start with #!/bin/sh, so whatever that points to on
> your system is what will be used.
> 
> > I also tried modifiying all ocf shells with "#!/usr/bin/bash" at the
> > beginning, no way, same output.
> 
> You'd have to change the RA that includes them.
> 
> > Any idea how can I change the used shell to support "local" variables?
> 
> You can either edit the #!/bin/sh line at the top of each RA, or figure
> out how to point /bin/sh to a Bourne-compatible shell. ksh isn't
> Bourne-compatible, so I'd expect lots of #!/bin/sh scripts to fail with
> it as the default shell.
> 
> > Gabriele
> >
> >
> 
> 
> > *Sonicle S.r.l. *: http://www.sonicle.com 
> > *Music: *http://www.gabrielebulfon.com
> 
> > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
> >
> >
> 
> >
> >
> > *Da:* Gabriele Bulfon 
> > *A:* kgail...@redhat.com Cluster Labs - All topics related to
> > open-source clustering welcomed 
> > *Data:* 26 agosto 2016 10.12.13 CEST
> > *Oggetto:* Re: [ClusterLabs] ocf::heartbeat:IPaddr
> >
> >
> > I looked around what you suggested, inside ocf-binaris and
> > ocf-shellfuncs etc.
> > So I found also these logs in corosync.log :
> >
> > Aug 25 17:50:33 [2250] crmd: notice: process_lrm_event:
> > xstorage1-xstorage2_wan2_IP_start_0:22 [
> > /usr/lib/ocf/resource.d/heartbeat/IPaddr[71]: local: not found [No
> > such file or
> > directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[354]: local:
> > not found [No such file or
> > directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[355]: local:
> > not found [No such file or
> > directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[356]: local:
> > not found [No 

Re: [ClusterLabs] ocf scripts shell and local variables

[Gabriele Bulfon]

I think the main issue is the usage of the "local" operator in ocf*
I'm not an expert on this operator (never used!), don't know how hard it is to 
replace it with a standard version.
Happy to contribute, it still the case
Gabriele

Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Kristoffer Grönlund
A: gbul...@sonicle.com Cluster Labs - All topics related to open-source 
clustering welcomed
kgail...@redhat.com Cluster Labs - All topics related to open-source clustering 
welcomed
Data: 29 agosto 2016 14.36.23 CEST
Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
Gabriele Bulfon
writes:
Hi Ken,
I have been talking with the illumos guys about the shell problem.
They all agreed that ksh (and specially the ksh93 used in illumos) is 
absolutely Bourne-compatible, and that the "local" variables used in the ocf 
shells is not a Bourne syntax, but probably a bash specific.
This means that pointing the scripts to "#!/bin/sh" is portable as long as the 
scripts are really Bourne-shell only syntax, as any Unix variant may link 
whatever Bourne-shell they like.
In this case, it should point to "#!/bin/bash" or whatever shell the script was 
written for.
Also, in this case, the starting point is not the ocf-* script, but the 
original RA (IPaddr, but almost all of them).
What about making the code base of RA and ocf-* portable?
It may be just by changing them to point to bash, or with some kind of 
configure modifier to be able to specify the shell to use.
Meanwhile, changing the scripts by hands into #!/bin/bash worked like a charm, 
and I will start patching.
Gabriele
Hi Gabriele,
Yes, your observation is correct: The resource scripts are not fully
POSIX compatible in this respect. We have been fixing these issues as
they come up, but since we all use bash-like shells it has never become
a pressing issue (IIRC Debian did have some of the same issues since
/bin/sh there is dash, which is also not fully bash-compatible).
It would be fantastic if you could file issues or submit patches at
https://github.com/ClusterLabs/resource-agents for the resource agents
where you still find these problems.
Cheers,
Kristoffer
--
// Kristoffer Grönlund
// kgronl...@suse.com
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Kristoffer Grönlund]

Gabriele Bulfon  writes:

> Hi Ken,
> I have been talking with the illumos guys about the shell problem.
> They all agreed that ksh (and specially the ksh93 used in illumos) is 
> absolutely Bourne-compatible, and that the "local" variables used in the ocf 
> shells is not a Bourne syntax, but probably a bash specific.
> This means that pointing the scripts to "#!/bin/sh" is portable as long as 
> the scripts are really Bourne-shell only syntax, as any Unix variant may link 
> whatever Bourne-shell they like.
> In this case, it should point to "#!/bin/bash" or whatever shell the script 
> was written for.
> Also, in this case, the starting point is not the ocf-* script, but the 
> original RA (IPaddr, but almost all of them).
> What about making the code base of RA and ocf-* portable?
> It may be just by changing them to point to bash, or with some kind of 
> configure modifier to be able to specify the shell to use.
> Meanwhile, changing the scripts by hands into #!/bin/bash worked like a 
> charm, and I will start patching.
> Gabriele

Hi Gabriele,

Yes, your observation is correct: The resource scripts are not fully
POSIX compatible in this respect. We have been fixing these issues as
they come up, but since we all use bash-like shells it has never become
a pressing issue (IIRC Debian did have some of the same issues since
/bin/sh there is dash, which is also not fully bash-compatible).

It would be fantastic if you could file issues or submit patches at
https://github.com/ClusterLabs/resource-agents for the resource agents
where you still find these problems.

Cheers,
Kristoffer

-- 
// Kristoffer Grönlund
// kgronl...@suse.com

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] ocf scripts shell and local variables

[Gabriele Bulfon]

Hi Ken,
I have been talking with the illumos guys about the shell problem.
They all agreed that ksh (and specially the ksh93 used in illumos) is 
absolutely Bourne-compatible, and that the "local" variables used in the ocf 
shells is not a Bourne syntax, but probably a bash specific.
This means that pointing the scripts to "#!/bin/sh" is portable as long as the 
scripts are really Bourne-shell only syntax, as any Unix variant may link 
whatever Bourne-shell they like.
In this case, it should point to "#!/bin/bash" or whatever shell the script was 
written for.
Also, in this case, the starting point is not the ocf-* script, but the 
original RA (IPaddr, but almost all of them).
What about making the code base of RA and ocf-* portable?
It may be just by changing them to point to bash, or with some kind of 
configure modifier to be able to specify the shell to use.
Meanwhile, changing the scripts by hands into #!/bin/bash worked like a charm, 
and I will start patching.
Gabriele

Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Ken Gaillot
A: gbul...@sonicle.com Cluster Labs - All topics related to open-source 
clustering welcomed
Data: 26 agosto 2016 15.56.02 CEST
Oggetto: Re: ocf scripts shell and local variables
On 08/26/2016 08:11 AM, Gabriele Bulfon wrote:
I tried adding some debug in ocf-shellfuncs, showing env and ps -ef into
the corosync.log
I suspect it's always using ksh, because in the env output I produced I
find this: KSH_VERSION=.sh.version
This is normally not present in the environment, unless ksh is running
the shell.
The RAs typically start with #!/bin/sh, so whatever that points to on
your system is what will be used.
I also tried modifiying all ocf shells with "#!/usr/bin/bash" at the
beginning, no way, same output.
You'd have to change the RA that includes them.
Any idea how can I change the used shell to support "local" variables?
You can either edit the #!/bin/sh line at the top of each RA, or figure
out how to point /bin/sh to a Bourne-compatible shell. ksh isn't
Bourne-compatible, so I'd expect lots of #!/bin/sh scripts to fail with
it as the default shell.
Gabriele

*Sonicle S.r.l. *: http://www.sonicle.com
*Music: *http://www.gabrielebulfon.com
*Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon

*Da:* Gabriele Bulfon
*A:* kgail...@redhat.com Cluster Labs - All topics related to
open-source clustering welcomed
*Data:* 26 agosto 2016 10.12.13 CEST
*Oggetto:* Re: [ClusterLabs] ocf::heartbeat:IPaddr
I looked around what you suggested, inside ocf-binaris and
ocf-shellfuncs etc.
So I found also these logs in corosync.log :
Aug 25 17:50:33 [2250] crmd: notice: process_lrm_event:
xstorage1-xstorage2_wan2_IP_start_0:22 [
/usr/lib/ocf/resource.d/heartbeat/IPaddr[71]: local: not found [No
such file or
directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[354]: local:
not found [No such file or
directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[355]: local:
not found [No such file or
directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[356]: local:
not found [No such file or directory]\nocf-exit-reason:Setup
problem: coul
Aug 25 17:50:33 [2246] lrmd: notice: operation_finished:
xstorage2_wan2_IP_start_0:3613:stderr [
/usr/lib/ocf/resource.d/heartbeat/IPaddr[71]: local: not found [No
such file or directory] ]
Looks like the shell is not happy with the "local" variable definition.
I tried running ocf-shellfuncs manually with sh and bash and they
all run without errors.
How can I see what shell is running these scripts?

*Sonicle S.r.l. *: http://www.sonicle.com
*Music: *http://www.gabrielebulfon.com
*Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Ken Gaillot
A: users@clusterlabs.org
Data: 25 agosto 2016 18.07.42 CEST
Oggetto: Re: [ClusterLabs] ocf::heartbeat:IPaddr
On 08/25/2016 10:51 AM, Gabriele Bulfon wrote:
Hi,
I'm advancing with this monster cluster on XStreamOS/illumos ;)
In the previous older tests I used heartbeat, and I had these
lines to
take care of the swapping public IP addresses:
primitive xstorage1_wan1_IP ocf:heartbeat:IPaddr params
ip="1.2.3.4"
cidr_netmask="255.255.255.0" nic="e1000g1"
primitive xstorage2_wan2_IP ocf:heartbeat:IPaddr params
ip="1.2.3.5"
cidr_netmask="255.255.255.0" nic="e1000g1"
location xstorage1_wan1_IP_pref xstorage1_wan1_IP 100: xstorage1
location xstorage2_wan2_IP_pref xstorage2_wan2_IP 100: xstorage2
They get configured, but then I get this in 

Re: [ClusterLabs] ocf scripts shell and local variables

[Dmitri Maziuk]

On 2016-08-26 08:56, Ken Gaillot wrote:

On 08/26/2016 08:11 AM, Gabriele Bulfon wrote:

I tried adding some debug in ocf-shellfuncs, showing env and ps -ef into
the corosync.log
I suspect it's always using ksh, because in the env output I produced I
find this: KSH_VERSION=.sh.version
This is normally not present in the environment, unless ksh is running
the shell.


The RAs typically start with #!/bin/sh, so whatever that points to on
your system is what will be used.


ISTR exec() family will ignore the shebang and run whatever shell's in 
user's /etc/passwd. Or something. Try changing that one.


Dima


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

[ClusterLabs] ocf scripts shell and local variables

[Gabriele Bulfon]

I tried adding some debug in ocf-shellfuncs, showing env and ps -ef into the 
corosync.log
I suspect it's always using ksh, because in the env output I produced I find 
this: KSH_VERSION=.sh.version
This is normally not present in the environment, unless ksh is running the 
shell.
I also tried modifiying all ocf shells with "#!/usr/bin/bash" at the beginning, 
no way, same output.
Any idea how can I change the used shell to support "local" variables?
Gabriele

Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
Da:
Gabriele Bulfon
A:
kgail...@redhat.com Cluster Labs - All topics related to open-source clustering 
welcomed
Data:
26 agosto 2016 10.12.13 CEST
Oggetto:
Re: [ClusterLabs] ocf::heartbeat:IPaddr
I looked around what you suggested, inside ocf-binaris and ocf-shellfuncs etc.
So I found also these logs in corosync.log :
Aug 25 17:50:33 [2250]   crmd:   notice: process_lrm_event: 
xstorage1-xstorage2_wan2_IP_start_0:22 [ 
/usr/lib/ocf/resource.d/heartbeat/IPaddr[71]: local: not found [No such file or 
directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[354]: local: not found [No 
such file or directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[355]: local: 
not found [No such file or 
directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[356]: local: not found [No 
such file or directory]\nocf-exit-reason:Setup problem: coul
Aug 25 17:50:33 [2246]   lrmd:   notice: operation_finished:
xstorage2_wan2_IP_start_0:3613:stderr [ 
/usr/lib/ocf/resource.d/heartbeat/IPaddr[71]: local: not found [No such file or 
directory] ]
Looks like the shell is not happy with the "local" variable definition.
I tried running ocf-shellfuncs manually with sh and bash and they all run 
without errors.
How can I see what shell is running these scripts?

Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Ken Gaillot
A: users@clusterlabs.org
Data: 25 agosto 2016 18.07.42 CEST
Oggetto: Re: [ClusterLabs] ocf::heartbeat:IPaddr
On 08/25/2016 10:51 AM, Gabriele Bulfon wrote:
Hi,
I'm advancing with this monster cluster on XStreamOS/illumos ;)
In the previous older tests I used heartbeat, and I had these lines to
take care of the swapping public IP addresses:
primitive xstorage1_wan1_IP ocf:heartbeat:IPaddr params ip="1.2.3.4"
cidr_netmask="255.255.255.0" nic="e1000g1"
primitive xstorage2_wan2_IP ocf:heartbeat:IPaddr params ip="1.2.3.5"
cidr_netmask="255.255.255.0" nic="e1000g1"
location xstorage1_wan1_IP_pref xstorage1_wan1_IP 100: xstorage1
location xstorage2_wan2_IP_pref xstorage2_wan2_IP 100: xstorage2
They get configured, but then I get this in crm status:
xstorage1_wan1_IP (ocf::heartbeat:IPaddr): Stopped
xstorage2_wan2_IP (ocf::heartbeat:IPaddr): Stopped
Failed Actions:
* xstorage1_wan1_IP_start_0 on xstorage1 'not installed' (5): call=20,
status=complete, exitreason='Setup problem: couldn't find command:
/usr/bin/gawk',
last-rc-change='Thu Aug 25 17:50:32 2016', queued=1ms, exec=158ms
* xstorage2_wan2_IP_start_0 on xstorage1 'not installed' (5): call=22,
status=complete, exitreason='Setup problem: couldn't find command:
/usr/bin/gawk',
last-rc-change='Thu Aug 25 17:50:33 2016', queued=1ms, exec=29ms
* xstorage1_wan1_IP_start_0 on xstorage2 'not installed' (5): call=22,
status=complete, exitreason='Setup problem: couldn't find command:
/usr/bin/gawk',
last-rc-change='Thu Aug 25 17:50:30 2016', queued=1ms, exec=36ms
* xstorage2_wan2_IP_start_0 on xstorage2 'not installed' (5): call=20,
status=complete, exitreason='Setup problem: couldn't find command:
/usr/bin/gawk',
last-rc-change='Thu Aug 25 17:50:29 2016', queued=0ms, exec=150ms
The crm configure process already checked of the presence of the
required IPaddr shell, and it was ok.
Now looks like it's looking for "/usr/bin/gawk", and that is actually there!
Is there any known incompatibility with the mixed heartbeat ocf ? Should
I use corosync specific ocf files or something else?
"heartbeat" in this case is just an OCF provider name, and has nothing
to do with the heartbeat messaging layer, other than having its origin
in the same project. There actually has been a recent proposal to rename
the provider to "clusterlabs" to better reflect the current reality.
The "couldn't find command" message comes from the ocf-binaries shell
functions. If you look at have_binary() there, it uses sed and which,
and I'm guessing that fails on your OS somehow. You may need to patch it.
Thanks again!
Gabriele

*Sonicle S.r.l. *: http://www.sonicle.com
*Music: