OpenNebula

Let me elaborate a bit..

$ONE_LOCATION/etc should instead be /etc/one.
$ONE_LOCATION/lib should instead be /usr/lib/one.

• Any command that you expect the user to call directly (onevm, onevnet, etc) should go in /usr/bin/.
• Commands that are meant to be used internally by OpenNebula should go in /usr/lib/opennebula somewhere (such as one_vmm_*, etc.).
• It doesn't seem to be the case right now, but if OpenNebula at some point has commands that are meant to be called by the user that is a wrapper around a ruby script (like one_im_ec2 is), the wrapper belongs in /usr/bin, while the wrapped script (e.g. one_im_ec2.rb) should go in /usr/lib/one

Proposed file layout.

/usr
    /bin: onevm, onehost, onevnet
    /sbin: oned, scheduler and one script
    /lib
        /one: files that are now in /lib
            /mads: mad files that now reside in /bin and also /libexec
    /share: files from share
/etc
    /one: /etc files
/var
    /lib/one: /var files except daemon logs
    /log/one: daemon log files from /var

I just attached FHS.diff which is a patch I've used locally to implement this. It hardcodes lots of stuff that is likely not acceptable for you, but I figured I'd share it regardless.

Changeset r294 in the trunk implements the changes. I've just followed soren's patch so it was really easy, the hard work was already in the patch ;).

Basically, both installation modes are available so you can still place OpenNebula under $ONE_LOCATION. Some changes have been introduced in the original layout to make it more coherent, and so you can now use the same config files regardless of the installation mode ($ONE_LOCATION or root). Also the install.sh script has been improved to handle both installations and to easily remove OpenNebula from the system.

• no files are installed in /usr/sbin because all the programs are meant to be executed by the same user. Although this may change in the future.

• VM log files are in /var/log/one/<$VM_ID>.log

• Also we have /var/run/one directory and the lock file is in /var/lock

We can close the ticket when the documentation is updated to include the new functionality (and some more testing is made)

Replying to [comment:5 ruben]:

Changeset r294 in the trunk implements the changes. I've just followed soren's patch so it was really easy, the hard work was already in the patch ;).

Basically, both installation modes are available so you can still place OpenNebula under $ONE_LOCATION. Some changes have been introduced in the original layout to make it more coherent, and so you can now use the same config files regardless of the installation mode ($ONE_LOCATION or root). Also the install.sh script has been improved to handle both installations and to easily remove OpenNebula from the system.

Some minor modifications to the proposed layout:

• no files are installed in /usr/sbin because all the programs are meant to be executed by the same user. Although this may change in the future.

• VM log files are in /var/log/one/<$VM_ID>.log

• Also we have /var/run/one directory and the lock file is in /var/lock

We can close the ticket when the documentation is updated to include the new functionality (and some more testing is made)

This actually just moves the problem a tiny bit.. It all comes down to the way Debian (and hence Ubuntu) packages are built. Let me explain:

The package is configured according to the FHS, so that all the correct paths are compiled into the binaries. Typically, this means that they look for configuration files in /etc, put log files in /var/log, etc. (note the absolute paths).
After building the package, we install the files into an install directory, typically debian/<packagename>. Everything in there is then tar'ed up and put into the .deb package (the tarball embedded in the .deb obviously doesn't have the debian/<packagename> part of the path). This is usually accomplished by passing a DESTDIR variable to "make install", so that anything it would otherwise have put in /usr/bin, it puts in $DESTDIR/usr/bin, for instance.
When the .deb is installed, that tarball is basically extracted in the system's root directory (this is not strictly true, since dpkg performs lots of sanity checks, but for the purpose of this discussion, it's mostly accurate), and everything is now in the right place.

• It now respects a DESTDIR variable (consistent with (I believe) the vast majority of modern software packages out there.
• Renamed the existing DST_DIR variable to ROOTDIR to alleviate confusion between DST_DIR and DESTDIR
• Added extra directories to MAKE_DIRS in the [ -z "$ROOT" ] case, since stuff like /usr/include and /usr/bin don't necessarily exist. This could easily be done in the packaging code, but it doesn't seem inappropriate in the install.sh, so I included it here, too.

I'll post a patch shortly.