NAME¶
alfred - Almighty Lightweight Fact Remote Exchange Daemon
SYNOPSIS¶
alfred [options]
DESCRIPTION¶
alfred is a user space daemon for distributing arbitrary local information over
the mesh/network in a decentralized fashion. This data can be anything which
appears to be useful - originally designed to replace the batman-adv
visualization (vis), you may distribute hostnames, phone books, administration
information, DNS information, the local weather forecast ...
alfred runs as daemon in the background of the system. A user may insert
information by using the alfred binary on the command line, or use special
programs to communicate with alfred (done via unix sockets). alfred then takes
care of distributing the local information to other alfred servers on other
nodes. This is done via IPv6 link-local multicast, and does not require any
configuration. A user can request data from alfred, and will receive the
information available from all alfred servers in the network.
OPTIONS¶
- -v, --version
- Print the version
- -h, --help
- Display a brief help message.
- -u, --unix-path path
- path to unix socket used for client-server communication.
CLIENT OPTIONS¶
- -s, --set-data data-type
- Sets new data to distribute from stdin for the supplied data type (0-255).
Note that 0 - 63 are reserved (please send an e-mail to the authors if you
want to register a datatype), and can not be used on the commandline.
Information must be periodically written again to alfred, otherwise it
will timeout and alfred will forget about it (after 10 minutes).
- -r, --request data-type
- Collect data from the network and prints it on the network
- -d, --verbose
- Show extra information in the data output
- -V, --req-version version
- Specify the data version set for -s
Skipping the parameter entirely has the same effect as setting the parameter
to 0 (' -V 0').
- -M, --modeswitch mode
-
master
Switch daemon to mode master
slave
Switch daemon to mode slave
- -I, --change-interface interface
- Change the alfred server to use the new interface(s)
SERVER OPTIONS¶
- -i, --interface face
- Specify the interface (or comma separated list of interfaces) to listen
on
- -b batmanif
- Specify the batman-adv interface configured on the system (default: bat0).
Use 'none' to disable the batman-adv based best server selection.
The -b option is optional, and only needed if you run alfred on a
batman-adv interface not called bat0, or if you don't use batman-adv at
all (use ' -b none'). In this case, alfred will still work but will
not be able to find the best next master server based on metrics.
- -m, --master
- Start up the daemon in master mode, which accepts data from slaves and
syncs it with other masters.
alfred servers may either run as master or slave in the network. Masters
will announce their status via broadcast, so that slaves can find them.
Slaves will then send their data to their nearest master (based on TQ).
Masters will exchange their data (which they have received from slaves or
got on their own) with other masters. By using masters and slaves,
overhead can be reduced while still keeping redundancy (by having multiple
masters). Obviously, at least one master must be present in the network to
let any data exchange happen. Also having all nodes in master mode is
possible (for maximum decentrality and overhead).
- -c, --update-command command
- Specify command to execute on data change. It will be called with
data-type list as arguments.
EXAMPLES¶
Start an alfred server listening on bridge br0 (assuming that this bridge
includes the batman interface bat0):
alfred -i br0 -m
Send data to the alfred server and store it under id 65:
cat /etc/hostname | alfred -s 65
Retreive all data stored as id 65 from all connected alfred servers:
alfred -r 65
{ "fe:f1:00:00:01:01", "OpenWRT-node-1\x0a" },
{ "fe:f1:00:00:02:01", "OpenWRT-node-2\x0a" },
{ "fe:f1:00:00:03:01", "OpenWRT-node-3\x0a" },
SEE ALSO¶
batadv-vis(8),
batctl(8)
AUTHOR¶
alfred was written by Simon Wunderlich <sw@simonwunderlich.de> and Sven
Eckelmann <sven@open-mesh.com>.
This manual page was written by Simon Wunderlich <sw@simonwunderlich.de>
and Sven Eckelmann <sven@open-mesh.com>.