On 01/28/2013 07:55 PM, Karanbir Singh wrote:
> 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 ).
>
Thanks to everyone for their replies. I suppose it's not possible in
this forum to ask such a question and not get into religion. Kinda like
the U.S. Congress.
No one has yet shown how a byte-for-byte, fully redundant, bootable
disk(set) can be created and kept up to date that will allow immediate
recovery from a catastrophic failure of the primary disk(set) with
nothing more than a reboot.
FWIW, Solaris' problems are not technical. Rather, they're Oracle's
licensing and support policies that have essentially fired all its small
system customers.
--
Tim Evans | 5 Chestnut Court
Linux/UNIX Consulting | Owings Mills, MD 21117
http://www.tkevans.com/ | 443-394-3864
http://www.come-here.com/News/ | tkevans@xxxxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
