Should Fedora revisit the idea having "one " image to be used across the cloud providers?

[Pádraig Brady]

Just some general notes...

On 06/28/2013 03:03 PM, Dennis Gilmore wrote:
> On Fri, 28 Jun 2013 08:37:17 +0000
> "Collins, Robert (HPCS)" <rbtcollins at hp.com> wrote:
> 
>> As far as using guestfs later in the build process - I don't see any
>> need for that; we start with a tarball, we chroot into that, we make
>> a filesystem matching the size of the content and rsync the contents
>> over. The reason we start a new filesystem is that its faster: we
>> started initially by cloning the original disk image and modifying,
>> but it turns out that vendor images have wildly varying filesytem
>> sizes and definitions, and we needed to provide images with well
>> understood and documentable characteristics. Resizing ext*
>> filesystems up and down isn't the fastest process, particularly on
>> LTS style releases like Ubuntu LTS and RHEL.

resizing down may also impact on data layout,
thus impacting future performance of the image.

> so a issue with that, is that it breaks things, tar doesnt preserve
> filesystem capabilities so on a fedora system and presumably furture
> rhel things will be broken. filesystem capabilities have been taking
> over from setuid/setgid in packages.  i pknow one thing that will be
> broken is that ping wont work for a user.  the best way to great a
> image is a automated install using kickstart or whatever the vendors
> automated install method is

rsync -X does preserve capabilities I think.

cp -a (as root) preserves capabilities.

To get a list of capabilities on rpm based distros you could
  rpm --qf "[%{FILECAPS} %{FILENAMES}\n]" -qa | grep '^=' #Output at ¹
Such a list could be used later to reinstate capabilities.

cheers,
Pádraig.

¹
/usr/sbin/suexec
/usr/bin/gnome-keyring-daemon
/usr/sbin/dumpcap
/bin/ping
/bin/ping6
/usr/sbin/seunshare
/usr/sbin/mtr
/usr/libexec/pt_chown