| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | | |
ACLs on directories
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This is a forward-port of 49362b6d633a7784f77650d5218d0e629d50e4fb
|
| | | |
|
| |\ \
| | | |
| | | | |
Essential package list cache is not cleared when Packages is refreshed
|
| | | | |
|
| | |/
| |/| |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Fix another place where a unicode XML string with an encoding
declaration may be read. Cf. 0f8d403d1a86cfbfe8222662dc445e16e8f7eff9
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is just a workaround to avoid a traceback; the real fix will
involve making the POSIX tool properly handle ACLs with no user/group
given, which refer to the current user/group of the file they apply
to.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I noticed that, at least on Python 2.4, memory for threads doesn't
get freed until the threads are joined. This patch causes the
collector to periodically go through and reap those threads.
Tested in production for ~1 month, no reported issues.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Added ability to specify initial content for a file that doesn't
exist, to avoid a messy situation where you'd have to probe for file
existence and either use a Path type="file" or Path type="augeas"
depending, and run Bcfg2 twice.
* All commands in an Augeas path are run if *any* of them fail to
verify. Previously, only commands that hadn't been run would be
installed, but that had issues, particularly with the Clear command,
which could pass verification but then be required during the
installation phase anyway.
* Miscellaneous bug fixes.
|
|\ \ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The full reparse turns out to be unnecessary with one change to
the server options, and plays havoc with ordering of django components
and overriding values in bcfg2-web.conf
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There is a little bit of code in the reporting web interface that
uses raw SQL rather than the django ORM. This bypassed the database
router functionality (since there is no model to bind to). Django
supports keeping track of multiple connections in the raw SQL interface,
so this commit does the refactoring necessary to support the multiple
databases.
|
| | | | |
|
| | | | |
|
|/ / / |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This matters during the test suite:
======================================================================
ERROR: Failure: AttributeError ('Namespace' object has no attribute
'reporting_db_engine')
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/nose/loader.py", line 364, in
loadTestsFromName
addr.filename, addr.module)
File "/usr/lib/python2.6/site-packages/nose/importer.py", line 39, in
importFromPath
return self.importFromDir(dir_path, fqname)
File "/usr/lib/python2.6/site-packages/nose/importer.py", line 84, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File
"/d/en/fennm-0/bcfg2-dbrouter/bcfg2-dbrouter.git/testsuite/Testtools/__init__.py",
line 14, in <module>
from common import *
File
"/d/en/fennm-0/bcfg2-dbrouter/bcfg2-dbrouter.git/testsuite/common.py",
line 62, in <module>
Bcfg2.DBSettings.finalize_django_config()
File
"/d/en/fennm-0/bcfg2-dbrouter/bcfg2-dbrouter.git/src/lib/Bcfg2/DBSettings.py",
line 99, in finalize_django_config
if opts.reporting_db_engine is not None:
AttributeError: 'Namespace' object has no attribute
'reporting_db_engine'
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit implements a Django database router which routes each
Django application to a database whose name matches a key in the database
dict, falling back to the default database if no matching key is found.
This support is plumbed through to the config file via
database.reporting_* database connection config options. These options
mirror ones available for the default database config. If
database.reporting_engine is not specified in the config, then the
configuration falls back to the traditional single-database way of doing
things with the database router becoming a no-op.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
_set_defaults_from_config must be called before _parse_config_options
This is due to a tricky interaction between the two methods:
(1) _set_defaults_from_config does what its name implies, it updates
the "default" property of each Option based on the value that exists
in the config.
(2) _parse_config_options will look at each option and set it to the
default value that is _currently_ defined. If the option does not
exist in the namespace, it will be added. The method carefully
avoids overwriting the value of an option that is already defined in
the namespace.
Thus, if _set_defaults_from_config has not been called yet when
_parse_config_options is called, all config file options will get set
to their hardcoded defaults. This process defines the options in the
namespace and _parse_config_options will never look at them again.
|
| | |
| | |
| | |
| | | |
This is to make the method name more in line with what it does
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
This ensures that /etc/bcfg2-web.conf gets read, even if the
--web-config for [reporting].config options are not given
|
| | |
| | |
| | |
| | |
| | | |
Some bits of Django appear to query the options directly from the
module, even if django.conf.settings.configure() has been called
|
| | |
| | |
| | |
| | | |
This also fixes some extraneous calls in the option parsing loop.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Older clients used to depend on this because there was no backported
python-ssl module available for various platforms. All supported
platforms now appear to either a) have the backported module or b) have
a recent enough version of python to use the builtin ssl module.
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|