Mailing List Archive: Linux-HA: Dev

cronjobs v1.2 rc1 OCF resource agent now available

Index | Next | Previous | View Threaded

pica1dilly at yahoo

Jul 1, 2008, 12:44 PM

Post #1 of 22 (1267 views)
Permalink

cronjobs v1.2 rc1 OCF resource agent now available

Cronjobs v1.2 rc1, a beta version fairly tested, successfully passed the ocf-tester.
Currently running on a 2 node test cluster and a 3 node pre-production cluster.

Main feature: preserves all those crontab entries added either manually or by other bots.

Pick up here: http://www.geocities.com/pica1dilly/cronjobs.zip

Installation:

1) drop cronjobs in /usr/lib/ocf/resource.d/heartbeat on each cluster node, chmod u+x the file,

2) drop cronjobs.cf in /etc/ha.d on each cluster node,

3) edit cronjobs.cf on each cluster node to suit the local cron flavor,

4) eventually, if you are picky, specify your own logger commands to invoke in place of, or additionally to, the ocf_log( ) if your needs exceed the current implementation,

5) fire up the haclient.py, create a new primitive resource, scroll the list of types, cronjobs should appear is an ocf/heartbeat agent,

6) specify the user of the crontab to manage, the source file of the block of crontab instructions to enable and disable each time the resource is started and stopped,

7) fill in the crontab source file on each node with cron instructions to run when the resource is enabled on that node, eventually maintain only one shared copy of the crontab instructions to run on all nodes for which a specific resource is configured to run on,

8) start the resource, tah-Dah, showtime !

# Name:                 cronjobs, an OCF resource agent
# Version:              1.2 beta, rc 1
# Author:               Eric Defferard <eric.defferard[at]adm.unige.ch>
# Last modification:    30-jun-2008
# License:              GNU General Public License (GPL) Version 2, June 1991
#                       http://www.gnu.org/licenses/gpl-2.0.txt
# Copyright:            (c) 2008 Eric Defferard, all rights reserved
#
#====================================================================================
#
# description:
# Enables and disables as cron jobs, those cron job entries listed in a source file
# which path is specified as parameter.
#
# The cron jobs are copied in the cron table of the user specified also as parameter.
#
# Unless an existing crontab entry is repeated exactly in a cron job source file,
# the agent *preserves* all cron job entries previously configured in the user's
# cron table.
#
# If a crontab file corruption is detected, the agent will automatically attempt to
# fix the crontab by removing from the crontab *all* job entries specified in the
# instance's cron job source file.
#
# Dillon cron (dcron) supported as hard coded default.
#
# OCF instance parameters:
# - OCF_RESKEY_crontabusr
# - OCF_RESKEY_crontabsrc
#
# OCF environment variables
# - OCF_ROOT, expected, no defaults.
#
# config file:
# - cronjobs.cf:
# Search order: /etc/ha.d/cronjobs.cf, /etc/ha.d/conf/cronjobs.cf.
# Contains the user specification of the crontab 'list' and 'replace' operations
# to support different cron implementations while keeping the code independent,
# as well as a 'logger' substitution operation for the ocf_log() function
# called by default.
#
# The user specified 'logger' operation was prompted as a quick user-manageable
# dynamic fix if user shys away from the "unfinished" or "to be improved" state
# of the implementation of the ocf_log() function and underlying APIs.
#
# The required attributes for a config file are:
# - must be a plain text file
# - must be NON-world writeable, non-executable
# - it's directory must be non-writeable
#
# Uses @@ encapsulated tokens that are automagically substituted
# with real values passed as OCF instance parameters (see above), or
# other values handled by the agent.
#
# Header:
#
# Configuration file for the 'cronjobs' OCF resource agent.
#
# Format: op = command , or
# log_env_var = value
#
# Syntax:
# - 'op' is:
# - the crontab operation to specify
# - 'list'
# - 'replace', or
# - the logging command that, if defined, shall be invoked
# in place of, or following any routine call in this agent
# to the standard ocf_log() function.
# - 'logger'
# - eval'd in place of call to ocf_log()
# - '+logger'
# - eval'd immediately following call to ocf_log()
#
# - 'command' is the exact command line that would be typed to
# invoke the crontab operation
#
# - '=' is the operation or variable delimiter
#
# - '@user@' is the token used to specify where in the command line
# the token should be substituted with the crontab user,
# in both command lines used respectively to invoke
# the 'list' and the 'replace' crontab operations, immediately
# before the command line is eval'ed.
#
# - '@file@' is the token used to specify where in the command line
# the token should be substituted with the crontab job
# source file, specifically in the command line used to
# invoke the 'replace' crontab operation.
#
# - '@msg@' is the token used to specify where in the specific 'logger'
# command line the token should be substituted with the message that
# is to be logged.
#
# - '@pri@' is the token used to specify where in the specific 'logger'
# command line the token should be substituted with the syslog
# priority that is to be assigned to a message that is to be logged.
#
# - '#', when the first non-blank character encountered in a line,
# used to comment out the whole line.
#
# - '\', when the last non-blank character encountered in a line,
# indicates the next line is the continuation of the current line.
#
# implementation notes:
#
#   - originally thought of a task that would comment out and uncomment cron jobs
#   in the crontabs but realized there was then no reliable way to distinguish
#   those permanent jobs from those dependent on heartbeat controlled resources.
#
#   - the config file is read using the bash 'read' command
#
#   - uses internally those log priority level names specified for BSD 4.3 syslog,
#   before eventually converting the names to what APIs may require.

