Custom Query (894 matches)

OpenSSH >=5.7 uses ecdsa keys as default for host keys. A trivial patch (attached) is a suggestion of how this can be supported in bcfg2. I have no idea if this works as I have no bcfg2-server with the correct version to test.

Just logging for time being.

I'm getting a Packages trace back on the server and yum dependancy resolution problems with the latest rc.

bcfg2-server 1.2.0rc2 ubuntu 11.04 x86_64

bcfg2 1.2.0rc2 on CentOS 5.7 x86_64

On the server I see

Plugin Packages: unexpected structure validation failure
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/Bcfg2/Server/Core.py", line 189, in validate_structures
    plugin.validate_structures(metadata, data)
  File "/usr/lib/pymodules/python2.7/Bcfg2/Server/Plugins/Packages/__init__.py", line 115, in validate_structures
    collection=collection)
  File "/usr/lib/pymodules/python2.7/Bcfg2/Server/Plugins/Packages/__init__.py", line 149, in _build_packages
    packages, unknown = collection.complete(base)
  File "/usr/lib/pymodules/python2.7/Bcfg2/Server/Plugins/Packages/Yum.py", line 454, in complete
    return Collection.complete(self, packagelist)
  File "/usr/lib/pymodules/python2.7/Bcfg2/Server/Plugins/Packages/Collection.py", line 150, in complete
    self.virt_pkgs[pgrps] = self.get_vpkgs()
  File "/usr/lib/pymodules/python2.7/Bcfg2/Server/Plugins/Packages/Collection.py", line 109, in get_vpkgs
    s_vpkgs = source.get_vpkgs(self.metadata)
  File "/usr/lib/pymodules/python2.7/Bcfg2/Server/Plugins/Packages/Yum.py", line 751, in get_vpkgs
    rv = Source.get_vpkgs(self, metadata)
  File "/usr/lib/pymodules/python2.7/Bcfg2/Server/Plugins/Packages/Source.py", line 170, in get_vpkgs
    for key, value in list(self.provides[agrp].items()):
KeyError: 'x86_64'

There is no error on the client side.

sources.xml is comprised of several entries like this:

<Source type="yum" rawurl="http://repo/centos5.7-x86_64/RPMS.os">
    <Arch>x86_64</Arch>
    <Arch>i386</Arch>
</Source>

I'm seeing many more unmanaged/extra entries on the yum clients than I did with rc1. For instance, the package bcfg2 is part of the clients config.

# rpm -qR bcfg2
/bin/sh  
/usr/bin/python2.4  
config(bcfg2) = 1.2.0rc2-0.1
python(abi) = 2.4
python-lxml >= 0.9
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

# rpm -q --whatprovides python
python-2.4.3-44.el5_7.1.x86_64

# rpm -q --whatprovides /bin/sh
bash-3.2-32.el5.x86_64

The bcfg2 package itself shows up as managed/correct, however, both python and bash show up as unmanaged/extra.

Hi, I've created an enhanced client side driver for portage/ebuild clients. It is a major re-write of the old Portage driver. The driver supports the following enhancements:

• Allow version auto or any
• Allow building packages from source with binpkgonly = False option
• Allow for calculating dependencies of specified packages with get_deps = True option
• Reasonable verbose mode logging output
• Fallback to old driver's behaviour by default

Introduction

For a Gentoo Linux machine, dependency calculation must be done client side, and it must be done after these steps:

• portage tree is synchronised
• any overlays are synchronised
• make.conf file is up to date
• any files under /etc/portage are up to date (specifically portage.use and portage.keywords)

For the same dependency checks to be implemented server side and work successfully, the architecture would most likely need to be the same on the host server. Additionally the host server would need to have the same state as the client regarding the above mentioned points. It is certainly much easier and makes much more sense to check this client side.

To check dependencies client side, the client lies about the list of extra packages. The FindExtraPackages function has been written to check what dependencies would be required to install all specified packages from the literal configuration. If any packages remain, these will be listed as extra packages.

Auto/any version support

This has been implemented with an additional function called _CheckForUpdates. This function will check all packages specified in the literal configuration. If a package has version auto it will be checked if an update can be performed. If a package has version any and is not installed it will be checked if an update can be performed.

Update checking is done in a single pass. To do this the full list of packages is fed to emerge (specifically emerge --update --newuse --nodeps) and the output is checked to see if the corresponding package exists. If it does exist, the version it will be installed as is noted.

Dependency checking via FindExtraPackages

The function FindExtraPackages was not implemented in the previous driver. To support dependency checking, this function lies about the list of extra packages.

The function takes the list of specified packages, checks if each package is installed then checks the dependencies via emerge --emptytree of the installed packages. If any packages that are currently installed are not in the returned list, the package is marked as an extra package.

Since running this function is costly time wise, the function will only perform the calculation twice; once at start-up and once after package installation/removal. The more default mode of operation would call this function once for every modified bundle after package installation/removal.

If dependency checking is not to be performed, the parent FindExtraPackages function will be used instead. The parent function will be called at startup and once for every modified bundle.

New Install function

The original driver did not implement the install driver. The new install driver checks if the specified version is explicitly specified. If it is not, the driver substitutes the version that should be installed (checked originally via _CheckForUpdates) and calls the parent Install function.

Modifications to VerifyPackage

The package verification method has been modified to account for versions of type auto and any. In all cases the package checks (done via equery check) will be performed on the installed version if requested. For packages of version auto, the installed version will be checked, but the package may fail verification because an update is required.

Configuration file options

The following two options have been added to the configuration file under the Portage section

• binpkgonly
  • Type: Boolean
  • Default: True
  • Description: Will use emerge --binpkgonly to install packages. When false, use options specified in EMERGE_DEFAULT_OPTS
• get_deps
  • Type: Boolean
  • Default: False
  • Description: Selects if the list of extra packages will not include packages required to install those packages specified in the configuration

Suggested methods of use

This information should be added to the documentation.

The new driver when included into the bcfg2 client would ideally be run from a cron job. The cron job would be as follows:

emerge --sync
layman --sync-all  # If required
emerge --update --deep world
bcfg2 -Qb critical
bcfg2 -r all
revdep-rebuild
emerge --depclean
eclean-dist -D

In the above example, the bundle critical would contain the bcfg2.conf file, the make.conf file, portage.use and portage.keywords. Running this bundle first will make sure that these changes are applied before any checking of packages is done.

If using binpkgonly=False, it is highly recommended to adjust EMERGE_DEFAULT_OPTS to something like --usepkgonly and have pre-built packages across your site. For build hosts (machines that would be compiling these packages for distribution), options like --newuse --update --deep could be used.

It is also recommended to look into appropriate PORTAGE_ELOG values in make.conf when compiling packages.