Building Shorewall from Git

Tom Eastep

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

2020/06/01


Note

This information is provided primarily for Shorewall developers. Users are expected to install from pre-built tarballs or packages. In addition to the below, it is also suggested to read the README file located in the root directory of the tools repository.

Git Taxonomy

The Shorewall Git tree at Gitlab serves as the master repository for Shorewall 4.4 and later versions. It is not possible to simply export a directory from Git and run the install.sh script in that directory. A build step is required to produce a directory that is suitable for the install.sh script to run in.

My local git repositories are:

code (clone of Code)

The development branch of each product is kept here.

  • Shorewall-core.

  • Shorewall

  • Shorewall6

  • Shorewall-lite

  • Shorewall6-lite

  • Shorewall-init

There are also several other directories which are described in the following sub-sections.

code/docs

The stable release XML documents. Depending on the point in the release cycle, these documents may also apply to the current development version.

release (Clone of Release)

Added in Shorewall 4.4.22, this directory contains the files that contain release-dependent information (change.txt, releasenotes.txt, .spec files, etc). This is actually a symbolic link to ../release which has its own Git repository.

testing (Clone of Testing)

This directory contains the regression library files.

tools (Clone of Tools)

This is where the release and build tools are kept. There are four subordinate directories:

tools/build

Tools for building and uploading new releases.

tools/files

Files that are used during the release process. The license and readme files are also kept there.

tools/testing

Tools for testing.

tools/web

Tools for publishing web content

web (Clone of Web)

The files from the web site that are maintained in HTML format. are kept in this directory.

Build Tools

As described above, the build tools are kept in tools/build. They are described in the following sections.

setversion

The setversion script updates the version number in a directory. The script is run with the current working directory being release.

setversion version

The version may either be a minor version or a patch version.

build45, build46, and build

These are the scripts that respectively build Shorewall 4.5, Shorewall 4.6 and Shorewall 5.[012] packages from Git. Build is actually a symlink to the current build script.

The scripts copy content from Git using the git archive command. They then use that content to build the packages. In addition to the usual Gnu utilities, the following software is required:

rpmbuild

Required to build the RPM packages.

xsltproc (libxslt)

Required to convert the XML documents to other formats.

Docbook XSL Stylesheets

Required to convert the XML documents to other formats.

Perl

Required to massage some of the config files.

xmlto

Required to convert the XML manpages to manpages. Be sure that you have a recent version; I use 0.0.25.

You should ensure that you have the latest scripts. The scripts change periodically as we move through the release cycles.

The scripts may need to be modified to fit your particular environment. There are a number of variables that are set near the top of the file:

STYLESHEET

Must point to the XHTML docbook.xsl stylesheet from your Docbook XSL Stylesheets installation.

LOGDIR

Directory where you want the build log placed. Defaults to the current working directory.

RPMDIR

Points to your RPM directory .

DIR

Directory where you want the release to be built. Defaults to the current working directory.

GIT

Shorewall GIT repository.

The scripts assume that there will be a separate build directory per major release. Each build directory should contain the empty file shorewall-pkg.config; that file is no longer used but has been retained just as a guard against initiating a build in an unintended directory. To build a release, you cd to the appropriate directory and run the build script.

The general form of the build command is:

build[xx] [ -options ] release [ prior release ]

where

options

are one or more of the following. If no options are given then all options are assumed

t

build tar files

r

build RPMs

c

Build the shorewall-core package.

i

Build the shorewall-init package.

l

Build the shorewall-lite package.

6

Build the shorewall6 package.

L

Build the shorewall6-lite package.

h

Build the html document package.

s

Build the shorewall package.

x

Build the xml document package.

release

The release version to build. Must match the version in the associated Git path.

prior release

The release to be used to generate patch files.

Example 1 - Build Shorewall 4.5.7 and generate patches against 4.5.6:

build45 4.5.7 4.5.6

Example 2 - Build Shorewall 4.5.7.1 Shorewall-core and generate patches against 4.5.7:

build45 -trc 4.5.7.1 4.5.7

upload

This script is used to upload a release to https://shorewall.org. The command is run in the build directory for the minor release of the product.

upload [ -products ] release

where

products

specifies the products to upload. If not given, all products are uploaded. This option is generally given only when uploading a patch release.

