diff options
-rw-r--r-- | doc/client/tools/index.txt | 11 | ||||
-rw-r--r-- | doc/client/tools/yumng.txt | 4 | ||||
-rw-r--r-- | doc/getting_started/index.txt | 5 | ||||
-rw-r--r-- | doc/getting_started/using-bcfg2-info.txt | 129 | ||||
-rw-r--r-- | doc/quickstart/ubuntu.txt | 16 | ||||
-rw-r--r-- | doc/server/configurationentries.txt | 2 | ||||
-rw-r--r-- | doc/server/plugins/generators/packages.txt | 4 | ||||
-rw-r--r-- | doc/server/plugins/generators/pkgmgr.txt | 6 | ||||
-rw-r--r-- | src/lib/Client/Tools/APT.py | 4 | ||||
-rw-r--r-- | src/lib/Client/Tools/Upstart.py | 63 | ||||
-rw-r--r-- | src/lib/Client/Tools/__init__.py | 23 | ||||
-rw-r--r-- | src/lib/SSLServer.py | 5 |
12 files changed, 252 insertions, 20 deletions
diff --git a/doc/client/tools/index.txt b/doc/client/tools/index.txt index 9d560ff6e..6ae903c50 100644 --- a/doc/client/tools/index.txt +++ b/doc/client/tools/index.txt @@ -52,8 +52,8 @@ Tool to manage services (primarily on Redhat based distros). .. note:: Start and stop are standard arguments, but the one for reload isn't consistent across services. You can specify which argument - to use with the `reload` property in Service tags. Example: - `<Service name="ftp" reload="condrestart" status="on" + to use with the `restart` property in Service tags. Example: + `<Service name="ftp" restart="condrestart" status="on" type="chkconfig">` DebInit @@ -132,6 +132,13 @@ SYSV Handles System V Packaging format that is available on Solaris. +Upstart +------- + +Upstart service support. Uses `Upstart`_ to configure services. + +.. _Upstart: http://upstart.ubuntu.com/ + Yum --- diff --git a/doc/client/tools/yumng.txt b/doc/client/tools/yumng.txt index 8e7ffa1eb..07706ad8b 100644 --- a/doc/client/tools/yumng.txt +++ b/doc/client/tools/yumng.txt @@ -433,7 +433,7 @@ Pkgmgr Configuration -------------------- Also see the general :ref:`Pkgmgr <server-plugins-generators-pkgmgr>` -and :ref:`unsorted-altsrc` pages. +and :ref:`server-plugins-structures-altsrc` pages. Package Tag (Old style) ^^^^^^^^^^^^^^^^^^^^^^^ @@ -588,7 +588,7 @@ The two utilities detailed below are provided in the tools directory of the source tarball. Also see the general :ref:`Pkgmgr <server-plugins-generators-pkgmgr>` -and :ref:`unsorted-altsrc` pages. +and :ref:`server-plugins-structures-altsrc` pages. pkgmgr_gen.py ^^^^^^^^^^^^^ diff --git a/doc/getting_started/index.txt b/doc/getting_started/index.txt index 01c264233..c3e27000b 100644 --- a/doc/getting_started/index.txt +++ b/doc/getting_started/index.txt @@ -18,6 +18,11 @@ Channel` and let us know) * `Bcfg2 from scratch on CentOS <QuickStart/CentOS>` +.. toctree:: + :maxdepth: 2 + + using-bcfg2-info + Must Reads ========== diff --git a/doc/getting_started/using-bcfg2-info.txt b/doc/getting_started/using-bcfg2-info.txt new file mode 100644 index 000000000..dc5e3ea10 --- /dev/null +++ b/doc/getting_started/using-bcfg2-info.txt @@ -0,0 +1,129 @@ +.. -*- mode: rst -*- + +.. _getting_started-using_bcfg2_info: + +================ +Using bcfg2-info +================ + +*bcfg2-info* is a tool for introspecting server functions. It is +useful for understanding how the server is interpreting your +repository. It consists of the same logic executed by the server to +process the repository and produce configuration specifications, just +without all of the network communication code. Think of *bcfg2-info* +as *bcfg2-server* on a stick. It is a useful location to do testing +and staging of new configuration rules, prior to deployment. This is +particularly useful when developing templates, or developing Bcfg2 +plugins. + +Getting Started +=============== + +First, fire up the bcfg2-info interpreter. + +.. code-block:: none + + [0:464] bcfg2-info + Loading experimental plugin(s): Packages + NOTE: Interfaces subject to change + Handled 8 events in 0.006s + Handled 4 events in 0.035s + Welcome to bcfg2-info + Type "help" for more information + > + +At this point, the server core has been loaded up, all plugins have +been loaded, and the *bcfg2-info* has both read the initial state of +the Bcfg2 repository, as well as begun monitoring it for changes. Like +*bcfg2-server*, *bcfg2-info* monitors the repository for changes, +however, unlike *bcfg2-server*, it does not process change events +automatically. File modification events can be processed by explicitly +calling the **update** command. This will process the events, +displaying the number of events processed and the amount of time taken +by this processing. If no events are available, no message will be +displayed. For example, after a change to a file in the repository: + +.. code-block:: none + + >update + Handled 1 events in 0.001s + > update + > + +This explicit update process allows you to control the update process, +as well as see the precise changes caused by repository +modifications. + +*bcfg2-info* has several builtin commands that display the state of +various internal server core state. These are most useful for +examining the state of client metadata, either for a single client, or +for clients overall. + +**clients** + displays a list of clients, along with their profile groups +**groups** + displays a list of groups, the inheritance hierarchy, profile + status, and category name, if there is one. +**showclient** + displays full metadata information for a client, including + profile group, group memberships, bundle list, and any connector + data, like Probe values or Property info. + +Debugging Configuration Rules +============================= + +In addition to the commands listed above for viewing client metadata, +there are also commands which can shed light on the configuration +generation process. Recall that configuration generation occurs in +three major steps: + +1) Resolve client metadata +2) Build list of entries for the configuration +3) Bind host-specific version of each entry + +Step *1* can be viewed with the commands presented in the previous +section. The latter two steps can be examined using the following +commands. + +**showentries** + displays a list of entries (optionally filtered by type) that + appear in a client's configuration specification + +**buildfile** + Perform the entry binding process on a single entry, displaying + its results. This command is very useful when developing + configuration file templates. + +**build** + Build the full configuration specification and write it to a + file. + +**mappings** + displays the entries handled by the plugins loaded by the server + core. This command is useful when the server reports a bind + failure for an entry. + +Debugging and Developing Bcfg2 +============================== + +*bcfg2-info* loads a full Bcfg2 server core, so it provides the ideal +environment for developing and debugging Bcfg2. Because it is hard to +automate this sort of process, we have only implemented two commands +in *bcfg2-info* to aid in the process. + +**profile** + The profile command produces python profiling information for + other *bcfg2-info* commands. This can be used to track + performance problems in configuration generation. + +**debug** + The debug command exits the *bcfg2-info* interpreter loop and + drops to a python interpreter prompt. The Bcfg2 server core is + available in this namespace as "self". Full documentation for + the server core is out of scope for this document. This + capability is most useful to call into plugin methods, often with + setup calls or the enabling of diagnostics. + + It is possible to return to the *bcfg2-info* command loop by + exiting the python interpreter with ^D. + diff --git a/doc/quickstart/ubuntu.txt b/doc/quickstart/ubuntu.txt index 226fc800f..365167ed4 100644 --- a/doc/quickstart/ubuntu.txt +++ b/doc/quickstart/ubuntu.txt @@ -144,8 +144,8 @@ Replace Pkgmgr with Packages in the plugins line of bcfg2.conf:: [components] bcfg2 = https://lucid:6789 -Create Packages layout (as per [wiki:Plugins/Packages#Exampleusage]) -in ``/var/lib/bcfg2`` +Create Packages layout (as per :ref:`packages-exampleusage`) in +``/var/lib/bcfg2`` .. code-block:: xml @@ -167,8 +167,8 @@ in ``/var/lib/bcfg2`` Due to the `Magic Groups`_, we need to modify our Metadata. Let's add an **ubuntu-lucid** group which inherits the **ubuntu** group already -present in /var/lib/bcfg2/Metadata/groups.xml. The resulting file should -look something like this +present in ``/var/lib/bcfg2/Metadata/groups.xml``. The resulting file +should look something like this .. _Magic Groups: http://trac.mcs.anl.gov/projects/bcfg2/wiki/Plugins/Packages#MagicGroups @@ -194,10 +194,10 @@ look something like this .. note:: When editing your xml files by hand, it is useful to occasionally run `bcfg2-repo-validate` to ensure that your xml validates properly. -The last thing we need is for the client to have the proper arch group -membership. For this, we will make use of the [wiki:DynamicGroups] -capabilities of the Probes plugin. Add Probes to your plugins line in -bcfg2.conf and create the Probe. +The last thing we need is for the client to have the proper +arch group membership. For this, we will make use of the +:ref:`unsorted-dynamic_groups` capabilities of the Probes plugin. Add +Probes to your plugins line in ``bcfg2.conf`` and create the Probe. .. code-block:: sh diff --git a/doc/server/configurationentries.txt b/doc/server/configurationentries.txt index 4e4516106..cedac8042 100644 --- a/doc/server/configurationentries.txt +++ b/doc/server/configurationentries.txt @@ -65,6 +65,8 @@ path. The following table describes the various types available for new | | entries | | | +-------------+----------------------+-----------------+--------------------------+ +.. _boundentries: + Bound Entries ============= diff --git a/doc/server/plugins/generators/packages.txt b/doc/server/plugins/generators/packages.txt index 7ca30cdbe..a96f3a725 100644 --- a/doc/server/plugins/generators/packages.txt +++ b/doc/server/plugins/generators/packages.txt @@ -90,6 +90,8 @@ any prerequisites that cannot be satisfied. This facility should largely remove the need to use the :ref:`Base <server-plugins-structures-base>` plugin. +.. _packages-exampleusage: + Example usage ============= @@ -201,7 +203,7 @@ Package Verification ==================== In order to do disable per-package verification Pkgmgr style, you will -need to use :ref:`BoundEntries <unsorted-boundentry>` like below +need to use :ref:`BoundEntries <boundentries>` like below .. code-block:: xml diff --git a/doc/server/plugins/generators/pkgmgr.txt b/doc/server/plugins/generators/pkgmgr.txt index a9c166446..d3342feb6 100644 --- a/doc/server/plugins/generators/pkgmgr.txt +++ b/doc/server/plugins/generators/pkgmgr.txt @@ -266,8 +266,8 @@ special Packages that are older than the ones available in the updates. </Client> </PackageList> -Simplifying Multi-Architecture Environments with :ref:`Altsrc <unsorted-altsrc>` -================================================================================ +Simplifying Multi-Architecture Environments with :ref:`Altsrc <server-plugins-structures-altsrc>` +================================================================================================= Frequently multi-architecture environments (typically x86_64) will run into problems needing to specify different architectures on different @@ -278,7 +278,7 @@ onerous, because different package targets (64bit, 32+64, etc) needed to be specified on a package by group basis. Two features have been implemented that should ease this situation considerably. -* The :ref:`Altsrc <unsorted-altsrc>` feature adds the ability to add a "bind as" directive +* The :ref:`Altsrc <server-plugins-structures-altsrc>` feature adds the ability to add a "bind as" directive to entries. For example, the following entry, in a bundle: .. code-block:: xml diff --git a/src/lib/Client/Tools/APT.py b/src/lib/Client/Tools/APT.py index 9b7b6d72d..ed686e400 100644 --- a/src/lib/Client/Tools/APT.py +++ b/src/lib/Client/Tools/APT.py @@ -64,9 +64,11 @@ class APT(Bcfg2.Client.Tools.Tool): for item in output: if "checksum mismatch" in item: files.append(item.split()[-1]) + elif "changed file" in item: + files.append(item.split()[3]) elif "can't open" in item: files.append(item.split()[5]) - elif "is not installed" in item: + elif "is not installed" in item or "missing file" in item: self.logger.error("Package %s is not fully installed" \ % entry.get('name')) else: diff --git a/src/lib/Client/Tools/Upstart.py b/src/lib/Client/Tools/Upstart.py new file mode 100644 index 000000000..a3da5b514 --- /dev/null +++ b/src/lib/Client/Tools/Upstart.py @@ -0,0 +1,63 @@ +'''Upstart support for Bcfg2''' +__revision__ = '$Revision$' + +import glob +import re + +import Bcfg2.Client.Tools +import Bcfg2.Client.XML + + +class Upstart(Bcfg2.Client.Tools.SvcTool): + '''Upstart service support for Bcfg2''' + name = 'Upstart' + __execs__ = ['/lib/init/upstart-job', + '/sbin/initctl', + '/usr/sbin/service'] + __handles__ = [('Service', 'upstart')] + __req__ = {'Service': ['name', 'status']} + svcre = re.compile("/etc/init/(?P<name>.*).conf") + + def get_svc_command(self, service, action): + return "/usr/sbin/service %s %s" % (service.get('name'), action) + + def VerifyService(self, entry, _): + '''Verify Service status for entry + + Verifying whether or not the service is enabled can be done + at the file level with upstart using the contents of + /etc/init/servicename.conf. All we need to do is make sure + the service is running when it should be. + ''' + output = self.cmd.run('/usr/sbin/service %s status' % \ + entry.get('name'))[1][0] + if output.split(' ')[1].split('/')[1].startswith('running'): + status = True + if entry.get('status') == 'off': + entry.set('current_status', 'on') + else: + status = False + if entry.get('status') == 'on': + entry.set('current_status', 'off') + + return status + + def InstallService(self, entry): + '''Install Service for entry''' + if entry.get('mode', 'default') == 'supervised': + pstatus, pout = self.cmd.run('/usr/sbin/service %s status' % \ + entry.get('name')) + if pstatus: + self.cmd.run('/usr/sbin/service %s start' % (entry.get('name'))) + return True + + def FindExtra(self): + '''Locate extra Upstart services''' + specified = [entry.get('name') for entry in self.getSupportedEntries()] + extra = [] + for name in [self.svcre.match(fname).group('name') for fname in + glob.glob("/etc/init/*.conf") \ + if self.svcre.match(fname).group('name') not in specified]: + extra.append(name) + return [Bcfg2.Client.XML.Element('Service', type='upstart', name=name) \ + for name in extra] diff --git a/src/lib/Client/Tools/__init__.py b/src/lib/Client/Tools/__init__.py index d25219579..33a0e19c1 100644 --- a/src/lib/Client/Tools/__init__.py +++ b/src/lib/Client/Tools/__init__.py @@ -1,9 +1,26 @@ '''This contains all Bcfg2 Tool modules''' __revision__ = '$Revision$' -__all__ = ["Action", "APT", "Blast", "Chkconfig", "DebInit", "Encap", "IPS", - "FreeBSDInit", "FreeBSDPackage", "launchd", "MacPorts", "Portage", - "POSIX", "RPMng", 'rpmtools', "RcUpdate", "SMF", "SYSV", "YUMng"] +__all__ = ["Action", + "APT", + "Blast", + "Chkconfig", + "DebInit", + "Encap", + "IPS", + "FreeBSDInit", + "FreeBSDPackage", + "launchd", + "MacPorts", + "Portage", + "POSIX", + "RPMng", + "rpmtools", + "RcUpdate", + "SMF", + "SYSV", + "Upstart", + "YUMng"] drivers = [item for item in __all__ if item not in ['rpmtools']] default = [item for item in drivers if item not in ['RPM', 'Yum']] diff --git a/src/lib/SSLServer.py b/src/lib/SSLServer.py index c3ecbdea5..fac332f14 100644 --- a/src/lib/SSLServer.py +++ b/src/lib/SSLServer.py @@ -203,6 +203,11 @@ class XMLRPCRequestHandler (SimpleXMLRPCServer.SimpleXMLRPCRequestHandler): size_remaining = int(self.headers["content-length"]) L = [] while size_remaining: + try: + select.select([self.rfile.fileno()], [], [], 3) + except select.error: + print "got select timeout" + raise chunk_size = min(size_remaining, max_chunk_size) L.append(self.rfile.read(chunk_size)) size_remaining -= len(L[-1]) |