On 01/28/2013 06:54 PM, Tim Evans wrote:
> It creates one or more "alternate boot environment(s)," then newfs's it,
This is redundant on CentOS
> mounts it, copies the running system to it, then applies
> upgrades/patches to it. It does not touch the running environment
not true, you have severe performance loss and no reliable way to
measure the impact of what that changeset is going to bring in. Patching
the running system, with a failback option is far better. Unless you
dont trust the platform at all. Lack of a reasonable manageable and
predictable packaging system can cause that lack of trust.
> (except to create a housekeeping database for the multiple boot
> environments). The target boot environment is made bootable, and the
the idea of bootable on Linux is limited to the kernel and the initrd (
which even has a shell ). Unless you installed a kernel in the
transactino set, there is no need to update grub, since your existing
running boot components are still intact ( if not, you can measure and
handle it ). If you do update the kernel, the setup will retain multiple
copies and your last running kernel is always retained as an option to
boot from next boot cycle
> grub configuration is updated to include the second bootable
> environment, and the /etc/fstab file on the second environment is
> modified to reflect the disks/LV's it uses.
Take a look at the yum lvm plugin, it already does most of this - with
some assumptions on what its going to snapshot and how you want to
handle that.
> The whole idea is not to touch the running system, apply changes to the
> alternate system, then boot to the alternate when change is done. Once
> the reboot to the new environment is done, you can further use LU to
> replace the un-upgraded/un-patched original environment with a copy of
> the new one.
This kind of highlights the issue here, you are attempting to look at
this with too far a solaris process mindset. Most CentOS best-practises
are driven towards keeping a running system up, by not breaking it or
needing to do downtime efforts. Some packages due to their nature will
enforce this, like glibc; but on the whole, its considered acceptable to
patch live and keep going, with the understanding that there is a
failover option / failback opton, rather than assume a running system
must be taken down for a patch to be applied.
There are exceptions, but most of them are niche implementation driven
ones, on the whole CentOS is built to be patched in place. Take a look
at the yum lvm plugin on how you can fairly-easily implement the extra
step you mentioned ( i.e tweak fstab to boot from a diff lv / uuid ).
- KB
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
