Don't assume environment.d is always under /tmp/in_target.d. This makes
dib-run-parts more flexible, and less specific to diskimage-builder. For
instance, dib-run-parts is already used by os-refresh-config, but
/tmp/in_target.d/environment.d is never going to exist when it's called
by os-refresh-config.
This is useful b/c elements can now install os-refresh-config scripts
under /opt/stack/os-config-refresh/environment.d to influence how
further scripts are run. Specifically, the OpenSuse packages prepend the
OpenStack user accounts with "openstack-". Instead of checking for which
users exists with an if/else in all the os-refresh-config scripts that
need to do user related things, we can just update the scripts to use
$NOVA_USER, etc. The OpenSuse element can then install a file under
/opt/stack/os-config-refresh/environment.d to set NOVA_USER to
openstack-nova. We could have files that declare defaults as well within
each specific element, or just set a default variable at the top of each
os-refresh-config script.
Change-Id: Iadbfad995da657e2965fd55fc4ba3a88138b4cfc
With https://review.openstack.org/#/c/70721 installing
the dhcp-agent subpackage was introduced, which is needed
for openSUSE. It seems on Fedora this is part of the main
package, so we need to map it back to that one.
Change-Id: I80f8412d291b3571d220fd26cfece86a03479440
Adds the ability to set $DIB_LOCAL_IMAGE to use as the base cloud image
for a Fedora image build. There are many repetitve tasks that are done
every image build. With this change you can build an image with the
fedora and vm element and then reuse the resulting image as input to
future image builds. This greatly reduces future image build times.
For instance 99-up-to-date is already taking almost 2 minutes (even with
rpm downloads already cached) for Fedora 20, and is only going to keep
taking longer. By having a local up to date Fedora cloud image, this
time can be saved on each image build.
There is one minor change to support this in that /tmp/grub needs to get
cleaned up at the end of image builds so that the image can be reused.
Plus, there is no reason for it to stick around anyway. (didn't think
this was worth a seperate commit).
Change-Id: Ic74d138da922ecc99c38c27f105170d90009a84a
Otherwise some dependend libraries might be missing in the ramdisk. E.g.
on SUSE bash is dynamically linked against libreadline.
Change-Id: I8b36bee6aa5a1e1da419e748e8bba046c29f3ae2
/usr/bin/env is more portable (/bin/env does not exist on SUSE).
Also address minor nit on review about python 3.x compatibility.
Change-Id: I6bc1a579bb43664f4d2be35a96f45189a6df0e27
Rename generate-interfaces-file.sh to dhcp-all-interfaces.sh
so that it is easier to find/remember in the $PATH on a deployed
image.
Also, on some distros the script actually generates many files
so the previous name was a bit confusing.
Change-Id: I7152fa7c28e8ade251311da2cd5f75972423b66c
Updates the generate-interfaces-file.sh script in
the dhcp-all-interfaces element so that we only
add interfaces that have real MAC addresses.
The generate-interfaces-file.sh script is run early enough
in the boot process (before OVS is initialized) that this
isn't usually a problem unless you execute it manually by hand
after booting. Then you'll end up with network/DHCP
configs for all of your OVS bridges, etc. This
patch avoids configuring all of the virtual interfaces
which have generated MAC addresses.
Change-Id: I7a705084aa5b11305ac0ec5ca37fd2e87a2ae8b7
Closes-bug: 1239479
map-services is used by os-svc-restart from Change-Id:
I15eb2a5db4b0a08e1fb40bda640cd8f224939a92
map-services is not only distro specific, it also needs to be able to
handle different service names for a given distro based on source vs
package installs, since the service names may be different. This is done
via a simple check if the requested service is defined, if it is, we
print the requested name, otherwise, we print the mapped name.
Currently only implemented for Fedora. Support for other distros is
easily implemented just like map-packages.
Change-Id: Ie7b2dcfa7cabd887d5c212df110d90f9d00a7f65
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
If creating an image of a disto without grub2 extlinux is instead used,
extlinux was being configured to mount the root filesystem as
read/write which in turn causes e2fsck to fail to test the filesystem,
on RHEL 6.5 this causes the boot process to fail.
Change-Id: I07859e0df9a2bc1ddd8c5f2ed4509ba14312e140
Delete stale symlinks created by current openSUSE 13.1
for kpartx loopback partitions. Those break bootloader
installation otherwise.
Change-Id: I13a7387e341b4426b459610fd1d3c49ce5730f46
On some systems ldd gives a slightly different output for VDSOs. It doesn't
contain a '=>'. E.g.:
linux-vdso.so.1 (0x00007fff2f4a6000)
instead of:
linux-vdso.so.1 => (0x00007fff2f4a6000)
This patch simply skips all entries in the ldd output which don't expand to a
path name to workaround that.
Change-Id: Ie37637890b775b36bb31af4e586e61131bd80fa8
