mirror of
https://github.com/PurpleI2P/i2pd_docs_en
synced 2025-02-10 05:44:13 +00:00
Fix grammar and and wording in user-guide.
This commit is contained in:
hugbubby
parent
ce46752b60
commit
b606e059d6
@ -1,17 +1,18 @@
|
||||
i2pd configuration
|
||||
==================
|
||||
|
||||
i2pd can be configured via command-line arguments and config files.
|
||||
Options are the same, for example, running i2pd with argument `--port=10123` and setting
|
||||
option `port = 10123` in config file will have same effect.
|
||||
i2pd can be configured via either command-line arguments or config files.
|
||||
Modifying `i2pd.conf` is just a way of passing command line arguments to i2pd at boot;
|
||||
for example, running i2pd with argument `--port=10123` and setting option `port = 10123` in config file will have
|
||||
the same effect.
|
||||
|
||||
There are two separate config files `i2pd.conf` and `tunnels.conf`. `i2pd.conf` is main configuration file, where
|
||||
you configure all options. `tunnels.conf` is I2P tunnel configuration file, where you configure I2P hidden services
|
||||
and client tunnels for you needs. `tunnels.conf` options are documented [here](tunnels.md).
|
||||
There are two separate config files: `i2pd.conf` and `tunnels.conf`. `i2pd.conf` is the main configuration file, where
|
||||
you configure all options. `tunnels.conf` is the tunnel configuration file, where you configure I2P hidden services
|
||||
and client tunnels. the `tunnels.conf` options are documented [here](tunnels.md).
|
||||
|
||||
INI-like, syntax is the following : <key> = <value>.
|
||||
Comments are "#", not ";" as you may expect. See [boost ticket](https://svn.boost.org/trac/boost/ticket/808)
|
||||
All command-line parameters are allowed as keys, but note for those which contains dot (.).
|
||||
`i2pd.conf` accets INI-like syntax, such as the following : <key> = <value>.
|
||||
Comments are "#", not ";" as you might expect. See [boost ticket](https://svn.boost.org/trac/boost/ticket/808)
|
||||
All command-line parameters are allowed as keys, but for those which contains dot (.), there is a special syntax.
|
||||
|
||||
For example:
|
||||
|
||||
@ -28,7 +29,7 @@ i2pd.conf:
|
||||
[sam]
|
||||
enabled = true
|
||||
|
||||
See also commented config with examples of all options in ``contrib/i2pd.conf``.
|
||||
You are also encouraged to see the commented config with examples of all options in ``contrib/i2pd.conf``.
|
||||
|
||||
Options specified on the command line take precedence over those in the config file.
|
||||
If you are upgrading your very old router (< 2.3.0) see also [this](config_opts_after_2.3.0.md) page.
|
||||
@ -229,6 +230,7 @@ exploratory.outbound.quantity | Exploratory outbound tunnels length. 3
|
||||
Local addressbook
|
||||
-----------------
|
||||
|
||||
There is also a special addressbook config file in working directory `addressbook/local.csv`.
|
||||
It is used to map long I2P destinations to short, human readable domain names. The syntax is csv.
|
||||
There is also a special addressbook config file in the working directory at `addressbook/local.csv`.
|
||||
It is used to map long I2P destinations to short, human readable domain names. The syntax is csv and
|
||||
it can be modified manually if the user wishes.
|
||||
|
||||
|
||||
@ -1,27 +1,27 @@
|
||||
Family configuration
|
||||
====================
|
||||
|
||||
Your might want to specify a family, your router belongs to.
|
||||
There are two possibilities: create new family or joining to existing.
|
||||
Your might want to specify a family your router belongs to.
|
||||
There are two ways to do this: create a new family or join to an existing one.
|
||||
|
||||
New family
|
||||
-----------
|
||||
|
||||
You must create family self-signed certificate and key.
|
||||
To create a new family, you must first create a family self-signed certificate and key.
|
||||
The only key type supported is prime256v1.
|
||||
Use the following list of commands:
|
||||
Use the following list of commands to do this through openssl:
|
||||
|
||||
openssl ecparam -name prime256v1 -genkey -out <your family name>.key
|
||||
openssl req -new -key <your family name>.key -out <your family name>.csr
|
||||
touch v3.ext
|
||||
openssl x509 -req -days 3650 -in <your family name>.csr -signkey <your family name>.key -out <your family name>.crt -extfile v3.ext
|
||||
|
||||
Specify <your family name>.family.i2p.net for CN (Common Name) when requested.
|
||||
Specify <your family name>.family.i2p.net for the CN (Common Name) when requested.
|
||||
|
||||
Once you are done with it place <your-family-name>.key and <your-family-name>.crt to <ip2d data>/family folder (for exmple ~/.i2pd/family).
|
||||
Once you are done generating it place <your-family-name>.key and <your-family-name>.crt in the <ip2d data>/family folder (for example ~/.i2pd/family).
|
||||
You should provide these two files to other members joining your family.
|
||||
If you want to register you family and let I2P network recognize it, create pull request for you .crt file into contrib/certificate/family.
|
||||
It will appear in i2pd and I2P next releases packages. Don't place .key file, it must be shared between you family members only.
|
||||
If you want to register your family and let the I2P network recognize it, create a pull request for your .crt file into contrib/certificate/family.
|
||||
Certificates added into the public repository this way will appear in i2pd and I2P next releases packages. Don't place .key file, it must be shared between you family members only.
|
||||
|
||||
How to join existing family
|
||||
---------------------------
|
||||
@ -31,6 +31,8 @@ Once you and that family agree to do it, they must give you .key and .crt file a
|
||||
Publish your family
|
||||
-------------------
|
||||
|
||||
Run i2pd with parameter 'family=<your-family-name>', make sure you have <your-family-name>.key and <your-family-name>.crt in your 'family' folder.
|
||||
Run i2pd with the parameters 'family=<your-family-name>', and make sure you have <your-family-name>.key and <your-family-name>.crt in your 'family' folder.
|
||||
If everything is set properly, you router.info will contain two new fields: 'family' and 'family.sig'.
|
||||
Otherwise your router will complain on startup with log messages starting with "Family:" prefix and severity 'warn' or 'error'.
|
||||
If not, your router will complain on startup with log messages starting with "Family:" prefix and severity 'warn' or 'error'.
|
||||
|
||||
TODO: List common errors
|
||||
|
||||
@ -4,9 +4,9 @@ Running i2pd
|
||||
Starting, stopping and reloading configuration
|
||||
----------------------------------------------
|
||||
|
||||
This chapter explains how to start and manage i2pd daemon under \*nix operation systems.
|
||||
This chapter explains how to start and manage the i2pd daemon under \*nix operation systems.
|
||||
|
||||
After you have built i2pd from source, just run a binary:
|
||||
After you have built i2pd from source, just run the binary:
|
||||
|
||||
./i2pd
|
||||
|
||||
@ -14,29 +14,29 @@ To display all available options:
|
||||
|
||||
./i2pd --help
|
||||
|
||||
i2pd can be controlled with signals. Process ID by default is written to file `~/.i2pd/i2pd.pid` or `/var/run/i2pd/i2pd.pid`.
|
||||
You can use `kill` utility to send signals like this:
|
||||
i2pd can be controlled with signals. The process ID by is written to the file `~/.i2pd/i2pd.pid` or
|
||||
`/var/run/i2pd/i2pd.pid` by default. You can use `kill` utility to send signals like this:
|
||||
|
||||
kill -INT $( cat /var/run/i2pd/i2pd.pid )
|
||||
|
||||
i2pd supports the following signals:
|
||||
|
||||
* INT - Graceful shutdown. i2pd will wait for 10 minutes and stop. Send second INT signal to shutdown i2pd immediately.
|
||||
* INT - Graceful shutdown. i2pd will wait for up to 10 minutes and stop. Send a second INT signal to shutdown i2pd immediately.
|
||||
* HUP - Reload configuration files.
|
||||
|
||||
|
||||
### systemd unit
|
||||
|
||||
Some Linux packages have a systemd control unit, so it is possible to manage i2pd with it.
|
||||
Some i2pd packages come with a systemd control unit, and for those that use systemd, it is possible to manage i2pd with it.
|
||||
|
||||
Start/stop i2pd:
|
||||
To start/stop i2pd:
|
||||
|
||||
sudo systemctl start i2pd.service
|
||||
sudo systemctl stop i2pd.service --no-block
|
||||
|
||||
Stop command initiates a graceful shutdown process, i2pd stops after finishing to route transit tunnels (maximum 10 minutes).
|
||||
The stop command initiates a graceful shutdown process, i2pd stops after finishing to route transit tunnels (maximum 10 minutes).
|
||||
|
||||
Enable/disable i2pd to be started on bootup:
|
||||
To enable/disable autostart of i2pd upon bootup:
|
||||
|
||||
sudo systemctl enable i2pd.service
|
||||
sudo systemctl disable i2pd.service
|
||||
@ -45,7 +45,8 @@ Enable/disable i2pd to be started on bootup:
|
||||
Recommended way to run i2pd built from source
|
||||
---------------------------------------------
|
||||
|
||||
This way all i2pd-related files will be stored at `$HOME/dist`.
|
||||
The following commands display the recommended way to build i2pd from source, without a package manager. Installing i2pd this
|
||||
way will ensure all i2pd-related files are stored at `$HOME/dist`.
|
||||
|
||||
mkdir $HOME/dist
|
||||
cp i2pd $HOME/dist
|
||||
@ -53,5 +54,8 @@ This way all i2pd-related files will be stored at `$HOME/dist`.
|
||||
cp contrib/i2pd.conf $HOME/dist
|
||||
cd $HOME/dist
|
||||
ulimit -n 4096 # only on Linux, increasing open file limit
|
||||
|
||||
Then, to run i2pd, simply travel to the installation directory and type:
|
||||
|
||||
./i2pd --datadir .
|
||||
|
||||
|
||||
@ -4,14 +4,15 @@ I2P tunnel configuration
|
||||
Overview
|
||||
--------
|
||||
|
||||
tunnels.conf is designed to support multiple I2P tunnels. Must be located in ``~/.i2pd`` (per-user) or ``/var/lib/i2pd`` (system-wide).
|
||||
`tunnels.conf` is designed to support multiple I2P tunnels. The configuration file must be located in
|
||||
``~/.i2pd`` (per-user) or ``/var/lib/i2pd`` (system-wide).
|
||||
|
||||
This file uses .ini file format. It consists of multiple sections with unique name each.
|
||||
This file uses the .ini file format. It consists of multiple sections each with a unique name.
|
||||
|
||||
Tunnel types
|
||||
------------
|
||||
|
||||
Section type is specified by *type* parameter.
|
||||
Section type is specified by the *type* parameter.
|
||||
|
||||
Available tunnel types:
|
||||
|
||||
@ -33,9 +34,9 @@ Client tunnels
|
||||
|
||||
Mnemonic: we can connect to someone as client
|
||||
|
||||
Must contain few mandatory parameters, some optional parameters might be also presented.
|
||||
Each client tunnel must contain a few mandatory parameters, along with some optional ones.
|
||||
|
||||
Example of client tunnel:
|
||||
Here is an example of a client tunnel:
|
||||
|
||||
[irc-out]
|
||||
type = client
|
||||
@ -44,8 +45,9 @@ Example of client tunnel:
|
||||
destination = irc.echelon.i2p
|
||||
keys = irc.dat
|
||||
|
||||
If *keys* is empty, transient keys will be created on every restart. If keys file is not found, new keys will be created and stored into specified file. If *keys* is equal to *transient*, new keys will be created, but not stored into a file.
|
||||
Client tunnels might share same local destination, if keys file contains same identity.
|
||||
If *keys* is empty, transient keys will be created on every restart. If the keys file is not found, new keys will be created and stored into the specified file.
|
||||
If *keys* is set to *transient*, new keys will be created, but not stored into a file.
|
||||
Client tunnels might share the same local destination, if the keys file contains the same identity.
|
||||
|
||||
Optional parameters:
|
||||
|
||||
@ -54,14 +56,14 @@ Optional parameters:
|
||||
* crytotype -- crypto type for new keys. Experimental. Should be alway 0
|
||||
* destinationport -- connect to particular port at destination. 0 by default
|
||||
|
||||
So, with example above, if you telnet to 127.0.0.1:6668 on localhost, i2pd will connect to irc.echelon.i2p:6668
|
||||
So, given the example above, if you connected to to 127.0.0.1:6668 on localhost, i2pd would tunnel that to irc.echelon.i2p:6668
|
||||
|
||||
Server/generic tunnels
|
||||
----------------------
|
||||
|
||||
Mnemonic: we serving some service to others in network
|
||||
|
||||
Example of server tunnel:
|
||||
Here is an example of a server tunnel:
|
||||
|
||||
[smtp-in]
|
||||
type = server
|
||||
@ -69,7 +71,8 @@ Example of server tunnel:
|
||||
port = 25
|
||||
keys = smtp-in.dat
|
||||
|
||||
*keys* must be presented, LeaseSet of address from keys file will be published. Server tunnel must use its own local destination.
|
||||
The file in *keys* must be present, and the LeaseSet of address from keys file will be published.
|
||||
The server tunnel must use its own local destination such as host 127.0.0.1 and port 80.
|
||||
|
||||
Optional parameters:
|
||||
|
||||
@ -83,10 +86,10 @@ Optional parameters:
|
||||
Server/http tunnels
|
||||
-------------------
|
||||
|
||||
*http* tunnel works same way as server tunnel, but replace 'Host:' field in HTTP header to address provided in configuration.
|
||||
Also resolves it if necessary.
|
||||
*http* tunnels are configured just like regular server tunnels, except the the 'Host:' field
|
||||
must be assigned to the address provided in configuration. i2pd will also resolve it if necessary.
|
||||
|
||||
Example of http tunnel:
|
||||
Here's an example of an http tunnel:
|
||||
|
||||
[http-in]
|
||||
type = http
|
||||
@ -143,9 +146,9 @@ There are 2 types of UDP tunnels: `udpclient` and `udpserver`
|
||||
Socks proxy
|
||||
-----------
|
||||
|
||||
Socks proxy interface can be defined in ``tunnels.conf``.
|
||||
The SOCKS proxy interface can be defined in ``tunnels.conf``.
|
||||
|
||||
Example of Socks proxy:
|
||||
Here's an example of a Socks proxy:
|
||||
|
||||
[alt-socks]
|
||||
type = socks
|
||||
@ -160,7 +163,7 @@ Example of Socks proxy:
|
||||
I2CP parameters
|
||||
---------------
|
||||
|
||||
I2CP parameter are common for all tunnel types and specify setting for a local destination.
|
||||
These I2CP parameter are common for all tunnel types and specify settings for a local destination.
|
||||
|
||||
* inbound.length -- number of hops of an inbound tunnel. 3 by default; lower value is faster but dangerous
|
||||
* outbound.length -- number of hops of an outbound tunnel. 3 by default; lower value is faster but dangerous
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user