Enjoy !

pica1dilly at yahoo

Jul 3, 2008, 8:22 AM

Post #2 of 22 (1215 views)
Permalink

Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

Just to announce cronjobs v1.2 rc2 was dropped at the link above.

Changes:

- hardened and cleaned up the code to meet production grade requirements
- added the missing handling of rarely met error conditions that previously dropped the user back to the shell with no message.

At this point, apart bug fixes, I've met my requirements for this agent and have no improvements in queue.

pica1dilly at yahoo

Jul 3, 2008, 4:11 PM

Post #3 of 22 (1210 views)
Permalink

Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

Just to announce cronjobs v1.2 rc3 was dropped at the link above.

Changes:

- respecified the status of some exits to OCF_ERR_INSTALLED and OCF_ERR_CONFIGURED to better match the handling by Heartbeat,

- corrected in one place the name of a variable that went by '$srcf',

- corrected in one place the name of a return code mistakingly specified as OCF_ERR_SUCCES

dejanmm at fastmail

Jul 14, 2008, 2:52 AM

Post #4 of 22 (1150 views)
Permalink

Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

Hi,

Would you mind making the script compatible with /bin/sh?

Many thanks for the contribution.

Cheers,

Dejan

On Tue, Jul 01, 2008 at 12:44:11PM -0700, Joe Bill wrote:
> Cronjobs v1.2 rc1, a beta version fairly tested, successfully passed the ocf-tester.
> Currently running on a 2 node test cluster and a 3 node pre-production cluster.
>
> Main feature: preserves all those crontab entries added either manually or by other bots.
>
> Pick up here: http://www.geocities.com/pica1dilly/cronjobs.zip
>
> Installation:
>
> 1) drop cronjobs in /usr/lib/ocf/resource.d/heartbeat on each cluster node, chmod u+x the file,
>
> 2) drop cronjobs.cf in /etc/ha.d on each cluster node,
>
> 3) edit cronjobs.cf on each cluster node to suit the local cron flavor,
>
> 4) eventually, if you are picky, specify your own logger commands to invoke in place of, or additionally to, the ocf_log( ) if your needs exceed the current implementation,
>
> 5) fire up the haclient.py, create a new primitive resource, scroll the list of types, cronjobs should appear is an ocf/heartbeat agent,
>
> 6) specify the user of the crontab to manage, the source file of the block of crontab instructions to enable and disable each time the resource is started and stopped,
>
> 7) fill in the crontab source file on each node with cron instructions to run when the resource is enabled on that node, eventually maintain only one shared copy of the crontab instructions to run on all nodes for which a specific resource is configured to run on,
>
> 8) start the resource, tah-Dah, showtime !
>
>
> # Name:???????????????? cronjobs, an OCF resource agent
> # Version:????????????? 1.2 beta, rc 1
> # Author:?????????????? Eric Defferard <eric.defferard[at]adm.unige.ch>
> # Last modification:??? 30-jun-2008
> # License:????????????? GNU General Public License (GPL) Version 2, June 1991
> #?????????????????????? http://www.gnu.org/licenses/gpl-2.0.txt
> # Copyright:??????????? (c) 2008? Eric Defferard, all rights reserved
> #
> #====================================================================================
> #
> # description:
> # Enables and disables as cron jobs, those cron job entries listed in a source file
> # which path is specified as parameter.
> #
> # The cron jobs are copied in the cron table of the user specified also as parameter.
> #
> # Unless an existing crontab entry is repeated exactly in a cron job source file,
> # the agent *preserves* all cron job entries previously configured in the user's
> # cron table.
> #
> # If a crontab file corruption is detected, the agent will automatically attempt to
> # fix the crontab by removing from the crontab *all* job entries specified in the
> # instance's cron job source file.
> #
> # Dillon cron (dcron) supported as hard coded default.
> #
> # OCF instance parameters:
> # - OCF_RESKEY_crontabusr
> # - OCF_RESKEY_crontabsrc
> #
> # OCF environment variables
> # - OCF_ROOT, expected, no defaults.
> #
> # config file:
> # - cronjobs.cf:
> # Search order: /etc/ha.d/cronjobs.cf, /etc/ha.d/conf/cronjobs.cf.
> # Contains the user specification of the crontab 'list' and 'replace' operations
> # to support different cron implementations while keeping the code independent,
> # as well as a 'logger' substitution operation for the ocf_log() function
> # called by default.
> #
> # The user specified 'logger' operation was prompted as a quick user-manageable
> # dynamic fix if user shys away from the "unfinished" or "to be improved" state
> # of the implementation of the ocf_log() function and underlying APIs.
> #
> # The required attributes for a config file are:
> # - must be a plain text file
> # - must be NON-world writeable, non-executable
> # - it's directory must be non-writeable
> #
> # Uses @@ encapsulated tokens that are automagically substituted
> # with real values passed as OCF instance parameters (see above), or
> # other values handled by the agent.
> #
> # Header:
> #
> # Configuration file for the 'cronjobs' OCF resource agent.
> #
> # Format: op = command , or
> # log_env_var = value
> #
> # Syntax:
> # - 'op' is:
> # - the crontab operation to specify
> # - 'list'
> # - 'replace', or
> # - the logging command that, if defined, shall be invoked
> # in place of, or following any routine call in this agent
> # to the standard ocf_log() function.
> # - 'logger'
> # - eval'd in place of call to ocf_log()
> # - '+logger'
> # - eval'd immediately following call to ocf_log()
> #
> # - 'command' is the exact command line that would be typed to
> # invoke the crontab operation
> #
> # - '=' is the operation or variable delimiter
> #
> # - '@user@' is the token used to specify where in the command line
> # the token should be substituted with the crontab user,
> # in both command lines used respectively to invoke
> # the 'list' and the 'replace' crontab operations, immediately
> # before the command line is eval'ed.
> #
> # - '@file@' is the token used to specify where in the command line
> # the token should be substituted with the crontab job
> # source file, specifically in the command line used to
> # invoke the 'replace' crontab operation.
> #
> # - '@msg@' is the token used to specify where in the specific 'logger'
> # command line the token should be substituted with the message that
> # is to be logged.
> #
> # - '@pri@' is the token used to specify where in the specific 'logger'
> # command line the token should be substituted with the syslog
> # priority that is to be assigned to a message that is to be logged.
> #
> # - '#', when the first non-blank character encountered in a line,
> # used to comment out the whole line.
> #
> # - '\', when the last non-blank character encountered in a line,
> # indicates the next line is the continuation of the current line.
> #
> # implementation notes:
> #
> #?? - originally thought of a task that would comment out and uncomment cron jobs
> #?? in the crontabs but realized there was then no reliable way to distinguish
> #?? those permanent jobs from those dependent on heartbeat controlled resources.
> #
> #?? - the config file is read using the bash 'read' command
> #
> #?? - uses internally those log priority level names specified for BSD 4.3 syslog,
> #?? before eventually converting the names to what APIs may require.
>
> Enjoy !
>
>
>
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

