Firewall Builder Installation

• Installation of Firewall Builder 3.0
• rpm and deb repositories for stable and testing packages
• Installation of Firewall Builder 2.0 and 2.1
• Update for Gentoo installation instructions
• Installing Firewall Builder on Gentoo Linux
• Migration to Firewall Builder 2.0
• Great RPM search engine

Installation of Firewall Builder 3.0

Using pre-built binary RPMs

You need to download and install two RPMs: libfwbuilder-3.0.0-1.i386.rpm and fwbuilder-3.0.0-1.i386.rpm . To satisfy dependencies, you need the following packages installed on your system:

• libxml2 v2.4.10 or newer
• libxslt v1.0.7 o newer
• ucd-snmp or net-snmp
• openssl - always use latest version
• QT 4.3.x, 4.4.x Fwbuilder depends on QT 4.3 or 4.4, it will not work with 4.2

Pre-built binary RPMs for RedHat Enterprise Linux 5 (RHEL 5) and CentOS 5.2 and 5.3

CentOS 5.3 does not come with QT4 and third-party binary RPMs of QT v4.3.x and 4.4.x are hard to come by. CentOS 5.3 has QT4, but the version (4.2.1) is older than what is required for fwbuilder GUI. We distribute binary rpms of Firewall Builder 3.0 statically linked with QT 4.4.1 for these distributions. These rpms are posted in the downloads area on the SourceForge project site. These rpms have the same standard names libfwbuilder-3.0.7-1.i386.el5.rpm and fwbuilder-3.0.7-1.i386.el5.rpm for CentOS 5.2 and libfwbuilder-3.0.7-1.i386.el53.rpm and fwbuilder-3.0.7-1.i386.el53.rpm for CentOS 5.3. They have no dependency on QT rpms.

If fwbuilder statically linked with QT crashes on start on your CentOS system, check if you have the following font packages installed: bitmap-fonts or bitstream-vera-fonts. Either one should make fwbuilder work (but I am told bitstream-vera fonts look better). See bug report #2595205 on SourceForge for more details.

Note for rpm packagers: Unfortunately rpms for these two font packages do not provide any generalized capability so I can not add proper dependency to my fwbuilder rpms. Actually, QT rpms on systems like Fedora Linux do not have dependency on these font rpms either. If this dependency is ever added to QT rpms, I'll copy it to my statically linked fwbuilder rpms as well.

Installing FreeBSD ports

Firewall Builder consists of two ports: /usr/ports/security/libfwbuilder and /usr/ports/security/fwbuilder. Once both ports are updated (it usually takes couple of weeks to update ports after the package is released), just install the port as usual using portinstall or issuing "make install" in /usr/ports/security/fwbuilder

Installing Windows package

Doubleclick on the package file, then follow step by step instructions in installation wizard.

Installing Mac OS X package

Mac OS X package is distributed in the form of a disk image ( .dmg file). Doubleclick on the image to mount it, then drag Firewall Builder application to your Applications folder (or any other place).

Compiling from source

Install development versions of the packages listed above (e.g. install libxml2-devel in addition to libxml2 and so on), including development package for QT.

Note:

You may need to install packages elfutils-libelf and elfutils-libelf-devel (libelf on SuSE), otherwise libfwbuilder won't pick up net-snmp library even if it is installed

If you get errors that refer to missing autoconf macros while running autogen.sh for fwbuilder, check if your system has RPM gettext-devel You may need to add other "development" RPMs besides these, but I have found these two are often forgotten.

To compile from source, download source archives from SourceForge libfwbuilder-3.0.0.tar.gz and fwbuilder-3.0.0.tar.gz and unpack them somewhere. Then build as follows:

cd libfwbuilder-3.0.0
./autogen.sh
make
make install
      
cd /fwbuilder-3.0.0
./autogen.sh
make
make install
                

Script configure in both libfwbuilder and fwbuilder tries to find your QT4 installation in several more or less standard places. However, if you installed QT in a directory where it can not find it automatically, you can provide the path to it using --with-qtdir option to script autogen.sh. This looks as follows:

cd libfwbuilder-3.0.0
./autogen.sh --with-qtdir=/opt/qt4
make
make install
      
