[chef] Re: Re: Re: Re: New user feedback and questions

[Joshua Timberman < >]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Tim!

On Sep 8, 2009, at 3:55 PM, Tim Uckun wrote:

> The chef server install is not accurate and is highly disruptive if
> you already have rails sites.  Here are the issues I remember.
>
> It undoes your passenger.conf (in my case it added passenger.conf and
> left my mod_rails.conf). This not too bad of an issue.
> It rewrites your default.conf. In my case this was disruptive.
> It rewrites ports.conf and apache2.conf setting the user to www-data
> (in my case that was disruptive the current way to do is to use the
> $APACHE_RUN_USER env variable).
>
> A better way to muck with apache would be to drop files into the
> /etc/apache2/conf.d directory IMHO

The chef-server installation/bootstrap is meant to be done on a  
dedicated type server system, not on an existing Rails application  
server. The instructions mention pre-installation planning, where you  
pick your 'server', and all other systems are 'clients'. This would  
include existing Rails app servers. You could of course manage your  
Rails applications with Chef.

> It doesn't set the proper permissions in the /var/log/chef directory
> (should be chef, chef).

When using the RubyGems installation method and the bootstrap  
cookbook, my chef-server has:

drwxrwxr-x 2 chef chef 4.0K 2009-06-28 21:19 /var/log/chef

When using the Debian/Ubuntu package based installation:

drwxr-xr-x 2 root root 4096 2009-09-06 06:25 /var/log/chef

The Debian packages do not create or otherwise manage a Chef user  
[yet], so the ownership is root.

> I don't like the fact that the default place for cookbooks is
> /srv/chef but I am sure I can get used it. It seems to me /etc/chef or
> /var/lib/chef are more appropriate.

Here's the rationale, in a nutshell:

The /srv/chef location, as well as /etc/chef or /var/lib/chef are all  
appropriately "FHS Compliant." The idea of the /srv location is "files  
served by this system." In the case of a chef-server, the cookbooks  
and associated assets (templates, remote files/directories, roles,  
etc) are served by the chef-server. Per FHS, /etc/chef would be where  
the chef-related configuration files are located, which is what the  
directory is used for - the client, server and other config files as  
appropriate but not the configuration cookbooks for your client nodes.  
The /var/lib/chef location is appropriate for many of the file paths  
used by Chef, and this is reflected in the Debian packaging. This may  
take preference in the future.

> Speaking of which I guess I don't see the need for the runit
> dependency either but maybe I'll like it and use it for other things
> too. Same goes for couchdb (why not dbdb?)

Runit is a dependency as a cross platform way to manage services. When  
Chef was released, we didn't have init scripts, and we (Opscode)  
really like runit as a service management platform. It works very  
well, and we recommend it. That said, we do have Debian and Red Hat  
style init scripts in the distro directory of the main Chef source and  
we're working on updating the bootstrap to account for the option of  
using init scripts instead of runit.

> The client install did not put any of the executables in the path.
> They are all in /var/lib/gems... directory. Not that big of a deal but
> the documentation should reflect that.  I am going to try the apt
> repos today and see if they put the binaries in /usr/local/bin

This is one of the reasons why we recommend installing RubyGems from  
source, which is mentioned on the installation documentation. If you  
used the Debian/Ubuntu rubygems package, it does not install binaries  
in /usr/bin for "FHS Compliance" reasons. See,

http://pkg-ruby-extras.alioth.debian.org/rubygems.html

For the Debian position on RubyGems.

> I think the process of publishing cookbooks is cumbersome.  You write
> them on your machine. Check them out on the server and then push them
> to the server (do I have to restart apache?).  This process has too
> many steps. Maybe the rake install should be smarter?

This workflow isn't required, but we follow it because we always  
manage our cookbooks in a version control system. The workflow  
reflects a commonly cited best practice, where sysadmins store all  
system configuration files in a VCS/SCM.

You don't need to restart the chef-server (or apache w/ Passenger) for  
the new cookbook changes to be effective, but you do need to restart  
it if you created or updated any roles using the Ruby DSL or JSON  
roles files.

> Speaking of which the documentation is too scattered (same can be said
> of puppet BTW).  The wiki style documentation doesn't seem to lend
> itself well to these kinds of projects.  Something more linear and
> hierarchical would be better for me (I realize everybody is
> different).

Please open ticket(s) about documentation structural improvements.  
While it is a wiki that you can edit yourself if you're logged in,  
large sweeping changes should probably be reviewed before  
implementing, since the 'structure' is fairly well known at this point.

> Yesterday I got the server up and the client (in a VM) going. Today I
> am going to see if I can push a couple of cookbooks. Let's see what
> happens.


Cool! We'd love to hear about your successes with Chef. If you have  
any issues, post to the list, or ask on IRC.

Thank you for using Chef, and for the feedback!

- --
Opscode, Inc
Joshua Timberman, Senior Solutions Engineer
C: 720.878.4322 E: 

 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkqnF1AACgkQO97WSdVpzT2j3ACgiAPt4V12cA3egS+bgvA0npyx
XzYAnRWP3kKa5+kcA1ZblJdgUJSutDZH
=s5Rt
-----END PGP SIGNATURE-----