[ClusterLabs] Antw: [EXT] Re: ip address configuration problem
Reid Wahl
nwahl at redhat.com
Tue Jul 28 06:12:21 EDT 2020
On Tue, Jul 28, 2020 at 2:44 AM Ulrich Windl <
Ulrich.Windl at rz.uni-regensburg.de> wrote:
> >>> Reid Wahl <nwahl at redhat.com> schrieb am 28.07.2020 um 10:21 in
> Nachricht
> <CAPiuu9-QY1tE_nat_HouCCAvDYm1rWXRGS6+hjcuTmgM4ggnFw at mail.gmail.com>:
> > On Tuesday, July 28, 2020, Ulrich Windl <
> Ulrich.Windl at rz.uni-regensburg.de>
> > wrote:
> >>>>> Gabriele Bulfon <gbulfon at sonicle.com> schrieb am 28.07.2020 um
> 09:35 in
> >> Nachricht <1046247888.11369.1595921749049 at www>:
> >>> Thanks, I patched all the scripts in build to have "#!/bin/bash" in
> > head, and
> >>> I receive no errors now.
> >>
> >> If it's needed, those scripts were buggy anyway.
> >
> > How does that mean the script is buggy? It would depend on what /bin/sh
> is
> > linked to on a particular system.
>
> /bin/sh may be a minimal Bourne-compatible shell. Assuming that it is
> bash-compatible is a bad idea.
> And: Is it really a problem to require bash? I mean there are scripts that
> require csh (yuk!)
>
Some resource agents do require bash (e.g., sybaseASE).
Re: csh -- there are? Gross ;)
Resource agents that have been around a while typically specify /bin/sh,
and it's considered a regression to introduce new non-portable syntax.
Syntax that was never 100% portable in the first place is a somewhat
different matter. Ideally it would have been totally portable in the first
place, though in practice, it apparently hasn't been. The main constraint
going forward is not to make it LESS portable.
"It is considered a regression to introduce a patch that will make a
previously sh compatible resource agent suitable only for bash, ksh, or any
other non-generic shell. It is, however, perfectly acceptable for a new
resource agent to explicitly define a specific shell, such as /bin/bash, as
its interpreter."
-
https://github.com/ClusterLabs/resource-agents/blob/master/doc/dev-guides/ra-dev-guide.asc
I discussed a little bit with one of the devs, who said the sh portability
testing has mostly been with dash on Debian. (BTW, by default,
`checkbashisms` allows things that aren't POSIX but that are specified by
Debian Policy.)
> >
> >>There is a "checkbashisms" program (in SLES at least) that can check
> > whether a shell script actually needs BASH (or compatible)...
> >
> > That's available for RHEL too. The question is whether it's worth
> modifying
> > libraries that are core to resource-agents, essentially for compatibility
> > with vanilla ksh. The conservative answer is no, although there is a case
>
> I never used ksh, but AFAIR the only advantage of ksh was vi-compatible
> command-line edition (which bash can do at least as good).
> Is there any good reason to require ksh for scripts?
>
I doubt it. But the only place we require ksh is for one `su` command in
the sybaseASE agent. To make sure we're on the same page: this wasn't a
case of the RA specifying ksh, but rather of Gabriele's default shell being
ksh and resolving sh to ksh.
> > to be made in favor of the change. The local keyword has been there for
> > years. A lot of shells besides bash support the local keyword, and even
> if
> > ksh is the default shell on a user's system, they can likely use a
> > different one if needed, as Gabriele has done.
> >>
> >>> Though, the IP is not configured :( I'm looking at it...
> >>> Is there any easy way to debug what's doing on the IP script?
> >>>
> >>> Gabriele
> >>>
> >>>
> >>> Sonicle S.r.l.
> >>> :
> >>> http://www.sonicle.com
> >>> Music:
> >>> http://www.gabrielebulfon.com
> >>> Quantum Mechanics :
> >>> http://www.cdbaby.com/cd/gabrielebulfon
> >>>
> >
> ----------------------------------------------------------------------------
> >>> ------
> >>> Da: Ulrich Windl
> >>> A: users at clusterlabs.org
> >>> Data: 28 luglio 2020 9.12.41 CEST
> >>> Oggetto: [ClusterLabs] Antw: [EXT] Re: ip address configuration problem
> >>> You could try replacing "local" with "typeset", also.
> >>> Reid Wahl
> >>> schrieb am 28.07.2020 um 09:05 in Nachricht
> >>> :
> >>> By the way, it doesn't necessarily have to be bash. Upon looking
> > further, a
> >>> lot of shells support the `local` keyword, even though it's not
> required
> > by
> >>> the POSIX standard. Plain ksh, however, does not :(
> >>> On Monday, July 27, 2020, Reid Wahl
> >>> wrote:
> >>> Hi, Gabriele. The `local` keyword is a bash built-in and not available
> in
> >>> some other shells (e.g., ksh). It's used in `have_binary()`, so it's
> >>> causing `check_binary(/usr/gnu/bin/awk)` to fail. It's also causing all
> > the
> >>> "local: not found" errors. I just reproduced it to make sure.
> >>> check_binary () {
> >>> if ! have_binary "$1"; then
> >>> if [ "$OCF_NOT_RUNNING" = 7 ]; then
> >>> # Chances are we have a fully setup OCF environment
> >>> ocf_exit_reason "Setup problem: couldn't find command: $1"
> >>> else
> >>> echo "Setup problem: couldn't find command: $1"
> >>> fi
> >>> exit $OCF_ERR_INSTALLED
> >>> fi
> >>> }
> >>> have_binary () {
> >>> if [ "$OCF_TESTER_FAIL_HAVE_BINARY" = "1" ]; then
> >>> false
> >>> else
> >>> local bin=`echo $1 | sed -e 's/ -.*//'`
> >>> test -x "`which $bin 2/dev/null`"
> >>> fi
> >>> }
> >>> Is bash available on your system?
> >>> On Mon, Jul 27, 2020 at 8:34 AM Gabriele Bulfon
> >>> wrote:
> >>> Hello,
> >>> after configuring crm for IP automatic configuration, I stumbled upon a
> >>> problem with the IPaddr utiliy that I don't understand:
> >>> IPaddr(xstha2_san0_IP)[10439]: 2020/07/27_17:26:17 ERROR: Setup
> problem:
> >>> couldn't find command: /usr/gnu/bin/awk
> >>> Jul 27 17:26:17 [10258] lrmd: notice: operation_finished:
> >>> xstha2_san0_IP_start_0:10439:stderr [
> >>> /usr/lib/ocf/resource.d/heartbeat/IPaddr[71]: local: not found [No such
> >>> file or directory] ]
> >>> Jul 27 17:26:17 [10258] lrmd: notice: operation_finished:
> >>> xstha2_san0_IP_start_0:10439:stderr [
> >>> /usr/lib/ocf/resource.d/heartbeat/IPaddr[354]: local: not found [No
> such
> >>> file or directory] ]
> >>> Jul 27 17:26:17 [10258] lrmd: notice: operation_finished:
> >>> xstha2_san0_IP_start_0:10439:stderr [
> >>> /usr/lib/ocf/resource.d/heartbeat/IPaddr[355]: local: not found [No
> such
> >>> file or directory] ]
> >>> Jul 27 17:26:17 [10258] lrmd: notice: operation_finished:
> >>> xstha2_san0_IP_start_0:10439:stderr [
> >>> /usr/lib/ocf/resource.d/heartbeat/IPaddr[356]: local: not found [No
> such
> >>> file or directory] ]
> >>> Jul 27 17:26:17 [10258] lrmd: notice: operation_finished:
> >>> xstha2_san0_IP_start_0:10439:stderr [ ocf-exit-reason:Setup problem:
> >>> couldn't find command: /usr/gnu/bin/awk ]
> >>> Jul 27 17:26:17 [10258] lrmd: notice: operation_finished:
> >>> xstha2_san0_IP_start_0:10439:stderr [
> >>> /usr/lib/ocf/resource.d/heartbeat/IPaddr[185]: local: not found [No
> such
> >>> file or directory] ]
> >>> Jul 27 17:26:17 [10258] lrmd: notice: operation_finished:
> >>> xstha2_san0_IP_start_0:10439:stderr [
> >>> /usr/lib/ocf/resource.d/heartbeat/IPaddr[186]: local: not found [No
> such
> >>> file or directory] ]
> >>> Jul 27 17:26:17 [10258] lrmd: info: log_finished: finished -
> >>> rsc:xstha2_san0_IP action:start call_id:22 pid:10439 exit-code:5
> >>> exec-time:91ms queue-time:0ms
> >>> It says it cannot find /usr/gnu/bin/awk but this is absolutely not
> true!
> >>> sonicle at xstorage1:/sonicle/home# ls -l /usr/gnu/bin/awk
> >>> -r-xr-xr-x 1 root bin 881864 Jun 1 12:25 /usr/gnu/bin/awk
> >>> sonicle at xstorage1:/sonicle/home# file /usr/gnu/bin/awk
> >>> /usr/gnu/bin/awk: ELF 64-bit LSB executable AMD64 Version 1,
> dynamically
> >>> linked, not stripped, no debugging information available
> >>> what may be happening??
> >>> Thanks!
> >>> Gabriele
> >>> Sonicle S.r.l. : http://www.sonicle.com
> >>> Music: http://www.gabrielebulfon.com
> >>> Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon
> >>> _______________________________________________
> >>> Manage your subscription:
> >>> https://lists.clusterlabs.org/mailman/listinfo/users
> >>> ClusterLabs home: https://www.clusterlabs.org/
> >>> --
> >>> Regards,
> >>> Reid Wahl, RHCA
> >>> Software Maintenance Engineer, Red Hat
> >>> CEE - Platform Support Delivery - ClusterHA
> >>> --
> >>> Regards,
> >>> Reid Wahl, RHCA
> >>> Software Maintenance Engineer, Red Hat
> >>> CEE - Platform Support Delivery - ClusterHA
> >>> _______________________________________________
> >>> Manage your subscription:
> >>> https://lists.clusterlabs.org/mailman/listinfo/users
> >>> ClusterLabs home: https://www.clusterlabs.org/
> >>
> >>
> >>
> >> _______________________________________________
> >> Manage your subscription:
> >> https://lists.clusterlabs.org/mailman/listinfo/users
> >>
> >> ClusterLabs home: https://www.clusterlabs.org/
> >>
> >>
> >
> > --
> > Regards,
> >
> > Reid Wahl, RHCA
> > Software Maintenance Engineer, Red Hat
> > CEE - Platform Support Delivery - ClusterHA
>
>
>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/
>
>
--
Regards,
Reid Wahl, RHCA
Software Maintenance Engineer, Red Hat
CEE - Platform Support Delivery - ClusterHA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20200728/ccf53792/attachment.htm>
More information about the Users
mailing list