pica1dilly at yahoo

Jul 14, 2008, 6:34 AM

Post #5 of 22 (1146 views)
Permalink

Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

> Would you mind making the script compatible with /bin/sh?
> Many thanks for the contribution.
> Cheers,
> Dejan

I can try.
I suppose you are thinking of v7 sh rather than posix.

It'll have to wait 2-3 weeks though, as I'm tying to push my mysql instance control out with it's OCF resource agent.

Got any good links to bash2sh guidelines or rules ?

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Jul 15, 2008, 6:18 AM

Post #6 of 22 (1129 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Mon, Jul 14, 2008 at 06:34:19AM -0700, Joe Bill wrote:
> > Would you mind making the script compatible with /bin/sh?
> > Many thanks for the contribution.
> > Cheers,
> > Dejan
>
> I can try.
> I suppose you are thinking of v7 sh rather than posix.
>
> It'll have to wait 2-3 weeks though, as I'm tying to push my mysql instance control out with it's OCF resource agent.
>
> Got any good links to bash2sh guidelines or rules ?

There's a tool in Debian which finds bashisms:

checkbashisms(1)

It should find most of bash features. Otherwise, I don't know any
conversion guides. You should be able to find shell references on
Internet. If in doubt, please ask on the list.

Cheers,

Dejan
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Jul 16, 2008, 3:00 PM

