3.2.3 Gnatsd Messages

You are not on the host access list: stdin (stdin)

Q: When starting gnatsd manually (on the command line), I get ‘520 You are not on the host access list: stdin (stdin)’.

A: (GNATS 3.1xx) Gnatsd is not intended to be started manually, but via inetd, xinetd, or a similar "super server". When gnatsd is started this way, its stdin and stdout (standard input and standard output streams) are connected to a so called "TCP socket" (one end of the network connection), and from this socket gnatsd learns the IP address of the remote end (and from this it derives the remote host name). When you start gnatsd from the command line, its stdin and stdout are connected to the terminal, and thus gnatsd gets a nonsense value.

You usually need ‘root’ privileges in order to change the configuration of your "super server". If you don’t have them, contact your system administrator.

See How to Start Gnatsd for inetd and xinetd configuration.

A: (GNATS 4.0) This error message should not occur with gnatsd 4.0 anymore, because gnatsd can be started from the command line. However, this probably only makes sense for debugging and diagnosing problems. Furthermore, you need to play the part of the client program yourself (i.e., you must "speak" the gnatsd client protocol).

You are not on the host access list

Q: Gnatsd rejects connections from a remote host with the error message ‘520 You are not on the host access list’.

A: Check the file ‘gnatsd.host_access’; if you are using the default locations, this is ‘/usr/local/etc/gnats/gnatsd.host_access’. (If you are still using GNATS 3.xxx, the file is named ‘gnatsd.conf’; its default place is ‘/usr/local/etc/gnatsd.conf’.)

Each line of the file names a host and its access level, separated by colons. Gnatsd tries the lines in turn to match the remote host, and the first line that matches wins.

The first field specifies the host(s); it may be a host name (like ‘goedel.example.com’), a partial domain (like ‘*.example.com’), an IP address (like ‘192.168.1.5’), or a partial IP address (like ‘192.168.*’). If it is only ‘*’, it matches all hosts.

Depending on how IP addresses are mapped to hostnames on your gnatsd machine, you may be able to omit the domain (like in ‘goedel’). You may even need to omit the domain for some hosts.

The second field is the access level granted to the remote host. This is usually increased by the access level granted to the user as soon as (s)he logs in.

The third field is currently not used; just leave it empty (but supply the colon between the second and the third field).

Example:

#
# This is a comment
#
# Grant view access to all hosts with IP addresses
# ranging from 192.168.0.0 to 192.168.255.255:
192.168.*:view:
# Users on host goedel.example.com get (at least) edit access:
goedel.example.com:edit:
# Users from escher.example.com may view all reports, even
# confidential ones:
escher.example.com:viewconf:
# Users from bach.example.com may only view all non-confidential
# reports:
bach.example.com:view:
# Users from other example.com hosts
# only get the access specified for them in gnatsd.user_access:
*.example.com:none:
# Same for domain our-users.example:
*.our-users.example:none:
# All other hosts are rejected
# without even asking for username and password:
*:deny:

The format is described in detail in the comments at the beginning of the file.

This document was generated by Chad Walstrom on March 3, 2015 using texi2html 1.82.