Commit graph

7 commits

Author SHA1 Message Date
Ian Wienand
36b59c001c Standarise tracing for scripts
There is a wide variety of tracing options through the various shell
scripts.  Some use "set -eux", others explicity set xtrace and others
do nothing.  There is a "-x" option to bin/disk-image-create but it
doesn't flow down to the many scripts it calls.

This adds a global integer variable set by disk-image-create
DIB_DEBUG_TRACE.  All scripts have a stanza added to detect this and
turn on tracing.  Any other tracing methods are rolled into this.  So
the standard header is

---
if [ "${DIB_DEBUG_TRACE:-0}" -gt 0 ]; then
    set -x
fi
set -eu
set -o pipefail
---

Multiple -x options can be specified to dib-create-image, which
increases the value of DIB_DEBUG_TRACE.  If script authors feel their
script should only trace at higher levels, they should modify the
"-gt" value.  If they feel it should trace by default, they can modify
the default value also.

Changes to pachset 16 : scripts which currently trace themselves by
default have retained this behaviour with DIB_DEBUG_TRACE defaulting
to "1".  This was done by running [1] on patch set 15.  See the thread
beginning at [2]

dib-lint is also updated to look for the variable being matched.

[1] https://gist.github.com/ianw/71bbda9e6acc74ccd0fd
[2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/051575.html

Change-Id: I6c5a962260741dcf6f89da9a33b96372a719b7b0
2015-02-12 10:41:32 +11:00
Abel Lopez
9009b18869 setfiles consistently
Working on host systems without selinux, where the guest image
does have selinux, creates a situation where the instance will
have about a 1 minute delay on first boot because it must relabel.
The previous check for sysfs assumes that the host system has
selinux, which is not needed for the guest setfiles to work.

Change-Id: Ic186a45991b6d80880ad635e9c80985612f53a05
Closes-bug: 1414200
2015-02-03 09:00:07 -08:00
Victor Lowther
e92398a318 Relabel filesystem if SELinux is available
Relabel the filesystem during image builds if SELinux is supported
in the kernel of the build machine and userspace tools are available.

Otherwise touch /.autorelabel to schedule a relabel the first time
the image boots. We relabel when possible because it decreases first
boot time.

Change-Id: I0bec885d6e5d4f4e1106f3bd2a90ba5f86395b07
Partial-Bug: 1347845
2014-08-04 17:56:33 -07:00
Richard Su
4e68a7965b Remove fixfiles from rpm-distro finalize
Running fixfiles after setfiles is redundant. setfiles
already corrected the SELinux file security contexts.

Change-Id: I48067f06968c5add48fa91a1496b9bf36944546c
Closes-Bug: #1316241
2014-07-03 11:47:10 +10:00
Ben Nemec
f6ba2aeaf4 set -e all the things
Using set -e in all of our scripts will prevent some subtle bugs
from slipping in, and will allow us to enforce use of set -e with
tooling.

This change also adds -u and set -o pipefail in the less complex
scripts where it is unlikely to cause problems.  A follow-up change
will enable those options in the complex scripts so that if it
breaks something it can be reverted easily.

Change-Id: I0ad358ccb98da7277a0ee2e9ce8fda98438675eb
2014-04-25 17:38:51 -05:00
James Slagle
ea257c96d9 Skip relabel unless SELinux is enforcing
The SELinux relabel of the filesystem is taking almost 2 minutes and
isn't needed unless you actually plan to run with SELinux enforcing.
Plus, it appears to "leak" out of the chroot, referencing filesystems on
partitions that aren't even mounted in the chroot.

Note you just can't use getenforce or selinuxenabled here to get the
state of SELinux because those commands are not accurate inside a
chroot.

TBH, a downside of this is that if someone goes to try to enable SELinux
in an image where it was built with it not enabled, the file contexts
are going to be wrong. So they'd need to relabel themselves at that
point. However, this saves me quite a bit of time during image builds,
so I thought I'd submit to get other folks opinion on it.

Change-Id: I2132060d573fc93cf974f3560fdc651ff8ba38b4
2014-01-23 15:29:29 -05:00
Chris Alfonso
301c3c4475 Extracting common functionality for rpm based distros
Rather than dublicating code to implement rhel or any
other derivitive, this patch introduces an rpm-distro
element that should be used as a dependency.

Change-Id: I8a92bb041764d03f430b438f0013704f79a8674c
2013-08-20 16:44:19 -04:00