Code Monkey home page Code Monkey logo

puppet-bsd's Introduction

Puppet BSD

Puppet Forge Build Status

A Puppet module for managing aspects of BSD. Currently supported are FreeBSD and OpenBSD. In here will be various facts, functions and classes for tuning and configuring a system.

It is intended that Puppet users of this code use only the classes and facts in their manifests. The rest of the code here is simply to support the interface supplied by the manifests. Implementing the functions directly is not advised, as the implementation may shift over time as the module requires.

Dependencies

This module requires the 'ipaddress' ruby gem to be installed.

gem install ipaddress

or let Puppet take care:

package { 'ipaddress':
  ensure   => 'present',
  provider => 'gem',
}

Installation

The easiest way to install is to install from the forge.

puppet module install zleslie/bsd

Network

Network configuration is handled under the bsd::network name space. Under this space you will find classes available to configure basic network configuration items like gateways and static address, to more advanced topics like vlan(4) and carp(4) interfaces.

Ideally, this module should support any useful aspect of network configuration, including things like wireless (AP and client) and static routes.

Gateways

The gateway can be configured for both router and hosts.

host

To configure static addressing on a host, first you may wish to configure the gateway(s).

class { 'bsd::network':
  v4gateway => '10.0.0.1',
  v6gateway => 'fc00::',
}

router

To set the upstream gateway on a router system as well as turn on dual stack forwarding, use the following configuration.

class { 'bsd::network':
  v4gateway    => '1.1.1.1',
  v6gateway    => '2001:b:b::1',
  v4forwarding => true,
  v6forwarding => true,
}

Addressing

Once you have the gateway set, you may wish to set some interface addresses.

bsd::network::interface { 'em0':
  description => 'Primary Interface',
  addresses   => [ '10.0.0.2/24', 'fc00::b0b/64' ],
}

This will do the needful of setting the configuration for setting the interface address and gateway.

NOTE: This only sets the configuration, it does not currently set the running interfaces addresses.

Interface configuration order

Clonable interfaces might require other interfaces to be configured first. The bsd::network::interface defined type has a 'parents' parameter that can take a string or array of interface names, that in turn will be required to be configured before. Note that the parent interfaces are not required to be managed via Puppet.

Interfaces

Interface configurations are handled per interface type. Each supported type will have an implementation of the library through the user of functions and expose a manifest to the user for configuration.

vlan(4)

To create a vlan(4) interface and assign an address to it, use a manifest like the following.

bsd::network::interface::vlan { 'vlan100':
  id         => 100,
  device     => 'em0',
  address    => ['10.0.0.1/24'],
  raw_values => ['!/sbin/route add -net 10.10.10.0/24 10.10.0.254',],
}

It is sometimes desirable to create a VLAN interface without needing to set any interface addresses on it. In such a case, simply leave off the address, and specify the VLAN ID and the device to attach the VLAN to.

bsd::network::interface::vlan { 'vlan100':
  id      => 100,
  device  => 'em0',
}

carp(4)

The carp(4) device is supported through the bsd::network::interface::carp defined type. Carp interface preemption is handled via the bsd::network::carp class, and defaults to false. This class is automatically included, when a carp device is managed.

class { 'bsd::network::carp':
  preempt => true,
}

bsd::network::interface::carp { "carp0":
  id         => 1,
  address    => ['10.0.0.1/24'],
  carpdev    => 'em0',
  pass       => 'TopSecret',
  raw_values => ['!/sbin/route add -net 10.10.10.0/24 10.0.0.254',],
}

pfsync(4)

Closely related to carp(4) interfaces are the pfsync(4) interfaces. They are supported by bsd::network::interface::pfsync defined type.

bsd::network::interface::pfsync { "pfsync0":
  description => 'PF state sync interface',
  syncdev     => 'bge0',
  syncpeer    => '10.0.0.123',
  maxupd      => 128,
  defer       => false,
}

lagg(4) and trunk(4)

