Installation — GNUnet documentation

# Installation

This guide is intended for those who want to install GNUnet from source. For instructions on how to install GNUnet as a binary package please refer to the official documentation of your operating system or package manager.

For understanding this guide properly it is important to know that there are two different ways of running GNUnet:

- the single-user setup

- the multi-user setup

The latter variant has a better security model and requires extra preparation before running make install and a different configuration. Beginners who want to quickly try out GNUnet can use the single-user setup.

## Dependencies

GNUnet needs few libraries and applications for being able to run and another few optional ones for using certain features. Preferably they should be installed with a package manager.

The mandatory libraries and applications are

- autoconf 2.59 or above (when building from git)

- automake 1.11.1 or above (when building from git)

- recutils 1.0 or above (when building from git)

- gettext

- glibc (read below, other libcs work)

- GnuTLS 3.2.12 or above, recommended to be linked against libunbound

- GNU make 4.0 or higher (other make implementations do work)

- iptables (on Linux systems)

- libtool 2.2 or above

- libltdl (part of libtool)

- libgcrypt 1.6 or above

- libidn2 or libidn

- libmicrohttpd 0.9.63 or above

- libunistring

- libjansson

- libjose (optional, for reclaimID)

- libgmp

- libcurl (ideally linked to GnuTLS) 7.35.0 or above

- Texinfo 5.2 or above (for building the documentation)

- Texlive 2012 or above (for building the documentation, and for gnunet-bcd)

- makeinfo 4.8 or above

- pkgconf (or pkg-config)

- zlib

Glibc is required for certain NSS features:

    One mechanism of integrating GNS with legacy applications via NSS is
    not available if this is disabled. But applications that don't use the
    glibc for NS resolution won't work anyway with this, so little is lost
    on *BSD systems.
    GNS via direct use or via the HTTP or DNS proxies is unaffected.

Other libcs should work, the resulting builds just don’t include the glibc NSS specific code. One example is the build against NetBSD’s libc as detailed in https://bugs.gnunet.org/view.php?id=5605.

In addition GNUnet needs at least one of these three databases (at the minimum sqlite3)

- sqlite + libsqlite 3.8 or above (the default, requires no further configuration)

- postgres + libpq

- mysql + libmysqlclient

These are the dependencies only required for certain features

- miniupnpc (for traversing NAT boxes more reliably)

- libnss

- libopus (for running the GNUnet conversation telephony application)

- libogg (for running the GNUnet conversation telephony application)

- gstreamer OR libpulse (for running the GNUnet conversation telephony application)

- bluez (for bluetooth support)

- libextractor (optional but highly recommended, read below)

- texi2mdoc (for automatic mdoc generation)

- perl5 for some utilities (which are not installed)

About libextractor being optional:

    While libextractor ("LE") is optional, it is recommended to build gnunet
    against it. If you install it later, you won't benefit from libextractor.
    If you are a distributor, we recommend to split LE into basis + plugins
    rather than making LE an option as an afterthought by the user.  LE
    itself is very small, but its dependency chain on first, second, third
    etc level can be big.  There is a small effect on privacy if your LE
    build differs from one which includes all plugins (plugins are build as
    shared objects): if users publish a directory with a mixture of file
    types (for example mpeg, jpeg, png, gif) the configuration of LE could
    leak which plugins are installed for which filetypes are not providing
    more details.  However, this leak is just a minor concern.

These are the test-suite requirements:

- python3.6 or higher

- gnunet (installation first)

- some core-utils: which(1), bc(1), curl(1), sed(1), awk(1), etc.

- a shell (very few Bash scripts, the majority are POSIX sh scripts)

These are runtime requirements:

- nss (the certutil binary, for gnunet-gns-proxy-setup-ca)

- openssl (openssl binary, for gnunet-gns-proxy-setup-ca)

## Getting the Source Code

You can either download the source code using git (you obviously need git installed) or as an archive.

Using git type

    $ git clone https://git.gnunet.org/gnunet.git

The release archive can be found at https://ftpmirror.gnu.org/gnu/gnunet/. You can find nightly builds at https://buildbot.gnunet.org/artifacts/. Extract it using a graphical archive tool or tar:

    tar xf gnunet-<VERSION> .tar.gz

