Custom Query (894 matches)


Show under each result:

Results (100 - 102 of 894)

Ticket Owner Reporter Resolution Summary
#274 desai thomas fixed Server crashes when the generators or structures line is empty in config file

I use bcfg2 with only one plugin which takes care of the generation and buildstructures parts. Problem is that the server is unable to parse the following config file snippet:

structures = MyPlugin? generators =

The error message is: Traceback (most recent call last):

File "/usr/bin/bcfg2-server", line 218, in ?


File "/usr/bin/bcfg2-server", line 81, in init

self.Core = Core(setup, setupconfigfile?)

File "/usr/lib/python2.4/site-packages/Bcfg2/Server/", line 236, in init

mod = getattr(import("Bcfg2.Server.Plugins.%s" %

ValueError?: Empty module name

If I write:

structures = MyPlugin? generators = MyPlugin?

it works just fine.

#279 desai naapuri fixed Add verbosity to bcfg2 -I questions

When running bcfg2 -I, the package installation questions should be more verbose. For example, now bcfg2 asks:

Would you like to install Package: screen? (y/N):

It could ask something like this:

Upgrade package 'screen' (1.2.3 => 1.2.4)? (y/N):

DOWNGRADE package 'screen' (1.2.4 => 1.2.3)? (y/N):

Re-install package 'screen' due to changed files? (List the files with 'debsums -as screen') (y/N):

Similarly, ConfigFile? installation questions could offer a choice to see a diff of the file.

OTOH, while these enhancements would be nice, there is the reporting system that should give this information anyway.

#280 desai naapuri fixed bcfg2 incorrectly reports "All entries correct."

Suppose that a config file belonging to a .deb package is changed, eg. /etc/screenrc. Running bcfg2 without -q notices this change and re-installs the 'screen' package. However, config files are not overwritten when re-installing packages (and they shouldn't be). So bcfg2 ends up re-installing 'screen' every time it is run, and still claiming "All entries correct." even though they are not.

The best fix I can think of for this problem (and other similar problems - I think these exist!) would be to re-run bcfg2 with -n whenever bcfg2 made choices and thought that everything was fixed. This should be done internally in bcfg2, and by default.

This will slow down the bcfg2 client, but only when there is something to fix.

Note: See TracQuery for help on using queries.