From 5a046b547b053c570cc1f332fe9d637e567a8f1c Mon Sep 17 00:00:00 2001 From: Sol Jerome Date: Fri, 12 Mar 2010 20:28:16 -0600 Subject: doc: Fix broken links Signed-off-by: Sol Jerome --- doc/client/tools/yumng.txt | 4 ++-- doc/quickstart/ubuntu.txt | 16 ++++++++-------- doc/server/configurationentries.txt | 2 ++ doc/server/plugins/generators/packages.txt | 4 +++- doc/server/plugins/generators/pkgmgr.txt | 6 +++--- 5 files changed, 18 insertions(+), 14 deletions(-) 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 ` -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 ` -and :ref:`unsorted-altsrc` pages. +and :ref:`server-plugins-structures-altsrc` pages. pkgmgr_gen.py ^^^^^^^^^^^^^ 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 ` 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 ` like below +need to use :ref:`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. -Simplifying Multi-Architecture Environments with :ref:`Altsrc ` -================================================================================ +Simplifying Multi-Architecture Environments with :ref:`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 ` feature adds the ability to add a "bind as" directive +* The :ref:`Altsrc ` feature adds the ability to add a "bind as" directive to entries. For example, the following entry, in a bundle: .. code-block:: xml -- cgit v1.2.3-1-g7c22 From aab798ccfb9d4e04634181780627c94cb66a5e53 Mon Sep 17 00:00:00 2001 From: Narayan Desai Date: Sat, 13 Mar 2010 15:51:47 +0000 Subject: APT: add support for new debsums (Patch from Nicolas Dandrimont) git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@5761 ce84e21b-d406-0410-9b95-82705330c041 --- src/lib/Client/Tools/APT.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) 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: -- cgit v1.2.3-1-g7c22 From 181dc3d8e47873f728f95cbb57097852f43677e7 Mon Sep 17 00:00:00 2001 From: Narayan Desai Date: Sat, 13 Mar 2010 16:10:28 +0000 Subject: SSLServer: add in transaction timeouts git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@5762 ce84e21b-d406-0410-9b95-82705330c041 --- src/lib/SSLServer.py | 5 +++++ 1 file changed, 5 insertions(+) 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]) -- cgit v1.2.3-1-g7c22 From 7c67a0dbf082a1e71a4434898bee2c4602fed7aa Mon Sep 17 00:00:00 2001 From: Narayan Desai Date: Sat, 13 Mar 2010 18:28:36 +0000 Subject: doc: add initial bcfg2-info doc git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@5763 ce84e21b-d406-0410-9b95-82705330c041 --- doc/getting_started/using-bcfg2-info.txt | 129 +++++++++++++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 doc/getting_started/using-bcfg2-info.txt diff --git a/doc/getting_started/using-bcfg2-info.txt b/doc/getting_started/using-bcfg2-info.txt new file mode 100644 index 000000000..0aee53caf --- /dev/null +++ b/doc/getting_started/using-bcfg2-info.txt @@ -0,0 +1,129 @@ +.. -*- mode: rst -*- + +.. _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, unlink *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. + -- cgit v1.2.3-1-g7c22 From 41858f6c26343684a827e4bf2ddae3d0dd58a1eb Mon Sep 17 00:00:00 2001 From: Sol Jerome Date: Sat, 13 Mar 2010 13:10:06 -0600 Subject: Upstart: Add new upstart client tool Due to the nature of the way Upstart handles service specification, turning 'servicename' off and on can be done via a configuration file located at /etc/init/.conf. Enabling a disabled service can be done by making sure that the Upstart configuration file and the service are bundled together. Signed-off-by: Sol Jerome --- doc/client/tools/index.txt | 11 +++++- doc/getting_started/index.txt | 5 +++ doc/getting_started/using-bcfg2-info.txt | 54 +++++++++++++-------------- src/lib/Client/Tools/Upstart.py | 63 ++++++++++++++++++++++++++++++++ src/lib/Client/Tools/__init__.py | 23 ++++++++++-- 5 files changed, 124 insertions(+), 32 deletions(-) create mode 100644 src/lib/Client/Tools/Upstart.py 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: - `` 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/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 ` +.. 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 index 0aee53caf..dc5e3ea10 100644 --- a/doc/getting_started/using-bcfg2-info.txt +++ b/doc/getting_started/using-bcfg2-info.txt @@ -1,9 +1,9 @@ .. -*- mode: rst -*- -.. _using_bcfg2_info: +.. _getting_started-using_bcfg2_info: ================ -Using bcfg2-info +Using bcfg2-info ================ *bcfg2-info* is a tool for introspecting server functions. It is @@ -14,29 +14,29 @@ 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. +plugins. Getting Started =============== -First, fire up the bcfg2-info interpreter. +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 - > + [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, unlink *bcfg2-server*, it does not process change events +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 @@ -52,22 +52,22 @@ displayed. For example, after a change to a file in the repository: This explicit update process allows you to control the update process, as well as see the precise changes caused by repository -modifications. +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. +for clients overall. -**clients** +**clients** displays a list of clients, along with their profile groups -**groups** +**groups** displays a list of groups, the inheritance hierarchy, profile - status, and category name, if there is one. + 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. + data, like Probe values or Property info. Debugging Configuration Rules ============================= @@ -83,7 +83,7 @@ three major steps: Step *1* can be viewed with the commands presented in the previous section. The latter two steps can be examined using the following -commands. +commands. **showentries** displays a list of entries (optionally filtered by type) that @@ -92,16 +92,16 @@ commands. **buildfile** Perform the entry binding process on a single entry, displaying its results. This command is very useful when developing - configuration file templates. + configuration file templates. **build** Build the full configuration specification and write it to a - file. + 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. + failure for an entry. Debugging and Developing Bcfg2 ============================== @@ -109,12 +109,12 @@ 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. +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. + performance problems in configuration generation. **debug** The debug command exits the *bcfg2-info* interpreter loop and @@ -122,8 +122,8 @@ in *bcfg2-info* to aid in the process. 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. + 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. + exiting the python interpreter with ^D. 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.*).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']] -- cgit v1.2.3-1-g7c22