Re: [ezjail] Proper Steps to Update Host & Jails

[Dirk Engling <erdgeist AT erdgeist DOT org>]

On 30.01.14 17:23, Kozlov Sergey wrote:

> First thing I noticed - "ezjail-admin update -U" not only doesn't update
> /etc and /var directories of jails, but also it calls "freebsd-update
> install" in the basejail again and again until it exists with error
> "nothing to install, please fetch".

This was implemented under the assumption that the gap mainly was there
to allow a reboot after installing kernel updates. In earlier
implementations this would mean, that the userland part of the update
was not installed at all. I stand corrected. ezjail-admin update -u has
the same problem.

> On the third step freebsd-update deletes obsolete library files, so
> when I started all my jails 80% of software installed from ports just
> didn't start. Freebsd-update stops after each step for a reason, so
> if I updated basejail and jails by hand i could just stop after the

Back in the days, running mergemaster for every jail was a real PITA. I
usually have jails in the magnitude of dozens per host, each with users
in them, I need to coordinate updates with. So the easiest way was to
just keep the self-contained /etc directories and handle updates by
telling my users to do the rest of their update. I understand that this
is not what most users of ezjail would expect.

> second step, rebuild all ports (as recommended by handbook) in all
> my jails and only then run freebsd-update on the basejail for the
> third time getting almost zero downtime.

The same was true with ports. In the very early days, ezjail would just
work with worlds built from /usr/src. After building the world, it would
copy the new version over the old one, leaving the old libraries intact,
thus not breaking ports. Users would then be asked to to the updates in
their jails. Stale libraries never were removed.

This changed when binary updates were introduced and the updates
actually broke stuff within the jails. This meant that sometimes you
would need to reserve a _huge_ amount of time to update your server with
more than a handful of jails. As long as mergemaster and freebsd-update
lets you manually merge diverging CVS-Ids for each /etc directory,
offering a 'simple' ezjail-admin update -u/-U should come with a warning
about all the implicit assumptions and the potentially hefty time
requirements.

> For jails (freebsd-update-jails.conf):
> Components world/base
> IgnorePaths /bin /boot /home /lib /libexec /proc /rescue /sbin /sys /tmp \
> /usr/bin /usr/sbin /usr/include /usr/lib /usr/lib32 /usr/libdata
> /usr/libexec \
> /usr/share /usr/src
> StrictComponents yes

I used the regex "/[^e][^t][^c].*" in order not to be surprised by new
directories later. But maybe /var should also match.

> # freebsd-update -b /usr/jails/$i -f freebsd-update-jails.conf install
> # done
> again and again

Hmmm, this potentiall leads to a huge /var/db/freebsd-update directory,
because freebsd-update organizes patches by base dir.

Also the skeleton jail (/usr/jails/newjail) needs to be updated. It has
no installed ports, though. A warning that an update also potentially
breaks flavours, is important, too.

> IMHO ezjail-admin -U option must be considered harmful in this
> implementation, and must be rewritten.
> I want to help and I would like to provide patches as soon as I have
> time to write them

I consider your feedback really valuable and can, of course, also write
the patches. Currently it suites my needs so I welcome any input how to
make it more generally useful (and less harmful, if you will).

I welcome any ideas of how to properly present a potentially time
consuming (and error-prone, I more than once made mistakes when merging
/etc files and had to restart) update mechanism. The idea of ezjail was
to make most of the stuff work out of the box with sane defaults and
currently it appears as if this goal is not achieved.

I see several problems with updating packages automatically. If they
were built with non-default options, stuff breaks inside the jails. This
might not be a problem with jails under the host admin's control, but
having jailed users install their own software, updates require some
work that is very tough to script. Not removing old versions of
libraries usually worked very well, although it's not the recommended way.

Opinions?

  erdgeist