CLX needs time in UTC. If you run CLX on the air, you should get
this correct. Otherwise, your node will send out DX spots with
wrong times. Look for information regarding local time settings
in a file sometimes called /usr/lib/zoneinfo/time.doc.
Generally, your CMOS clock should run on UTC, also your system clock should be on UTC. If your machine runs completely on UTC, you need not change anything. However, if you like to have clocks display local time on your computer, you must read on.
First, in the /usr/lib/zoneinfo you
should make a link from your local timezone to localtime.
Additionally, you must make a link to posixrules, as
this is needed to interpret the TZ environment variable.
Second, in both clx_us's and postgres's ~/.profile
you should set the TZ variable as follows:
TZ=GMT
export TZ
To change the CMOS clock from within Linux, you must use the
command /sbin/clock -w. At boot time, to set the
system clock from the CMOS clock, you should put /sbin/clock -au
in your start files.
Also you should see that your computer' clock is not lagging or
leading in time. There is a nice trick of keeping your clock
accurate without the need for an external time base. This is
done by first measuring the deviation over a certain period
(say one week) and then specifying this deviation in the file
/etc/adjtime.
After that, the command /sbin/clock -au will automatically
correct the hardware clock at regular intervals. The more exact
the deviation is known, the better. Look into the man page for
/sbin/clock (try man 8 clock) for exact details.
CLX makes extensive use of the syslog facility. This requires
syslogd to run. You may redirect CLX's output to different
log files. This is done in the /etc/syslog.conf file.
There are several levels of logging output. Here is
part of DB0CLX's /etc/syslog.conf file. The debug option
generates lots of output, beware! Also with lots of traffic, the
debug option generates so much traffic that the system may lock
up. This is something we have observed at DB0BCC some time ago.
When we discontinued the debug log, all was OK again.
local1,local2,local3,local4,local5.err -/usr/local/clx/log/err.log
local1,local2,local3,local4,local5.crit -/usr/local/clx/log/crit.log
local1,local2,local3,local4,local5.info -/usr/local/clx/log/io.log
# local1,local2,local3,local4,local5.debug -/usr/local/clx/log/debug.log
There is an important detail when specifying the file name:
Normally, the syslogd syncs the
file system (fsync) with every single message. This
produces a very high system
load especially when a lot of log messages ocur. With ``-'' in front
of the filename, no fsyncs are triggered and the default Unix behaviour
is used. This information is described in the syslog.conf manual
page (try man 5 syslog.conf). We recommend to use ``-'',
otherwise your system may become very slow.
When you make changes to /etc/syslog.conf, you will have to
restart syslogd with kill -1 to make it read the new
version of the file. You can deactivate entries in
the config file by putting a ``#'' in front of the commands.
Carl Makin, VK1KCM, writes that he feeds all log output into a single file with the following configuration:
local1,local2,local3,local4,local5.* /usr/local/clx/log/all.log
The CLX startup and shutdown script ~/bin/clx
also allows to check CLX's
running status, i.e. if all is well. For this, you must
call clx with the ``-c'' option.
$ clx -c
Checking clx processes...
Shared Memory manager clx_ctl: rc = OK
Internal Communications Manager int_com: rc = OK
Transmit Spooler snd_ctl: rc = OK
User Administration usr_ctl: rc = OK
Inter-User communication iu_com: rc = OK
Inter-Node communication icl_com: rc = OK
User Database Interface usr_req: rc = OK
User Data Table Manager udt_mng: rc = OK
Mailbox Controller mb_ctl: rc = OK
User Commands Manager usc_mng: rc = OK
User Dialog manager usr_dlg: rc = OK
BBS interface bbs_if: rc = OK
Received messages Dispatcher rm_disp: rc = OK
Received messages Spooler rcv_ctl: rc = OK
AX.25 interface con_ctl: rc = OK
$
Normally, all processes should return OK as their status. If one of the processes is missing, you should shutdown CLX and restart.
If this happens often, there maybe a problem with CLX, with the database or else. Please read the bugs chapter for known problems and errors.
Also clx's return status can be used to determine
a problem. CLX's own watchdog feature uses an internal
function to check its status. For more information see
CLX Watchdog.
For automatic startup you should make a link from
/sbin/init.d/rc3.d to
/usr/local/clx/tools/startup. This will then run
the appropriate startup script when Unix is starting up.
The startup file will remove any lock files, change some
parameters in the Linux kernel, then start up Postgres and
then CLX.
Contrary to the original DOS-based Pavillion software, CLX does not need to be restarted at regular intervals due to memory leakage etc. Of course there may also be bugs in the software and memory leaks, but the impact is not so dramatic and so, in general, CLX can run for a long period without a restart.
If you still decide to shut down CLX regularly or even reboot your computer, you could use the following lines for root's crontab entry:
# crontab -l
1 0 * * * /usr/local/bin/adjtime
0 2 * * * /usr/local/clx/tools/clean_log
30 2 * * * /usr/local/clx/bin/clx -s
45 2 * * * /sbin/reboot
Read this as follows:
As CLX may be instable or flakey at times, you may wish to
control its status at regular times. With release 3.03,
a watchdog concept was implemented into the core CLX software
in that all the processes update a time stamp in the shared memory
area once every sixty seconds. If all processes have timestamped that
memory location, a file named clx_stat in the ~/log
directory is being updated. A script called clx_watchdog is called
by crontab every 10 minutes and checks the status of this file. If the
file has changed in the last five minutes all is left alone. However,
if it hasn't, clx_watchdog shuts down CLX and restarts it.
To use the watchdog utility, put a line like this into your root's crontab file:
0,10,20,30,40,50 * * * * /usr/local/clx/tools/clx_watchdog
The watchdog script has undergone several changes and enhancements in the past. There is now a feature to turn off or turn back on the watchdog from the shell prompt and from inside the CLX program (as a privileged user only). The commands to control this are:
| Shell as clx_us | From within CLX (sysop mode)
---------------------------------------------------------------
Turn on | clx_watchdog on | enable/watchdog
Turn off | clx_watchdog off | disable/watchdog
Show status | clx_watchdog show | show/watchdog
---------------------------------------------------------------
This feature comes in handy when updating the CLX software or doing other time-consuming jobs when watchdog could interfere and shut down CLX when it was not really necessary.
A hint regarding this rare kernel feature. This portion is an excerpt from the Linux BootPrompt-HOWTO:
In the unlikely event of a kernel panic (i.e. an internal error that
has been detected by the kernel, and which the kernel decides is
serious enough to moan loudly and then halt everything), the default
behaviour is to just sit there until someone comes along and notices
the panic message on the screen and reboots the machine. However if a
machine is running unattended in an isolated location it may be
desirable for it to automatically reset itself so that the machine
comes back on line. For example, using `panic=30' at boot would cause
the kernel to try and reboot itself 30 seconds after the kernel panic
happened. A value of zero gives the default behaviour, which is to
wait forever.
Note that this timeout value can also be read and set via the
/proc/sys/kernel/panic sysctl interface.
There are some other things which should be started regularly.
For this, we have added sample file crontab.clx_us
file in the ~/config directory which looks like this:
# At 00:02 UTC every day, create a new MOTD file
2 0 * * * /usr/local/clx/tools/mk_motd
# At 00:11 UTC every day start database maintenance
11 0 * * * /usr/local/clx/tools/db_maint batch
This file can be activated with the following command:
$ crontab ~/config/crontab.clx_us
Whenever you make changes to this file, you must re-read
it with the crontab command or you may directly
edit the crontab entry with crontab -e.
There are several scripts in the ~/tools directory
which may be used by the system administrator.
bup_db backup or restore all CLX databases.
When called with ``-s'' the utility
will make an ASCII backup of all CLX
database tables to the directory ~/backup
plus tar all files in
the ~/box directory, which represent
any mail and bulletin files.
With ``-r'' this program will read back
the ASCII data into an empty, newly
created database and unpack the tar file.
bup_db will also
back up user defined tables and additionally send a warning
message if the formats of the old and new tables don't match.
The strategy is as follows:
When backing up, bup_db saves any CLX table which is found in
Postgres table pg_class except ar_data and sys_dat
as these may change in a future version of CLX. When restoring
data, bup_db restores everything from the ~/backup
directory except files ending in *.tmpl. This way it is possible
to also restore user defined tables.
Sometimes a new attribute has been introduced when migrating to
a new version. For example, in the transition from CLX 2.06 to 2.07
one new field in the us_data table was added which holds
the user's character set selection. When you backed up this table,
(the old) CLX did not know about this. When restoring this into
the new CLX, the number of columns in the backup did not match.
To fix this problem, you should edit the backup file in ~/backup
and add the missing number of <TAB>s to every line. this can
be done with sed, or any other editor. The sed solution looks
like this:
$ cd ~/backup
$ sed -e s/$/^I/ < us_data > us_data.new # ^I is a TAB character
$ mv us_data us_data.old
$ mv us_data.new us_data
$ bup_db -r us_data
Of course, you may simply ignore this warning and continue with a fresh
us_data table at this time.
clx_db destroy and create CLX postgres tables
clx_idx create indexes for the CLX postgres tables
These programs are used to either restart the database in case it has become corrupt or for other reasons. You should not use them in a normal situation.
The db_maint program is used for many routine maintenance
jobs. It can be called from within CLX (as a privileged user),
from the command line or via cron in batch mode. For example,
to cleanup the DX database, purge the user log, delete old
user records from the database, delete old mail messages and
finally run vacuum you could use the following crontab entry:
# at 03:08 every day, cleanup CLX database and run vacuum
8 3 * * * /usr/local/clx/tools/db_maint batch
For more details on how to use this program, see db_maint.
startup startup CLX with correct environment (.profile)
clean_log compress yesterday's logs and start a new log today
clx_watchdog check if all CLX processes are still alive and if
not, shutdown and reboot
mk_motd generate a new "Message of the Day"
You may have read about these programs before.
check checking your installation.
mk_th create some directories for mailbox (used within the clx script)
log_monitor display excerpts from the syslog
us_adm user administration tool (modify permission flags)
shmd display shared memory contents
mbx_chk a tool to check the consistency of entities under ~/box
rm_fwd a script for cleaning up mail forwarding queues
check_adv_txt a utility to help you translate the <tt/adv_txt/ file
read_ak1a a program to import PacketCluster WWV/DX/OPERNAM/QSL/FUL files
A few more details about these tools:
see section User Commands for more details.
A tool was created to keep CLX's database of files in sync with the
entries under ~/box.
mbx_chk checks if all files have corresponding entries
in the ml_file table and if all entries in the table have corresponding
files under ~/box. The remaining files/entries will be deleted. Also
files with a negative size in the database (this is when the files are listed
with ``#'' as the size symbol) will be deleted.
When do negative file sizes ocur? This is when CLX is shut down during
message forwarding.
mbx_chk may be run at any time, with CLX up or down.
This script is useful when you wish to clean up your mail forwarding
queue to a specific node. Let's say, node yy0yy has ceased to
exist but there is still a bunch of mail to be forwarded to him in your
iclb directory. To remove these mails (which can never be
sucessfully forwarded anyway), use the command rm_fwd yy0yy.
A utililty to dump shared memory contents. This program is mainly for debugging purposes so that we can ask you to mail us a shared memory dump in case you are observing a strange error.
A little program to follow the log messages which are kind of hard
to read. This script can filter out specific callsigns. Use
log_monitor -h to find out its options. Basically they are:
-f to focus on a specific callsign. Only messages to and
from that call are being shown.
-x to exclude messages to or from a specific callsign.
-w to adjust screen width of the messages. Your screen looks
bad when the messages shown are wrapping around the right
end of the terminal and continue on the next. To change this,
you can limit the number of characters shown to let's say
80 and so any longer lines will be truncated.
-s Starting time. The time must be given in a format like
``Jul 19 08:20:30''. This is for off-line monitoring of
old log files. See decription below.
Here is a sample session to show you what's possible:
$ log_monitor -f dl6rai
CLX log monitor v1.0 -- Focus: "dl6rai"
dl6rai->: Connect.
dl6rai->: *** connected to dl6rai
dl6rai<-: Hi Ben, here is "clx"! Experimental cluster-software on linux.
dl6rai<-: clx >
dl6rai->:
dl6rai->:
dl6rai<-: clx >
dl6rai->: sh/us
dl6rai->:
dl6rai<-: User:
dl6rai<-: dl6rai
dl6rai<-: clx >
dl6rai->: sh/dx/2 1
dl6rai->:
dl6rai<-: 1835.7 TI4CF 6-Oct-1996 0641Z <dl8ui>
dl6rai<-: 1842.9 D44BC 6-Oct-1996 0528Z <dl1yd>
dl6rai<-: clx >
dl6rai->: bye
dl6rai->:
dl6rai<-: Bye...
dl6rai<-: Disconnect.
This tool may also be called via the privileged command
monitor when you are logged in as a CLX admin or
superuser. You just specify the callsign to be monitored
on the command line:
monitor dl6rai
Using command f you can direct the focus to another callsign,
and with q you can leave the monitor. By default, the window
size shown is limited to 65 characters to make it look nice on a
80x24 terminal. This parameter can be changed with the w command
from inside the monitor.
When specifying a file name, you can trace an existing log file (off-line monitoring). The log file will then be traced from the begining unless you specify a starting time using the ``-s''option. This allows you to watch a specific situation to find problems or misbehaviours. When ``-s'' was specified, the log is printed in quasi-realtime, and the time given in square brackets shows when the net log entry is to be expected. Try this out if it interests you and you will quickly understand what's going on.
a tool to check translated adv_txt files for completeness
and generally helping you with translation. Please refer to
section
check_adv_txt for further
details.
This utility is provided to import data from the original PacketCluster
files DX.DAT, OPERNAM.DAT and WWV.DAT and QSL
information from a PacketCluster .ful file. Additionally,
DL8EBW's VHF database can be read using the VHF type.
The program has several flags and options:
-f Output to a file named "postgres.input". Normally
read_ak1a directly connects to the postmaster and
feeds the data into the table.
-v Be verbose
-p Generate PSQL statements instead of "COPY from"
-c Create a new table. Normally, read_ak1a appends data
to an existing table.
-t <type> Here you must specify the type of data you are
reading in. This is either DX or OPERNAM, WWV, QSL,
FUL or VHF.
-r <comment> Add a comment to the table being created. This feature
is only available when type=FUL and is being used for
creating new Udt-tables.
-k <rights> Defines with which access rights the Udt table is being
created. Default is "+-" (read-only). This feature
is only available when type=FUL.
read_ak1a transfers data to the following CLX tables:
DX.DAT dx_data
OPERNAM.DAT us_data and us_uhn
WWV.DAT wwv_data
QSL.FUL qsl_mng
*.FUL any other Udt table
Using the program is very straightforward. Let's say, you wish to import your old PacketCluster files one by one into clx. Here are the steps you have to do.
DX.DAT, OPERNAM.DAT and WWV.DAT and
some *.ful files
from PacketCluster into a temporary directory, say
~clx_us/tmp:
$ read_ak1a -t dx dx.dat
$ read_ak1a -t opernam opernam.dat
$ read_ak1a -t wwv wwv.dat
$ read_ak1a -t qsl qsl.ful
$ read_ak1a -t ful address.ful address
-c flag
and you may optionally add more flags for the Udt tables being created:
$ read_ak1a -c -t dx dx.dat
$ read_ak1a -c -t opernam opernam.dat
$ read_ak1a -c -t wwv wwv.dat
$ read_ak1a -c -t qsl qsl.ful
$ read_ak1a -c -r "Address Database" -k "++" -t ful address.ful address
If you encounter any trouble and see syntax error messages, this
indicates a problem with the original data. The files I got from DB0BCC
were partly corrupted, especially the OPERNAM.DAT contained a
lot of trash and I could only use a small part of it. To find out
where the trouble is, first create an intermediate file from the data
and take a look at it. This is what I did with my OPERNAM.DAT:
$ read_ak1a -f -t opernam opernam.dat
$ vi postgres.input
$ dd if=opernam.dat bs=196 count=121 of=opernam.new
$ read_ak1a -c -t opernam opernam.new
First I converted the complete file into the intermediate file
postgres.input and had a look at it. I decided that only the
first 121 records (who are 196 bytes long each) were useful. The rest
of the data was completely trashed.
With the dd command, I extracted the first 121 records and
wrote them to a new file opernam.new. Finally I imported this
file into my data table.
Using this program is not a prerequisite to run CLX. It just provides a way to save your long-time DX information to the new system or import some available database files into CLX. If you decide to completely start from scratch, just go ahead.
Here are a few benchmarks reading in DX.DAT files run on a 90 MHz Pentium machine with 64 MB RAM:
Reading 10,000 DX spots: 46 seconds
Reading 100,000 DX spots: 648 seconds
Reading 486,333 DX spots: 7911 seconds
There are a few commands which are reserved for the
CLX admin. Any user who
has the ``admin'' bit set in his user data record is
treated as a CLX admin. Additionally, any user who
has successfully passed the set/privi or the pw
dialog, does have admin privileges.
There are four ways to achieve admin status:
us_adm. This way, a specific callsign
is always privileged. This is for relatively private
installations where there is no fear of radio pirates.
set/priv and supplying
a password. This password must be generated using the
~/bin/get_pwd program. It is a string which is
calculated from a random number and the pw: entry
in the ~/config/clx_par file.
The dialog that follows set/priv, CLX presents you
with a code:
set/priv
Get password for: 866992064
~/bin/get_pwd.
This implies that you have Linux running locally because
~/bin/get_pwd is a statically linked ELF binary
and cannot be run under MS-DOS or Windows.
$ ~/bin/get_pwd abcdefgh 866992064
^BTg]V>FUUF
$
set/priv
Get password for: 866992064
^BTg]V>FUUF
Tnx.
dl6rai-3 de xx0xx 17-Jul-1997 1752Z clx >
Tnx. or with Sri. depending on whether you
replied with the correct password or not.
Un-setting the privileges is done with the command
set/nopriv. Users with a permanent admin status
in the user record cannot switch off their privileged
status in an way.
See
CLX parameters in ~/config/clx_par
how to specify the pw:
field in the CLX configuration file.
pw command. This is
compatible with THENET or BAYCOM password generation.
For this you must specify a password in the
~/config/clx_par file using the
baycom_pw command. The minimum length of the
baycom password is 5 characters.
dl6rai-3 de xx0xx 17-Jul-1997 1745Z clx >
pw
DB0CLX> 29 11 35 9 8
f5&94
dl6rai-3 de xx0xx 17-Jul-1997 1745Z clx >
35g0al54w4zhagltkf5&94tr904w6zhtskarel94w
^^^^^
pw off.
Users with a permanent admin status in the user record cannot
switch off their privileged status in an way.
See
CLX parameters in ~/config/clx_par how
to specify the baycom_pw:
field in the CLX configuration file.
set/priv <call>
to change the user status for <call> to
``admin''. This status is kept for the current connection only,
it is not permanent. Admin status can be removed again by using
set/nopriv <call>.
Generally, the CLX admin can use any program located under
the ~/exec/privileg directory. By default, there are a few
commands like !, which allows executing Unix commands from
the clx prompt:
! pwd
/usr/local/clx
dl6rai de db0clx 20-Jul-1997 0807Z clx >
These commands are executed with standard clx_us privileges.
Also there is an interactive shell command which allows you
to spawn a shell and interactively work with the command prompt. the
shell and ! are in fact identical, the ! is
just a Unix convention found in many programs. However, note the blank
which must go between the ! and the command.
dl6rai de db0clx 20-Jul-1997 0808Z clx >
shell
$ cd config
$ ed cluster_par
301
/bcc
-db0bcc xa+ tnt-router
s/-db0bcc/db0bcc/
w
300
q
$ exit
exit
dl6rai de db0clx 20-Jul-1997 0810Z clx >
The above is an example how you can edit the ~/config/cluster_par
file from within CLX. You may even call the
editor from the CLX command line:
dl6rai-2 de db0clx 23-Nov-1997 1834Z clx >
! ed config/cluster
301
q
dl6rai-2 de db0clx 23-Nov-1997 1834Z clx >
You can use other programs this way too the like:
! clx -c
There are a few other programs/scripts in that directory like
ps to list process status from within the CLX shell, or
a ping command to generate a PC51, or mon which
lets you call the log_monitor described in
Log Monitor.
There are some basic commands for the CLX admin to
modify any files under the ~/box subdirectory:
ls to list a directory relative to the ~/box directory
get to read a file
put to write/create a file
rm to erase a file
mkdir to create a new directory under ~/box
These commands will basically do two things:
With this you may create a new file area or change the Message of the day. With the following CLX command you can enter a new ``Message of the Day'' message:
put info/help/motd
Please refer to the section MOTD describing how to set the message of the day automatically.
Or with this command you can examine DJ0ZY's login script:
get batch/start/dj0zy
User Data Tables are general purpose database tables for storing information like addresses, IOTA information etc. These are the commands to administer these tables.
create/udt <tablename>/<flags> <cmnt> create a new table
destroy/udt <tablename> destroy an existing table
info/udt <tablename> show info about table
show/<tablename> <key> searches the key field and outputs
matching values (exact match)
show/<tablename> ~<partial key> searches the key field and outputs
matching values (partial match)
delete/<tablename> <key> delete a record
update/<tablename> <key> update a record
The names of the tables may use characters a-z,
underscore ``_'' and
the minus sign ``-''. The length of the name is limited to 3-10
characters. Internally (i.e. in Postgres) the table is created with
the prefix ``Udt_''. The structure of
the table is very simple and
essentially identical to PacketCluster's ``.ful'' style
files. There
is a case-insensitive keyword consisting of characters a-z,
underscore ``_'' and the minus sign ``-'', which
may be 1-16 characters in length.
The content field may contain roughly 8000 characters.
The information record, which is created automatically when the table is created from within CLX, may contain a comment of up to 255 characters.
There are flags for user write and user read.
These flags are specified
when the table is created with + and - characters.
The first, leftmost digit is the read symbol, the
second one is the write symbol.
++ User may read and write the table
+- User may read the table only (this is the default)
-+ User may write the table (but not read --- does this make sense?)
-- User may not read nor write the table
The information about the table (user rights, comment etc.) is contained
in the Clx_Udt_Info record. This record can not be accessed directly
by the user as all user supplied keywords are converted to lower case
before passing them on to Postgres.
The CLX admin may create or destroy Udt tables, as described in section User Data Table Commands. Please refer to this section for further details.
In order to maintain the CLX database, remove old or erroneous entries, delete old mail messages and other such tasks, a little menu-driven tool was put under the privileged path. Any user with sysop status can call up this menu. The output of the program is very limited:
db_maint
(db_maint:dl6rai) -->
The program stops and waits for your input. Using the h
command, you may list the available options:
db_maint
(db_maint:dl6rai) --> h
CLX Database maintenance program, main menu
1 -- DX Table related functions
2 -- WWV Table related functions
3 -- Statistical functions
4 -- Modify user records
5 -- User log related functions
6 -- Mailbox related functions
7 -- QSL table related functions
8 -- General functions
q -- Exit
(db_maint:clx_us) --> _
The available options are pretty self-explaining. The
db_maint program is also available from the tools
directory and can be run by cron to do periodic maintenance
jobs, like deleting old mail messages, purging log records
etc. For this to work well, db_maint silently turns off
the CLX watchdog and back on after it has finished.
Several parameters for db_maint can be specified
in the clx_par
file like aging of user records or mail messages.
For running db_maint via cron, a special mode, the ``batch'' mode
was implemented which executes a number of commands which can
be specified in the clx_par file with the
batchcommands: parameter. Other parameters can also
be set there like, for how many days log entries should be kept,
how long user records should be kept, how many days back
DX spots should be kept etc. etc.
For further details see CLX parameters in ~/config/clx_par.
With CLX version 3.03 and later, distribution lists are available. These are a kind of symbolic addresses which can be used both with mail and announce commands by the users. This is useful for sending special interest bulletins to a group of people as a private mail.
Basically there are three commands to manage the distribution lists:
set/distro to add a user to a list - a new list
will automatically be created.set/nodistro to remove a user from a distribution
list - if the iist is empty, it will automatically be
deleted.show/distro to find out who is on a specific
distribution list or which lists are available.Here is an example: Let's say we wish to create a new distribution
list called SIX for the 6 meter enthusiasts. So here we go:
set/distro six dl7av
set/distro six dj5mn
set/distro six dj1oj
Now DL7AV, DJ5MN and DJ1OJ are on the list as we can see here:
sh/distro six
dj1oj dj5mn dl7av
dl6rai de xx0xx 31-Jan-1998 2051Z clx >
To see which other lists are available, we can use the following command:
sh/distro
six ukw
dl6rai de xx0xx 31-Jan-1998 2051Z clx >
One other list named ukw is available too. To remove
DJ5MN from the SIX list, we use the following command:
set/nodistro ukw dj5mn
Thats all about distribution lists. Users can send messages to
these lists using the symbolic names instead of callsings with
the send command. Additionally, they may use the announce
command to make directed announcements to a specific distibution list.
In some countries, like the U.K. the sysop is responsible for the messages
on his system. He is required to have a means to auomatically check
for mail messages containing evil words or expressions. To make
life easier, CLX allows creating a file where you can specify bad
words. A script in the special directory ~clx_us/exec/checks
is called for every incoming mail and if the message contains a bad
word, it is disregarded. Simply list the bad words one by one (each
in a new line) in the ~/config/bad_words file.
Sample bad words file:
milk
alcohol
This bad_words file will kill all incoming messages which contain
the words milk or alcohol.
The difference between a CLX admin and superuser is
that only the superuser may give admin rights to
other users.
This is done with ``set/priv <call>''.
(See also
Achieving Admin Status).
To become a superuser, you must use the procedures described
in section
User Administration.
The first user who logs in after installing the
CLX software (usually from the console using the net_usr command)
will automatically be granted superuser rights. Note that
logins with net_usr automatically have SSID -16 if nothing
else is specified.
You may put your own command extensions into this directory.
Anything found here is executable by the user. CLX (in fact
the program usc_mng) calls the program with at least one
parameter, namely the user's callsign. If the user specifies
anything on the command line, these parameters are passed
as $2, $3, etc.
As an example for
extensions, we provide the program sun in that directory
which calculates sunrise and sunset times. When DL6RAI enters
sh/sun kl7
on the command line, the program is called from usc_mng
as follows:
~clx_us/exec/command/sh/sun dl6rai kl7
The sources of the program sun are available as an example
application. You may create your own and if you like, you may send
them to us for inclusion in future releases of the CLX software.
After a while experimenting with the external commands, it became clear that to seamlessly integrate external programs into CLX, one would need to achieve national language support too. However, adding this functionality into the external program seemed very complicated and unwise, as CLX already provides this functionality. So we took another approach.
A new directory was added to the list of command extension directories
unter ~/exec, called
~/exec/interpr. Programs in this directory are bound
to produce a slightly different output in the form:
\<msg-nr>\tab<par1>\tab<par2>\tab .... \tab<parn>\n
The first parameter is the message number requested from adv_txt.
this is a number of 1-4 figures prefixed with a backslash. This may be
followed by one or more (max. 20) parameters which are filled into
the appropriate "%s" fields in the message. The parameters must be
separated by TABs and can only be strings, no binary data. The last
parameter must end with a linefeed. The message numbers must be between
001 and 2000. Missing parameters are filled with the empty string.
CLX now takes this output and interprets it in the appropriate language and fills in the missing variables in the output string.
This tool gives you the ability
to view the status of the node, and start or stop connections to
other nodes or users. In the future, some of the features currently
provided by external tools will be integrated into clx_adm.
clx_adm comes up with an interactive surface:
#=== C L X ===#
[ Function: [
#=============#
You may now press <F2> to see the menu of available sub menus:
#=== C L X ===#
[ Function: [
#=========+-----------+
| b basics |
| c cluster |
| u user |
+-----------+
Ian Maude, G0VGS, reports that he had to set an environment variable
called TERMINFO to make this look correctly. What he did was
$ export TERMINFO=/usr/share/terminfo
before starting clx_adm.
Select a sub menu with the cursor-up/cursor-down keys or by pressing the first characters. Then press <Enter>. Selecting the basics-Menu, for example, gives you a status report of the system currently running:
#=== C L X ===#
[ Function: b [
#=+-Basics--------------------------------------------------+
| |
| Version: 4.02 emulate: 5447 |
| |
| Call: xx0xx Last Start-Up: 20-Sep-1998 0734Z |
| |
| Data-Base: on Name: clx_db Host: |
| |
+---------------------------------------------------------+
Pressing <F4> will bring up a small list to select from:
#=== C L X ===#
[ Function: b [
#=+-Basics--------------------------------------------------+
| |
| Version: 4.02 emulate: 5447 |
| +-------------+ |
| Call: | clx_par |Last Start-Up: 20-Sep-1998 0734Z |
| | cluster_par | |
| Data-B| adv_txt |: clx_db Host: |
| +-------------+ |
+---------------------------------------------------------+
This is the select list to make CLX re-read one of the two configuration files or the language dependend message files. If this action is not triggered manually, CLX will automatically notice the change of the configuration files within the next five minutes.
One can also use this feature from the command line:
$ clx_adm +b clx_par
This command will also make CLX re-read the configuration file
clx_par.
Returning to the previous menu level is possible by pressing <ESC> twice. So <ESC><ESC> brings you back to the main menu.
The second sub menu cluster allows you to instantly lock/unlock,
connect and disconnect nodes in your ~/config/cluster_par file.
You cannot
add any entries to the file here but you can force a connect. This is
a nice option for testing out new routes or connect scripts.
Press `c' or select the sub menu with the
cursor-up/cursor-down keys.
#=== C L X ===#
[ Function: c [
#=+-Cluster----------+
| |
| Call: |
| |
+------------------+
You will then be prompted for a callsign. You may now either enter
one callsign from your ~/config/cluster_par file directly or rather
press <Enter>. Now you will see the list of all currently known
nodes for selection:
#=== C L X ===#
[ Function: c [
#=+-Cluster----------+
| |
| Call: |
| +----------------------------------------------------------+
+-----| db0clx [xx0xx ] >cl act clx PC a |
| monitor [xx0xx ] >cl ^ pass clx U |
| db0bcc [xx0xx ] >cl act clx PC a |
| |
| |
| |
| |
| |
| |
| |
+----------------------------------------------------------+
This screen is actually a status report of the current link situation. It shows (in this order):
x'' or `` '')cl). This later flag will be deleted
in a future version as it does not make much sense any more.SHOW/CONFIGURATION.act) or
passive (pass).clx or -).PC) or
user mode protocol (U).a/w/x/i).You can now select one of them by pressing the <Enter> key. Now press <F4>. A list of available commands is displayed:
#=== C L X ===#
[ Function: c [
#=+-Cluster----------+
| |
| Call: db0bcc |
| +------------+
+-------| lock |
| unlock |
| connect |
| disconnect |
| ping |
+------------+
Locking means that you can temporarily lock a node callsign from being
automatically connected. The unlock function
temporarily also unlocks a
callsign from the locked list.
No permanent changes are applied to the cluster_par file,
after a restart of CLX, all changes made by lock/unlock
are gone.
You can now select one of these options or simply go back with <ESC><ESC> to the previous menu.
Finally, the third sub menu is designed for user callsigns. It looks very similar to the previous one:
#=== C L X ===#
[ Function: u [
#=+-User-------------+
| |
| Call: |
| |
+------------------+
You may now either enter a user's callsign (who must be currently connected) or simply press <Enter> to select one from the list of users currently connected. Then, pressing <F4> brings up a choice of options available.
#=== C L X ===#
[ Function: u [
#=+-User-------------+
| |
| Call: xx0xx |
| +------------+
+-------| disconnect |
| log |
+------------+
So this is it at the moment. You may also use clx_adm in a
non-interactive way by simply stating the commands on the command
line. For example:
$ clx_adm +c connect db0bcc
will make CLX instantly startup the connection to DB0BCC. Or,
$ clx_adm +u disconnect df2rg
will instantly disconnect DF2RG.