Post #7 of 22 (1112 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On 2008-07-15T15:18:26, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:

> There's a tool in Debian which finds bashisms:
>
> checkbashisms(1)
>
> It should find most of bash features. Otherwise, I don't know any
> conversion guides. You should be able to find shell references on
> Internet. If in doubt, please ask on the list.

We pull in XML libraries, python, perl, tls, not to mention that the
cluster will usually be hosting an actual application or several, but
then try to not require bash - a package which is smaller than even the
heartbeat package.

That is, sorry, a complete waste of time. I never understood why the
project even bothered, and figure it must be some archaic time where
bash was not universally available.

Just put bash into the default dependencies and be done with it.

Sorry if that sounds harsh, but we really have more important topics ;-)

Regards,
Lars

--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

matt at soffen

Jul 16, 2008, 5:42 PM

Post #8 of 22 (1113 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

The main reason for not wanting bash was for the Non Linux
architectures (i.e. *BSD and Solaris).

Yes, its a readily available but since it isn't standard and sh
is, whats the big deal ?

Desiging/coding for sh (not for bash) means maximum portability.

Matt

At 06:00 PM 7/16/2008, you wrote:

>That is, sorry, a complete waste of time. I never understood why the
>project even bothered, and figure it must be some archaic time where
>bash was not universally available.
>
>Just put bash into the default dependencies and be done with it.
>
>Sorry if that sounds harsh, but we really have more important topics ;-)

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

pica1dilly at yahoo

Jul 17, 2008, 1:32 AM

Post #9 of 22 (1105 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

--- On Tue, 7/15/08, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:

> > I can try.
> > I suppose you are thinking of v7 sh rather than posix.

Can I rely on the sh to include the posix extensions ?

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

t.d.lee at durham

Jul 17, 2008, 3:15 AM

Post #10 of 22 (1097 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Thu, 17 Jul 2008, Lars Marowsky-Bree wrote:

> We pull in XML libraries, python, perl, tls, not to mention that the
> cluster will usually be hosting an actual application or several, but
> then try to not require bash - a package which is smaller than even the
> heartbeat package.
>
> That is, sorry, a complete waste of time. I never understood why the
> project even bothered, and figure it must be some archaic time where
> bash was not universally available.

Let's split this into 'history' and 'current', because I think there may
be differences, recognition of which might pull our thoughts together
towards closer harmony.

History:

The _history_ is that the GNU Coding Standards 7.2.2 still (10 June 2008
revision) state:
"Don't use any special features of ksh or bash, or posix features not
widely supported in traditional Bourne sh."

