Forgot your password?
New user?
Document Actions
Comoonics Enterprisecopy Users Guide
Users Guide for the Comoonics Enterprisecopy Suite
Users Guide
2007-03-06
| Revision History | ||
|---|---|---|
| Revision 1.0 | 2007-03-26 | MH |
| First Release | ||
Abstract
This userguide describes The comoonics Enterprisecopy™.
Table of Contents
This document uses the following conventions
Warning
Warning
This is a warning.
Caution
Caution
This cautions the reader.
Hint
Tip
This is a hint.
Note
Note
This is a note.
File name
file.extension
Directory name
directory
Commands to be typed
commandApplications Names
applicationPrompt of users command under bash shell
bash$
Prompt of root users command under bash shell
bash#
Prompt of user command under tcsh shell
tcsh$
Environment Variables
VARIABLE
Emphasized word
word
Quoted text
“quote”
Code Example
<para>Beginning and end of paragraph</para>
This userguide describes the usage of the Comoonics Enterprisecopy application.
This document, Comoonics Enterprisecopy - Users Guide , is copyrighted (c) 2007 by ATIX GmbH. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available at http://www.gnu.org/copyleft/fdl.html.
Linux is a registered trademark of Linus Torvalds.
No liability for the contents of this document can be accepted. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies, that could be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility.
All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.
Feedback is most certainly welcome for this document. Send
your additions, comments and criticisms to the following
email address : <grimme (at) atix.de> or
<hlawatschek (at) atix.de>.
The Comoonics Enterprisecopy Suite (comoonics-ec) is a software designed to help cloning and copying new Linux clusters or servers.
The comoonics-ec is part of the com.oonics cluster suite (comoonics-cs). It consists of two software packages - the comoonics-cs-py and the comoonics-ec-py packages. The comoonics-cs-py Package holds the base python libraries and binaries for the Comoonics Clustersuite which is the base for the packages comoonics-ec-py. This package provides all libraries and binaries for the Comoonics Enterprisecopy functionality itself. Both packages should always be available as RPMs.
Note
The comonics-cs package also has to be installed to
fulfill all dependencies.
First of all the RPM libxslt-python has to be installed.
Note
As the dependency in RHEL4 U3 of the RPM libxslt-python is broken it has to be installed manually. That means download it with up2date --get libxslt-pyton and then install it manually with rpm -ivh /var/spool/up2date/libxslt-python-1.1.11-1.*.rpm
Use the up2date command to install the comoonics rpms up2date -i comoonics-cs comoonics-ec-py comoonics-cs-py
The main tool providing the functionality to the user is the com-ec
binary normally found in /usr/bin/com-ec.
If you call com-ec -h it will output a help screen as shown in Figure 1, “Execution of com-ec”
Figure 1. Execution of com-ec
root@lilr627b:~# com-ec -h
/usr/bin/com-ec [-X|--onlyxslt] [-m|--modificationset value] [-x|--xslt value] [-a|--ask] [-U|--noundo] [-v|--version] [-n|--novalidate] [-d|--debug] [-c|--copyset value] [-h|--help] file [valuepath=value]*
The comoonics Enterprisecopy binary parses an xml configfile and then goes through every copy and modificationset and
does it.
-X|--onlyxslt only do the xslt work
-m|--modificationset value <name>|all only do all or the given modification set (default: None)
-x|--xslt value preconvert xmlfile with given xsltfile. (default: None)
-a|--ask ask before any command is executed
-U|--noundo don't do the undoing if anything goes wrong
-v|--version output the version
-n|--novalidate novalidate don't validate the xml. Handle with care!!!
-d|--debug toggle debugmode and be more helpful
-c|--copyset value <name>|all only do all or the given modification set (default: None)
-h|--help this help
calling com-ec -h or com-ec without any options shows which options you can choose.
com-ec can be called in diffrent oprational modes.
com-ec can be called with the debug and ask flags set. The debug (-d) flag enables the output of debug information whearas the ask (-a) flag enables an interactive processing. Both flags set, gives a good possibility to degung and verify the enterprise-copy configuration.
The com-ec processes all instrauctions given by the enterprise-copy process definition (ec-pd).
The process definition can be defined in a single XML file. (The enterprise-copy process definition file - ec-pdf).
As the process definition and the resulting process definition file can get very large and complex to adapt, com-ec supports XSL transformation. A XML based process definition template (ec-pdt) can be used together with a XSL file to create the process definition.
The basic part of the com-ec command is the enterprise-copy process
definition file (ec-pdf).
This is a normal XML file following the DTD found
in /opt/atix/comoonics_cs/xml/comoonics-enterprise-copy.dtd. A detailed
description of the
ec-pdf can be found in
the section called “The comoonics enterprisecopy process definition file”. A
really basic ec-pdf is shown in Figure 2, “A basic ec-pdf for the comoonics-ec”
Figure 2. A basic ec-pdf for the comoonics-ec
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE enterprisecopy SYSTEM
"file:/opt/atix/comoonics_cs/xml/comoonics-enterprise-copy.dtd">
<enterprisecopy name='clone-bootdisk-partitions'>
<copyset name='copy-bootdisk' type='partition'>
<source type='disk'>
<disk name='/dev/sda'/>
</source>
<destination type='disk'>
<disk name='/dev/sdc'/>
</destination>
</copyset>
</enterprisecopy>
Every comoonics-ec ec-pdf needs a name describing the job to be done. In this case the name is clone-bootdisk-partitions which tells us the sense of this job which is to clone the partitions of two disks. Every enterprisecopy process definition can have multiple childs of either copyset or modificationset. Basically the difference between a copyset and modificationset is that a copyset copys data described by the type from one source to one destination. A destitination or source themselves are again defined by a type and more children describing the type in more detail (again have a look at the section called “The comoonics enterprisecopy process definition file”). In this case either source or destitination are of the same type disk. One describes the source disk and the other the destination disk.
After creating the enterprise copy process definition file (ec-pdf), the clone process can be started.
Warning
A misconfigured ec-pdf can destroy all your data! If you are unsure about your ec-pdf, you should first run the com-ec in the “debug” and “ask” mode.
You should never execute com-ec without using any commandswitch if you created a configuration for the first time. Because every copy or modificationset can currupt all data on any stated destination. So first we will execute com-ec in the following way com-ec -a -d ./clone-bootdisk-partitions.xml
Tip
The ec-pdf creation can be simplified with the use of a xslt file
Figure 3. Example executing com-ec with baseconfig
root@lilr202a:~# com-ec -a -d ./clone-bootdisk-partitions.xml
-------Parsing document ./clone-bootdisk-partitions.xml--------
DEBUG:root:copyset, enterprisecopy
-----Execution of businesscopy clone-bootdisk-partitions-------
-----------Executing None copysets 1---------------------------
INFO:root:Executing copyset PartitionCopyset(copy-bootdisk:partition)
/usr/lib/python2.3/site-packages/comoonics/enterprisecopy/ComPartitionCopyset.py:45: RuntimeWarning: tempnam is a potential security risk to your program
__tmp=os.tempnam("/tmp")
DEBUG:root:/sbin/sfdisk -d /dev/sdc
/sbin/sfdisk -d /dev/sdc (y,n)y
DEBUG:root:/sbin/sfdisk -d /dev/sda
/sbin/sfdisk -d /dev/sda (y,n)y
DEBUG:root:partition tables are the same. No need to update
-------Executing None modificationsets 0-----------------------
------Successfully executed businesscopy. ---------------------
You can savely ignore the RuntimeWarning. Now what the copyset does,
is to copy the whole partitiontable from device /dev/sda to
/dev/sdc. But the copyset detects that both partitions are equal so
no update has to be done. If you are really sure what you are doning you can leave the
options -a and -d so the whole process is executed
without debug messages and without asking before every command executed.
The comoonics enterprisecopy process definition file (ec-pdf) consists of “copyset” and “medificationset” definitions (sets).
Note
The sets are processed in sequential order. I.e. one set after the other.
The ec-pdf is a XML file defined by the comoonics-enterprise-copy.dtd
DTD.
The parent element is the “enterprisecopy” with an unique “name”. The childs are “copyset” and “modificationset” elements.
Example:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE enterprisecopy SYSTEM "/opt/atix/comoonics-cs/xml/comoonics-enterprise-copy.dtd">
<enterprisecopy name='an_unique_name'>
<copyset .../>
<.../>
<modificationset .../>
<.../>
<enterprisecopy/>
A copyset is used to clone specific information from “source” to “destination” E.g. clone a coplete filesystem to another device or backup mechanism. It is described by a unique “name”, the “type” attribute, a “source” and a “destination” element.
The source and destination elements contain information about their “type”. I.e. they can be either a resource on the physical disk or an archive definition.
Example:
<copyset type='a_defined_type' name='a_unique_name'>
<source type='a_defined_type'>
<a_source_definition/>
</source>
<destination type='a_defined_type'>
<a_destination_definition/>
</destination>
</copyset>
The partition copyset is used to copy partition tables
Right now the following source and destination types are supported:
Example:
<copyset type='partition' name='copy-rootdisk'>
<source type='disk'>
<disk name='/dev/mapper/mpath1'/>
</source>
<destination type='backup'>
<metadata>
<archive name='/data/linux/clones/in/li//meta-clone-lilr627-02.tar' format='tar' type='file' compression='none'>
<file name='./partition-root.xml'/>
</archive>
</metadata>
</destination>
</copyset>
The LVM copyset is used to copy LVM volumegroups
Right now the following source and destination types are supported:
Example:
<copyset type='lvm' name='copy-lvm-root'>
<source type='lvm'>
<volumegroup name='vg_lilr627_sr'/>
</source>
<destination type='backup'>
<metadata>
<archive name='/data/linux/clones/in/li//meta-clone-lilr627-02.tar' format='tar' type='file' compression='none'>
<file name='./lvm-root.xml'/>
</archive>
</metadata>
</destination>
</copyset>
The filesystem copyset is used to copy filesystem data and meta information
Right now the following source and destination types are supported:
The filesystem type represents a filesystem on the pysical disks connected to the computer. I.e. all meta information like filesystem type, and blocksize and all data will be used to copy to or from a filesystem.
Example:
<copyset type='filesystem' name='copy-sharedroot'>
<source type='filesystem'>
<device id='sourcerootfs' name='/dev/vg_lilr627_sr/lv_sharedroot' options='skipmount'>
<filesystem type='gfs'/>
<mountpoint name='/'/>
</device>
</source>
<destination type='backup'>
<metadata>
<archive name='/data/linux/clones/in/li//meta-clone-lilr627-02.tar' format='tar' type='file' compression='none'>
<file name='./fs-root.xml'/>
</archive>
</metadata>
<data>
<archive name='/data/linux/clones/in/li//root-clone-lilr627-02.tgz' format='tar' type='file' compression='gzip'/>
</data>
</destination>
</copyset>
The Bootloader copyset is used to copy bootloders. Note that in the current release, only the “grub” bootloader is supported.
Right now the following source and destination types are supported:
Note
Only the “grub” bootloader is supported. The bootloader cannot be archived.
Example:
<copyset type='bootloader' name='bootloader'>
<source type='none'/>
<destination type='disk'>
<disk name='/dev/mapper/mpath3'/>
<bootloader type='grub'/>
</destination>
</copyset>
A modification set is used to perform modifications on a system. Typically host or cluster specific configuration files are modified. But generally all kind of modification are possible.
The set is defined by a “type” and has an unique “name”.
The first child element defines the destination, where the underlying list of modifications are done.
Example:
<modificationset type='a_valid_type' name='an_unique_name'>
<a_type_specific_destination>
<modification type='a_valid_type'>
<modification_information/>
</modification>
<modification type='a_valid_type'>
<modification_information/>
</modification>
</modificationset>
A modification can have a “requirement”, that has to be done before the real modification is performed
Example:
<modification type='a_valid_type'>
<requirement .../>
<the_real_modification/>
</modification>
The archive requirement extracts an archive to “dest”. After the modifications the archive is re-created again.
Right now, gzipped cpio archives are supported for modification requirements.
Tip
The gzipped cpio archives can used to modify initrd images.
Example:
<requirement dest='/var/lib/com-ec/tmp' format='cpio' type='archive' name='/var/lib/com-ec/dest/initrd_sr-2.6.9-42.0.3.ELsmp.img'/>
A filesystem modificationset is used to perform modifications on a specific filesystem, e.g. file modifications or filesystem operations.
All modifications are done on the filesystem defined by the “device” and “filesystem” elements.
The filesystem modifciationset can use different “modifciations”.
Note
The modification is done with the filesystem mountpoint as current working directory.
Example:
<modificationset type='filesystem' name='an_unique_name'>
<device refid='a_device_reference'>
<modification type='a_valid_type'>
</modification>
<...>
</modificationset/>
A copy modification is used to copy files on a filesystem. It walks though a list of “file” definitions. A file definition for a copy modification uses a “sourcefile” and a “name” attribute.
Example:
<modification type='copy'>
<file sourcefile='path_of_the_sourcefile1' name='path_of_the_destination_file1'/>
<file sourcefile='path_of_the_sourcefile2' name='path_of_the_destination_file2'/>
<.../>
</modification>
A move modification is used to move a file in the filesystem. It walks throug the list of “file” elements.
Example:
<modification type="move">
<file name="etc/myfile" sourcefile="etc/myfile.orig"/>
</modification>
A regulary expression regexp modification is used to perform regulary expression based serach and replace operations to file. E.g. you could serach ifcfg-eth1 for a string like “IPADDR=.*” and replace this with a valid IP address lile “ IPADDR=192.168.234.234”.
Note
Per default, a backup of the modified file is made. This can be disabled with
nopackup='1'.Example:
<modification search='IPADDR=.*' nobackup='1' type='regexp' replace='IPADDR=10.0.46.47'>
<file name='cluster/cdsl/1/etc/sysconfig/network-scripts/ifcfg-bond1'/>
</modification>
A. Glossary
- Extensible Stylesheet Language
A language for expressing stylesheets written in XML. It includes the XSL formatting objects (XSL-FO) language, but refers to separate documents for the transformation language and the path language.
See Also Extensible Markup Language.
- XSL Transformation
The part of XSL for transforming XML documents into other XML documents, HTML, or text. It can be used to rearrange the content and generate new content.
See Also Extensible Markup Language, Extensible Stylesheet Language.
- XML Path Language
A language for addressing parts of an XML document. It is used to find the parts of your document to apply different styles to. All XSL processors use this component.
See Also Extensible Markup Language, Extensible Stylesheet Language, XSL Transformation.
- Extensible Markup Language
The Extensible Markup Language (XML) is a W3C-recommended general-purpose markup language that supports a wide variety of applications.
Follow @OpenSharedroot on twitter