cd /fwbuilder-3.0.0
./autogen.sh --with-qtdir=/opt/qt4
make
make install
                

By default script configure assumes prefix="/usr/local" and installs libfwbuilder libraries in /usr/local/lib and binaries in /usr/local/bin. Make sure /usr/local/lib is added to your LD_LIBRARY_PATH environment variable or to the /etc/ld.so.conf configuration file, otherwise the program won't find dynamic libraries there. Likewise, /usr/local/bin needs to be in your PATH.

You can install libraries and binaries in a different place by specifying new prefix as follows:

./autogen.sh --prefix="/opt"
                

This will install libraries in /opt/lib and the program in /opt/bin

rpm and deb repositories for stable and testing packages

We now have repositories for rpm and deb packages, all packages are signed with GPG key (key ID PACKAGE-GPG-KEY-fwbuilder.asc id 0xEAEE08FE) . Two separate repositories are maintained for each package type: "stable" and "testing". Stable serves packages that have been oficially released, while testing serves nightly builds. Instructions how to set up yum and apt to access repositories can be found here.

Installation of Firewall Builder 2.0 and 2.1

Using pre-built binary RPMs

You need the following packages installed on your system:

• libxml2 v2.4.10 or newer
• libxslt v1.0.7 o newer
• ucd-snmp or net-snmp
• openssl - always use latest version
• QT 3.1.x, 3.2.x, 3.3.x

QT must be compiled with thread support

Installing FreeBSD ports

Firewall Builder consists of two ports: /usr/ports/security/libfwbuilder and /usr/ports/security/fwbuilder. Once both ports are updated (it usually takes couple of weeks to update ports after the package is released), just install the port as usual using portinstall or issuing "make install" in /usr/ports/security/fwbuilder

Installing Windows package

Doubleclick on the package file, then follow step by step instructions in installation wizard.

Installing Mac OS X package

Mac OS X package is distributed in the form of a disk image ( .dmg file). Doubleclick on the image to mount it, then drag Firewall Builder application to your Applications folder (or any other place).

Compiling from source

Install development versions of the packages listed above (e.g. install libxml2-devel in addition to libxml2 and so on), including development package for QT. Make sure environment variable QTDIR is set and points to a directory where QT is installed on your system. It should be the top-level directory of the QT installation, such as for example /usr/lib/qt-3.3. This is the directory in which QT puts its own "bin", "inlcude" directories when it is installed.

Note:

You may need to install packages elfutils-libelf and elfutils-libelf-devel (libelf on SuSE), otherwise libfwbuilder won't pick up net-snmp library even if it is installed

If you get errors that refer to missing autoconf macros while running autogen.sh for fwbuilder, check if your system has RPM ac-archive if you run RedHat 9.0, Fedora Core1/2, Mandrake or SuSE and gettext-devel if you are on Fedora Core 3. You may need to add other "development" RPMs besides these, but I have found these two are often forgotten.

To compile from source, download source archives from SourceForge libfwbuilder-2.0.0.tar.gz and fwbuilder-2.0.0.tar.gz and unpack them somewhere. Then build as follows:

cd libfwbuilder-2.0.0
./autogen.sh
make
make install
      
cd /fwbuilder-2.0.0
./autogen.sh
make
make install
                

By default API libraries are installed in /usr/local/lib and binaries in /usr/local/bin. Make sure /usr/local/lib is added to your LD_LIBRARY_PATH environment variable or to the /etc/ld.so.conf configuration file, otherwise the program won't find dynamic libraries there. Likewise, /usr/local/bin needs to be in your PATH.

You can install libraries and binaries in a different place by specifying a prefix as follows:

./autogen.sh --prefix="/opt"
                

This will install libraries in /opt/lib and the program in /opt/bin

Update for Gentoo installation instructions

Carsten Lohrke <carlo@gentoo.org> has sent this update to me:

Hello,
I read http://www.fwbuilder.org/guides/firewall_builder_installation.shtml and want to correct the information regarding the Gentoo installation a bit.

If the newer version is present you will need to use the ~x86 use flag (or the ~flag for your specific platform).