This is in the context of Makefiles, but its underlying principle is about
(non-)availability of software across the wide range of UNIX-like systems.

So to keep 'heartbeat' portable (and not fall into the Microsoft "We are
the only world" mentality), that led to the historical decisions about
requiring Bourne-only programming.

Hence the explanation (good, I think) for a relatively conservative
approach to programming the portability of 'heartbeat'.

Current:

That was then, and this is now. In those early days, Solaris (and other
OSes) didn't have bash. These days, the currently supported versions of
Solaris do have bash available (but I don't know about other OSes).

I hope we still try to follow portability principles (i.e. to avoid the
Microsoft world-domination mindset) where reasonably possible.

The outcomes of those principles themselves evolve. That evolution seems
to be what the current discussion is about.

Towards conclusions:

"Should the project now assume 'bash'?" is a worthwhile question for Lars
to ask.

Solaris: I think assuming 'bash' would now (unlike back then) be
reasonable; 'bash' has been distributed since Solaris 2.8. In my early
'heartbeat' days, I was working on 2.6 and 2.7 which didn't have bash.

*BSD: that needs Matt Soffen to indicate whether currently supported *BSDs
have 'bash' (or something like it) reasonably available.

Darwin. it's on our list of 'heartbeat' OSes. Anyone have any knowledge
of current versions and 'bash'?

Commerical OSes often need to have long support periods, perhaps
approaching a decade (or more).

Whatever the outcome, the first line (the "#!...") of a script *must*
accurately reflect which shell is wanted. If a script includes bashisms
then it should at least start "#!/bin/bash", not "#!/bin/sh".

Hope that helps.

Changing subject a little, but reltaed principles:

For the record: a few months ago I put in a couple of patches to the Hg
repository to try to persuade it to work with a Sun compiler.

Lars expressed his concern about this, wondering whether we simply say
"heartbeat requires gcc". Lars's thought was a good thought.

And in retrospect I think I would agree with Lars about 'gcc'. (So feel
free to back out my patches.)

--

: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: UNIX Team Leader Durham University :
: South Road :
: http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

beekhof at gmail

Jul 17, 2008, 4:41 AM

Post #11 of 22 (1096 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Thu, Jul 17, 2008 at 12:15, David Lee <t.d.lee[at]durham.ac.uk> wrote:

> Darwin. it's on our list of 'heartbeat' OSes. Anyone have any knowledge
> of current versions and 'bash'?

bash is the default shell on darwin
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Jul 17, 2008, 3:43 PM

Post #12 of 22 (1085 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On 2008-07-16T20:42:28, Matthew Soffen <matt[at]soffen.com> wrote:

> The main reason for not wanting bash was for the Non Linux architectures
> (i.e. *BSD and Solaris).
>
> Yes, its a readily available but since it isn't standard and sh is, whats
> the big deal ?
>
> Desiging/coding for sh (not for bash) means maximum portability.

We've had incidents where people sh-ified scripts such as drbd, which is
plain pointless, as that is only available on Linux.

Compared to the other stuff we pull in, I really, really, really don't
get it.

Regards,
Lars

--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

beekhof at gmail

Jul 18, 2008, 12:52 AM

Post #13 of 22 (1073 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Jul 18, 2008, at 12:43 AM, Lars Marowsky-Bree wrote:

> On 2008-07-16T20:42:28, Matthew Soffen <matt[at]soffen.com> wrote:
>
>> The main reason for not wanting bash was for the Non Linux
>> architectures
>> (i.e. *BSD and Solaris).
>>
>> Yes, its a readily available but since it isn't standard and sh is,
>> whats
>> the big deal ?
>>
>> Desiging/coding for sh (not for bash) means maximum portability.
>
> We've had incidents where people sh-ified scripts such as drbd,
> which is
> plain pointless, as that is only available on Linux.
>
> Compared to the other stuff we pull in, I really, really, really don't
> get it.

agreed

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

beekhof at gmail

Jul 18, 2008, 12:56 AM

Post #14 of 22 (1075 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Jul 17, 2008, at 5:48 PM, David Lee wrote:

> On Thu, 17 Jul 2008, Andrew Beekhof wrote:
>
>> On Jul 17, 2008, at 2:20 PM, Raoul Bhatia [IPAX] wrote:
>>
>>> Andrew Beekhof wrote:
>>>> On Thu, Jul 17, 2008 at 12:15, David Lee <t.d.lee[at]durham.ac.uk>
>>>> wrote:
>>>>
>>>>> Darwin. it's on our list of 'heartbeat' OSes. Anyone have any
>>>>> knowledge
>>>>> of current versions and 'bash'?
>>>>
>>>> bash is the default shell on darwin
>>>
>>> ack - don't know the version thou.
>>> will try to get that information
>>
>>
>> GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)
>> Copyright (C) 2005 Free Software Foundation, Inc.
>
> Looks promising. Thanks, Andrew.
>
> I suppose the real question is a pair:
> (a) What is the earliest version of darwin that we need to support?

Technically we don't _need_ to support any version.
It just happens that I do most of the development there and so
anything that doesn't work tends to get fixed.

Tiger (the current version minus one) is the oldest one that I'd
bother caring about and it also has bash as the default.
Prior to that bash was available but not the default (but more
importantly the peer pid stuff used by the IPC code wasn't functional
back then).

>
> (b) Does that version of darwin have a reasonable 'bash'?
>
>
> By example, taking the Solaris equivalent (which is what I know a
> little
> about):
>
> A few years ago that would have been: "(a) Solaris 2.6; (b) no easy
> bash".
> Nowadays: "(a) Solaris 2.8 (probably 2.9). (b) Decent bash since
> 2.8".
>
>
>
> So a migration to assume availability of bash is looking promising.
>
>
> --
>
> : David Lee I.T. Service :
> : Senior Systems Programmer Computer Centre :
> : UNIX Team Leader Durham University :
> : South Road :
> : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE :
> : Phone: +44 191 334 2752 U.K. :
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Jul 18, 2008, 3:01 AM

Post #15 of 22 (1072 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Thu, Jul 17, 2008 at 12:00:52AM +0200, Lars Marowsky-Bree wrote:
> On 2008-07-15T15:18:26, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:
>
> > There's a tool in Debian which finds bashisms:
> >
> > checkbashisms(1)
> >
> > It should find most of bash features. Otherwise, I don't know any
> > conversion guides. You should be able to find shell references on
> > Internet. If in doubt, please ask on the list.
>
> We pull in XML libraries, python, perl, tls, not to mention that the
> cluster will usually be hosting an actual application or several, but
> then try to not require bash - a package which is smaller than even the
> heartbeat package.

The bash shell is also around ten times bigger and more complex
then a POSIX compatible shell. That should also be taken into
account.

> That is, sorry, a complete waste of time. I never understood why the
> project even bothered, and figure it must be some archaic time where
> bash was not universally available.
>
> Just put bash into the default dependencies and be done with it.
>
> Sorry if that sounds harsh, but we really have more important topics ;-)
>
>
> Regards,
> Lars
>
> --
> Teamlead Kernel, SuSE Labs, Research and Development
> SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Jul 18, 2008, 3:03 AM

