IMG (Image Me Give) is a small python client/server application suite which manages the supervision of the MIC2 image creation following the submission of a ks file by the user. Before proceeding with the reading of this document the reader is asked to consult the IMG main page.
The first version of this page has been created after a successful OpenSuse IMG installation based on the document IMG Installation for Debian] as friendly provided by Nokia. The publisher acknowledges this fact and thanks Nokia for its support.
The installation of IMG implies the installation of all of the the dependencies of packages associated with the IMG. It may occur that different versions of these dependencies are hosted on different locations and versions conflicts arise. In this case, the user must assure that he works with the right version of a package:
zypper -qi package zypper info package
With few exceptions, all the commands of the installation procedure below can be entered in the "sudo" mode.
Remark: If available, the user is highly encouraged to install and to use YAST which is a time-saving complement to the commandline mode presented in the following.
Launch:
sudo zypper lr -d
in order to check which repositories have already been added. The repositories below are normally present by default on an OpenSuse machine, but you must add them if this is not the case:
zypper ar http://download.opensuse.org/distribution/11.4/repo/oss/ openSUSE-11.4-distr-repo-oss zypper ar http://download.opensuse.org/distribution/11.4/repo/non-oss/ openSUSE-11.4-distr-repo-non-oss zypper ar http://download.opensuse.org/update/11.4/ openSUSE-11.4-update
Following repositories, if not present, must be now added in order to guarantee a seamless installation of all the dependencies:
zypper ar http://repo.pub.meego.com/Project:/MINT:/Testing/openSUSE_11.4/Project:MINT:Testing.repo zypper ar http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_11.4/openSUSE:Tools.repo zypper ar http://download.opensuse.org/repositories/devel:/languages:/perl/openSUSE_11.4/devel:languages:perl.repo zypper ref
The packages "python-django" and "python-django-south" are dependencies of the "img-web" package. Assure that the latest versions of these 2 packages are installed from the repository:
http://download.opensuse.org/factory/repo/oss/suse/noarch
by doing a remote installation:
zypper in http://download.opensuse.org/factory/repo/oss/suse/noarch/python-django-1.3-4.2.noarch.rpm zypper in http://download.opensuse.org/factory/repo/oss/suse/noarch/python-django-south-0.7.2-2.1.noarch.rpm
where python-django-1.3-4.2.noarch.rpm and python-django-south-0.7.2-2.1.noarch.rpm are the currently latest versions of the packages "python-django" and "python-django-south". Alternatively, you can first download the latest versions of the packages "python-django" and "python-django-south" from the "factory" repository above to your local machine and then install the packages locally:
zypper in python-django zypper in python-django-south
Remark: As factory is not a fully maintain repository, you cannot register "factory" in the list of your default repositories and you must thus do the download from the full URL.
Install the latest version of the package "python-amqplib" from the MINT:Testing.repo (that we have activated when starting this procedure):
zypper in python-amqplib
The version of the installed package can be now verified by:
rpm -qi python-amqplib
The version sould be 0.6.1, release 3.1 or better.
Install manually the latest version of the "python-flup" package:
python-flup-1.0.2-2.1.noarch.rpm
from the repository:
http://software.opensuse.org/search?q=flup&baseproject=openSUSE%3A11.4&lang=en&exclude_debug=true
by downloading it first to your local machine and subsequently performing a local installation:
zypper in python-flup.
Now, install the package "img-web":
zypper in img-web
Following the successful installation of img-web launch the mysql-server:
/etc/init.d/mysql start
Update the file:
/etc/mic2/mic2.conf
You can adapt it to your needs and may specify a proxy or change the default image format.
SkyNET facilitates the management of BOSS participants and permits control of each BOSS participant (start/stop/reload/status). By default, SkyNET is already correctly preconfigurated following BOSS & SkyNET installation and the user has nothing to do. The configuration is done in:
/etc/skynet/skynet.conf
The main value that needs to be set is the "amqp_host". Verify that your file "skynet.conf" contains the following lines:
# This section controls the default BOSS instance. [boss] amqp_host = 127.0.0.1:5672 amqp_user = boss amqp_pwd = boss amqp_vhost = boss
SkyNET launches participants without any system environment. Some installations may need to set proxy information. This can be done in:
/etc/skynet/skynet.env
By default, SkyNET participants are installed to:
/var/lib/SkyNET/store
Following a correct BOSS/SkyNET installation you should have 6 participants in the directory with "check" and "notify" being 2 particular participants as required for SkyNET launch:
>ll /var/lib/SkyNET/store
drwxr-xr-x 4 root root 4096 21 juil. 12:03 build_image drwxr-xr-x 4 root root 4096 21 juil. 12:03 build_ks drwxr-xr-x 4 root root 4096 8 juil. 11:01 check drwxr-xr-x 4 root root 4096 8 juil. 11:02 notify drwxr-xr-x 4 root root 4096 21 juil. 12:03 request_image drwxr-xr-x 4 root root 4096 21 juil. 12:03 update_image_status
Finally, launch SkyNET with:
/usr/share/boss-skynet/skynet_launch
The log files for a participant $NAME can be found in:
/var/lib/SkyNET/store/$NAME/log/main/current
For more details see the SkyNET page Working with SkyNET.
The SkyNET participants are listed below:
1) build_image (worker) 2) build_ks 3) request_image 4) update_image_status
The participant "Build_image" is the actual image building worker. Depending on its configuration it will:
Configuration of the image building worker is done in "/etc/skynet/build_image.conf"
The two important configuration options are base_url and base_dir:
You will need to do:
install -d -m 0777 /var/www/img/images
An example of the correct "build_img.conf" file is presented below:
>cat /etc/skynet/build_image.conf
[worker] base_url = http://127.0.0.1/img base_dir = /var/www/img/images use_kvm = no use_sudo = yes mic_opts = --save-kernel img_home = /usr/share/img img_tmp = /tmp/ id_rsa = /usr/share/img/id_rsa base_img = /usr/share/img/base.img
In order to run the MIC2 tool, the nobody user needs sudo rights for mic-image-creator:
chmod 0640 /etc/sudoers cat >> /etc/sudoers << EOF nobody ALL=(ALL)NOPASSWD:/usr/bin/mic-image-creator EOF chmod 0440 /etc/sudoers
In the KVM mode, IMG first creates an overlay image from the base image (not distributed) and then starts it using the overlay image as the hard disk. Virtio is used as a speed optimisation method for KVM. After the elapse of a specified time interval IMG will copy the ks file and the MIC2 configuration file to the guest VM. Subsequently, it runs MIC2 in the VM with parameters specified in the init method. Following a successful MIC2 run, the created images are copied from the guest VM via scp.
Once the worker has been configured it should be started and registered. Enable (start) the participant via:
skynet enable build_image
Register the participant to SkyNET:
skynet register -n build_image
This participant validates and manipulates the kickstart file. When extra repositories and packages are added to the ks file, this information is handled by "build_ks".
Only one participant should be running. It should be launched on the same machine as "img-web". In order to configure the particpant, edit the file:
/etc/skynet/build_ks.conf
Set "reposerver" to point to the OBS http repository server (the user-facing download server, not the backend bs_reposrv system).
Set "ksstore" to point to the location that holds the kickstart files referenced by the webui.
Enable (start) the participant via:
skynet enable build_ks
As a one-off the participant should be registered to BOSS:
skynet register -n build_ks
This tells BOSS that there is at least one participant prepared to carry out this task. For more information see Working with SkyNET.
This participant allows IMG to be used by a normal BOSS process.
Enable (start) the participant
skynet enable request_image
Register the participant to SkyNET:
skynet register -n request_image
This participant updates the queue data for the IMG web ui when a worker finishes a job. No configuration is needed.
Enable (start) the participant
skynet enable update_image_status
Register the participant to SkyNET:
skynet register -n update_image_status
IMG uses a django web application to provide a UI. This WEB UI needs a MySQL DB to store information about the images.
MySQL is installed by default and during the installation a root account may have been created. Create now a password for the user "img" and grant him the appropriate rights on the MySQL IMG DB:
mysql -u root -p mysql>create database imgdb CHARACTER SET utf8; mysql>GRANT ALL ON imgdb.* TO 'img'@'localhost' IDENTIFIED BY 'img'; mysql>exit
Remark: By default, no password for the root user of MySQL will have been created, i.e. the password is an empty string. In such a case you should simply type "Enter" when demanded for password after entering the command "mysql -u root -p". Note: if you work on an OpenSUSE host with a default OBS installation or an OBS appliance the mysql root password is opensuse.
The Django interface is configured via the file "/etc/imager/img.conf". An example of the default version of this file is presented below:
[web] url_prefix=img doc_root = /var/www/ static_media_collect = %(doc_root)s%(url_prefix)s/site_media templates_dir = %(doc_root)s%(url_prefix)s/templates
[db] db_engine = mysql db_name = imgdb db_user = img db_pass = img
[boss] boss_host = 127.0.0.1 boss_user = boss boss_pass = boss boss_vhost = boss
[ldap] use_ldap = no ldap_server = ldaps://127.0.0.1 ldap_dn_template = uid=%(user)s,ou=example,dc=com ldap_mail_attr = mail ldap_fname_attr = givenName ldap_lname_attr = sn ldap_mail_attr = mail
[notify] enabled = yes
[test] enabled = yes devicegroup = devicegroup:mygroup
[processes] process_dir = /usr/share/img_web/processes create_image_process = %(process_dir)s/CREATE_IMAGE getlog_process = %(process_dir)s/UPDATE_STATUS notify_process = %(process_dir)s/NOTIFY_IMAGE test_process = %(process_dir)s/TEST_IMAGE delete_process = %(process_dir)s/DELETE_IMAGE
Set the configuration values in the file "/etc/imager/img.conf" as in this example or adapt them to your needs. Create now locations for the images and templates:
install -d -m 0777 /var/www/img/images install -d -m 0777 /var/www/img/templates
Setup django:
export DJANGO_SETTINGS_MODULE=img_web.settings ATTENTION: the export command above must be done by root, sudo is not admitted here!
For a successful synchronization between the MySQL DB and the WEB UI of IMG launch the command:
django-admin.py syncdb
Specify the superuser and the password for the WEB UI of IMG. You will need these identifiers when logging in the WEB UI of IMG. Accomplish the synchronization by doing:
django-admin.py migrate django-admin.py collectstatic
Create the file "/etc/lighttpd/vhosts.d/img.conf" with the following content:
var.namebasedir = "/img"
$HTTP["url"] =~ "^" + namebasedir {
dir-listing.activate = "disable"
}
url.redirect += ( "^" + namebasedir + "$" => namebasedir + "/" )
fastcgi.server += (
"/img.fcgi" => (
"main" => (
"socket" => "/var/run/img_web" + ".socket",
"check-local" => "disable",
)
),
)
url.rewrite-if-not-file += (
"^(" + namebasedir + "/.*)$" => "/img.fcgi/$1"
)
Now we will modify the following 2 lighttpd configuration files:
/etc/lighttpd/lighttpd.conf /etc/lighttpd/modules.conf
Add the following line at the end of the file "lighttpd.conf":
include "/etc/lighttpd/vhosts.d/img.conf"
For more information on the "lighttpd.conf" file the user is encouraged to consult the Doc on lighttpd
Assure the presence of the following block in the file "modules.conf" by uncommenting the needed server-modules and by putting the server.modules list inside the global block:
global{
server.modules = (
"mod_access",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_fastcgi",
"mod_rewrite",
# "mod_auth",
# "mod_evasive",
# "mod_redirect",
# "mod_setenv",
# "mod_usertrack",
)
}
First you have to start the lighttpd fastcgi server:
service lighttpd start
Start IMG with the following command:
service img-web start
The locations of the user WI, of the admin WI and of the images WI are listed below:
http://127.0.0.1/img/ http://127.0.0.1/img/admin/ http://127.0.0.1/img/images
In order to check that IMG has been successfully launched verify that you can access these pages. Choose the "Create an image" action and try to create an image with a valid ks file.
In order to see the list of participants enter:
skynet list
In order to view a participant log enter one of the follwing:
skynet log build_image skynet log build_ks skynet log request_image skynet log update_image_status
The command "skynet log build_image" will provide you the path to the directory cotaining the input ks file and a build image log file. In the case of a successful image creation this directory will also contain an iso file. The user is encouraged to consult the document Working with SkyNET for more details.
Description:
Following the change/update of the configuration files of lighttpd/img-web or modifications of the source code of img-web and the relaunch of the lighttpd server and of the img-web service the corresponding WEB UI page of the server didn't change.
Resolution:
Clean the cache of your browser.
Description:
Over a period of time too many image creation jobs appear on the WI queue page and the user is annoyed. He wants to see only the recently launched jobs.
Resolution example:
In order to see only the last 5 jobs and to delete from the WI queue page all except the most recent 5 jobs launch the command below:
>mysql -u root -p imgdb -e "DELETE FROM app_imagejob ORDER BY created ASC LIMIT 5"
Refresh the WI queue page in order to see that only the 5 most recent jobs appear. Subsequently, you have the option to delete the corresponding directories on your Linux machine if you are sure that you will never need this data. The relevant directories are stored in:
/var/www/img/images/web/$userid>ll total 96 drwxr-xr-x 2 nobody nobody 4096 26 juil. 14:09 1-20110726-140904 drwxr-xr-x 2 nobody nobody 4096 26 juil. 14:09 1-20110726-140931 drwxr-xr-x 2 nobody nobody 4096 26 juil. 14:09 1-20110726-140958 drwxr-xr-x 2 nobody nobody 4096 26 juil. 14:11 1-20110726-141146 drwxr-xr-x 2 nobody nobody 4096 26 juil. 14:38 1-20110726-143847 drwxr-xr-x 2 nobody nobody 4096 26 juil. 15:54 1-20110726-144925 drwxr-xr-x 2 nobody nobody 4096 26 juil. 16:15 1-20110726-153015 drwxr-xr-x 2 nobody nobody 4096 27 juil. 16:01 1-20110727-160143
Remark: In future IMG releases the user will have the option to launch this operation automatically via a tab menu on the WI queue page.