stucky101
activity item
Nov 05
Question Edited
hosts file for oracle rac nodes

Fellow chefs
Total newbie here trying to make his way through the kitchen :). Starting with a simple hosts file cookbook in order to learn. My issue is I have a lot of oracle rac nodes that require that all nodes in a given cluster have 3 hosts entries per node. Public, public virtual and private interconnect. So a typical hostsfile on a 2-node rac cluster would look like:

127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
1.2.3.4  rac1.domain.com  rac1  #bond0 pub
1.2.3.5  rac1v.domain.com  rac1v  #bond0 pub floating virtual
192.168.0.1  rac1p.domain.com  rac1p  #bond1 private
1.2.3.6  rac2.domain.com  rac2  #bond0 pub
1.2.3.7  rac2v.domain.com  rac2v  #bond0 floating virtual
192.168.0.2  rac2p.domain.com  rac2p  #bond1 private

First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address.

So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following:

Attributes :

#
case platform_family
when "rhel"
  default['hosts']['hosts_file'] = '/etc/hosts'
  default['hosts']['owner'] = 'root'
  default['hosts']['group'] = 'root'
  default['hosts']['perms'] = '644'
else
  # We don't cook for unsupported platforms.
  abort "Unsupported platform family detected....exiting"
end

Role:

#
name "devdbc01"
description "Dev RAC cluster 01"
default_attributes(
  "hosts" => {
    "rac_members" => [{ 'ip'       => '1.2.3.4',
                        'fqdn'     => 'host1.domain.com',
                        'hostname' => 'host1' },
                      { 'ip'       => '1.2.3.5',
                        'fqdn'     => 'host2.domain.com',
                        'hostname' => 'host2' }]
  }
)

Default recipe:

#
template node['hosts']['hosts_file'] do
  source "hosts.erb"
  owner node['hosts']['owner']
  group node['hosts']['group']
  mode node['hosts']['perms']
end

Template:

#
# Generated by Chef for <%= node['fqdn'] %>
# Local modifications will be overwritten.
127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
<% if node['hosts']['rac_members'] -%>
<% node['hosts']['rac_members'].each do |e| -%>
<%= e['ip'] -%>  <%= e['fqdn'] -%>  <%= e['hostname'] -%><%= "\n" -%>
<% end -%>
<% end -%>

It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions.

The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ?

Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template.

Any input is appreciated and thank you for a great product !

thx

more →
Nov 05
Question Edited
hosts file for oracle rac nodes

Fellow chefs
Total newbie here trying to make his way through the kitchen :). Starting with a simple hosts file cookbook in order to learn. My issue is I have a lot of oracle rac nodes that require that all nodes in a given cluster have 3 hosts entries per node. Public, public virtual and private interconnect. So a typical hostsfile on a 2-node rac cluster would look like:

127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
1.2.3.4  rac1.domain.com  rac1  #bond0 pub
1.2.3.5  rac1v.domain.com  rac1v  #bond0 pub floating virtual
192.168.0.1  rac1p.domain.com  rac1p  #bond1 private
1.2.3.6  rac2.domain.com  rac2  #bond0 pub
1.2.3.7  rac2v.domain.com  rac2v  #bond0 floating virtual
192.168.0.2  rac2p.domain.com  rac2p  #bond1 private

First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address.

So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following:

Attributes :

#
case platform_family
when "rhel"
  default['hosts']['hosts_file'] = '/etc/hosts'
  default['hosts']['owner'] = 'root'
  default['hosts']['group'] = 'root'
  default['hosts']['perms'] = '644'
else
  # We don't cook for unsupported platforms.
  abort "Unsupported platform family detected....exiting"
end

Role:

#
name "devdbc01"
description "Dev RAC cluster 01"
default_attributes(
  "hosts" => {
    "rac_members" => [{ 'ip'       => '1.2.3.4',
                        'fqdn'     => 'host1.domain.com',
                        'hostname' => 'host1' },
                      { 'ip'       => '1.2.3.5',
                        'fqdn'     => 'host2.domain.com',
                        'hostname' => 'host2' }]
  }
)