Post #16 of 22 (1074 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Thu, Jul 17, 2008 at 01:32:42AM -0700, Joe Bill wrote:
> --- On Tue, 7/15/08, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:
>
> > > I can try.
> > > I suppose you are thinking of v7 sh rather than posix.
>
> Can I rely on the sh to include the posix extensions ?

I think that should be safe.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Jul 18, 2008, 3:10 AM

Post #17 of 22 (1072 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Fri, Jul 18, 2008 at 12:43:32AM +0200, Lars Marowsky-Bree wrote:
> On 2008-07-16T20:42:28, Matthew Soffen <matt[at]soffen.com> wrote:
>
> > The main reason for not wanting bash was for the Non Linux architectures
> > (i.e. *BSD and Solaris).
> >
> > Yes, its a readily available but since it isn't standard and sh is, whats
> > the big deal ?
> >
> > Desiging/coding for sh (not for bash) means maximum portability.
>
> We've had incidents where people sh-ified scripts such as drbd, which is
> plain pointless, as that is only available on Linux.

It's not just the availability of bash. For example, the next
Debian version will have dash (a POSIX compliant shell) as
default. I think that Ubuntu has already done that.

> Compared to the other stuff we pull in, I really, really, really don't
> get it.

I'd also prefer that there's a wider audience for the scripts
we deliver. Given the zillion interesting features in the bash,
which I'm sure will fairly soon proliferate in heartbeat, we'll
have a bunch of scripts understandable only by a minority. Also,
who guarantees that those feature, which are not standardized
anywhere, will behave in the same way on different bash versions.

