97c01e48ed
Currently we have all our elements and library files in a top-level directory and install them into <root>/share/diskimage-builder/[elements|lib] (where root is either / or the root of a virtualenv). The problem with this is that editable/development installs (pip -e) do *not* install data_files. Thus we have no canonical location to look for elements -- leading to the various odd things we do such as a whole bunch of guessing at the top of disk-image-create and having a special test-loader in tests/test_elements.py so we can run python unit tests on those elements that have it. data_files is really the wrong thing to use for what are essentially assets of the program. data_files install works well for things like config-files, init.d files or dropping documentation files. By moving the elements under the diskimage_builder package, we always know where they are relative to where we import from. In fact, pkg_resources has an api for this which we wrap in the new diskimage_builder/paths.py helper [1]. We use this helper to find the correct path in the couple of places we need to find the base-elements dir, and for the paths to import the library shell functions. Elements such as svc-map and pkg-map include python unit-tests, which we do not need tests/test_elements.py to special-case load any more. They just get found automatically by the normal subunit loader. I have a follow-on change (I69ca3d26fede0506a6353c077c69f735c8d84d28) to move disk-image-create to a regular python entry-point. Unfortunately, this has to move to work with setuptools. You'd think a symlink under diskimage_builder/[elements|lib] would work, but it doesn't. [1] this API handles stuff like getting files out of .zip archive modules, which we don't do. Essentially for us it's returning __file__. Change-Id: I5e3e3c97f385b1a4ff2031a161a55b231895df5b |
||
|---|---|---|
| .. | ||
| init-scripts | ||
| install.d | ||
| static/usr/local/bin | ||
| element-deps | ||
| package-installs.yaml | ||
| README.rst | ||
=============
dynamic-login
=============
This element insert a helper script in the image that allows users to
dynamically configure credentials at boot time. This is specially useful
for troubleshooting.
Troubleshooting an image can be quite hard, specially if you can not get
a prompt you can enter commands to find out what went wrong. By default,
the images (specially ramdisks) doesn't have any SSH key or password for
any user. Of course one could use the ``devuser`` element to generate
an image with SSH keys and user/password in the image but that would be
a massive security hole and very it's discouraged to run in production
with a ramdisk like that.
This element allows the operator to inject a SSH key and/or change the
root password dynamically when the image boots. Two kernel command line
parameters are used to do it:
sshkey
:Description: If the operator append sshkey="$PUBLIC_SSH_KEY" to the
kernel command line on boot, the helper script will append
this key to the root user authorized_keys.
rootpwd
:Description: If the operator append rootpwd="$ENCRYPTED_PASSWORD" to the
kernel command line on boot, the helper script will set the
root password to the one specified by this option. Note that
this password must be **encrypted**. Encrypted passwords
can be generated using the ``openssl`` command, e.g:
*openssl passwd -1*.
.. note::
The value of these parameters must be **quoted**, e.g: sshkey="ssh-rsa
BBBA1NBzaC1yc2E ..."
.. warning::
Some base operational systems might require selinux to be in
**permissive** or **disabled** mode so that you can log in
the image. This can be achieved by building the image with the
``selinux-permissive`` element for diskimage-builder or by passing
``selinux=0`` in the kernel command line. RHEL/CentOS are examples
of OSs which this is true.