Chef support on freebsd is subpar


#1

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}-([^-]+)$/

  1. 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


#2

Hi Sig - have you filed these as bugs?

Adam

On Tue, Sep 21, 2010 at 8:35 AM, Sig Lange sig.lange@gmail.com 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.

  1. 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}-([^-]+)$/

  1. 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: adam@opscode.com


#3

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 adam@opscode.com wrote:

Hi Sig - have you filed these as bugs?

Adam

On Tue, Sep 21, 2010 at 8:35 AM, Sig Lange sig.lange@gmail.com 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.

  1. 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}-([^-]+)$/

  1. 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: adam@opscode.com


#4

On Thu, Sep 23, 2010 at 10:27 AM, Sig Lange sig.lange@gmail.com wrote:

I haven’t gotten to it yet.

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

There were a couple of us that worked on the original providers. I
don’t use FreeBSD on a daily basis and most of the work I did was for
specific proof of concepts for usage that I was familiar with. I would
imagine that we aren’t yet at a point in our culture where the reasons
people would choose FreeBSD for all of their systems have converged
with the reasons people choose to use configuration management or
strive for a devops oriented culture.

If there are bugs that are blocking you, please file them and I’ll
take a look at them.

Bryan


#5

On 24/09/2010 22:23, Bryan McLellan wrote:

On Thu, Sep 23, 2010 at 10:27 AM, Sig Lange sig.lange@gmail.com wrote:

I haven’t gotten to it yet.

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

[ snip ]

I would
imagine that we aren’t yet at a point in our culture where the reasons
people would choose FreeBSD for all of their systems have converged
with the reasons people choose to use configuration management or
strive for a devops oriented culture.

Interestingly put, I’ll bite :slight_smile:

I’m curious about the “we” in “our culture”. Just as a data point: I run
(fsdo) large-ish amount of FreeBSD hosts with configuration management
at scale, and I know others who do too. I’d consider ourselves
devops-oriented, f’sure.

As much as chef appeals to me I’m still reluctant to use it owing to
CHEF-13 [*], and despite good intentions I’ve not made much progress in
helping address that beyond baby steps in a lab environment.

But that’s my (fussy, arguably misguided) issue with Chef’s approach.
Sig, thanks for writing about the problems you’ve been having with its
actual behaviour on FreeBSD.

It’s interesting data in my ongoing, and admittedly fluffy, evaluation
of different tools available to me as a devops-shaped FreeBSD sysadmin.
We’re certainly out there :slight_smile:

Regards, jon.

[*] Here:
http://tickets.opscode.com/browse/CHEF-13
http://lists.opscode.com/sympa/arc/chef/2009-11/msg00020.html et seq
http://lists.opscode.com/sympa/arc/chef/2009-12/msg00002.html et seq


#6

On Sat, Sep 25, 2010 at 1:07 AM, jon stuart lists@zomo.co.uk wrote:

Interestingly put, I’ll bite :slight_smile:

Oooh, score one for me!

I’m curious about the “we” in “our culture”. Just as a data point: I run
(fsdo) large-ish amount of FreeBSD hosts with configuration management
at scale, and I know others who do too. I’d consider ourselves
devops-oriented, f’sure.

OS + distribution wars acknowledged; you tend to see trends in why
people choose one over another. Some are maybe more stereotypes than
others. Maybe not. Are most Gentoo users fascinated with eeking out
performance? OpenBSD users putting security first? RHEL users sleep
better at night with enterprise support? shrug

We is us. Hi there! But, being a chef list, “we” is mostly chef users
and “our culture” is that of users of chef.

As much as chef appeals to me I’m still reluctant to use it owing to
CHEF-13 [*], and despite good intentions I’ve not made much progress in
helping address that beyond baby steps in a lab environment.

We’re working on that, and it’ll happen, but there are shortcomings to
no-op. If you want chef to tell you that it would change an apache
config file, which would cause it to restart apache, that’s well
enough and will work. It probably won’t tell you that apache will fail
to start because of a typo in your configuration file though. Sure,
you could parse the config to verify correctness, but that’d be an
execute, and in noop mode that wouldn’t actually run, chef would only
tell you that it would run. It would work most of the time if you kept
everything pretty simple and stayed away from execute and other
resources where you’re modifying the state of the system directly in a
way that chef can’t track. If a system is in state X, and running
resource A requires that it be in state Y, so you run resource B to
move the system from state X to state Y, will noop mode be able to
follow this state change and tell you that both A and B would occur?