Default recipe:

#
template node['hosts']['hosts_file'] do
  source "hosts.erb"
  owner node['hosts']['owner']
  group node['hosts']['group']
  mode node['hosts']['perms']
end

Template:

#
# Generated by Chef for <%= node['fqdn'] %>
# Local modifications will be overwritten.
127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
<% if node['hosts']['rac_members'] -%>
<% node['hosts']['rac_members'].each do |e| -%>
<%= e['ip'] -%>  <%= e['fqdn'] -%>  <%= e['hostname'] -%><%= "\n" -%>
<% end -%>
<% end -%>

It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions.

The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ?

Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template.

Any input is appreciated and thank you for a great product !

thx

more →
Nov 05
Question Edited
hosts file for oracle rac nodes

Fellow chefs
Total newbie here trying to make his way through the kitchen :). Starting with a simple hosts file cookbook in order to learn. My issue is I have a lot of oracle rac nodes that require that all nodes in a given cluster have 3 hosts entries per node. Public, public virtual and private interconnect. So a typical hostsfile on a 2-node rac cluster would look like:

127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
1.2.3.4  rac1.domain.com  rac1  #bond0 pub
1.2.3.5  rac1v.domain.com  rac1v  #bond0 pub floating virtual
192.168.0.1  rac1p.domain.com  rac1p  #bond1 private
1.2.3.6  rac2.domain.com  rac2  #bond0 pub
1.2.3.7  rac2v.domain.com  rac2v  #bond0 floating virtual
192.168.0.2  rac2p.domain.com  rac2p  #bond1 private

First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address.

So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following:

Attributes :

#
case platform_family
when "rhel"
  default['hosts']['hosts_file'] = '/etc/hosts'
  default['hosts']['owner'] = 'root'
  default['hosts']['group'] = 'root'
  default['hosts']['perms'] = '644'
else
  # We don't cook for unsupported platforms.
  abort "Unsupported platform family detected....exiting"
end

Role:

#
name "devdbc01"
description "Dev RAC cluster 01"
default_attributes(
  "hosts" => {
    "rac_members" => [{ 'ip'       => '1.2.3.4',
                        'fqdn'     => 'host1.domain.com',
                        'hostname' => 'host1' },
                      { 'ip'       => '1.2.3.5',
                        'fqdn'     => 'host2.domain.com',
                        'hostname' => 'host2' }]
  }
)

Default recipe:

#
template node['hosts']['hosts_file'] do
  source "hosts.erb"
  owner node['hosts']['owner']
  group node['hosts']['group']
  mode node['hosts']['perms']
end

Template:

#
# Generated by Chef for <%= node['fqdn'] %>
# Local modifications will be overwritten.
127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
<% if node['hosts']['rac_members'] -%>
<% node['hosts']['rac_members'].each do |e| -%>
<%= e['ip'] -%>  <%= e['fqdn'] -%>  <%= e['hostname'] -%><%= "\n" -%>
<% end -%>
<% end -%>

It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions.

The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ?

Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template.

Any input is appreciated and thank you for a great product !

thx

more →
Nov 05
Following Question
hosts file for oracle rac nodes

Fellow chefs
Total newbie here trying to make his way through the kitchen :). Starting with a simple hosts file cookbook in order to learn. My issue is I have a lot of oracle rac nodes that require that all nodes in a given cluster have 3 hosts entries per node. Public, public virtual and private interconnect. So a typical hostsfile on a 2-node rac cluster would look like:

127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
1.2.3.4  rac1.domain.com  rac1  #bond0 pub
1.2.3.5  rac1v.domain.com  rac1v  #bond0 pub floating virtual
192.168.0.1  rac1p.domain.com  rac1p  #bond1 private
1.2.3.6  rac2.domain.com  rac2  #bond0 pub
1.2.3.7  rac2v.domain.com  rac2v  #bond0 floating virtual
192.168.0.2  rac2p.domain.com  rac2p  #bond1 private

First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address.

So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following:

Attributes :

#
case platform_family
when "rhel"
  default['hosts']['hosts_file'] = '/etc/hosts'
  default['hosts']['owner'] = 'root'
  default['hosts']['group'] = 'root'
  default['hosts']['perms'] = '644'
else
  # We don't cook for unsupported platforms.
  abort "Unsupported platform family detected....exiting"
end

Role:

#
name "devdbc01"
description "Dev RAC cluster 01"
default_attributes(
  "hosts" => {
    "rac_members" => [{ 'ip'       => '1.2.3.4',
                        'fqdn'     => 'host1.domain.com',
                        'hostname' => 'host1' },
                      { 'ip'       => '1.2.3.5',
                        'fqdn'     => 'host2.domain.com',
                        'hostname' => 'host2' }]
  }
)

Default recipe:

#
template node['hosts']['hosts_file'] do
  source "hosts.erb"
  owner node['hosts']['owner']
  group node['hosts']['group']
  mode node['hosts']['perms']
end

Template:

#
# Generated by Chef for <%= node['fqdn'] %>
# Local modifications will be overwritten.
127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
<% if node['hosts']['rac_members'] -%>
<% node['hosts']['rac_members'].each do |e| -%>
<%= e['ip'] -%>  <%= e['fqdn'] -%>  <%= e['hostname'] -%><%= "\n" -%>
<% end -%>
<% end -%>

It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions.

The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ?

Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template.

Any input is appreciated and thank you for a great product !

thx

more →
Nov 05
New Question
hosts file for oracle rac nodes

Fellow chefs
Total newbie here trying to make his way through the kitchen :). Starting with a simple hosts file cookbook in order to learn. My issue is I have a lot of oracle rac nodes that require that all nodes in a given cluster have 3 hosts entries per node. Public, public virtual and private interconnect. So a typical hostsfile on a 2-node rac cluster would look like:

127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
1.2.3.4  rac1.domain.com  rac1  #bond0 pub
1.2.3.5  rac1v.domain.com  rac1v  #bond0 pub floating virtual
192.168.0.1  rac1p.domain.com  rac1p  #bond1 private
1.2.3.6  rac2.domain.com  rac2  #bond0 pub
1.2.3.7  rac2v.domain.com  rac2v  #bond0 floating virtual
192.168.0.2  rac2p.domain.com  rac2p  #bond1 private

First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address.

So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following:

Attributes :

#
case platform_family
when "rhel"
  default['hosts']['hosts_file'] = '/etc/hosts'
  default['hosts']['owner'] = 'root'
  default['hosts']['group'] = 'root'
  default['hosts']['perms'] = '644'
else
  # We don't cook for unsupported platforms.
  abort "Unsupported platform family detected....exiting"
end

Role:

#
name "devdbc01"
description "Dev RAC cluster 01"
default_attributes(
  "hosts" => {
    "rac_members" => [{ 'ip'       => '1.2.3.4',
                        'fqdn'     => 'host1.domain.com',
                        'hostname' => 'host1' },
                      { 'ip'       => '1.2.3.5',
                        'fqdn'     => 'host2.domain.com',
                        'hostname' => 'host2' }]
  }
)

Default recipe:

#
template node['hosts']['hosts_file'] do
  source "hosts.erb"
  owner node['hosts']['owner']
  group node['hosts']['group']
  mode node['hosts']['perms']
end

Template:

