CLX uses a specific file structure under its home directory ~clx_us:
ax25/ some binaries and AX.25 .tgz files
backup/ where tools/bup_db writes and reads ASCII backups
bin/ CLX binaries and clx startup/shutdown script
box/batch/start/ user startup files (profiles)
box/iclb/ mail to be forwarded
box/mail/ user mail directory
box/bulletin/ DX bulletin directory
callb/ callbook files, links to QRZ-DX CDROM
exec/command/ command extensions for all users
exec/connect/ connect scripts for CLX
exec/interpr/ command extensions for all, with message interpreter
exec/privileg/ command extensions for admin users
exec/checks/ directory for mail checking
config/ configuration files
db/ command files to create database tables
box/info/help -> Link to default language help files
box/info/help.german/ German user help files
box/info/help.english/ English user help files
box/info/help.french/ French user help files (tnx HB9BZA)
box/info/help.italian/ Italian user help files (tnx IK3HUK)
box/info/help.portuguese/ Portuguese user help files (tnx PP5AQ)
log/ directory for log files (specify in /etc/syslog.conf)
postgres/ Postgres database binaries and data
tools/ system and user administration tools
The CLX software consists of several programs which are linked
via shared memories and database entries. The server software is
being started and shutdown by the clx script, which starts
and stops the processes.
Here is a definition for each particular module
is the communication interface (AX.25, telnet sockets)
manages receive spooling.
manages transmit spooling. At a later time, this process may handle priorities. Currently all messages are in one single processing queue.
receive message dispatcher, forwards messages to other processes.
manages all user commands, user database requests, forks a process for every database task to make it run in the background. The background process later sends the results directly to send_ctl.
mailbox control. The mailbox keeps messages in a file system, header information is stored in the database.
user administration (logins, logouts, logbook).
manages external user commands and command extensions.
manages user dialogs like the set/priv sequence.
Packet Radio Bulletin Board System (PBBS) interface implementing the W0RLI mail forwarding protocol.
inter user communication (talk, conference).
inter node communication (processing and generating PCxx messages).
system administration, installing shared memory pages. It also controls cyclic jobs like building up link connections, testing with ping etc.
manages internal program communications.
manages private data tables (udt's).
special program started for special access to database. This program will be terminated when the transaction is finished.
Manages the index files in the callbook directory
~/callb. This program will be started at the start of
CLX and then finishes, after the update of these files.
When a user accesses the callbook, this program handles the
interaction between user and callbook data.
a program which is started up for each incoming PBBS
connection. PBBS systems are identified using the bbs_lst
configuration command in clx_par. See
bbs_lst for further details.
The following programs may be run from the console:
A login program for clx from the console or when started
via ax25d. net_usr is a statically linked program (except that it
needs libc.so.5). It can be run from another computer and does not need
any of the specific CLX shared libraries.
net_usr has a number of command line switches, enabling
different features:
-h <host> connect to CLX on a different host
-i necessary for batch programming. Makes net_usr read from STDIN
only when the connection to the running CLX is established.
This should make it possible to run net_usr from a shell
script reading commands from a file (like this):.
net_usr -i dl6rai <<NNNN
sh/dx/10
bye
NNNN
Unfortunately, due to CLX's multiple processes, the second
command goes through faster and so the output of the first
command never gets out. We have not found a solution to this
problem at the moment but it did not seem very important
anyway. The general problem is that CLX does not serialize
the commands but tries to work them down as soon as possible.
-r similar to the -i option above with the difference that the
program only terminates after having received a response from
CLX. It is working for an announce command like this:
echo "ann DB0BCC will be shut down now" | net_usr -r
-x Makes net_usr convert all <CR> characters to <LF> on input.
This is necessary for net_usr to run correctly under ax25d.
-m MS mode: Makes net_usr convert all <LF> to <CR><LF> on output.
This is necessary to make telnet access under MS-Windows look
nice.
Another login program with readline support, basically
providing the same functionality as net_usr but with GNU readline
support. term_usr supports exactly the same command line options
as net_usr.
Press ``ctrl-P''/``ctrl-N'' for previous/next commands, goto begin or end of line with ``ctrl-A''/``ctrl-E'' and move the cursor back and forth with ``ctrl-B''/``ctrl-F''. The standard cursor control keys may also be used.
Vi fans may also permanently switch to Vi mode by creating a file
~/.inputrc containing the line:
set editing-mode vi
Then command history and recall are available with the standard Vi
functions like <ESC>-k, <ESC>-j, etc.
term_usr supports a number of so-called inline commands for
uploading or downloading of files. This way it is easy to start writing
to a log file to document a CLX bug or you may use it for uploading
files and data to the CLX system. Commands currently supported
are:
~p print working directory
~l list current directory
~c <path> change working directory to <path>
~> <file> upload <file>
~< <file> download to <file> (appends, never overwrites)
~. finish download
~? shows a short command description
When logging to a file, all input lines are logged with leading
>>'s.
Administration tool which is being described in section Administration Tools further below.
CLX runs uses a number of tables in the postgres database. The tables are accessed through the CLX programs so the user normally doesn't even know that there are databases, tables, index etc. For the Sysop however, it may be interesting to know that there are in fact a number of tables which are read from and written to by several CLX programs.
Table Content write read
access access
----------------------------------------------------------
ann_data Announce icl_com db_san
ar_band Band Boundaries <setup> usr_req
distr_li Distribution Lists ? ?
dx_data DX-Data icl_com db_sdx
dxcc_pfx DXCC Prefix List clx_ctl usr_req
dxcc_dat DXCC Countries List clx_ctl usr_req
ml_dir Mailbox Directory mb_ctl mb_ctl
ml_file Mailbox Files mb_ctl mb_ctl
qsl_mng QSL Information usr_req db_sqsl
sys_dat System Information clx_ctl clx_ctl
us_data User Data usr_ctl usr_ctl
us_log Logbook usr_ctl db_slog
us_uhn Homenode Table icl_com,usr_ctl usr_req
wwv_data WWV Propagation Data icl_com db_swwv
-----------------------------------------------------------
The QSL database is currently empty. read_ak1a, a tool to import QSL
information from PacketCluster files is in the ~/tools directory.
Look at section
read_ak1a to find out more about this tool.
You can import a full-blown PacketCluster QSL-Database, like the
one available from DB0SDX/DL1SBF which is available on the Internet,
currently at
ftp://ftp.grossmann.com/pub/db.
This database is maintained
by DL1SBF, who has been working on the data for several years - probably
a good start for you.
The VHF Group DL-West has produced a fine database of VHF station
information for central European VHF/UHF enthusiasts. Several interesting
information from active callsigns are registered there like QTH locator,
Packet and E-Mail address, Name, type of activity etc. This database
can also be imported using the read_ak1a utility. See
read_ak1a for an exact description of the details.
The command to read in the database goes like this:
$ read_ak1a -c -t vhf vhf_150.dbf
The database is available directly from Guido, please mail him at [email protected].
The DXCC table is read from the file ~/config/cty.dat. This file
is a standard list of DXCC and WAE countries very popular and kept
up to date world wide by CT (copyright K1EA) users. A recent version is
always available from
http://www.contesting.com/ct/files/#cty.
Whenever this file changes, clx_ctl, which is the first program
started when launching CLX, will reread the table in the background.
The home node table of CLX remembers user's home nodes and sends mail messages that way. The user may either explicitly select a home node location. If he does, the information is saved permanently, regardless of logins at other places. If no home node information is entered by the user, the system takes the first login it gets to know about this user, as his home node. If the user later connects to another node, CLX waits until it has received this information five times consecutively, before it does to change the home node information accordingly.
Some of the tables have indexes:
Table Index file(s)
-----------------------------------------------------------
ann_data idx_and
distr_li idx_dli
dx_data idx_dxc, idx_dxl, idx_dxf, idx_dxd
ml_dir idx_mdd, idx_mdn
ml_file idx_mfn, idx_mfd
qsl_mng idx_qsl, idx_mng
us_data idx_usd, idx_uld
us_log idx_usl, idx_ulc
us_uhn idx_uhn
wwv_data idx_wwd
-----------------------------------------------------------
All files of the CLX database are stored in the directory
~postgres/data/base/clx_db. With clx version
3.00, indexes have again been activated. They
were switched off due to internal Postgres problems in
previous releases.
It may be of interest to you that the hardest part for the
database is retrieving ``the last n'' spots from the dx_data
table. The reason behind this is that a query is built step
by step. So when you query the last 5 records from the dx_data
table, the following happens:
The same is true for the last 5 records of 20 meters:
The more specific the query is, the less overhead. So when you look up the last KL7 station on 40 meters RTTY this job will be handled very quickly and efficiently. This is a general problem and has nothing to do with Postgres but with the use of a database in this way.
To get around this problem, we have taken two approaches:
sh/dx/5'' command is taken from and this explains why
it is so much faster than ``sh/dx 2''.
fed from.
dx_data table, we first try to
find a result
in a small time interval going back from ``now''. If this
fails the interval is
made longer and longer until the query really looks through
all data. Currently we have implemented 6 different intervals:
2 days back
8 days back
31 days back
125 days back
500 days back
all
When the query gets into the third level (31 days) it writes a message
to the user saying ``Patience. This query needs time'' (message
#205 in adv_txt).
With version 2.04 and later of CLX, it is
now possible to install your own
database tables in the Postgres database. For this, a conversion
program called read_ak1a is provided in the
~/tools directory and a set of CLX
commands for the installation and administration
of these tables exists (see
udtadmin).
This is the command set for administering the UDTs:
As a very esoteric feature, a database may be defined as follows:
create/!udt <tablename>/<flags> <clx command>
The ``!''-character denotes that the record is not being looked up but a CLX command is called when the database is being accessed. This way, CLX can make its database tables accessible to other nodes. They can access the database table through a PC44 (remote database request).
Also, this provides a way to make an alias for a database table.
Let's say, you with to export your QSL database to another node (be it CLX or Pavillion PacketCluster).
create/!udt clx_qsl/+- sh/qsl <?>
This command creates a new table called clx_qsl
which turns any request into the clx command sh/qsl.
Note that the argument to the command is passed in the
<?>. This must be specified, otherwise
sh/qsl would be called without an argument.
Not only can you make an executable table but also records in your table may contain executable statements. This allows you to collect different programs and utilities under a common command interface. The syntax here is similar:
update/<tablename> !<key> <clx command> <?>
The <?> argument is optional and if stated
will contain the command line parameter.
The ~/box directory contains a number of subdirectories
where the part of the user data is kept, which is not stored
in the postgres database. These are mail messages, mails in the
forwardig queue, user startup files, DX bulletins and the user
help files. This portion of the file system is administered
internally and you should use the Unix commands only in special
cases where you know what you are doing. Generally, each file
in this hierarchy also has a corresponding database entry and
it's always a bad idea to get the two out of sync by manually
fiddling around here. CLX provides a command interface to
this area with the privileged CLX commands PUT, GET,
LS and RM commands.
The consistency of the ~/box directory hierachy is
checked with the script mbx_chk
(see
mbx_chk), normally at CLX startup.
However, can also be called from the commandline.
This directory contains another subdirectory called start.
Below this, files are stored named after users' callsigns containing
the startup procedure they have defined using the CLX command
UPDATE/PROFILE.
This directory contains a subdirectory for every year. These
are generated automatically when an upload ocurs in a new year
or if a user explicitly specifies the year with the UPLOAD
command. The files are then stored one level below.
There is no strict convention on how users may name the
uploaded bulletin files.
The bulletin subdirectory is never changed by mbx_chk -
but mbx_chk picks up any new files in this directory
and includes them in the database. Knowing this, you may add
bulletin files at the shell prompt to these directories by
directly copying them into place and then running
mbx_chk.
The iclb directory contains subdirectories for every
partner node it forwards mail to. Under these directories you
will find files named by a number ranging from 1 to 9999. These
are files to be forwarded and the to be deleted after sucessful
completion. The destination address and other message-relevant
information is kept in the database.
Files in this directory are checked both ways by mbx_chk.
Whenever the file or the database entry is missing, the
corresponding part will be deleted. With the command rm_fwd
you may remove mail queues directed to specific nodes.
For more information on this command, see section
rm_fwd.
The info subdirectory contains both a place for the help files
(different languages) and for changible system files (like the
motd file) in ~/box/info/etc.
mbx_chk does not check this directory at all.
User help files are to be found under ~/box/info.
The old place ~/doc/user is now used for the CLX
user manual which was compiled by Ian, G0VGS, with a lot of
effort. There is a printable version and also a HTML version of
the user manual available.
The file structure in that directory is as follows:
The directory help should always be a symbolic link
to the English version of the on line help files. These
are the most current files.
Secondly, a link should be made from the language used in
your country to help.default. You should see that the
help files in that directory are well up to date with respect
to the English versions too. Additionally, there are a number
of language directories like French, Italian, German and
Portuguese. Leave them in place, if a user choses to switch
languages, these directories will be used.
If you put some work into the help files, please be sure to mail us a copy to include in a future distribution of CLX. If you are translating the help files, please be sure to take a look at section special characters.
mail subdirectory
The mail directory contains subdirectories for every user and
for standard bulletin addresses. These subdirectories then contain
files numbered from 1 to 9999 which are the true message files without
and additional information (no headers). That information is only
kept in the database.
Files in this directory are checked both ways by mbx_chk.
Whenever the file or the database entry is missing, the
corresponding part will be deleted.