I'm strongly against moving to bash as a standard. We can switch
from Bourne shell to POSIX shell, though.

Thanks,

Dejan

>
> Regards,
> Lars
>
> --
> Teamlead Kernel, SuSE Labs, Research and Development
> SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

beekhof at gmail

Jul 18, 2008, 3:49 AM

Post #18 of 22 (1073 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Fri, Jul 18, 2008 at 12:01, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:
> On Thu, Jul 17, 2008 at 12:00:52AM +0200, Lars Marowsky-Bree wrote:
>> On 2008-07-15T15:18:26, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:
>>
>> > There's a tool in Debian which finds bashisms:
>> >
>> > checkbashisms(1)
>> >
>> > It should find most of bash features. Otherwise, I don't know any
>> > conversion guides. You should be able to find shell references on
>> > Internet. If in doubt, please ask on the list.
>>
>> We pull in XML libraries, python, perl, tls, not to mention that the
>> cluster will usually be hosting an actual application or several, but
>> then try to not require bash - a package which is smaller than even the
>> heartbeat package.
>
> The bash shell is also around ten times bigger and more complex
> then a POSIX compatible shell. That should also be taken into
> account.

however given that we already require python, e2fsprogs, libxml2,
gnutls, libxslt, glade, etc etc, the difference is a comparative drop
in the ocean
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Jul 18, 2008, 7:46 AM

Post #19 of 22 (1072 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Fri, Jul 18, 2008 at 12:49:20PM +0200, Andrew Beekhof wrote:
> On Fri, Jul 18, 2008 at 12:01, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:
> > On Thu, Jul 17, 2008 at 12:00:52AM +0200, Lars Marowsky-Bree wrote:
> >> On 2008-07-15T15:18:26, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:
> >>
> >> > There's a tool in Debian which finds bashisms:
> >> >
> >> > checkbashisms(1)
> >> >
> >> > It should find most of bash features. Otherwise, I don't know any
> >> > conversion guides. You should be able to find shell references on
> >> > Internet. If in doubt, please ask on the list.
> >>
> >> We pull in XML libraries, python, perl, tls, not to mention that the
> >> cluster will usually be hosting an actual application or several, but
> >> then try to not require bash - a package which is smaller than even the
> >> heartbeat package.
> >
> > The bash shell is also around ten times bigger and more complex
> > then a POSIX compatible shell. That should also be taken into
> > account.
>
> however given that we already require python, e2fsprogs, libxml2,
> gnutls, libxslt, glade, etc etc, the difference is a comparative drop
> in the ocean

We are talking about different metrics. All monitor operations
require a fork of a shell. And that probably more than once. The
leaner the shell the better the performance. It also looks like,
though I'm not entirely happy with that, that people tend to use
more rather than less monitors and to schedule them very
frequently (once a second? anybody?). And, unfortunately, a
better monitor API/interface is still far away for most
resource types.

bash is excellent as an interactive shell, but there's really no
need to use it to manage resources.

Cheers,

Dejan
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Jul 18, 2008, 8:32 AM

Post #20 of 22 (1068 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On 2008-07-18T16:46:49, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:

> We are talking about different metrics. All monitor operations
> require a fork of a shell.

... which incidentially is also something we eventually need to fix, and
either fork a daemon when the RA starts (which then would talk to the
LRM directly), or have a "monitor-loop" extension which keeps running
and simply writes "ok" every so often to stdout or "failed" when it's
gone down.

