enable multiple fastd instances with different interface ids

[rubo77]

• the new standard is MTU 1280
• added $mesh_interface to ffnord::fastd
• moved old MTU 1426 into example in the README.md as second fastd instances called ${mesh_code}-old

[rubo77]

You can test this with the branch uses the branch https://github.com/rubo77/ffnord-example/commits/multiple_fastd

[do9xe]

This looks pretty good to me, but as this is not automaticly mergeable, i would need to check the "why" first. If i found why, I'll tell you to resolf the conflicts. I am eager to merge this. Any other oppinions?

[do9xe]

Also: can you please stagg the commits into two or three?

[rubo77]

I merged all commits into one. You can still see the old single commits here: https://github.com/rubo77/ffnord-puppet-gateway/tree/multi_fastd_dev

[rubo77]

Bevor man diese änderung auf einem Gateway ausrollt muss man natürlich nun dort einiges anpassen:

• Externe Firewalls müssen Port 11280 durchlassen
• Nagios muss nun nach "fastd_${mesh_interface}" statt "fastd_${mesh_code}" checken
• ... bitte weitere todos hier ergänzen

[ohrensessel]

bitte die von dir genannten Punkte noch hier im PR ergänzen, da dieser sonst nicht nutzbar ist.

edit: der sinn des puppet-scripts besteht ja darin, dass keine manuellen eingriffe mehr auf ner maschine nötig sind nach nem run. von daher sollten diese dinge integriert werden, sodass dies der fall ist.

[do9xe]

Thanks for your work. I talked with @ohrensessel and it would be really awesome if you could provide:

• an example for a gateway.pp with two fastd-instances definded (for me its a bit unclear how to use it)
• some enhancements to the scripts that add a firewall rule and everything else needed automaticly, because it must not be necessary to edit a server manually by hand. Everything with the nagios on external servers has nothing to do with this script.

[rubo77]

I think the firewall can be done within this PR https://github.com/ffnord/ffnord-puppet-gateway/pull/118

I already added the example in the README.md what else would be needed?

[ohrensessel]

no, it cannot. PR #118 just updates the firewall framework. each module has to add a rule for the ports it needs by defining ffnord::firewall::service with the appropriate parameters (see https://github.com/ffnord/ffnord-puppet-gateway/blob/master/manifests/fastd.pp#L55-L59)

[rubo77]

Then everything should be ok already: https://github.com/ffnord/ffnord-puppet-gateway/pull/120/files#diff-e83e93e7402ec3932435863e37a7b834R59 Each fastd instance gets his own $mesh_interface so there is one firewall rule for each.

the first instance (1280) is defined in init.pp and the old (1426) in the example in README.md

[rubo77]

If you still want to run a gateway with only the 1426MTU then you would have to define this in your manifest. If you don't choose an MTU the default will be 1280 now.

[do9xe]

As everything is clear now I am going to merge this. Thank you.

[ohrensessel]

sorry, but I still have some open points.

• why is there fastd_secret, fastd_port and fastd_peers_git in ffnord::mesh? it seems a little inconsistent if fastd is now specified at multiple locations.
• why is there mesh_mac and vpn_mac in ffnord::fastd? at least mesh_mac shouldn't be there as this is a value belonging to ffnord::mesh.
• I don't like it that ffnord::fastd doesn't have to be defined within ffnord::mesh. each ffnord::fastd belongs exactly to one ffnord::mesh, so this relationsship is enforced by the mesh_code. would be much nicer if ffnord::mesh would have ffnord::fast as a child or how one should call that.
• I don't like the possibility to name the vpn interface. it would be better to have a fixed naming scheme, like vpn so that it is easy to catch all interfaces within monitoring or firewall rules.