relocatable RPM or installing from source?

Jason Brockdorf apocalysque at yahoo.com
Thu Feb 25 23:39:28 CET 2016


Wow, thank you very much for your very thorough and complete response, and
the additional RPM package.

I did find a way to force the (original) RPM to relocate by using the
--badreloc option with RPM.  I was going to try to use symlinks to get it to
work as-is but I'd be more than glad to help test and contribute in any way.
Unfortunately I'm working 2 projects at the same time, as well as working
trouble tickets, and I'm on loan to our mail admins for scripting powershell
for some AD issues we're dealing with due to recent changes.  :\  Also, as
you can tell, I'm still rather new to all of this.

I'll try testing out that new RPM as time permits.

Thanks again!

-----Original Message-----
From: J.C. Cleaver [mailto:cleaver at terabithia.org] 
Sent: Thursday, February 25, 2016 4:26 PM
To: Jason Brockdorf <apocalysque at yahoo.com>
Cc: xymon at xymon.com
Subject: Re: relocatable RPM or installing from source?

On Thu, February 25, 2016 12:53 pm, Jason Brockdorf wrote:
> Hello Xymon folks,
>
>
> I've been racking my brain about this lately and I don't see an easy way.
> I'd like to install the xymon client to /opt (or even the xymon 
> server, but that's another problem) and I'm using the Terabithia RPMS.  
> I do have the option to install them in the regular FHS but then I 
> have to depend our DCS vendor for any operations regarding the 
> software, and with their track record, I'd rather not.  Additionally 
> our current environment has the client installed in /opt in all of the 
> existing servers (older client which will need to be upgraded as part 
> of this project) and I'd like to stick with that convention, which was 
> advised by my sysadmin, manager, and a colleague.
> It
> makes administration easier on us to stick with this convention.


A combination of relocation, EL7 (systemd), and the Terabithia 4.3 RPMs is
going to be tricky. xymon itself is written around the use of a home
directory, but the RPMs were built (at first) to specifically to rip a lot
of that out and use FHS locations instead :) So re-relocating after that
will be perilous.


Experimentally, I've built a version with relocations enabled for /usr/
/etc/ and /var/ on the client package (only), and uploaded this to
http://terabithia.org/rpms/xymon/testing/el7/* as 4.3.26-1.1 (I haven't
rebuilt the repo, so yum won't see it yet.)

This lets this command actually complete:
rpm --verbose --debug -ip --relocate /usr=/opt --relocate /etc=/opt/etc
--relocate /var=/opt/var xymon-client-4.3.26-1.1.el7.x86_64.rpm

... but as you've seen, that only changes where the files are placed, not
any of the configs, and it doesn't help with dependency tracking for yum.

To make a package install-relocatable, just add 'Prefix:' lines underneath
that %package heading. That tells rpm that those dirs can be moved.
+Prefix:                %{_prefix}
+Prefix:                %{_sysconfdir}
+Prefix:                %{_localstatedir}


> When I try to install them to a different root using YUM, it tries to 
> install all of the dependencies as well.  Apparently there's no way to 
> get YUM to ignore dependencies and if I try to install the RPM by 
> relocating,

Right. If you're using yum --installroot, that's more for chroot type
environments, or installing over a separate mounted partition, than enabling
classical RPM relocation. yum doesn't really provide native support for
that.


> I
> get a message that the RPM is not relocatable.  So, I'm guessing I 
> need to install from source or build my own package (yuck).
>
>
>
> So, I've installed from source on a test system, but then there's no 
> scripts to create user accounts or add service definitions for 
> starting/stopping the service.  I've found the runclient.sh script but 
> I don't know how to adapt that to systemd on centos 7.

You can run
rpm -qp --scripts /path/to/your/xymon-4.3.26-1*rpm on an existing package to
see what exactly it's doing at install time for adding user accounts, etc.

You *might* be able to stick the runclient.sh script into /etc/init.d/,
chkconfig --add it, and hope systemd handles it OK, but I'm not sure. To get
the sysvinit scripts in the package, you'll need to rebuild it using
"--without systemd". That should give you a result using the normal sysvinit
stuff.


>
> Can the Terabithia RPMs be made relocatable or does anyone advice on 
> how to proceed?


For your client systems, unless you're using any of the Terabithia
features, I'd suggest distributing it as a tarball into /opt/ and using
runclient.sh or an init script that executes runclient.sh. That's the
quickest/easiest option.


If you need it in RPM form and are feeling experimental, add this to the
top of xymon.spec and do a rebuild of the SRPM:

%define _prefix /opt

This will likely have a greater chance of success than just a 'Prefix:
/opt' install relocation, but there are probably things that will still be
broken -- especially for the server side. (I would advise just using the
normal RPM on your Xymon Servers -- the file layout is going to be much
more complex there.)

If you can identify what breaks, though, that would be really helpful.
Redefining _prefix's and install relocations are some of those things that
are supposed to work in theory, but are rarely used and not very well
tested. They're officially discouraged in Fedora and other RPM-based
distros. That said, if there's better support that can be put into the RPM
to get closer to that ideal, I'd like to add it in...



(One of my goals in 4.4 is to significantly reduce the variation between
the source tarball and the RPMs and get rid of most of the workarounds
that are in place. That might mean more %post section config munging, or
more reliance on symlinks to simply place XYMONHOME locations in their
right spots and call it a day. This is an area of active work -- literally
just in the last few days -- but it's certainly not near production ready
yet.)


Hope this helps a little,

-jc





More information about the Xymon mailing list