Commit a13408eb authored by Nikos Skalkotos's avatar Nikos Skalkotos
Browse files

Merge branch 'master' into debian-trusty

parents da989307 2342b7a3
2014-09-22, v0.16
* Add support for Desktop variants of Windows
* Add support for archipelago images
* Update the documentation
2014-07-18, v0.15.2
* Fix configure.ac to work with newer versions of automake
......
......@@ -6,7 +6,7 @@ Advanced Topics
Image Format
^^^^^^^^^^^^
snf-image supports 3 types of image formats:
*snf-image* supports 3 types of image formats:
* **extdump**: a raw dump of an ext{2,3,4} file system
* **ntfsdump**: a raw dump of an NTFS file system
......@@ -24,8 +24,8 @@ should have the following properties:
* The OS they host should not depend on any other partitions
* Start at sector 2048
* Have a boot loader installed in the boot sector of the partition (not MBR)
* Have the root device in */etc/fstab* specified in a persistent way, using
UUID or LABEL (for extdump only)
* Have the root device in ``/etc/fstab`` specified in a persistent way, using
UUID or LABEL (for *extdump* only)
Known Issues
------------
......@@ -37,7 +37,7 @@ Known Issues
diskdump image format (recommended)
+++++++++++++++++++++++++++++++++++
Diskdump is a newer format that overcomes most of the aforementioned issues.
*diskdump* is a newer format that overcomes most of the aforementioned issues.
This format is a dump (raw copy using dd) of a whole disk.
This design decision has the following benefits:
......@@ -48,21 +48,78 @@ This design decision has the following benefits:
* Separate system and boot partition in Windows
* There are no restrictions on starting sectors of partitions
Although diskdump is a lot more flexible than the older formats, there are
Although *diskdump* is a lot more flexible than the older formats, there are
still some rules to follow:
* For Linux:
* All block devices in */etc/fstab* should be specified using persistent
names (UUID or LABEL)
* All block devices in ``/etc/fstab`` should be specified using persistent names (UUID or LABEL)
* LVM partitions are not supported
* Only ext{2,3,4} file systems are supported
* For FreeBSD:
* GUID Partition Tables (GPT) should be used
* Only UFS2 file systems are supported
* Labels should be omitted in */etc/fstab* entries
* Labels should be omitted in ``/etc/fstab`` entries
* For {Open,Net}BSD:
* Only FFS file systems should be used
.. _windows-deployment:
Windows Deployment
^^^^^^^^^^^^^^^^^^
*snf-image* performs Windows customization by installing an Answer File for
Unattended Installation (typically named Unattend.xml) into the VM's hard
disk and customizing the file accordingly. The VM will auto-configure itself
the first time it boots. For this to work, the used Windows image must have
previously been generalized [#f1]_ with a command like this:
.. code-block:: console
Sysprep /generalize /shutdown /oobe
The pre-included Unattend.xml file that *snf-image* will by default install on
the VM's hard disk is this one:
.. literalinclude:: ../snf-image-helper/unattend.xml
:language: xml
:emphasize-lines: 7,21-30
:linenos:
The file above is expected to work with all AMD64 releases (Server or Desktop)
of Microsoft Windows starting from version 6.1. The table below lists the
releases the developers have confirmed it to work with:
+-------+----------------------+----------------------+
|Version|Marketing name | Editions |
+=======+======================+======================+
|6.1 |Windows 7 |Professional, Ultimate|
| +----------------------+----------------------+
| |Windows Server 2008 R2|Datacenter |
+-------+----------------------+----------------------+
|6.2 |Windows 8 |Professional |
| +----------------------+----------------------+
| |Windows Server 2012 |Datacenter |
+-------+----------------------+----------------------+
|6.3 |Windows 8.1 |Professional |
| +----------------------+----------------------+
| |Windows Server 2012 R2|Datacenter |
+-------+----------------------+----------------------+
Nevertheless, the user may want to use a custom Unattend.xml file that better
fits his needs. To do so, he can either update the *UNATTEND* configuration
parameter in ``/etc/default/snf-image`` to point to such a file in the host
system or put his copy of the file in the root directory of the image's
%SystemDrive% (*snf-image* will not install an Unattend.xml file if it is
already present in the image, unless *IGNORE_UNATTEND* image property is
defined). The latter is the recommended way to do it since it allows to provide
answer files in a per-image basis.
.. warning::
When using custom Unattend.xml files, keep in mind that the highlighted
entries (lines 7 & 21-30) are crucial for *snf-image* to work. You may remove
or add settings in the file but the highlighted entries must be present.
Progress Monitoring Interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
......@@ -156,3 +213,7 @@ standard error output stream of *snf-image-helper*. Valid *error* messages look
like this:
``{"subtype": "error", "type": "image-helper", "messages": ["The image contains a(n) MSDOS partition table. For FreeBSD images only GUID Partition Tables are supported."], "timestamp": 1379507910.799365}``
.. rubric:: Footnotes
.. [#f1] http://technet.microsoft.com/en-us/library/hh824938.aspx
......@@ -4,27 +4,27 @@ Architecture
Overview
^^^^^^^^
snf-image is a Ganeti OS definition. This means that Ganeti provisions a new
disk (block device) and passes it to snf-image. Then, snf-image is responsible
to deploy an Image on that disk. If snf-image returns successfully, Ganeti will
then spawn a VM with that disk as its primary disk.
*snf-image* is a Ganeti OS definition. This means that Ganeti provisions a new
disk (block device) and passes it to *snf-image*. Then, *snf-image* is
responsible to deploy an Image on that disk. If *snf-image* returns
successfully, Ganeti will then spawn a VM with that disk as its primary disk.
Thus, snf-image is responsible for two (2) things, which are executed in two
Thus, *snf-image* is responsible for two (2) things, which are executed in two
separate steps:
| 1. Fill the newly provisioned disk with Image data
| 2. Customize the Image accordingly
For (1), snf-image can fetch the Image from a number of backends, as we
describe later. For (2) snf-image spawns a helper VM and runs a number of
For (1), *snf-image* can fetch the Image from a number of backends, as we
describe later. For (2) *snf-image* spawns a helper VM and runs a number of
configuration tasks inside the isolated environment. Once the last task returns
successfully, the helper VM ceases and snf-image returns the newly configured
successfully, the helper VM ceases and *snf-image* returns the newly configured
disk to Ganeti.
The whole procedure is configurable via OS interface parameters, that can be
passed to snf-image from the Ganeti command line or RAPI.
passed to *snf-image* from the Ganeti command line or RAPI.
snf-image is split in two components: The main program running on the Ganeti
*snf-image* is split in two components: The main program running on the Ganeti
host with full root privilege (*snf-image*, previously *snf-image-host*) and a
part running inside an unprivileged helper VM (*snf-image-helper*).
......@@ -35,18 +35,19 @@ snf-image
This part implements the Ganeti OS interface. It extracts the Image onto the
Ganeti-provided block device, using streaming block I/O (dd with oflag=direct),
then spawns a helper VM, and passes control to snf-image-helper running inside
that helper VM. The helper VM is created using either KVM or XEN depending on
the supported hypervisor as dictated by Ganeti. It runs as an unprivileged
user.
then spawns a helper VM, and passes control to *snf-image-helper* running
inside that helper VM. The helper VM is created using either KVM or XEN
depending on the supported hypervisor as dictated by Ganeti. It runs as an
unprivileged user.
There is no restriction on the distribution running inside the helper VM, as
long as it executes the snf-image-helper component automatically upon boot-up.
The snf-image-update-helper script is provided with snf-image to automate the
creation of a helper VM image based on Debian Stable, using multistrap.
long as it executes the *snf-image-helper* component automatically upon
boot-up. The ``snf-image-update-helper`` script is provided with *snf-image*
to automate the creation of a helper VM image based on Debian Stable, using
``multistrap``.
The snf-image-helper component runs inside a specific environment, which is
created and ensured by snf-image:
The *snf-image-helper* component runs inside a specific environment, which is
created and ensured by *snf-image*:
* The VM features a virtual floppy, containing an ext2 file system with all
parameters needed for image customization.
......@@ -57,11 +58,11 @@ created and ensured by snf-image:
maintains.
* The helper VM is expected to output "SUCCESS" to its second serial port if
image customization was successful inside the VM.
* If "SUCCESS" is not returned, snf-image assumes that, execution of the
helper VM or snf-image-helper has failed.
* If "SUCCESS" is not returned, *snf-image* assumes that, execution of the
helper VM or *snf-image-helper* has failed.
* The helper VM is expected to shutdown automatically once it is done. Its
execution is time-limited; if it has not terminated after a number of
seconds, configurable via ``/etc/default/snf-image``, snf-image sends a
seconds, configurable via ``/etc/default/snf-image``, *snf-image* sends a
SIGTERM and/or a SIGKILL to it.
snf-image-helper
......@@ -105,12 +106,12 @@ newly created block device. The following back-ends are supported:
* **Pithos backend**:
*snf-image* contains a special command-line tool (*pithcat*) for retrieving
images residing on a Pithos installation. To set up snf-image's Pithos
images residing on a Pithos installation. To set up *snf-image*'s Pithos
backend the user needs to setup the ``PITHOS_BACKEND_STORAGE`` variable
inside ``/etc/default/snf-image``.
Possible values are ``nfs`` and ``rados``. If ``nfs`` is used the user needs
to setup ``PITHOS_DATA`` variable, and when ``rados`` is used the user needs
to setup ``PITHOS_RADOS_POOL_MAPS`` and ``PITHOS_RADOS_POOL_BLOCKS``
to setup *PITHOS_DATA* variable, and when ``rados`` is used the user needs
to setup *PITHOS_RADOS_POOL_MAPS* and *PITHOS_RADOS_POOL_BLOCKS*
accordingly.
* **Null backend**:
......@@ -125,8 +126,8 @@ newly created block device. The following back-ends are supported:
Image Configuration Tasks
^^^^^^^^^^^^^^^^^^^^^^^^^
Configuration tasks are scripts called by snf-image-helper inside the helper VM
to accomplish various configuration steps on the newly created instance. See
Configuration tasks are scripts called by *snf-image-helper* inside the helper
VM to accomplish various configuration steps on the newly created instance. See
below for a description of each one of them:
**FixPartitionTable**: Enlarges the last partition in the partition table of
......
......@@ -39,7 +39,7 @@ master_doc = 'index'
# General information about the project.
project = u'snf-image'
copyright = u'2011, 2012, 2013 GRNET S.A. All rights reserved'
copyright = u'2011, 2012, 2013, 2014 GRNET S.A. All rights reserved'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
......
Configuration
=============
The user may configure the behavior of snf-image by uncommenting and
The user may configure the behavior of *snf-image* by uncommenting and
overwriting the default value for some configuration parameters and the path of
some external programs in ``/etc/default/snf-image``:
......@@ -42,7 +42,7 @@ some external programs in ``/etc/default/snf-image``:
# HELPER_USER="nobody"
# HELPER_MEMORY: Virtual RAM size in megabytes to be given to the helper VM.
# HELPER_MEMORY="500"
# HELPER_MEMORY="512"
# MULTISTRAP_CONFIG: Configuration file to be used with multistrap to create
# the rootfs of the helper image.
......@@ -53,7 +53,7 @@ some external programs in ``/etc/default/snf-image``:
# MULTISTRAP_APTPREFDIR="/etc/snf-image/apt.pref.d"
# XEN_SCRIPTS_DIR: Directory where the Xen scripts are stored
# XEN_SCRIPTS_DIR=="/etc/xen/scripts"
# XEN_SCRIPTS_DIR="/etc/xen/scripts"
# PITHOS_DB: Pithos database in SQLAlchemy format
# PITHOS_DB="sqlite://///var/lib/pithos/backend.db"
......@@ -61,15 +61,15 @@ some external programs in ``/etc/default/snf-image``:
# PITHOS_BACKEND_STORAGE: Select Pithos backend storage. Possible values are
# 'nfs' and 'rados'. According to the value you select, you need to set the
# corresponding variables that follow.
# If you select 'nfs' that's 'PITHOS_DATA'. If you select 'rados' then you
# need to set all the "*_RADOS_*" ones.
# If you select 'nfs' that's 'PITHOS_DATA'. If you select 'rados' then you need
# to set all the "*_RADOS_*" ones.
# PITHOS_BACKEND_STORAGE="nfs"
# PITHOS_DATA: Directory where Pithos data are hosted
# PITHOS_DATA="//var/lib/pithos/data"
# PITHOS_RADOS_CEPH_CONF: RADOS configuration file
# PITHOS_RADOS_CEPH_CONF="@sysconfdir@/ceph/ceph.conf"
# PITHOS_RADOS_CEPH_CONF="/etc/ceph/ceph.conf"
# PITHOS_RADOS_POOL_MAPS: RADOS pool for storing Pithos maps
# PITHOS_RADOS_POOL_MAPS="maps"
......@@ -77,12 +77,15 @@ some external programs in ``/etc/default/snf-image``:
# PITHOS_RADOS_POOL_BLOCKS: RADOS pool for storing Pithos blocks
# PITHOS_RADOS_POOL_BLOCKS="blocks"
# PROGRESS_MONITOR: External program that monitors the progress of image
# deployment. Monitoring messages will be redirected to the standard input of
# this program.
# PITHOS_ARCHIPELAGO_CONF: Archipelago configuration file
# PITHOS_ARCHIPELAGO_CONF="/etc/archipelago/archipelago.conf"
# PROGRESS_MONITOR: External program that monitors the progress of the image
# deployment. The snf-image monitor messages will be redirected to the standard
# input of this program.
# PROGRESS_MONITOR=""
# UNATTEND: This variables overwrites the unattend.xml file used when deploying
# UNATTEND: This variable overwrites the unattend.xml file used when deploying
# a Windows image. snf-image-helper will use its own unattend.xml file if this
# variable is empty. Please leave this empty, unless you really know what you
# are doing.
......@@ -90,6 +93,7 @@ some external programs in ``/etc/default/snf-image``:
# Paths for needed programs. Uncomment and change the variables below if you
# don't want to use the default one.
# KVM="kvm"
# LOSETUP="losetup"
# KPARTX="kpartx"
# SFDISK="sfdisk"
......@@ -106,18 +110,18 @@ The most common configuration parameters the user may need to overwrite are:
* **IMAGE_DIR**: To specify the directory where the local images are hosted
* **HELPER_SOFT_TIMEOUT**: To increase the allowed deployment time
* **PITHOS_DB**: To specify the Pithos database and credentials, in case the
user is accessing pithos-hosted images
* **PITHOS_DATA**: To specify the directory where the pithos data blocks are
hosted, in case the user is accessing pithos-hosted images
user is accessing Pithos-hosted images
* **PITHOS_DATA**: To specify the directory where the Pithos data blocks are
hosted, in case the user is accessing Pithos-hosted images
* **PROGRESS_MONITOR**: To specify an executable that will handle the
monitoring messages exported by snf-image
monitoring messages exported by *snf-image*
Paths of external programs
^^^^^^^^^^^^^^^^^^^^^^^^^^
In ``/etc/default/snf-image`` the user may also overwrite the path of some
external programs snf-image uses, or add default options to them. For example,
if the user wants to access network based images via insecure SSL connections,
he/she will need to overwrite the value of the *CURL* variable like this:
``CURL="curl -k"``
external programs *snf-image* uses, or add default options to them. For
example, if the user wants to access network based images via insecure SSL
connections, he/she will need to overwrite the value of the *CURL* variable
like this: ``CURL="curl -k"``
Installation
============
Before installing snf-image be sure to have a working Ganeti installation in
Before installing *snf-image* be sure to have a working Ganeti installation in
your cluster. The installation process should take place in **all** Ganeti
nodes. Here we will describe the installation in a single node. The process is
identical for all nodes and should be repeated manually or automatically, e.g.,
......@@ -39,12 +39,12 @@ the post install phase of the package installation.
Ubuntu
^^^^^^
For Ubuntu 12.04 LTS we provide packages in our APT repository. To use our
For Ubuntu 14.04 LTS we provide packages in our APT repository. To use our
repository add the following lines to file ``/etc/apt/sources.list``:
``deb http://apt.dev.grnet.gr precise/``
``deb http://apt.dev.grnet.gr trusty/``
``deb-src http://apt.dev.grnet.gr precise/``
``deb-src http://apt.dev.grnet.gr trusty/``
After you update ``/etc/apt/sources.list`` import the repo's GPG key:
......@@ -76,7 +76,7 @@ To add the GRNET repository in your system, run:
You can verify the authenticity of the package using our public key found
`here <https://dev.grnet.gr/files/apt-grnetdev.pub>`_.
To install snf-image run:
To install *snf-image* run:
.. code-block:: console
......@@ -104,7 +104,7 @@ Untar, configure and build the source:
$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
$ make
Install snf-image:
Install *snf-image*:
.. code-block:: console
......
......@@ -24,7 +24,7 @@ following OS Parameters:
Image Format (img_format)
^^^^^^^^^^^^^^^^^^^^^^^^^
snf-image supports 3 different types of image formats:
*snf-image* supports 3 different types of image formats:
* **diskdump** (recommended): a raw dump of a disk
* **extdump**: a raw dump of an ext{2,3,4} file system
......@@ -57,8 +57,8 @@ to be used. If no prefix is used, it defaults to the local back-end:
* **Network backend**:
If the **imd_id** starts with ``http:``, ``https:``, ``ftp:`` or ``ftps:``,
snf-image will treat the **img_id** as a remote URL and will try to fetch the
image using `cURL <http://curl.haxx.se/>`_.
*snf-image* will treat the **img_id** as a remote URL and will try to fetch
the image using `cURL <http://curl.haxx.se/>`_.
| For example, if we want to deploy an image from an http location:
| ``img_id=http://www.synnefo.org/path/to/image/slackware-image``
......@@ -66,13 +66,13 @@ to be used. If no prefix is used, it defaults to the local back-end:
* **Pithos backend**:
If the **img_id** is prefixed with ``pithos://`` or ``pithosmap://`` the
image is considered to reside on a Pithos deployment. For ``pithosmap://``
images, the user needs to have set a valid value for the ``PITHOS_DATA``
variable in snf-image's configuration file (``/etc/default/snf-image`` by
default) if the storage backend is ``nfs`` or ``PITHOS_RADOS_POOL_MAPS`` and
``PITHOS_RADOS_POOL_BLOCKS`` if the storage backend is ``rados``.
For ``pithos://`` images, in addition to ``PITHOS_DATA`` or
``PITHOS_RADOS_POOL_*``, the user needs to have set a valid value for the
``PITHOS_DB`` variable, too.
images, the user needs to have set a valid value for the *PITHOS_DATA*
variable in *snf-image*'s configuration file (``/etc/default/snf-image`` by
default) if the storage backend is ``nfs`` or *PITHOS_RADOS_POOL_MAPS* and
*PITHOS_RADOS_POOL_BLOCKS* if the storage backend is ``rados``.
For ``pithos://`` images, in addition to *PITHOS_DATA* or
*PITHOS_RADOS_POOL_**, the user needs to have set a valid value for the
*PITHOS_DB* variable, too.
| For example, if we want to deploy using a full Pithos URI:
| ``img_id=pithos://<user-uuid>/<container>/<slackware-image>``
......@@ -98,10 +98,10 @@ Image Properties (img_properties)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*snf-image* may use a number of properties to properly configure the image.
Those image properties are passed to snf-image by Ganeti through the
*img_poroperties* OS parameter (see Ganeti OS Interface). The name of all image
properties is case-insensitive. For the diskdump format some properties are
mandatory. For {ext,ntfs}dump formats all image properties are optional.
Those image properties are passed to *snf-image* by Ganeti through the
**img_poroperties** OS parameter (see Ganeti OS Interface). The name of all
image properties is case-insensitive. For the *diskdump* format some properties
are mandatory. For *{ext,ntfs}dump* formats all image properties are optional.
We can group image properties in two categories:
......@@ -116,11 +116,11 @@ Mandatory properties (for diskdump only)
* **OSFAMILY=linux|windows|freebsd|netbsd|openbsd**
This specifies whether the image is a Linux, a Windows or a \*BSD Image.
{ext,ntfs}dump formats are self descriptive regarding this property.
*{ext,ntfs}dump* formats are self descriptive regarding this property.
* **ROOT_PARTITION=n**
This specifies the partition number of the root partition. As mentioned
earlier, for now, only primary partitions are supported. This property is
trivial for {ext,ntfs}dump formats (they only host one partition).
trivial for *{ext,ntfs}dump* formats (they only host one partition).
Optional properties
+++++++++++++++++++
......@@ -138,9 +138,19 @@ Optional properties
* **DO_SYNC=yes**
By default in ResizeUnmounted task, when ``resize2fs`` is executed to
enlarge a ext[234] file system, ``fsync()`` is disabled to speed up the
whole process. I for some reason you need to disable this behavior, use the
whole process. If for some reason you need to disable this behavior, use the
*DO_SYNC* image property.
* **IGNORE_UNATTEND=yes**
When deploying a Windows image, the InstallUnattend configuration task will
install an Answer File for Unattended Installation (the one shipped with
*snf-image* or the one pointed out by the *UNATTEND* configuration
parameter) only if such a file is not already present in the root directory
of the image's %SystemDrive%. By defining this property, the installation of
the external answer file is always performed, even if such a file already
exists in the above-mentioned location. For more information on "answer
files" please refer to :ref:`windows-deployment`.
* **PASSWORD_HASHING_METHOD=md5|sha1|blowfish|sha256|sha512**
This property can be used on Unix instances to specify the method to be used
to hash the users password. By default this is determined by the type of the
......@@ -156,7 +166,7 @@ Optional properties
kernel will assign to this partition. For example, if you have a disk with
an MSDOS partition table on it and one primary partition, the image
property *SWAP=2:512* would instruct *snf-image* to create a 512MB long
primary partition for swap with id=2. On the other hand, if the SWAP
primary partition for swap with id=2. On the other hand, if the *SWAP*
property had this form: *SWAP=5:512*, since primary partitions may have an
id from 1 to 4, *snf-image* would create a 512MB extended partition with
id=2 and a logical swap partition with id=5 in it with the same size. This
......@@ -166,7 +176,7 @@ Optional properties
If this property is defined with a value other than null, then during the
deployment, the image will not be configured at all. This is really handy
because it gives the ability to deploy images hosting operating systems
whose configuration is not supported by snf-image.
whose configuration is not supported by *snf-image*.
* **EXCLUDE_TASK_<task_name>=yes**
This family of properties gives the ability to exclude individual
......@@ -184,7 +194,7 @@ Optional properties
img_properties OS parameter
+++++++++++++++++++++++++++
Image properties are passed to snf_image through the img_properties OS
Image properties are passed to *snf-image* through the **img_properties** OS
parameter as a simple JSON string like the one below:
| {
......@@ -199,7 +209,7 @@ parameter as a simple JSON string like the one below:
A real life example for creating a new Ganeti instance and passing image
properties to snf-image looks like this:
properties to *snf-image* looks like this:
.. code-block:: console
......@@ -227,14 +237,21 @@ array supports the following keys:
* **mode**: The permission mode of the file (number)
The first two (path, contents) are mandatory. The others (owner, group, mode)
are optional and their default value is root, root and 0440 respectively.
are optional and their default value is root, root and 288 (0440) respectively.
.. warning::
The mode field expects is a decimal number. ``chmod`` and the other similar
Unix tools expect octal numbers. The ``-r--r-----`` mode which is written as
440 is in fact the octal number 0440 which equals to 288. Since the JSON
standard does not support octal number formats, the user needs to do the
translation himself.
Example
+++++++
The JSON string below defines two files (*/tmp/test1*, */tmp/test2*) whose
content is ``test1\n`` and ``test2\n``, they are both owned by *root:root* and
their permissions are ``-rw-r--r--`` [#]_
their permissions are ``-rw-r--r--`` (0644):
| [
| {
......@@ -242,7 +259,7 @@ their permissions are ``-rw-r--r--`` [#]_
| "contents": "dGVzdDENCg==",
| "owner": "root",
| "group": "root",
| "mode": 0644
| "mode": 420
| },
| {
| "path": "/tmp/test2",
......@@ -253,4 +270,3 @@ their permissions are ``-rw-r--r--`` [#]_
| }
| ]
.. [#] The first mode is in octal representation and the second in decimal.
......@@ -8,7 +8,7 @@ Sample Images
While developing *snf-image*, we created and tested a number of images. The
following images are basic installations of some popular Linux distributions,
that have been tested with snf-image and provided here for testing purposes:
that have been tested with *snf-image* and provided here for testing purposes:
* Debian Wheezy Base System
......@@ -66,19 +66,19 @@ Sample Usage
Download an Image
+++++++++++++++++
Download a :ref:`Sample Image <sample-images>` and store it under IMAGE_DIR.
Download a :ref:`Sample Image <sample-images>` and store it under *IMAGE_DIR*.
Make sure you also have its corresponding metadata file.
Spawn a diskdump image
++++++++++++++++++++++
If you want to deploy an image of type diskdump, you
need to provide the corresponding *img_properties* as described in the
:ref:`Image Format<image-format>` section. If using a diskdump found in the
:ref:`sample-images` list, use the *img_properties* described in the image's
To deploy an image of type *diskdump*, you need to provide the corresponding
**img_properties** as described in the
:ref:`Image Properties<image-properties>` section. If you want to use one of
the :ref:`sample-images`, use the **img_properties** described in the image's
metadata file. For example, to successfully deploy the
*debian_base-7.0-x86_64.diskdump* image file, you need to provide the following
image properties:
``debian_base-7.0-x86_64.diskdump`` image file, you need to provide the
following image properties:
| OSFAMILY=linux
| ROOT_PARTITION=1
......@@ -94,7 +94,7 @@ like this:
-t plain --disk=0:size=10G --no-name-check --no-ip-check --no-nics my_debian_server1
If you don't want to configure the image at all and just copy it to the Ganeti
provided disk, use the ``EXCLUDE_ALL_TASKS`` image property, like this:
provided disk, use the *EXCLUDE_ALL_TASKS* image property, like this:
.. code-block:: console
......
__version__ = "0.15.2"
__version__ = "0.16"
......@@ -479,7 +479,7 @@ get_unattend() {
target="$1"
# Workaround to search for $target/Unattend.xml in an case insensitive way.
exists=$(find "$target"/ -maxdepth 1 -iname unattend.xml)
exists=$(find "$target"/ -maxdepth 1 -iregex ".*/\(auto\)?unattend\.xml" )
if [ $(wc -l <<< "$exists") -gt 1 ]; then
log_error "Found multiple Unattend.xml files in the image:" $exists
fi
......
......@@ -60,7 +60,7 @@ def main():
infh = sys.stdin if input_file is None else open(input_file, 'r')
outfh = open(output_file, 'w')
properties = json.load(infh)
properties = json.load(infh, strict=False)
for key, value in properties.items():
os.environ['SNF_IMAGE_PROPERTY_' + str(key).upper()] = value
......
......@@ -73,7 +73,7 @@ def parse_arguments(input_args):
def main():
(input_file, target, decode) = parse_arguments(sys.argv[1:])
files = json.load(input_file)
files = json.load(input_file, strict=False)
if decode:
manifest = open(target + '/manifest', 'w')
......
......@@ -47,7 +47,7 @@ mkdir -p "$target/Windows/Setup/Scripts"
unattend=$(get_unattend "$target")
if [ -n "$unattend" -a -z "$SNF_IMAGE_PROPERTY_USE_DEFAULT_UNATTEND" ]; then
if [ -n "$unattend" -a -z "$SNF_IMAGE_PROPERTY_IGNORE_UNATTEND" ]; then
warn "Using the Unattend.xml file found in the image"
else
rm -f "$unattend"
......
......@@ -82,7 +82,7 @@ windows_password() {
for usr in $SNF_IMAGE_PROPERTY_USERS; do
echo -n "Installing new password for user \`$usr'..."
echo "net user $usr $password" >> \
echo "net user $usr $password /ACTIVE:YES /LOGONPASSWORDCHG:NO /EXPIRES:NEVER /PASSWORDREQ:YES" >> \
"$target/Windows/SnfScripts/ChangeAdminPassword.cmd"
echo done
done
......
......@@ -5,6 +5,8 @@
<DisableAutoDaylightTimeSet>false</DisableAutoDaylightTimeSet>
<TimeZone>GTB Standard Time</TimeZone>
<ComputerName>*</ComputerName>
<RegisteredOrganization>Microsoft</RegisteredOrganization>
<RegisteredOwner>AutoBVT</RegisteredOwner>
<CopyProfile>true</CopyProfile>
<DoNotCleanTaskBar>true</DoNotCleanTaskBar>
</component>
......@@ -17,30 +19,30 @@
<component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<RunSynchronous>