[chef] Re: Re: chef support on freebsd is subpar

[Sig Lange < >]

I haven't gotten to it yet.

Mostly looking to gauge usage. It seems like not many people use chef
on freebsd =/

~ Sig

On Tue, Sep 21, 2010 at 11:05 AM, Adam Jacob 
<
 >
 wrote:
> 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: 
> 
 
>