In the next chapter we will assume that the source code is available in the home directory at ~/gnunet.

## Create user and groups for the system services

For single-user setup this section can be skipped

The multi-user setup means that there are system services, which are run once per machine as a dedicated system user (called gnunet) and user services which can be started by every user who wants to use GNUnet applications. The user services communicate with the system services over unix domain sockets. To gain permissions to read and write those sockets the users running GNUnet applications will need to be in the gnunet group. In addition the group gnunetdns may be needed (see below).

Create user gnunet who is member of the group gnunet (automatically created) and specify a home directory where the GNUnet services will store persistent data such as information about peers.

    $ sudo useradd --system --home-dir /var/lib/gnunet --create-home gnunet

Now add your own user to the gnunet group:

    $ sudo usermod -aG gnunet <user>

Create a group gnunetdns. This allows using setgid in a way that only the DNS service can run the gnunet-helper-dns binary. This is only needed if system-wide DNS interception will be used. For more information see Configuring system-wide DNS interception.

    $ sudo groupadd gnunetdns

## Preparing and Compiling the Source Code

For preparing the source code for compilation a bootstrap script and configure has to be run from the source code directory. When running configure, options can be specified to customize the compilation and installation process. For details execute:

    $ ./configure --help

The following example configures the installation prefix /usr/local and disables building the documentation

    $ cd ~/gnunet
    $ ./bootstrap
    $ ./configure --prefix=/usr/local --disable-documentation

After running the bootstrap script and configure successfully the source code can be compiled and the compiled binaries can be installed using:

    $ make
    $ make install

The latter command may need to be run as root (or with sudo) because some binaries need the suid bit set. Without that some features (e.g. the VPN service, system-wide DNS interception, NAT traversal using ICMP) will not work.

### NSS plugin (optional)

NOTE: The installation of the NSS plugin is only necessary if GNS resolution shall be used with legacy applications (that only support DNS) and if you cannot do not want to use the DNS2GNS service.

One important library is the GNS plugin for NSS (the name services switch) which allows using GNS (the GNU name system) in the normal DNS resolution process. Unfortunately NSS expects it in a specific location (probably `/lib`) which may differ from the installation prefix (see `--prefix` option in the previous section). This is why the plugin has to be installed manually.

Find the directory where nss plugins are installed on your system, e.g.:

    $ ls -l /lib/libnss_*
    /lib/libnss_mymachines.so.2
    /lib/libnss_resolve.so.2
    /lib/libnss_myhostname.so.2
    /lib/libnss_systemd.so.2

Copy the GNS NSS plugin to that directory:

    cp ~/gnunet/src/gns/nss/.libs/libnss_gns.so.2 /lib

### Installing the GNS Certificate Authority (Optional)

NOTE: Installing the GNS certificate authority is only necessary if GNS shall be used in a browser and if you cannot or do not want to use the DNS2GNS service.

The GNS Certificate authority can provide TLS certificates for GNS names while downloading webpages from legacy webservers. This allows browsers to use HTTPS in combinations with GNS name resolution.

To install it execute the GNS CA-setup script. So far Firefox and Chromium are supported.

    $ gnunet-gns-proxy-setup-ca

A local proxy server, that takes care of the name resolution and provides certificates on-the-fly needs to be started:

    $ /usr/lib/gnunet/libexec/gnunet-gns-proxy

Now GNS should work in browsers that are configured to use a SOCKS proxy on localhost:7777.

## Minimal configuration

GNUnet needs a configuration file to start (see Config file format). For the single-user setup an empty file is sufficient:

    $ touch ~/.config/gnunet.conf

For the multi-user setup we need an extra config file for the system services. The default location is `/etc/gnunet.conf`. The minimal content of that file which activates the system services roll is:

    [arm]
    START_SYSTEM_SERVICES = YES
    START_USER_SERVICES = NO

The config file for the user services (`~/.config/gnunet.conf`) needs the opposite configuration to activate the user services roll:

    [arm]
    START_SYSTEM_SERVICES = NO
    START_USER_SERVICES = YES