Hi - I''ve searched around and haven''t found anyone who''s implemented a type+provider for configuring network interfaces in puppet. Does anyone have such a thing already running that''s just not on forge / github? I found some prior art (aside from the old ''interface'' type which was deleted in 0.24) but most people seem to use definitions + templates which isn''t a good "first class citizen" solution. I and other puppet hackers around my organization worked up a strawman proposal that we thought would be a reasonable interface and I figured I would float it by the list. Obviously it''s a complicated beast but this would be great functionality to have in puppet. I''ll update https://projects.puppetlabs.com/issues/3153 with the results of the discussion here and maybe we can get some traction on it. - Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook - ### basic examples networkinterface { "eth0": ensure => enabled, bootproto => dhcp, # required for DHCP/BOOTP, optional for static hwaddr => "00:aa:bb:cc:dd:ee" } networkinterface { "eth0": ensure => "enabled", # sets ONBOOT=true, causes ifup refresh hwaddr => "00:aa:bb:cc:dd:ee" ipaddress => "10.0.0.2", netmask => "255.255.255.0", gateway => "10.0.0.1", } ### vlan example networkinterface { "vlan201": ensure => "enabled", ipaddress => "10.0.0.3", netmask => "255.255.255.0", gateway => "10.0.0.1", vlantag => "201", # 1 through 4096 physicaldev => "eth0", # parent device, need this or hwaddr # not too happy about this, but IMO the yum ''enablerepo'' example # shows there is a need to pass arbitrary provider-specific args # i.e. the RH sysvinit provider would turn " " to \n and # drop these into the network-scripts file. # This particular option enables ''/dev/vlan201'' instead of ''/dev/eth0.201'' extra_opts => "VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD PEERDNS=NO PEERNTP=NO" } ### bonding example - master interface with two slaves networkinterface { "bond0": ensure => "enabled", ipaddress => "10.0.0.4", netmask => "255.255.255.0", gateway => "10.0.0.1", # rather than support a crapload of attributes like "bond_mode => active_backup", # use the new-style BONDING_OPTS variable extra_opts => "BONDING_OPTS=''mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254''" } # slave interfaces for the bond networkinterface { "eth0": ensure => enabled, bond_master => bond0, } networkinterface { "eth1": ensure => enabled, bond_master => bond0, } ### ip aliases # this requires a unique namevar so you couldn''t model solaris # or iproute2-style secondary addresses without composite keys networkinterface { "bge0:1": ensure => enabled, ipaddress => "10.0.0.5", netmask => "255.255.255.0", gateway => "10.0.0.1", } -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Probably better to use network::interface, so you can add support for other network resources. Also: https://github.com/ohlol/puppet-network Old, out of date, not complete, but it''s a start. On Tue, Mar 1, 2011 at 5:50 PM, Eric Sorenson <eric.sorenson@me.com> wrote:> Hi - I''ve searched around and haven''t found anyone who''s implemented a > type+provider for configuring network interfaces in puppet. Does anyone > have such a thing already running that''s just not on forge / github? I found > some prior art (aside from the old ''interface'' type which was deleted in > 0.24) but most people seem to use definitions + templates which isn''t a good > "first class citizen" solution. > > I and other puppet hackers around my organization worked up a strawman > proposal that we thought would be a reasonable interface and I figured I > would float it by the list. Obviously it''s a complicated beast but this > would be great functionality to have in puppet. I''ll update > https://projects.puppetlabs.com/issues/3153 with the results of the > discussion here and maybe we can get some traction on it. > > - Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook - > > > ### basic examples > networkinterface { "eth0": > ensure => enabled, > bootproto => dhcp, # required for DHCP/BOOTP, optional for static > hwaddr => "00:aa:bb:cc:dd:ee" > } > > networkinterface { "eth0": > ensure => "enabled", # sets ONBOOT=true, causes ifup refresh > hwaddr => "00:aa:bb:cc:dd:ee" > ipaddress => "10.0.0.2", > netmask => "255.255.255.0", > gateway => "10.0.0.1", > } > > ### vlan example > networkinterface { "vlan201": > ensure => "enabled", > ipaddress => "10.0.0.3", > netmask => "255.255.255.0", > gateway => "10.0.0.1", > vlantag => "201", # 1 through 4096 > physicaldev => "eth0", # parent device, need this or hwaddr > # not too happy about this, but IMO the yum ''enablerepo'' example > # shows there is a need to pass arbitrary provider-specific args > # i.e. the RH sysvinit provider would turn " " to \n and > # drop these into the network-scripts file. > # This particular option enables ''/dev/vlan201'' instead of > ''/dev/eth0.201'' > extra_opts => "VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD PEERDNS=NO > PEERNTP=NO" > } > > ### bonding example - master interface with two slaves > networkinterface { "bond0": > ensure => "enabled", > ipaddress => "10.0.0.4", > netmask => "255.255.255.0", > gateway => "10.0.0.1", > # rather than support a crapload of attributes like "bond_mode => > active_backup", > # use the new-style BONDING_OPTS variable > extra_opts => "BONDING_OPTS=''mode=active-backup arp_interval=60 > arp_ip_target=192.168.1.254''" > } > # slave interfaces for the bond > networkinterface { "eth0": > ensure => enabled, > bond_master => bond0, > } > networkinterface { "eth1": > ensure => enabled, > bond_master => bond0, > } > > ### ip aliases > # this requires a unique namevar so you couldn''t model solaris > # or iproute2-style secondary addresses without composite keys > networkinterface { "bge0:1": > ensure => enabled, > ipaddress => "10.0.0.5", > netmask => "255.255.255.0", > gateway => "10.0.0.1", > } > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Eric Sorenson wrote:> Hi - I''ve searched around and haven''t found anyone who''s implemented a > type+provider for configuring network interfaces in puppet. Does anyone > have such a thing already running that''s just not on forge / github? I > found some prior art (aside from the old ''interface'' type which was > deleted in 0.24) but most people seem to use definitions + templates > which isn''t a good "first class citizen" solution. > > I and other puppet hackers around my organization worked up a strawman > proposal that we thought would be a reasonable interface and I figured I > would float it by the list. Obviously it''s a complicated beast but this > would be great functionality to have in puppet. I''ll > update https://projects.puppetlabs.com/issues/3153 with the results of > the discussion here and maybe we can get some traction on it. > > - Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook -Eric One of our GSOC students started some work on this: https://github.com/blkperl/puppet-network James -- James Turnbull Puppet Labs 1-503-734-8571 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 2011-03-02 02:50, Eric Sorenson wrote: (Sorry for responding late; I''m a bit behind in reading puppet-users and puppet-dev.)> Hi - I''ve searched around and haven''t found anyone who''s implemented > a type+provider for configuring network interfaces in puppet. Does > anyone have such a thing already running that''s just not on forge / > github? I found some prior art (aside from the old ''interface'' type > which was deleted in 0.24) but most people seem to use definitions + > templates which isn''t a good "first class citizen" solution. > > I and other puppet hackers around my organization worked up a strawman > proposal that we thought would be a reasonable interface and I figured > I would float it by the list. Obviously it''s a complicated beast but > this would be great functionality to have in puppet. I''ll update > https://projects.puppetlabs.com/issues/3153 with the results of the > discussion here and maybe we can get some traction on it.> ### basic examples > networkinterface { "eth0": > ensure => enabled, > bootproto => dhcp, # required for DHCP/BOOTP, optional for static > hwaddr => "00:aa:bb:cc:dd:ee" > } > > networkinterface { "eth0": > ensure => "enabled", # sets ONBOOT=true, causes ifup refresh > hwaddr => "00:aa:bb:cc:dd:ee" > ipaddress => "10.0.0.2", > netmask => "255.255.255.0", > gateway => "10.0.0.1", > }The basic seems OK. A few comments, questions and discussion points: - What does the hwaddr parameter do? I guess that it corresponds to the HWADDR setting in /etc/sysconfig/network-scripts/ifcfg-eth* on RedHat:ish systems, and not the MACADDR setting? I.e. it will be used to select which interface is eth0, not the set the MAC address of eth0? I hope it is supposed to be an optional parameter, so we don''t have to write ''hwaddr => $macaddress_eth0'' on every interface resource. - It would be nice to be able to specify the netmask as either a proper netmask (i.e. like 255.255.255.0) or as a number of bits (i.e. 24). - It would be nice to be able to specify the IP address and netmask in one parameter using CIDR notation, i.e: networkinterface { "eth0": ipaddress => "10.0.0.3/24"; "eth1": ipaddress => "192.168.17.23/255.255.240.0"; } - The gateway parameter is optional, I suppose? - I would like the ensure parameter to be split into two: ''ensure => up'', ''ensure => down'' or ''ensure => dontcare'' to specify which state the interface should be in right now, and ''onboot => true'' or ''onboot => false'' to specify if it should be brought up when the machine boots. (Exact names of the parameters and values is not so important.) - There is also a need to be able to configure an interface as up (and onboot=true) but without setting any network parameters. I need it on some of my multihomed Xen dom0 machines, where the dom0 itself should only use eth1, but the guests need a connection via eth0. If I bring down eth0, my guests lose their network... In the definition I''m using now, I use ''bootproto => unconfigured, onboot => true, ensure => up'', but I''m not married to that particular spelling. - And here''s a big discussion point: IPv6. One can use different address assignment methods for IPv4 and IPv6 for the same interface. On IPv6 it is also common to have several addresses on each interface. I don''t really have any ideas here, though; we are only just now starting to look at IPv6, I''m afraid...> ### vlan example > networkinterface { "vlan201": > ensure => "enabled", > ipaddress => "10.0.0.3", > netmask => "255.255.255.0", > gateway => "10.0.0.1", > vlantag => "201", # 1 through 4096 > physicaldev => "eth0", # parent device, need this or hwaddr > # not too happy about this, but IMO the yum ''enablerepo'' example > # shows there is a need to pass arbitrary provider-specific args > # i.e. the RH sysvinit provider would turn " " to \n and > # drop these into the network-scripts file. > # This particular option enables ''/dev/vlan201'' instead of ''/dev/eth0.201'' > extra_opts => "VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD PEERDNS=NO PEERNTP=NO" > }The extra_opts parameter is a good idea. I would suggest that you should specifiy it as an array of options, like this: extra_opts => [ "VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD", "PEERDNS=NO", "PEERNTP=NO" ] I don''t have any specific comments on the VLAN stuff, though.> ### bonding example - master interface with two slaves > networkinterface { "bond0": > ensure => "enabled", > ipaddress => "10.0.0.4", > netmask => "255.255.255.0", > gateway => "10.0.0.1", > # rather than support a crapload of attributes like "bond_mode => active_backup", > # use the new-style BONDING_OPTS variable > extra_opts => "BONDING_OPTS=''mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254''" > } > # slave interfaces for the bond > networkinterface { "eth0": > ensure => enabled, > bond_master => bond0, > } > networkinterface { "eth1": > ensure => enabled, > bond_master => bond0, > }The only comment I have on bonding, is to think about terminology. I believe the official Ethernet name is "aggregation", while Linux calls it "bonding", and HP use "trunking".> ### ip aliases > # this requires a unique namevar so you couldn''t model solaris > # or iproute2-style secondary addresses without composite keys > networkinterface { "bge0:1": > ensure => enabled, > ipaddress => "10.0.0.5", > netmask => "255.255.255.0", > gateway => "10.0.0.1", > }Iproute2-style secondary addresses probably ties into how one should configure IPv6 addresses. /Bellman -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thanks Thomas. My Reply is also late :) But thanks very much for your good points. Replies inline. On Mar 16, 8:06 am, Thomas Bellman <bell...@nsc.liu.se> wrote:> - What does the hwaddr parameter do? I guess that it corresponds to > the HWADDR setting in /etc/sysconfig/network-scripts/ifcfg-eth* on > RedHat:ish systems, and not the MACADDR setting? I.e. it will be > used to select which interface is eth0, not the set the MAC address > of eth0? I hope it is supposed to be an optional parameter, so we > don''t have to write ''hwaddr => $macaddress_eth0'' on every interface > resource.Yes this should be flagged as optional, there is a bootstrapping problem here between interface fact names/values and what''s specified in manifest but the whole type will be tricky that way.> - It would be nice to be able to specify the netmask as either a proper > netmask (i.e. like 255.255.255.0) or as a number of bits (i.e. 24). > > - It would be nice to be able to specify the IP address and netmask > in one parameter using CIDR notation, i.e: > > networkinterface{ > "eth0": ipaddress => "10.0.0.3/24"; > "eth1": ipaddress => "192.168.17.23/255.255.240.0"; > }What do you think about making CIDR the *only* way to specify netmask? It would simplify things...> - The gateway parameter is optional, I suppose?Yes> > - I would like the ensure parameter to be split into two: ''ensure => up'', > ''ensure => down'' or ''ensure => dontcare'' to specify which state the > interface should be in right now, and ''onboot => true'' or ''onboot => > false'' to specify if it should be brought up when the machine boots. > (Exact names of the parameters and values is not so important.)> > - There is also a need to be able to configure an interface as up (and > onboot=true) but without setting any network parameters. I need it > on some of my multihomed Xen dom0 machines, where the dom0 itself > should only use eth1, but the guests need a connection via eth0. If > I bring down eth0, my guests lose their network... In the definition > I''m using now, I use ''bootproto => unconfigured, onboot => true, > ensure => up'', but I''m not married to that particular spelling. >These all make sense, will incorporate and repost, maybe on a gist or a fork of blkperl''s provider since that''s where I''m starting.> - And here''s a big discussion point: IPv6. One can use different > address assignment methods for IPv4 and IPv6 for the same interface. > On IPv6 it is also common to have several addresses on each interface. > I don''t really have any ideas here, though; we are only just now > starting to look at IPv6, I''m afraid... >I don''t have any idea about that either. I have to focus on solving the problem in front of me; maybe if someone wants to work on ipv6 they can chime in with their opinion.> The extra_opts parameter is a good idea. I would suggest that you > should specifiy it as an array of options, like this: > > extra_opts => [ "VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD", > "PEERDNS=NO", > "PEERNTP=NO" ]Ah, good point, updated> > The only comment I have on bonding, is to think about terminology. > I believe the official Ethernet name is "aggregation", while Linux > calls it "bonding", and HP use "trunking". > > > ### ip aliases > > # this requires a unique namevar so you couldn''t model solaris > > # or iproute2-style secondary addresses without composite keys > >networkinterface{ "bge0:1": > > ensure => enabled, > > ipaddress => "10.0.0.5", > > netmask => "255.255.255.0", > > gateway => "10.0.0.1", > > } > > Iproute2-style secondary addresses probably ties into how one > should configure IPv6 addresses. > > /Bellman-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.