Revision b2b9a247

b/docs/advanced.rst
76 76
image-info
77 77
++++++++++
78 78

  
79
This message type is used to display random progress information. It has an
79
This message type is used to display arbitrary progress information. It has an
80 80
extra *messages* field whose value is a list of strings. A valid ``image-info``
81 81
message looks like this:
82 82

  
b/docs/architecture.rst
15 15
| 1. Fill the newly provisioned disk with Image data
16 16
| 2. Customize the Image accordingly
17 17

  
18
For (1), snf-image can fetch the Image from a number of backends, as we describe
19
later. For (2) snf-image spawns a helper VM and runs a number of configuration
20
tasks inside the isolated environment. Once the last task returns successfully,
21
the helper VM ceases and snf-image returns the newly configured disk to Ganeti.
18
For (1), snf-image can fetch the Image from a number of back-ends, as we
19
describe later. For (2) snf-image spawns a helper VM and runs a number of
20
configuration tasks inside the isolated environment. Once the last task returns
21
successfully, the helper VM ceases and snf-image returns the newly configured
22
disk to Ganeti.
22 23

  
23 24
The whole procedure is configurable via OS interface parameters, that can be
24 25
passed to snf-image from the Ganeti command line or RAPI.
......
47 48
The snf-image-helper component runs inside a specific environment, which is
48 49
created and ensured by snf-image:
49 50

  
50
 * The VM features a virtual floppy, containing an ext2 filesystem with all
51
 * The VM features a virtual floppy, containing an ext2 file system with all
51 52
   parameters needed for image customization.
52 53
 * The hard disk provided by Ganeti that we want to deploy and customize is
53
   accessible as the first virtio hard disk.
54
   accessible as the first VirtIO hard disk.
54 55
 * All kernel/console output is redirected to the first virtual serial console,
55 56
   and eventually finds its way into the OS definition log files that Ganeti
56 57
   maintains.
......
66 67
snf-image-helper
67 68
^^^^^^^^^^^^^^^^
68 69

  
69
This part runs inside the helper VM during bootup and undertakes customization
70
This part runs inside the helper VM during boot-up and undertakes customization
70 71
of the target disk. It does so, by running a number of :ref:`configuration
71 72
tasks <image-configuration-tasks>`. The exact tasks that should run, are
72 73
specified by rules found in the virtual floppy, placed there by *snf-image*,
......
83 84

  
84 85
.. _storage-backends:
85 86

  
86
Storage backends
87
^^^^^^^^^^^^^^^^
87
Storage back-ends
88
^^^^^^^^^^^^^^^^^
88 89

  
89 90
As stated above, for step (1), *snf-image* is capable of fetching images that
90
are stored in a variety of different backends and then extracting them onto the
91
newly created block device. The following backends are supported:
92

  
93
 * **Local backend**:
94
   The local backend is used to retrieve images that are stored on the Ganeti
95
   node that the image deployment takes place. All local images are expected to be
96
   found under a predifined image directory. By default */var/lib/snf-image* is
97
   used, but the user may change this by overwriting the value of the
91
are stored in a variety of different back-ends and then extracting them onto
92
the newly created block device. The following back-ends are supported:
93

  
94
 * **Local back-end**:
95
   The local back-end is used to retrieve images that are stored on the Ganeti
96
   node that the image deployment takes place. All local images are expected to
97
   be found under a predefined image directory. By default */var/lib/snf-image*
98
   is used, but the user may change this by overwriting the value of the
98 99
   *IMAGE_DIR* variable under ``/etc/default/snf-image``.
99 100

  
100
 * **Network backend**:
101
   The network backend is used to retrieve images that are accessible from the
102
   network. snf-image can fetch images via *http:*, *https:*, *ftp:* or *ftps:*,
103
   using `cURL <http://curl.haxx.se/>`_.
101
 * **Network back-end**:
102
   The network back-end is used to retrieve images that are accessible from the
103
   network. snf-image can fetch images via *http:*, *https:*, *ftp:* or
104
   *ftps:*, using `cURL <http://curl.haxx.se/>`_.
104 105

  
105
 * **Pithos backend**:
106
 * **Pithos back-end**:
106 107
   *snf-image* contains a special command-line tool (*pithcat*) for retrieving
107
   images residing on a Pithos installation. To set up snf-image's Pithos backend
108
   the user needs to setup the ``PITHOS_DATA`` and ``PITHOS_DB`` variables inside
109
   ``/etc/default/snf-image`` accordingly.
108
   images residing on a Pithos installation. To set up snf-image's Pithos
109
   back-end the user needs to setup the ``PITHOS_DATA`` and ``PITHOS_DB``
110
   variables inside ``/etc/default/snf-image`` accordingly.
110 111

  
111
 * **Null backend**:
112
   If the null backend is selected, no image copying is performed. This actually
113
   is meant for bypassing step (1) alltogether. This is useful, if the disk
114
   provisioned by Ganeti already contains an OS installation before *snf-image* is
115
   executed (for example if the disk was created as a clone of an existing VM's
116
   hard disk).
112
 * **Null back-end**:
113
   If the null back-end is selected, no image copying is performed. This
114
   actually is meant for bypassing step (1) altogether. This is useful, if the
115
   disk provisioned by Ganeti already contains an OS installation before
116
   *snf-image* is executed (for example if the disk was created as a clone of
117
   an existing VM's hard disk).
117 118

  
118 119
.. _image-configuration-tasks:
119 120

  
......
138 139
by *SNF_IMAGE_TARGET*. The script will fail if any of those 3 variables has a
139 140
non-sane value.
140 141

  
141
**AddSwap**: Formats the swap partion added by *FixPartitionTable* task and
142
**AddSwap**: Formats the swap partition added by *FixPartitionTable* task and
142 143
adds an appropriate swap entry in the system's ``/etc/fstab``. The script will
143 144
only run if *SNF_IMAGE_PROPERTY_SWAP* is present and will fail if
144 145
*SNF_IMAGE_TARGET* in not defined.
145 146

  
146
**DeleteSSHKeys**: For linux images, this script will clear out any ssh keys
147
found in the image and for debian, it will recreate them too. In order to find
147
**DeleteSSHKeys**: For Linux images, this script will clear out any ssh keys
148
found in the image and for Debian, it will recreate them too. In order to find
148 149
the ssh keys, the script looks in default locations (/etc/ssh/ssh_*_key) and
149 150
also parses ``/etc/ssh/sshd_config`` file if present. The script will fail if
150 151
*SNF_IMAGE_TARGET* is not set.
......
158 159
needed by windows in order to perform an unattended setup. The
159 160
*SNF_IMAGE_TARGET* variables needs to be present for this task to run.
160 161

  
161
**SELinuxAutorelabel**: Creates *.autorelabel* file in RedHat images. This is
162
**SELinuxAutorelabel**: Creates *.autorelabel* file in Red Hat images. This is
162 163
needed if SELinux is enabled to enforce an automatic file system relabeling at
163
the next boot. The only enviromental variable required by this task is
164
the next boot. The only environmental variable required by this task is
164 165
*SNF_IMAGE_TARGET*.
165 166

  
166 167
**AssignHostname**: Assigns or changes the hostname in a Linux or Windows
167 168
image. The task will fail if the Linux distribution is not supported. For now,
168
we support Debian, Redhat, Slackware, SUSE and Gentoo derived distros. The
169
hostname is read from *SNF_IMAGE_HOSTNAME* variable. In addition to the latter,
170
*SNF_IMAGE_TARGET* is also required.
169
we support Debian, Red Hat, Slackware, SUSE and Gentoo derived distributions.
170
The hostname is read from *SNF_IMAGE_HOSTNAME* variable. In addition to the
171
latter, *SNF_IMAGE_TARGET* is also required.
171 172

  
172 173
**ChangePassword**: Changes the password for a list of users. For Linux systems
173 174
this is accomplished by directly altering the image's ``/etc/shadow`` file. For
174 175
Windows systems a script is injected into the VM's hard disk. This script will
175
be executed during the specialize pass of the Windows setup. The list of users
176
whose passwords will changed is determined by the *SNF_IMAGE_PROPERTY_USERS*
177
variable (see :ref:`image-properties`). For this task to run *SNF_IMAGE_TARGET*
178
and *SNF_IMAGE_PASSWORD* variables need to be present.
176
be executed during the specialize pass of the Windows setup. For FreeBSD
177
``/etc/master.passwd`` is altered, ``/etc/spwd.db`` is removed and a script is
178
injected into the VM's hard disk that will recreate the aforementioned file.
179
The list of users whose passwords will changed is determined by the
180
*SNF_IMAGE_PROPERTY_USERS* variable (see :ref:`image-properties`). For this
181
task to run *SNF_IMAGE_TARGET* and *SNF_IMAGE_PASSWORD* variables need to be
182
present.
179 183

  
180 184
**FilesystemResizeMounted**: Injects a script into a Windows image file system
181 185
that will enlarge the last file system to cover up the whole partition. The
b/docs/interface.rst
116 116
+++++++++++++++++++
117 117

  
118 118
 * **USERS="username1 username2...."**
119
   This is a space-seperated list of users, whose password will be reset by
119
   This is a space-separated list of users, whose password will be reset by
120 120
   *snf-image*. The use of this property is optional, but highly recommended.
121 121
   For now, if this property is missing, the users are chosen according to a
122 122
   set of rules, but those rules may change or even be dropped in the future.

Also available in: Unified diff