Feature #59

Make OpenNebula more FHS friendly

Added by soren-ubuntu-com - over 12 years ago. Updated over 12 years ago.

Status:ClosedStart date:
Priority:HighDue date:
Assignee:Ruben S. Montero% Done:

0%

Category:Core & System
Target version:Release 1.2
Resolution:fixed Pull request:

Description

OpenNebula currently makes it rather difficult to install in a Filesystem Hierarchy Standard compliant way. I'd like OpenNebula's configuration files to all reside in /etc/opennebula or /etc/one, and everything else in /usr/{bin,lib,...}. This is blocking inclusion in e.g. Ubuntu.

FHS.diff Magnifier - FHS patch (52.9 KB) soren-ubuntu-com -, 12/24/2008 12:07 AM

install.sh.diff Magnifier - Proposed patch against install.sh (2.43 KB) soren-ubuntu-com -, 01/07/2009 05:39 PM

Associated revisions

Revision 77681ccf
Added by Ruben S. Montero over 12 years ago

Address ticket #59

git-svn-id: http://svn.opennebula.org/one/trunk@294 3034c82b-c49b-4eb3-8279-a7acafdc01c0

Revision 49ae7960
Added by Tino Vázquez over 12 years ago

Further fixes for Ububntu compliance. Closes ticket #59.

git-svn-id: http://svn.opennebula.org/one/trunk@307 3034c82b-c49b-4eb3-8279-a7acafdc01c0

Revision 066d18a7
Added by Ruben S. Montero over 12 years ago

backport of changsets [306] [307] [308] [309], tickets #65 #59 #67

git-svn-id: http://svn.opennebula.org/one/branches/one-1.2@315 3034c82b-c49b-4eb3-8279-a7acafdc01c0

History

#1 Updated by soren-ubuntu-com - over 12 years ago

Let me elaborate a bit..

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

$ONE_LOCATION/bin should be completely restructured:
  • 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

#2 Updated by Ruben S. Montero over 12 years ago

  • Status changed from New to Assigned

After some discussions with the team we have decided to work on this for the next release of OpenNebula. Currently we are in the 1.2 release cycle (at OpenNebula Beta1). Although introducing this change at this stage may cause some inconveniences and will delay the final 1.2 release, we believe the benefits worths it!. I am targeting this ticket for the 1.2 milestone.

#3 Updated by Javi Fontan over 12 years ago

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

#4 Updated by soren-ubuntu-com - over 12 years ago

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.

#5 Updated by Ruben S. Montero over 12 years ago

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)

#6 Updated by soren-ubuntu-com - over 12 years ago

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.

To accomplish this, I've reworked your install.sh like so:
  • 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.

#7 Updated by Tino Vázquez over 12 years ago

  • Status changed from Assigned to Closed
  • Resolution set to fixed

Diff applied in r307. I'm closing the ticket, if there are further issues please do email mailing list.

Also available in: Atom PDF