summaryrefslogtreecommitdiffstats
path: root/doc/deployment.xml
diff options
context:
space:
mode:
authorRick Bradshow <bradshaw@mcs.anl.gov>2005-03-09 21:12:44 +0000
committerRick Bradshow <bradshaw@mcs.anl.gov>2005-03-09 21:12:44 +0000
commit2696b7c055f0c1db49199de7775d5b0540b23a9b (patch)
treee6e38d1665e1d6a0c8abe27758e6e3905b0e8372 /doc/deployment.xml
parenta005e524ee0d735b51fd386de5f60be08b7c966b (diff)
downloadbcfg2-2696b7c055f0c1db49199de7775d5b0540b23a9b.tar.gz
bcfg2-2696b7c055f0c1db49199de7775d5b0540b23a9b.tar.bz2
bcfg2-2696b7c055f0c1db49199de7775d5b0540b23a9b.zip
initial file
(Logical change 1.210) git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@890 ce84e21b-d406-0410-9b95-82705330c041
Diffstat (limited to 'doc/deployment.xml')
-rw-r--r--doc/deployment.xml193
1 files changed, 193 insertions, 0 deletions
diff --git a/doc/deployment.xml b/doc/deployment.xml
index e69de29bb..19777f619 100644
--- a/doc/deployment.xml
+++ b/doc/deployment.xml
@@ -0,0 +1,193 @@
+<chapter>
+<title>Deploying Bcfg2</title>
+ <sect1>
+ <title>Object Oriented Configs</title>
+ <para>
+One of the most powerful and useful parts about bcfg2 metadata system
+is the ability to have truely Object Oriented configs. I have found
+that this has made me understand the machines I am managing in a whole
+new light. Instead of focusing on what is installed, I now focus on
+how machines relate to each other, or what pieces of the metadata are
+similar in their configs. To illistrate this think about the following
+example machines:
+</para>
+<itemizedlist>
+<listitem><para>A users desktop machine</para></listitem>
+<listitem><para>A multiuser compute machine</para></listitem>
+<listitem><para>A users home machine. (telecommuter)</para></listitem>
+</itemizedlist>
+<para>
+These 3 machines have 3 distinct focuses for usage, but in reality
+they can have a very similar metadata, depending on how the config is
+broken up or the view that is taken of the config. If you focus first
+on where the machines are the same it will help to build the common
+metadata. below is what all 3 machines have in common:
+</para>
+<itemizedlist>
+<listitem><para>users need to have the software they need to perform
+there work. </para></listitem>
+</itemizedlist>
+<para>
+let just encode this into metadata by creating a Class called
+common-software that contains all the common software between all 3
+machines.
+</para>
+<programlisting>
+ <![CDATA[
+<Class name='common-software'>
+ <Bundle ... />
+ ....
+</Class>
+]]>
+</programlisting>
+<para>
+now we need to find where they differ:
+</para>
+<variablelist>
+<varlistentry>
+<term>Desktop machines</term>
+ <listitem>
+ <itemizedlist>
+ <listitem>
+ <para>need to have a GUI interface( Xwindows or what not )</para>
+ </listitem>
+ <listitem>
+ <para>use NIS for authentification</para>
+ </listitem>
+ <listitem>
+ <para>use Autofs to mount home directories</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+</varlistentry>
+<varlistentry>
+<term>Multiuser compute machines</term>
+ <listitem>
+ <itemizedlist>
+ <listitem>
+ <para>only accessible by SSH, No GUI interface</para>
+ </listitem>
+ <listitem>
+ <para>use NIS for authentification</para>
+ </listitem>
+ <listitem>
+ <para>use Autofs to mount home directories</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+</varlistentry>
+<varlistentry>
+<term>Home machine</term>
+ <listitem>
+ <itemizedlist>
+ <listitem>
+ <para>need to have a GUI interface( Xwindows or what not )</para>
+ </listitem>
+ <listitem>
+ <para>use static password file</para>
+ </listitem>
+ <listitem>
+ <para>use local disk for home directories</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+</varlistentry>
+</variablelist>
+<para>
+As you can see that there are common things pairwise in these configs
+that can be further exploited by the object oriented system of bcfg2
+</para>
+<programlisting>
+ <![CDATA[
+<Class name="Gui-Interface">
+ <Bundle ... />
+ ...
+</Class>
+<Class name="NIS-Autofs">
+ <Bundle ... />
+ ...
+</Class>
+]]>
+</programlisting>
+<para>
+now all that is left is to ensure that all needs are met and we find
+we need to make one more class:
+</para>
+<programlisting>
+ <![CDATA[
+<Class name="static-password-local-disk">
+ <Bundle ... />
+ ...
+</Class>
+]]>
+</programlisting>
+<para>
+Now we can mix and match these classes together to build the 3
+profiles or even build new profiles with these descrete entities.
+</para>
+<programlisting>
+ <![CDATA[
+<Profile name='desktop'>
+ <Class name='common-software'/>
+ <Class name="Gui-Interface"/>
+ <Class name="NIS-Autofs">
+</Profile>
+<Profile name='computerserver'>
+ <Class name='common-software'/>
+ <Class name="NIS-Autofs">
+</Profile>
+<Profile name='home-desktop'>
+ <Class name='common-software'/>
+ <Class name="Gui-Interface"/>
+ <Class name="static-password-local-disk">
+</Profile>
+<Profile name='bare-system'>
+ <Class name='common-software'/>
+</Profile>
+]]>
+</programlisting>
+<para>
+The free form object oriented fashion in which metadata can be
+constructed is truely a double edge sword. On one hand you can build
+up a nice list of descrete entities that can compose even the most
+complicated configs, but it also allows for the creation of entities
+that could provide monolithic solutions to each machines config. It is
+all in how one views the machines and how much they are willing to
+harness the power of the OO based metadata system.
+ </para>
+ </sect1>
+ <sect1>
+ <title>Tips & Tricks</title>
+ <para/>
+ </sect1>
+ <sect1>
+ <title>An example application of bcfg2</title>
+ <para>
+ In my computing environment there are quite a diverse set of machines
+and requirements for there operation. What this meant is that I needed
+to devise a build system for machines that would allow me to easily
+customize the software and services on the machine while still being
+able to easily manage them and keep them secure. What I came up with
+that solved this problem was that the initial install needed to be the
+smallest subset of software that all machines had in common and
+install this with whatever automated install system fit the OS. The
+goal being that the OS automated installer( ie: kickstart, or
+systemimager ) would put the initial bits on disk and take care of
+hardware stuff and then as part of the postinstall process I run bcfg2
+to insure that the rest of the software and configuration occurs based
+on the machines metadata. The overall goal was met. I could now build
+any type of machine that I needed just by using the common buildsystem
+and let bcfg2 determine what was different machine to machine.
+ </para>
+ <para>
+My current build process is centered around systemimager and
+bcfg2. I have done some small enhancements to systemimager so that
+with one floppy or cdrom any administrator can build any number of
+machine profiles automatically. This is all done with some of the new
+features that allow the encoding of the profile and image in the
+clientside command so that the back end metadata can be asserted from
+the client, which overrides the defaults specified in the metadata.xml
+file.
+ </para>
+ </sect1>
+</chapter>