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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