While very similar to a use flag, it's an arch(itecture) flag. A preceding ~ means, that the ebuild has testing status on the respective arch.
If a user wants to install the considered stable version, doing "emerge fwbuilder" compiles and installs the application. In case he wants the ~arch version,

ACCEPT_KEYWORDS="~x86" emerge fwbuilder

is not the correct way (anymore), deprecated and should not be used. Instead

    echo ~net-libs/libfwbuilder-2.0.4 >> /etc/portage/package.keywords
    echo ~net-firewall/fwbuilder-2.0.4 >> /etc/portage/package.keywords

unmasks version 2.0.4 and possible ebuild revisions (e.g. fwbuilder-2.0.4-r1), while

    echo net-libs/libfwbuilder >> /etc/portage/package.keywords
    echo net-firewall/fwbuilder >> /etc/portage/package.keywords

unmasks all ~arch keyworded ebuilds. Afterwards the unmasked ebuilds can be emerged as usual.

Regards,
Carsten Lohrke

Installing Firewall Builder on Gentoo Linux

Bill Chmura (Bill at Explosivo.com) sent this short installation note to me:

Gentoo Installation

Gentoo provides e-build's for both fwbuilder and libfwbuilder in the portage system. Newer releases of Firewall Builder may be masked and not appear as the default installation.

To see which version portage will install, run the following commands:

emerge sync (if you have not recently)
emerge -pv fwbuilder

If the version listed is not the current version of Firewall Builder, check the net-firewall/fwbuilder directory of your portage tree. If the newer version is present you will need to use the ~x86 use flag (or the ~flag for your specific platform).

ACCEPT_KEYWORDS="~x86" emerge -pv fwbuilder

If the installation list looks good, you can install with the command:

ACCEPT_KEYWORDS="~x86" emerge fwbuilder

Note: The ~x86 represents a package in testing status for the x86 platform. Be aware that means the ebuild may not be perfect although the source code installed and compiled is not affected. If you are running a different architecture, you will need to substitute ~x86 with your platform. See Portage documentation for more information help with portage.

Migration to Firewall Builder 2.0

One of the new features in Firewall Builder 2.0 is that it does not create copies of the standard objects in user's data files. This allows us to expand standard objects in the subsequent releases and fix bugs in these objects. The old version used to copy them to the data file which means users worked with a "frozen" copies of these objects which could not be easily updated. New version maintains separation between object libraries and keeps Standard objects library read-only. When a data file is opened, the program merges objects from it with objects in the Standard objects library so the user could use both in groups and rules. When data file is saved, objects are split again.

If you ever edited a standard object in fwbuilder 1.1.x and used it in your rules, the new fwbuilder will detect the change when you open your data file. This happens because at that point two copies of the same object exist: one in the standard objects library shipped with fwbuilder 2.0 and another in your data file. Since you edited this object, these two copies are different and fwbuilder detects this situation as a conflict and presents you with a dialog asking you to make a choice as of which copy of the object you want to use. Note that a change in any attribute of an object triggers conflict, even change in the name or comment text. When such conflict is detected, a dialog that looks like this is shown:

Left panel in the dialog represents object found in the objects tree, while right panel shows properties of the same objects in the data file being opened. Click the button under the copy of the object you want to use.

We recommend to use objects from the standard objects library because these are going to be maintained in the future. If you want to make changes in a standard object, you can duplicate it into your own library using pop-up menu item "Duplicate" or Copy/Paste operation and then modify it. The copy is a new object which you can edit, it will not trigger conflict with the standard library object that you used to create it.

Note that if you choose to use your modified copy of the object, you will end up with the same modified object and will get a conflict next time you open the same data file. The best way to resolve this situation and get rid of the conflict is to create a copy of your modified object in the Users objects library and replace all its occurences in groups and rules with a copy. Use "Find" function to find all references to this object in the tree and in all rules.

Great RPM search engine

Grzegorz Paszka sent me an email with a URL for the interesting specialized search engine for RPMs: http://rpm.pbone.net. They index lots of the web and ftp sites that provide access to tons of RPMs; their search engine is flexible and has lots of options. Thanks to Grzegorz for the reference!