Custom Query (894 matches)

The path to the bcfg2.conf file is hardcoded to /etc/bcfg2.conf in the following files:

bin/

GenerateHostInfo? StatReports? bcfg2 bcfg2-info bcfg2-repo-validate bcfg2-server

lib/python*/site-packages/Bcfg2/Client/

Proxy.py

In addition, the following files assume /usr/share/bcfg2/*

bin/

StatReports? bcfg2-repo-validate

While this can't really be considered a bug, it's rather inconvenient for those who keep third party software in an alternative location, such as /local/*. I'd like to request that these config paths be configurable as part of the bcfg2 installation.

As of BCFG2 0.8.1, here are observed bugs and problems from our Solaris environment:

Architecture specific packages

Solaris 10 SYSV can have multiple packages for supporting the various sparc architectures. Examples of this is SUNWcakr, SUNWcar, SUNWced, SUNWkvm. Using SUNWkvm as a test case, our Pkgmgr/* definitions for the S10 1/06 release originally looked like this:

<Package simplefile='SUNWkvmt200.v' name='SUNWkvmt200.v' version='11.10.0,REV=2005.08.10.02.13'/> <Package simplefile='SUNWkvm.v' name='SUNWkvm.v' version='11.10.0,REV=2005.08.04.12.25'/> <Package simplefile='SUNWkvm.us' name='SUNWkvm.us' version='11.10.0,REV=2005.01.20.17.25'/>

When Solaris is installed via jumpstart, one of these packages will be picked depending on processor type, and the resulting package name as seen by pkginfo is simply 'SUNWkvm'. bcfg2 will be unable to bind to this because it knows nothing about a 'SUNWkvm' package, and will want to remove or update the package. One workaround is to create a group for the processor type and add the specific package definition to it, changing the name= to name='SUNWkvm'. It's not clear whether this is something bcfg2 should deal with internally. Overall, there is probably a better way to deal with it.

Service Management Facility

SMF does not manage what are referred to as legacy_run services. These are traditional /etc/init.d scripts that have not been converted to the new XML based format. Since SMF does not manage these, bcfg2 doesn't know how to deal with them properly (sometimes it thinks it should try to enable or disable them). Here's a non-definitive list from one of our Solaris machines:

# svcs -a | grep legacy legacy_run Mar_28 lrc:/etc/rc2_d/S10lu legacy_run Mar_28 lrc:/etc/rc2_d/S20sysetup legacy_run Mar_28 lrc:/etc/rc2_d/S42ncakmod legacy_run Mar_28 lrc:/etc/rc2_d/S72autoinstall legacy_run Mar_28 lrc:/etc/rc2_d/S73cachefs_daemon legacy_run Mar_28 lrc:/etc/rc2_d/S81dodatadm_udaplt legacy_run Mar_28 lrc:/etc/rc2_d/S89PRESERVE legacy_run Mar_28 lrc:/etc/rc2_d/S94ncalogd legacy_run Mar_28 lrc:/etc/rc2_d/S98deallocate legacy_run Mar_28 lrc:/etc/rc2_d/S99audit legacy_run Mar_28 lrc:/etc/rc3_d/S16boot_server legacy_run Mar_28 lrc:/etc/rc3_d/S81volmgt

bcfg2 should at the very least ignore these for the time being, or better yet gain smarts that they should be dealt with in a more traditional /etc/rc?.d manner

Patches

Regardless of which patch mechanism you make use of, patches present a problem for bcfg2, and it doesn't support any type of patching under Solaris at the moment The basic problem is that a core SYSV package might get updated as part of a patch, such as a kernel patch. This will change the version number for that package, and that will require a manual change to the Pkgmgr/* definition for that package. Otherwise, bcfg2 will try to downgrade the package based on the install media, and that can have disasterous consequences. Then there is the issue of manual vs. automatic patching. It would be nice if bcfg2 supported a way to do both. In the case of automatic patching, it should update the Pkgmgr/* definition automatically. bcfg2 should know how to interface with the Sun supplied 'smpatch' CLI, or the third party PCA tool (​http://www.par.univie.ac.at/solaris/pca/). Ideally, bcfg2 would provide its own implementation of what PCA can do.

Unknown failure Traceback (most recent call last):

File "/usr/lib/python2.3/site-packages/Bcfg2/Client/Proxy.py", line 38, in run_me\thod

ret = apply(method, self._authinfo + method_args)

File "/usr/lib/python2.3/xmlrpclib.py", line 1032, in call

return self.send(self.name, args)

File "/usr/lib/python2.3/xmlrpclib.py", line 1319, in request

verbose=self.verbose

File "/usr/lib/python2.3/xmlrpclib.py", line 1065, in request

self.send_content(h, request_body)

File "/usr/lib/python2.3/xmlrpclib.py", line 1179, in send_content

connection.endheaders()

File "/usr/lib/python2.3/httplib.py", line 715, in endheaders

self._send_output()

File "/usr/lib/python2.3/httplib.py", line 600, in _send_output

self.send(msg)

File "/usr/lib/python2.3/httplib.py", line 567, in send

self.connect()

File "/usr/lib/python2.3/httplib.py", line 988, in connect

ssl = socket.ssl(sock, self.key_file, self.cert_file)

File "/usr/lib/python2.3/socket.py", line 73, in ssl

return _realssl(sock, keyfile, certfile)

sslerror: (8, 'EOF occurred in violation of protocol') Failed to download probes from bcfg2

The server process was running, but it wasn't logging anything for 2 days, so I can't tell you what happened on the server. All I can say is that a restart fixed the problem.