[chef] Re: Re: Re: Re: using env attr to override a default


Chronological Thread 
  • From:
  • To:
  • Subject: [chef] Re: Re: Re: Re: using env attr to override a default
  • Date: Tue, 27 Sep 2011 18:32:10 -0700

hai, responses inline.

On Wed, 28 Sep 2011, AJ Christensen wrote:

> > [chef-repo]$ cat environments/dev.json
> > {
> >  "name": "dev",
> >  "default_attributes": {
> >    "postfix": {
> >      "mail-server": {
> >        "relayhost": "[outbound.mailhop.org],[smtp.gmail.com]:587"
> >      },
> >      "mail-client": {
> >        "relayhost": "mungbeans.dev.dorqtown.com"
> >      }
> >    }
> >  },
> >  "json_class": "Chef::Environment",
> >  "description": "Development environment (dev)",
> >  "chef_type": "environment"
> > }
> 
> This new one is bad too. The structure you want, quote unquote, is:
> 
> "default_attributes": {
>   "postfix": { "relayhost" : "mungbeans.dev.dorqtown.com" }
> }
> 
> Notice the wildly obvious exclusion of any mention of the "name" of
> your other roles, "mail-server" and "mail-client" - the names of the
> roles are irrelevant. they are *attribute holders* - you will unlikely
> ever refer to them by name apart from when doing a Search or run_list
> introspection for dual-behavior.
 
ah.. and now that i've corrected the dev env with your feedback
above, it's working, in that a client's main.cf gets the env relayhost
rather that the default one from the cookbook. yay!

> This whole pattern you're in - setting things globally - is a sure
> sign of a cfengine "expert".
 
ayep. i'm workin' on grokkin' a new config mgmt paradigm here.

> In chef, you do *not* want to be doing
> that configuration - you want to be discovering it. The relay server
> node can expose attributes to the search index, which is exposed to
> all nodes with access. You can simply query for a combination of a
> recipe + particular attribute/value.
> 
> I'd suggest using the existing Opscode cookbooks which already
> implement Search for discovery of the local relay master, by toggling
> an attribute.
> 
> https://github.com/opscode/cookbooks/blob/master/postfix/attributes/default.rb#L1
> 
> e.g.
> 
> role postfix_client defaults postfix.client_type = "client"
> role postfix_server defaults postfix.client_type = "master"
 
i just ran thru the opscode postfix cookbook from a pristine state,
and followed jtimberman's blog about "Encrypted Data Bag for Postfix
SASL Authentication". that helped turn a little light on for me, even
tho i'm getting a chef client error about smtp_sasl (i'll poke at that
later). so i skip the smtp_sasl bit, and just try to get a vanilla
postfix master and client.

my postfix master node kept converging as a client until, while using
jtimberman's "operations master" role, i added an override_attribute
to that role as "mail_type" => "master". once i did that, it worked:
it became a master. (jtimberman, is that missing from your role in this
blog post?)

now i wonder if i'm still falling back into setting things globally.
am i? is there a better, more flexible way to do this?

my mail-server role, based on jtimberman's post
(http://jtimberman.posterous.com/64227128), sans recipe[postfix::sasl_auth]:

name "mail-server"
override_attributes(
  "postfix" => {
    "mail_type" => "master",
    "relayhost" => "[outbound.mailhop.org]",
    "smtp_sasl_auth_enable" => "no",
    "smtp_sasl_passwd" => "",
    "smtp_sasl_user_name" => ""
  }
)


practice practice practice.. thanks for your help so far.

kallen




Archive powered by MHonArc 2.6.16.

§