Re: [ClusterLabs] Antw: Re: ocf scripts shell and local variables

[Dejan Muhamedagic]

On Tue, Aug 30, 2016 at 08:09:34AM +0200, Ulrich Windl wrote:
> >>> Dejan Muhamedagic  schrieb am 29.08.2016 um 16:37 in
> Nachricht <20160829143700.GA1538@tuttle.homenet>:
> > 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,
> 
> Isn't it "typeset"?

I don't think that /bin/dash supports typeset. Anyway, supporting
typeset, which covers much more than limiting the scope, would
also invite people to use it for that other stuff. If it's there,
someone's sure to use it ;-)

Thanks,

Dejan

> 
> > 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
> 
> 
> 
> 
> ___
> 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

[ClusterLabs] Antw: Re: ocf scripts shell and local variables

[Ulrich Windl]

>>> Lars Ellenberg  schrieb am 29.08.2016 um 22:07 in
Nachricht <20160829200739.GQ5268@soda.linbit>:

[...]
> 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...

Yes, those with a PDP-11 and 128kB "core" memory using a 300 baud acoustic 
coupler for dial-in;-)

[...]

Ulrich




___
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] Antw: Re: ocf scripts shell and local variables

[Ulrich Windl]

>>> Jehan-Guillaume de Rorthais  schrieb am 29.08.2016 um 
>>> 18:04 in
Nachricht <20160829180440.5b7f1a2e@firost>:
> 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'd like to write RAs in Perl, also. It's much safer (more tests, more 
warnings, better language) and possibly efficient, too.

> 
> 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 





___
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] Antw: Re: ocf scripts shell and local variables

[Ulrich Windl]

>>> Dmitri Maziuk  schrieb am 29.08.2016 um 17:13 in
Nachricht <161a5209-166c-e837-dcb0-169b8a4b3...@gmail.com>:
> 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.

Nonsense: If you use the exec system call, it uses the shebang; if you 
explictly call the script with a shell, that shell is used. Read the docs of 
the language or library!

> 
> 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 





___
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] Antw: Re: ocf scripts shell and local variables

[Ulrich Windl]

>>> Gabriele Bulfon  schrieb am 29.08.2016 um 17:08 in
Nachricht <14184995.610.1472483315074.JavaMail.sonicle@www>:
> 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.

A completely different idea: What about defining an OCF shell function that 
tells you the category of the shell, like "bourne|posix|bash"? So some 
pseudo-code like this could be used:
if [ `shell_class` != bash ]; then
  # report a problem
  exit ...
fi

Regards,
Ulrich

> 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-variable
>  
> s-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, 

[ClusterLabs] Antw: Re: ocf scripts shell and local variables

[Ulrich Windl]

>>> Dejan Muhamedagic  schrieb am 29.08.2016 um 16:37 in
Nachricht <20160829143700.GA1538@tuttle.homenet>:
> 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,

Isn't it "typeset"?


> 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




___
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] Antw: Re: ocf scripts shell and local variables

[Ulrich Windl]

>>> Ken Gaillot  schrieb am 29.08.2016 um 15:47 in 
>>> Nachricht
<8ca22867-2103-b2da-316b-ac97234f8...@redhat.com>:
> On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:

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

Their VI was unable to handle 8-bit characters (like 10 years ago), not to talk 
about Unicode, also, and their NTP daemon isn't telling its version. I'm not a 
Solaris user, but that's what I know from co-workers...

Ulrich




___
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