Robin Rawson-Tetley's homepage

inetdxtra

Having invested in a Linksys NSLU2
recently (2007), I set myself the challenge of running as many of my network
services as possible via the inetd supserserver to keep all my
network services unloaded when they're not needed (it only has 32MB of
RAM after all). I probably went further than necessary really, just
for the challenge.

inetd-based services already available that I used included:

SSH (dropbear)

Telnet (netkit)

FTP (openbsd)

OpenVPN

POP3 (popa3d)

IMAP4 (uw-imapd)

This left me having to write my own inetd servers to handle the
following protocols. Well, I didn't have to, but it was a
fun problem and I really enjoy seeing a ps listing that contains just inetd,
cron and the syslogger (yes, I'm weird).

The great thing about these apps is that they're simple,
they're all written in C, they don't have any dependencies except
the platform C library and none of their binaries are
more than 20Kb in size (and well under 100Kb when running). I use
them constantly and they simply don't
break - they follow the mantra of "do one thing and do it well".
I've only tested them against Linux since that's what my machines run,
but they shouldn't require much (if any) work to port
for other Unixes. They are ideal candidates for embedded platforms
where other servers are simply too resource hungry.

in.www

in.www is a tiny webserver that is designed to run
through inetd. Support is limited to HTTP 1.0 and CGI 1.0

Security

in.www is secure as possible. The default compile uses -DNORELATIVE,
which causes 403 errors to be sent to any client attempting to use
relative paths to escape the document tree. This stops 99% of
web-based attacks. All buffers are carefully checked and limited in
an attempt to prevent buffer overrun attacks.

The -DCGI compile switch enables CGI functionality. For a script
to run, it can be anywhere in the tree (in.www does not have a cgi-bin
directory) and must be executable. If you
don't need CGI and want the extra security, do not compile with this
switch.

Other security features (allowed/disallowed hosts, spoof protection)
are provided by the tcpd wrapper or xinetd depending on your choice.
You can also chroot in.www if
necessary (although it shouldn't be). If you compiled with the -DONELOG
switch, a log of requests in NCSA combined format will be output
in /var/log/in.www.log

I use in.www on my slug to run my CGI playlist manager software and
stream mp3 files to the mvpmc boxes around my house. Doing this takes
just 0.3% of the slug's CPU and 84Kb of RAM per stream.

See the README for compile/install instructions.

in.proxy

in.proxy is a tiny HTTP proxy. It supports all HTTP methods, does
no caching and simply logs requests (if -DONELOG is enabled). It is
intended as a simple HTTP relay for a network.

The CONNECT method is now supported, and in.proxy can be used
as an SSL proxy. Security is handled via client filtering through
tcpd/xinetd.

See the README for compile/install instructions.

in.jabberd

in.jabberd is a tiny Jabber instant message server that is designed to run
through inetd.

Security

in.jabberd is simple to configure - /etc/in.jabberd.conf contains
a list of usernames and their passwords. Mechanisms supported are plaintext
passwords or SHA-1 digest authentication.

All users in the list are automatically each others buddies and
basic presence notifications (online/offline) will be sent to
users. This makes in.jabberd very useful for groups of
people collaborating on a single server (moreso than the normal
jabber daemons as you don't have to mess around making each
other buddies).

in.jabberd uses message files as outgoing transmit buffers for
connected users, which are
created in /tmp. To prevent unnecessary USB disk hammering on the slug,
my /tmp directory is mounted as tmpfs - this should be the case for
most Linux distributions anyway but it's worth checking.

I use this as my local chat server to replace jabberd on my slug -
it's much simpler to set up, and it just works.

It's probably also worth warning you that I've only really tested
in.jabberd with the Pidgin and Gossip instant message clients, so your
mileage may vary with other clients (Sep 2014, dummy support for
privacy lists was added for compatibility with Empathy and others).

See the README file for installation instructions.

in.smtp

in.smtp is a tiny SMTP relay server designed to run through inetd.
It will receive email via SMTP and then relay it by calling the
system sendmail binary. This means you can use a small mailer (such
as ssmtp) for
delivery out of your network. I use this to allow
my NSLU2 to act as a mailhub for my local network.

in.smtp has no inherent security filtering, although with it being
an inetd service, you can use the tcpd wrapper to restrict access to
subnets and interfaces.

in.ctcs

It supports basic bandwidth sharing and download rate monitoring (under
certain thresholds it will get more peers from the tracker or even
completely reconnect.

A sample CGI web interface (for use with in.www
or any CGI compliant webserver) is included to view downloading torrents,
control them and download new torrents from pasted links. You'll need
a minimal python installation to run the web interface (it only uses the
os, sys and datetime libs and obviously the python interpreter only runs
when you are requesting a page) and wget for torrent link downloading.

See the README file for installation instructions.

in.dns

in.dns is a miniscule DNS server designed to run through inetd.
It only handles A and PTR records (which should be enough for a small
network), is very easy to configure and like everything else on
this page is written in C with no dependencies and is fast and
small. It is deliberately aimed at small networks and low-powered
hardware where the overhead of BIND is not needed.

It uses a single config file with a simple HOST -> ADDRESS format
and infers PTR records from the first hostname for a given IP. You
can also edit the config file without having to restart it.

in.dns is authoritative for the values in its config file (ie. It
will give an answer for any fully qualified domain name you specify
in the config file), but it does not do recursive searching (it will
return a not found packet if it has no answer so that your client
can move to the next server quickly).

This has now replaced BIND on my slug for handling DNS queries on
my network.

In addition, if -DUSE_NSS is set, in.dns will act as a DNS relay
for the local NSS. This allows you to use in.dns as a DNS relay on
different subnets.

See the README file for installation instructions.

in.dhcp

in.dhcp is a complete DHCP server designed to run
through inetd.
It handles ipv4, all standard DHCP options, multiple interfaces via
xinetd, address pools, static leasing,
and is fully compatible with the ISC
DHCP, udhcp, Hauppage MVP H1+ and Wii clients (and anything you'd care
to throw at it I expect, they're just the ones I had handy to test with).

Configuring it is simple - a config file for each interface lists
static lease parameters and global parameters are set at the bottom
of the file (a sample config is included). A lease file for any dynamic
pools on each interface is written to /tmp

Optionally, if -DUSE_NSS is set, in.dhcp will use /etc/ether and the
local NSS to find hostnames and IP addresses for client MAC addresses.

See the README file for installation instructions and details on the
config file format.

in.mvp

in.mvp is an inetd version of the mvprelay.c file floating around
the net. I couldn't track down the original author, but the source
is given away freely.

It's used to respond to the broadcast packets issued by later
(H2+) revision Hauppage MVP devices - which they use to determine the
TFTP server to get their OS from.

Older MVP revisions used the DHCP siaddr
option and didn't need a new protocol (and this relay program) to
discover the TFTP server - but I guess not
many non-nerds run their own DHCP server so Hauppage had to come up
with a way for MVPs to get
an address from any old device and then find their OS.

I modified it to work from inetd, threw away the win32 specific
stuff (pah!), removed the unnecessary command line parameters and added
improved logging via syslog.