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(a)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