Chef is a systems integration framework, which allows the system to
dynamically changed based on external information. Noop might do
nothing now, but in thirty seconds it might generate a completely
different list of nodes to add to the load balancer configuration
because you’re building search-based infrastructure. Maybe you’re
hotadding physical resources to virtualized guests or spinning up EC2
instances based on queue depth. Perhaps you’re using Science to
determine the current tuning for your application server based on
various performance metrics.

It’s awesome to find security in knowing what chef would do through
noop, but it can be dangerous to take too much solace in it.

It’s interesting data in my ongoing, and admittedly fluffy, evaluation
of different tools available to me as a devops-shaped FreeBSD sysadmin.
We’re certainly out there :slight_smile:

So glad!

Bryan


#7

Gents & Ladies,

Where’s the OSS love? I’m an avid user of *nix gentoo, openBSD, and FreeBSD
are my choice OSes. I love open source and have always taken to heart the
mentality I often see preached…

If it’s broken and it’s opensource it’s your obligation not to just
complain, but to take responsibility as a devops member of a community of
users and developers to contribute criticism, tickets (:P), and better code
to the project.

that said, Sig Lane, I agree with what you said, there are certain operating
systems that are shown more love than others in regard to chef. FreeBSD
being neglect shouldn’t be anything new to ya :), I know how that goes. I
would definitely encourage you to file bugs it’s the only slow and steady
way to guarantee *bsd support gets better.

That and I’ll even make you this guarantee, I will even take some of those
tickets and supply fixes to some of the problems aforementioned as most of
my servers home are FreeBSD -current.

Happy Hacking!

–sahil

On Sat, Sep 25, 2010 at 2:02 AM, Bryan McLellan btm@loftninjas.org wrote:

On Sat, Sep 25, 2010 at 1:07 AM, jon stuart lists@zomo.co.uk wrote:

Interestingly put, I’ll bite :slight_smile:

Oooh, score one for me!

I’m curious about the “we” in “our culture”. Just as a data point: I run
(fsdo) large-ish amount of FreeBSD hosts with configuration management
at scale, and I know others who do too. I’d consider ourselves
devops-oriented, f’sure.

OS + distribution wars acknowledged; you tend to see trends in why
people choose one over another. Some are maybe more stereotypes than
others. Maybe not. Are most Gentoo users fascinated with eeking out
performance? OpenBSD users putting security first? RHEL users sleep
better at night with enterprise support? shrug

We is us. Hi there! But, being a chef list, “we” is mostly chef users
and “our culture” is that of users of chef.

As much as chef appeals to me I’m still reluctant to use it owing to
CHEF-13 [*], and despite good intentions I’ve not made much progress in
helping address that beyond baby steps in a lab environment.

We’re working on that, and it’ll happen, but there are shortcomings to
no-op. If you want chef to tell you that it would change an apache
config file, which would cause it to restart apache, that’s well
enough and will work. It probably won’t tell you that apache will fail
to start because of a typo in your configuration file though. Sure,
you could parse the config to verify correctness, but that’d be an
execute, and in noop mode that wouldn’t actually run, chef would only
tell you that it would run. It would work most of the time if you kept
everything pretty simple and stayed away from execute and other
resources where you’re modifying the state of the system directly in a
way that chef can’t track. If a system is in state X, and running
resource A requires that it be in state Y, so you run resource B to
move the system from state X to state Y, will noop mode be able to
follow this state change and tell you that both A and B would occur?

Chef is a systems integration framework, which allows the system to
dynamically changed based on external information. Noop might do
nothing now, but in thirty seconds it might generate a completely
different list of nodes to add to the load balancer configuration
because you’re building search-based infrastructure. Maybe you’re
hotadding physical resources to virtualized guests or spinning up EC2
instances based on queue depth. Perhaps you’re using Science to
determine the current tuning for your application server based on
various performance metrics.

It’s awesome to find security in knowing what chef would do through
noop, but it can be dangerous to take too much solace in it.

It’s interesting data in my ongoing, and admittedly fluffy, evaluation
of different tools available to me as a devops-shaped FreeBSD sysadmin.
We’re certainly out there :slight_smile:

So glad!

Bryan


#8

As much as chef appeals to me I’m still reluctant to use it owing to
CHEF-13 [*], and despite good intentions I’ve not made much progress in
helping address that beyond baby steps in a lab environment.

Stage. Your. Changes.

You never know for sure until you run it.


#9

On 25/09/2010 10:02, Bryan McLellan wrote:

On Sat, Sep 25, 2010 at 1:07 AM, jon stuart lists@zomo.co.uk wrote:

I’m curious about the “we” in “our culture”. Just as a data point: I run
(fsdo) large-ish amount of FreeBSD hosts with configuration management
at scale, and I know others who do too. I’d consider ourselves
devops-oriented, f’sure.

OS + distribution wars acknowledged; you tend to see trends in why
people choose one over another. Some are maybe more stereotypes than
others. Maybe not. Are most Gentoo users fascinated with eeking out
performance? OpenBSD users putting security first? RHEL users sleep
better at night with enterprise support? shrug

I see your point. I’d not encountered this perception about FreeBSD and
configuration management before, it surprised me.

We is us. Hi there! But, being a chef list, “we” is mostly chef users
and “our culture” is that of users of chef.

Thanks for having me as an interested lurker.

As much as chef appeals to me I’m still reluctant to use it owing to
CHEF-13 [*], and despite good intentions I’ve not made much progress in
helping address that beyond baby steps in a lab environment.

We’re working on that, and it’ll happen, but there are shortcomings to
no-op. If you want chef to tell you that it would change an apache
config file, which would cause it to restart apache, that’s well
enough and will work. It probably won’t tell you that apache will fail
to start because of a typo in your configuration file though. Sure,
you could parse the config to verify correctness, but that’d be an
execute, and in noop mode that wouldn’t actually run, chef would only
tell you that it would run. It would work most of the time if you kept
everything pretty simple and stayed away from execute and other
resources where you’re modifying the state of the system directly in a
way that chef can’t track. If a system is in state X, and running
resource A requires that it be in state Y, so you run resource B to
move the system from state X to state Y, will noop mode be able to
follow this state change and tell you that both A and B would occur?

Chef is a systems integration framework, which allows the system to
dynamically changed based on external information. Noop might do
nothing now, but in thirty seconds it might generate a completely
different list of nodes to add to the load balancer configuration
because you’re building search-based infrastructure. Maybe you’re
hotadding physical resources to virtualized guests or spinning up EC2
instances based on queue depth. Perhaps you’re using Science to
determine the current tuning for your application server based on
various performance metrics.

Thanks for taking the time to illustrate this. Good to hear some manner
of noop is on the cards.

It’s awesome to find security in knowing what chef would do through
noop, but it can be dangerous to take too much solace in it.

Indeed. Personally I’m happy to take the risk that noop will necessarily
be inperfect to gain some visibility of what an automated tool might do
to systems before it actually does it.

Anyways, I conflated the FreeBSD thing with CHEF-13. Sorry about that!

Regards, jon.


#10

On 25/09/2010 19:40, Andrew Shafer wrote:

As much as chef appeals to me I’m still reluctant to use it owing to
CHEF-13 [*], and despite good intentions I’ve not made much progress in
helping address that beyond baby steps in a lab environment.

Stage. Your. Changes.

Yes, I do. Workflow has changes bubble up from scratch / test /
integration through to stage envs that are as similar to production as
possible. I aim to catch issues during this process, of course.

However, and you can call me a misguided wuss, I still like to check a
(perhaps imperfect) dry run on production envs before pulling the trigger.

Regards, jon.


#11

Bryan,

The thread unraveled as I would have expected…Good to see some
backing on the freebsd front.

I’ve managed to work around almost all the issues one way or another,
So ithere are no blockers. However, they are less then ideal fixes as
work arounds often are.

I’ve created [package version parsing on freebsd is wrong] which
contains a comment with a hot fix (Sorry, wiki munges text)
http://tickets.opscode.com/browse/CHEF-1711

Unfortunately I don’t have the time to test on a newer version of
chef. When I get more cycles i’ll dig into the other issues more and
attempt to explain them. I don’t believe there is a good solution to
#1. I still opened a ticket for it to hopefully capture the problem
for a potential solution…
http://tickets.opscode.com/browse/CHEF-1712

#3 appears to be fixed already in github;
http://github.com/opscode/chef/blob/master/chef/lib/chef/provider/package/freebsd.rb

Cheers,

~ Sig

On Fri, Sep 24, 2010 at 2:23 PM, Bryan McLellan btm@loftninjas.org wrote:

On Thu, Sep 23, 2010 at 10:27 AM, Sig Lange sig.lange@gmail.com wrote:

I haven’t gotten to it yet.

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

There were a couple of us that worked on the original providers. I
don’t use FreeBSD on a daily basis and most of the work I did was for
specific proof of concepts for usage that I was familiar with. I would
imagine that we aren’t yet at a point in our culture where the reasons
people would choose FreeBSD for all of their systems have converged
with the reasons people choose to use configuration management or
strive for a devops oriented culture.

If there are bugs that are blocking you, please file them and I’ll
take a look at them.

Bryan