Apache resource agent broken in Debian lenny

Hi,

If I should have written this to the Debian package
maintainer, my bad,
but since there's a debian/ subdirectory in the source tree,
I thought
this might interest you.

The latest apache2.2-common update in Debian lenny (2.2.9-5)
breaks the
hearbeat ocf resource agent heuristics that determine what
user to run
it as and where to put the pid file. The apache2.conf now
sports

PidFile $
User $
Group $

instead of the actual place and user/group ids, which are
specified in
/etc/apache2/envvars like so:

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
export APACHE_PID_FILE=/var/run/apache2.pid

Since the resource agent basically greps the apache
configuration for
these, it ends up using $, and since
/etc/apache2/envvars is never read, leaves them empty -
which makes the
whole thing fail miserably.

In principle, the fix for this is trivial - the resource
agent just has
to do something like

if [ -e /etc/apache2/envvars ]; then
    . /etc/apache2/envvars
fi

before the action starts - this is what /etc/init.d/apache2
does.
However, I am unsure whether hardcoding it in this manner is
the right
way to go - it might be prudent to make it a runtime
variable like
OCF_RESKEY_configfile, only to be loaded if specified.

What do you think?

Regards,

Florian Knauf
_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Hi,

On Sat, Jul 19, 2008 at 09:41:29PM +0200, Florian Knauf
wrote:
> Hi,
> 
> If I should have written this to the Debian package
maintainer, my bad,
> but since there's a debian/ subdirectory in the source
tree, I thought
> this might interest you.

This is the right place to discuss all heartbeat
development
related issues.

> The latest apache2.2-common update in Debian lenny
(2.2.9-5) breaks the
> hearbeat ocf resource agent heuristics that determine
what user to run
> it as and where to put the pid file. The apache2.conf
now sports
> 
> PidFile $
> User $
> Group $
> 
> instead of the actual place and user/group ids, which
are specified in
> /etc/apache2/envvars like so:
> 
> export APACHE_RUN_USER=www-data
> export APACHE_RUN_GROUP=www-data
> export APACHE_PID_FILE=/var/run/apache2.pid
> 
> Since the resource agent basically greps the apache
configuration for
> these, it ends up using $, and since
> /etc/apache2/envvars is never read, leaves them empty -
which makes the
> whole thing fail miserably.
> 
> In principle, the fix for this is trivial - the
resource agent just has
> to do something like
> 
> if [ -e /etc/apache2/envvars ]; then
>     . /etc/apache2/envvars
> fi

The fix is not that trivial: the apache would understand,
but the
RA wouldn't, because it parses the apache configuration
without
expanding variables.

> before the action starts - this is what
/etc/init.d/apache2 does.
> However, I am unsure whether hardcoding it in this
manner is the right
> way to go - it might be prudent to make it a runtime
variable like
> OCF_RESKEY_configfile, only to be loaded if specified.
> 
> What do you think?

Thanks for bringing this up.

I'm not sure if we should deal with this at all in
heartbeat.
Trying to support all the new setups and distributions, it
may
become a nightmare. For the maintenance too: dealing with
the
apache configuration is already rather complex and I'm
really
reluctant to make it more so. However, since apache now
supports
variables in the config and that may become a norm in
future,
perhaps we should support environment variables too. Sigh.

Another option may be to kindly ask the apache people to
provide
some facility to query the server configuration.

In the meantime, just don't use environment variables in
the
configuration.

Can you please file an enhancement bugzilla.

Cheers,

Dejan

> Regards,
> 
> Florian Knauf
>
_______________________________________________________
> Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On 2008-07-20T17:30:20, Dejan Muhamedagic <dejanmmfastmail.fm> wrote:

> I'm not sure if we should deal with this at all in
heartbeat.
> Trying to support all the new setups and distributions,
it may
> become a nightmare. For the maintenance too: dealing
with the
> apache configuration is already rather complex and I'm
really
> reluctant to make it more so. However, since apache now
supports
> variables in the config and that may become a norm in
future,
> perhaps we should support environment variables too.
Sigh.

The first step is to allow a manual setting of everything
which is
normally retrieved from auto-detection; validate-all could
at least be
able to identify if some variable isn't in the right format
(ie,
auto-detection failed), and then flag a request to specify
it.

If people then use ocf-tester before adding something to
their
configuration, they'll find out quickly 

> Another option may be to kindly ask the apache people
to provide
> some facility to query the server configuration.

