| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When GNU Anubis accepts an incoming connection, it first has to identify the remote party, i.e. determine whether it has the right to use Anubis resources and, if so, what configuration settings should be used during the session. We call this process authentication. The exact method of authentication depends on Anubis operation mode. Currently there are two modes:
This is the default mode. It is compatible with versions of GNU Anubis
up to 3.6.2. In this mode, Anubis relies on AUTH service (identd)
to authenticate users.
This mode uses SMTP AUTH mechanism to authenticate incoming connections. See section Pixie & Dixie, this is the first draft description of this mode.
Both modes have their advantages and deficiencies, which you have to weigh carefully before choosing which one to use. These are discussed below:
Deficiencies:
identd installed on his machine.
Advantages:
Deficiencies:
Advantages:
identd on their machines.
| 3.1 User Database | ||
| 3.2 Database URL | ||
| 3.3 Managing the Database |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
User Database is a place where GNU Anubis uses keeps user credentials, i.e. data used to authenticate and authorize users. The exact way of storing these data does not matter here, it will be addressed further in this manual. In this section we treat user database as an abstraction layer.
The user database consists of records. Each record keeps information about a particular user. A record consists of four fields. A field may contain some value, or be empty, in which case we say that the field has null value.
The record fields are:
SMTP AUTHIDSMTP authentication ID of the user.
AUTH PASSWORDSMTP password.
ACCOUNTSystem user name to be used.
CONFIGPath to the configuration file.
The first two fields are mandatory and must always have non-null values.
No two records in the database may have the same value of
SMTP AUTHID field. When anubis is trying to
authenticate a user, it first looks up in the database a record
with the value of SMTP AUTHID field matching AUTHID given
by the user. If no such entry is found, authentication fails.
Otherwise, anubis goes on and compares the password
supplied by the user with that from AUTH PASSWORD column.
If these match, authentication succeeds and anubis
passes to authorization state.
In this state, it first determines the user ID
(UID) to switch to. If the ACCOUNT field
is not null, its value is used as a login name of the system
account to use. If it is null, anubis switches to
the privilege level of a default not privileged user,
specified by user-notprivileged statement in the global
configuration file (see section user-notprivileged).
The final step is to parse user configuration file. If
CONFIG field is not null, its value is used as absolute
path to the configuration file. Otherwise, anubis searches
for file ‘~/.anubisrc’ (where ‘~’ denotes home directory
for the system account obtained on the previous step) and if such
a file exists, loads it.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Anubis database is identified by its URL, or Universal
Resource Locator. A URL consists of following elements
(square brackets enclose optional elements):
proto://[[user[:password]@]host]/path[params] |
The detailed description of each URL part follows:
Specifies a database protocol. The protocol describes how the database is to be accessed. In a way, it may be regarded as specifying the database type. Currently, GNU Anubis supports following database protocols:
‘text’ | A plain text file, containing users' credentials. |
‘gdbm’ | GDBM database |
‘mysql’ | MySQL database |
‘pgsql’ | PostgreSQL database |
‘postgres’ | Alias for ‘pgsql’. |
These protocols are described in detail below.
User name necessary to access the database.
User password necessary to access the database.
Domain name or IP address of a machine running the database.
A path to the database. The exact meaning of this element depends on the database protocol. It is described in detail when discussing particular database protocols.
A list of protocol-dependent parameters. Each parameter is of the
form keyword=name, parameters are separated
by semicolons.
| 3.2.1 Plain text databases | ||
| 3.2.2 Databases in GDBM format | ||
| 3.2.3 MySQL and PostgreSQL | MySQL and PostgreSQL databases |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This is the simplest database possible. It is kept in a plain text file. Each line in this file represents a single record, empty lines and lines beginning with ‘#’ (comments) sign are ignored. Records consist of fields, each field being a sequence of characters. Fields are separated by colons (‘:’, ASCII 58). If ‘:’ character occurs in a field, it is preceeded by a single backslash character (‘\\’, ASCII 92). A record must contain at least two fields.
The URL syntax for this type of databases is quite simple:
text:path |
where path specifies absolute file name of the database file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The protocol value ‘gdbm’ specifies a GDBM database. For the detailed description of GDBM system (gdbm)Top section `Introduction' in The GNU DBM Manual.
URL syntax for GDBM databases is:
gdbm:path |
where path specifies absolute file name of the database file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This is the most flexible database format. GNU Anubis 4.1.1 supports MySQL(2) and PostgreSQL(3) interfaces. No matter which of them you use, the implementation details are hidden behind a single consistent Anubis interface.
GNU Anubis supposes that all user data are kept in a single database table. This table must have at least four columns for storing SMTP ‘AUTHID’, SMTP password, system account name and path to user configuration file. Among those, only the last two may have NULL values. There is no restriction on the name of the database or the authentication table, nor on its column names. This information may be specified in URL as discussed below.
proto://[[user[:password]@host/dbname[params] |
Proto describes the exact database type to use. Use ‘mysql’ for MySQL databases and ‘pgsql’ or ‘postgres’ for PostgreSQL databases.
Optional user and password specify authentication credentials used to access the database.
Host sets domain name or IP address of the machine running the database. It may be omitted if the database resides on ‘localhost’.
The database name is specified by dbname element.
Finally, further details needed for connecting to the database may be given by URL parameters. All of them have reasonable default values, so you'll have to specify only those parameters that does not match the default values. Known parameters are:
Specifies the port number to be used when connecting to the database. If it is not specified, the behavior depends on the value of socket parameter: if socket is not present, the program will use the default port number for the given protocol (i.e. 3306 for ‘mysql’ and 5432 for ‘pgsql’.
Specifies UNIX name of the socket to connect to. This parameter cannot be used together with port (see above).
Sets the length of the buffer used to create SQL queries. Default is 1024 bytes.
Specifies the name of database table keeping where the authentication data are stored. Default is ‘users’.
Specifies the name of a column in table which holds ‘AUTHID’ value. Default is ‘authid’.
Specifies the name of a column in table which holds user password. Default is ‘passwd’.
Specifies the name of a column in table which holds the name of system account to be used for this ‘AUTHID’. Default is ‘account’.
Specifies the name of a column in table which holds path to the user's configuration file. Default is ‘rcfile’.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Managing the user database is a complex task, which looks differently from administrator's and user's point of view. The administrator have full rights on the database, it can add new records and delete or modify existing ones. A user, of course, does not have such ample rights. The only thing he is able to do is to maintain his own record in the database, provided that he already has one. If he does not, he should contact the system administrator and arrange for the creation of his record.
| 3.3.1 Administrators | The Administrator's View | |
| 3.3.2 Users | The User's View |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
All administrative tasks are done using anubisadm command —
a multipurpose tool for Anubis administrator.
The command usage syntax is:
anubisadm command [options] database-url |
where command specifies the operation to be performed on the database, options give additional operation-specific parameters, and database-url specifies the database to operate upon.
All administrative tasks can be subdivided into the following five categories:
These operations are described in detail in the following subsections .
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To create a database use anubisadm --create (or
anubisadm -c) command. Anubisadm will read database
entries from the standard input and write them to the database.
The standard input is supposed to be formatted as text database
(see section Plain text databases).
Thus to create a GDBM database from plain text file ‘userlist’, use the following command
anubisadm --create gdbm:/etc/anubis.db < userlist |
Similarly, to create an initially empty database, type
anubisadm --create gdbm:/etc/anubis.db < /dev/null |
Notice, that if you use SQL database format, ‘--create’ command does not imply creating the database structure! So, before running
anubisadm --create mysql://localhost/dbname < userlist |
make sure you create the underlying database structure (including
granting privileges to the anubis user), via the
usual procedure. Please refer to corresponding database manual
for the detailed instructions on this.
It is sometimes necessary to convert the existing user database
from one format (protocol) to another. For example, suppose you
have been running GDBM database (text:/etc/anubis.db)
for some time, but now it has grown considerably and you decided to
switch to PostgreSQL database to improve performance. To do so,
first create the database using postgres utilities. Then run
anubisadm --list text:/etc/anubis.db | \ anubisadm --create pgsql://localhost/dbname |
That's all there is to it!
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The command ‘--list’ (or ‘-l’) lists the existing database. When run without additional options, it will display all records from the database, e.g.:
anubisadm --list gdbm:/etc/anubis.db |
Among its other uses, such invocation is handy for converting user database to another format (see section Creating the Database).
If you wish to list only a particular record, specify the
AUTHID using ‘--authid’ (‘-i’) option. For example,
to list record of the user with AUTHID ‘test’,
type:
example$ anubisadm --list --authid test gdbm:/etc/anubis.db |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To add a new record use command ‘--add’ (‘-a’). Additional data are specified via the following options:
Specify the user SMTP AUTHID.
Specify user password password.
Specify system user name corresponding to the given AUTHID.
Specify configuration file to be used for this user.
For example, the following command adds a record with SMTP
AUTHID ‘test’, password ‘guessme’ and maps it
to the system account ‘gray’:
anubisadm --add --authid test --password guessme \
--user gray gdbm:/etc/anubis.db
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Removing a record is quite straightforward: use ‘--remove’
(‘-r’) command and specify AUTHID using
‘--authid’ option. For example, to remove the record created
in the previous subsection, run:
anubisadm --remove --authid test gdbm:/etc/anubis.db |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To modify an existing record use command ‘--modify’ (‘-m’). The record is identified via ‘--authid’ option. The fields to be changed are given with the following options:
Specify user password password.
Specify system user name corresponding to the given AUTHID.
Specify configuration file to be used for this user.
For example, the following command sets new configuration file name for the user ‘smith’:
anubisadm --authid smith \
--rcfile=/var/spool/anubis/common gdbm:/etc/anubis.db
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
anubisadm command [options] database-url |
Create the database.
List the contents of an existing database.
Add a new record.
Modify an existing record.
Remove an existing record.
Display program version number and exit.
Display short usage summary and exit.
Specify the authid to operate upon. This option is mandatory for ‘--add’, ‘--modify’ and ‘--remove’ commands. It may also be used with ‘--list’ command.
Specify the password for the authid. This option is mandatory for ‘--add’, ‘--modify’ and ‘--remove’ commands.
Specify the system user name corresponding to the given authid. It may be used with ‘--add’, ‘--modify’, and ‘--remove’ commands.
Specify the rc file to be used for this authid. The option may be used with ‘--add’, ‘--modify’, and ‘--remove’ commands.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Users maintain their database records using anubisusr
command. Main purpose of this command is to keep the copy of
your configuration on GNU Anubis server up to date.
. We recommend to invoke
anubisusr from your ‘~/.profile’, which will make
sure that your configuration file is up to date when you log in.
(4).
anubisusr [options] [smtp-url] |
where smtp-url is a URL of your GNU Anubis server.
Notice that if it lacks user name and password, then
anubisusr will first try to retrieve them from your
‘~/.netrc’ file (See netrc(5) for more info), and if not
found it will prompt you to supply them.
Only use SASL mechanism mech. Use this option several times to set a list of allowed mechanisms.
Verbose output. Multiple options increase the verbosity. Maximum verbosity level is 3.
Display program version number and exit.
Display short usage summary and exit.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Sergey Poznyakoff on December, 20 2008 using texi2html 1.78.