| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
TemplateAbuse detects templated scripts (either files that end with a
known extension, or that start with a shebang line) and executables
(based off of their permissions in info.xml) and warns about them,
since templating scripts is dicey at best, and almost always better
done by templating a config file for the script to read instead.
|
| |
|
|
|
|
|
|
|
| |
Previously, if CfgEncryptedGenerator was imported before the Cfg
object was instantiated, it would finalize the
Bcfg2.Server.Plugins.Cfg.SETUP object with a value of None, and would
be unable to access the options dict.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This mimics the behavior for "real" tools
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Plugins that use the database often act quite differently depending on
whether or not the database is enabled. If we start the server
without the database (e.g., the connection failed), then Very Strange
Things can happen.
|
| |
|
|
|
|
| |
functionality
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lxml 3.2.1 complains when you try to parse a unicode (in Python 2) or
string (in Python 3) containing an XML document with an encoding
declaration. Traceback:
ValueError: Unicode strings with encoding declaration are not
supported. Please use bytes input or XML fragments without
declaration.
This encodes the document as a string (in Python 2) or bytes (in
Python 3) to avoid the lxml error. There may be other places this
happens, too, although in most other cases we should use
lxml.etree.parse() to parse a file, or we parse strings (in Python 2)
instead of unicode objects.
|
| |
|
|
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
|
| |
|
| |
|
|\
| |
| | |
bcfg2-reports: update to use current models
|
| | |
|
|\ \
| | |
| | | |
Proxy: Catch SSL errors and retry
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The SSL library can throw an exception during the XMLRPC method call. There
is no explicit except statement for this type of exception so they get raised
up and abort the client's processing. This patch catches the exception so that
normal retry processing occurs.
Typical traceback:
Traceback (most recent call last):
File "/usr/sbin/bcfg2", line 29, in ?
sys.exit(main())
File "/usr/sbin/bcfg2", line 26, in main
return Client(setup).run()
File "/usr/lib/python2.4/site-packages/Bcfg2/Client/Client.py", line 256, in run
rawconfig = self.get_config(times=times).decode('utf-8')
File "/usr/lib/python2.4/site-packages/Bcfg2/Client/Client.py", line 225, in get_config
self.run_probes(times=times)
File "/usr/lib/python2.4/site-packages/Bcfg2/Client/Client.py", line 151, in run_probes
probes = Bcfg2.Client.XML.XML(str(self.proxy.GetProbes()))
File "/usr/lib/python2.4/site-packages/Bcfg2/Proxy.py", line 81, in __call__
return _orig_Method.__call__(self, *args)
File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__
return self.__send(self.__name, args)
File "/usr/lib64/python2.4/xmlrpclib.py", line 1383, in __request
verbose=self.__verbose
File "/usr/lib/python2.4/site-packages/Bcfg2/Proxy.py", line 331, in request
return self.parse_response(response)
File "/usr/lib64/python2.4/xmlrpclib.py", line 1255, in parse_response
return self._parse_response(file, None)
File "/usr/lib64/python2.4/xmlrpclib.py", line 1276, in _parse_response
response = file.read(1024)
File "/usr/lib64/python2.4/httplib.py", line 480, in read
s = self.fp.read(amt)
File "/usr/lib64/python2.4/socket.py", line 303, in read
data = self._sock.recv(recv_size)
File "/usr/lib64/python2.4/site-packages/M2Crypto/SSL/Connection.py", line 217, in read
return self._read_bio(size)
File "/usr/lib64/python2.4/site-packages/M2Crypto/SSL/Connection.py", line 202, in _read_bio
return m2.ssl_read(self.ssl, size, self._timeout)
M2Crypto.SSL.SSLError: (104, 'Connection reset by peer')
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
In 9eb3db84, Bcfg2.Server.Admin.Mode.__call__() was changed from
pass to raise a NotImplementedError. This causes bcfg2-admin
compare and bcfg2-admin snapshots to fail because they call
Bcfg2.Server.Admin.Mode.__call__() right away. Since that method
didn't do anything anyway, it seems expediant to just avoid the call
altogether.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit f813f86f8ac2bc7b55f4eb6a0d936f1ce4f68ba7. Premature
optimization is the root of all evil, etc.
Conflicts:
src/lib/Bcfg2/Reporting/Collector.py
|
| |
| |
| |
| |
| |
| | |
1. Use a better convention for calling the threading.Thread constructor
2. Add docstring to ReportingStoreThread.run
3. Give the storage thread variable a better name
|
|\ \
| | |
| | |
| | | |
reporting-thread-each-data-import
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This ensures consistency between the in-memory representation of
clients.xml and the representation on disk. If we don't read our
writes immediately, there's a race condition when creating a new
client: If it asserts its profile or version before the FAM event from
the clients.xml edit is processed, then the clients doesn't appear to
exist yet, and Bcfg2 complains.
|
| | | |
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When dealing with a high-latency database connection (eg. across a
WAN), the bcfg2-report-collector process can fall behind in its
import queue. The imports are very much bound by the response
latency of the database server and not processing throughput.
This patch fires off a new thread for each database interaction.
The thread itself simply falls out of scope when the interaction
is finished processing. The interaction object is still read from
the disk serially in order avoid having to create a locking mechanism
for that part of the process.
This change does potentially create greater load on the database
server, but ultimately the load is limited by rate at which the
bcfg2 server can generate work.
|
| | |
|