"Permanently" install packages onto host OS

PantsManUK

Cadet
Joined
Nov 21, 2019
Messages
5
I've got 11.2-U7 running in an XCP-ng VM, and I've figured out how to install the Xen guest utilities from pkg by conglomerating a number of resources from around the web. I've also managed to install NRPE3 much the same way so that our Nagios install can keep an eye on it. This all "just works [tm]". I've even done the same for my 11.3-BETA1 play install VM (all same same).

The problem is that any time these VMs are restarted, they forget everything for the package installs and I have to manually follow my "install packages" process (it's not a huge long list of steps)

Is there a "user" way to (semi) permanently install packages against the host OS so they at least survive reboots? I'm prepared to have to redo after updates (that makes sense)... I realise there are situations where "use jails" is the right answer, but this is not one of them.

(Mods, if this is in the wrong place, please feel free to move.)
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,700
You're outside the boundary of supported scenarios here.

VMware guest agent is already in the build, so perhaps that's a safer place to be if you want support.

If you don't care about that, perhaps look into the fact that you probably haven't lost the package contents, just the startup of the daemons, so look into tunables... A loader type tunable with a name of daemon_load and a value of YES will load whatever is called daemon at startup.

Maybe that will help you?
 

Chris Moore

Hall of Famer
Joined
May 2, 2015
Messages
10,079
One of the iXsystems staff, possibly dlavigne or maybe anodos, would be best equipped to answer this.
Part of the problem is that the system config is rebuilt from the config database when the OS boots. You can't make persistent changes to the OS and that is the way it was designed to work. It is meant to be a feature. You would likely need to put any installers for your modifications into a persistent directory, like root's home directory, and run an installation script after boot.
 

PantsManUK

Cadet
Joined
Nov 21, 2019
Messages
5
Thanks for the responses - what I was expecting based on the web trawl that led me to the steps I currently follow.

@sretalla - funnily, the rc.conf entries tended to survive reboots - I somehow managed to make them semi-permanent before U7 dropped, they've gone with that update however. Not sure about the packages themselves - didn't think to look ;-)

@Chris Moore - you mentioned using an installation script from the root home directory. That feels do-able (sed to modify the pkg and rc config files, plus a pkg install and "manual" start...). I'm going to take a look after posting (the benefits and curses of EU/USA time differences...), but is this documented anywhere?
 

PantsManUK

Cadet
Joined
Nov 21, 2019
Messages
5
Thanks for the responses - what I was expecting based on the web trawl that led me to the steps I currently follow.

@sretalla - funnily, the rc.conf entries tended to survive reboots - I somehow managed to make them semi-permanent before U7 dropped, they've gone with that update however. Not sure about the packages themselves - didn't think to look ;-)

@Chris Moore - you mentioned using an installation script from the root home directory. That feels do-able (sed to modify the pkg and rc config files, plus a pkg install and "manual" start...). I'm going to take a look after posting (the benefits and curses of EU/USA time differences...), but is this documented anywhere?

Don't think I can edit (yet, maybe?), but taking what @sretalla said, I think I can use rc.conf tunables to keep the rc.conf entries live, so my line about using sed reduces to just changing the pkg config files.
 

PantsManUK

Cadet
Joined
Nov 21, 2019
Messages
5

kdragon75

Wizard
Joined
Aug 7, 2016
Messages
2,457
Your best bet would be to install and setup via boot time script, keep all resources on the pool and just call the script. This would be the closest to supported and least Likely to break after updating.
 

PantsManUK

Cadet
Joined
Nov 21, 2019
Messages
5
Paying it forward, this is how I've fixed the problem of getting xe-guest-utilities and nrpe3 automatically installed at boot (working on an 11.3-BETA1 lab install, and as soon as I'm done with this post I'm going to deploy it to our "production" 11.2-U7 install).

To start, we need to grab the packages and their dependencies from FreeBSD and keep them locally. THIS IS A ONE-OFF (unless the packages get updated), so we'll (temporarily) reconfigure pkg so it can get packages from FreeBSD.

Using your favourite editor (nano for me), edit /usr/local/etc/pkg/repos/local.conf and change enabled: yes to enabled: no (disabling the local package repository). Similarly, edit /usr/local/etc/pkg/repos/FreeBSD.conf and change enabled: no to enabled: yes (enabling the FreeBSD package repository).

Now we fetch the packages and their dependencies with pkg install -F sysutils/xe-guest-utilities net-mgmt/nrpe3. This will fetch (only) all the packages and put them in the package cache. Move them out of the cache and into /root (mv /var/cache/pkg/* /root) - you should have five package files and five links to those package files.

While you're in the shell, create a script in /root to do the "heavy lifting" (I called mine postinstall.sh):-

Code:
#! /bin/bash

# Install locally "cached" packages
/usr/sbin/pkg add /root/xe-guest-utilities-6.2.0_2.txz
/usr/sbin/pkg add /root/nrpe3-3.2.1.txz

# Install local nrpe.cfg
/bin/cp /root/nrpe.cfg /etc/local/nrpe.cfg

# Start packages
/usr/local/etc/rc.d/xenguest start
/usr/local/etc/rc.d/nrpe3 start


(This assumes you already have a "corporate" nrpe.cfg that you've copied into /root) chmod +x /root/postinit.sh to make it executable. The script will need to be moved onto a Pool FS so that Tasks can "see" it - I made a small 3GiB mirror for this.

With that done, we get to the easy bit; in System > Tunables create two rc-type tunables:-

VariableValueTypeComment
nrpe3_enableYESrc.confEnable nrpe3
xenguest_enableYESrc.confEnable xenguest
And finally, in Tasks > Init/Shutdown Scripts we create a new Post Init script entry for /mnt/<pool>/postinit.sh.


The services the packages add can be manually started from the shell - see the final two commands in the script.
 
Last edited:
Top