[chef] Re: RE: Re: Re: Re: Re: Failed uploading transformed data to the Chef 12 server


Chronological Thread 
  • From: Daniel DeLeo < >
  • To:
  • Subject: [chef] Re: RE: Re: Re: Re: Re: Failed uploading transformed data to the Chef 12 server
  • Date: Thu, 4 Dec 2014 11:29:52 -0800



On Thursday, December 4, 2014 at 10:52 AM, Nico Kadel-Garcia wrote:

> In the RHEL based world, It would be really helpful if the “chef-server” 
> RPM’s included ‘%ghost’ entries in the .spec file for the /var/opt/opscode, 
> and for ‘/var/opt/chef-server’ on older chef releases. This would allow 
> “rpm –ql chef-server’ to at least indicate that those directories are 
> relevant.
>  
> I once had one heck of a time re-intallinag a chef server due to not 
> knowing about these, and wound up having to replace it with an entirely new 
> host.
>  
> Nico Kadel-Garcia


Does that make it impossible to uninstall and re-install without destroying 
the database? The first thing I found on google is this: 
http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html ;
but it doesn’t explain how upgrades are handled either (I know that in some 
ways—particularly with what scripts are executed--rpm treats upgrades as an 
uninstall of the old and install of the new. Would this stuff get nuked on 
upgrades?

FWIW, we provide a `chef-server-ctl implode` command that nukes everything, 
but allows you to decide whether or not to do it independent of whatever 
logic the package manager hard-codes. I’m personally a bit wary of delegating 
too much control to the package manager, based on bad experiences people have 
with packaging systems automatically starting services with default 
configurations as part of the post-install process.

--  
Daniel DeLeo




Archive powered by MHonArc 2.6.16.

§