Yes, that I guess would be good too. It's not our job to
parse arbitrary
configuration files which happen to be in such inconvenient
formats -
they really should switch to XML. *ducks & runs* 


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-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Hi,

>> In principle, the fix for this is trivial - the
resource agent just has
>> to do something like
>>
>> if [ -e /etc/apache2/envvars ]; then
>>     . /etc/apache2/envvars
>> fi
> 
> The fix is not that trivial: the apache would
understand, but the
> RA wouldn't, because it parses the apache configuration
without
> expanding variables.

Well, it worked for me. I can see how it could cause
problems with
variable expansion, though - it's really something of a
dirty hack this way.

> I'm not sure if we should deal with this at all in
heartbeat.
> Trying to support all the new setups and distributions,
it may
> become a nightmare.

True, that can be quite problematic. The initng project had
major
problems with precisely that - it was messy, let me tell
you.

Mind you, with the plethora of services that someone might
want to
cluster, I expect admins usually wind up writing their own
agents for
most of them, anyway. Excepting the most basic ones (like,
say, drbd),
it might not be feasible to provide anything beyond
"This worked for
someone, maybe you can tweak it to your needs," anyway.
In the context
of debian packages, this might mean declaring everything in
/usr/lib/ocf/resource.d/heartbeat a configuration file, so
that future
updates don't overwrite any custom changes that might have
been applied.

However...

> For the maintenance too: dealing with the
> apache configuration is already rather complex and I'm
really
> reluctant to make it more so. However, since apache now
supports
> variables in the config and that may become a norm in
future,
> perhaps we should support environment variables too.
Sigh.
> 
> Another option may be to kindly ask the apache people
to provide
> some facility to query the server configuration.

>From what I can see, the apache RA basically replicates 
functionality
that's already part of apache2ctl - which is supposed to be
used to
start, stop and control apache, anyway. Apache2ctl evaluates
the envvars
file if it finds it, and uses appropriate default values or
shell
overrides if it doesn't. I think this and all related
problems would
vanish if the resource agent used it instead of calling the
apache
binary directly, and it would make the whole thing a _lot_
simpler.

> Can you please file an enhancement bugzilla.

I will, but I'd like to run some tests with apache2ctl first
to make
sure I'm correct about the above paragraph. If I find the
time, I may
write a proof-of-concept RA, although I probably won't be
able to test
that before next weekend - I'll have to remember how I built
that
virtual testing cluster last time. 

In other words, I'll get it into bugzilla as soon as I'm
sure what I
write is correct.

Regards,

Florian Knauf

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

On 2008-07-20T21:40:12, Florian Knauf <f.knaufmmkf.de> wrote:

> From what I can see, the apache RA basically replicates
 functionality
> that's already part of apache2ctl - which is supposed
to be used to
> start, stop and control apache, anyway. Apache2ctl
evaluates the envvars
> file if it finds it, and uses appropriate default
values or shell
> overrides if it doesn't. I think this and all related
problems would
> vanish if the resource agent used it instead of calling
the apache
> binary directly, and it would make the whole thing a
_lot_ simpler.

Oh, I totally approve!

Be our hero, submit a patch  If we
meet, pizza is on me!


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-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Lars Marowsky-Bree schrieb:

> Oh, I totally approve!
> 
> Be our hero, submit a patch  If we
meet, pizza is on me!

Well, alright. Who can say no to pizza? :-D

I attached a pre-alpha, untested,
do-not-use-in-production-unless-you-are-a-complete-lunatic
version of
what I have in mind. I hacked it together just now in a very
short time,
after a stressful day involving a failing mail relay and a
very
bureaucratic telephone company, but it should give you a
rough idea of
where I'm going with this, and whether you like the general
approach.

Scroll past the metadata (which I blatantly copied from the
old script)
to get to the action. The idea pretty much is to set some
environment
variables and outsource all the real work to apache2ctl,
then deal with
its results.

Also, I have one question - the current apache RA has a
status command,
which apparently checks whether the process in the pid file
is running.
I couldn't find this at http://www.l
inux-ha.org/OCFResourceAgent , and
it does seem to serve pretty much the same ends as monitor,
so I clipped
it for now. Is this a horrible idea because the status
command is
absolutely essential for the script to function, or am I
within my
rights there?

Regards,

Florian Knauf

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

Hi,

Dejan Muhamedagic schrieb:

> Can you please file an enhancement bugzilla.

It is done:

http://developerbugs.linux-foundation.org/show_bug
.cgi?id=1943

Regards,

Florian Knauf
_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/