[chef] Re: chef support on freebsd is subpar


Chronological Thread 
  • 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.

§