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@xxxxxx> 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
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
