|
GNUnet
GNU’s decentralized anonymous and censorship-resistant P2P framework. |
|
||
|
GNUnet
GNU’s decentralized anonymous and censorship-resistant P2P framework. |
|
||
First, in addition to the GNUnet sources you must download the latest version of libextractor and install that library. libextractor has itself various mandatory and optional dependencies. Please check the dependency list, both GNUnet and libextractor contain a file README.debian that lists the current package dependencies for Debian. Note that in addition to satisfying the dependencies, you might have to make sure that development headers for the various libraries are also installed. There maybe files for other distributions, or you might be able to find equivalent packages for your distribution. If you are root and cannot find binary packages, you should install GNUnet and libextractor to /usr/local and run gnunetd as a special administrative user gnunet. For that, change $HOME in the instructions below to /usr/local. The instructions below work when installing GNUnet as an ordinary user on most GNU/Linux systems. Installing libextractor should be as simple as:
$ ./configure --prefix=$HOME $ make # make install
For GNUnet, you should again check the dependency list. Now compile and install GNUnet using:
$ ./configure --prefix=$HOME --with-extractor=$HOME $ make # make install
Finally, you probably want to compile gnunet-gtk:
$ ./configure --prefix=$HOME --with-extractor=$HOME --with-gnunet=$HOME $ make # make install
If you are updating from a version from the 0.7.x series, you should (after stopping gnunetd) run:
# gnunet-update
This should trigger all necessary changes. Note that you will also have to run gnunet-update after certain changes to the gnunetd.conf configuration file. gnunetd will immediately exit with an error message if gnunet-update must be run.
If you are using GNUnet for the first time (or if you deleted all of your old files) you will probably want to run gnunet-setup at this point. The setup tool supports various styles of user interfaces. Invoke gnunet-setup without arguments to see the various styles supported on your platform. You should run gnunet-setup with the -d option in order to configure gnunetd. Unless you specify a different location with the -c option, the gnunetd configuration will be stored in /etc/gnunetd.conf. In order to enable gnunet-setup to edit that file, you should run it as user root:
# gnunet-setup -d wizard-gtk
Using one of the wizards should allow a quick initial configuration.
After finishing the configuration with gnunet-setup, you can test the installation using
# gnunet-transport-check
# gnunet-transport-check -p
The first command tests your local transports (basics), the second one connectivity to the rest of the peer-to-peer network (ping). If the test fails (i.e. gnunet-transport-check -p reports being able to connect to 0 peers), you should revisit your configuration, in particular your network setup. Again, after changing the configuration, you should always run gnunet-update to allow GNUnet to perform necessary internal updates. Note that it is normal for the NAT transport to be reported as not-working in some configurations. Once configuration is complete and gnunet-update is done, start the server using:
# gnunetd -d
The "-d" option causes gnunetd to print all errors to the console and prevents gnunetd from detaching from the console. If you get any errors, you may have to edit the configuration file:
# gnunet-setup -d gconfig
Some errors maybe related to the specific applications that are being used, so consult the documentation there. Use the log-files and the tools described below to diagnose problems. You may also want to increase the verbosity of the logging using the parameter "-L DEBUG". Read the man pages for additional information about command line options.
Once everything works and you get no error messages, press "CTRL-C" to abort gnunetd and restart it without the "-d" option. Without the option, gnunetd will detach from the terminal and write errors into the logfile.
If you want to automatically start GNUnet each time your machine boots contrib/initgnunet contains an example script to start the server as user gnunet with a configuation in /etc/gnunet.conf. If you installed a binary package, the installer probably already put the start-script into "/etc/init.d/gnunetd" or the appropriate location for your system. Still, even in that case, you may have to activate the script.
GNUnet typically requires the configuration of four basic layers. On the lowest layer, you need to configure the transport services that allow GNUnet to communicate with other peers. A simple example is the specification of the port number used by a TCP or UDP transport. The GNUnet core needs to know certain resource limitations, such as CPU load and bandwidth usage. Both the configuration of the transport services and the GNUnet core are described below. Additionally, the applications run on top of GNUnet may also require some configuration. Finally, the user interface(s) that are used to interact with gnunetd are configured in a per-user configuration file.
When a required configuration file is not present on startup, any GNUnet tool will attempt to create one by running gnunet-setup generate-defaults which dumps a copy of the default configuration file to ~/.gnunet/gnunet.conf. The option -c can be used for any GNUnet tool to specify an alternative location for the configuration file. GNUnet uses two different configuration files (with the same syntax but different options), one for the server (gnunetd) and another one for all of the clients. The rationale is that typcially the system administrator will setup gnunetd while ordinary users are executing the clients.
The default location for the configuration of gnunetd is /etc/gnunetd.conf. A few tools that help setup and diagnose the daemon (like gnunet-transport-check) also use this configuration file. A template for this configuration is in contrib/gnunetd.conf. You should use gnunet-setup -d to create or modify /etc/gnunetd.conf.
The GNUnet clients (like gnunet-insert or gnunet-gtk) use a different configuration file. All GNUnet clients expect this file to reside by default in $HOME/.gnunet/gnunet.conf. A template for this file is in contrib/gnunet.conf. You should use gnunet-setup (without the -d option) to create or modify ~/.gnunet/gnunet.conf. If the configuration file is not found, all GNUnet tools will use default options for the various settings.
All of the options described here refer to the server configuration. This section describes the most important options to setup gnunetd. The gnunet-setup tool gives more detailed descriptions for each option. If you are on dialup, look at HELLOEXPIRES and probably INTERFACES. If you are behind a NAT box, look at IP. If you are a frontier host that is accessible from a trusted LAN and connected to the Internet, have a look at TRUSTED, BLACKLIST and HELLOEXCHANGE.
The configuration of the SMTP transport layer is described here
With this option, you can specify to which TCP port the gnunet-clients should connect. It is also the choice of the port for gnunetd. While you can restrict access to this port using the NETWORK: TRUSTED option, you may also want to firewall this port. A different port must be used for the TCP and UDP peer-to-peer transport mechanism. The default value is 2087.
Use this option to specify which interface GNUnet should use to try to determine your IP. The interface is also used to determine the network load. Alternatively, you can use the IP option. If both an interface and an IP is specified, the IP option takes preference.
This option allows you to specify the advertised IP. If you do not specify anything, GNUnet will attempt to detect the IP. You really need this option if you are behind a NAT box. In that case, you have to specify the IP of the NAT box here (you can use a hostname, DNS is supported). For NAT boxes with changing IP, you may want to use Dynamic DNS.
With this option you can specfiy which addresses are trusted enough to connect to gnunetd via TCP as clients. The default is only the local host. If you are on a trusted LAN, you may want to specify the LAN network and netmask. You must use IPs, DNS lookup is not supported. The format of this option is IP/NETWORK;. Multiple entries (seperated and terminated by a semicolon) are permitted. The network can be specified using a bitmask (for example, /255.255.0.0) or the number of bits (for example, /16).
Under this option you specify which interfaces GNUnet is going to monitor to determine the load. If you have ethernet, the default is eth0. If you have a modem, try ppp0. In general, the command ifconfig (may not be in your path if you are logged in as a normal user, try /sbin/ifconfig) will show you the active devices.
Use basic bandwidth limitation? YES or NO. The basic method notes only gnunet traffic and can be used to specify simple maximum bandwidth usage of GNUnet. Choose the basic method if you don’t want other network traffic to interfere with GNUnets operation, but still wish to constrain gnunet’s bandwidth usage, or if you can’t reliably measure the maximum capabilities of your connection. The basic method might also be good when the used interface can transmit data to/from local network very fast compared to internet traffic (a condition that makes the advanced method unreliable).
The advanced bandwidth limitation measures total traffic over the chosen interface (including GNUnet traffic), and allows gnunetd to participate if the total traffic is low enough.
If you use basic bandwidth limitation, this option specifies the maximum GNUnet can use for its internal traffic. When using advanced limiting, use this option to specify your maximum upload speed (how many bytes per second your node can send). In that case, do not specify how much you want GNUnet to use, but use the maximum theoretically available. If you do not know your bandwidth, stick with the default of 50,000 bytes per second.
Same as MAXNETBPSUPTOTAL but for download speeds. Note that GNUnet can not control exactly how much data other nodes are sending to your machine (an approximate control is attempted, but malicious peers can always ignore the protocol and send more data). The upload limit is strictly enforced. If we are above our boundaries for the download limits, GNUnet will notify peers to reduce the amount of traffic until we are back inside the limits. Note that if you disable BASICLIMITING, GNUnet will sense if non-GNUnet traffic is going on and only use the specified amount of bandwidth if you are not using it otherwise.
Up to which CPU load will GNUnet process packets from other nodes. If the average CPU load goes over this value (like for the network, this includes other applications), GNUnet will start dropping packets and reduce the load. GNUnet may also do fewer of the expensive message-packing computations, trading bandwidth for CPU time. For example, if you are running an application that takes up all of your CPU power, GNUnet will pretty much not serve any other nodes (the node is considered busy). Only if the load is under the value specified here, GNUnet will serve other nodes. The default is 50, which should keep your hosts responsive enough while being more than sufficient for GNUnet on any modern machine.
Which port should the UDP transport layer use? If no value is specified, GNUnet will try to find a port in /etc/services. If you specify 0, this means that you do not want to open UDP for receiving messages (but, if you load the transport module, you can still send UDP traffic). The default port is 2086 as assigned to GNUnet by IANA. Since other peers will try to connect to this port, you should configure your firewall to let all traffic through. UDP is a stateless protocol, thus just allowing related traffic in a stateful firewall will not be sufficient.
If your node receives advertisements for nodes on virtual private networks, it should not even attempt to connect to those networks. You can use this option to specify a list of networks that are forbidden. gnunetd will then never attempt to communicate with these addresses. You will get an error if your own IP address is listed here. The format of this option is IP/NETWORK;. Multiple entries (seperated and terminated by a semicolon) are permitted. The network can be specified using a bitmask (for example, /255.255.0.0) or the number of bits (for example, /16).
This option specifies the maximum transfer unit, the maximum number of bytes that GNUnet will put in a UDP packet. This does not include the IP or UDP headers. Do not use more than your OS (and firewall) can support. Typcially, your want to avoid fragmentation and should choose network-MTU minus 28. You can determine your MTU using the ifconfig command. For ethernet, the network MTU should be 1500 octets, resulting in 1472 octets for the GNUnet MTU, which is also the default. Do not use values smaller than 1200.
Which port should the TCP transport layer use? If no value is specified, GNUnet will try to find a port in /etc/services. If you specify 0, this means that you do not want to open TCP for receiving messages (but, if you load the transport module, you can still initiate bi-directional TCP connections). Setting the TCP port to 0 is a common configuration for machines behind NAT boxes (these peers can then still initiate connections but other nodes will not attempt to connect). The default port is 2086 as assigned to GNUnet by IANA. Since other peers will try to connect to this port, you should configure your firewall to let all traffic through. Make sure that the port number you select here does not conflict with the client TCP port.
If your node receives advertisements for nodes on virtual private networks, it should not even attempt to connect to those networks. You can use this option to specify a list of networks that are forbidden. gnunetd will then never attempt to communicate with these addresses. You will get an error if your own IP address is listed here. The format of this option is IP/NETWORK;. Multiple entries (seperated and terminated by a semicolon) are permitted. The network can be specified using a bitmask (for example, /255.255.0.0) or the number of bits (for example, /16).
This option specifies the maximum transfer unit, the maximum number of bytes that GNUnet will put in a TCP packet. This does not include the IP or TCP headers. Typcially, your want to avoid fragmentation and should choose network-MTU minus 40. For ethernet, this would result in 1460 octets, which is also the default. Do not use less than 1200.
The NAT transport allows connections between machines using network-address translation (NAT) and "normal" peers with a globally unique IP address. Thus in practice, all GNUnet peers that support TCP should also load the NAT transport service, either since they need it to connect themselves or because it allows them to connect to other peers that require NAT support. NAT support requires loading ethe TCP transport service (IPv4 and/or IPv6). The only option for the NAT transport is "LIMITED". The default value "NO" is used for peers that either have a globally routed IP address (are not using NAT at all) or for peers that advertise the IP of the NAT box and where the NAT box forwards the TCP port to the NAT-ed IP in the LAN. Only if you can not configure your NAT box to forward the TCP port to your local machine you should set LIMITED to "YES".
In summary, there are three possibilities. If you use TCP and don′t use NAT on your local network, load the NAT transport anyway, set LIMITED to "NO". If you use NAT on your local network and have control over your NAT box, configure the NAT box to forward the TCP (and if possibly UDP) ports to the machine running gnunetd, also load the NAT transport and also set LIMITED to "NO". If you use NAT on your local network and do NOT have control over the NAT box, you must load the TCP and the NAT transport, set the TCP-PORT to "0" and LIMITED to "YES".
The last option is the worst since it limits whom you can connect to and thus limits your anonymity. If you are adventurous, you can supplement the last option with the SMTP transport, which is difficult to configure but will allow NAT-to-NAT communication.
Loglevel, how much should be logged? You can use NOTHING, FATAL, ERROR, WARNING, INFO, STATUS or DEBUG (which log more and more messages in this order). Default is WARNING. You can override this option at the commandline with the -L switch.
If gnunetd is not started with the -d option, it writes logging messages into this file (with -d all messages are written to the console). Read this mail if you are using logrotate.
In which file should gnunetd write the process-id of the server? If you run gnunetd as root, you may want to choose /var/run/gnunetd.pid. It’s not the default since gnunetd may not have write rights at that location.
In this directory GNUnet stores the key and last known Internet address of each known GNUnet node. Each file is about 600 bytes long (different transport protocols may have different address sizes). On startup, GNUnet downloads a list of initial hosts from the specified HOSTLISTURL. The files listed in the HOSTLISTURL are generated using:
$ cat /var/lib/GNUnet/data/hosts/* > hostlist
Running the command above and offering the generated hostlist file on a webserver is all it takes to run your own hostlist server. gnunetd will try to download peer advertisements from a (random) server specified in the HOSTLISTURL only if too few peers are connected for a longer period of time.
Once connected, GNUnet hosts exchange information about other hosts automatically. Thus except for the initial connection, there should be no pressing need to obtain a new list (except if a node was offline for a long time and the old list aged so much that it became useless). If hosts cannot be reached and the time that the key has been signed to be valid by the sender has expired, GNUnet deletes their identities from data/hosts/. Note that the trust information is kept "forever".
Whenever gnunetd needs to learn about an initial set of peers that it can connect to, it downloads a list of initial nodes to connect to via http. The URL to use is specified here. Multiple URLs can be specified separated by spaces.
Which applications should gnunetd support? Specify the name of the dynamic shared object (DSO) that implements the service in the gnunetd core here. Multiple DSOs can be specified, separated by spaces. You should always specify "advertising getoption" since these are rather fundamental applications. Add "stats" in order to be able to obtain statistics using gnunet-stats. Add "traffic" to see statistics about traffic (also used by anonymous file sharing for cover traffic estimates). Further additions depend on which specific applications you want to use. Possible choices include "fs chat tbench tracekit".
Which transport services should be used? Use space-separated list of the modules, for example "udp smtp tcp nat". If you want to use SMTP, please read the SMTP documentation for details.
The gnunet-setup tool also contains help texts for the various options.
These are options that should be specified in the per-user gnunet.conf configuration files. They apply to the various user interfaces for GNUnet.
With this option, you can specify to which host the GNUnet clients should connect by default. You can override the choice you make here with the -H option. The default, localhost should be fine.
With this option, you can specify to which TCP port the gnunet-clients should connect. It is also the choice of the port for gnunetd. While you can restrict access to this port using the NETWORK: TRUSTED option, you may also want to firewall this port. A different port must be used for the TCP and UDP peer-to-peer transport mechanism. The default value is 2087.
The gnunet-transport-check tool checks if a transport is configured correctly. By default the tool checks if the transport is at least able to send a message to its own address. This test is called the loopback mode. This mode is useful to check basic transport functionality when new transports are implemented or when GNUnet is ported to a new platform. By default, gnunet-transport-check tests all the transports that are currently specified in the configuration file.
With the option -p it is possible to run gnunet-transport-check in ping mode. In ping mode gnunet-transport-check performs an http download of the peer list specified in the configuration (HOSTLISTURL option) and attempts to connect to each of these peers (if a matching transport is configured). This way the tool is able to catch a variety of problems, including problems relating to NAT boxes, the firewall configuration and virtual private networks (VPNs). Note that it is perfectly normal that not all peers from the hostlist can be reached, but for both common transports (tcp and udp) at least a few should succeed. The default time that gnunet-transport-check waits for a reply is 15s. For a quick test the timeout can be reduced, for example to 500 ms with the option -T 500.
Note that you can not run gnunet-transport-check while gnunetd is running! You must stop gnunetd before testing transports. The output of gnunet-transport-check looks something like this:
$ gnunet-transport-check Testing transport(s) udp tcp Transport OK, 0ms for 1 messages of size 11 bytes. Transport OK, 0ms for 1 messages of size 11 bytes.
And for ping mode:
$ gnunet-transport-check -p Available transport(s): udp tcp ..................... 8 out of 21 peers contacted successfully (0 times transport unavailable).
The gnunet-peer-info tool displays the identities, trust earned and Internet addresses of all GNUnet peers that the local peer is aware of. The output looks like this:
$ gnunet-peer-info Peer \'CJ4J...\' with trust 31 and address \'31.79.24.1:2086 (TCP)\' Peer \'FA65...\' with trust 0 and address \'80.16.46.2:2086 (UDP)\'
gnunet-stats is a little tool that displays statistics. Unlike the other core tools, it uses the client configuration and only works if gnunetd is already running. gnunet-stats also only works if the stats module is loaded as an application. The numbers are for the current gnunetd process only. The output looks similar to the following example, but depends on which modules you have loaded and what your node has been doing so far.
$ gnunet-stats Uptime (seconds) : 47 % of allowed network load : 0 % of allowed cpu load : 0 # bytes of noise received : 0 # bytes received from clients : 8 # times outgoing msg sent (bandwidth ok) : 0 # times outgoing msg dropped (bandwidth stressed) : 0 # times incoming msg accepted (cpu ok) : 0 # times incoming msg dropped (cpu overloaded) : 0 # sessionkeys received : 0 # valid sessionkeys received : 0 # sessionkeys sent : 0 # connections shutdown : 0 # currently connected nodes : 0 # bytes noise sent : 0 # encrypted bytes sent : 0 # bytes decrypted : 0 # ping messages sent : 0 # ping messages received : 0 # pong messages sent : 0 # pong messages received : 0 # HELLO messages received from http server : 34 # HELLO messages received overall : 1 # valid HELLO messages received : 0 # HELLO messages forwarded from other peers : 0 # HELLO messages originated : 0
The number of connected hosts is the nummber of hosts that the local node is directly connected to (1 hop). The total number of hosts in the network must be larger or equal to this number.
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 Christian Grothoff. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
Translation engine based on i18nHTML (C) 2003, 2004, 2005, 2006, 2007 Christian Grothoff.