Adoptable Cookbooks List

Looking for a cookbook to adopt? You can now see a list of cookbooks available for adoption!
List of Adoptable Cookbooks

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

Select Badges

Select Supported Platforms

Select Status

RSS

shorewall (1) Versions 0.0.1

Configures iptables with Shorewall

Policyfile
Berkshelf
Knife
cookbook 'shorewall', '~> 0.0.1', :supermarket
cookbook 'shorewall', '~> 0.0.1'
knife supermarket install shorewall
knife supermarket download shorewall
README
Dependencies
Quality 17%

Description

Shorewall is a rather comprehensive and easy-to-use abstraction layer on top of
iptables.

Requirements

This cookbook currently uses the yumrepo module to install the EPEL
repository, and is therefore CentOS-specific.

The library functions anticipate a network topology in which a cluster of
servers have interconnects over a "private" network which is sufficiently
insecure that a firewall is appropriate to control connections from that
subnet. (This particularly applies to services such as memcached which expect
security to handled at a different layer). However, the module is expected to
remain useful in other scenarios as well.

Capabilities

Creates pretty Shorewall configuration files intended to be aesthetically
comparable to hand-written ones.

The following is a typical example of output (in this case, for a rules file):

#
# Shorewall version 4 - Rules File
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
############################################################################################################################
#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK
#                                                       PORT    PORT(S)         DEST            LIMIT           GROUP
#SECTION ESTABLISHED
#SECTION RELATED
SECTION NEW

# Allow all from VM host
ACCEPT          net:10.0.2.2    fw              -       -       -               -               -               -       -

# Incoming SSH to firewall
ACCEPT          all             fw              tcp     22      -               -               -               -       -

# Allow database load-balancer db1.vguest access to repmgr monitor
ACCEPT          lan:192.168.123.10 \
                                fw              tcp     5480    -               -               -               -       -

Note how line continuations are added as necessary to keep column alignment in place.

Usage

Typical usage from another module is expected to look like the following:

add_shorewall_rules(
  match_nodes=[
    ['recipes:tippr_db\:\:haproxy', { :name => 'database load-balancer' }],
    ['roles:monitoring', { :name => 'monitoring server' }]
  ],
  rules={
    :description => proc { |data| "Allow #{data[:match][:name]} #{data[:node].name} access to repmgr monitor" },
    :action => :ACCEPT,
    :source => proc { |data| "lan:#{data[:local_address]}" },
    :dest => :fw,
    :proto => :tcp,
    :dest_port => 5480
  }
)

...in the above case, we're using the add_shorewall_rules helper to add an
ACCEPT rule for each host which matches either the tippr_db::haproxy recipe
or the monitoring role (with different comments depending on which role
matched). If a single host matches twice, only a single rule (for each of its
internal IP addresses) is added.

Notably, any of the values in the rules hash can be a block, in which case it
is executed with an argument containing both the match metadata passed to the
match_nodes argument and the matched node retrieved by the search operation.

Alternately, an explicit rule (or policy) can be added as follows:

# Give ALL hosts in lan zone access to logstash
node.override[:shorewall][:rules] << {
  :description => "Access to logstash web server",
  :action => :ACCEPT,
  :source => :lan,
  :dest => :fw,
  :proto => :tcp,
  :dest_port => 9292
}

Again: Only address matching one of the networks defined in
shorewall/private_ranges will be added by the add_shorewall_rules helper.

Attributes

Important: Many of these are defined at the override level rather than the
default level. This is done such that node[:shorewall][:zones] << { ... }
works as you'd expect.

  • shorewall/default_interface_settings - Default settings to be used in filling out the interfaces file. May be overwritten on a per-interface basis.
  • shorewall/enabled - Boolean (also accepts string versions of true/false); whether we actually start the firewall after configuring it.
  • shorewall/private_ranges - IP address ranges considered eligible as private interconnect addresses.
  • shorewall/zone_hosts/ZONE - if this starts with search:, the remainder is used as a search expression to identify hosts which should be considered members of this zone (when populating the shorewall hosts file). Otherwise, it can be a CIDR address (as 192.168.0.0/16 or 0.0.0.0/0) to refer to a subnet.
  • shorewall/zone_interfaces/ZONE - maps from a shorewall zone name to the Ethernet interface serving that zone. If multiple zones are mapped to the same interface, then that interface will be distinguished via the shorewall hosts file.
  • shorewall/rules, shorewall/policy, shorewall/hosts, shorewall/interfaces all correspond directly to the relevant upstream configuration files.

For more details, see the attributes/default.rb file.

Limitations

Patches to address any of these items would be gratefully accepted.

  • Includes a hardcoded, non-configurable versions of the shorewall.conf file.
  • Searches retrieve far more information (entire nodes) than is actually needed.
  • Support for non-CentOS targets should be both worthwhile and straightforward.
  • Not all of shorewall's configuration is mapped.
  • No thought has been given to IPv6 support.

Dependent cookbooks

yumrepo >= 0.0.0

Contingent cookbooks

There are no cookbooks that are contingent upon this one.

Collaborator Number Metric
            

0.0.1 failed this metric

Failure: Cookbook has 0 collaborators. A cookbook must have at least 2 collaborators to pass this metric.

Contributing File Metric
            

0.0.1 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must contain a CONTRIBUTING.md file

Foodcritic Metric
            

0.0.1 failed this metric

FC064: Ensure issues_url is set in metadata: shorewall/metadata.rb:1
FC065: Ensure source_url is set in metadata: shorewall/metadata.rb:1
FC066: Ensure chef_version is set in metadata: shorewall/metadata.rb:1
FC069: Ensure standardized license defined in metadata: shorewall/metadata.rb:1
FC072: Metadata should not contain "attribute" keyword: shorewall/metadata.rb:1
Run with Foodcritic Version 16.3.0 with tags metadata,correctness ~FC031 ~FC045 and failure tags any

No Binaries Metric
            

0.0.1 passed this metric

Testing File Metric
            

0.0.1 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must contain a TESTING.md file

Version Tag Metric
            

0.0.1 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must include a tag that matches this cookbook version number