finger (RFC 1288) server-side daemon.
finger is both a protocol and a utility to get the information and status from a user on a distant machine. It was standardized in RFC 742 in 1977, then in RFC 1288 in 1991, and has been abandoned since.
While describing the protocol in a blog post of mine, I wanted to implement this protocol for fun, but didn’t want to present the real information about the users on my server, so I made this to present some fictional information in order to be able to tell a story through finger.
The finger server should be available through the TCP port 79, which can only be opened by root on UNIX-like machines. Instead of using this port directly, which forces the use of the root user to manage the service, you can redirect the incoming transmissions from an interface on TCP port 79 to another TCP port which you can open as a user (port number over 1024) by appending a rule in iptables:
iptables -t nat -A OUTPUT -p tcp [-s <source ip>] [-d <destination ip>] \ --dport 79 -j DNAT --to <ip:port>
Where <source ip> is the source IP address or network that are redirected, <destination ip> is the destination IP address or network for which the requests are redirected and <ip:port> is the IP and port you want to forward the packets to, e.g. 127.0.0.1:4000.
The basic configuration of the server is stored in the actions.ini file, see the comments for how to make it do what you want it to do. Other configuration files are described in their specific sections.
To run the application, use the following command:
python3 -m fingerd <command line options>
The actions are stored as a TOML document. Each action is stored under its time offset, using an array section, where the time offset is represented this way:
Where negative times, starting with a dash (-), are the initial situation, what is supposed to have happened before the beginning.
For example, -1w5d2h means “1 week, 5 days and 2 hours before the origin” and 2j means “2 days after the origin”. So if we want to make an action that takes place 5 seconds after the origin, the first line of the action will be the following one:
All actions have a type represented by the type property, and other properties depending on the type. Types and related properties are described in the sections below.
What is left to do
separate users and sessions, so that there can be several sessions displayed as in these examples:
Login Name Tty Idle Login Time Office Office Phone cake Thomas Touhey pts/0 Sep 12 22:51 (XXXX::XXXX) cake Thomas Touhey pts/1 Sep 12 22:51 (XXXX::XXXX)
Login: cake Name: Thomas Touhey Directory: /home/cake Shell: /bin/zsh On since Wed Sep 12 22:51 (CEST) on pts/0 from XXXX::XXXX 8 seconds idle On since Wed Sep 12 22:51 (CEST) on pts/1 from XXXX::XXXX 4 seconds idle No Plan.