Custom Query (894 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (58 - 60 of 894)

Ticket Owner Reporter Resolution Summary
#39 desai [email protected] fixed debian toolset issue
Description

Problem with the latest svn checkout 1814 on my debian GNU linux

Traceback (most recent call last):

File "/usr/sbin/bcfg2", line 401, in ?

File "/usr/sbin/bcfg2", line 389, in run

try:

File "/usr/lib/python2.3/site-packages/Bcfg2/Client/Toolset.py", line 173, in GenerateStats?

stats.set('state', 'clean')

File "etree.pyx", line 419, in etree._Element.set File "etree.pyx", line 756, in etree._Attrib.setitem

AttributeError?: 'NoneType?' object has no attribute 'encode'

#40 desai [email protected] fixed Path to bcfg2.conf file hardcoded in various places
Description

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.

#41 desai [email protected] fixed BCFG2 on Solaris
Description

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.

Note: See TracQuery for help on using queries.