c

Upload the shorewall-core package.

l

Upload the shorewall-lite package.

i

Upload the shorewall-init package.

s

Upload the shorewall package.

6

Upload the shorewall6 package.

L

Upload the shorewall6-lite package.

release

The version number of the release to upload.

Example 1 - Upload release 4.3.7:

upload 4.3.7

Example 2 - Upload shorewall-core-4.3.7.3:

upload -c 4.3.7.3

install.sh files

Each product includes an install script (install.sh) that may be used to install the product on a machine or into a directory.

By default, the scripts install the corresponding product into "/'; you can direct them to install into an empty existing directory by setting an environmental variable:

  • DESTDIR (release 4.4.10 and later)

  • PREFIX (all releases)

There are a number of other environmental variables that you can set to cause the directory to be populated for a particular target environment:

  • DEBIAN - Debian-based systems (Debian, Ubuntu, etc.)

  • SUSE - SEL and OpenSuSE

  • REDHAT - RHEL, CentOS, Foobar, etc.

  • MAC - Apple MacIntosh (Shorewall-core, Shorewall and Shorewall6 packages only)

  • CYGWIN - Cygwin under Windows (Shorewall-core, Shorewall and Shorewall6 packages only)

  • OPENWRT - OpenWRT (Shorewall-core, Shorewall-lite, Shorewall6-lite and Shorewall-init only)

See the installation article for additional information

Documentation


Frequently Used Articles

- FAQs - Manpages - Configuration File Basics - Beginner Documentation - Troubleshooting

Shorewall 4.4/4.5/4.6 Documentation

Shorewall 4.0/4.2 Documentation


Shorewall 5.0/5.1/5.2 HOWTOs and Other Articles

- 6to4 and 6in4 Tunnels - Accounting - Actions - Aliased (virtual) Interfaces (e.g., eth0:0) - Anatomy of Shorewall - Anti-Spoofing Measures - AUDIT Target support - Bandwidth Control - Blacklisting/Whitelisting - Bridge/Firewall - Building Shorewall from GIT - Commands - Compiled Programs - Configuration File Basics - DHCP - DNAT - Docker - Dynamic Zones - ECN Disabling by host or subnet - Events - Extension Scripts - Fallback/Uninstall - FAQs - Features - Fool's Firewall - Forwarding Traffic on the Same Interface - FTP and Shorewall - Helpers/Helper Modules - Installation/Upgrade - IPP2P - IPSEC - Ipsets - IPv6 Support - ISO 3661 Country Codes - Kazaa Filtering - Kernel Configuration - KVM (Kernel-mode Virtual Machine) - Limiting Connection Rates - Linux Containers (LXC) - Linux-vserver - Logging - Macros - MAC Verification - Manpages - Manual Chains - Masquerading - Multiple Internet Connections from a Single Firewall - Multiple Zones Through One Interface - My Shorewall Configuration - Netfilter Overview - Network Mapping - No firewalling of traffic between bridge port - One-to-one NAT - Operating Shorewall - OpenVPN - OpenVZ - Packet Marking - Packet Processing in a Shorewall-based Firewall - 'Ping' Management - Port Forwarding - Port Information - Port Knocking (deprecated) - Port Knocking, Auto Blacklisting and Other Uses of the 'Recent Match' - PPTP - Proxy ARP - QuickStart Guides - Release Model - Requirements - Routing and Shorewall - Routing on One Interface - Samba - Shared Shorewall/Shorewall6 Configuration - Shorewall Events - Shorewall Init - Shorewall Lite - Shorewall on a Laptop - Shorewall Perl - Shorewall Setup Guide - SMB - SNAT - Split DNS the Easy Way - Squid with Shorewall - Starting/stopping the Firewall - Static (one-to-one) NAT - Support - Tips and Hints - Traffic Shaping/QOS - Simple - Traffic Shaping/QOS - Complex - Transparent Proxy - UPnP - Upgrade Issues - Upgrading to Shorewall 4.4 (Upgrading Debian Lenny to Squeeze) - VPN - VPN Passthrough - White List Creation - Xen - Shorewall in a Bridged Xen DomU - Xen - Shorewall in Routed Xen Dom0

Top of Page