[chef] Re: Re: Re: Re: Deploying server under CentOS

[Albert Llop < >]

Hi all!
This is a resumed list of the problems I recall having. I wish it was more detailed.

• The nastiest one was discovering the problem with the json gem. I did uninstall json and reinstalled version 1.4.2, but still I only managed to have it all working when I uninstalled json_pure the same way. If you catch the exception on the put_rest method of lib/chef/rest.rb you'd get a weird JSON::SAFE_STATE_PROTOTYPE error. Since the exception wasn't caught, it failed silently (in my case, when creating a new view in couchdb => chef/lib/couchdb.rb line 95).
• Another thing I found very very confusing was, the init.d scripts provided with the gem don't have a reasonable $CONFIG default. For the chef-solr-indexer it's "/etc/chef/solr-indexer.rb" and for the chef-server-webui it's "/etc/chef/webui.rb". The bootstrapping cookbook only creates solr.rb and server.rb config files. I think it'd make more sense if the scripts pointed to solr.rb and server.rb. It's not so hard to debug this one, but it was very unexpected.
• Another weird default for the init.d scritps is the pidfile, in the bootstrapping process you end up with config files pointing to /srv/chef/run/, whereas the init.d scripts provided use /var/run/chef/. Not weird, but also not quite expected.
  
• On attribute definition, for example on the server_proxy recipe if you have:
  set_unless[:chef][:doc_root] = "#{languages[:ruby][:gems_dir]}/gems/chef-server-webui-#{chef[:server_version]}/public"
  It seems to generate the [:chef][:doc_root] attribute and save it. So when you update chef-server you have go to the webui and remove this attribute, or it will still point to older versions.

The first one was the worst, because I just couldn't figure it out until I dived into the code. The other ones were just a matter of time, but could help in the future if they're ironed out.
I'm not (yet) so lucky as to be working with chef full time, so apologies in advance for not being able to contribute in a better way (opening tickets or providing packages). Chef is awesome, I love it!

Thanks for the excellent work!
--
{ :name => "Albert Llop" }

On 9 July 2010 18:21, Albert Llop < " target="_blank"> > wrote:

I finally got it all working today (kind of). Will try to write the problems I've had (next week though) and see if I was doing something wrong and if I contribute with something.

Thanks for the help!

--
{ :sent_from => "iPhone" }

On 09/07/2010, at 16:53, Joshua Timberman < " target="_blank"> > wrote:

> Hello!
>
> On Jul 9, 2010, at 1:01 AM, Albert Llop wrote:
>
>> I amanged to have chef server working on CentOS up to 8.16 aswell, but 9.6 has just been completely impossible. I've managed to update it all, launch all the services, but there's no way in hell I can get to log in to the webui admin.
>>
>> Will try to get an ubuntu virtual machine working to save me some hassle in the future, and if I can't (or the boss doesn't approve, which could be :P) will try Paul's tips! Thanks a lot!!
>
>
> The RPMs currently install the Chef software as RubyGems, so you should be able to update the gems. The fun part is, the chef-server gems depend on merb 1.1, which depends on bundler, which depends on RubyGems 1.3.6+. So first, update RubyGems:
>
> sudo gem update --system
>
> (unlike debian/ubuntu, you can actually do this on CentOS :)).
>
> Then update the gems by installing them by name:
>
> sudo gem install chef chef-server-api chef-solr
>
> Finally, restart the services.
>
> for i in server solr solr-indexer
> do
>  sudo service chef-$i restart
> done
>
> I just performed this update on a centos 5 test system and it worked, in that the client was able to run, and save, to the chef server. I didn't test any cookbooks, though.
>
> --
> Opscode, Inc
> Joshua Timberman, Senior Solutions Engineer
> C: 720.334.RUBY E: " target="_blank">
>