[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ezjail] Proper Steps to Update Host & Jails
The only (few) problems I see has nothing to do with ezjail itself. I'm updating since FreeBSD 8.2 in a similar way like Werner, having a VM of the productive jails to test, writing a small shell script for final tunings. It was never a 'one click' thing and that was not the problem of ezjail, it was (is) the problem of not using ONLY default and tested binary packages that you can have since they come up. So I don't believe you can achieve an real 'easy' way to update a bunch of jails if they a) not exactly one as the other and b) always in tune with the host.
I just TRUELY hope erdgeist will find the time to solve the moronic jail.conf invention since 10.0. Everything else would be to give a little more switches to control which steps of the -U/-u process I want to run. Giving just a little more control to everyone seems to be nice, because we all seem to have different needs and environments.
just my 50 cent.
Am 30.01.2014 um 21:30 schrieb Werner Thie <werner AT thieprojects DOT ch>:
> Hi all
> What I'm asking myself is, do we have now with FreeBSD10 other viable alternatives to jails and ezjail specifically. In the past I made it a habit to run a VM with a FreeBSD version in sync with the production servers, allowing me to do dry runs of the whole jail updating. I did this just to feel safe that what I was trying to achieve (usually minimal downtime) also went down as planned. Doing this for several years now and with quite a few jails involved, this scheme starts to feel creaky and old.
> What would ezjail users out there chose today instead of ezjail?
> I used ezjail mainly because of the 'shared' part and the promise that master machine and jails can be kept in lockstep when updates arise.
> After the recent discussions I'm not sure, that I will migrate towards FreeBSD10 but rather flatten the iron, do a fresh install and work with full VM's.
> On 30/01/14 07:20, Dirk Engling wrote:
>> 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
>>> 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.