upgrading /etc/rc.d/ in jails

dvl@

Developer
I recently upgraded a jail host from FreeBSD 9.2 to 9.3. This host uses ezjail for managing the jails.

The issue: after the upgrade, the individual jails do not have the new 9.3 files (e.g. /etc/rc.d/sshd is from 9.2, not 9.3).

This seems like a non-trival situation.

The only solution I can think of: obtain the source for 9.3-RELEASE and run mergemaster into each jail.

Other suggestions?
 
If I understand correctly, you have upgraded the host system and the ezjail base jail to FreeBSD 9.3. Since ezjail has individual /etc hierarchies for each jail it sounds like the files in /etc/rc.d might be copied into each jail and therefore don't form part of the base jail upgrade. This means that your jails now have 9.2 scripts left in /etc/rc.d. I'll caveat this by saying that I don't have access to my FreeBSD systems from where I'm posting so I haven't checked that this is how the ezjail scripts work.

Assuming I am correct, it should be safe to overwrite (no need to merge) the 9.2 scripts in each jail's /etc/rc.d with the 9.3 versions from your host system provided you haven't customised them. It would also be worth reporting this as a bug/feature request to the ezjail authors as it doesn't sound like ideal behaviour. Something like mounting the /etc/rc.d directory from the base jail under each jail's own /etc could be a solution. I put all my custom startup scripts in /usr/local/etc/rc.d so forcing /etc/rc.d to be common to all jails wouldn't seem unreasonable.
 
That summary is accurate.

I've established that /etc/rc.d in my jails does not vary much from jail to jail. I'm going to try putting that directory into the basejail.

Here is the script I used:

Code:
#!/bin/sh

JAILS=`/usr/sbin/jls name`
for jail in ${JAILS}
do
  echo $jail
  jailpath=`/usr/sbin/jls -j ${jail} path`
  diff -ruN /usr/local/jails/bacula.example.org/etc/rc.d/ ${jailpath}/etc/rc.d/
done
 
Well... it's the same, really. jls(8) only shows running jails. So using it to get a list of jails to upgrade will miss the ones that are not running.
 
I have quite a few jails to upgrade before 9.2 reaches end of life in December 2014. Having thought about it, I'm not sure I like the suggestion I made in my previous post of using mount_nullfs(8) so that /etc/rc.d (and as @@dvl's blog entry mentioned, /etc/periodic) are shared between all jails. I'm leaning towards @dvl@'s original suggestion (and @wblock@'s recommendation in Thread 47629) of using mergemaster(8) for each jail's /etc hierarchy. Adding a suitably configured /etc/mergemaster.rc to my ezjail flavours, such that future upgrades need minimal user interaction is an option I am keen to explore.
 
Last edited by a moderator:
I tried mergemaster.

I did mergemaster -p first, then tried mergemaster -U.

This is the start of that last command:

Code:
# mergemaster -U

*** The directory specified for the temporary root environment,
    /var/tmp/temproot, exists.  This can be a security risk if untrusted
    users have access to the system.

  Use 'd' to delete the old /var/tmp/temproot and continue
  Use 't' to select a new temporary root directory
  Use 'e' to exit mergemaster

  Default is to use /var/tmp/temproot as is

How should I deal with this? [Use the existing /var/tmp/temproot] d

   *** Deleting the old /var/tmp/temproot

*** Creating the temporary root environment in /var/tmp/temproot
 *** /var/tmp/temproot ready for use
 *** Creating and populating directory structure in /var/tmp/temproot

unlink: /var/tmp/temproot//bin: is a directory
unlink: /var/tmp/temproot//boot: is a directory
unlink: /var/tmp/temproot//lib: is a directory
unlink: /var/tmp/temproot//libexec: is a directory
unlink: /var/tmp/temproot//rescue: is a directory
unlink: /var/tmp/temproot//sbin: is a directory
unlink: /var/tmp/temproot//usr/bin: is a directory
unlink: /var/tmp/temproot//usr/include: is a directory
unlink: /var/tmp/temproot//usr/lib: is a directory
unlink: /var/tmp/temproot//usr/lib32: is a directory
unlink: /var/tmp/temproot//usr/libdata: is a directory
unlink: /var/tmp/temproot//usr/libexec: is a directory
unlink: /var/tmp/temproot//usr/sbin: is a directory
unlink: /var/tmp/temproot//usr/sbin: is a directory
unlink: /var/tmp/temproot//usr/share: is a directory
unlink: /var/tmp/temproot//usr/src: is a directory


*** Beginning comparison

   *** Checking /etc/rc.d for stale files

   *** No stale files found

*** The installed file /boot has the type "symbolic link"
    but the new version has the type "directory"

    How would you like to handle this?

    Use 'r' to remove /boot
    You will be able to install it as a "directory"

    Use 'i' to ignore this

    How to proceed? [i] i
*** See the man page about adding /boot to the list of IGNORE_FILES
 *** Press the [Enter] or [Return] key to continue 

 *** Temp ./.cshrc and installed have the same Id, deleting
 *** Temp ./.profile and installed have the same Id, deleting
 *** Temp ./COPYRIGHT and installed have the same Id, deleting
...

The rest proceeded normally (based on my past experience).

The IGNORE_FILES option in /etc/mergemaster.rc has no effect on this, presumably because it is use for files, not directories.

Next, I tried make delete-old. This failed.

Code:
s run 'make delete-old-libs'.
[root@mydev:/usr/src] # make delete-old
>>> Removing old files (only deletes safe to delete libs)
remove /usr/share/man/man1/send-pr.1.gz? y
rm: /usr/share/man/man1/send-pr.1.gz: Read-only file system
*** [delete-old-files] Error code 1

Stop in /usr/src.
*** [delete-old] Error code 1

Stop in /usr/src.

At present, I am leaning towards abandoning ezjail and using basic jails.
 
FYI, I know that the basejail is upgraded. I did a ezjail-admin install a few days ago.
 
This approach ( mergemaster -p && mergemaster -U) in each jails seems to be working.

4 down, 34 to go.

On this host.

All by hand.

This is mind numbing.
 
I'm not sure how they would help.

I wound up doing: csshX AllTheHosts and finished off the remaining 24 jails for the price of one jail.
 
Back
Top