It can contain @file{.nock} files: fully downloaded, but still not
checksummed. Can be checksummed (with @file{.nock} extension removing)
- with @command{nncp-check -nock}.
+ with @command{@ref{nncp-check} -nock}.
Also it can contain @file{seen/} and @file{hdr/} subdirectories,
that should be cleaned too from time to time.
- All of that cleaning tasks can be done with @ref{nncp-rm} utility.
+ All of that cleaning tasks can be done with @command{@ref{nncp-rm}} utility.
@cindex shared spool
@cindex setgid
@item
Optional @ref{CfgIncoming, incoming} directories where uploaded
- files are stored. Probably you want to run @ref{nncp-reass} from
- time to time to reassemble all chunked uploads. Example crontab
+ files are stored. Probably you want to run @command{@ref{nncp-reass}}
+ from time to time to reassemble all chunked uploads. Example crontab
entry:
@example
@pindex supervise
@pindex multilog
@item
- Possibly long running @ref{nncp-daemon}, @ref{nncp-caller},
- @ref{nncp-toss}, @ref{nncp-check} daemons. As all software, they can
+ Possibly long running @command{@ref{nncp-daemon}},
+ @command{@ref{nncp-caller}}, @command{@ref{nncp-toss}},
+ @command{@ref{nncp-check}} daemons. As all software, they can
fail and you should place them under some supervisor control.
For example you can use @url{http://cr.yp.to/daemontools.html,
@pindex inetd
@item
- @ref{nncp-daemon} can also be run as
+ @command{@ref{nncp-daemon}} can also be run as
@url{https://en.wikipedia.org/wiki/Inetd, inetd} service on UUCP's port:
@example
After that you should get various @command{bin/nncp-*} binaries and
@command{bin/hjson-cli} command (only for your convenience, not
necessary installation). For example, documentation for
-@command{nncp-bundle} command can be get with
+@command{@ref{nncp-bundle}} command can be get with
@command{info doc/nncp.info -n nncp-bundle}.
@pindex redo
@cindex streaming media
@unnumbered Bundles
-Usual @ref{nncp-xfer} command requires filesystem it can operate on.
-That presumes random access media storage usage, like hard drives, USB
-flash drives and similar. But media like CD-ROM and especially tape
-drives are sequential by nature. You can prepare intermediate directory
-for recording to CD-ROM disc/tape, but that requires additional storage
-and is inconvenient.
-
-Bundles, created with @ref{nncp-bundle} command are convenient
-alternative to ordinary @command{nncp-xfer}. Bundle is just a collection
-of @ref{Encrypted, encrypted packets}, stream of packets. It could be
-sequentially streamed for recording and digested back.
+Usual @command{@ref{nncp-xfer}} command requires filesystem it can
+operate on. That presumes random access media storage usage, like hard
+drives, USB flash drives and similar. But media like CD-ROM and
+especially tape drives are sequential by nature. You can prepare
+intermediate directory for recording to CD-ROM disc/tape, but that
+requires additional storage and is inconvenient.
+
+Bundles, created with @command{@ref{nncp-bundle}} command are convenient
+alternative to ordinary @command{@ref{nncp-xfer}}. Bundle is just a
+collection of @ref{Encrypted, encrypted packets}, stream of packets. It
+could be sequentially streamed for recording and digested back.
@itemize
Technically bundle is valid POSIX.1-2001
@url{https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_01, pax archive}
with directory/files hierarchy identical to that is used in
-@ref{nncp-xfer}: @file{NNCP/RECIPIENT/SENDER/PACKET}. So bundle can also
-be created by manual tar-ing of @command{nncp-xfer} resulting directory.
+@command{@ref{nncp-xfer}}: @file{NNCP/RECIPIENT/SENDER/PACKET}.
+So bundle can also be created by manual tar-ing of
+@command{@ref{nncp-xfer}} resulting directory.
@vindex calls
@unnumbered Call configuration
-Call is a rule when and how node can be called by @ref{nncp-caller}.
+Call is a rule when and how node can be called by @command{@ref{nncp-caller}}.
Example list of call structures:
@anchor{CfgNoCK}
@item nock
NoCK (no-checksumming) tells not to do checksumming of received files,
-assuming that it will be done for example with @ref{nncp-check} command
-later. That can help minimizing time spent online, because HDD won't do
-simultaneous reading of the data for checksumming and writing of the
-received one, but just sequential writing of the file. Pay attention
-that you have to make a call to remote node after checksumming is done,
-to send notification about successful packet reception.
+assuming that it will be done for example with
+@command{@ref{nncp-check}} command later. That can help minimizing time
+spent online, because HDD won't do simultaneous reading of the data for
+checksumming and writing of the received one, but just sequential
+writing of the file. Pay attention that you have to make a call to
+remote node after checksumming is done, to send notification about
+successful packet reception.
@vindex mcd-ignore
@anchor{CfgMCDIgnore}
@section Configuration directory
Optionally you can convert configuration file to the directory layout
-with @ref{nncp-cfgdir} command. And vice versa too, of course loosing
-the comment lines. Directory layout can looks like that:
+with @command{@ref{nncp-cfgdir}} command. And vice versa too, of course
+loosing the comment lines. Directory layout can looks like that:
@example
nncp-cfg-dir
Your @option{-cfg} and @env{$NNCPCFG} could point to that directory,
instead of @file{.hjson} file. It will be transparently converted to
internal JSON representation. However it can not be encrypted with the
-@ref{nncp-cfgenc}.
+@command{@ref{nncp-cfgenc}}.
@cindex private keys
That layout should be much more machine friendly and scriptable. Each
@anchor{CfgMCDListen}
@item mcd-listen
Specifies list of network interfaces regular expression
-@ref{nncp-caller} will listen for incoming @ref{MCD} announcements.
+@command{@ref{nncp-caller}} will listen for incoming @ref{MCD} announcements.
@vindex mcd-send
@anchor{CfgMCDSend}
@item mcd-send
Specifies list of network interfaces regular expressions, and intervals
-in seconds, where @ref{nncp-daemon} will send @ref{MCD} announcements.
+in seconds, where @command{@ref{nncp-daemon}} will send @ref{MCD} announcements.
+
@end table
@cindex yggdrasil aliases
Optional @ref{Yggdrasil}-related aliases are used for convenience and
keeping private keys away being used directly in command line. Each
@code{PUB}, @code{PRV}, @code{PEER}, @code{BIND} value in
-@ref{nncp-daemon}'s @option{-yggdrasil} and in @code{yggdrasil:}
+@command{@ref{nncp-daemon}}'s @option{-yggdrasil} and in @code{yggdrasil:}
addresses is replaced with alias value. Moreover each entry in list of
@code{PUB}s, @code{PEER}s and @code{BIND} can be an alias too. Pay
attention, that all aliases ending with @code{prv} will be saved with
@cindex Hjson
NNCP uses single file configuration file in @url{https://hjson.org/,
Hjson} format (see also section about @ref{Configuration directory,
-directory layout}) . Initially it is created with @ref{nncp-cfgnew}
+directory layout}) . Initially it is created with @command{@ref{nncp-cfgnew}}
command and at minimum it can look like this:
@verbatim
@item addrs
Dictionary containing known network addresses of the node. Each key
is human-readable name of the address. For direct TCP connections
- use @verb{|host:port|} format, pointing to @ref{nncp-daemon}'s
+ use @verb{|host:port|} format, pointing to @command{@ref{nncp-daemon}}'s
listening instance.
Also you can pipe connection through the external command using
@ref{CfgYggdrasilAliases, possible aliases} usage.
May be omitted if either no direct connection exists, or
- @ref{nncp-call} is used with forced address specifying.
+ @command{@ref{nncp-call}} is used with forced address specifying.
@vindex rxrate
@vindex txrate
@anchor{CfgCalls}
@item calls
List of @ref{Call, call configuration}s.
- Can be omitted if @ref{nncp-caller} won't be used to call that node.
+ Can be omitted if @command{@ref{nncp-caller}} won't be used to call that node.
@end table
@vindex NoisePrv
@vindex NoisePub
@strong{noise*} are used during @ref{Sync, synchronization protocol}
-working in @ref{nncp-call}, @ref{nncp-caller}, @ref{nncp-daemon}.
+working in @command{@ref{nncp-call}}, @command{@ref{nncp-caller}},
+@command{@ref{nncp-daemon}}.
storage devices, and/or at different time, reassembling the whole packet
on the destination node.
-Splitting is done with @ref{nncp-file, nncp-file -chunked} command and
-reassembling with @ref{nncp-reass} command.
+Splitting is done with @command{@ref{nncp-file} -chunked} command and
+reassembling with @command{@ref{nncp-reass}} command.
@vindex .nncp.meta
@vindex .nncp.chunk
@item -quiet
Print only errors, omit simple informational messages. In any case
those messages are logged, so you can reread them using
- @ref{nncp-log} command.
+ @command{@ref{nncp-log}} command.
@item -progress, -noprogress
Either force progress showing, or disable it.
@item -version
tape drives could easily provide too much throughput your CPU won't be
able to verify on the fly. So if you won't @ref{nncp-toss, toss}
received packets at the place, it is advisable either to run
-@ref{nncp-check} utility for packets integrity verification, or to use
-@option{-check} option to enable on the fly integrity check.
+@command{@ref{nncp-check}} utility for packets integrity verification,
+or to use @option{-check} option to enable on the fly integrity check.
You can specify multiple @option{NODE} arguments, telling for what nodes
you want to create the stream, or take it from. If no nodes are
@verb{|yggdrasil:PUB;PRV;PEER[,...]|} formats.
If you specify @option{-ucspi} option, then it is assumed that you run
-@command{nncp-call} command under some UCSPI-TCP compatible utility,
+@command{@ref{nncp-call}} command under some UCSPI-TCP compatible utility,
that provides read/write channels through 6/7 file descriptors.
@option{-mcd-wait} options tells to wait up to specified number of
@option{-autotoss} option runs tosser on node's spool every second
during the call. All @option{-autotoss-*} options is the same as in
-@ref{nncp-toss} command.
+@command{@ref{nncp-toss}} command.
Partly downloaded packets are stored in @file{.part} files. By default
all downloaded files are sequentially checksummed in the background,
files to @file{.nock} extension. Pay attention that checksumming can be
time consuming and connection could be lost during that check, so remote
node won't be notified that the file is finished. If you run
-@ref{nncp-check, @command{nncp-check -nock}}, that will checksum files
-and strip the @file{.nock} extension, then repeated call to remote node
-will notify about packet's completion. Also it will be notified if
-@ref{nncp-toss, tossing} created @file{seen/} file.
-Read @ref{CfgNoCK, more} about @option{-nock} option.
+@command{@ref{nncp-check} -nock}, that will checksum files and strip the
+@file{.nock} extension, then repeated call to remote node will notify about
+packet's completion. Also it will be notified if @ref{nncp-toss, tossing}
+created @file{seen/} file. Read @ref{CfgNoCK, more} about @option{-nock}
+option.
Otherwise all nodes with specified @emph{calls} configuration
field will be called.
-Look at @ref{nncp-call} for more information.
+Look at @command{@ref{nncp-call}} for more information.
Print out stripped configuration version: only path to @ref{Spool,
spool}, path to log file, neighbours public keys are stayed. This is
-useful mainly for usage with @ref{nncp-xfer} that has to know only
-neighbours, without private keys involving.
+useful mainly for usage with @command{@ref{nncp-xfer}} that has to know
+only neighbours, without private keys involving.
Start listening TCP daemon, wait for incoming connections and run
@ref{Sync, synchronization protocol} with each of them. You can run
-@ref{nncp-toss} utility in background to process inbound packets from
-time to time.
+@command{@ref{nncp-toss}} utility in background to process inbound
+packets from time to time.
@option{-maxconn} option specifies how many simultaneous clients daemon
can handle. @option{-bind} option specifies @option{addr:port} it must
@option{-autotoss} option runs tosser on node's spool every second
during the call. All @option{-autotoss-*} options is the same as in
-@ref{nncp-toss} command.
+@command{@ref{nncp-toss}} command.
Read @ref{CfgNoCK, more} about @option{-nock} option.
@option{-dump} option outputs plain packet's payload (if it is file
transmission, then it will be the file itself as an example). If it is
an encrypted packet, then it will be decrypted first, outputing the
-included plain packet, that can be fed to @command{nncp-pkt} again:
+included plain packet, that can be fed to @command{@ref{nncp-pkt}} again:
@example
Packet type: plain
@item If @option{-tmp} option is specified, then it will delete all
temporary files in @file{spool/tmp} directory. Files may stay in it when
-commands like @ref{nncp-file} fail for some reason.
+commands like @command{@ref{nncp-file}} fail for some reason.
@item If @option{-lock} option is specified, then all @file{.lock} files
will be deleted in your spool directory.
running this command as a daemon.
@option{-seen} option creates empty @file{seen/XXX} file after
-successful tossing of @file{XXX} packet. @ref{nncp-xfer},
-@ref{nncp-bundle}, @ref{nncp-daemon} and @ref{nncp-call} commands skip
-inbound packets that has been already seen, processed and tossed. This
-is helpful to prevent duplicates.
+successful tossing of @file{XXX} packet. @command{@ref{nncp-xfer}},
+@command{@ref{nncp-bundle}}, @command{@ref{nncp-daemon}} and
+@command{@ref{nncp-call}} commands skip inbound packets that has been
+already seen, processed and tossed. This is helpful to prevent
+duplicates.
@option{-nofile}, @option{-nofreq}, @option{-noexec}, @option{-notrns},
@option{-noarea} options allow disabling any kind of packet types processing.
@option{-rx} option tells only to move inbound packets addressed to us.
@option{-tx} option tells exactly the opposite: move only outbound packets.
-@ref{nncp-cfgmin} could be useful for creating stripped minimalistic
-configuration file version without any private keys.
+@command{@ref{nncp-cfgmin}} could be useful for creating stripped
+minimalistic configuration file version without any private keys.
@file{DIR} directory has the following structure:
@file{RECIPIENT/SENDER/PACKET}, where @file{RECIPIENT} is Base32 encoded
destination node, @file{SENDER} is Base32 encoded sender node.
-Also look for @ref{nncp-bundle}, especially if you deal with CD-ROM and
-tape drives.
+Also look for @command{@ref{nncp-bundle}}, especially if you deal with
+CD-ROM and tape drives.
@unnumbered Comparison with existing solutions
Here is comparison with @url{https://en.wikipedia.org/wiki/UUCP, UUCP}
-(Unix to Unix copy), FTN (@url{https://en.wikipedia.org/wiki/FidoNet,
-FidoNet} Technology Networks) and @url{https://en.wikipedia.org/wiki/SMTP, SMTP}
+(Unix to Unix copy), FTN (@url{https://en.wikipedia.org/wiki/FidoNet, FidoNet}
+Technology Networks) and @url{https://en.wikipedia.org/wiki/SMTP, SMTP}
(because it is also store-and-forward solution).
@multitable @columnfractions 0.40 0.15 0.15 0.15 0.15
@pindex uuxqt
@item Connect to remote system
@tab @command{uucico -s}, @command{uupoll}
- @tab @command{nncp-call}, @command{nncp-caller}
+ @tab @command{@ref{nncp-call}}, @command{nncp-caller}
@item Receive connection (pipe, daemon, etc)
@tab @command{uucico} (@option{-l} or similar)
- @tab @command{nncp-daemon}
+ @tab @command{@ref{nncp-daemon}}
@item Request remote execution, @code{stdin} piped in
@tab @command{uux}
- @tab @command{nncp-exec}
+ @tab @command{@ref{nncp-exec}}
@item Copy file to remote machine
@tab @command{uucp}
- @tab @command{nncp-file}
+ @tab @command{@ref{nncp-file}}
@item Copy file from remote machine
@tab @command{uucp}
- @tab @command{nncp-freq}
+ @tab @command{@ref{nncp-freq}}
@item Process received requests
@tab @command{uuxqt}
- @tab @command{nncp-toss}
+ @tab @command{@ref{nncp-toss}}
@item Move outbound requests to dir (for USB stick, airgap, etc)
@tab N/A
- @tab @command{nncp-xfer}
+ @tab @command{@ref{nncp-xfer}}
@item Create streaming package of outbound requests
@tab N/A
- @tab @command{nncp-bundle}
+ @tab @command{@ref{nncp-bundle}}
@end multitable
.endif
@end example
-This is pretty straightforward. We pipe to @command{nncp-exec}, run it
-as the nncp user. @command{nncp-exec} sends it to a target node and runs
+This is pretty straightforward. We pipe to @command{@ref{nncp-exec}}, run it
+as the nncp user. @command{@ref{nncp-exec}} sends it to a target node and runs
whatever that node has called @command{rsmtp} (the command to receive
bsmtp data). When the target node processes the request, it will run the
configured command and pipe the data in to it.
@itemize
-@item You need an @ref{nncp-exec} program that extracts the sender
-address from mail that arrives via NNCP, and that feeds the mail into
-the Postfix @command{sendmail} command.
+@item You need an @command{@ref{nncp-exec}} program that extracts the
+sender address from mail that arrives via NNCP, and that feeds the mail
+into the Postfix @command{sendmail} command.
@item Define a @command{pipe(8)} based mail delivery transport for
delivery via NNCP:
flags=Rqhu user=nncp argv=nncp-exec -quiet $nexthop sendmail $recipient
@end example
-This runs the @command{nncp-exec} command to place outgoing mail into
+This runs the @command{@ref{nncp-exec}} command to place outgoing mail into
the NNCP queue after replacing @var{$nexthop} by the receiving NNCP
node and after replacing @var{$recipient} by the recipients. The
-@command{pipe(8)} delivery agent executes the @command{nncp-exec}
+@command{pipe(8)} delivery agent executes the @command{@ref{nncp-exec}}
command without assistance from the shell, so there are no problems with
shell meta characters in command-line parameters.
@itemize
-@item You need an @ref{nncp-exec} program that extracts the sender
-address from mail that arrives via NNCP, and that feeds the mail into
-the Postfix @command{sendmail} command.
+@item You need an @command{@ref{nncp-exec}} program that extracts the
+sender address from mail that arrives via NNCP, and that feeds the mail
+into the Postfix @command{sendmail} command.
@item Specify that all remote mail must be sent via the @command{nncp}
mail transport to your NNCP gateway host, say, @emph{nncp-gateway}:
flags=Fqhu user=nncp argv=nncp-exec -quiet $nexthop sendmail $recipient
@end example
-This runs the @command{nncp-exec} command to place outgoing mail into
+This runs the @command{@ref{nncp-exec}} command to place outgoing mail into
the NNCP queue. It substitutes the hostname (@emph{nncp-gateway}, or
whatever you specified) and the recipients before execution of the
-command. The @command{nncp-exec} command is executed without assistance
+command. The @command{@ref{nncp-exec}} command is executed without assistance
from the shell, so there are no problems with shell meta characters.
@item Execute the command @command{postfix reload} to make the changes
@cindex serial connection
@section Serial connection
-It is not trivial to run online @command{nncp-daemon},
-@command{nncp-call} and @command{nncp-caller} commands over the serial
-link, because it is link without built-in error detection. For efficient
-usage you have to use some kind of window-sliding error correction
-protocol, like Kermit, ZMODEM, UUCP's g-protocol and similar well known
-ones.
+It is not trivial to run online @command{@ref{nncp-daemon}},
+@command{@ref{nncp-call}} and @command{@ref{nncp-caller}} commands over
+the serial link, because it is link without built-in error detection.
+For efficient usage you have to use some kind of window-sliding error
+correction protocol, like Kermit, ZMODEM, UUCP's g-protocol and similar
+well known ones.
However TCP is already satisfying and existing protocol for the same
purposes. So it would be more easier to bring up the IP interconnection
Log is a plaintext file consisting of
@url{https://www.gnu.org/software/recutils/, recfile} records. It can be
-read by human, but it is better to use either @ref{nncp-log}, or
-@command{recutils} utilities for selecting and formatting the required
+read by human, but it is better to use either @command{@ref{nncp-log}},
+or @command{recutils} utilities for selecting and formatting the required
fields.
Two example records from it:
@itemize
@item
- @ref{nncp-daemon} sends multicast messages about its presence from
- time to time. See @ref{CfgMCDSend, mcd-send} configuration option.
+ @command{@ref{nncp-daemon}} sends multicast messages about its
+ presence from time to time. See @ref{CfgMCDSend, mcd-send}
+ configuration option.
@item
- When @ref{nncp-caller} sees them, it adds them as the most
+ When @command{@ref{nncp-caller}} sees them, it adds them as the most
preferred addresses to already known ones. If MCD address
announcement was not refreshed after two minutes -- it is removed.
See @ref{CfgMCDListen, mcd-listen} and
@strong{@verb{|ff02::4e4e:4350|}} (hexadecimal ASCII @verb{|NNCP|})
multicast address and @strong{5400} port. Operating system will use IPv6
link-local address as a source one, with the port taken from
-@command{nncp-daemon}'s @option{-bind} option. That way, IP packet
+@command{@ref{nncp-daemon}}'s @option{-bind} option. That way, IP packet
itself will carry the link-scope reachable address of the daemon.
Each multicast group is identified by so-called @strong{area}. Area
consists of private/public Curve25519 keypairs for @ref{Encrypted area,
packets encryption}, identity (BLAKE2b-256 hash of the public key) and
-possible subscribers. Areas are created with @ref{nncp-cfgnew} command.
+possible subscribers. Areas are created with @command{@ref{nncp-cfgnew}}
+command.
You can make either file or exec transmissions to the areas. Those
ordinary file/exec packets are double wrapped in:
@enumerate
@item
-@command{nncp-file} creates an encrypted packet with area packet and
+@command{@ref{nncp-file}} creates an encrypted packet with area packet and
encrypted packet inside it, with our own @code{self} node as a recipient
(in the @file{SPOOL/SELF/tx} directory). It also creates the
@file{SPOOL/SELF/area/AREA/MsgHash} file.
@item
-@command{nncp-toss} sees @file{tx/} file and "opens" it, applying the
+@command{@ref{nncp-toss}} sees @file{tx/} file and "opens" it, applying the
area message tossing procedure as described above. That will create
outgoing packets in @file{SPOOL/nodeB/tx} and @file{SPOOL/nodeD/tx}
directories with @file{SPOOL/nodeB/area/AREA/MsgHash}
higher priority packets, like mail messages, will pass first, even when
lower priority packet was already been partially downloaded.
-There are default niceness levels built-in for @ref{nncp-exec},
-@ref{nncp-file} and @ref{nncp-freq} commands. But pay attention that it
-can give information about underlying payload to the adversary!
+There are default niceness levels built-in for
+@command{@ref{nncp-exec}}, @command{@ref{nncp-file}} and
+@command{@ref{nncp-freq}} commands. But pay attention that it can give
+information about underlying payload to the adversary!
There are 1-255 niceness levels. They could be specified either as
integer, or using aliases with delta modifiers:
@cindex nock files
@item LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ.nock
non-checksummed (NoCK) @strong{fully} received file. Its checksum is
-verified against its filename either by @ref{nncp-check}, or by working
-online daemons. If it is correct, then its extension is trimmed.
+verified against its filename either by @command{@ref{nncp-check}}, or
+by working online daemons. If it is correct, then its extension is trimmed.
@cindex seen files
@item seen/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ
-@ref{nncp-toss} utility can be invoked with @option{-seen} option,
-leading to creation of @file{seen/} files, telling that the file with
-specified hash has already been processed before. It could be useful
-when there are use-cases where multiple ways of packets transfer
+@command{@ref{nncp-toss}} utility can be invoked with @option{-seen}
+option, leading to creation of @file{seen/} files, telling that the file
+with specified hash has already been processed before. It could be
+useful when there are use-cases where multiple ways of packets transfer
available and there is possibility of duplicates reception. You have to
manually remove them, when you do not need them (probably because they
are expired).
then @file{hdr/} files are automatically created for every ordinary
(fully received and checksummed) packet. It literally contains just the
header of the corresponding packet. It will be automatically created
-even during simple @ref{nncp-stat} call. On filesystems with big
-blocksize (ZFS for example) it can greatly help listing the packets in
-directories, because it prevents unnecessary read-amplification. On
+even during simple @command{@ref{nncp-stat}} call. On filesystems with
+big blocksize (ZFS for example) it can greatly help listing the packets
+in directories, because it prevents unnecessary read-amplification. On
other filesystems probably it won't help at all, or even harm
performance.
There is a hack: you can create more dense @file{hdr/} allocation by
-removing all @file{hdr/} files and then running @command{nncp-stat},
+removing all @file{hdr/} files and then running @command{@ref{nncp-stat}},
that will recreate them. In many cases many @file{hdr/} files will be
allocated more or less linearly on the disk, decreasing listing time
even more.
@emph{bob-airgap} доступен путём посылки промежуточного ретранслируемого
пакета через узел @emph{bob}.
-Любая команда типа @command{nncp-file myfile bob-airgap:} автоматически
+Любая команда типа @command{@ref{nncp-file} myfile bob-airgap:} автоматически
создаст инкапсулированный пакет: один непосредственно для целевой точки,
а другой несущий его для промежуточного узла.
хотите проходить любому трафику когда узел доступен через ЛВС (LAN).
Вы легко можете настроить ваши предпочтения в @ref{Call, настройках
-звонков} для @ref{nncp-caller} команды, используемой при online связи.
+звонков} для @command{@ref{nncp-caller}} команды, используемой при
+online связи.
@verbatim
neigh: {
KISS}!
Просто скажите вашим обоим Postfix/Exim-ам (на сервере и ноутбуке)
-отправлять сообщения через NNCP (@ref{nncp-exec}) на заданный узел.
+отправлять сообщения через NNCP (@command{@ref{nncp-exec}}) на заданный узел.
Более подробно читайте для Postfix @ref{Postfix, здесь}, а для Exim
@ref{Exim, здесь}. Вся почта будет сохранятся в NNCP @ref{Spool, спуле},
который после обмена данных и распаковки вызовет локальный
Представьте, что вы послали два файла узлу @emph{bob}. Вставьте USB
устройство (SD гораздо предпочтительнее!) хранения, подмонтируйте и
-запустите @ref{nncp-xfer}:
+запустите @command{@ref{nncp-xfer}}:
@example
$ nncp-xfer -node bob /media/usbstick
@end example
чтобы найти все пакеты относящиеся к их узлу и локально скопируют для
-дальнейшей обработки. @command{nncp-xfer} это единственная команда
+дальнейшей обработки. @command{@ref{nncp-xfer}} это единственная команда
используемая с переносными устройствами хранения.
@node UsecasePOPRU
@subsection Легковесная и быстрая замена POP3/IMAP4
-@ref{nncp-daemon} может быть соединён с @ref{nncp-caller} длительное
-время -- он создаёт TCP соединение на многие часы. Когда SMTP сервер
-получает письмо, то вызывает @ref{nncp-exec} для создания исходящего
+@command{@ref{nncp-daemon}} может быть соединён с
+@command{@ref{nncp-caller}} длительное время -- он создаёт TCP
+соединение на многие часы. Когда SMTP сервер получает письмо, то
+вызывает @command{@ref{nncp-exec}} для создания исходящего
зашифрованного пакета. Демон ежесекундно проверяет исходящую директорию
и сразу же посылает оповещение о недоставленных пакетах противоположной
стороне, которая сразу же их может скачать.
вы не "распаковываете" эти пакеты сразу же на том же самом устройстве.
Распаковка (чтение этих зашифрованных пакетов с извлечением переданных
файлов и почтовых сообщений) может и должна бы быть произведена на
-отдельном компьютере (@ref{nncp-cfgmin} команда может помочь с созданием
-конфигурационного файла без приватных ключей для этой цели).
+отдельном компьютере (@command{@ref{nncp-cfgmin}} команда может помочь с
+созданием конфигурационного файла без приватных ключей для этой цели).
Если вы действительно хотите взять с собой приватные ключи, то
-@ref{nncp-cfgenc} команда способна зашифровать ваш конфигурационный
-файл. Парольная фраза вами введённая усиливается функцией нагружающей и
-центральный процессор и память.
+@command{@ref{nncp-cfgenc}} команда способна зашифровать ваш
+конфигурационный файл. Парольная фраза вами введённая усиливается
+Ñ\84Ñ\83нкÑ\86ией нагÑ\80Ñ\83жаÑ\8eÑ\89ей и Ñ\86енÑ\82Ñ\80алÑ\8cнÑ\8bй пÑ\80оÑ\86еÑ\81Ñ\81оÑ\80 и памÑ\8fÑ\82Ñ\8c.
@emph{bob-airgap} can be reached by sending intermediate relay packet
through the @emph{bob}.
-Any command like @command{nncp-file myfile bob-airgap:} will
+Any command like @command{@ref{nncp-file} myfile bob-airgap:} will
automatically create an encapsulated packet: one for the destination
endpoint, and other carrying it for intermediate relaying node.
through in anytime. Also you wish to pass any kind of traffic when the
node is available through the LAN.
-You can easily set your preferences in @ref{Call, call
-configurations} for @ref{nncp-caller} command used in online
-communications.
+You can easily set your preferences in @ref{Call, call configurations}
+for @command{@ref{nncp-caller}} command used in online communications.
@verbatim
neigh: {
@url{https://en.wikipedia.org/wiki/KISS_principle, KISS}!
Just tell both of your Postfix/Exim (on the server and notebook) to drop
-email as a mail via NNCP (@ref{nncp-exec}) to specified node.
+email as a mail via NNCP (@command{@ref{nncp-exec}}) to specified node.
More information for Postfix is @ref{Postfix, here} and for Exim is
@ref{Exim, here}. All mail will be stored in NNCP @ref{Spool, spool},
media for transferring packets to other nodes.
Assume that you send two files to @emph{bob} node. Insert USB storage
-device (SD is preferable!), mount it and run @ref{nncp-xfer}:
+device (SD is preferable!), mount it and run @command{@ref{nncp-xfer}}:
@example
$ nncp-xfer -node bob /media/usbstick
@end example
to find all packets related to their node and copy them locally for
-further processing. @command{nncp-xfer} is the only command used with
+further processing. @command{@ref{nncp-xfer}} is the only command used with
removable devices.
@cindex IMAP4 replacement
@section Lightweight fast POP3/IMAP4 replacement
-@ref{nncp-daemon} can be connected with @ref{nncp-caller} for a long
-time -- it can create TCP connection that lasts for many hours. When
-SMTP server receives mail, it will call @ref{nncp-exec} creating an
-outbound encrypted packet. Daemon checks outbound directory each second
-and immediately sends notification about undelivered packets to remote
-side, that also downloads it at once.
+@command{@ref{nncp-daemon}} can be connected with
+@command{@ref{nncp-caller}} for a long time -- it can create TCP
+connection that lasts for many hours. When SMTP server receives mail, it
+will call @command{@ref{nncp-exec}} creating an outbound encrypted
+packet. Daemon checks outbound directory each second and immediately
+sends notification about undelivered packets to remote side, that also
+downloads it at once.
There are only dozens of bytes notifying about incoming packets, dozens
of bytes telling to download those packets. Mail packets are compressed
with it (don't you?), you do not "toss" those packets immediately on the
same device. Tossing (reading those encrypted packets and extracting
transferred files and mail messages) could and should be done on a
-separate computer (@ref{nncp-cfgmin} command could help creating
+separate computer (@command{@ref{nncp-cfgmin}} command could help creating
configuration file without private keys for that purpose).
-If you really want to carry your private keys, then @ref{nncp-cfgenc}
+If you really want to carry your private keys, then @command{@ref{nncp-cfgenc}}
command will be able to encrypt your configuration file. Passphrase you
enter is strengthened with both CPU and memory hard function.
@node Workflow
+@cindex workflow
@unnumbered Workflow
NNCP consists of several utilities. As a rule you will have the
following workflow:
@enumerate
-@item Run @ref{nncp-cfgnew} on each node to create an initial
+
+@item Run @command{@ref{nncp-cfgnew}} on each node to create an initial
@ref{Configuration, configuration} file.
+
@item Tune it up and set at least @ref{Spool, spool} and log paths.
+
@item Share your public keys and reachability addressees with your
neighbours. Add their keys to your configuration file and do any other
required configuration about their reachability, permissions of file or
freq transmission.
-@item Use @ref{nncp-file}, @ref{nncp-freq}, @ref{nncp-exec}
-(look @ref{Postfix, how} Postfix and @ref{Exim, how} Exim SMTP servers
-could be configured) commands to queue file, freq and exec
-transmissions. Repeat as many times any time as you wish.
+
+@item Use @command{@ref{nncp-file}}, @command{@ref{nncp-freq}},
+@command{@ref{nncp-exec}} (look @ref{Postfix, how} Postfix and
+@ref{Exim, how} Exim SMTP servers could be configured) commands to queue
+file, freq and exec transmissions. Repeat as many times any time as you
+wish.
+
@item Depending on connection methods, either:
@itemize
- @item run @ref{nncp-daemon} to accept remotely initiated connections
- to your node
- @item run either @ref{nncp-call} or @ref{nncp-caller} to initiate
- connection to required nodes from time to time
- @item use @ref{nncp-xfer} with removable storage devices for copying
- packets to/from other nodes
- @item use @ref{nncp-bundle} with either sequential storage devices
- or broadcasting transmissions for copying packets
+ @item run @command{@ref{nncp-daemon}} to accept remotely initiated
+ connections to your node
+ @item run either @command{@ref{nncp-call}} or
+ @command{@ref{nncp-caller}} to initiate connection to required nodes
+ from time to time
+ @item use @command{@ref{nncp-xfer}} with removable storage devices
+ for copying packets to/from other nodes
+ @item use @command{@ref{nncp-bundle}} with either sequential storage
+ devices or broadcasting transmissions for copying packets
@end itemize
+
@item After successful packet exchanging (or just simply from time to
-time), run @ref{nncp-toss} for tossing (decrypting and processing) all
-inbound queues to receive exec messages, files, file requests and relay
-transition packets to other nodes.
+time), run @command{@ref{nncp-toss}} for tossing (decrypting and
+processing) all inbound queues to receive exec messages, files, file
+requests and relay transition packets to other nodes.
+
@end enumerate
@itemize
@item If you wish to encrypt your configuration file containing your
-private keys, then use @ref{nncp-cfgenc} utility. You can always use an
-encrypted config without decrypting it in temporary memory file.
+private keys, then use @command{@ref{nncp-cfgenc}} utility. You can
+always use an encrypted config without decrypting it in temporary memory file.
@item If you wish to strip off any private keys from your config, then
-use @ref{nncp-cfgmin} utility. It will be useful for transferring
+use @command{@ref{nncp-cfgmin}} utility. It will be useful for transferring
messages with offline methods, but tossing them later on the machine
with private keys.
@end itemize
full-featured TUN network interface, there is pure Go built-in stack,
responsible for IPv6 and TCP protocols support. You do not need to think
about network interfaces, addressing and firewall setup at all:
-@ref{nncp-daemon} acts as Yggdrasil IPv6 reachable host, listening on
-single TCP port. You can reach it using ordinary non-Yggdrasil capable
-version of @ref{nncp-call}, calling corresponding 200::/7 IPv6 address
-through native Yggdrasil daemon created TUN interface.
-@ref{nncp-daemon}, @ref{nncp-call}* can freely peer with Yggdrasil
-nodes, reusing existing infrastructure.
+@command{@ref{nncp-daemon}} acts as Yggdrasil IPv6 reachable host,
+listening on single TCP port. You can reach it using ordinary
+non-Yggdrasil capable version of @command{@ref{nncp-call}}, calling
+corresponding 200::/7 IPv6 address through native Yggdrasil daemon
+created TUN interface. @command{@ref{nncp-daemon}},
+@command{@ref{nncp-call}}* can freely peer with Yggdrasil nodes, reusing
+existing infrastructure.
Only minor modifications were done to current NNCP's tools:
@itemize
@cindex yggdrasils schema
-making it also as a Yggdrasil listener network node. It can
+@item @command{@ref{nncp-daemon}} has @option{-yggdrasil yggdrasils://}
+option, making it also as a Yggdrasil listener network node. It can
automatically connect to other peers and participate in routing. It does
not have to answer NNCP's online protocol requests at all and just can
be some intermediate routing point in the whole mesh network.
@cindex yggdrasilc schema
+@item @command{@ref{nncp-call}}/@command{@ref{nncp-caller}} commands understand
@code{yggdrasilc://} addresses, pointing to the desired Yggdrasil's
public key (that also acts as the destination host's address). Yggdrasil
background goroutine is automatically started, connecting to the
specified Yggdrasil entrypoints, calling remote NNCP node and initiating
NNCP's native @ref{Sync, online protocol} handshake on top of that.
-@item @ref{nncp-cfgnew} is able to generate ed25519 keypair.
+@item @command{@ref{nncp-cfgnew}} is able to generate ed25519 keypair.
@item @ref{CfgYggdrasilAliases, Configuration file} optionally contains
@code{yggdrasil-aliases} map.
You should share that public key with other NNCP peers.
@item
-Start @ref{nncp-daemon} listening on Yggdrasil's incoming connections.
+Start @command{@ref{nncp-daemon}} listening on Yggdrasil's incoming connections.
You have to specify:
@itemize