Crowbar is not FHS-compliant

[aspiers]

In a few places, Crowbar violates the FHS (Filesystem Hierarchy Standard). As agreed on the mailing list, let's use this ticket to track all violations and decide the best way to fix them.

Here is the current list of known violations:

• /srv/tftpboot should be used instead of /tftpboot
• /opt/dell/crowbar_framework/log - log files are variable rather than static data, and so are not allowed under /opt. An appropriate alternative would be either /var/log/crowbar_framework or /var/opt/dell/crowbar_framework/log.
• /opt/dell/crowbar_framework/tmp - temporary files are variable rather than static data, and so are not allowed under /opt. It appears that this directory is used for lock files at least, so an appropriate alternative might be /var/run/crowbar_framework or /var/tmp/crowbar_framework or /var/opt/dell/crowbar_framework/tmp.
• /opt/dell/bin/barclamp_*lib.rb should live in /opt/dell/lib or similar.
• /install-logs is not a permitted top-level directory and should be moved under /var/log
• /updates is not a permitted top-level directory - files are copied here from barclamps' updates subdirectories by barclamp_mgmt_lib.rb if they exist; not sure where this belongs
• Various .json files which are effectively configuration files (e.g. bc-network.json) currently live under /opt but should live under /etc/opt.
• /opt/dell/crowbar_framework/.crowbar-installed-ok is touched by both install-chef.sh and install-chef-suse.sh. It should use /var/opt/dell/crowbar_framework/.crowbar-installed-ok or similar. Note that /var/run would be inappropriate since it can be cleared on reboot.

Additionally, Chef violates the /var part of the FHS spec by creating a top-level /var/chef directory. I assume this is probably an issue with how Crowbar configures Chef's path attribute.

[cthiel]

Maybe it would also make sense to enable crowbar to get installed into something else than /opt/dell, to make it more vendor neutral?

[aspiers]

Agreed :) It seems that the FHS allows /opt/<package> as well as /opt/<provider>/<package>, so in this case, moving to /opt/crowbar seems reasonable.

[galthaus]

hmmm - this will take some effort. How important is this?

[aspiers]

Well, the FHS and LSB are fundamental cornerstones of every enterprise Linux distro, so IMHO it's clearly the Right Thing To Do ;-) But of course the standards were formed from practical considerations, so violating them will result in impracticalities. Specific examples which spring to my mind are the breakages which will occur if /opt is mounted read-only, or if security frameworks such as SELinux or AppArmor are configured with policies which prevent creation of new top-level directories and/or modification of files under those directories. And keeping binaries in .../bin cleanly separated from libraries in .../lib will obviously minimise confusion for anyone looking more closely at the code. I'm sure someone more knowledgeable than me in this area could come up with other reasons, perhaps stronger than mine.

I doubt fixing it will require much effort - it's just a case of search and replace. The lead-up to 2.0 sounds like a good window of opportunity to do this, as the other invasive refactoring already planned will require full re-validation of the entire codebase anyway.