#
# Generated by Chef for <%= node['fqdn'] %>
# Local modifications will be overwritten.
127.0.0.1  localhost.localdomain    localhost
::1        localhost6.localdomain6  localhost6
<% if node['hosts']['rac_members'] -%>
<% node['hosts']['rac_members'].each do |e| -%>
<%= e['ip'] -%>  <%= e['fqdn'] -%>  <%= e['hostname'] -%><%= "\n" -%>
<% end -%>
<% end -%>

It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions.

The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ?

Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template.

Any input is appreciated and thank you for a great product !

thx

more →
Jun 19
Question Edited
Grouping similar OS types once instead of multiple times

Chefs
I’m a newbie studying the ntp cookbook and have a question.
It appears the author groups similar OS types every time he needs this functionality. F.e. he does it twice in the default recipe alone :

when “redhat”,“centos”,“fedora”,“scientific” package “ntp” do

action :install

end

and

when “redhat”,“centos”,“fedora”,“scientific” # ntpstats dir doesn’t exist on RHEL/CentOS else

and then again in the cookbook attributes :

case platform when “ubuntu”,“debian” default[:ntp][:service] = “ntp” when “redhat”,“centos”,“fedora”,“scientific” default[:ntp][:service] = “ntpd”

Wouldn’t it make more sense to define this grouping once (maybe in a data bag?) and then pull it from anywhere whenever you need it ?

Any thoughts would be appreciated.

more →
Jun 19
New Question
Grouping similar OS types once instead of multiple times

Chefs
I’m a newbie studying the ntp cookbook and have a question.
It appears the author groups similar OS types every time he needs this functionality. F.e. he does it twice in the default recipe alone :

when “redhat”,“centos”,“fedora”,“scientific” package “ntp” do

action :install

end

and

when “redhat”,“centos”,“fedora”,“scientific” # ntpstats dir doesn’t exist on RHEL/CentOS else

and then again in the cookbook attributes :

case platform when “ubuntu”,“debian” default[:ntp][:service] = “ntp” when “redhat”,“centos”,“fedora”,“scientific” default[:ntp][:service] = “ntpd”

Wouldn’t it make more sense to define this grouping once (maybe in a data bag?) and then pull it from anywhere whenever you need it ?

Any thoughts would be appreciated.

more →
Jun 19
Following Question
Attributes in metadata.rb

Fellow chefs
Newbie here, both to ruby and chef. I’m currently studying the ntp cookbook and have a question.

It appears all cookbooks set attributes in metadata.rb eventhough as per documentation chef ignores those. Example from metadata.rb from the ntp cookbook:

attribute “ntp/servers”, :display_name => “NTP Servers”, :description => “Array of servers we should talk to”, :type => “array”, :default => [“0.pool.ntp.org”, “1.pool.ntp.org” ]

I did a test by removing all other places where this attribute is set. In this case chef fails since ntp servers is not defined so this confirms that chef doesn’t read these.

It looks like there is one cloudprovider named Rightscale that forces you to duplicate your attributes into metadata.rb for their dashboard. My assumption is that this is why official cookbooks have this added by default. Can anyone confirm deny that Rightscale is currently the only provider that requires this ?

thx

more →
Jun 19
New Question
Attributes in metadata.rb

Fellow chefs
Newbie here, both to ruby and chef. I’m currently studying the ntp cookbook and have a question.

It appears all cookbooks set attributes in metadata.rb eventhough as per documentation chef ignores those. Example from metadata.rb from the ntp cookbook:

attribute “ntp/servers”, :display_name => “NTP Servers”, :description => “Array of servers we should talk to”, :type => “array”, :default => [“0.pool.ntp.org”, “1.pool.ntp.org” ]

I did a test by removing all other places where this attribute is set. In this case chef fails since ntp servers is not defined so this confirms that chef doesn’t read these.

It looks like there is one cloudprovider named Rightscale that forces you to duplicate your attributes into metadata.rb for their dashboard. My assumption is that this is why official cookbooks have this added by default. Can anyone confirm deny that Rightscale is currently the only provider that requires this ?

thx

more →