- From: Adam Jacob <
>
- To:
- Subject: [chef] Re: chef support on freebsd is subpar
- Date: Tue, 21 Sep 2010 11:05:53 -0700
Hi Sig - have you filed these as bugs?
Adam
On Tue, Sep 21, 2010 at 8:35 AM, Sig Lange
<
>
wrote:
>
Fellow Chefs,
>
>
I've encountered a few problems with chef on freebsd.
>
>
I wanted to bring some awareness to the community to gauge freebsd
>
usage with chef.
>
>
I know that freebsd is not likely as popular as other distributions
>
but if functionality for such platform
>
is included (and touted as supported) it should at least be functional.
>
>
Here is a list of issues i've encountered. Some bugs. Some
>
questionably achievable by other means.
>
But as I see it, expected behavior is wrong.
>
>
>
>
1. assumptions are made on package names in ports versus package names
>
that are built using 'make package'
>
Goal: Install apache
>
Many variations of package are supported in the provider like URL,
>
FTP, from ports using whereis, absolute port path
>
>
in my environment $PACKAGESITE is exported so pkg_add -r XXXX can
>
install a binary if available.
>
>
Apache can only be installed via a URL with a version # and
>
architecture hard coded in.
>
all fail due to the ports package differing then the package installed.
>
>
a. package "apache22"
>
Bails since the installed package name differs then the ports name.
>
installed package name: apache-2.2.11_7
>
ports package name: "apache22"
>
>
Incorrectly tries to fetch (it's a 404):
>
http:///freebsd/ports/amd64/packages-7.2-release/Latest/apache22.tbz
>
>
b. package "apache"
>
Bails since make -V PORTVERSION XXX is used to determine
>
version. This is not a name of a valid port.
>
>
>
c. package "/usr/ports/www/apache22"
>
just like 1.a, Incorrectly tries to fetch (it's a 404):
>
http:///freebsd/ports/amd64/packages-7.2-release/Latest/apache22.tbz
>
>
d.
>
package "apache22" do
>
source
>
"http://XXX/freebsd/ports/amd64/packages-7.2-release/Latest/"
>
end
>
>
I'm not sure what the right solution here to maintain a "repository"
>
Since the ports package name differs then the installed package
>
name one must manually symlink
>
the tbz to a name that is being interpreted and also is a valid
>
port name on the system.
>
>
It seems like 1.a and 1.c are closest to functional if the packaged
>
name matched what was trying to be fetched.
>
>
>
2. package version parsing is just plain wrong.
>
>
a version is detected by prefix and - so any package name with a
>
dash in it similiar to another will fail to
>
install. ie, protobuf and protobuf-c
>
>
--- recipe ---
>
>
package "protobuf"
>
>
--- chef run ---
>
>
[Tue, 21 Sep 2010 07:56:43 -0700] DEBUG: Processing package[protobuf]
>
[Tue, 21 Sep 2010 07:56:43 -0700] DEBUG: package[protobuf] using
>
Chef::Provider::Package::Freebsd
>
[Tue, 21 Sep 2010 07:56:43 -0700] DEBUG: Current version is c-0.14
>
[Tue, 21 Sep 2010 07:56:43 -0700] DEBUG: Ports candidate version is 2.1.0
>
>
--- debug ---
>
$ pkg_info |grep protobuf
>
protobuf-c-0.14 C bindings for Google's Protocol Buffers
>
py25-protobuf-2.1.0 Google protobuf Python Client Library
>
>
>
Well obviously c-0.14 is not a version for protbuf. The regular
>
expression is greedy when it should not be.
>
>
In
>
/usr/local/lib/ruby/gems/1.8/gems/chef-0.7.16/lib/chef/provider/package/freebsd.rb
>
>
Chef does this to determine candidate version
>
$ make -V PORTVERSION -C /usr/ports/devel/protobuf
>
2.1.0
>
>
And does this to determine current version
>
$ pkg_info -E protobuf\*
>
protobuf-c-0.14
>
>
>
It does not bother to parse the package properly and get the
>
package_name and assert it
>
matches before returning the version.
>
>
line ~34
>
WRONG:
>
when /^#{package_name}-(.+)/
>
>
Something like this has worked for me:
>
when /^#{package_name}-([^-]+)$/
>
>
>
3. Typos is package provider exception handling
>
Various places in chef package provider typo'd the exception name
>
space for package.
>
>
Chef::Exception::Package is used instead of Chef::Exceptions::Package
>
>
So meaningful error messages are suppressed with a unknown constant error
>
>
>
>
Hope this helps anyone attempting to use freebsd in the future.
>
>
Cheers,
>
>
~ Sig
>
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E:
Archive powered by MHonArc 2.6.16.