HACMP and the "copy" command: Bug or design issue?

HACMP and the "copy" command: Bug or design issue?

Post by Kevin R. Ge » Sun, 18 Jul 1999 04:00:00



A warning to others and a issue for IBM:

I recently had an issue with an HACMP 4.2.2 cluster, where I found that
the acquire_service_addr and acquire_takeover_addr scripts reference
the "copy" command instead of the more traditional "cp" command.

IBM Support indicates that bos.compat.cmds should be installed with any
system running HACMP (in this case, we have version 4.2.2).  The
problem is that MOST AIX systems do not have the bos.compat.cmds
fileset installed (so that any calls to these scripts will give errors
unless bos.compat.cmds is installed).

The circumstances behind this was that the machines were installed by a
3rd party and I found the error while validating the installation.

My issue is that if HACMP requires the bos.compat.cmds fileset, then
attempts to install HACMP should fail if the system lacks this fileset
(installp provides the opportunity, I believe, to define
prerequisites), OR provide some sort of documentation indicating that
the fileset is required.  Either that, or the HACMP developers should
just use the standard "cp" command.

However, IBM Support indicates that this is a "design" issue (of
course, I suspect that could just be reluctance on their part to
escalate the problem to development, since IBM development charges AIX
Support for any assistance they have to offer).  Hey, I spent 3.5 years
at IBM and used the old "that's a design issue" many times (but I had a
more solid defense than what I'm being offered in this case, IMHO).

Again, I don't have a big issue in installing the fileset (and I can
always get around the problem by symbolically linking /usr/bin/copy
to /usr/bin/cp).  My whole issue is that I don't always have the option
of installing MYSELF all the HACMP clusters I might have to support at
work.  I've already found one clusters installed by the same 3rd party
where the installer "hacked" the aforementioned scripts to
change "copy" to "cp" (which is why we didn't see the problem on those
clusters) -- a bad kludge that would affect us if we ever installed
HACMP maintenance (which we will shortly have to do), since new
versions of those scripts might be installed with the original problem.

In my opinion, if a product requires the existence of a particular
fileset, then EITHER the installation process for that product (in this
case, the product, the prerequisite, and the installation process are
all from IBM) should flag this, documentation should be written to
indicate this, or the product should NOT use those specific commands.

I can understand how nothing will be changed in the install process or
documentation for HACMP 4.2.2 (but future releases could be altered to
prerequire the installation of bos.compat.cmds or at least document
it).  This is certainly a design issue.  But shouldn't the EXISTING
4.2.2 product be altered to just use the "cp" command?

It's a fine line, to be sure (between "broken-as-designed"
and "broken).  Still, I just wanted to forewarn anyone about to install
a cluster -- install bos.compat.cmds before you start testing,
especially if you have any NFS-mounted file systems that are shared.

Any comments on the design-vs.-bug issue from anyone at IBM?

--
Kevin R. Gee
MS Student, University of Texas at Arlington, Arlington, TX
Senior UNIX Administrator, Origin Technology in Business, Arlington, TX

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

HACMP and the "copy" command: Bug or design issue?

Post by Kevin R. Ge » Tue, 20 Jul 1999 04:00:00


Just wanted to follow up on this:

I got an email back from an IBMer indicating that this was a packaging
bug (yes, he did use the word "bug") with HACMP 4.2.2.  There was a
news release to IBMers informing them about this, but it apparently
hasn't been read by all IBMers.

He indicated that HACMP 4.3.0 no longer has any dependencies on
bos.compat.cmds.

I guess it all depends on who you talk to at IBM (of course, having
worked there once upon a time, I knew that...)

Kevin



Quote:> A warning to others and a issue for IBM:

> I recently had an issue with an HACMP 4.2.2 cluster, where I found
that
> the acquire_service_addr and acquire_takeover_addr scripts reference
> the "copy" command instead of the more traditional "cp" command.

> IBM Support indicates that bos.compat.cmds should be installed with
any
> system running HACMP (in this case, we have version 4.2.2).  The
> problem is that MOST AIX systems do not have the bos.compat.cmds
> fileset installed (so that any calls to these scripts will give errors
> unless bos.compat.cmds is installed).

> The circumstances behind this was that the machines were installed by
a
> 3rd party and I found the error while validating the installation.

> My issue is that if HACMP requires the bos.compat.cmds fileset, then
> attempts to install HACMP should fail if the system lacks this fileset
> (installp provides the opportunity, I believe, to define
> prerequisites), OR provide some sort of documentation indicating that
> the fileset is required.  Either that, or the HACMP developers should
> just use the standard "cp" command.

> However, IBM Support indicates that this is a "design" issue (of
> course, I suspect that could just be reluctance on their part to
> escalate the problem to development, since IBM development charges AIX
> Support for any assistance they have to offer).  Hey, I spent 3.5
years
> at IBM and used the old "that's a design issue" many times (but I had
a
> more solid defense than what I'm being offered in this case, IMHO).

> Again, I don't have a big issue in installing the fileset (and I can
> always get around the problem by symbolically linking /usr/bin/copy
> to /usr/bin/cp).  My whole issue is that I don't always have the
option
> of installing MYSELF all the HACMP clusters I might have to support at
> work.  I've already found one clusters installed by the same 3rd party
> where the installer "hacked" the aforementioned scripts to
> change "copy" to "cp" (which is why we didn't see the problem on those
> clusters) -- a bad kludge that would affect us if we ever installed
> HACMP maintenance (which we will shortly have to do), since new
> versions of those scripts might be installed with the original
problem.

> In my opinion, if a product requires the existence of a particular
> fileset, then EITHER the installation process for that product (in
this
> case, the product, the prerequisite, and the installation process are
> all from IBM) should flag this, documentation should be written to
> indicate this, or the product should NOT use those specific commands.

> I can understand how nothing will be changed in the install process or
> documentation for HACMP 4.2.2 (but future releases could be altered to
> prerequire the installation of bos.compat.cmds or at least document
> it).  This is certainly a design issue.  But shouldn't the EXISTING
> 4.2.2 product be altered to just use the "cp" command?

> It's a fine line, to be sure (between "broken-as-designed"
> and "broken).  Still, I just wanted to forewarn anyone about to
install
> a cluster -- install bos.compat.cmds before you start testing,
> especially if you have any NFS-mounted file systems that are shared.

> Any comments on the design-vs.-bug issue from anyone at IBM?

> --
> Kevin R. Gee

--
Kevin R. Gee
MS Student, University of Texas at Arlington, Arlington, TX
Senior UNIX Administrator, Origin Technology in Business, Arlington, TX

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.