We really need to avoid forking completely.

> And that probably more than once. The leaner the shell the better the
> performance. It also looks like, though I'm not entirely happy with
> that, that people tend to use more rather than less monitors and to
> schedule them very frequently (once a second? anybody?).

Well, obviously, they want them to detect failures quickly; no other
way.

The shell scripts then also call out to many scripts and binaries
anyway, so whether or not bash gets forked really doesn't matter.

While I see your point, but I'd much rather have a RA written in bash
than none at all for some service, and the submitter gets to chose the
language (or shell).

> And, unfortunately, a better monitor API/interface is still far away
> for most resource types.

It's trivial once someone did it ;-)

Anyway, this discussion is already going on for longer than its worth,
and I apologize for starting it. My fault, but it proves the bikeshed
doctrine ;-)

Regards,
Lars

--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Jul 20, 2008, 8:59 AM

Post #21 of 22 (1028 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On Fri, Jul 18, 2008 at 05:32:06PM +0200, Lars Marowsky-Bree wrote:
> On 2008-07-18T16:46:49, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:
>
> > We are talking about different metrics. All monitor operations
> > require a fork of a shell.
>
> ... which incidentially is also something we eventually need to fix, and
> either fork a daemon when the RA starts (which then would talk to the
> LRM directly), or have a "monitor-loop" extension which keeps running
> and simply writes "ok" every so often to stdout or "failed" when it's
> gone down.
>
> We really need to avoid forking completely.

I couldn't agree more, but how are we to do that. We could
deal with one class of monitoring for process existence, and NTT
already provided something similar. For other kinds of monitors,
which are more resource specific we would need some kind of
cooperation from the resource itself. That doesn't exist. And I
don't see it on anybody's todo list. Or am I missing something?

> > And that probably more than once. The leaner the shell the better the
> > performance. It also looks like, though I'm not entirely happy with
> > that, that people tend to use more rather than less monitors and to
> > schedule them very frequently (once a second? anybody?).
>
> Well, obviously, they want them to detect failures quickly; no other
> way.
>
> The shell scripts then also call out to many scripts

which also need an interpreter, which is why I wrote that the
shell is forked "probably more than once".

> and binaries
> anyway, so whether or not bash gets forked really doesn't matter.
>
> While I see your point, but I'd much rather have a RA written in bash
> than none at all for some service, and the submitter gets to chose the
> language (or shell).

That's fine, until we ship the RA and then it's up to us to
maintain it and resolve customer issues.

> > And, unfortunately, a better monitor API/interface is still far away
> > for most resource types.
>
> It's trivial once someone did it ;-)

:-D

> Anyway, this discussion is already going on for longer than its worth,
> and I apologize for starting it. My fault, but it proves the bikeshed
> doctrine ;-)

The famous one. This time it's not, at least not for me.

Thanks,

Dejan

>
> Regards,
> Lars
>
> --
> Teamlead Kernel, SuSE Labs, Research and Development
> SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Jul 23, 2008, 9:35 AM

Post #22 of 22 (952 views)
Permalink

Re: Re: cronjobs v1.2 rc1 OCF resource agent now available [In reply to]

On 2008-07-20T17:59:21, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:

> > ... which incidentially is also something we eventually need to fix, and
> > either fork a daemon when the RA starts (which then would talk to the
> > LRM directly), or have a "monitor-loop" extension which keeps running
> > and simply writes "ok" every so often to stdout or "failed" when it's
> > gone down.
> >
> > We really need to avoid forking completely.
>
> I couldn't agree more, but how are we to do that. We could
> deal with one class of monitoring for process existence, and NTT
> already provided something similar. For other kinds of monitors,
> which are more resource specific we would need some kind of
> cooperation from the resource itself. That doesn't exist. And I
> don't see it on anybody's todo list. Or am I missing something?

Apparently you missed that I described two ways of doing it just above.
;-) I have been going on about this for quite awhile, and there's an
enhancement request in the LF bugzilla for ages. I think it is assigned
to you ;-)

It's not exceptionally high priority, but it would be cool.

Regards,
Lars

--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com