[chef] Re: Re: Re: Re: Re: Managing network interfaces

[Jacobo García < >]

After taking a look on this
http://github.com/opscode/chef/blob/master/chef/lib/chef/provider/ifconfig.rb
it seems that debian/ubuntu and slackware are not supported.

In debian network configuration is all done in one file
/etc/network/interfaces so probably is not as straightforward as in
red hat to write the file.You have to parse /etc/network/interfaces
and rewrite it respecting previous interfaces. I am willing to try to
fix that and write a patch even if I'm a rusty coder as I mainly work
as a sysadmin, so do you have any advice on how to parse this file?

Thanks.



Jacobo García López de Araujo
blog: http://robotplaysguitar.com
http://workingwithrails.com/person/13395-jacobo-garc-a




On Wed, Jul 14, 2010 at 1:12 PM, Jacobo García 
<
 >
 wrote:
> Thanks for all the information, chefs.
>
>
> Jacobo García López de Araujo
> blog: http://robotplaysguitar.com
> http://workingwithrails.com/person/13395-jacobo-garc-a
>
>
>
>
> On Wed, Jul 14, 2010 at 3:23 AM, Jesse Nelson 
> <
 >
>  wrote:
>> heres an example oh how we do it
>>
>> $ knife data bag show network test01
>> {
>>  "routes": {
>>    "home": {
>>      "network": "172.30.10.0/24",
>>      "gateway": "127.0.0.1"
>>    }
>>  },
>>  "id": "test01",
>>  "interfaces": {
>>    "sys-ext": {
>>      "mask": "255.255.255.0",
>>      "ip": "127.0.1.4",
>>      "dev": "lo:0"
>>    },
>>    "mail": {
>>      "mask": "255.255.255.0",
>>      "ip": "127.0.0.3",
>>      "dev": "lo:1"
>>    },
>>    "mail-ext": {
>>      "mask": "255.255.255.0",
>>      "ip": "127.0.1.3",
>>      "dev": "lo:2"
>>    },
>>    "sys": {
>>      "mask": "255.255.255.0",
>>      "ip": "127.0.0.4",
>>      "dev": "lo:3"
>>    }
>>  }
>> }
>>
>>
>> and the default recipe from a "network" cookbook:
>>
>> # want to catch this so we don't always have to set up interfaces
>> begin
>>    net_dbag = data_bag_item('network', @node[:hostname] )
>> rescue
>>    net_dbag = nil
>> end
>>
>> # we want to ignore these failures  we catch them in splunk for now
>> if net_dbag
>>  net_dbag['interfaces'].each_value do |int|
>>    ifconfig  int['ip'] do
>>      ignore_failure  true
>>      device  int['dev']
>>      mask    int['mask']
>>      gateway int['gateway'] if int['gateway']
>>      mtu     int['mtu'] if int['mtu']
>>    end
>>  end
>>
>>  # custom routes  well do dbag routes first here and then
>>  # attrib based routes as well
>>  net_dbag['routes'].each_value do |r|
>>    route r['network'] do
>>      ignore_failure true
>>      gateway r['gateway']
>>      netmask  r['netmask'] if r['netmask']
>>      device   r['device']  if r['device']
>>    end
>>  end
>> end
>>
>> i also setup a route resource based on node attribs. so that roles and 
>> such can set routes if need be
>>
>> super simple data bag driven network config.
>>
>> On Jul 13, 2010, at 5:50 PM, John Hanks wrote:
>>
>>> I have a recipe that is redhat/centos specific that I use to configure
>>> eth, vlan and bond devices. It's crude but effective and uses a set of
>>> attributes like (most complicated example I've used):
>>>
>>> "netcfg" => {
>>>    "devices" => {
>>>        "bond0" => {
>>>          "bootproto" => "dhcp",
>>>          "device" => "bond0",
>>>          "nics" => "eth0,eth1",
>>>          "onboot" => "yes",
>>>          "mtu" => "9000",
>>>          "mode" => "0"
>>>        },
>>>      "vlan32" => {
>>>            "bootproto" => "dhcp",
>>>            "device" => "vlan32",
>>>            "physdev" => "bond0"
>>>        }
>>>    },
>>>    "gatewaydev" => "vlan32"
>>> }
>>>
>>> Or, a simpler config for 2 nics:
>>>
>>> "netcfg" => {
>>>    "devices" => {
>>>        "eth0" => {
>>>            "bootproto" => "dhcp",
>>>            "device" => "eth0",
>>>            "onboot" => "yes"
>>>        },
>>>        "eth1" => {
>>>            "bootproto" => "dhcp",
>>>            "device" => "eth1",
>>>            "onboot" => "yes",
>>>            "mtu" => "9000"
>>>        }
>>>    },
>>>    "gatewaydev" => "eth1"
>>> }
>>>
>>> The cookbook should support all available redhat style settings for
>>> ifcfg-* files and /etc/sysconfig/network. But since all my interfaces
>>> dhcp, using this for the static settings is poorly tested. If anyone
>>> is interested I've stuck a recent copy of it here:
>>> http://www.broadinstitute.org/~jbh/netcfg.tar.gz
>>>
>>> Because my nodes are diskless, there's not much effort put into
>>> maintaining files, just into creating them since everything gets
>>> rebuilt upon reboot. It'd probably take a bit more polish to make this
>>> safe for a server provisioned to disk where you'd want to maintain and
>>> update the files over time.
>>>
>>> jbh
>>>
>>>
>>> On Tue, Jul 13, 2010 at 7:59 PM, Jesse Nelson 
>>> <
 >
>>>  wrote:
>>>> you can manage the files directly or use the resources.   we use the
>>>> resource and data bags to manage static assignments for sub-interface and
>>>> vlan interfaces on some (not all) hosts..
>>>> this model has allowed me to name interfaces in json data in a data bag 
>>>> and
>>>> reuse or search against those names in other recipes. this has worked out
>>>> well for me.
>>>> i am happy to share the very simple recipe that achieves this, but its 
>>>> not
>>>> up anywhere atm.
>>>>
>>>>
>>>>
>>>> On Jul 13, 2010, at 4:23 PM, Ryan C. Creasey wrote:
>>>>
>>>> I've played around with managing auxiliary interfaces on my nodes (eth1,
>>>> loopback aliases, etc) for some of our DSR nodes and took the easy way 
>>>> out
>>>> and had the recipe manage the templates to the
>>>> "/etc/sysconfig/network-scripts/ifcfg-#{interface[:device]}" (yes, we're
>>>> redhat based).
>>>> I'd also be interested to hear other use cases for interface management 
>>>> with
>>>> chef.
>>>>
>>>> Ryan C. Creasey
>>>> PRINCIPAL SYSTEMS ENGINEER
>>>> IGN Entertainment
>>>> T: 714.460.6789  |  C: 949.378.9023 | AIM: ryancreasey
>>>>
>>>>
>>>> On Jul 13, 2010, at 4:19 PM, Jacobo García wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have to manage some network interfaces, routes and and ipip tunnels.
>>>> I know about chef's route and ifconfig resource. But I'd like to know
>>>> experiences of people playing with these sensitive stuff, specially
>>>> about configuring network interfaces, is the resource reliable enough?
>>>> does it work with virtual interfaces?
>>>>
>>>> Thanks :)
>>>>
>>>> Jacobo García López de Araujo
>>>> blog: http://robotplaysguitar.com
>>>> http://workingwithrails.com/person/13395-jacobo-garc-a
>>>>
>>>>
>>>>
>>>>
>>
>>
>