On 6/27/07, David Lee <[EMAIL PROTECTED]> wrote:
On Wed, 27 Jun 2007, Lars Marowsky-Bree wrote:> On 2007-06-26T14:10:16, Madison Kelly <[EMAIL PROTECTED]> wrote: > > > Madison Kelly wrote: > > >Filesystem[3233]: 2007/06/25_16:20:07 ERROR: Setup problem: > > >Couldn't find utility fsck > > > > I finally figured this out... Turns out the file: > > /usr/lib/ocf/resource.d/heartbeat/Filesystem had the entry 'FSCK=fsck'. > > Changing that entry to: 'FSCK=/sbin/fsck' made things work. > > There seems to have been a built error here on Debian. > > We've fixed this in hg.linux-ha.org/dev; it'll now additionally search > the path for the command if required. Does that fix happen to be Dejan's "e898fa7b59d3"? Technically, it may work. But I think it is the wrong place for correcting this flaw. Which brings me on to ... Actually, I think we have a deeper problem in the build system, both with a lack of consistency in handling such paths, and in many cases I think deviating from the spirit of autoconf. This may be getting too technical for the general "linux-ha" list, so I'm Cc:ing to "linux-ha-dev", which might be a more appropriate place to follow this up. In autoconf, we widely use "AC_PATH_PROGS(variable,prog-to-check-for)". That's good. Example: AC_PATH_PROGS(PYTHON, python) If the "prog-..." is found, variable is set to the full pathname, otherwise it is not set. That's good and clean. BUT ... we often use the additional, optional "value-if-not-found", which I think we should be cautious about for true portability. And then, worse, we set that to the simple program name; remember that the whole point of "AC_PATH_PROGS" is to set the variable to a full pathname. I suggest we need to rationalise: 1. Wherever possible our autoconf should simply use the basic: AC_PATH_PROGS(variable,prog-to-check-for) If it is not found we leave it blank, and let other code handle the result. Often that other code might be elsewhere in "configure", for instance if the absence of "prog..." is likely to be a show-stopper for all heartbeat installations. Otherwise it could be (for instance) run-time handling of the absence (empty variable) in a shell script. 2. In some cases (such as when we know that a command is highly specific to a particular OS), there may be an argument for "value-if-not-found" being used. I would suggest that this is infrequent. If it really is necessary then it should follow the spirit and be the full pathname. I cannot see any argument for it ever being the simple name. Example 1: Assuming "mdadm" is Linux-specific. If we really need the "value-if-not-found" option (do we really?) then its current: AC_PATH_PROGS(MDADM, mdadm, /sbin/mdadm) would be OK (OS-specific, and the fallback option is a full pathname). Example 2: The current "fsck" is: AC_PATH_PROGS(FSCK, fsck, fsck) I argue that this is clearly wrong: "fsck" is multi-platform so we should use the simple form (without the final ", fsck" clause), and we cannot second guess its location (Linux: /sbin Solaris: /usr/sbin). How does that seem? (In the original poster's problem, if "fsck" was present, then configure should have found it (or there was something flawed with his build process which needs addressing). If it was absent, then simply setting a full pathname isn't going to find it. The thing that is going to use it (or something else in the build process) needs to be able to respond appropriately to its absence.) Thoughts?
My feeling is that we are fundamentally abusing autoconf by having it generate RAs in this manner. Finding out whether we should be using bison, yacc or whatever and defining the result as @YACC@ is one thing, but this nonsense of having it calculate full paths only serves to make shell scripts (of all things) non-portable. There is a mechanism for finding binaries, its called $PATH (which incidentally, needed to be set correctly in order for autoconf to do the right thing anyway). What I would like to see, is that for binaries that require distro-specific options (eg. echo), or have equivalent alternatives (eg. yacc), that we have autoconf generate a _single_ file which can be included by the RAs^. That way if an admin wants a custom value, or we mess up, it is at least centrally defined and continues to be used even if the RA(s) are upgraded. Anything else is required to be in the path and the RA can use lmb's revised check_util() macro and return OCF_ERR_INSTALLED (5) if required binaries are not found. ^ eg. heartbeat/shellfuncs.in which is already included automatically and sets up all the directory locations (which very few RAs make use of for some reason) _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
