add support for deploying chef to FreeBSD

[caleb]

Adding support for FreeBSD was fairly simple. To determine if the user was on FreeBSD or Linux, I use uname -o.

There are a couple of caveats:

• FreeBSD requires us to use /bin/sh as our shell
• FreeBSD's root user's group is wheel not root, but on OSX, Linux and FreeBSD systems, the GID is 0, so use the GID instead of the group name

There are a couple of notes that need to be made for FreeBSD hosts (namely the user you ssh in as needs to use a sh-style shell, not tcsh, and you need to install sudo), but I'm not sure if you'd want that added to the README or the wiki.

Thanks for the work on littlechef.

[caleb]

I've been working with getting a successful setup working with littlechef and FreeBSD, and this last patch is all I needed to successfully deploy some encrypted data bags and cookbooks.

Maybe it would be better to move the shell detection code to a before hook of some kind that executes on all remote-executing tasks.

[tobami]

Thanks for adding FreeBSD support!

It looks good. I suppose it is safe to use 0 as group, but I'd rather we remain explicit and use the proper name for each platform.

solo.rb already had root user detection:

root_user = "root"
    if node.get('platform') in ["freebsd", "mac_os_x"]:
        root_user = "wheel"

Why not build on that and just determine the root user and group names in a function, then asume it is correctly set from then on? There should only be two possible "entry" places, one in solo.py and one in chef.py. Before the first remote command we call this function, and the root user is properly configured. (I would avoid the extra run call in runner, because we will incur in an extra overhead for all commands)

What do you think?

[caleb]

I think you're right about the group detection and the extra call in runner.

The problem is that I need some way to determine the platform for a node, and I don't know how to do that without making a remote call.

FreeBSD doesn't have /bin/bash and this is a problem since we need to set env.shell to /bin/sh -c before we run any commands (or else we will get an error).

How would you detect the platform without performing a remote call?

In the meantime I've committed a version that doesn't hardcode the GID, but instead calls the UNIX id command to get the root user's primary group. I know this isn't what you are looking for, but it's working for me at the moment :)

[caleb]

I think I understand what's going on here. Are you supposed to set "platform" in the node JSON configuration file? Is that the best way to specify that a node is FreeBSD?

I'd be okay with that as a solution if that's the case.

[tobami]

Yes, exactly. node["platform"] is the automatic ohai attribute which the node file would have in a Chef Server environment. In our case, chef-solo obviously doesn't save back those attributes to the node file, so you would have to enter it manually. The advantage, apart from not incurring in more overhead for everyone, is that other platforms can be supported, for example windows.

The way you've done it with id -g -n root is very nice because it does not involve an extra ssh call. Only the extra run call in runner.py bothers me. If we kept relying on node["platform"] (only more consistently), we would avoid that call.

[caleb]

Cool! I'll implement it like that and add a note to the README file explaining the need to specify your platform in your node file if your platform isn't linux.

[caleb]

I have some changes that makes working with different platforms easier in the future.

As part of the deploy_chef task, I write a node config file if it doesn't exist, with some fields from Ohai included. I'm not sure if this is a good idea, but it seems like it could be useful.

[tobami]

Saving platform dependent ohai attributes is a great idea. There is no need to save all those attributes more than just once, when you deploy_chef for the first time, as they are never going to change, so that solves things.

[caleb]

I cleaned the try: block up a bit.

[tobami]

Very nice, thanks for keeping on improving the implementation!