diff options
Diffstat (limited to 'doc/unsorted')
| -rw-r--r-- | doc/unsorted/contribute.txt | 81 | ||||
| -rw-r--r-- | doc/unsorted/converging_rhel5.txt | 116 | ||||
| -rw-r--r-- | doc/unsorted/developing_for_bcfg2.txt | 111 | ||||
| -rw-r--r-- | doc/unsorted/development_tips.txt | 20 | ||||
| -rw-r--r-- | doc/unsorted/development_writing_plugins.txt | 77 | ||||
| -rw-r--r-- | doc/unsorted/dynamic_groups.txt | 27 | ||||
| -rw-r--r-- | doc/unsorted/emacs_snippet.txt | 53 | ||||
| -rw-r--r-- | doc/unsorted/gentoo.txt | 177 | ||||
| -rw-r--r-- | doc/unsorted/install.txt | 47 | ||||
| -rw-r--r-- | doc/unsorted/learningpython.txt | 23 | ||||
| -rw-r--r-- | doc/unsorted/mrepo.txt | 71 | ||||
| -rw-r--r-- | doc/unsorted/nat_howto.txt | 56 | ||||
| -rw-r--r-- | doc/unsorted/writing_specification.txt | 3 |
13 files changed, 2 insertions, 860 deletions
diff --git a/doc/unsorted/contribute.txt b/doc/unsorted/contribute.txt deleted file mode 100644 index fab9d09a1..000000000 --- a/doc/unsorted/contribute.txt +++ /dev/null @@ -1,81 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-contribute: - -===================== -Contributing to Bcfg2 -===================== - -There are several ways users can contribute to the Bcfg2 project. - -* Developing code -* Testing prereleases -* Adding to the common repository -* Improving the wiki - -Development -=========== - -Send patches to the [wiki:MailingList bcfg mailing list] or create -a trac [https://trac.mcs.anl.gov/projects/bcfg2/newticket ticket] -with the patch included. In order to submit a ticket via the -trac system, you will need to create a session by clicking on the -[https://trac.mcs.anl.gov/projects/bcfg2/prefs Preferences] link and -filling out/saving changes to the form. In order to be considered for -mainline inclusion, patches need to be BSD licensed. The most convenient -way to prepare patches is by using git diff inside of a source tree -checked out of subversion. The source tree can be checked out by running:: - - git clone git://git.mcs.anl.gov/bcfg2.git - -Users wishing to contribute on a regular basis can apply for direct -subversion access. Mail the mailing list for details. - -Several resources for developers exist in the wiki: - -* [wiki:DevelopmentTips] -* [wiki:Development/WritingPlugins Writing Bcfg2 Server Plugins] -* [wiki:Architecture] -* [wiki:WritingClientToolDrivers] -* [wiki:Bcfg2SubversionHowto] -* [wiki:LearningPython] -* [wiki:UsingRcache] - -Bcfg2 is the result of a lot of work by many different people. They are -listed on the [wiki:Contributors contributors page.] - -Feel free to drop in during a [wiki:CodeSprintIdeas code sprint] if you -would like to help out with some easier problems. - -Testing Prereleases -=================== - -Before each release, several prereleases will be tagged. It is helpful -to have users test these releases (when feasible) because it is hard to -replicate the full range of potential reconfiguration situations; between -different operating systems, system management tools, and configuration -specification variation, there can be large differences between sites. - -See the [wiki:TrackingDevelopmentTrunk] page for a better view of changes -in the prereleases. - -Adding to the Common Repository -=============================== - -The Bcfg2 common repository is a set of portable examples that new -repositories can be based on. This repo has several parts. The first -is a series of group definitions that describe a wide range of client -systems. The second is a set of portable bundles that have been ported -to use these groups. This makes these bundles transparently portable -across new client architectures. - -This approach has several benefits to users - -* Configuration specification can be shared across sites where appropriate -* This common configuration specification can be reused, allowing sites to migrate to new systems that other sites have already ported the common repository to -* Setup of new systems becomes a lot easier. - -Improving the wiki -================== - -Mail the [wiki:MailingList mailing list] for an account on the wiki. diff --git a/doc/unsorted/converging_rhel5.txt b/doc/unsorted/converging_rhel5.txt deleted file mode 100644 index 9d508e5e4..000000000 --- a/doc/unsorted/converging_rhel5.txt +++ /dev/null @@ -1,116 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-converging_rhel5: - -====================================== -Converging on Verification with RHEL 5 -====================================== - -Running verification -==================== - -To get complete verification status, run:: - - bcfg2 -vqned - -Unmanaged entries -================= - -* Package (top-level) - - #. Enable the "Packages" plugin in {{{/etc/bcfg2.conf}}}, and configure the Yum repositories in {{{/var/lib/bcfg2/Packages/config.xml}}}. - #. If a package is unwanted, remove it:: - - sudo yum remove PACKAGE - - #. Otherwise, add {{{<Package name="PACKAGE" />}}} to the Base or Bundler configuration. - -* Package (dependency) - - #. Ensure the Yum repository sources configured in {{{/var/lib/bcfg2/Packages/config.xml}}} are correct. - #. Ensure the Yum repositories themselves are up-to-date with the main package and dependencies. - #. Rebuild the Packages plugin cache:: - - bcfg2-admin xcmd Packages.Refresh - -* Service - - #. Add {{{<Service name="SERVICE" />}}} to the Base or Bundler configuration. - #. Add {{{<Service name="SERVICE" status="on" type="chkconfig" />}}} to {{{/var/lib/bcfg2/Rules/services.xml}}}. - -Incorrect entries -================= - -For a "Package" ---------------- - -* Failed RPM verification - - #. Run {{{rpm -V PACKAGE}}} - #. Add configuration files (the ones with "c" next to them in the verification output) to {{{/var/lib/bcfg2/Cfg/}}}. - - * For example, {{{/etc/motd}}} to {{{/var/lib/bcfg2/Cfg/etc/motd/motd}}}. Yes, there is an extra directory level named after the file. - - #. Specify configuration files as {{{<Path name='PATH' />}}} in the Base or Bundler configuration. - #. Add directories to {{{/var/lib/bcfg2/Rules/directories.xml}}}. For example: - - .. code-block:: xml - - <Rules priority="0"> - <Directory name="/etc/cron.hourly" group="root" owner="root" perms="0700" /> - <Directory name="/etc/cron.daily" group="root" owner="root" perms="0700" /> - </Rules> - -* Multiple instances - - * Option A: Explicitly list the instances - - #. Drop the {{{<Package />}}} from the Base or Bundler configuration. - #. Add an explicit {{{<BoundPackage>}}} and {{{<Instance />}}} configuration to a new Bundle, like the following: - - .. code-block:: xml - - <Bundle name='keys'> - <!-- GPG keys --> - <BoundPackage name="gpg-pubkey" type="yum"> - <Instance simplefile="/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL" version="217521f6" release="45e8a532"/> - <Instance simplefile="/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" version="37017186" release="45761324"/> - </BoundPackage> - </Bundle> - - #. Add the bundle to the applicable groups in {{{/var/lib/bcfg2/Metadata/groups.xml}}}. - - * Option B: Disable verification of the package - - #. Add {{{pkg_checks="false"}}} to the {{{<Package />}}} tag. - -For a "Path" -------------------- - - * Unclear verification problem (no details from BCFG2) - - 1. Run {{{bcfg2 -vqI}}} to see detailed verification issues (but deny any suggested actions). - - * Permissions mismatch - - 1. Create an {{{info.xml}}} file in the same directory as the configuration file. Example: - - .. code-block:: xml - - <FileInfo> - <Group name='webserver'> - <Info owner='root' group='root' perms='0652'/> - </Group> - <Info owner='root' group='sys' perms='0651'/> - </FileInfo> - -Other troubleshooting tools -=========================== - - * Generate the physical configuration from the server side:: - - bcfg2-info buildfile /test test.example.com - - * Generate the physical configuration from the client side:: - - bcfg2 -vqn -c/root/bcfg2-physical.xml diff --git a/doc/unsorted/developing_for_bcfg2.txt b/doc/unsorted/developing_for_bcfg2.txt deleted file mode 100644 index 9d3e77bd7..000000000 --- a/doc/unsorted/developing_for_bcfg2.txt +++ /dev/null @@ -1,111 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-developing_for_bcfg2: - -==================== -Developing For Bcfg2 -==================== - -While the Bcfg2 server provides a good interface for representing -general system configurations, its plugin interface offers the -ability to implement configuration interfaces and representation -tailored to problems encountered by a particular site. This -chapter describes what plugins are good for, what they can do, and -how to implement them. - -Bcfg2 Plugins -============= - -Bcfg2 plugins are loadable python modules that the Bcfg2 server -loads at initialization time. These plugins can contribute to -the functions already offered by the Bcfg2 server or can extend -its functionality. In general, plugins will provide some portion -of the configuration for clients, with a data representation -that is tuned for a set of common tasks. Much of the core -functionality of Bcfg2 is implemented by several plugins, -however, they are not special in any way; new plugins could -easily supplant one or all of them. - -The following table describes the various functions of bcfg2 plugins. - -|| '' '''Name''' '' || '' '''Description''' '' || -|| Probes || Plugins can issue commands to collect client-side state (like hardware inventory) to include in client configurations || -|| !ConfigurationEntry List || Plugins can construct a list of per-client configuration entry lists to include in client configurations. || -|| !ConfigurationEntry contents || Literal values for configuration entries. || -|| XML-RPC functions || Plugins can export function calls that expose internal functions. || - -Writing Bcfg2 Plugins -===================== - -Bcfg2 plugins are python classes that subclass from -Bcfg2.Server.Plugin.Plugin. Several plugin-specific values must -be set in the new plugin. These values dictate how the new -plugin will behave with respect to the above four functions. -The following table describes all important member fields. - -|| '' '''Name''' '' || '' '''Description''' '' || '' '''Format''' '' || -|| __name__ || The name of the plugin || string || -|| __version__ || The plugin version (generally tied to revctl keyword expansion). || string || -|| __author__ || The plugin author. || string || -|| __rmi__ || Set of functions to be exposed as XML-RPC functions || List of function names (strings) || -|| Entries || Multidimentional dictionary of keys that point to the function [[BR]] used to bind literal contents for a given configuration entity. || Dictionary of !ConfigurationEntityType, Name keys and function reference values || -|| !BuildStructures || Function that returns a list of the structures for a given client || Member function || -|| !GetProbes || Function that returns a list of probes that a given client should execute || Member function || -|| !ReceiveData || Function that accepts the probe results for a given client. || Member function || - -Example Plugin -============== - -.. code-block:: python - - import Bcfg2.Server.Plugin - class MyPlugin(Bcfg2.Server.Plugin.Plugin): - '''An example plugin''' - # All plugins need to subclass Bcfg2.Server.Plugin.Plugin - __name__ = 'MyPlugin' - __version__ = '1' - __author__ = 'me@me.com' - __rmi__ = ['myfunction'] - # myfunction is not available remotely as MyPlugin.myfunction - - def __init__(self, core, datastore): - Bcfg2.Server.Plugin.Plugin.__init__(self, core, datastore) - self.Entries = {'Path':{'/etc/foo.conf': self.buildFoo}} - - def myfunction(self): - '''function for xmlrpc rmi call''' - #do something - return True - - def buildFoo(self, entry, metadata): - '''Bind per-client information into entry based on metadata''' - entry.attrib.update({'type':'file', 'owner':'root', 'group':'root', 'perms':'644'}) - entry.text = '''contents of foo.conf''' - -Example Connector -================= - -.. code-block:: python - - import Bcfg2.Server.Plugin - - class Foo(Bcfg2.Server.Plugin.Plugin, - Bcfg2.Server.Plugin.Connector): - '''The Foo plugin is here to illustrate a barebones connector''' - name = 'Foo' - version = '$Revision: $' - experimental = True - - def __init__(self, core, datastore): - Bcfg2.Server.Plugin.Plugin.__init__(self, core, datastore) - Bcfg2.Server.Plugin.Connector.__init__(self) - self.store = XMLFileBacked(self.data, core.fam) - - def get_additional_data(self, metadata): - mydata = {} - for data in self.store.entries['foo.xml'].data.get("foo", []): - mydata[data] = "bar" - return dict([('mydata', mydata)]) - - def get_additional_groups(self, meta): - return self.cgroups.get(meta.hostname, list()) diff --git a/doc/unsorted/development_tips.txt b/doc/unsorted/development_tips.txt deleted file mode 100644 index 29924e645..000000000 --- a/doc/unsorted/development_tips.txt +++ /dev/null @@ -1,20 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-development_tips: - -========================== -Tips for Bcfg2 Development -========================== - -#. Focus on either the client or server code. This focuses the development process down the the precise pieces of code that matter for the task at hand. - - * If you are developing a client driver, then write up a small configuration specification that includes the needed characteristics. - * If you are working on the server, run bcfg2-info and use to assess the code - -#. Use the python interpreter. One of python's most appealing features is interactive use of the interpreter. - - * If you are developing for the client-side, run "python -i /usr/sbin/bcfg2" with the appropriate bcfg2 options. This will cause the python interpreter to continue running, leaving all variables intact. This can be used to examine data state in a convenient fashion. - * If you are developing for the server side, use bcfg2-info and the "debug" option. This will leave you at a python interpreter prompt, with the server core loaded in the variable "bcore". - -#. Use pylint obsessively. It raises a lot of style-related warnings which can be ignored, but most all of the errors are legitimate. -#. If you are doing anything with Regular Expressions, [http://kodos.sourceforge.net/ Kodos - The Python Regular Expression Debugger] and [http://re-try.appspot.com/ re-try] are your friends. diff --git a/doc/unsorted/development_writing_plugins.txt b/doc/unsorted/development_writing_plugins.txt deleted file mode 100644 index cc0bd7c00..000000000 --- a/doc/unsorted/development_writing_plugins.txt +++ /dev/null @@ -1,77 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-development_writing_plugins: - -=============== -Writing Plugins -=============== - -Server Plugin Types -=================== - -Generator ---------- - -Generator plugins contribute to literal client configurations - -Structure ---------- - -Structure Plugins contribute to abstract client configurations - -Metadata --------- - -Signal metadata capabilities - -Connector ---------- - -Connector Plugins augment client metadata instances - -Probing -------- - -Signal probe capability - -Statistics ----------- - -Signal statistics handling capability - -Decision --------- - -Signal decision handling capability - -Version -------- - -Interact with various version control systems - -Writing Server Plugins -====================== - -Metadata --------- - -If you would like to define your own Metadata plugin (to extend/change functionality of the existing Metadata plugin), here are the steps to do so. We will call our new plugin `MyMetadata`. - -#. Add MyMetadata.py - - .. code-block:: python - - __revision__ = '$Revision$' - - import Bcfg2.Server.Plugins.Metadata - - class MyMetadata(Bcfg2.Server.Plugins.Metadata.Metadata): - '''This class contains data for Bcfg2 server metadata''' - __version__ = '$Id$' - __author__ = 'bcfg-dev@mcs.anl.gov' - - def __init__(self, core, datastore, watch_clients=True): - Bcfg2.Server.Plugins.Metadata.Metadata.__init__(self, core, datastore, watch_clients) - -#. Add MyMetadata to `src/lib/Server/Plugins/__init__.py` -#. Replace Metadata with MyMetadata in the plugins line of bcfg2.conf diff --git a/doc/unsorted/dynamic_groups.txt b/doc/unsorted/dynamic_groups.txt deleted file mode 100644 index 11535dc8b..000000000 --- a/doc/unsorted/dynamic_groups.txt +++ /dev/null @@ -1,27 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-dynamic_groups: - -============== -Dynamic Groups -============== - -Bcfg2 supports the use of dynamic groups. These groups are not included -in a client's profile group, but instead are derived from the results -of probes executed on the client. These dynamic groups need not already -exist in ``Metadata/groups.xml``. If a dynamic group is defined in -``Metadata/groups.xml``, clients that include this group will also get -all included groups and bundles. - -Setting up dynamic groups -========================= - -In order to define a dynamic group, setup a probe that outputs the text -based on system properties:: - - group:groupname - -This output is processed by the Bcfg2 server, and results in dynamic -group membership in groupname for the client. See the :ref:`Probes -<server-plugins-probes-index>` page for a more thorough description -of probes. diff --git a/doc/unsorted/emacs_snippet.txt b/doc/unsorted/emacs_snippet.txt deleted file mode 100644 index 471a3b244..000000000 --- a/doc/unsorted/emacs_snippet.txt +++ /dev/null @@ -1,53 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-emacs_snippet: - -======================================= -Using Bcfg2 with Emacs + YASnippet mode -======================================= - -This page describes using emacs with YASnippet mode with a set of snippets that allow quick composition of bundles and base files. More snippets are under development. - -#. Download YASnippet from http://code.google.com/p/yasnippet/ -#. Install it into your emacs load path (typically ~/.emacs.d/site-lisp) -#. Add YASnippet initialization to your .emacs (remember to re-byte-compile it if needed) - - .. code-block:: cl - - (require 'yasnippet-bundle) - - ;;; Bcfg2 snippet - - (yas/define-snippets 'sgml-mode - '( - ("<Bundle" "<Bundle name='${1:bundlename}' version='2.0'> - $0 - </Bundle>" nil) - ("<Base" "<Base> - $0 - </Base>" nil) - ("<Group" "<Group name='${1:groupname}> - $0 - </Group>" nil) - ("<Config" "<ConfigFile name='${1:filename}'/> - $0" nil) - ("<Service" "<Service name='${1:svcname}'/> - $0" nil) - ("<Package" "<Package name='${1:packagename}'/> - $0" nil) - ("<Action" "<Action name='${1:name}'/> - $0" nil) - ("<Directory" "<Directory name='${1:name}'/> - $0" nil) - ("<SymLink" "<SymLink name='${1:name}'/> - $0" nil) - ("<Permissions" "<Permissions name='${1:name}'/> - $0" nil) - ) - ) - -#. One quick M-x eval-current-buffer, and this code is enabled - -Each of these snippets activates on the opening element, ie <Bundle. After this string is entered, but before entering a space, press <TAB>, and the snippet will be expanded. The template will be inserted into the text with a set of input prompts, which default to overwrite mode and can be tabbed through. - -The code above only works for bundles and base, but will be expanded to support other xml files as well. diff --git a/doc/unsorted/gentoo.txt b/doc/unsorted/gentoo.txt deleted file mode 100644 index 4a549210d..000000000 --- a/doc/unsorted/gentoo.txt +++ /dev/null @@ -1,177 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-gentoo: - -====== -Gentoo -====== - -This document tries to lay out anything Gentoo-specific that you need -to know in order to use Bcfg2. Mostly that has to do with getting it -to cooperate with the various pieces of Portage. Services, all things -POSIX, and just about anything else that Bcfg2 does will work the same -on Gentoo as on any other distribution. Bcfg2 is new on Gentoo; please -let the list know if you find errors or omissions. - -Installing Bcfg2 -================ - -Early in July 2008, Bcfg2 was added to the Gentoo portage tree. So far -it's only keyworded for ~x86, but we hope to see it soon in the amd64 and -x64-solaris ports. If you're using Gentoo on some other architecture, it -should still work provided that you have a reasonably up to date Python; -try adding `app-admin/bcfg2 ~*` to your `/etc/portage/package.keywords` -file. - -If you don’t use portage to install Bcfg2, you’ll want to make sure you -have all the prerequisites installed first. For a server, you’ll need: - -* ``app-admin/gamin`` or ``app-admin/fam`` -* ``dev-python/lxml`` - -Clients will need at least: - -* ``app-portage/gentoolkit`` - -Package Repository -================== - -You’ll need (to make) at least one archive of binary packages. The -Portage driver calls ``emerge`` with the ``–getbinpkgonly`` option. See -:manpage:`make.conf(5)` and :manpage:`emerge(1)` manpages, specifically -the *PORTAGE_BINHOST* environment variable. - -Time Saver: quickpkg --------------------- - -If you have a standing Gentoo machine that you want to preserve or -propagate, you can generate a complete package archive based on the -present state of the system by using the quickpkg utility. For example: - -.. code-block:: sh - - for pkg in `equery -q l` ; do quickpkg "=$pkg" ; done - -…will leave you with a complete archive of all the packages on your -system in ``/usr/portage/packages/All``, which you can then move to your -ftp server. - -Cataloging Packages In Your Repository --------------------------------------- - -Once you have a set of packages, you will need to create a catalog for -them in ``/var/lib/bcfg2/Pkgmgr``. Here’s a template: - -.. code-block:: xml - - <PackageList uri='' type='portage' priority=''> - <Group name=''> - <Package name='' version=''/> - </Group> - </PackageList> - -…and a partially filled-out example, for our local Gentoo/VMware build: - -.. code-block:: xml - - <PackageList uri='ftp://filthy.uchicago.edu/200701-vmware/' type='portage' priority='0'> - <Group name='gentoo-200701-vmware'> - <Package name='app-admin/bcfg2' version='0.9.1_pre1'/> - [...] - <Package name='x11-wm/twm' version='1.0.1'/> - </Group> - </PackageList> - -The `<Group>` name (in our example, “gentoo-200701-vmware”) should -be included by any host which will draw its packages from this list. Our -collection of packages for this class of machines is at the listed URI, -and we only have one collection of packages for this batch of machines so -in our case the `priority` doesn’t really matter, we’ve set it to `0`. - -Notice that package name fields are in `CAT/TITLE` format. - -Here is a hack which will generate a list of Package lines from -a system’s database of installed packages, especially useful in -conjunction with the `quickpkg` example above: - -.. code-block:: sh - - #!/bin/bash - for pkg in `equery -q l` ; do - title=`echo $pkg | sed -e 's/\(.*\)-\([0-9].*\)/\1/'` - version=`echo $pkg | sed -e 's/\(.*\)-\([0-9].*\)/\2/'` - echo " <Package name='${title}' version='${version}'/>" - done - -Configuring Client Machines -=========================== - -Set up ``/etc/bcfg2.conf`` the way you would for any other Bcfg2 client. - -In ``make.conf``, set *PORTAGE_BINHOST* to point to the URI of -your package repository. You may want to create versions of -``make.conf`` for each package repository you maintain, with -appropriate *PORTAGE_BINHOST* URI's in each, and associated with -that package archive's group under ``Cfg`` -- for example, we have -``Cfg/etc/make.conf/make.conf.G99_gentoo-200701-vmware``. If a client -host switches groups, and the new group needs a different set of packages, -everything should just fall into place. - -Pitfalls -======== - -Package Verification Issues ---------------------------- - -As of this writing (2007/01/31), we’re aware of a number of packages -marked stable in the Gentoo x86 tree which, for one reason or another, -consistently fail to verify cleanly under `equery check`. In some cases -(pam, openldap), files which don’t (ever) exist on the system are -nonetheless recorded in the package database; in some (python, Bcfg2, -ahem), whole classes of files (.pyc and .pyo files) consistently fail -their md5sum checks; and in others, the problem appears to be a -discrepancy in the way that symlinks are created vs. the way they’re -recorded in the database. For example, in the OpenSSH package, -/usr/bin/slogin is a symlink to ./ssh, but equery expects it to point to -an unadorned ssh. An analogous situation exists with their manpages, -leading to noise like this:: - - # equery check openssh - [ Checking net-misc/openssh-4.5_p1 ] - !!! /etc/ssh/sshd_config has incorrect md5sum - !!! /usr/bin/slogin does not point to ssh - !!! /usr/share/man/man1/slogin.1.gz does not point to ssh.1.gz - !!! /etc/ssh/ssh_config has incorrect md5sum - * 62 out of 66 files good - -We can ignore the lines for ``ssh_config`` and ``sshd_config``; those will -be caught by Bcfg2 as registered config files and handled appropriately. - -Because Bcfg2 relies on the client system’s native package reporting -tool to judge the state of installed packages, complaints like these -about trivial or intractable verification failures can trigger unnecessary -bundle reinstalls when the Bcfg2 client runs. Bcfg2 will catch on after a -pass or two that the situation isn’t getting any better with repeated -package installs, stop trying, and list those packages as “bad” in -the client system’s statistics. - -Aside from filing bugs with the Gentoo package maintainers, your narrator -has been unable to come up with a good approach to this. Maybe write a -series of ``Rules`` definitions according to what the package database -thinks it should find, and/or stage copies of affected files under -``Cfg``, and associate those rules and files with the affected package in -a bundle? Annoying but possibly necessary if you want your stats file -to look good. - -/boot ------ - -Gentoo as well as some other distros recommend leaving ``/boot`` unmounted -during normal runtime. This can lead to trouble during verification and -package installation, for example when ``/boot/grub/grub.conf`` turns -up missing. The simplest way around this might just be to ensure that -``/boot`` is mounted whenever you run Bcfg2, possibly wrapping Bcfg2 -in a script for the purpose. I’ve also thought about adding *Action* -clauses to bundles for grub and our kernel packages, which would mount -``/boot`` before the bundle installs and unmount it afterward, but this -doesn’t get around the problem of those packages flunking verification. diff --git a/doc/unsorted/install.txt b/doc/unsorted/install.txt deleted file mode 100644 index 6589261ab..000000000 --- a/doc/unsorted/install.txt +++ /dev/null @@ -1,47 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-install: - -============ -Installation -============ - -Prerequisites -============= - -First, install the prerequisite libraries. See the [wiki:Prereqs] page for more information. - -Bcfg2 -===== - -Before installing, you will need to choose a machine to be the Bcfg2 server. We recommend a Linux-based machine for this purpose, but the server will work on any supported operating system. Note that you may eventually want to run a web server on this machine for reporting and serving up package repositories. - -* '''From packages:''' The easiest way to install Bcfg2 is from packages for your operating system. You can grab packages (and source packages) for various OSes from the [wiki:Download] page. Install them as you would any other packages. The server package only needs to be installed on your designated Bcfg2 server machine; the clients package needs to be installed on any machine you plan to manage by Bcfg2. -* '''From source:''' The Bcfg2 source tarball can also be grabbed from the [wiki:Download] page. After untarring the file, you can build Bcfg2 with {{{python setup.py install --prefix=/install/prefix}}} This will install both the client and server on that machine. - -Configuration -============= - -Once Bcfg2 is installed, head over to the [wiki:QuickStart] to get it configured and up-and-running. - - -OS X -==== - -Using native OS X python ------------------------- - -First, make sure you have Xcode installed as you need `packagemaker` which comes bundled in the Developer tools. - -Clone the git source:: - - git clone git://git.mcs.anl.gov/bcfg2.git - -Change to the osx directory and type make. Your new package should be located at bcfg2-'''$VERSION'''.pkg (where '''$VERSION''' is that which is specified in setup.py). - -Using macports --------------- - -Once macports is installed:: - - port install bcfg2 diff --git a/doc/unsorted/learningpython.txt b/doc/unsorted/learningpython.txt deleted file mode 100644 index 3810d3899..000000000 --- a/doc/unsorted/learningpython.txt +++ /dev/null @@ -1,23 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-learningpython: - -=============== -Learning Python -=============== - -Learning -======== - -* MIT OpenCourseWare [http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-189January--IAP--2008/CourseHome/index.htm A Gentle Introduction to Programming Using Python] which primarily uses [http://www.greenteapress.com/thinkpython/thinkpython.html Think Python: How to Think Like a Computer Scientist]. -* [http://www.diveintopython.org/ Dive into Python], available in (free) online and dead trees formats. Good introduction, but a bit dated at this point (2004). -* djbclark recommends [http://hetland.org/writing/beginning-python/ Beginning Python: From Novice to Professional] -* djbclark recommends [http://www.oreilly.com/catalog/pythoncook2/ Python Cookbook, 2nd Edition] - -References -========== - -* desai recommends "Python: Essential Reference, 3rd Edition", which is available [http://safari.samspublishing.com/0672328623 online], in [http://www.samspublishing.com/bookstore/product.asp?isbn=0768664985&rl=1 pdf], and as a [http://www.samspublishing.com/bookstore/product.asp?isbn=0672328623&rl=1 book]. -* djbclark recommends [http://www.oreilly.com/catalog/pythonpr3/ Python Pocket Reference, 3rd Edition] -* [http://www.oreilly.com/catalog/pythonian2/ Python in a Nutshell, 2nd Edition] -* lueningh recommends the official [http://docs.python.org/lib/lib.html library reference] for, say, when you just need to know what all of a string object's methods are. diff --git a/doc/unsorted/mrepo.txt b/doc/unsorted/mrepo.txt deleted file mode 100644 index 61c3fd8c8..000000000 --- a/doc/unsorted/mrepo.txt +++ /dev/null @@ -1,71 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-mrepo: - -===== -mrepo -===== - -This page describes how to setup an `mrepo`_ mirror. - -.. _mrepo: http://dag.wieers.com/home-made/mrepo/ - -mrepo builds a local APT/Yum RPM repository from local ISO files, -downloaded updates, and extra packages from 3rd party repositories. It -takes care of setting up the ISO files, downloading the RPMs, -configuring HTTP access and providing PXE/TFTP resources for remote -network installations. - -Sample mrepo configuration -========================== - -:: - - ### Configuration file for mrepo - - ### The [main] section allows to override mrepo's default settings - ### The mrepo-example.conf gives an overview of all the possible settings - [main] - srcdir = /var/mrepo/src - wwwdir = /var/www/mrepo - confdir = /etc/mrepo.conf.d - arch = x86_64 - - mailto = <youremail> - smtp-server = localhost - - hardlink = yes - shareiso = yes - - rsync-timeout = 3600 - - [centos5] - name = CentOS Server $release ($arch) - release = 5 - arch = x86_64 - metadata = yum repomd - - # ISO images - iso = centos-$release-server-$arch-DVD.iso - - #addons = rsync://mirrors.kernel.org/centos/$release/addons/$arch/RPMS - centosplus = rsync://mirrors.kernel.org/centos/$release/centosplus/$arch/RPMS - extras = rsync://mirrors.kernel.org/centos/$release/extras/$arch/RPMS - #fasttrack = rsync://mirrors.kernel.org/centos/$release/fasttrack/$arch/RPMS - os = rsync://mirrors.kernel.org/centos/$release/os/$arch/CentOS - updates = rsync://mirrors.kernel.org/centos/$release/updates/$arch/RPMS - dag = http://apt.sw.be/redhat/el$release/en/$arch/RPMS.dag - dries = http://apt.sw.be/redhat/el$release/en/$arch/RPMS.dries - rpmforge = http://apt.sw.be/redhat/el$release/en/$arch/RPMS.rpmforge - - ### Any other section is considered a definition for a distribution - ### You can put distribution sections in /etc/mrepo.conf.d/ - ### Examples can be found in the documentation at: - ### /usr/share/doc/mrepo-0.8.6/dists/. - -Run mrepo to update the repositories -==================================== - -:: - - mrepo -ug diff --git a/doc/unsorted/nat_howto.txt b/doc/unsorted/nat_howto.txt deleted file mode 100644 index 131c0c533..000000000 --- a/doc/unsorted/nat_howto.txt +++ /dev/null @@ -1,56 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-nat_howto: - -========= -NAT HOWTO -========= - -This page describes how to setup bcfg2 to properly function with a collection of clients behind NAT. It describes the issues, how the underlying portions of the bcfg2 system function, and how to correctly setup client metadata to cope with this environment. - -Issues -====== - -Bcfg2, by default, uses ip address lookup to determine the identity of a client that has connected. This process doesn't work properly in the case of NATted hosts, because all requests from these clients come from the same external address when connecting to the server. - -These client identification issues will manifest themselves in a number of ways: - -* Inability to setup discrete clients with different profiles -* Incorrect sharing of probe results across clients in the same NAT pool -* Inability to bootstrap clients properly when client data is not predefined - -Architectural Issues -==================== - -Client identification is performed as the beginning of each client/server interaction. As of 0.9.3pre3, client identification via IP address can be completely short-circuited through the use of a client uuid. Setup of client uuids requires actions of both the client and server. On the server side, the client uuid must be added to the client record in Metadata/clients.xml. This attribute allows the server to use the user part of the authentication to resolve the client's metadata. Also, either the location attribute should be set to floating, or the IP address of the NAT must be reflected in the address attribute. -Once added, the Client entry in clients.xml will look like: - -.. code-block:: xml - - <Client profile="desktop" name="test1" pingable="N" - uuid='9001ec29-1531-4b16-8198-a71bea093d0a' location='floating'/> - -Alternatively, the Client entry can be setup like: - -.. code-block:: xml - - <Client profile="desktop" name="test1" pingable="N" - uuid='9001ec29-1531-4b16-8198-a71bea093d0a' address='ip-address-of-NAT'/> - -The difference between these definitions is explained in detail on the [wiki:Authentication] page, but in short, the second form requires that the client access the server from the NAT address, while the first form allows it to connect from any address provided it uses the proper uuid. (Client identification is orthogonal to the use of per-client passwords; this can be set in addition to the attributes above.) - -Once this setup is done, each client must be configured to use the proper uuid upon any server interaction. This can be done using either the command line argument -u, or the setting "user" in the "communication" section of /etc/bcfg2.conf. - -UUID Choice -=========== - -When determining client UUIDs, one must take care to ensure that UUIDs are unique to the client. Any hardware-specific attribute, like a hash of a mac address would be sufficient. Alternatively, if a local hostname is unique, it may be used as well. - -Automated Client Bootstrapping -============================== - -Automated setup of new clients from behind NAT works by using the common password. For example:: - - /usr/sbin/bcfg2 -u ubik3 -p desktop -x <password> - -It is not possible at this time to do automated setup without setting up a pre-shared per-client key. diff --git a/doc/unsorted/writing_specification.txt b/doc/unsorted/writing_specification.txt index 5a75165bf..eced54841 100644 --- a/doc/unsorted/writing_specification.txt +++ b/doc/unsorted/writing_specification.txt @@ -166,7 +166,8 @@ The following is an annotated copy of a bundle: .. code-block:: xml - <Bundle name='ssh' version='2.0'> + <Bundle revision='$Revision: 2668 $' name='ssh' version='2.0' + origin='https://svn.mcs.anl.gov/repos/bcfg/trunk/repository/Bundler/ssh.xml'> <Path name='/etc/ssh/ssh_host_dsa_key'/> <Path name='/etc/ssh/ssh_host_rsa_key'/> <Path name='/etc/ssh/ssh_host_dsa_key.pub'/> |