search

ffnord / ffnord-puppet-gateway

Deploy and manage your Freifunk community gateway, mostly compatible with Gluon.
15 stars 13 forks source link

Add options peer_limit and use_blacklist #93

Closed wusel42 closed 9 years ago

wusel42 commented 9 years ago

Split backbone (other gateways) and peers; adding an option to add a limit to the fastd.conf for the peers. Adding another option to use the "blacklist feature", i. e. have a list of unwanted peers, anyone else may connect (see https://github.com/ffruhr/fastdbl).

do9xe commented 9 years ago

I'd like to sse this explained a bit better. If there are some unwanted keys, then you can just remove them from the peer repo. Please explain, why you would want such an addon, when you could simply remove the key.

ohrensessel commented 9 years ago

this is absolutely wanted. please do not take my comments as rejection of your idea, but as hints to improve it.

the aim of the puppet script is to be as complete as possible, so that config adaptions after puppet has been run are not necessary. that's why I proposed having a puppet solution where everything in regard to the blacklist json file is set up (like pulling the file from a remote location via cron).

wusel42 commented 9 years ago

Improvement (well, fixing the actual bugs ;)) done. Agreeing on the approach for completeness; I want to write a gwXX.pp or bgpX.pp, fire puppet and have a working gateway/supernode (definition below) that suits our needs. If I need to run additional scripts after each puppet run, something is broken beyond repair, IMO. (Gateway: runs fastd, connects to other gateways via (VPN-) mesh, anything else is routed(!) to a Supernode. Supernode: talks to internal (iBGP) and external (eBGP; IC-VPN, local or remote IP termination, ...) entities, handles IP (v4 & v6) exit; does not participate directly in the local meshes.)

I'm unsure with this process though. As my new commits do show up in this thread, do I need to create a new pull request (for bbff9b7, f19770f)?

sargon commented 9 years ago

When introducing a new feature it is polite not to make them the default, hence creating files directly in the base class is the opposite of that. Instead introduce an additional class which can be included iff the feature is activated. In case of peer limits or alike features, which only set a value in some already existing configuration file your realization is fine.

Furthermore I see some values in your blacklist template, I am not familiar with this feature of fastd, but what I am certain of is that these values seem to be kind of community specific, and that is nothing we are going to merge. Like ohrensessel mentioned above the way we handle those thinks are either a way to list values in the manifest or have an vcs (prefered git) repository which is cloned and pull periodically (via cron).

When creating file resources, do not use templates, unless you have some template work to do. Otherwise use the files directory and the source attribute.

We are currently not supporting the profiling pattern with this module. This module is for setting up a full featured routing machine for a mesh network. Everything else is maybe going to happen after the 1.0 release. Also we do not support the use of puppet masters, so the requirement to run some extra command after an puppet apply is a valid workaround for task that may kick you from your machine or in worst case lock you out completely.

wusel42 commented 9 years ago

I hereby withdraw the pull request. It's forked, if you find something useful, feel free to grab and adopt, it seems the targets to achieve are incompatible for now.