bsd::network::interface::trunk { "trunk0":
  interface => ['em0','em1],
  address   => ['10.0.0.1/24'],
}

vlan trunks

To configure a set of interfaces as a trunk passing multiple vlans, just leave the address off of the trunk(4) interface and use it as the device for the vlan(4) interface.

bsd::network::interface::trunk { "trunk0":
  interface => ['em0','em1'],
}

bsd::network::interface::vlan { "vlan10":
  id      => 10,
  address => ['10.0.10.1/24'],
  device  => 'trunk0',
}

bsd::network::interface::vlan { "vlan11":
  id         => 11,
  address    => ['10.0.11.1/24'],
  device     => 'trunk0',
  raw_values => ['!/sbin/route add -net 10.10.10.0/24 10.0.11.254',],
}

tun tunnel devices

The tun(4) device is supported directly through the bsd::network::interface defined type.

bsd::network::interface { 'tun0':
  raw_values => [
    'up',
    '!/usr/local/bin/openvpn --daemon'
  ]
}

gif tunnel devices

The gif(4) device is supported directly through the bsd::network::interface defined type. I.e. an IPv6 via IPv4 tunnel could look like:

bsd::network::interface { 'gif0':
  description => 'IPv6 in IPv4 tunnel',
  parents     => 'em0',
  raw_values  => [
    'tunnel 1.2.3.4 5.6.7.8',
    'inet6 alias 2001:470:6c:bbb::2 2001:470:6c:bbb::1 prefixlen 128',
    '!/sbin/route -n add -inet6 default 2001:470:6c:bbb::1',
  ],
}

Note: Ethernet-over-IP modes are not yet supported via this module.

gre tunnel devices

The gre(4) device is supported directly through the bsd::network::interface defined type. Prior to make GRE interfaces work, GRE needs to be allowed. Additionally WCCPv1-style GRE packets can be enabled as well as MobileIP packets. Example of the bsd::network::gre class below shows the default values.

class { 'bsd::network::gre':
  allowed  => true,
  wccp     => false,
  mobileip => false,
}

bsd::network::interface { 'gre0':
  description => 'Tunnel interface',
  parents     => 'em0',
  raw_values  => [
    '172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up',
    'tunnel 1.2.3.4 5.6.7.8',
  ],
}

pflow interfaces

The pflow(4) device is supported directly through the bsd::network::interface defined type.

bsd::network::interface { 'pflow0':
  description => 'Pflow to collector',
  parents     => 'em0',
  raw_values  => [
    'flowsrc 1.2.3.4 flowdst 5.6.7.8:1234',
    'pflowproto 10',
  ],
}

wireless interfaces

There are many networking options for wifi. See [http://www.openbsd.org/faq/faq6.html#Wireless](the openbsd documentation) for more information.

Use the following to connect to a wireless network using WPA.

bsd::network::interface::wifi { 'athn0':
  network_name => 'myssid',
  network_key  => 'mysecretkey',
}

bridge(4) interfaces

bsd::network::interface::bridge { "bridge0":
  interface => ['em0','em1'],
}

Storing interface data in Hiera example

Now that the primitives of this module have been outlined, you may want to consider storing the data for your interfaces in Hiera. Below is an outline of how this might easily be accomplished.

First we leverage all the standard interface definitions from our hiera_hash() lookup to pass to create_resources().

class profile::network::interfaces {

  case $::osfamily {
    /(Open|Free)BSD/: {
      include bsd::network

      # Manage physical interfaces
      $interfaces = hiera_hash('bsd::network::interface', {})
      create_resources('bsd::network::interface', $interfaces)
    }
  }
}

Next we repeat the pattern for the various virtual interfaces, including the above class.

class profile::network::interfaces::trunk {
  include profile::network::interfaces

  case $::osfamily {
    /(Open|Free)BSD/: {
      # Setup the trunk interfaces
      $trunk_interfaces = hiera_hash('bsd::network::interface::trunk', {})
      create_resources('bsd::network::interface::trunk', $trunk_interfaces)
    }
  }
}

A complete example for one users "Jail Host" role looks like the following, assuming the above two classes are included.

bsd::network::v4gateway: '172.16.0.1'
bsd::network::v6gateway: '2001:111:111:111::111'
bsd::network::v4forwarding: true
bsd::network::v6forwarding: true

bsd::network::interface:
  igb0:
    description: "Router trunk member interface"
    ensure: 'up'
  igb1:
    description: "Router trunk member interface"
    ensure: 'up'
  lo1:
    description: "Jail service loopback"
    ensure: 'up'
    addresses:
      - '2001:111:111:200::100/120'
      - '172.16.1.0/27'

bsd::network::interface::trunk:
  lagg0:
    interface:
      - 'igb0'
      - 'igb1'
    address:
      - '2001:111:111:111::120/120'
      - '172.16.0.2/24'

Contributing

Please help make this module better by sending pull requests and filing issues for feature requests or bugs. Please adhere to the style and be mindful of the tests.

puppet-bsd's People

Contributors

zachfi avatar buzzdeee avatar dajeffers avatar danieldreier avatar

Stargazers

Oleg Ginzburg avatar Harshad Sharma avatar Olivia avatar Ian Watt avatar Rain avatar Aslak Raanes avatar Lee Packham avatar  avatar Don Jackson avatar

Watchers

 avatar  avatar James Cloos avatar Oleg Ginzburg avatar Joe Rodriguez Jr avatar  avatar Daniel Kossakowski avatar

puppet-bsd's Issues

route does not get set on FreeBSD

Hello,

I'm trying to set a static IP and default route on a FreeBSD 11.1 machine with:

class { 'bsd::network':
v4gateway => '192.168.0.1'
}
bsd::network::interface { 'em0':
description => 'Primary Interface',
addresses => [ '192.168.0.37/24' ]
}

on a machine the previously received and IP over DHCP.

The interesting thing that happens is that the default route gets removed but not added back again by the puppet agent run. This in turn leaves the server not accessible.

From what I can gather, it's because the routing service on FreeBSD has no "status" command and also does not need to be running. As can be seen from below, the restart is never issued.

Debug: Executing: '/etc/rc.d/routing onestatus'
Debug: /Stage[main]/Bsd::Network/Service[routing]: Skipping restart; service is not running

Am I missing some option in my node definition?

order of interface handling in the catalog

On initial provision, there is no order guaranteed for interface creation.

i.e. you have physical interfaces, trunks on top, vlans on top of trunks, and maybe carp interfaces on the vlan interfaces, etc.
When puppet runs, it may create and start carp interfaces before the vlan interfaces are configured, and so on.

For the interface types in network/interface/*.pp, they all have parameters specifying the parents, i.e. trunk.pp has the 'interface' parameter, vlan.pp and carp.pp have the 'device' parameter.

How about, adding a parameter to bsd::network::interface called parent (should be an array), defaulting to 'undef'.
When configuring a trunk, vlan or carp interface, the given interface or respective device parameters are handed over to the 'parent' parameter of bsd::network::interface when it is called.

Further down the road, add a 'parent' parameter to bsd_interface native type, and hand over the parents if given. Then in bsd_interface, when ensure = 'up' or 'present', there could be an
autorequire to the parent interface(s)

Do you think that sounds sane and would be feasible?
Other ideas? I'd like to look into that to get something along the lines working.

cheers,
Sebastian

wifi interfaces with two static IPs don't work

I'm running dual-stack @home, so I have IPv4 and IPv6 to configure on my AP. With this, I specify two static IPs:

I have this in Hiera defined:
bsd::network::interface::wifi:
"%{hiera('node::odo::ds9::wifi_if_name')}":
network_name: "%{hiera('network::wifi::network_name')}"
address:
- "%{hiera('node::odo::ds9::wifi_if_inet')}%{hiera('network::wifi::inet_cidr_netmask')}"
- "%{hiera('node::odo::ds9::wifi_if_inet6')}/%{hiera('network::wifi::inet6_prefix')}"
description: 'Access Point'
options:
- 'chan 1'
- 'media OFDM54'
- 'mode 11g'
- 'mediaopt hostap'

which produces this result when run:

inet 10.23.4.56 255.255.0.0 NONE inet6 2001:471:4336:ff::1 64 nwid brb.freifunk.net chan 1 media OFDM54 mode 11g mediaopt hostap description "Access Point"
up

which ends up in:

sh /etc/netstart ral0
ifconfig: inet6: bad value

The module should be better splitting up the lines like:
inet 10.23.4.56 255.255.0.0 NONE
inet6 2001:471:4336:ff::1 64
nwid brb.freifunk.net chan 1 media OFDM54 mode 11g mediaopt hostap description "Access Point"
up

sysctl dependency change problem

Since I run all my moudles from upstream git, and update daily, I
kind of quickly ran into this issue here ;)

I have duritong/sysctl installed in parallel to hercules/augeasproviders_sysctl
and I get with latest git:

puppet agent --test

Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid parameter value on Sysctl[net.inet.ip.forwarding] at /etc/puppet/environments/production/modules/bsd/manifests/network.pp:31 on node MYNODE
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

git reset --hard 39d22ef

then I at least only get:

puppet agent --test

Info: Retrieving pluginfacts
Info: Retrieving plugin
Notice: /File[/var/puppet/lib/puppet/provider/sysctl/augeas.rb]/ensure: defined content as '{md5}227da37dd9052c3bbb4bc53f69936afb'
Info: Loading facts
Info: Loading facts
Info: Caching catalog for MYNODE
Warning: Found multiple default providers for sysctl: augeas, parsed; using augeas
Info: Applying configuration version '1466582508'

luckily I use duritong/sysctl only in my own
modules and can fix that, but others might run into similar dependency issues.

Should manage cloned interfaces in rc.conf on FreeBSD

Without this, addressing does not persist a reboot, and will rely on Puppet running to bring the interfaces back into the desired state. We simply need to figure out what interfaces we are managing, and add them to rc.conf.

link-local IPv6 addresses with %interface suffix are not matched/valid

Hi,

for my rented root server, I had up to now my default gateway defined as: fe80::1%re0

due to the failing test:

puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Loading facts
Could not retrieve fact='apache_version', resolution='<anonymous>': undefined method `[]' for nil:NilClass
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: {"message":"Server Error: Evaluation Error: Error while evaluating a Function Call, Class[Bsd::Network]: parameter 'v6gateway' expects a match for Variant[IP::Address::V6::Full = Pattern[/\\A[[:xdigit:]]{1,4}(:[[:xdigit:]]{1,4}){7}(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/], IP::Address::V6::Compressed = Pattern[/\\A:(:|(:[[:xdigit:]]{1,4}){1,7})(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){1}(:|(:[[:xdigit:]]{1,4}){1,6})(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){2}(:|(:[[:xdigit:]]{1,4}){1,5})(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){3}(:|(:[[:xdigit:]]{1,4}){1,4})(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){4}(:|(:[[:xdigit:]]{1,4}){1,3})(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){5}(:|(:[[:xdigit:]]{1,4}){1,2})(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){6}(:|(:[[:xdigit:]]{1,4}){1,1})(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){7}:(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/], IP::Address::V6::Alternative = Pattern[/\\A([[:xdigit:]]{1,4}:){6}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){5}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){4}(:[[:xdigit:]]{1,4}){0,1}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){3}(:[[:xdigit:]]{1,4}){0,2}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){2}(:[[:xdigit:]]{1,4}){0,3}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A([[:xdigit:]]{1,4}:){1}(:[[:xdigit:]]{1,4}){0,4}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/, /\\A:(:[[:xdigit:]]{1,4}){0,5}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}(\\/(1([01][0-9]|[2][0-8])|[1-9][0-9]|[1-9]))?\\z/], IP::Address::V6::NoSubnet::Full = Pattern[/\\A[[:xdigit:]]{1,4}(:[[:xdigit:]]{1,4}){7}\\z/], IP::Address::V6::NoSubnet::Compressed = Pattern[/\\A:(:|(:[[:xdigit:]]{1,4}){1,7})\\z/, /\\A([[:xdigit:]]{1,4}:){1}(:|(:[[:xdigit:]]{1,4}){1,6})\\z/, /\\A([[:xdigit:]]{1,4}:){2}(:|(:[[:xdigit:]]{1,4}){1,5})\\z/, /\\A([[:xdigit:]]{1,4}:){3}(:|(:[[:xdigit:]]{1,4}){1,4})\\z/, /\\A([[:xdigit:]]{1,4}:){4}(:|(:[[:xdigit:]]{1,4}){1,3})\\z/, /\\A([[:xdigit:]]{1,4}:){5}(:|(:[[:xdigit:]]{1,4}){1,2})\\z/, /\\A([[:xdigit:]]{1,4}:){6}(:|(:[[:xdigit:]]{1,4}){1,1})\\z/, /\\A([[:xdigit:]]{1,4}:){7}:\\z/], IP::Address::V6::NoSubnet::Alternative = Pattern[/\\A([[:xdigit:]]{1,4}:){6}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}\\z/, /\\A([[:xdigit:]]{1,4}:){5}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}\\z/, /\\A([[:xdigit:]]{1,4}:){4}(:[[:xdigit:]]{1,4}){0,1}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}\\z/, /\\A([[:xdigit:]]{1,4}:){3}(:[[:xdigit:]]{1,4}){0,2}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}\\z/, /\\A([[:xdigit:]]{1,4}:){2}(:[[:xdigit:]]{1,4}){0,3}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}\\z/, /\\A([[:xdigit:]]{1,4}:){1}(:[[:xdigit:]]{1,4}){0,4}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}\\z/, /\\A:(:[[:xdigit:]]{1,4}){0,5}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}\\z/]], got 'fe80::1%re0' at /etc/puppetlabs/code/environments/production/modules/profile/manifests/network.pp:16:7 on node deepspace.l00-bugdead-prods.de","issue_kind":"RUNTIME_ERROR"}
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

just to let you know, haven't checked if there is something in thrnio/ip that might match 'fe80::1%re0' and the bsd module has to be updated, or if the thrnio/ip module should get an update to match addresses like this.

wifi interfaces don't allow to configure wpa keys

Hi,

the wifi interface only has parameter network_key, which "magically" maps to wpakey.

How about changing the wifi interface the following way:

keep network_key as is, but add a deprecation warning.
add wpa_key and wep_key parameters, where both behave as the name suggests ;)

Seeking New Ownership

For many years, Puppet has been the core of my infrastructure needs. That has changed in the last 9 months, and I've begun a new path that I hope will carry me as long as Puppet has.

For those that may still benefit from any of this code, you all deserve maintainers that will give it the attention required, and that is no longer me. And if I'm being honest, it hasn't been me for longer than I'm ready to admit.

So, for those few, I request that if anyone wants this to persist, fork it and make a new. I plan to archive all of the Puppet repos under my name in the coming month and collapse all of my puppet related infrastructure. Expect no more releases from me. Any coordination/communication of forks should happen quickly.

Thank you for all the collaboration over the years. It has been a real privilege.

carp interface management doesn't handle carp passwords

While playing with the module, to create a CARP interface, I figured, it doesn't handle the configuration of passwords for carp traffic authentication.

I have a patch ready that does that ;)
Just waiting for the future parser patch to get accepted.
OR I could stuff it into the future parser patch.

Sebastian

Support for gif(4)

Actually, the module is great, configuring network interfaces.
The one interface type I'm missing, for my IPv6 via IPv4 tunnel is a gif interface.

Would be really nice, if the module could support gif tunnel interfaces,
in addition to gre tunnel interfaces ;)

cheers,
Sebastian

FreeBSD VLAN support appears to be broken

Currently the vlan support for FreeBSD appears to be broken when going to instantiate the standard interface class for two reasons.

1. How the values array is treated.

In lib/puppet/parser/functions/get_freebsd_rc_conf_shellconfig.rb line 12:

 c[:address] = config["values"] if config["values"]

And in lib/puppet_x/bsd/rc_conf.rb the address array is explicitly treated as an array of addresses and process_addresses() is called on each of the array items, which includes vlan id and vlandev values.

This results in the following error:

Error: addr is vlan 1 of class String: Invalid IP "vlan 1" at /etc/puppet/modules/bsd/manifests/network/interface.pp:93 on node xxxxxxxxx
/var/lib/puppet/lib/puppet_x/bsd/rc_conf.rb:189:in `rescue in block in process_addresses'
/var/lib/puppet/lib/puppet_x/bsd/rc_conf.rb:174:in `block in process_addresses'
/var/lib/puppet/lib/puppet_x/bsd/rc_conf.rb:170:in `each'
/var/lib/puppet/lib/puppet_x/bsd/rc_conf.rb:170:in `process_addresses'
/var/lib/puppet/lib/puppet_x/bsd/rc_conf.rb:127:in `load_hash'
/var/lib/puppet/lib/puppet_x/bsd/rc_conf.rb:16:in `initialize'
/etc/puppet/modules/bsd/lib/puppet/parser/functions/get_freebsd_rc_conf_shellconfig.rb:15:in `new'

A potential solution is to pass $vlan_values to options and $address to values in vlan.pp.

2. No cloned_interfaces in rc.conf

In order for the VLAN interface to function, there needs to be a cloned_interfaces line in rc.conf as per http://people.freebsd.org/~arved/vlan/vlan_en.html

For example:

cloned_interfaces="vlan101"
ifconfig_vlan101="inet 10.0.5.1/24 vlan 1 vlandev em0"

I imagine at least the first issue may affect other interface types, but I have not tested any of them yet.

trunk does not manage cloned_interfaces parameter

the following configuration:

 bsd::network::interface::trunk { 'lagg10':
    interface => [ 'vtnet1', 'vtnet2' ],
    address   => [ '10.0.0.1/24' ],
  }

creates /etc/rc.conf entry:

ifconfig_lagg10="inet 10.0.0.1/24 laggproto lacp laggport vtnet1 laggport vtnet2"

but doesn't set

cloned_interface=".. lagg10 .."

However, if I try to manage cloned_interface via puppet-bsd module:

 bsd::network::interface::cloned { 'lagg10':
    ensure => present,
  }

I get the following result:

Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: Bsd::Network::Interface::Cloned[lagg10] is already declared at (file: /etc/puppetlabs/code/environments/production/modules/mymodule/manifests/init.pp, line: 8); cannot redeclare (file: /etc/puppetlabs/code/environments/production/modules/bsd/manifests/network/interface.pp, line: 123) (file: /etc/puppetlabs/code/environments/production/modules/bsd/manifests/network/interface.pp, line: 123, column: 7) (file: /etc/puppetlabs/code/environments/production/modules/bsd/manifests/network/interface/trunk.pp, line: 41) on node XXX

I suppose that * bsd::network::interface::trunk* should manage cloned_interfase as well

Document setting the MTU

There is currently no documentation for setting the MTU of an interface. Fix bugs if necessary.

gre interfaces does not appear to work on freebsd 11.1

Hi,

Using puppet4 it does not seem to work when using gre interfaces;

For example I have this code in my node manifest :

bsd::network::interface { 'gre2':
ensure => 'up',
description => "Tunnel interface ${hostname} to XXX",
parents => [ 'vtnet0' ],
raw_values => [ "${tunneladdress_gre2} netmask 255.255.255.252 tunnel ${ipaddresses_v4} ${tunnel_destination_gre2} up" ],
}

If the cloned_interfaces= already exists in rc.conf it doesn't do anything. If the gre2 interface is not available there yet, it will get added. The code also creates gre2, but there is no rc.conf information for it, so the interface remains empty..

How can I investigate what is going on and see what I am doing wrong? :-)

Thanks for all your hard work though, I do really appreciate it and I am leveraging it more and more!

Should support commands

hostname.if(5) allows for commands to be run as part of the interface configuration. We should support this as part of the interface management.

Cloned interfaces on FreeBSD

We're currently handling cloned interfaces in types we manage, but other interfaces like lo would be useful. To make this more generic, perhaps a fact for the platforms cloned interfaces and then a check to determine when we need to manage the rc.conf entry would be good.

Removing pseudo interfaces raises error in puppet

Once the interface has been delete, ifconfig vlan0 for example will raise an error in puppet since the command exits a non-zero status. We should capture the exit status to avoid raising it to puppet, while still being able to use the mechanism to determine if an interface exists.

Error: Failed to apply catalog: no parameter named 'value'

Hi,

With the below config, I'm getting an error that I cannot figure out
`package { 'ipaddress':
ensure => 'present',
provider => 'gem',
}

class { 'bsd::network':
v4gateway => '1.2.3.4'
}`

The error:
puppet agent --test --noop Info: Using configured environment 'production' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Retrieving locales Info: Loading facts Warning: Found multiple default providers for sysctl: parsed, augeas; using parsed Error: Failed to apply catalog: no parameter named 'value'

The puppet node is an OpenBSD 6.3 amd64 bare-metal with ruby-2.4.3p0 and ipaddress version 0.8.3.

Can this issue be fixed?

Alias IP addresses and routes on other than bsd::network::interface interfaces

Hi,

i need to create alias IP addresses on carp interfaces, as well as add some static routes to hostname.carpXXX files.

Looking at the code in manifests/network/interface/carp.pp I see only 'address' as paramter.
address is usually the main IP address given as a string, but I tried to give it an array of multiple addresses, which it actually takes, but the outcome is:

cat /etc/hostname.carp100
inet 172.16.0.5 255.255.255.0 NONE inet alias 172.16.0.55 255.255.255.0 NONE vhid 4 carpdev vlan100
up

sh /etc/netstart carp100
ifconfig: inet: bad value

haven't tried, but looking at the code, it seems that other interface configuration i.e. vlan will face the same issue.

how about adding 'values' parameter, an array, to at least vlan, carp and trunk interfaces, that can contain statements for alias IP addresses and route entries?

Those 'values' then to be merged into the value given to the values parameter of bsd::network::interface before that gets called, usually at the end?

Sebastian

Should support kernel module load state

Loading an unloading modules, both at boot time and during run seems like something this module could handle for the variety of BSD situations. I'm not aware of a module interface that handles this work, and I will soon have a need.

Refresh should move to the bsd_interface provider.

A new provider for each platform should inherit from the parrent bsd_interface provider, but implement each own #refresh method to avoid exec-ing. This will clean up some of the code and allow a notify or subscribe on an interface. This should end up just doing the correct thing.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.