Drawing lessons from fatal SELinux bug #1054350

[Chris Murphy]

On Jan 24, 2014, at 2:58 AM, Sergio Pascual <sergio.pasra at gmail.com> wrote:

> 2014/1/24 Ralf Corsepius <rc040203 at freenet.de>
> 
> Certainly, downgrading installations which already upgraded to faulty packages would not work.
> 
> Ralf
> 
> The situation (a broken system that cannot be upgraded)  could be mitigated a little bit by using yum + system snapshots. You can rollback to a previous sane system.

This is non-trivial for the typical user. And as far as I'm aware there's no storage SIG to define a best practices, so at the moment there are 19 recipes per snapshot technology. So one person can explain how they do it, then the user gets into some trouble with a question and no other user can really answer the question because they do it a different way.
> 
> There is a plugin yum-plugin-fs-snapshot, but it requires better documentation and system integration.

Well I'd go a step further and ask some more basic questions how how many snapshots should be bootable, whether systemd-journal should be persistent across snapshots or snapshot specific, what exactly are we snapshotting, can we require /home be separate (presently we don't require it) in order to support such bootable snapshots, on and on.

I'm not so sure the plugin needs an update or replacing or a separate user space program that helps manage the moving parts: the snapshot creation, the update, altering fstab and grub.cfg as needed, and even what the bootable snapshot options should look like and where: we have three kernels to choose from in GRUB, as soon as there's one snapshot, we might have three identical kernel versions each with two sysroots; or possibly there are four kernels, one only boots the old sysroot, one only boots the new sysroot and two could boot either sysroot. And that's just with one snapshot, as soon as there are accumulating snapshots to boot, I start looking for blood because I don't have enough going to my brain as it is.


> 
> Currently (I don't know how current is F16 documentation) it requires running lvm by hand 
> 
> http://docs.fedoraproject.org/en-US/Fedora/16/html/System_Administrators_Guide/sec-Plugin_Descriptions.html

Right and there's a legitimate question how useful conventional LVM snapshots are, just because at one time they were the only thing we had, but they're slow and inefficient and you wouldn't want to use them for very long as that's not what they were designed for. Whereas LVM thinp snapshots are completely different, useable, accumulatble over the long haul, do not require preallocation, very much like Btrfs snapshots but of course a different implementation. And then Btrfs snapshots are dead nuts simple to create and remove compared to thinp - *and* they are directly grub2 bootable unlike LVM thinp.


Chris Murphy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140124/09c95e2b/attachment.html>