X-Git-Url: http://www.dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=sgml%2Fadminmanual.sgml;h=043f3316855970e70f2178a504db8517167ebbbe;hb=3243377f11cd9de768b6b488c6019dc841c8c583;hp=1a33fc0fd863851f9f6461292364f7446459376d;hpb=06858d299ea1490083c3ae6cc36fa67d23735914;p=spider.git diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml index 1a33fc0f..043f3316 100644 --- a/sgml/adminmanual.sgml +++ b/sgml/adminmanual.sgml @@ -1,4895 +1,1823 @@ - - -
- - - -The DXSpider Installation and Administration Manual -<author>Ian Maude, G0VGS, (ianmaude@btinternet.com) -<date>$Date$ $Revision$ -<abstract> -A reference for SysOps of the DXSpider DXCluster program. -</abstract> - -<!-- Table of contents --> -<toc> - -<!-- Begin the document --> - -<sect>Installation (Original version by Iain Philipps, G0RDI) - -<sect1>Introduction - -<P> -This section describes the installation of DX Spider v1.46 on a -<htmlurl url="http://www.redhat.com" name="RedHat"> Linux Distribution. -Wherever possible I will try to include differences for other distributions. -I do not intend to try and cover the installation of Linux or the setup -of the AX25 utilities. If you need help on this then read Iains original -installation guide that comes with the Spider distribution. - -<P> -I am assuming a general knowledge of Linux and its commands. You should -know how to use <em>tar</em> and how to edit files using your favourite editor. - -<P> -The crucial ingredient for all of this is -<htmlurl url="http://www.perl.org" name="Perl">. Earlier versions of -Spider required perl 5.004, however it is now <it>STRONGLY</it> recommended -that you use at least version 5.005_03 as this is the version being used -in the development of Spider. - -<P>In addition to the standard Red Hat distribution you will require the -following modules from <htmlurl url="http://www.cpan.org/CPAN.html" name="http://www.cpan.org/CPAN.html"> ... - -<P> -<itemize> - -<item> Data-Dumper-2.101.tar.gz -<item> TimeDate-1.10.tar.gz -<item> IO-1.20.tar.gz (for perl 5.00403 and lower) -<item> Net-Telnet-3.02.tar.gz -<item> Curses-1.05.tar.gz -<item> Time-HiRes-01.20.tar.gz - -</itemize> - -<P> - -<em>Do</em> get the latest versions of these packages and install them -but use the above list as the earliest versions usable. - -<sect1>Preparation - -<P> -I will assume that you have already downloaded the latest tarball of -the DXSpider software and are ready to install it. I am assuming version -1.46 for this section but of course you would use the latest version. - -<P> -Login as root and create a user to run the cluster under. <bf><it>UNDER -NO CIRCUMSTANCES USE ROOT AS THIS USER!</it></bf>. I am going to use -the name <em>sysop</em>. You can call it anything you wish. Depending -on your security requirements you may wish to use an existing user, -however this is your own choice. - -<P> -<tscreen><verb> -# adduser -m sysop -</verb></tscreen> - -<P> -Now set a password for the user ... - -<tscreen><verb> -# passwd sysop -# New UNIX password: -# Retype new UNIX password: -passwd: all authentication tokens updated successfully -</verb></tscreen> - -<sect1>Installing the software - -<P> -Now to unpack the DX Spider distribution, set symbolic links and group -permissions. Copy the tarball to /home/sysop and do the following. - -<tscreen><verb> -# cd ~sysop -# tar xvfz spider-1.46.tar.gz -# ln -s ~sysop/spider /spider -# groupadd -g 251 spider (or another number) -</verb></tscreen> - -If you do not have the command <em>groupadd</em> available to you simply -add a line in /etc/group by hand. - -<tscreen><verb> -# vi /etc/group (or your favorite editor) -</verb></tscreen> - -You also need to add some others to the group, including your own callsign -(this will be used as an alias) and root. The finished line in /etc/group -should look something like this - -<tt> -spider:x:251:sysop,g0vgs,root -</tt> - -<P> -The next step is to set the permissions on the Spider directory tree and files .... - -<tscreen><verb> -# chown -R sysop.spider spider -# find . -type d -exec chmod 2775 {} \; -# find . -type f -exec chmod 775 {} \; -</verb></tscreen> - -<P> -This last step allows various users of the group <em>spider</em> to have -write access to all the directories. This is not really needed just yet -but will be useful when web interfaces start to appear. - -<P> -Finally, you need to fix the permissions on the ax25_call and netrom_call -programs. Check where they are with the <em>locate</em> command and alter -the permissions with the <em>chmod</em> command like this .. - -<tscreen><verb> -# chown root ax25_call netrom_call -# chmod 4775 ax25_call netrom_call -</verb></tscreen> - -<sect1>Setting callsigns etc - -<P> -Now login to your machine as the user you created earlier. In my case that -user is called <em>sysop</em>. Once logged in, issue the following commands .... - -<tscreen><verb> -$ cd /spider -$ mkdir local -$ mkdir local_cmd -$ cp perl/DXVars.pm.issue local/DXVars.pm -$ cd local -$ vi DXVars.pm (or your favourite editor) -</verb></tscreen> - -<P> -Using the distributed DXVars.pm as a a template, set your cluster callsign, -sysop callsign and other user info to suit your own environment. Note that -this a perl file which will be parsed and executed as part of the cluster. If -you get it wrong then perl will complain when you start the cluster process. -It is important only to alter the text of any section. Some of the lines look -a little odd. Take this line for example .... - -<tt> -$myemail = "ianmaude\@btinternet.com"; -</tt> - -<P> -There appears to be an extra slash in there. However this has to be there -for the file to work so leave it in. - -<P><bf>PLEASE USE CAPITAL LETTERS FOR CALLSIGNS</bf> - -<P> -DON'T alter any file in /spider/perl, they are overwritten with every -release. Any files or commands you place in /spider/local or /spider/local_cmd -will automagically be used in preference to the ones in /spider/perl EVEN -while the cluster is running! - -<P> -Save the new file and change directory to ../perl .... - -<tscreen><verb> -$ cd ../perl -</verb></tscreen> - -<P> -Now type the following command which creates the basic user file with you as -the sysop. - -<tscreen><verb> -$ ./create_sysop.pl -</verb></tscreen> - -<sect1>Starting up for the first time - -<P> -We can now bring spider up for the first time and see if all is well or not! -It should look something like this ... - -<tscreen><verb> -$ ./cluster.pl -DXSpider DX Cluster Version 1.46 -Copyright (c) 1998 Dirk Koopman G1TLH -loading prefixes ... -loading band data ... -loading user file system ... -starting listener ... -reading existing message headers -reading cron jobs -orft we jolly well go ... -</verb></tscreen> - -<P> -If all is well then login on another term or console as <em>sysop</em> and -cd to /spider/src. Now issue the following command ... - -<tscreen><verb> -$ ./client -</verb></tscreen> - -<P> -This should log you into the cluster as the sysop under the alias callsign we -set earlier. In this case the callsign is G0VGS. The cluster callsign is set -in the DXVars.pm file in /spider/local. In this case we will assume that this -was set as GB7MBC. You should therefore see this when you login .... - -<tscreen><verb> -G0VGS de GB7MBC 19-Nov-1999 2150Z > -</verb></tscreen> - -If you do, congratulations! If not, look over the instructions again, you -have probably missed something out. You can shut spider down again with the -command .... - -<tscreen><verb> -shutdown -</verb></tscreen> - -<P> -and both the cluster and the client should return to Linux prompts. - -<sect1>The Client program - -<P> -In earlier versions of Spider, all the processes were Perl scripts. This -was fine but with a lot of users your computer memory would soon be used up. -To combat this a new client was written in "C". This client only works for -<em>incoming</em> connects at the moment. Before you can use it though it -has to be "made". CD to /spider/src and type <em>make</em>. You -should see the output on your screen and hopefully now have a small C program -called <em>client</em>. Leave it in this directory. - - -<sect>Quick installation guide - -<P> -This section is designed for experienced Spider sysops who want to install -Spider from scratch. It is simply a check list of things that need to be -done without any explanations. The name in brackets at the end of each line -is the user that should be doing that process. - -<itemize> -<item>Login as root -<item>Get the additional CPAN modules and install them (root) -<item>Create the "sysop" user and set a password (root) -<item>Put the Spider tarball in ~sysop and untar it (root) -<item>ln -s ~sysop/spider /spider (root) -<item>groupadd -g 251 spider (root) -<item>Add any more users you need to the group entry in /etc/group (root) -<item>Set the permissions on the spider tree (root) -<item>Fix permissions on ax25_call and netrom_call (root) -<item>Login as the sysop user -<item>cd to /spider (sysop) -<item>mkdir local (sysop) -<item>mkdir local_cmd (sysop) -<item>cp perl/DXVars.pm.issue local/DXVars.pm (sysop) -<item>cd to /spider/local and edit DXVars to set your details (sysop) -<item>cd ../perl (sysop) -<item>./create_sysop.pl (sysop) -<item>./cluster.pl (sysop) -</itemize> - -Spider should now be running and you should be able to login using the -client program. - -<itemize> -<item>Login as root -<item>Enter the correct line in ax25d.conf (root) -<item>Enter the correct line in /etc/services (root) -<item>Enter the correct line in /etc/inetd.conf (root) -<item>killall -HUP inetd (root) -</itemize> - -Spider should now be able to accept logins via telnet, netrom and ax25. - -<itemize> -<item>Login as sysop -<item>Start the cluster (sysop) -<item>set/node and type for links (sysop) -<item>Write any connect scripts (sysop) -<item>Edit /spider/crontab as required (sysop) -<item>Edit any other files as necessary (sysop) -<item>Set filters, hops and forwarding files (sysop) -<item>Login as root -<item>Enter the correct line in /etc/inittab (root) -</itemize> - -<sect>Configuration - -<sect1>Allowing ax25 connects from users - -<P> -As stated previously, the aim of this document is not to tell you how to -configure Linux or the ax25 utilities. However, you do need to add a line -in your ax25d.conf to allow connections to DXSpider for your users. For -each interface that you wish to allow connections on, use the following format ... - -<tscreen><verb> -default * * * * * * - sysop /spider/src/client client %u ax25 -</verb></tscreen> - -or, if you wish your users to be able to use SSID's on their callsigns .. - -<tscreen><verb> -default * * * * * * - sysop /spider/src/client client %s ax25 -</verb></tscreen> - -For most purposes this is not desirable. The only time you probably will need this is -when you need to allow other cluster nodes that are using SSID's in. In this case it -owuld probably be better to use the first example and then add a specific line for that -node like this: - -<tscreen><verb> -GB7DJK-2 * * * * * * - sysop /spider/src/client client gb7djk-2 ax25 -default * * * * * * - sysop /spider/src/client client %u ax25 -</verb></tscreen> - -<sect1>Allowing telnet connects from users - -<P> -From version 1.47 there is a new (more efficient) way of doing this (see next section) but, -if you prefer, the method of doing it described here will continue to work just fine. - -<P> -Allowing telnet connections is quite simple. Firstly you need to add a line -in /etc/services to allow connections to a port number, like this .... - -<tscreen><verb> -spdlogin 7300/tcp # spider anonymous login port -</verb></tscreen> - -Then add a line in /etc/inetd.conf like this .... - -<tscreen><verb> -spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet -</verb></tscreen> - -<P> -Once this is done, you need to restart inetd like this .... - -<tscreen><verb> -killall -HUP inetd -</verb></tscreen> - - -<P>Now login as <em>sysop</em> and cd spider/src. You can test that spider -is accepting telnet logins by issuing the following command .... - -<tscreen><verb> -./client login telnet -</verb></tscreen> - -You should get a login prompt and on issuing a callsign, you will be given -access to the cluster. Note, you will not get a password login. There seems -no good reason for a password prompt to be given so it is not asked for. - -<P> -Assuming all is well, then try a telnet from your linux console .... - -<tscreen><verb> -telnet localhost 7300 -</verb></tscreen> - -<P> -You should now get the login prompt and be able to login as before. - -<sect1>Setting up telnet connects (from 1.47 onwards) - -<P> -From version 1.47 you can chose to allow the perl cluster.pl program to -allow connections direct (i.e. not via the <tt>/spider/src/client</tt> -interface program). If you are using Windows then this is the only method -available of allowing incoming telnet connections. - -<P> -To do this you need first to remove any line that you may previously have set -up in /etc/inetd.conf. Remember to:- - -<tscreen><verb> -killall -HUP inetd -</verb></tscreen> - -<p> -to make the change happen... - -<p> -Having done that then you need to copy the file -<tt>/spider/perl/Listeners.pm</tt> to <tt>/spider/local</tt> and -then edit it. You will need to uncomment the line containing &dquot;0.0.0.0&dquot; -and select the correct port to listen on. So that it looks like this:- - -<tscreen><verb> -@listen = ( - ["0.0.0.0", 7300], -); -</verb></tscreen> - -<p>As standard, the listener will listen on all interfaces simultaniously. If you require more -control than this, you can specify each interface individually:- - -<tscreen><verb> -@listen = ( - ["gb7baa.dxcluster.net", 7300], - ["44.131.16.2", 6300], -); -</verb></tscreen> - -<p>This will only be successful if the IP addresses on each interface are static. -If you are using some kind of dynamic IP addressing then the 'default' method is the -only one which will work. - -<P> -Restart the cluster.pl program to enable the listener. - -<P> -One important difference with the internal listener is that no echoing is done by the -cluster program. Users will need to set 'local-echo' on in their telnet clients if -it isn't set automatically (as per the standards). Needless to say this will probably -only apply to Windows users. - -<sect1>Setting up for AGW Engine (1.47 onwards) - -<p>AGW Engine is a Windows based ax25 stack. You can connect to an AGW engine from Linux -as well as Windows based machines. - -<p>In order to enable access to an AGW Engine you need to copy <tt>/spider/perl/AGWConnect.pm</tt> -to <tt>/spider/local</tt> and edit it. Specifically you must:- - -<itemize> -<item> set <tt>$enable</tt> to 1. -<item> set <tt>$login</tt> and <tt>$passwd</tt> to the values set up in your AGW installation. -If you haven't set any there, then you should not touch these values. -<item> You can connect to a remote AGW engine (ie on some other machine) by changing <tt>$addr</tt> -and <tt>$port</tt> appropriately. -<item> Restart the cluster.pl program -</itemize> - - -<sect1>Setting up node connects - -<P> -In order to allow cluster node connections, spider needs to know that the -connecting callsign is a cluster node. This is the case whether the connect -is incoming or outgoing. In spider this is a simple task and can be done in -runtime. - -<P> -Later versions of Spider can distinguish different software and treat them -differently. For example, the WCY beacon cannot be handles by AK1A type -nodes as AK1A does not know what to do with PC73. There are 4 different -types of node at present and although they may not have any major -differences at the moment, it allows for compatibility. The 4 types are ... - -<tscreen><verb> -set/node (AK1A type) -set/spider -set/dxnet -set/clx -</verb></tscreen> - -<P> -For now, we will assume that the cluster we are going to connect to is an -AK1A type node. - -<P> -Start up the cluster as you did before and login as the sysop with client. -The cluster node I am wanting to make a connection to is GB7BAA but you would -obviously use whatever callsign you required. At the prompt type ... - -<tscreen><verb> -set/node gb7baa -</verb></tscreen> - -<P> -The case does not matter as long as you have a version of DXSpider later than -1.33. Earlier versions required the callsign to be in upper case. - -<P> -That is now set, it is as simple as that. To prove it, login on yet another -console as sysop, cd to spider/src and issue the command ... - -<tscreen><verb> -./client gb7baa (using the callsign you set as a node) -</verb></tscreen> - -<P> -You should get an initialisation string from DXSpider like this ... - -<tscreen><verb> -./client gb7baa -PC38^GB7MBC^~ -</verb></tscreen> - -If the callsign you just set up as a cluster node is for an incoming connect, -this is all that needs to be done. If the connection is to be outgoing then -a connection script needs to be written. - -<P> -Sometimes you make a mistake... Honest, it does happen. If you want to make a node -back to being a normal user, regardless -of what type it is, do: - -<tscreen><verb> -unset/node gb7baa -</verb></tscreen> - -<sect1>Connection scripts - -<P> -Because DXSpider operates under Linux, connections can be made using just about -any protocol; AX25, NETRom, tcp/ip, ROSE etc are all possible examples. -Connect scripts live in the /spider/connect directory and are simple ascii files. -Writing a script for connections is therefore relatively simple. - -<P> -The connect scripts consist of lines which start with the following keywords -or symbols:- - -<descrip> - -<tag/#/All lines starting with a <tt>#</tt> are ignored, as are completely - blank lines. - -<tag/timeout/<tt>timeout</tt> followed by a number is the number of seconds to wait for a - command to complete. If there is no timeout specified in the script - then the default is 60 seconds. - -<tag/abort/ <tt>abort</tt> is a regular expression containing one or more strings to look - for to abort a connection. This is a perl regular expression and is - executed ignoring case. - -<tag/connect/<tt>connect</tt> followed by ax25, agw (for Windows users) or telnet and some type dependent - information. In the case of a telnet connection, there can be up to - two parameters. - The first is the ip address or hostname of the computer you wish to - connect to and the second is the port number you want to use (this - can be left out if it is a normal telnet session). - In the case of an ax25 session then this would normally be a call to - ax25_call or netrom_call as in the example above. It is your - responsibility to get your node and other ax25 parameters to work - before going down this route! - -<tag/'/<tt>'</tt> is the delimiting character for a word or phrase of an expect/send - line in a chat type script. The words/phrases normally come in pairs, - either can be empty. Each line reads input from the connection until - it sees the string (or perl regular expression) contained in the - left hand string. If the left hand string is empty then it doesn't - read or wait for anything. The comparison is done ignoring case. - When the left hand string has found what it is looking for (if it is) - then the right hand string is sent to the connection. - This process is repeated for every line of chat script. - -<tag/client/<tt>client</tt> starts the connection, put the arguments you would want here - if you were starting the client program manually. You only need this - if the script has a different name to the callsign you are trying to - connect to (i.e. you have a script called other which actually - connects to GB7DJK-1 [instead of a script called gb7djk-1]). -</descrip> - - -There are many possible ways to configure the script but here are three examples, -one for a NETRom/AX25 connect, one for AGW engines and one for tcp/ip. - -<tscreen><verb> -timeout 60 -abort (Busy|Sorry|Fail) -# don't forget to chmod 4775 netrom_call! -connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh -'Connect' '' -'Connect' 'c np7' -'Connect' 'c gb7dxm' -# you can leave this out if you call the script 'gb7dxm' -client gb7dxm ax25 -</verb></tscreen> - -<P> - -<tscreen><verb> -timeout 60 -abort (Busy|Sorry|Fail) -# this does exactly the same as the previous example -# the '1' is the AGW port number to connect thru for g1tlh -connect agw 1 g1tlh -'Connect' '' -'Connect' 'c np7' -'Connect' 'c gb7dxm' -# you can leave this out if you call the script 'gb7dxm' -client gb7dxm ax25 -</verb></tscreen> - -<P> - -<tscreen><verb> -timeout 15 -connect telnet dirkl.tobit.co.uk -'login' 'gb7djk' -'word' 'gb7djk' -# tell GB7DJK-1 that it is connected to GB7DJK -# you can leave this out if you call this script 'gb7djk' -client gb7djk telnet -</verb></tscreen> - -<P> -Both these examples assume that everything is set up properly at the other end. -You will find other examples in the /spider/examples directory. - -<sect1>Starting the connection - -<P> -You start the connection, from within a sysop enabled cluster login, by typing -in the word <em>connect</em> followed by a script name like this .... - -<tscreen><verb> -G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1 -connection to GB7DJK-1 started -G0VGS de GB7MBC 13-Dec-1998 2043Z > -</verb></tscreen> - -This will start a connection using the script called <em>gb7djk-1</em>. You can -follow the connection by watching the term or console from where you started -<em>cluster.pl</em>. From version 1.47 onwards, you will need to <tt>set/debug connect</tt> first. -You should see something like this ... - -<tscreen><verb> -<- D G1TLH connect gb7djk-1 --> D G1TLH connection to GB7DJK-1 started --> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z > -timeout set to 15 -CONNECT sort: telnet command: dirkl.tobit.co.uk -CHAT "login" -> "gb7djk" -received " -Red Hat Linux release 5.1 (Manhattan) -Kernel 2.0.35 on an i586 -" -received "login: " -sent "gb7djk" -CHAT "word" -> "gb7djk" -received "gb7djk" -received "Password: " -sent "gb7djk" -Connected to GB7DJK-1, starting normal protocol -<- O GB7DJK-1 telnet --> B GB7DJK-1 0 -GB7DJK-1 channel func state 0 -> init -<- D GB7DJK-1 -<- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1 -<- D GB7DJK-1 PC38^GB7DJK-1^~ -<- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime -0 00:00^5447^~ - etc - -</verb></tscreen> - -<P> -With later versions of Spider there is a set/login command for users. This -tells them when a user or node logs in or out. If you do not add a line to -your scripts after the final line (or before the client line which should always -be last if needed) then the login/logout information will be sent to users -<it>before</it> the login actually completes. This means if a node is -unreachable, it will continue sending logins and logouts to users even though it -is not actually connecting. To avoid this use the following line ... - -<tscreen><verb> -'connect' '' -</verb></tscreen> - -<P> -In a script, this might look like ... - -<tscreen><verb> -timeout 35 -abort (Busy|Sorry|Fail) -connect telnet mary 3000 -'ogin:' 'gb7mbc' -'>' 'telnet 44.131.93.96 7305' -'connect' '' -</verb></tscreen> - -<sect1>Telnet echo - -<P> -Cluster links in particular suffer greatly from the presence of telnet echo. -This is caused by the telnet negotiation itself and can create at worst severe -loops. At best it creates unnecessary bandwidth and large logfiles! There are -things that can be done to limit this problem but will not always work dependent -on the route taken to connect. - -<P> -Telnet echo itself should only be a problem if the connection is being made to -the telnet port (23). This port uses special rules that include echo negotiation. -If the connection is to a different port, such as 7300, this negotiation does -not happen and therefore no echo should be present. - -<P> -Sometimes it is not possible to make a direct connection to another node and this -can cause problems. There is a way of trying to suppress the telnet echo but -this will not always work, unfortunately it is difficult to be more specific. -Here is an example of what I mean ... - -<tscreen><verb> -timeout 35 -abort (Busy|Sorry|Fail) -connect telnet mary.lancs.ac.uk -'ogin:' 'gb7mbc' -'word:' 'mypasswd' -'\$' 'stty -echo raw' -'\$' 'telnet 44.131.93.96' -'connect' '' -</verb></tscreen> - -So, the first connection is made by Spider. This is fine as Spider uses the -Net_Telnet script from within perl. This actually uses TCP rather than TELNET -so no negotiation will be done on the first connection. Once connected to -mary.lancs.ac.uk, the command is sent to suppress echo. Now a telnet is made -to a cluster node that is accepting connections on port 23. The problem with -this link is that the negotiation is made by the remote machine, therefore you -have no control over it. The chances are that this link will create echo and -there will be no way you can stop it. - - -<sect>Automating things - -<P> -Ok, you should now have DXSpider running nicely and allowing connects by cluster -nodes or users. However, it has to be shutdown and restarted manually and if -connection scripts fail they have to be started again manually too, not much use -if you are not at the console! So, in this section we will automate both. -Firstly starting the cluster. - -<sect1>Autostarting the cluster - -<P> -This is not only a way to start the cluster automatically, it also works as a -watchdog, checking the sanity of DXSpider and respawning it should it crash for -any reason. Before doing the following, shutdown the cluster as you did earlier. - -<P> -Login as root and bring up the /etc/inittab file in your favourite editor. Add -the following lines to the file near the end ... - -<tscreen><verb> -##Start DXSpider on bootup and respawn it should it crash -DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7 -</verb></tscreen> - -<P> -This line works fine for RedHat distributions. It is also fine for SuSE up to -7.0. From Suse 7.1 you need to add runlevels 2 and 5 like this ... - -<tscreen><verb> -DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7 -</verb></tscreen> - - -The line required for Slackware distributions is slightly different. My thanks to -Aurelio, PA3EZL for this information. - -<tscreen><verb> -DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7 -</verb></tscreen> - -<P> -This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart -it should it crash for any reason. - -<P> -As root type the command <em>telinit q</em>. DXSpider should start up -immediately. You will see the output on tty7 and if you login as <em>sysop</em> -you should find everything running nicely. - -<P> -So far so good, now to automate script connections... - -<sect1>The crontab file - -<P> -Login as <em>sysop</em> and create a file in /spider/local_cmd called crontab. -Edit it with your favourite editor and add a line like this (I have included -a comment) - -<tscreen><verb> -# check every 10 minutes to see if gb7xxx is connected and if not -# start a connect job going - -0,10,20,30,40,50 * * * * start_connect('gb7xxx') if unless connected('gb7xxx') -</verb></tscreen> - -<P> -The callsign involved will be the callsign of the cluster node you are -going to connect to. This will now check every 10 minutes to see if -gb7xxx is connected, if it is then nothing will be done. If it is not, -then a connect attempt will be started. - -<P> -There are probably lots of other things you could use this crontab file for. -If you want to know more about it, look at the -<htmlurl url="http://www.dxcluster.org/cron.html" name="DXSpider"> website -at the cron page where it is explained more fully. - -<sect>Hop control - -<P> -Starting with version 1.13 there is simple hop control available on a per -node basis. Also it is possible to isolate a network completely so that you -get all the benefits of being on that network, but can't pass on information -from it to any other networks you may be connected to (or vice versa). - -<sect1>Basic hop control - -<P> -In /spider/data you will find a file called hop_table.pl. This is the file -that controls your hop count settings. It has a set of default hops on the -various PC frames and also a set for each node you want to alter the hops for. -You may be happy with the default settings of course, but this powerful tool -can help to protect and improve the network. The file will look something -like this ... - -<tscreen><verb> -# -# hop table construction -# - -package DXProt; - -# default hopcount to use -$def_hopcount = 5; - -# some variable hop counts based on message type -%hopcount = -( - 11 => 10, - 16 => 10, - 17 => 10, - 19 => 10, - 21 => 10, -); - - -# the per node hop control thingy - - -%nodehops = - - GB7ADX => { 11 => 8, - 12 => 8, - 16 => 8, - 17 => 8, - 19 => 8, - 21 => 8, - }, - - GB7UDX => { 11 => 8, - 12 => 8, - 16 => 8, - 17 => 8, - 19 => 8, - 21 => 8, - }, - GB7BAA => { - 11 => 5, - 12 => 8, - 16 => 8, - 17 => 8, - 19 => 8, - 21 => 8, - }, -}; -</verb></tscreen> - -<P> -Each set of hops is contained within a pair of curly braces and contains a -series of PC frame types. PC11 for example is a DX spot. The figures here -are not exhaustive but should give you a good idea of how the file works. - -<P> -You can alter this file at any time, including whilst the cluster is running. -If you alter the file during runtime, the command <em>load/hops</em> will -bring your changes into effect. - -<sect1>Isolating networks - -<P> -It is possible to isolate networks from each other on a "gateway" node using the - <em>set/isolate <node_call></em> command. - -<P> -The effect of this is to partition an isolated network completely from another -nodes connected to your node. Your node will appear on and otherwise behave -normally on every network to which you are connected, but data from an isolated -network will not cross onto any other network or vice versa. However all the -spot, announce and WWV traffic and personal messages will still be handled -locally (because you are a real node on all connected networks), that is locally -connected users will appear on all networks and will be able to access and -receive information from all networks transparently. All routed messages will -be sent as normal, so if a user on one network knows that you are a gateway for -another network, he can still still send a talk/announce etc message via your -node and it will be routed across. - -<P> -The only limitation currently is that non-private messages cannot be passed down -isolated links regardless of whether they are generated locally. This will change -when the bulletin routing facility is added. - -<P> -If you use isolate on a node connection you will continue to receive all -information from the isolated partner, however you will not pass any information -back to the isolated node. There are times when you would like to forward only -spots across a link (maybe during a contest for example). To do this, isolate -the node in the normal way and put in a filter in the /spider/filter/spots -directory to override the isolate. This filter can be very simple and consists -of just one line .... - -<tscreen><verb> -$in = [ - [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count -]; -</verb></tscreen> - -<P> -There is a lot more on filtering in the next section. - -<sect>Filtering (Old Style upto v1.44) - -<P> -Filters can be set for spots, announcements and WWV. You will find the -directories for these under /spider/filter. You will find some examples in -the directories with the suffix <em>.issue</em>. There are two types of -filter, one for incoming information and one for outgoing information. -Outgoing filters are in the form <em>CALLSIGN.pl</em> and incoming filters -are in the form <em>in_CALLSIGN.pl</em>. Filters can be set for both nodes -and users. - -<P> -All filters work in basically the same way. There are several elements -delimited by commas. There can be many lines in the filter and they are -read from the top by the program. When writing a filter you need to think -carefully about just what you want to achieve. You are either going to write -a filter to <em>accept</em> or to <em>reject</em>. Think of a filter as -having 2 main elements. For a reject filter, you would have a line or multiple -lines rejecting the things you do not wish to receive and then a default line -accepting everything else that is not included in the filter. Likewise, for an -accept filter, you would have a line or multiple lines accepting the things you -wish to receive and a default line rejecting everthing else. - -<P> -In the example below, a user requires a filter that would only return SSB spots -posted in Europe on the HF bands. This is achieved by first rejecting the CW -section of each HF band and rejecting all of VHF, UHF etc based on frequency. -Secondly, a filter rule is set based on CQ zones to only accept spots posted in -Europe. Lastly, a default filter rule is set to reject anything outside the filter. - -<tscreen><verb> -$in = [ - [ 0, 0, 'r', # reject all CW spots - [ - 1800.0, 1850.0, - 3500.0, 3600.0, - 7000.0, 7040.0, - 14000.0, 14100.0, - 18068.0, 18110.0, - 21000.0, 21150.0, - 24890.0, 24930.0, - 28000.0, 28180.0, - 30000.0, 49000000000.0, - ] ,1 ], - [ 1, 11, 'n', [ 14, 15, 16, 20, 33, ], 15 ], #accept EU - [ 0, 0, 'd', 0, 1 ], # 1 = want, 'd' = everything else -]; -</verb></tscreen> - -<P> -The actual elements of each filter are described more fully in the following -sections. - -<sect1>Spots - -<P> -The elements of the Spot filter are .... - -<tscreen><verb> -[action, field_no, sort, possible_values, hops] -</verb></tscreen> - -<P> -There are 3 elements here to look at. Firstly, the action element. This is -very simple and only 2 possible states exist, accept (1) or drop (0). - -<P> -The second element is the field_no. There are 13 possiblities to choose from -here .... - -<tscreen><verb> - 0 = frequency - 1 = call - 2 = date in unix format - 3 = comment - 4 = spotter - 5 = spotted dxcc country - 6 = spotter's dxcc country - 7 = origin - 8 = spotted itu - 9 = spotted cq - 10 = spotter's itu - 11 = spotter's cq - 12 = callsign of the channel on which the spot has appeared -</verb></tscreen> - -<P> -The third element tells us what to expect in the fourth element. There are -4 possibilities .... - -<tscreen><verb> - n - numeric list of numbers e.g. [ 1,2,3 ] - r - ranges of pairs of numbers e.g. between 2 and 4 or 10 to 17 - [ 2,4, 10,17 ] - a - an alphanumeric regex - d - the default rule -</verb></tscreen> - -<P> -The fifth element is simply the hops to set in this filter. This would only -be used if the filter was for a node of course and overrides the hop count in -hop_table.pl. - -<P> -So, let's look at an example spot filter. It does not matter in the example -who the filter is to be used for. So, what do we need in the filter? We need -to filter the spots the user/node requires and also set a default rule for -anything else outside the filter. Below is a simple filter that stops spots -arriving from outside Europe. - -<tscreen><verb>$in = [ - [ 0, 4, 'a', '^(K|N|A|W|VE|VA|J)'], # 0 = drop, 'a' = alphanumeric - [ 1, 0, 'd', 0, 1 ], # 1 = want, 'd' = everything else - ]; -</verb></tscreen> - -<P> -So the filter is wrapped in between a pair of square brackets. This tells -Spider to look in between these limits. Then each line is contained within -its own square brackets and ends with a comma. Lets look carefully at the first -line. The first element is 0 (drop). Therefore anything we put on this line -will not be accepted. The next element is 4. This means we are filtering by -the spotter. The third element is the letter "a" which tells the program to -expect an alphanumeric expression in the fourth element. The fourth element -is a list of letters separated by the pipe symbol. - -<P> -What this line does is tell the program to drop any spots posted by anyone in -the USA, Canada or Japan. - -<P> -The second line is the default rule for anything else. The "d" tells us this -and the line simply reads... accept anything else. - -<P> -You can add as many lines as you need to complete the filter but if there are -several lines of the same type it is neater to enclose them all as one line. -An example of this is where specific bands are set. We could write this like -this .... - -<tscreen><verb> -[ 0,0,'r',[1800.0, 2000.0], 1], -[ 0,0,'r',[10100.0, 10150.0], 1], -[ 0,0,'r',[14000.0, 14350.0], 1], -[ 0,0,'r',[18000.0, 18200.0], 1], -</verb></tscreen> - -<P> -But the line below achieves the same thing and is more efficient .... - -<tscreen><verb> - [ 0, 0, 'r', - [ - 1800.0, 2000.0, # top band - 10100.0, 10150.0, # WARC - 14000.0, 14350.0, # 20m - 18000.0, 18200.0, # WARC - [ ,1 ], -</verb></tscreen> - - -<sect1>Announcements - -<P> -<tscreen><verb> - -# This is an example announce or filter allowing only West EU announces -# -# The element list is:- -# 0 - callsign of announcer -# 1 - destination * = all, <callsign> = routed to the node -# 2 - text -# 3 - * - sysop, <some text> - special list eg 6MUK, ' ', normal announce -# 4 - origin -# 5 - 0 - announce, 1 - wx -# 6 - channel callsign (the interface from which this spot came) - -$in = [ - [ 1, 0, 'a', '^(P[ABCDE]|DK0WCY|G|M|2|EI|F|ON)' ], - [ 0, 0, 'd', 0 ] -]; -</verb></tscreen> - -In this example, only the prefixes listed will be allowed. It is possible to -be quite specific. The Dutch prefix "P" is followed by several secondary -identifiers which are allowed. So, in the example, "PA" or "PE" would be ok -but not "PG". It is even possible to allow information from a single callsign. -In the example this is DK0WCY, to allow the posting of his Aurora Beacon. - -<sect1>WWV - -<P> -<tscreen><verb> - -# This is an example WWV filter -# -# The element list is:- -# 0 - nominal unix date of spot (ie the day + hour:13) -# 1 - the hour -# 2 - SFI -# 3 - K -# 4 - I -# 5 - text -# 6 - spotter -# 7 - origin -# 8 - incoming interface callsign - -# this one doesn't filter, it just sets the hop count to 6 and is -# used mainly just to override any isolation from WWV coming from -# the internet. - -$in = [ - [ 1, 0, 'd', 0, 6 ] -]; - -</verb></tscreen> - -<P> -It should be noted that the filter will start to be used only once a user/node -has logged out and back in again. -<P> -I am not going to spend any more time on these filters now as they will become -more "comprehensive" in the near future. - -<sect>Filtering (New Style v1.45 and later) - -<sect1>General filter rules - -<P> -Upto v1.44 it was not possible for the user to set their own filters. From -v1.45 though that has all changed. It is now possible to set filters for just -about anything you wish. If you have just updated from an older version of -DXSpider you will need to update your new filters. You do not need to do -anything with your old filters, they will be renamed as you update. - -<P> -There are 3 basic commands involved in setting and manipulating filters. These -are <em>accept</em>, <em>reject</em> and <em>clear</em>. First we will look -generally at filtering. There are a number of things you can filter in the -DXSpider system. They all use the same general mechanism. - -<P> -In general terms you can create a 'reject' or an 'accept' filter which can have -up to 10 lines in it. You do this using, for example ... - -<tscreen><verb> -accept/spots ..... -reject/spots ..... -</verb></tscreen> - -where ..... are the specific commands for that type of filter. There are filters -for spots, wwv, announce, wcy and (for sysops) connects. See each different -accept or reject command reference for more details. - -There is also a command to clear out one or more lines in a filter. They are ... - -<tscreen><verb> -clear/spots 1 -clear/spots all -</verb></tscreen> - -There is clear/xxxx command for each type of filter. - -<P> -and you can check that your filters have worked by the command ... - -<tscreen><verb> -show/filter -</verb></tscreen> - -<P> -For now we are going to use spots for the examples, but you can apply the same -principles to all types of filter. - -<sect1>Types of filter - -<P> -There are two main types of filter, <em>accept</em> or <em>reject</em>. You -can use either to achieve the result you want dependent on your own preference -and which is more simple to do. It is pointless writing 8 lines of reject -filters when 1 accept filter would do the same thing! Each filter has 10 -lines (of any length) which are tried in order. If a line matches then the -action you have specified is taken (ie reject means ignore it and accept -means take it) - -<P> -If you specify reject filters, then any lines that arrive that match the filter -will be dumped but all else will be accepted. If you use an accept filter, -then ONLY the lines in the filter will be accepted and all else will be dumped. -For example if you have a single line <em>accept</em> filter ... - -<tscreen><verb> -accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16) -</verb></tscreen> - -then you will <em>ONLY</em> get VHF spots <em>from</em> or <em>to</em> CQ zones -14, 15 and 16. - -<P> -If you set a reject filter like this ... - -<tscreen><verb> -reject/spots on hf/cw -</verb></tscreen> - -Then you will get everything <em>EXCEPT</em> HF CW spots. You could make this -single filter even more flexible. For example, if you are interested in IOTA -and will work it even on CW even though normally you are not interested in -CW, then you could say ... - -<tscreen><verb> -reject/spots on hf/cw and not info iota -</verb></tscreen> - -But in that case you might only be interested in iota and say:- - -<tscreen><verb> -accept/spots not on hf/cw or info iota -</verb></tscreen> - -which achieves exactly the same thing. You should choose one or the other -until you are comfortable with the way it works. You can mix them if you -wish (actually you can have an accept AND a reject on the same line) but -don't attempt this until you are sure you know what you are doing! - -<P> -You can arrange your filter lines into logical units, either for your own -understanding or simply convenience. Here is an example ... - -<tscreen><verb> -reject/spots 1 on hf/cw -reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16) -</verb></tscreen> - -What this does is to ignore all HF CW spots and also rejects any spots on VHF -which don't either originate or spot someone in Europe. - -<P> -This is an example where you would use a line number (1 and 2 in this case), if -you leave the digit out, the system assumes '1'. Digits '0'-'9' are available. -This make it easier to see just what filters you have set. It also makes it -more simple to remove individual filters, during a contest for example. - -<P> -You will notice in the above example that the second line has brackets. Look -at the line logically. You can see there are 2 separate sections to it. We -are saying reject spots that are VHF or above <em>APART</em> from those in -zones 14, 15 and 16 (either spotted there or originated there). If you did -not have the brackets to separate the 2 sections, then Spider would read it -logically from the front and see a different expression entirely ... - -<tscreen><verb> -(on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16 -</verb></tscreen> - -The simple way to remember this is, if you use OR - use brackets. Whilst we are -here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'. - -As mentioned earlier, setting several filters can be more flexible than -simply setting one complex one. Doing it in this way means that if you want -to alter your filter you can just redefine or remove one or more lines of it or -one line. For example ... - -<tscreen><verb> -reject/spots 1 on hf/ssb -</verb></tscreen> - -would redefine our earlier example, or - -<tscreen><verb> -clear/spots 1 -</verb></tscreen> - -To remove all the filter lines in the spot filter ... - -<tscreen><verb> -clear/spots all -</verb></tscreen> - -<sect1>Filter options - -<P> -You can filter in several different ways. The options are listed in the -various helpfiles for accept, reject and filter. - -<sect1>Default filters - -<P> -Sometimes all that is needed is a general rule for node connects. This can -be done with a node_default filter. This rule will always be followed, even -if the link is isolated, unless another filter is set specifically. Default -rules can be set for nodes and users. They can be set for spots, announces, -WWV and WCY. They can also be used for hops. An example might look like -this ... - -<tscreen><verb> -accept/spot node_default by_zone 14,15,16,20,33 -set/hops node_default spot 50 -</verb></tscreen> - -This filter is for spots only, you could set others for announce, WWV and WCY. -This filter would work for ALL nodes unless a specific filter is written to -override it for a particular node. You can also set a user_default should -you require. It is important to note that default filters should be -considered to be "connected". By this I mean that should you override the -default filter for spots, you need to add a rule for the hops for spots also. - -<sect1>Advanced filtering - -<P> -Once you are happy with the results you get, you may like to experiment. - -<P> -The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU -can be written with a mixed filter, for example ... - -<tscreen><verb> -rej/spot on hf/cw -acc/spot on 0/30000 -acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16) -</verb></tscreen> - -Note that the first filter has not been specified with a number. This will -automatically be assumed to be number 1. In this case, we have said <em>reject all -HF spots in the CW section of the bands but accept all others at HF. Also -accept anything in VHF and above spotted in or by operators in the zones -14, 15 and 16</em>. Each filter slot actually has a 'reject' slot and -an 'accept' slot. The reject slot is executed BEFORE the accept slot. - -<P> -It was mentioned earlier that after a reject test that doesn't match, the default -for following tests is 'accept', the reverse is true for 'accept'. In the example -what happens is that the reject is executed first, any non hf/cw spot is passed -to the accept line, which lets through everything else on HF. The next filter line -lets through just VHF/UHF spots from EU. - - -<sect>Other filters - -<sect1>Filtering Mail - -<P> -In the /spider/msg directory you will find a file called badmsg.pl.issue. Rename -this to badmsg.pl and edit the file. The original looks something like this .... - -<tscreen><verb> - -# the list of regexes for messages that we won't store having -# received them (bear in mind that we must receive them fully before -# we can bin them) - - -# The format of each line is as follows - -# type source pattern -# P/B/F T/F/O/S regex - -# type: P - private, B - bulletin (msg), F - file (ak1a bull) -# source: T - to field, F - from field, O - origin, S - subject -# pattern: a perl regex on the field requested - -# Currently only type B and P msgs are affected by this code. -# -# The list is read from the top down, the first pattern that matches -# causes the action to be taken. - -# The pattern can be undef or 0 in which case it will always be selected -# for the action specified - - - -package DXMsg; - -@badmsg = ( -'B', 'T', 'SALE', -'B', 'T', 'WANTED', -'B', 'S', 'WANTED', -'B', 'S', 'SALE', -'B', 'S', 'WTB', -'B', 'S', 'WTS', -'B', 'T', 'FS', -); -</verb></tscreen> - -<P> -I think this is fairly self explanatory. It is simply a list of subject -headers that we do not want to pass on to either the users of the cluster or -the other cluster nodes that we are linked to. This is usually because of -rules and regulations pertaining to items for sale etc in a particular country. - -<sect1>Filtering DX callouts (Depricated) - -<P> -<bf><it>From version 1.47, this method is replaced by the command set/baddx</it></bf> - -<P> -In the same way as mail, there are some types of spot we do not wish to pass on -to users or linked cluster nodes. In the /spider/data directory you will find -a file called baddx.pl.issue. Rename this to baddx.pl and edit the file. The -original looks like this .... - -<tscreen><verb> - -# the list of dx spot addresses that we don't store and don't pass on - - -package DXProt; - -@baddx = qw - - FROG - SALE - FORSALE - WANTED - P1RATE - PIRATE - TEST - DXTEST - NIL - NOCALL -); -</verb></tscreen> - -<P> -Again, this is simply a list of names we do not want to see in the spotted -field of a DX callout. - - -<sect1>Filtering words from text fields in Announce, Talk and DX spots - -<P> -Create a file in /spider/data called <em>badwords</em>. The format is quite -simple. Lines beginning with # are ignored so comments can be added. An -example file is below ... - -<tscreen><verb> -# Below is a list of words we do not wish to see on the cluster -grunge grunged grunging -splodge splodger splodging -grince -fluffle -</verb></tscreen> - -Multiple words can be used on the same line as shown. Obviously these -are just examples :-) - -<P> -You can reload the file from the cluster prompt as sysop with load/badwords. - -<sect>Mail - -<P> -DXSpider deals seamlessly with standard AK1A type mail. It supports both -personal and bulletin mail and the sysop has additional commands to ensure -that mail gets to where it is meant. DXSpider will send mail almost -immediately, assuming that the target is on line. However, only one -mail message is dealt with at any one time. If a mail message is already -being sent or recieved, then the new message will be queued until it has -finished. - -The cluster mail is automatically deleted after 30 days unless the sysop -sets the "keep" flag using the <em>msg</em> command. - -<sect1>Personal mail - -<P> -Personal mail is sent using the <em>sp</em> command. This is actually the -default method of sending mail and so a simple <em>s</em> for send will do. -A full list of the send commands and options is in the <em>command set</em> -section, so I will not duplicate them here. - -<sect1>Bulletin mail - -<P> -Bulletin mail is sent by using the <em>sb</em> command. This is one of the -most common mistakes users make when sending mail. They send a bulletin -mail with <em>s</em> or <em>sp</em> instead of <em>sb</em> and of course -the message never leaves the cluster. This can be rectified by the sysop -by using the <em>msg</em> command. - -<P>Bulletin addresses can be set using the Forward.pl file. - -<sect1>Forward.pl - -<P> -DXSpider receives all and any mail sent to it without any alterations needed -in files. Because personal and bulletin mail are treated differently, there -is no need for a list of accepted bulletin addresses. It is necessary, however, -to tell the program which links accept which bulletins. For example, it is -pointless sending bulletins addresses to "UK" to any links other than UK -ones. The file that does this is called forward.pl and lives in /spider/msg. -At default, like other spider files it is named forward.pl.issue. Rename it -to forward.pl and edit the file to match your requirements. -The format is below ... - -<tscreen><verb> -# -# this is an example message forwarding file for the system -# -# The format of each line is as follows -# -# type to/from/at pattern action destinations -# P/B/F T/F/A regex I/F [ call [, call ...] ] -# -# type: P - private, B - bulletin (msg), F - file (ak1a bull) -# to/from/at: T - to field, F - from field, A - home bbs, O - origin -# pattern: a perl regex on the field requested -# action: I - ignore, F - forward -# destinations: a reference to an array containing node callsigns -# -# if it is non-private and isn't in here then it won't get forwarded -# -# Currently only type B msgs are affected by this code. -# -# The list is read from the top down, the first pattern that matches -# causes the action to be taken. -# -# The pattern can be undef or 0 in which case it will always be selected -# for the action specified -# -# If the BBS list is undef or 0 and the action is 'F' (and it matches the -# pattern) then it will always be forwarded to every node that doesn't have -# it (I strongly recommend you don't use this unless you REALLY mean it, if -# you allow a new link with this on EVERY bull will be forwarded immediately -# on first connection) -# - -package DXMsg; - -@forward = ( -'B', 'T', 'LOCAL', 'F', [ qw(GB7MBC) ], -'B', 'T', 'ALL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'UK', 'F', [ qw(GB7BAA GB7ADX) ], -'B', 'T', 'QSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'QSLINF', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'DX', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'DXINFO', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'DXNEWS', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'DXQSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -'B', 'T', 'SYSOP', 'F', [ qw(GB7BAA GB7ADX) ], -'B', 'T', '50MHZ', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], -); -</verb></tscreen> - -Simply insert a bulletin address and state in the brackets where you wish -that mail to go. For example, you can see here that mail sent to "UK" will -only be sent to the UK links and not to PA4AB-14. - -<P> -To force the cluster to reread the file use load/forward - - -<sect1>The msg command - -<P> -The <em>msg</em> command is a very powerful and flexible tool for the -sysop. It allows the sysop to alter to and from fields and make other -changes to manage the cluster mail. - -Here is a full list of the various options ... - -<tscreen><verb> - MSG TO <msgno> <call> - change TO callsign to <call> - MSG FRom <msgno> <call> - change FROM callsign to <call> - MSG PRrivate <msgno> - set private flag - MSG NOPRrivate <msgno> - unset private flag - MSG RR <msgno> - set RR flag - MSG NORR <msgno> - unset RR flag - MSG KEep <msgno> - set the keep flag (message won't be deleted ever) - MSG NOKEep <msgno> - unset the keep flag - MSG SUbject <msgno> <new> - change the subject to <new> - MSG WAittime <msgno> - remove any waiting time for this message - MSG NOREad <msgno> - mark message as unread - MSG REad <msgno> - mark message as read - MSG QUeue - queue any outstanding bulletins - MSG QUeue 1 - queue any outstanding private messages -</verb></tscreen> - -These commands are simply typed from within the cluster as the sysop user. - -<sect1>Message status - -<P> -You can check on a message from within the cluster by using the command -<em>stat/msg</em>. This will give you additional information on the -message number including which nodes have received it, which node it -was received from and when etc. Here is an example of the output of -the command ... - -<tscreen><verb> -G0VGS de GB7MBC 28-Jan-2001 1308Z > -stat/msg 6869 - From: GB7DJK - Msg Time: 26-Jan-2001 1302Z - Msgno: 6869 - Origin: GB7DJK - Size: 8012 - Subject: AMSAT 2line KEPS 01025.AMSAT - To: UK -Got it Nodes: GB7BAA, GB7ADX - Private: 0 -Read Confirm: 0 - Times read: 0 -G0VGS de GB7MBC 28-Jan-2001 1308Z > -</verb></tscreen> - -<sect1>Filtering mail - -<P> -This is described in the section on <em>Other filters</em> so I will not -duplicate it here. - -<sect1>Distribution lists - -<P> -Distribution lists are simply a list of users to send certain types of -mail to. An example of this is mail you only wish to send to other -sysops. In /spider/msg there is a directory called <em>distro</em>. You -put any distibution lists in here. For example, here is a file called -SYSOP.pl that caters for the UK sysops. - -<tscreen><verb> -qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX - GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH - GB7DXK GB7DXI GB7DXS) -</verb></tscreen> - -Any mail sent to "sysop" would only be sent to the callsigns in this list. - -<sect1>BBS interface - -<P> -Spider provides a simple BBS interface. No input is required from the sysop -of the cluster at all. The BBS simply sets the cluster as a BBS and pushes -any required mail to the cluster. No mail can flow from Spider to the BBS, -the interface is one-way. - -<P> -Please be careful not to flood the cluster network with unnecessary mail. -Make sure you only send mail to the clusters that want it by using the -Forward.pl file very carefully. - -<sect>Databases - -<P> -Spider allows the creation of local or remote databases. It supports -chained databases, allowing several different databases to be scanned -with one simple command. Importing of databases is limited at present -to the standard AK1A databases such as OBLAST and the DB0SDX QSL -database but will expand with time. - -<sect1>Creating databases - -<P> -Creating a database could not be more simple. All the commands are -sent from the cluster prompt as the <em>sysop</em> user. - -To create a database you use the command <em>dbcreate</em>. It can -be used in 3 different ways like so .. - -<tscreen><verb> -dbcreate <name> -</verb></tscreen> - -To simply create a database locally, you just tell the command the -name of the database. This does not create the actual database, it -simply defines it to say that it exists. - -<tscreen><verb> -dbcreate <name> chain <name> [<name>...] -</verb></tscreen> - -This creates a chained database entry. The first database will be -scanned, then the second, the third etc... - -<tscreen><verb> -dbcreate <name> remote <name> -</verb></tscreen> - -This creates a remote entry. the first name field is the database -name at the remote node, then the remote switch, then the actual -node_call of the remote node, for example... - -<tscreen><verb> -dbcreate buckmaster remote gb7dxc -</verb></tscreen> - -Remote databases cannot be chained, however, the last database in a -chain can be a remote database. - -<sect1>Importing databases - -<P> -The only databases that Spider can currently import are the standard -AK1A databases such as OBLAST or the DB0SDX qsl and address database. -This will be added to with time. - -To import such a database, first put the file somewhere useful like /tmp -and then issue the following command ... - -<tscreen><verb> -dbimport oblast /tmp/OBLAST.FUL -</verb></tscreen> - -This will update the existing local oblast database or create it if -it does not exist. - -<sect1>Checking available databases - -<P> -Once a database is created, you will want to check that it has been -added. To do this use the <em>dbavail</em> command. This will -output the available databases. For example ... - -<tscreen><verb> -dbavail -DB Name Location Chain -qsl Local -buck GB7ADX -hftest GB7DXM -G0VGS de GB7MBC 3-Feb-2001 1925Z > -</verb></tscreen> - -<sect1>Looking up databases - -<P> -To look for information in a defined database, simply use the <em>dbshow</em> -command, for example ... - -<tscreen><verb> -dbshow buckmaster G0YLM -</verb></tscreen> - -will show the information for the callsign G0YLM from the buckmaster -database if it exists. To make things more standard for the users -you can add an entry in the Aliases file so that it looks like a standard -<em>show</em> command like this ... - -<tscreen><verb> -'^sh\w*/buc', 'dbshow buckmaster', 'dbshow', -</verb></tscreen> - -Now you can simply use show/buckmaster or an abreviation. - -<sect1>Removing databases - -<P> -To delete an existing database you use the <em>dbremove</em> command. -For example ... - -<tscreen><verb> -dbremove oblast -</verb></tscreen> - -would remove the oblast database and its associated datafile from the -system. There are no warnings or recovery possible from this command. -If you remove a database it ceases to exist and would have to be created -from scratch if you still required it. - -<sect>Information, files and useful programs - -<sect1>MOTD - -<P> -One of the more important things a cluster sysop needs to do is to get -information to his users. The simplest way to do this is to have a banner -that is sent to the user on login. This is know as a "message of the day" -or "motd". To set this up, simply create a file in /spider/data called motd -and edit it to say whatever you want. It is purely a text file and will be -sent automatically to anyone logging in to the cluster. - -<sect1>Downtime message - -<P> -If for any reason the cluster is down, maybe for upgrade or maintenance but -the machine is still running, a message can be sent to the user advising them -of the fact. This message lives in the /spider/data directory and is called -"offline". Simply create the file and edit it to say whatever you wish. -This file will be sent to a user attempting to log into the cluster when -DXSpider is not actually running. - -<sect1>Other text messages - -<P> -You can set other text messages to be read by the user if they input the file -name. This could be for news items or maybe information for new users. -To set this up, make a directory under /spider called <em>packclus</em>. -Under this directory you can create files called <em>news</em> or <em>newuser</em> -for example. In fact you can create files with any names you like. These can -be listed by the user with the command .... - -<tscreen><verb> -show/files -</verb></tscreen> - -They can be read by the user by typing the command .... - -<tscreen><verb> -type news -</verb></tscreen> - -If the file they want to read is called <em>news</em>. You could also set -an alias for this in the Alias file to allow them just to type <em>news</em> - -<P> -You can also store other information in this directory, either directly or -nested under directories. One use for this would be to store DX bulletins -such as the OPDX bulletins. These can be listed and read by the user. -To keep things tidy, make a directory under /spider/packclus called -<em>bulletin</em>. Now copy any OPDX or similar bulletins into it. These -can be listed by the user in the same way as above using the <em>show/files</em> -command with an extension for the bulletin directory you have just created, -like this .... - -<tscreen><verb> -show/files bulletin -</verb></tscreen> - -<P> -An example would look like this .... - -<tscreen><verb> -sh/files -bulletin DIR 20-Dec-1999 1715Z news 1602 14-Dec-1999 1330Z -</verb></tscreen> - -You can see that in the files area (basically the packclus directory) there is a -file called <em>news</em> and a directory called <em>bulletin</em>. You can -also see that dates they were created. In the case of the file <em>news</em>, -you can also see the time it was last modified, a good clue as to whether the -file has been updated since you last read it. To read the file called -<em>news</em> you would simply issue the command .... - -<tscreen><verb> -type news -</verb></tscreen> - -To look what is in the bulletin directory you issue the command .... - -<tscreen><verb> -show/files bulletin -opdx390 21381 29-Nov-1999 1621Z opdx390.1 1670 29-Nov-1999 1621Z -opdx390.2 2193 29-Nov-1999 1621Z opdx391 25045 29-Nov-1999 1621Z -opdx392 35969 29-Nov-1999 1621Z opdx393 15023 29-Nov-1999 1621Z -opdx394 33429 29-Nov-1999 1621Z opdx394.1 3116 29-Nov-1999 1621Z -opdx395 24319 29-Nov-1999 1621Z opdx396 32647 29-Nov-1999 1621Z -opdx396.1 5537 29-Nov-1999 1621Z opdx396.2 6242 29-Nov-1999 1621Z -opdx397 18433 29-Nov-1999 1621Z opdx398 19961 29-Nov-1999 1621Z -opdx399 17719 29-Nov-1999 1621Z opdx400 19600 29-Nov-1999 1621Z -opdx401 27738 29-Nov-1999 1621Z opdx402 18698 29-Nov-1999 1621Z -opdx403 24994 29-Nov-1999 1621Z opdx404 15685 29-Nov-1999 1621Z -opdx405 13984 29-Nov-1999 1621Z opdx405.1 4166 29-Nov-1999 1621Z -opdx406 28934 29-Nov-1999 1621Z opdx407 24153 29-Nov-1999 1621Z -opdx408 15081 29-Nov-1999 1621Z opdx409 23234 29-Nov-1999 1621Z -Press Enter to continue, A to abort (16 lines) > -</verb></tscreen> - -You can now read any file in this directory using the type command, like this .... - -<tscreen><verb> -type bulletin/opdx391 -Ohio/Penn DX Bulletin No. 391 -The Ohio/Penn Dx PacketCluster -DX Bulletin No. 391 -BID: $OPDX.391 -January 11, 1999 -Editor Tedd Mirgliotta, KB8NW -Provided by BARF-80 BBS Cleveland, Ohio -Online at 440-237-8208 28.8k-1200 Baud 8/N/1 (New Area Code!) -Thanks to the Northern Ohio Amateur Radio Society, Northern Ohio DX -Association, Ohio/Penn PacketCluster Network, K1XN & Golist, WB2RAJ/WB2YQH -& The 59(9) DXReport, W3UR & The Daily DX, K3TEJ, KN4UG, W4DC, NC6J, N6HR, -Press Enter to continue, A to abort (508 lines) > -</verb></tscreen> - -The page length will of course depend on what you have it set to! - -<sect1>The Aliases file - -<P> -You will find a file in /spider/cmd/ called Aliases. First, copy this file to -/spider/local_cmd/Aliases and edit this file. You will see something like this ... - -<tscreen><verb> - -#!/usr/bin/perl - -# provide some standard aliases for commands for terminally -# helpless ak1a user (helpless in the sense that they never -# read nor understand help files) - -# This file is automagically reloaded if its modification time is -# later than the one stored in CmdAlias.pm - -# PLEASE make this file consistant with reality! (the patterns MUST -# match the filenames!) - -# Don't alter this file, copy it into the local_cmd tree and modify it. -# This file will be replaced everytime I issue a new release. - -# You only need to put aliases in here for commands that don't work as -# you desire naturally, e.g sh/dx on its own just works as you expect -# so you need not add it as an alias. - - - -package CmdAlias; - -%alias = ( - '?' => [ - '^\?', 'apropos', 'apropos', - ], - 'a' => [ - '^ann.*/full', 'announce full', 'announce', - '^ann.*/sysop', 'announce sysop', 'announce', - '^ann.*/(.*)$', 'announce $1', 'announce', - ], - 'b' => [ - ], - 'c' => [ - ], - 'd' => [ - '^del', 'kill', 'kill', - '^del\w*/fu', 'kill full', 'kill', - '^di\w*/a\w*', 'directory all', 'directory', - '^di\w*/b\w*', 'directory bulletins', 'directory', - '^di\w*/n\w*', 'directory new', 'directory', - '^di\w*/o\w*', 'directory own', 'directory', - '^di\w*/s\w*', 'directory subject', 'directory', - '^di\w*/t\w*', 'directory to', 'directory', - '^di\w*/f\w*', 'directory from', 'directory', - '^di\w*/(\d+)', 'directory $1', 'directory', - ], - 'e' => [ - ], - 'f' => [ - ], - 'g' => [ - ], - 'h' => [ - ], - 'i' => [ - ], - 'j' => [ - ], - 'k' => [ - ], - 'l' => [ - '^l$', 'directory', 'directory', - '^ll$', 'directory', 'directory', - '^ll/(\d+)', 'directory $1', 'directory', - ], - 'm' => [ - ], - 'n' => [ - '^news', 'type news', 'type', - ], - 'o' => [ - ], - 'p' => [ - ], - 'q' => [ - '^q', 'bye', 'bye', - ], - 'r' => [ - '^r$', 'read', 'read', - '^rcmd/(\S+)', 'rcmd $1', 'rcmd', - ], - 's' => [ - '^s/p$', 'send', 'send', - '^sb$', 'send noprivate', 'send', - '^set/home$', 'set/homenode', 'set/homenode', - '^set/nobe', 'unset/beep', 'unset/beep', - '^set/nohe', 'unset/here', 'unset/here', - '^set/noan', 'unset/announce', 'unset/announce', - '^set/nodx', 'unset/dx', 'unset/dx', - '^set/nota', 'unset/talk', 'unset/talk', - '^set/noww', 'unset/wwv', 'unset/wwv', - '^set/nowx', 'unset/wx', 'unset/wx', - '^sh$', 'show', 'show', - '^sh\w*/buck', 'dbshow buck', 'dbshow', - '^sh\w*/bu', 'show/files bulletins', 'show/files', - '^sh\w*/c/n', 'show/configuration nodes', 'show/configuration', - '^sh\w*/c$', 'show/configuration', 'show/configuration', - '^sh\w*/com', 'dbavail', 'dbavail', - '^sh\w*/dx/(\d+)-(\d+)', 'show/dx $1-$2', 'show/dx', - '^sh\w*/dx/(\d+)', 'show/dx $1', 'show/dx', - '^sh\w*/dx/d(\d+)', 'show/dx from $1', 'show/dx', - '^sh\w*/email', 'dbshow email', 'dbshow', - '^sh\w*/hftest', 'dbshow hftest', 'dbshow', - '^sh\w*/vhftest', 'dbshow vhftest', 'dbshow', - '^sh\w*/qsl', 'dbshow qsl', 'dbshow', - '^sh\w*/tnc', 'who', 'who', - '^sh\w*/up', 'show/cluster', 'show/cluster', - '^sh\w*/w\w*/(\d+)-(\d+)', 'show/wwv $1-$2', 'show/wwv', - '^sh\w*/w\w*/(\d+)', 'show/wwv $1', 'show/wwv', - '^sp$', 'send', 'send', - - ], - 't' => [ - '^ta$', 'talk', 'talk', - '^t$', 'talk', 'talk', - ], - 'u' => [ - ], - 'v' => [ - ], - 'w' => [ - '^wx/full', 'wx full', 'wx', - '^wx/sysop', 'wx sysop', 'wx', - ], - 'x' => [ - ], - 'y' => [ - ], - 'z' => [ - ], -) -</verb></tscreen> - -You can create aliases for commands at will. Beware though, these may not -always turn out as you think. Care is needed and you need to test the -results once you have set an alias. - -<sect1>Console.pl - -<P> -In later versions of Spider a simple console program is provided for the sysop. -This has a type ahead buffer with line editing facilities and colour for spots, -announces etc. To use this program, simply use console.pl instead of client. - -<P> -To edit the colours, copy /spider/perl/Console.pl to /spider/local and edit the -file with your favourite editor. - -<sect1>Updating kepler data - -<P> -Spider has a powerful and flexible show/satellite command. In order for -this to be accurate, the kepler data has to be updated regularly. In -general, this data is available as an email or via cluster mail. -Updating it is simple. First you need to export the mail message as a -file. You do this with the <em>export</em> command from the cluster prompt -as the sysop. For example ... - -<tscreen><verb> -export 5467 /spider/perl/keps.in -</verb></tscreen> - -would export message number 5467 as a file called keps.in in the -/spider/perl directory. - -Now login to a VT as sysop and cd /spider/perl. There is a command in -the perl directory called <em>convkeps.pl</em>. All we need to do now is -convert the file like so ... - -<tscreen><verb> -./convkeps.pl keps.in -</verb></tscreen> - -Now go back to the cluster and issue the command ... - -<tscreen><verb> -load/keps -</verb></tscreen> - -That is it! the kepler data has been updated. - -<sect1>The QRZ callbook - -<P> -The command <em>sh/qrz</em> will only work once you have followed a few -simple steps. First you need to get a user ID and password from qrz.com. -Simply go to the site and create one. Secondly you need to copy the file -/spider/perl/Internet.pm to /spider/local and alter it to match your user -ID and password. You also at this point need to set $allow=1 to complete -the setup. Many thanks to Fred Lloyd, the proprieter of -<htmlurl url="http://www.qrz.com" name="qrz.com"> for allowing this access. - -<sect>CVS - -<P> -CVS stands for "Concurrent Versions System" and the CVS for DXSpider is held -at <htmlurl url="http://www.sourceforge.net" name="Sourceforge">. This means -that it is possible to update your DXSpider installation to the latest -sources by using a few simple commands. - -<P> -THIS IS NOT FOR THE FAINT HEARTED!!! ONLY DO THIS IF YOU HAVE A TEST -INSTALLATION OR ARE WILLING TO HAVE YOUR CLUSTER CRASH ON YOU!!! -THIS MUST BE CONSIDERED AT LEAST BETA TESTING AND MAYBE EVEN ALPHA!! -YOU HAVE BEEN WARNED!!! - -<P> -DID I MENTION..... ONLY DO THIS IF YOU ARE WILLING TO ACCEPT THE -CONSEQUENCES!!! - -<P> -I am of course assuming that you have a machine with both DXSpider and -Internet access running. - -<P> -BEFORE YOU EVEN CONSIDER STARTING WITH THIS MAKE A BACKUP OF YOUR -ENTIRE SPIDER TREE!! - -<P> -Assuming you are connected to the Internet, you need to login to the -CVS repository and then update your Spider source. There are several -steps which are listed below ... - -<P> -First login as the user <em>sysop</em>. Next you need to connect to the CVS -repository. You do this with the command below ... - -<verb> -cvs -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login -</verb> - -You will get a password prompt. Simply hit return here and your machine should -return to a normal linux prompt. - -<P> -What happens next depends on whether you have an existing installation that -you want to update with the latest and greatest or whether you just want -to see what is there and/or run it on a new machine for testing. - -If you are installing Spider from CVS then change directory to /home/sysop - -If you are wanting to update Spider then cd to /tmp - -<P> -The next step will create a brand new 'spider' directory in your current -directory. - -<verb> -cvs -z3 -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider co spider -</verb> - -This command is all on one line. - -<P> -Hopefully your screen should show you downloading files. The -z3 simply compresses -the download to improve speed. -When this has finished, you will have exactly the same as if you had untarred a full -tarball PLUS some extra directories and files that CVS needs to do the magic that -it does. - -<P> -Now if you are doing a new installation, that's it. Carry on as if you have -just downloaded and untarred the lastest tarball. - -<P> -If you want to upgrade your current installation then do this ... - -<tscreen><verb> -tar cvfz /tmp/s.tgz spider -cd / -tar xvfzp /tmp/s.tgz -</verb></tscreen> - -This is assuming you downloaded to the /tmp directory of course. - -<P> -NOTE: the 'p' on the end of the 'xvfz' is IMPORTANT! It keeps the permissions -correct. YOU WERE LOGGED IN AS THE USER SYSOP WEREN'T YOU????? - -Remember to recompile the C client (cd /spider/src; make) - -<P> -At this point the files have been upgraded. You can (usually) restart the cluster -in your own time. However, if you attempt to use any new commands or features -expect it to be fatal! At least your cluster will have been restarted then so it -will be too late to worry about it! - -<P> -Now the magic part! From now on when you want to update, simply connect to the -Internet and then, as the user <em>sysop</em> ... - -<tscreen><verb> -cd /spider -cvs -z3 update -d -</verb></tscreen> - -and your files will be updated. As above, remember to recompile the "C" client -if it has been updated (CVS will tell you) and restart if any of the perl scripts -have been altered or added, again, CVS will tell you. - -<P> -You will find any changes documented in the /spider/Changes file. - -<sect>The DXSpider command set - -<P> -Below is a complete list of commands available from the cluster prompt. -Most maintenance tasks are automatic but there are some commands that are useful -for a sysop. These are listed below in alphabetical order. The number in -brackets following the command name is the permissions level needed to use -the command. - -<sect1>accept/announce (0) - -<P> -<tt> -<bf>accept/announce [0-9] <pattern></bf> Set an accept filter - line for announce -</tt> - -<P> -Create an 'accept this announce' line for a filter. - -An accept filter line means that if the announce matches this filter it is -passed onto the user. See HELP FILTERS for more info. Please read this -to understand how filters work - it will save a lot of grief later on. - -You can use any of the following things in this line:- - -<tscreen><verb> - info <string> eg: iota or qsl - by <prefixes> eg: G,M,2 - origin <prefixes> - origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G) - origin_itu <numbers> - origin_zone <numbers> - by_dxcc <numbers> - by_itu <numbers> - by_zone <numbers> - channel <prefixes> - wx 1 filter WX announces - dest <prefixes> eg: 6MUK,WDX (distros) -</verb></tscreen> - -some examples:- - -<tscreen><verb> - acc/ann dest 6MUK - acc/ann 2 by_zone 14,15,16 - (this could be all on one line: acc/ann dest 6MUK or by_zone 14,15,16) -</verb></tscreen> - -or - -<tscreen><verb> - acc/ann by G,M,2 -</verb></tscreen> - -This filter would only allow announces that were posted buy UK stations. -You can use the tag 'all' to accept everything eg: - -<tscreen><verb> - acc/ann all -</verb></tscreen> - -but this probably for advanced users... - -<sect1>accept/announce (extended for sysops) (8) - -<P> -<tt> -<bf>accept/announce <call> [input] [0-9]<pattern></bf> Announce filter sysop version -</tt> - -<P> -This version allows a sysop to set a filter for a callsign as well as the -default for nodes and users eg:- - -<tscreen><verb> - accept/ann by G,M,2 - accept/ann input node_default by G,M,2 - accept/ann user_default by G,M,2 -</verb></tscreen> - -<sect1>accept/spots (0) - -<P> -<tt> -<bf>accept/announce [0-9] <pattern></bf> Set an accept filter -line for spots -</tt> - -<P> -Create an 'accept this spot' line for a filter. - -<P> -An accept filter line means that if the spot matches this filter it is -passed onto the user. See HELP FILTERS for more info. Please read this -to understand how filters work - it will save a lot of grief later on. - -You can use any of the following things in this line:- - -<tscreen><verb> - freq <range> eg: 0/30000 or hf or hf/cw or 6m,4m,2m - on <range> same as 'freq' - call <prefixes> eg: G,PA,HB9 - info <string> eg: iota or qsl - by <prefixes> - call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G) - call_itu <numbers> - call_zone <numbers> - by_dxcc <numbers> - by_itu <numbers> - by_zone <numbers> - origin <prefixes> - channel <prefixes> -</verb></tscreen> - -<P> -For frequencies, you can use any of the band names defined in -SHOW/BANDS and you can use a subband name like: cw, rtty, data, ssb - -thus: hf/ssb. You can also just have a simple range like: 0/30000 - -this is more efficient than saying simply: freq HF (but don't get -too hung up about that) - -some examples:- - -<tscreen><verb> - acc/spot 1 on hf/cw - acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16) -</verb></tscreen> - -You can use the tag 'all' to accept everything, eg: - -<tscreen><verb> - acc/spot 3 all -</verb></tscreen> - -but this probably for advanced users... - -<sect1>accept/spots (extended for sysops) (8) - -<P> -<tt> -<bf>accept/spots <call> [input] [0-9] <pattern></bf> Spot filter sysop version -</tt> - -<P> -This version allows a sysop to set a filter for a callsign as well as the -default for nodes and users eg:- - -<tscreen><verb> - accept/spot db0sue-7 1 by_zone 14,15,16 - accept/spot node_default all - set/hops node_default 10 - - accept/spot user_default by G,M,2 -</verb></tscreen> - -<sect1>accept/wcy (0) - -<P> -<tt> -<bf>accept/wcy [0-9] <pattern></bf> set an accept WCY filter -</tt> - -<P> -It is unlikely that you will want to do this, but if you do then you can -filter on the following fields:- - -<tscreen><verb> - by <prefixes> eg: G,M,2 - origin <prefixes> - origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G) - origin_itu <numbers> - origin_zone <numbers> - by_dxcc <numbers> - by_itu <numbers> - by_zone <numbers> - channel <prefixes> -</verb></tscreen> - -<P> -There are no examples because WCY Broadcasts only come from one place and -you either want them or not (see UNSET/WCY if you don't want them). - -This command is really provided for future use. - -See HELP FILTER for information. - -<sect1>accept/wcy (extended for sysops) (8) - -<P> -<tt> -<bf>accept/wcy <call> [input] [0-9] <pattern></bf> -WCY filter sysop version -</tt> - -<P> -This version allows a sysop to set a filter for a callsign as well as the -default for nodes and users eg:- - -<tscreen><verb> - accept/wcy node_default all - set/hops node_default 10 -</verb></tscreen> - -<sect1>accept/wwv (0) - -<P> -<tt> -<bf>accept/wwv [0-9] <pattern></bf> Set an accept WWV filter -</tt> - -<P> -It is unlikely that you will want to do this, but if you do then you can -filter on the following fields:- - -<tscreen><verb> - by <prefixes> eg: G,M,2 - origin <prefixes> - origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G) - origin_itu <numbers> - origin_zone <numbers> - by_dxcc <numbers> - by_itu <numbers> - by_zone <numbers> - channel <prefixes> -</verb></tscreen> - -for example - -<tscreen><verb> - accept/wwv by_zone 4 -</verb></tscreen> - -is probably the only useful thing to do (which will only show WWV broadcasts -by stations in the US). - -See HELP FILTER for information. - -<sect1>accept/wwv (extended for sysops) (8) - -<P> -<tt> -<bf>accept/wwv <call> [input] [0-9] <pattern></bf> -WWV filter sysop version -</tt> - -<P> -This version allows a sysop to set a filter for a callsign as well as the -default for nodes and users eg:- - -<tscreen><verb> - accept/wwv db0sue-7 1 by_zone 4 - accept/wwv node_default all - set/hops node_default 10 - - accept/wwv user_default by W,K -</verb></tscreen> - -<sect1>announce (0) - -<P> -<tt> -<bf>announce <text></bf> Send an announcement to local users -</tt> - -<P> -Send an announcement to LOCAL users only, where <text> is the text -of the announcement you wish to broadcast - -<sect1>announce full (0) - -<P> -<tt> -<bf>announce full <text></bf> Send an announcement cluster wide -</tt> - -<P> -This command will send your announcement across the whole cluster -network. - - -<sect1>announce sysop (5) - -<P> -<tt> -<bf>announce sysop <text></bf> -</tt> - -<P> -Send an announcement to Sysops only - -<sect1>apropos (0) - -<P> -<tt> -<bf>apropos <string></bf> Search the help database -</tt> - -<P> -Search the help database for <string> (it isn't case sensitive), -and print the names of all the commands that may be relevant. - -<sect1>bye (0) - -<P> -<tt> -<bf>bye</bf> Exit from the cluster -</tt> - -<P> -This will disconnect you from the cluster - -<sect1>catchup (5) - -<P> -<tt> -<bf>catchup <node_call> All|[<msgno> ...]</bf> -Mark a message as sent -</tt> - -<P> -When you send messages the fact that you have forwarded it to another node -is remembered so that it isn't sent again. When you have a new partner -node and you add their callsign to your /spider/msg/forward.pl file, all -outstanding non-private messages will be forwarded to them. This may well -be ALL the non-private messages. You can prevent this by using these -commmands:- - -<tscreen><verb> - catchup GB7DJK all - catchup GB7DJK 300 301 302 303 500-510 -</verb></tscreen> - -and to undo what you have just done:- - -<tscreen><verb> - uncatchup GB7DJK all - uncatchup GB7DJK 300 301 302 303 500-510 -</verb></tscreen> - -which will arrange for them to be forward candidates again. - -Order is not important. - -<sect1>clear/spots (0) - -<P> -<tt> -<bf>clear/spots [1|all]</bf> Clear a spot filter line -</tt> - -<P> -This command allows you to clear (remove) a line in a spot filter or to -remove the whole filter. - -If you have a filter:- - -<tscreen><verb> - acc/spot 1 on hf/cw - acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16) -</verb></tscreen> - -and you say:- - -<tscreen><verb> - clear/spot 1 -</verb></tscreen> - -you will be left with:- - -<tscreen><verb> - acc/spot 2 on vhf and (by_zone 14,15,16 or call_zone 14,15,16) -</verb></tscreen> - -If you do: - -<tscreen><verb> - clear/spot all -</verb></tscreen> - -the filter will be completely removed. - - -<sect1>connect (5) - -<P> -<tt> -<bf>connect <callsign></bf> Start a connection to another DX Cluster -</tt> - -<P> -Start a connection process that will culminate in a new connection to the -DX cluster <callsign>. This process creates a new 'client' process which will -use the script in /spider/connect/<callsign> to effect the 'chat' exchange -necessary to traverse the network(s) to logon to the cluster <callsign>. - -<sect1>dbavail (0) - -<P> -<tt> -<bf>dbavail</bf> Show a list of all the databases in the system -</tt> - -<P> -The title says it all really, this command lists all the databases defined -in the system. It is also aliased to SHOW/COMMAND. - -<sect1>dbcreate (9) - -<P> -<tt> -<bf>dbcreate <name></bf> Create a database entry<newline> -<bf>dbcreate <name> chain <name> [<name>..]</bf> Create a -chained database entry<newline> -<bf>dbcreate <name> remote <node></bf> Create a remote database -entry<newline> -</tt> - -<P> -DBCREATE allows you to define a database in the system. It doesn't actually -create anything, just defines it. - -The databases that are created are simple DB_File hash databases, they are -therefore already 'indexed'. - -You can define a local database with the first form of the command eg: - - DBCREATE oblast - -You can also chain databases with the addition of the 'chain' keyword. -This will search each database one after the other. A typical example -is: - - DBCREATE sdx_qsl chain sql_ad - -No checking is done to see if the any of the chained databases exist, in -fact it is usually better to do the above statement first then do each of -the chained databases. - -Databases can exist offsite. To define a database that lives on another -node do: - - DBCREATE buckmaster remote gb7dxc - -Remote databases cannot be chained; however, the last database in a -a chain can be a remote database eg: - - DBCREATE qsl chain gb7dxc - -To see what databases have been defined do: - - DBAVAIL (or it will have been aliased to SHOW/COMMAND) - -It would be normal for you to add an entry into your local Aliases file -to allow people to use the 'SHOW/<dbname>' style syntax. So you would -need to add a line like:- - -<tscreen><verb> - 's' => [ - .. - .. - '^sh\w*/buc', 'dbshow buckmaster', 'dbshow', - .. - .. - ], -</verb></tscreen> - -to allow - - SH/BUCK g1tlh - -to work as they may be used to. - -See DBIMPORT for the importing of existing AK1A format data to databases. -See DBSHOW for generic database enquiry - -<sect1>dbimport (9) - -<P> -<tt> -<bf>dbimport <dbname></bf> Import AK1A data into a database -</tt> - -<P> -If you want to import or update data in bulk to a database you can use -this command. It will either create or update entries into an existing -database. For example:- - - DBIMPORT oblast /tmp/OBLAST.FUL - -will import the standard OBLAST database that comes with AK1A into the -oblast database held locally. - -<sect1>dbremove (9) - -<P> -<tt> -<bf>dbremove <dbname></bf> Delete a database -</tt> - -<P> -DBREMOVE will completely remove a database entry and also delete any data -file that is associated with it. - -There is no warning, no comeback, no safety net. - -For example: - - DBREMOVE oblast - -will remove the oblast database from the system and it will also remove -the associated datafile. - -I repeat: - -There is no warning, no comeback, no safety net. - -You have been warned. - -<sect1>dbshow (0) - -<P> -<tt> -<bf>dbshow <dbname> <key></bf> Display an entry, if it exists, -in a database -</tt> - -<P> -This is the generic user interface to the database to the database system. -It is expected that the sysop will add an entry to the local Aliases file -so that users can use the more familiar AK1A style of enquiry such as: - -<tscreen><verb> - SH/BUCK G1TLH -</verb></tscreen> - -but if he hasn't and the database really does exist (use DBAVAIL or -SHOW/COMMAND to find out) you can do the same thing with: - -<tscreen><verb> - DBSHOW buck G1TLH -</verb></tscreen> - - -<sect1>debug (9) - -<P> -<tt> -<bf>debug</bf> Set the cluster program into debug mode -</tt> - -<P> -Executing this command will only have an effect if you are running the cluster -in debug mode i.e. - -<tscreen><verb> - perl -d cluster.pl -</verb></tscreen> - -It will interrupt the cluster just after the debug command has finished. - -<sect1>directory (0) - -<P> -<tt> -<bf>directory</bf> List messages<newline> -<bf>directory all</bf> List all messages<newline> -<bf>directory own</bf> List your own messages<newline> -<bf>directory new</bf> List all new messages<newline> -<bf>directory to <call></bf> List all messages to <call><newline> -<bf>directory from <call></bf> List all messages from <call><newline> -<bf>directory subject <string></bf> List all messages with <string> -in subject<newline> -<bf>directory <nn></bf> List last <nn> messages<newline> -<bf>directory <from>-<to></bf> List messages <from> message <to> message <newline> -</tt> - -<P> -List the messages in the messages directory. - -If there is a 'p' one space after the message number then it is a -personal message. If there is a '-' between the message number and the -'p' then this indicates that the message has been read. - -You can use shell escape characters such as '*' and '?' in the <call> -fields. - -You can combine some of the various directory commands together eg:- - -<tscreen><verb> - DIR TO G1TLH 5 -or - DIR SUBJECT IOTA 200-250 -</verb></tscreen> - -You can abbreviate all the commands to one letter and use ak1a syntax:- - -<tscreen><verb> - DIR/T G1* 10 - DIR/S QSL 10-100 5 -</verb></tscreen> - - -<sect1>directory (extended for sysops) (5) - -<P> -Works just like the user command except that sysops can see ALL messages. - -<sect1>disconnect (8) - -<P> -<tt> -<bf>disconnect <call> [<call> ...]</bf> Disconnect a user or node -</tt> - -<P> -Disconnect any <call> connected locally - -<sect1>dx (0) - -<P> -<tt> -<bf>dx [by <call>] <freq> <call> <remarks></bf> Send a DX spot -</tt> - -<P> -This is how you send a DX Spot to other users. You can, in fact, now -enter the <freq> and the <call> either way round. - -<tscreen><verb> - DX FR0G 144.600 - DX 144.600 FR0G - DX 144600 FR0G -</verb></tscreen> - -will all give the same result. You can add some remarks to the end -of the command and they will be added to the spot. - -<tscreen><verb> - DX FR0G 144600 this is a test -</verb></tscreen> - -You can credit someone else by saying:- - -<tscreen><verb> - DX by G1TLH FR0G 144.600 he isn't on the cluster -</verb></tscreen> - -The <freq> is compared against the available bands set up in the -cluster. See SHOW/BANDS for more information. - -<sect1>export (9) - -<P> -<tt> -<bf>export <msgno> <filename></bf> Export a message to a file -</tt> - -<P> -Export a message to a file. This command can only be executed on a local -console with a fully privileged user. The file produced will be in a form -ready to be imported back into the cluster by placing it in the import -directory (/spider/msg/import). - -This command cannot overwrite an existing file. This is to provide some -measure of security. Any files written will owned by the same user as the -main cluster, otherwise you can put the new files anywhere the cluster can -access. For example:- - - EXPORT 2345 /tmp/a - -<sect1>export_users (9) - -<P> -<tt> -<bf>export_users [<filename>]</bf> Export the users database to ascii -</tt> - -<P> -Export the users database to a file in ascii format. If no filename -is given then it will export the file to /spider/data/user_asc. - -If the file already exists it will be renamed to <filename>.o. In fact -up to 5 generations of the file can be kept each one with an extra 'o' on the -suffix. - -BE WARNED: this will write to any file you have write access to. No check is -made on the filename (if any) that you specify. - -<sect1>forward/latlong (8) - -<P> -<tt> -<bf>forward/latlong <node_call></bf> Send latitude and longitude -information to another cluster -</tt> - -<P> -This command sends all the latitude and longitude information that your -cluster is holding against callsigns. One advantage of recieving this -information is that more locator information is held by you. This -means that more locators are given on the DX line assuming you have -<em>set/dxgrid</em> enabled. This could be a LOT of information though, so -it is not recommended on slow links. - -<sect1>forward/opername (1) - -<P> -<tt> -<bf>forward/opername <call></bf> Send out information on this <call> -to all clusters -</tt> - -<P> -This command sends out any information held in the user file which can -be broadcast in PC41 protocol packets. This information is Name, QTH, Location -and Homenode. PC41s are only sent for the information that is available. - -<sect1>help (0) - -<P> -<tt> -<bf>help <cmd></bf> Get help on a command -</tt> - -<P> -All commands can be abbreviated, so SHOW/DX can be abbreviated -to SH/DX, ANNOUNCE can be shortened to AN and so on. - -Look at the APROPOS <string> command which will search the help database -for the <string> you specify and give you a list of likely commands -to look at with HELP. - -<sect1>init (5) - -<P> -<tt> -<bf>init <node call></bf> Re-initialise a link to an AK1A compatible node -</tt> - -<P> -This command attempts to re-initialise a link to a (usually) AK1A node -that has got confused, usually by a protocol loop of some kind. It may -work - but you usually will be better off simply disconnecting it (or -better, if it is a real AK1A node, doing an RCMD <node> DISC/F <your -node>). - -Best of luck - you will need it. - -<sect1>kill (0) - -<P> -<tt> -<bf>kill <msgno> [<msgno> ..]</bf> Delete a message -from the local system -</tt> - -<P> -Delete a message from the local system. You will only be able to -delete messages that you have originated or been sent (unless you are -the sysop). - -<sect1>kill (5) - -<P> -<tt> -<bf>kill <msgno> [<msgno> ...]</bf> Remove or erase a message from -the system<newline> -<bf>kill from <call></bf> Remove all messages from a callsign<newline> -<bf>kill to <call></bf> Remove all messages to a callsign<newline> -</tt> - -<P> -You can get rid of any message to or originating from your callsign using -this command. You can remove more than one message at a time. - -As a sysop you can kill any message on the system. - -<sect1>kill full (5) - -<P> -<tt> -<bf>kill full <msgno> [<msgno>]</bf> Delete a message from the -whole cluster -</tt> - -<P> -Delete a message (usually a 'bulletin') from the whole cluster system. - -This uses the subject field, so any messages that have exactly the same subject -will be deleted. Beware! - -<sect1>links (0) - -<P> -<tt> -<bf>links</bf> Show which nodes are physically connected -</tt> - -<P> -This is a quick listing that shows which links are connected and -some information about them. See WHO for a list of all connections. - - -<sect1>load/aliases (9) - -<P> -<tt> -<bf>load/aliases</bf> Reload the command alias table -</tt> - -<P> -Reload the /spider/cmd/Aliases file after you have editted it. You will need to -do this if you change this file whilst the cluster is running in order for the -changes to take effect. - - -<sect1>load/baddx (9) - -<P> -<tt> -<bf>load/baddx</bf> Reload the bad DX table -</tt> - -<P> -Reload the /spider/data/baddx.pl file if you have changed it manually whilst -the cluster is running. This table contains the DX Calls that, if spotted, -will not be passed on. FR0G and TEST are classic examples. - -<sect1>load/badmsg (9) - -<P> -<tt> -<bf>load/badmsg</bf> Reload the bad message table -</tt> - -<P> -Reload the /spider/msg/badmsg.pl file if you have changed it manually whilst -the cluster is running. This table contains a number of perl regular -expressions which are searched for in the fields targetted of each message. -If any of them match then that message is immediately deleted on receipt. - -<sect1>load/badwords (9) - -<P> -<tt> -<bf>load/badwords</bf> Reload the badwords file -</tt> - -<P> -Reload the /spider/data/badwords file if you have changed it manually whilst -the cluster is running. This file contains a list of words which, if found -on certain text portions of PC protocol, will cause those protocol frames -to be rejected. It will all put out a message if any of these words are -used on the announce, dx and talk commands. The words can be one or -more on a line, lines starting with '#' are ignored. - -<sect1>load/bands (9) - -<P> -<tt> -<bf>load/bands</bf> Reload the band limits table -</tt> - -<P> -Reload the /spider/data/bands.pl file if you have changed it manually whilst -the cluster is running. - -<sect1>load/cmd_cache (9) - -<P> -<tt> -<bf>load/cmd_cache</bf> Reload the automatic command cache -</tt> - -<P> -Normally, if you change a command file in the cmd or local_cmd tree it will -automatially be picked up by the cluster program. Sometimes it can get confused -if you are doing a lot of moving commands about or delete a command in the -local_cmd tree and want to use the normal one again. Execute this command to -reset everything back to the state it was just after a cluster restart. - -<sect1>load/forward (9) - -<P> -<tt> -<bf>load/forward</bf> Reload the msg forwarding routing table -</tt> - -Reload the /spider/msg/forward.pl file if you have changed it -manually whilst the cluster is running. - -<sect1>load/messages (9) - -<P> -<tt> -<bf>load/messages</bf> Reload the system messages file -</tt> - -<P> -If you change the /spider/perl/Messages file (usually whilst fiddling/writing ne -commands) you can have them take effect during a cluster session by executing this -command. You need to do this if get something like :- - -unknown message 'xxxx' in lang 'en' - -<sect1>load/prefixes (9) - -<P> -<tt> -<bf>load/prefixes</bf> Reload the prefix table -</tt> - -<P> -Reload the /spider/data/prefix_data.pl file if you have changed it manually -whilst the cluster is running. - -<sect1>merge (5) - -<P> -<tt> -<bf>merge <node> [<no spots>/<no wwv>]</bf> Ask for the -latest spots and WWV -</tt> - -<P> -MERGE allows you to bring your spot and wwv database up to date. By default -it will request the last 10 spots and 5 WWVs from the node you select. The -node must be connected locally. - -You can request any number of spots or wwv and although they will be appended -to your databases they will not duplicate any that have recently been added -(the last 2 days for spots and last month for WWV data). - -<sect1>msg (9) - -<P> -<tt> -<bf>msg <cmd> <msgno> [data ...]</bf> Alter various message -parameters -</tt> - -<P> -Alter message parameters like To, From, Subject, whether private or bulletin -or return receipt (RR) is required or whether to keep this message from timing -out. - -<tscreen><verb> - MSG TO <msgno> <call> - change TO callsign to <call> - MSG FRom <msgno> <call> - change FROM callsign to <call> - MSG PRrivate <msgno> - set private flag - MSG NOPRrivate <msgno> - unset private flag - MSG RR <msgno> - set RR flag - MSG NORR <msgno> - unset RR flag - MSG KEep <msgno> - set the keep flag (message won't be deleted ever) - MSG NOKEep <msgno> - unset the keep flag - MSG SUbject <msgno> <new> - change the subject to <new> - MSG WAittime <msgno> - remove any waitting time for this message - MSG NOREad <msgno> - mark message as unread - MSG REad <msgno> - mark message as read - MSG QUeue - queue any outstanding bulletins - MSG QUeue 1 - queue any outstanding private messages -</verb></tscreen> - -You can look at the status of a message by using:- - - STAT/MSG <msgno> - -This will display more information on the message than DIR does. - -<sect1>pc (8) - -<P> -<tt> -<bf>pc <call> <text></bf> Send text (eg PC Protocol) to <call> -</tt> - -<P> -Send some arbitrary text to a locally connected callsign. No processing is done on -the text. This command allows you to send PC Protocol to unstick things if problems -arise (messages get stuck etc). eg:- - - pc gb7djk PC33^GB7TLH^GB7DJK^400^ - -You can also use in the same way as a talk command to a connected user but -without any processing, added of "from <blah> to <blah>" or whatever. - - pc G1TLH Try doing that properly!!! - -<sect1>ping (1) - -<P> -<tt> -<bf>ping <node></bf> Check the link quality between nodes -</tt> - -<P> -his command allows you to send a frame to another cluster node on -the network and get a return frame. The time it takes to do this -is a good indication of the quality of the link. The actual time -it takes is output to the console in seconds. -Any visible cluster node can be PINGed. - - -<sect1>rcmd (1) - -<P> -<tt> -<bf>rcmd <node call> <cmd></bf> Send a command to another DX cluster -</tt> - -<P> -This command allows you to send nearly any command to another DX Cluster -node that is connected to the system. - -Whether you get any output is dependant on a) whether the other system knows -that the node callsign of this cluster is in fact a node b) whether the -other system is allowing RCMDs from this node and c) whether you have -permission to send this command at all. - -<sect1>read (0) - -<P> -<tt> -<bf>read</bf> Read the next unread personal message addressed to you<newline> -<bf>read <msgno></bf> Read the specified message<newline> -</tt> - -<P> -You can read any messages that are sent as 'non-personal' and also any -message either sent by or sent to your callsign. - - -<sect1>read (extended for sysops) (5) - -<P> -<tt> -<bf>read <msgno></bf> Read a message on the system -</tt> - -<P> -As a sysop you may read any message on the system - -<sect1>reject/announce - -<P> -<tt> -<bf>reject/announce [0-9] <pattern></bf> Set a reject filter -for announce -</tt> - -<P> -Create an 'reject this announce' line for a filter. - -An reject filter line means that if the announce matches this filter it is -passed onto the user. See HELP FILTERS for more info. Please read this -to understand how filters work - it will save a lot of grief later on. - -You can use any of the following things in this line:- - -<tscreen><verb> - info <string> eg: iota or qsl - by <prefixes> eg: G,M,2 - origin <prefixes> - origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G) - origin_itu <numbers> - origin_zone <numbers> - by_dxcc <numbers> - by_itu <numbers> - by_zone <numbers> - channel <prefixes> - wx 1 filter WX announces - dest <prefixes> eg: 6MUK,WDX (distros) -</verb></tscreen> - -some examples:- - -<tscreen><verb> - rej/ann by_zone 14,15,16 and not by G,M,2 -</verb></tscreen> - -You can use the tag 'all' to reject everything eg: - -<tscreen><verb> - rej/ann all -</verb></tscreen> - -but this probably for advanced users... - -<sect1>reject/announce (extended for sysops) (8) - -<P> -<tt> -<bf>reject/announce <call> [input] [0-9] <pattern></bf> Announce filter sysop version -</tt> - -<P> -This version allows a sysop to set a filter for a callsign as well as the -default for nodes and users eg:- - -<tscreen><verb> - reject/ann by G,M,2 - reject/ann input node_default by G,M,2 - reject/ann user_default by G,M,2 -</verb></tscreen> - -<sect1>reject/spots (0) - -<P> -<tt> -<bf>reject/spots [0-9] <pattern></bf> Set a reject filter -line for spots -</tt> - -<P> -Create a 'reject this spot' line for a filter. - -A reject filter line means that if the spot matches this filter it is -dumped (not passed on). See HELP FILTERS for more info. Please read this -to understand how filters work - it will save a lot of grief later on. - -You can use any of the following things in this line:- - -<tscreen><verb> - freq <range> eg: 0/30000 or hf or hf/cw or 6m,4m,2m - on <range> same as 'freq' - call <prefixes> eg: G,PA,HB9 - info <string> eg: iota or qsl - by <prefixes> - call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G) - call_itu <numbers> - call_zone <numbers> - by_dxcc <numbers> - by_itu <numbers> - by_zone <numbers> - origin <prefixes> - channel <prefixes> -</verb></tscreen> - -For frequencies, you can use any of the band names defined in -SHOW/BANDS and you can use a subband name like: cw, rtty, data, ssb - -thus: hf/ssb. You can also just have a simple range like: 0/30000 - -this is more efficient than saying simply: on HF (but don't get -too hung up about that) - -some examples:- - -<tscreen><verb> - rej/spot 1 on hf - rej/spot 2 on vhf and not (by_zone 14,15,16 or call_zone 14,15,16) -</verb></tscreen> - -You can use the tag 'all' to reject everything eg: - -<tscreen><verb> - rej/spot 3 all -</verb></tscreen> - -but this probably for advanced users... - -<sect1>reject/spots (extended for sysops) (8) - -<P> -<tt> -<bf>reject/spots <call> [input] [0-9] <pattern></bf> - Reject spot filter sysop version -</tt> - -<P> -This version allows a sysop to set a filter for a callsign as well as the -default for nodes and users eg:- - -<tscreen><verb> - reject/spot db0sue-7 1 by_zone 14,15,16 - reject/spot node_default all - set/hops node_default 10 - - reject/spot user_default by G,M,2 -</verb></tscreen> - -<sect1>reject/wcy (0) - -<P> -<tt> -<bf>reject/wcy [0-9] <pattern></bf> Set a reject WCY filter -</tt> - -<P> -It is unlikely that you will want to do this, but if you do then you can -filter on the following fields:- - -<tscreen><verb> - by <prefixes> eg: G,M,2 - origin <prefixes> - origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G) - origin_itu <numbers> - origin_zone <numbers> - by_dxcc <numbers> - by_itu <numbers> - by_zone <numbers> - channel <prefixes> -</verb></tscreen> - -There are no examples because WCY Broadcasts only come from one place and -you either want them or not (see UNSET/WCY if you don't want them). - -This command is really provided for future use. - -See HELP FILTER for information. - -<sect1>reject/wcy (extended for sysops) (8) - -<P> -<tt> -<bf>reject/wcy <call> [input] [0-9] <pattern></bf> - WCY reject filter sysop version -</tt> - -<P> -This version allows a sysop to set a filter for a callsign as well as the -default for nodes and users eg:- - - reject/wcy gb7djk all - -<sect1>reject/wwv (0) - -<P> -<tt> -<bf>reject/wwv [0-9] <pattern></bf> Set a reject WWV filter -</tt> - -<P> -It is unlikely that you will want to do this, but if you do then you can -filter on the following fields:- - -<tscreen><verb> - by <prefixes> eg: G,M,2 - origin <prefixes> - origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G) - origin_itu <numbers> - origin_zone <numbers> - by_dxcc <numbers> - by_itu <numbers> - by_zone <numbers> - channel <prefixes> -</verb></tscreen> - -for example - -<tscreen><verb> - reject/wwv by_zone 14,15,16 -</verb></tscreen> - -is probably the only useful thing to do (which will only show WWV broadcasts -by stations in the US). - -See HELP FILTER for information. - -<sect1>reject/wwv (extended for sysops) (8) - -<P> -<tt> -<bf>reject/wwv <call> [input] [0-9] <pattern></bf> - WWV reject filter sysop version -</tt> - -<P>This version allows a sysop to set a filter for a callsign as well as the -default for nodes and users eg:- - -<tscreen><verb> - reject/wwv db0sue-7 1 by_zone 4 - reject/wwv node_default all - - reject/wwv user_default by W -</verb></tscreen> - -<sect1>reply (0) - -<P> -<tt> -<bf>reply</bf> Reply (privately) to the last message that you have read<newline> -<bf>reply <msgno></bf> Reply (privately) to the specified message<newline> -<bf>reply B <msgno></bf> Reply as a Bulletin to the specified message<newline> -<bf>reply NOPrivate <msgno></bf> Reply as a Bulletin to the specified -message<newline> -<bf>reply RR <msgno></bf> Reply to the specified message with read -receipt<newline> -</tt> - -<P> -You can reply to a message and the subject will automatically have -"Re:" inserted in front of it, if it isn't already present. - -You can also use all the extra qualifiers such as RR, PRIVATE, -NOPRIVATE, B that you can use with the SEND command (see SEND -for further details) - -<sect1>send (0) - -<P> -<tt> -<bf>send <call> [<call> ...]</bf> Send a message to -one or more callsigns<newline> -<bf>send RR <call></bf> Send a message and ask for a read receipt<newline> -<bf>send COPY <msgno> <call></bf> Send a copy of a message -to someone<newline> -<bf>send PRIVATE <call></bf> Send a personal message<newline> -<bf>send NOPRIVATE <call></bf> Send a message to all stations<newline> -</tt> - -<P> -All the SEND commands will create a message which will be sent either to -an individual callsign or to one of the 'bulletin' addresses. - -SEND <call> on its own acts as though you had typed SEND PRIVATE, that is -it will mark the message as personal and send it to the cluster node that -that callsign is connected to. - -You can have more than one callsign in all of the SEND commands. - -You can have multiple qualifiers so that you can have for example:- - -<tscreen><verb> - SEND RR COPY 123 PRIVATE G1TLH G0RDI -</verb></tscreen> - -which should send a copy of message 123 to G1TLH and G0RDI and you will -receive a read receipt when they have read the message. - -SB is an alias for SEND NOPRIVATE (or send a bulletin in BBS speak) -SP is an alias for SEND PRIVATE - -<sect1>set/address (0) - -<P> -<tt> -<bf>set/address <your_address></bf> Record your postal address -</tt> - -<P> -Literally, record your address details on the cluster. - -<sect1>set/announce (0) - -<P> -<tt> -<bf>set/announce</bf> Allow announce messages -</tt> - -<P> -Allow announce messages to arrive at your terminal. - -<sect1>set/arcluster (5) - -<P> -<tt> -<bf>set/arcluster <node_call> [<node_call> ...]</bf> Make -the node_call an AR-Cluster type node -</tt> - -<P> -Set the node_call as an AR-Cluster type node - -<sect1>set/baddx (8) - -<P> -<tt> -<bf>set/baddx <call></bf> Stop words we do not wish to see in the callsign field -of a dx spot being propagated -</tt> - -<P> -Setting a word as 'baddx' will prevent spots with that word in the callsign -field of a DX spot from going any further. They will not be displayed and they -will not be sent onto other nodes. - -The word must be wriiten in full, no wild cards are allowed eg:- - -<tscreen><verb> - set/baddx FORSALE VIDEO FR0G -</verb></tscreen> - -To allow a word again, use the following command ... - -<tscreen><verb> - unset/baddx VIDEO -</verb></tscreen> - -<sect1>set/badnode (6) - -<P> -<tt> -<bf>set/badnode <node_call></bf> Stop spots from this node_call -being propagated -</tt> - -<P> -Setting a callsign as a 'badnode' will prevent spots from that node -going any further. They will not be displayed and they will not be -sent onto other nodes. - -The call can be a full or partial call (or a prefix), eg:- - -<tscreen><verb> - set/badnode K1TTT -</verb></tscreen> - -will stop anything from K1TTT (including any SSID's) - -<tscreen><verb> - unset/badnode K1TTT -</verb></tscreen> - -will allow spots from him again. - -Use with extreme care. This command may well be superceded by FILTERing. - -<sect1>set/badspotter (8) - -<P> -<tt> -<bf>set/badspotter <call></bf> Stop spots from this callsign being propagated -</tt> - -<P> -Setting a callsign as a 'badspotter' will prevent spots from this callsign -going any further. They will not be displayed and they will not be -sent onto other nodes. - -The call must be written in full, no wild cards are allowed eg:- - -<tscreen><verb> - set/badspotter VE2STN -</verb></tscreen> - -will stop anything from VE2STN. If you want SSIDs as well then you must -enter them specifically. - -<tscreen><verb> - unset/badspotter VE2STN -</verb></tscreen> - -will allow spots from him again. - -Use with extreme care. This command may well be superceded by FILTERing. - -<sect1>set/beep (0) - -<P> -<tt> -<bf>set/beep</bf> Add beeps to terminal messages -</tt> - -<P> -Add a beep to DX and other terminal messages. - -<sect1>set/clx (5) - -<P> -<tt> -<bf>set/clx <node_call> [<node_call> ...]</bf> Make -the node_call a CLX type node -</tt> - -<P> -Set the node_call as a CLX type node - -<sect1>set/debug (9) - -<P> -<tt> -<bf>set/debug <name></bf> Add a debug level to the debug set -</tt> - -<P> -You can choose to log several different levels. The levels are - -chan -state -msg -cron -connect - -You can show what levels you are logging with the <em>show/debug</em> -command. - -You can remove a debug level with unset/debug <name> - -<sect1>set/dx (0) - -<P> -<tt> -<bf>set/dx</bf>Allow DX messages to arrive at your terminal -</tt> - -<P> -You can stop DX messages with the <em>unset/dx</em> command - -<sect1>set/dxgrid (0) - -<P> -<tt> -<bf>set/dxgrid</bf>Allow grid squares on the end of DX messages -</tt> - -<P> -Some logging programs do not like the additional information at -the end of a DX spot. If this is the case, use the <em>unset/dxgrid</em> -command to remove the grid squares. - -<sect1>set/dxnet (5) - -<P> -<tt> -<bf>set/dxnet <node_call> [<node_call> ...]</bf> Make -the node_call a DXNet type node -</tt> - -<P> -Set the node_call as a DXNet type node - -<sect1>set/echo (0) - -<P> -<tt> -<bf>set/echo</bf> Make the cluster echo your input -</tt> - -<P> -If you are connected via a telnet session, different implimentations -of telnet handle echo differently depending on whether you are -connected via port 23 or some other port. You can use this command -to change the setting appropriately. - -You can remove the echo with the <em>unset/echo</em> command - -The setting is stored in your user profile. - -YOU DO NOT NEED TO USE THIS COMMAND IF YOU ARE CONNECTED VIA AX25. - -<sect1>set/here (0) - -<P> -<tt> -<bf>set/here</bf> Set the here flag -</tt> - -<P> -Let others on the cluster know you are here by only displaying your -callsign. If you are away from your terminal you can use the <em>unset/here</em> -command to let people know you are away. This simply puts brackets -around your callsign to indicate you are not available. - -<sect1>set/homenode (0) - -<P> -<tt> -<bf>set/homenode <node_call></bf> Set your home cluster -</tt> - -<P> -Tell the cluster system where you normally connect to. Any Messages sent -to you will normally find their way there should you not be connected. -eg:- - -<tscreen><verb> - SET/HOMENODE gb7djk -</verb></tscreen> - -<sect1>set/hops (8) - -<P> -<tt> -<bf>set/hops <node_call> ann|spots|wwv|wcy <n></bf> -Set hop count -</tt> - -<P> -Set the hop count for a particular type of broadcast for a node. - -This command allows you to set up special hop counts for a node -for currently: announce, spots, wwv and wcy broadcasts. - -<tscreen><verb> -eg: - set/hops gb7djk ann 10 - set/hops gb7mbc spots 20 -</verb></tscreen> - -Set SHOW/HOPS for information on what is already set. This command -creates a filter and works in conjunction with the filter system. - -<sect1>set/isolate (9) - -<P> -<tt> -<bf>set/isolate <node call></bf> Isolate a node from the rest of the network -</tt> - -<P> -Connect a node to your system in such a way that you are a full protocol -member of its network and can see all spots on it, but nothing either leaks -out from it nor goes back into from the rest of the nodes connected to you. - -You can potentially connect several nodes in this way. - -You can see which nodes are isolated with the show/isolate (1) command. - -You can remove the isolation with the command unset/isolate. - -<sect1>set/language (0) - -<P> -<tt> -<bf>set/language <language></bf> Set the language you wish to use -</tt> - -<P> -You can select the language that you want the cluster to use. Currently -the languages available are <em>en</em> (English) and <em>nl</em> (Dutch). - -<sect1>set/location (0) - -<P> -<tt> -<bf>set/location <lat and long></bf> Set your latitude and longitude -</tt> - -<P> -You can set your latitude and longitude manually or alternatively use the -<em>set/qra</em> command which will do the conversion for you. - -<tscreen><verb> - set/location 54 04 N 2 02 E -</verb></tscreen> - - -<sect1>set/sys_location (9) - -<P> -<tt> -<bf>set/sys_location <lat & long></bf> Set your cluster latitude and longitude -</tt> - -<P> -In order to get accurate headings and such like you must tell the system -what your latitude and longitude is. If you have not yet done a SET/QRA -then this command will set your QRA locator for you. For example:- - -<tscreen><verb> - SET/LOCATION 52 22 N 0 57 E -</verb></tscreen> - -<sect1>set/logininfo (0) - -<P> -<tt> -<bf>set/logininfo</bf> Show logins and logouts of nodes and users -</tt> - -<P> -Show users and nodes when they log in and out of the local cluster. You -can stop these messages by using the <em>unset/logininfo</em> command. - - -<sect1>set/lockout (9) - -<P> -<tt> -<bf>set/lockout <call></bf> Stop a callsign connecting to the cluster -</tt> - -<P> -You can show who is locked out with the <em>show/lockout</em> command. -To allow the user to connect again, use the <em>unset/lockout</em> command. - -<sect1>set/name (0) - -<P> -<tt> -<bf>set/name <your_name></bf> Set your name -</tt> - -<P> -Tell the cluster what your name is, eg:- - -<tscreen><verb> - set/name Dirk -</verb></tscreen> - -<sect1>set/node (9) - -<P> -<tt> -<bf>set/node <call> [<call> ...]</bf> Make the callsign an AK1A cluster -</tt> - -<P> -Tell the system that the call(s) are to be treated as AK1A cluster and -fed PC Protocol rather normal user commands. - -From version 1.41 you can also set the following types of cluster - -<tscreen><verb> - set/spider - set/dxnet - set/clx - set/arcluster -</verb></tscreen> - -To see what your nodes are set to, use the <em>show/nodes</em> command. - -<sect1>set/obscount (9) - -<P> -<tt> -<bf>set/obscount <count> <node call></bf> Set the 'pump-up' -obsolescence counter -</tt> - -<P> -From version 1.35 onwards neighbouring nodes are pinged at regular intervals (see -SET/PINGINTERVAL), usually 300 seconds or 5 minutes. There is a 'pump-up' -counter which is decremented on every outgoing ping and then reset to -the 'obscount' value on every incoming ping. The default value of this -parameter is 2. - -What this means is that a neighbouring node will be pinged twice at -(default) 300 second intervals and if no reply has been heard just before -what would be the third attempt, that node is disconnected. - -If a ping is heard then the obscount is reset to the full value. Using -default values, if a node has not responded to a ping within 15 minutes, -it is disconnected. - -<sect1>set/page (0) - -<P> -<tt> -<bf>set/page <n></bf> Set the number of lines per page -</tt> - -<P> -Tell the system how many lines you wish on a page when the number of lines -of output from a command is more than this. The default is 20. Setting it -explicitly to 0 will disable paging. - -<tscreen><verb> - SET/PAGE 30 - SET/PAGE 0 -</verb></tscreen> - -The setting is stored in your user profile. - - -<sect1>set/password (9) - -<P> -<tt> -<bf>set/password <callsign> <string></bf> Set a users password -</tt> - -<P> -The password for a user can only be set by a full sysop. The string -can contain any characters but any spaces are removed (you can type in -spaces - but they won't appear in the password). You can see the -result with STAT/USER. The password is the usual 30 character baycom -type password. - -<sect1>set/pinginterval (9) - -<P> -<tt> -<bf>set/pinginterval <time> <node call></bf> Set the ping time -to neighbouring nodes -</tt> - -<P> -As from version 1.35 all neighbouring nodes are pinged at regular intervals -in order to determine the rolling quality of the link and, in future, to -affect routing decisions. The default interval is 300 secs or 5 minutes. - -You can use this command to set a different interval. Please don't. - -But if you do the value you enter is treated as minutes up 60 and seconds -for numbers greater than that. - -This is used also to help determine when a link is down at the far end -(as certain cluster software doesn't always notice), see SET/OBSCOUNT -for more information. - -<sect1>set/privilege (9) - -<P> -<tt> -<bf>set/privilege <n> <call> [<call> ...]</bf> Set the -privilege level on a call -</tt> - -<P> -Set the privilege level on a callsign. The privilege levels that pertain -to commands are as default:- - -<tscreen><verb> - 0 - normal user - 1 - allow remote nodes normal user RCMDs - 5 - various privileged commands (including shutdown, but not disc- - connect), the normal level for another node. - 8 - more privileged commands (including disconnect) - 9 - local sysop privilege. DO NOT SET ANY REMOTE USER OR NODE TO THIS - LEVEL. -</verb></tscreen> - -If you are a sysop and you come in as a normal user on a remote connection -your privilege will automatically be set to 0. - -<sect1>set/spider (5) - -<P> -<tt> -<bf>set/spider <node_call> [<node_call> ...]</bf> Make -the node_call a DXSpider type node -</tt> - -<P> -Set the node_call as a DXSpider type node - -<sect1>set/sys_qra (9) - -<P> -<tt> -<bf>set/sys_qra <locator></bf> Set your cluster QRA locator -</tt> - -<sect1>set/qra (0) - -<P> -<tt> -<bf>set/qra <locator></bf> Set your QRA locator -</tt> - -<P> -Tell the system what your QRA (or Maidenhead) locator is. If you have not -done a SET/LOCATION then your latitude and longitude will be set roughly -correctly (assuming your locator is correct ;-). For example:- - -<tscreen><verb> - SET/QRA JO02LQ -</verb></tscreen> - -<sect1>set/qth (0) - -<P> -<tt> -<bf>set/qth <your QTH></bf> Set your QTH -</tt> - -<P> -Tell the system where your are. For example:- - -<tscreen><verb> - set/qth East Dereham, Norfolk -</verb></tscreen> - -<sect1>set/talk (0) - -<P> -<tt> -<bf>set/talk</bf> Allow talk messages to be seen at your console -</tt> - -<P> -Allow talk messages to arrive at your console. You can switch off -talks with the <em>unset/talk</em> command. - -<sect1>set/wcy (0) - -<P> -<tt> -<bf>set/wcy</bf> Allow WCY messages to be seen at your console -</tt> - -<P> -Allow WCY information to be seen at your console. You can switch off -WCY messages with the <em>unset/wcy</em> command. - -<sect1>set/wwv (0) - -<P> -<tt> -<bf>set/wwv</bf> Allow WWV messages to be seen at your console -</tt> - -<P> -Allow WWV information to be seen at your console. You can switch off -WWV messages with the <em>unset/wwv</em> command. - -<sect1>set/wx (0) - -<P> -<tt> -<bf>set/wx</bf> Allow WX messages to be seen at your console -</tt> - -<P> -Allow WX information to be seen at your console. You can switch off -WX messages with the <em>unset/wx</em> command. - -<sect1>show/baddx (1) - -<P> -<tt> -<bf>show/baddx</bf>Show all the bad dx calls in the system -</tt> - -<P> -Display all the bad dx callsigns in the system, see SET/BADDX -for more information. - -<sect1>show/badnode (6) - -<P> -<tt> -<bf>show/badnode</bf> Show all the bad nodes in the system -</tt> - -<P> -Display all the bad node callsigns in the system, see SET/BADNODE -for more information. - -<sect1>show/badspotter (1) - -<P> -<tt> -<bf>show/badspotter</bf> Show all the bad spotters in the system -</tt> - -<P> -Display all the bad spotter's callsigns in the system, see SET/BADSPOTTER -for more information. - -<sect1>show/date (0) - -<P> -<tt> -<bf>show/date [<prefix>|<callsign>]</bf> Show -the local time -</tt> - -<P> -This is very nearly the same as SHOW/TIME, the only difference the format -of the date string if no arguments are given. - -If no prefixes or callsigns are given then this command returns the local -time and UTC as the computer has it right now. If you give some prefixes -then it will show UTC and UTC + the local offset (not including DST) at -the prefixes or callsigns that you specify. - -<sect1>show/debug (9) - -<P> -<tt> -<bf>show/debug</bf> Show what levels of debug you are logging -</tt> - -<P> -The levels can be set with <em>set/debug</em> - -<sect1>show/dx (0) - -<P> -<tt> -<bf>show/dx [options]</bf> interrogate the spot database -</tt> - -<P> -If you just type SHOW/DX you will get the last so many spots -(sysop configurable, but usually 10). - -In addition you can add any number of these options in very nearly -any order to the basic SHOW/DX command, they are:- - -<tscreen><verb> -on <band> - eg 160m 20m 2m 23cm 6mm -on <region> - eg hf vhf uhf shf (see SHOW/BANDS) - -<number> - the number of spots you want -<from>-<to> - <from> spot no <to> spot no in - the selected list - -<prefix> - for a spotted callsign beginning with <prefix> -*<suffix> - for a spotted callsign ending in <suffix> -*<string>* - for a spotted callsign containing <string> - -day <number> - starting <number> days ago -day <from>-<to> - <from> days <to> days ago - -info <text> - any spots containing <text> in the info or remarks - -by <call> - any spots spotted by <call> (spotter <call> - is the same). - -qsl - this automatically looks for any qsl info on the call - held in the spot database. - -iota [<iota>] - If the iota island number is missing it will - look for the string iota and anything which looks like - an iota island number. If you specify then it will look - for that island. - -qra [<locator>] - this will look for the specific locator if - you specify one or else anything that looks like a locator. -</verb></tscreen> - -e.g. - -<tscreen><verb> - SH/DX 9m0 - SH/DX on 20m info iota - SH/DX 9a on vhf day 30 - SH/DX rf1p qsl - SH/DX iota - SH/DX iota eu-064 - SH/DX qra jn86 -</verb></tscreen> - -<sect1>show/dxcc (0) - -<P> -<tt> -<bf>show/dxcc <prefix></bf> Interrogate the spot database by country -</tt> - -<P> -This command takes the <prefix> (which can be a full or partial -callsign if desired), looks up which internal country number it is -and then displays all the spots as per SH/DX for that country. - -The options for SHOW/DX also apply to this command. -e.g. - -<tscreen><verb> - SH/DXCC G - SH/DXCC W on 20m info iota -</verb></tscreen> - -<sect1>show/files (0) - -<P> -<tt> -<bf>show/files [<filearea> [<string>]]</bf> List -the contents of a filearea -</tt> - -<P> -SHOW/FILES on its own will show you a list of the various fileareas -available on the system. To see the contents of a particular file -area type:- - -<tscreen><verb> - SH/FILES <filearea> -</verb></tscreen> - -where <filearea> is the name of the filearea you want to see the -contents of. - -You can also use shell globbing characters like '*' and '?' in a -string to see a selection of files in a filearea eg:- - -<tscreen><verb> - SH/FILES bulletins arld* -</verb></tscreen> - -See also TYPE - to see the contents of a file. - -<sect1>show/filter (0) - -<P> -<tt> -<bf>show/filter</bf> Show the filters you have set -</tt> - -<P> -Show the contents of all the filters that are set by you. This command -displays all the filters set - for all the various categories. - -<sect1>show/filter (extended for sysops) (5) - -<P> -<tt> -<bf>show/filter <callsign></bf> Show the filters set by <callsign> -</tt> - -<P> -A sysop can look at any filters that have been set. - -<sect1>show/hops (8) - -<P> -<tt> -<bf>show/hops <node_call> [ann|spots|wcy|wwv|]</bf> Show the hop -counts for a node -</tt> - -<P> -This command shows the hop counts set up for a node. You can specify -which category you want to see. If you leave the category out then -all the categories will be listed. - -<sect1>show/isolate (1) - -<P> -<tt> -<bf>show/isolate</bf> Show a list of isolated nodes -</tt> - -<P> -Show which nodes are currently set to be isolated. - -<sect1>show/lockout (9) - -<P> -<tt> -<bf>show/lockout</bf> Show a list of excluded callsigns -</tt> - -<P> -Show a list of callsigns that have been excluded (locked out) of the -cluster locally with the <em>set/lockout</em> command - -<sect1>show/log (8) - -<P> -<tt> -<bf>show/log [<callsign>]</bf> Show excerpts from the system log -</tt> - -<P> -This command outputs a short section of the system log. On its own -it will output a general logfile. With the optional callsign it will -show output from the log associated with that callsign. - -<sect1>show/moon (0) - -<P> -<tt> -<bf>show/moon [<prefix>|<callsign>]</bf> Show moon -rise and set times -</tt> - -<P> -Show the Moon rise and set times for a (list of) prefixes or callsigns, -together with the azimuth and elevation of the sun currently at those -locations. - -If you don't specify any prefixes or callsigns, it will show the times for -your QTH (assuming you have set it with either SET/LOCATION or SET/QRA), -together with the current azimuth and elevation. - -In addition, it will show the gain or loss dB relative to the nominal -distance of 385,000Km due to the ellipsoidal nature of the orbit. - -If all else fails it will show the Moonrise and set times for the node -that you are connected to. - -For example:- - -<tscreen><verb> - SH/MOON - SH/MOON G1TLH W5UN -</verb></tscreen> - -<sect1>show/muf (0) - -<P> -<tt> -<bf>show/muf <prefix> [<hours>][long]</bf> Show -the likely propagation to <prefix> -</tt> - -<P> -This command allow you to estimate the likelihood of you contacting -a station with the prefix you have specified. The output assumes a modest -power of 20dBW and receiver sensitivity of -123dBm (about 0.15muV/10dB SINAD) - -The result predicts the most likely operating frequencies and signal -levels for high frequency (shortwave) radio propagation paths on -specified days of the year and hours of the day. It is most useful for -paths between 250 km and 6000 km, but can be used with reduced accuracy -for paths shorter or longer than this. - -The command uses a routine MINIMUF 3.5 developed by the U.S. Navy and -used to predict the MUF given the predicted flux, day of the year, -hour of the day and geographic coordinates of the transmitter and -receiver. This routine is reasonably accurate for the purposes here, -with a claimed RMS error of 3.8 MHz, but much smaller and less complex -than the programs used by major shortwave broadcasting organizations, -such as the Voice of America. - -The command will display some header information detailing its -assumptions, together with the locations, latitude and longitudes and -bearings. It will then show UTC (UT), local time at the other end -(LT), calculate the MUFs, Sun zenith angle at the midpoint of the path -(Zen) and the likely signal strengths. Then for each frequency for which -the system thinks there is a likelihood of a circuit it prints a value. - -The value is currently a likely S meter reading based on the conventional -6dB / S point scale. If the value has a '+' appended it means that it is -1/2 an S point stronger. If the value is preceeded by an 'm' it means that -there is likely to be much fading and by an 's' that the signal is likely -to be noisy. - -By default SHOW/MUF will show the next two hours worth of data. You -can specify anything up to 24 hours worth of data by appending the no of -hours required after the prefix. For example:- - -<tscreen><verb> - SH/MUF W -</verb></tscreen> - -produces: - -<tscreen><verb> - RxSens: -123 dBM SFI: 159 R: 193 Month: 10 Day: 21 - Power : 20 dBW Distance: 6283 km Delay: 22.4 ms - Location Lat / Long Azim - East Dereham, Norfolk 52 41 N 0 57 E 47 - United-States-W 43 0 N 87 54 W 299 - UT LT MUF Zen 1.8 3.5 7.0 10.1 14.0 18.1 21.0 24.9 28.0 50.0 - 18 23 11.5 -35 mS0+ mS2 S3 - 19 0 11.2 -41 mS0+ mS2 S3 -</verb></tscreen> - -indicating that you will have weak, fading circuits on top band and -80m but usable signals on 40m (about S3). - -inputing:- - -<tscreen><verb> - SH/MUF W 24 -</verb></tscreen> - -will get you the above display, but with the next 24 hours worth of -propagation data. - -<tscreen><verb> - SH/MUF W L 24 - SH/MUF W 24 Long -</verb></tscreen> - -Gives you an estimate of the long path propagation characterics. It -should be noted that the figures will probably not be very useful, nor -terrible accurate, but it is included for completeness. - -<sect1>show/node (1) - -<P> -<tt> -<bf>show/node [<node_call> ...]</bf> Show the type and version -number of nodes -</tt> - -<P> -Show the type and version (if connected) of the nodes specified on the -command line. If no callsigns are specified then a sorted list of all -the non-user callsigns known to the system will be displayed. - -<sect1>show/prefix (0) - -<P> -<tt> -<bf>show/prefix <callsign></bf> Interrogate the prefix database -</tt> - -<P> -This command takes the <callsign> (which can be a full or partial -callsign or a prefix), looks up which internal country number -it is and then displays all the relevant prefixes for that country -together with the internal country no, the CQ and ITU regions. - -See also SHOW/DXCC - - -<sect1>show/program (5) - -<P> -<tt> -<bf>show/program</bf> Show the locations of all the included program modules -</tt> - -<P> -Show the name and location where every program module was load from. This -is useful for checking where you think you have loaded a .pm file from. - -<sect1>show/qra (0) - -<P> -<tt> -<bf>show/qra <locator> [<locator>]</bf> Show the distance -between locators<newline> -<bf>show/qra <lat> <long></bf> Convert latitude and longitude to -a locator -</tt> - -<P> -This is a multipurpose command that allows you either to calculate the -distance and bearing between two locators or (if only one locator is -given on the command line) the distance and beraing from your station -to the locator. For example:- - -<tscreen><verb> -SH/QRA IO92QL -SH/QRA JN06 IN73 -</verb></tscreen> - -The first example will show the distance and bearing to the locator from -yourself, the second example will calculate the distance and bearing from -the first locator to the second. You can use 4 or 6 character locators. - -It is also possible to convert a latitude and longitude to a locator by -using this command with a latitude and longitude as an argument, for -example:- - -<tscreen><verb> -SH/QRA 52 41 N 0 58 E -</verb></tscreen> - -<sect1>show/qrz (0) - -<P> -<tt> -<bf>show/qrz <callsign></bf> Show any callbook details on a callsign -</tt> - -<P> -This command queries the QRZ callbook server on the internet -and returns any information available for that callsign. This service -is provided for users of this software by http://www.qrz.com - -<sect1>show/route (0) - -<P> -<tt> -<bf>show/route <callsign></bf> Show the route to <callsign> -</tt> - -<P> -This command allows you to see to which node the callsigns specified are -connected. It is a sort of inverse sh/config. - -<tscreen><verb> - sh/route n2tly -</verb></tscreen> - -<sect1>show/satellite (0) - -<P> -<tt> -<bf>show/satellite <name> [<hours> <interval>]</bf> -Show satellite tracking data -</tt> - -<P> -Show the tracking data from your location to the satellite of your choice -from now on for the next few hours. - -If you use this command without a satellite name it will display a list -of all the satellites known currently to the system. - -If you give a name then you can obtain tracking data of all the passes -that start and finish 5 degrees below the horizon. As default it will -give information for the next three hours for every five minute period. - -You can alter the number of hours and the step size, within certain -limits. - -Each pass in a period is separated with a row of '-----' characters - -So for example:- - -<tscreen><verb> -SH/SAT AO-10 -SH/SAT FENGYUN1 12 2 -</verb></tscreen> - -<sect1>show/sun (0) - -<P> -<tt> -<bf>show/sun [<prefix>|<callsign>]</bf> Show -sun rise and set times -</tt> - -<P> -Show the sun rise and set times for a (list of) prefixes or callsigns, -together with the azimuth and elevation of the sun currently at those -locations. - -If you don't specify any prefixes or callsigns, it will show the times for -your QTH (assuming you have set it with either SET/LOCATION or SET/QRA), -together with the current azimuth and elevation. - -If all else fails it will show the sunrise and set times for the node -that you are connected to. - -For example:- - -<tscreen><verb> - SH/SUN - SH/SUN G1TLH K9CW ZS -</verb></tscreen> - -<sect1>show/time (0) - -<P> -<tt> -<bf>show/time [<prefix>|<callsign>]</bf> Show -the local time -</tt> - -<P> -If no prefixes or callsigns are given then this command returns the local -time and UTC as the computer has it right now. If you give some prefixes -then it will show UTC and UTC + the local offset (not including DST) at -the prefixes or callsigns that you specify. - -<sect1>show/wcy (0) - -<P> -<tt> -<bf>show/wcy</bf> Show the last 10 WCY broadcasts<newline> -<bf>show/wcy <n></bf> Show the last <n> WCY broadcasts -</tt> - -<P> -Display the most recent WCY information that has been received by the system - -<sect1>show/wwv (0) - -<P> -<tt> -<bf>show/wwv</bf> Show the last 10 WWV broadcasts<newline> -<bf>show/wwv <n></bf> Show the last <n> WWV broadcasts -</tt> - -<P> -Display the most recent WWV information that has been received by the system - - -<sect1>shutdown (5) - -<P> -<tt> -<bf>shutdown</bf> Shutdown the cluster -</tt> - -<P> -Shutdown the cluster and disconnect all the users. If you have Spider -set to respawn in /etc/inittab it will of course restart. - -<sect1>spoof (9) - -<P> -<tt> -<bf>spoof <callsign> <command></bf> Run commands as another user -</tt> - -<P> -This is a very simple yet powerful command for the sysop. It allows you to -issue commands as if you were a different user. This is very useful for the -kind of things that users seem to always get wrong.. like home_node for -example. - -<sect1>stat/db (5) - -<P> -<tt> -<bf>stat/db <dbname></bf> Show the status of a database -</tt> - -<P> -Show the internal status of a database descriptor. - -Depending on your privilege level you will see more or less information. -This command is unlikely to be of much use to anyone other than a sysop. - -<sect1>stat/channel (5) - -<P> -<tt> -<bf>stat/channel <callsign></bf> Show the status of a channel on the cluster -</tt> - -<P> -Show the internal status of the channel object either for the channel that -you are on or else for the callsign that you asked for. - -Only the fields that are defined (in perl term) will be displayed. - -<sect1>stat/msg (5) - -<P> -<tt> -<bf>stat/msg <msgno></bf> Show the status of a message -</tt> - -<P> -This command shows the internal status of a message and includes information -such as to whom it has been forwarded, its size, origin etc etc. - -<sect1>stat/user (5) - -<P> -<tt> -<bf>stat/user <callsign></bf> Show the full status of a user -</tt> - -<P> -Shows the full contents of a user record including all the secret flags -and stuff. - -Only the fields that are defined (in perl term) will be displayed. - -<sect1>sysop (0) - -<P> -<tt> -<bf>sysop</bf> Regain your privileges if you login remotely -</tt> - -<P> -The system automatically reduces your privilege level to that of a -normal user if you login in remotely. This command allows you to -regain your normal privilege level. It uses the normal system: five -numbers are returned that are indexes into the character array that is -your assigned password (see SET/PASSWORD). The indexes start from -zero. - -You are expected to return a string which contains the characters -required in the correct order. You may intersperse those characters -with others to obscure your reply for any watchers. For example (and -these values are for explanation :-): - -<tscreen><verb> - password = 012345678901234567890123456789 - > sysop - 22 10 15 17 3 -</verb></tscreen> - -you type:- - -<tscreen><verb> - aa2bbbb0ccc5ddd7xxx3n - or 2 0 5 7 3 - or 20573 -</verb></tscreen> - -They will all match. If there is no password you will still be offered -numbers but nothing will happen when you input a string. Any match is -case sensitive. - -<sect1>talk (0) - -<P> -<tt> -<bf>talk <callsign></bf> Enter talk mode with <callsign><newline> -<bf>talk <callsign> <text></bf> Send a text message to <callsign><newline> -<bf>talk <callsign> > <node_call> [<text>]</bf> -Send a text message to <callsign> via <node_call> -</tt> - -<P> -Send a short message to any other station that is visible on the cluster -system. You can send it to anyone you can see with a SHOW/CONFIGURATION -command, they don't have to be connected locally. - -The second form of TALK is used when other cluster nodes are connected -with restricted information. This usually means that they don't send -the user information usually associated with logging on and off the cluster. - -If you know that G3JNB is likely to be present on GB7TLH, but you can only -see GB7TLH in the SH/C list but with no users, then you would use the -second form of the talk message. - -If you want to have a ragchew with someone you can leave the text message -out and the system will go into 'Talk' mode. What this means is that a -short message is sent to the recipient telling them that you are in a 'Talking' -frame of mind and then you just type - everything you send will go to the -station that you asked for. - -All the usual announcements, spots and so on will still come out on your -terminal. - -If you want to do something (such as send a spot) you precede the normal -command with a '/' character, eg:- - -<tscreen><verb> - /DX 14001 G1TLH What's a B class licensee doing on 20m CW? - /HELP talk -</verb></tscreen> - -To leave talk mode type: - -<tscreen><verb> - /EX -</verb></tscreen> - -<sect1>type (0) - -<P> -<tt> -<bf>type <filearea>/<name></bf> Look at a file in one of the fileareas -</tt> - -<P> -Type out the contents of a file in a filearea. So, for example, in -filearea 'bulletins' you want to look at file 'arld051' you would -enter:- - -<tscreen><verb> - TYPE bulletins/arld051 -</verb></tscreen> - -See also SHOW/FILES to see what fileareas are available and a -list of content. - -<sect1>who (0) - -<P> -<tt> -<bf>who</bf> Show who is physically connected locally -</tt> - -<P> -This is a quick listing that shows which callsigns are connected and -what sort of connection they have - -<sect1>wx (0) - -<P> -<tt> -<bf>wx <text></bf> Send a weather message to local users<newline> -<bf>wx full <text> </bf> Send a weather message to all cluster users -</tt> - -<P> -Weather messages can sometimes be useful if you are experiencing an extreme -that may indicate enhanced conditions - -<sect1>wx (enhanced for sysops) (5) - -<P> -<tt> -<bf>wx sysop <text></bf> Send a weather message to other clusters only -</tt> - -<P> -Send a weather message only to other cluster nodes and not to general users. - - - -</article> +<!doctype linuxdoc system> + +<article> + +<!-- Title information --> + +<title>The DXSpider Administration Manual v1.51 +Ian Maude, G0VGS, (g0vgs@gb7mbc.net), and +Charlie Carroll, K1XX, (k1xx@ptcnh.net) +June 2004 revision 1 + + +A reference for SysOps of the DXSpider DXCluster program. + + + + + + + +Routing and Filtering + +Introduction + +

+From DXSpider version 1.48, major changes were introduced to the way +node connections are treated. This is part of an ongoing process to +remove problems with loops and to enable talk and other functions to +propagate across the whole of the worldwide cluster network. In fact, +in a Spider network, it would be useful, perhaps even necessary to +have loops. This would give real resilience to the network, meaning +that if a link dropped, the information flow would simply come in and +go out via a different route. Of course, we do not have a complete +network of Spider nodes, there are other programs out there. Some of +these do not have any protection from loops. Certainly AK1A does not +handle loops well at all. It is therefore necessary to have some form +of protection for these nodes. + +

+In fact DXSpider has had a simple system for some time which is called +isolation. This is similar to what in other systems such as +clx, is called passive mode. A more detailed explanation +of isolation is given further below. This system is still available +and, for simple networks, is probably all that you need. + +

+The new functionality introduced in version 1.48 allows filtering the node +and user protocol frames on a "per interface" basis. We call this +route filtering. This is used instead of +isolation. + +

+What this really means is that you can control more or less completely +which user and node management PC protocol frames pass to each of your +partner nodes. You can also limit what comes into your node from your +partners. It is even possible to control the settings that your partner +node has for the routing information that it sends to you +(using the rcmd command). + +Route Filters + +

+Initially when route filters were being tested we generated a +"default" filter. Unfortunately it quickly became apparent that this +might suit the UK cluster network but didn't really fit anybody else. +However using a default filter is an appropriate thing to do. How, is +explained further on. + +

+The first thing that you must do is determine whether you need to use +route filtering at all. If you are a "normal" node with two or +three partners and you arranged in an "official" non-looping tree type +network, then you do not need to do route filtering and you will +feel a lot better for not getting involved. If you are successfully using +isolation then you also probably don't need to use route filtering. + +

+To put it simply, you should not mix Isolation and Route Filtering. It +will work, of sorts, but you will not get the expected results. If you +are using Isolation sucessfully at the moment, do not get involved in +Route Filtering unless you have a good supply of aspirin! Once you have +started down the road of Route Filtering, do not use Isolation either. +Use one or the other, not both. + +

+You will only require this functionality if you are "well-connected". What +that means is that you are connected to several different parts of (say) +the EU cluster and, at the same time, also connected to two or three places +in the US which, in turn are connected back to the EU. This is called a +"loop" and if you are seriously looped then you need filtering. + +

+I should at this stage give a little bit of background on filters. All +the filters in Spider work in basically the same way. You can either +accept or reject various options in order to create the filter rules +you wish to achieve. Some filters are user settable, others can only +be altered by the sysop. Route filtering can only be done by the sysop. + +

+Anyway, without further discouragement, let me start the process +of explanation. + +The node_default filter + +

+All normal systems should have a default routing filter and it should +usually be set to send only the normal, unlooped, view of your +"national" network. Here in the UK that means nodes from the UK and +Eire, in EU it is more complex as the networks there grew up in a more +intertwined way. + +

+The generic commands are:- + + +reject/route node_default <filter_option> + +or + +accept/route node_default <filter_option> + + +where filter_option is one of the following ... + + +call <prefixes> +call_dxcc <numbers> +call_itu <numbers> +call_zone <numbers> +channel <prefixes> +channel_dxcc <numbers> +channel_itu <numbers> +channel_zone <numbers> + + +Please be careful if you alter this setting, it will affect +ALL your links! Remember, this is a default +filter for node connections, not a per link default. + +

+For the default routing filter then you have two real choices: either +a "national" view or the "safe" option of only your own +callsign. Examples of each (for my node: GB7DJK) are:- + + +acc/route node_default call_dxcc 61,38 +acc/route node_default call gb7djk + + +GB7DJK uses the first of these. The DXCC countries can be obtained from the +show/prefix command. + +

+The example filters shown control output TO all your +partner nodes unless they have a specific filter applied to them (see +next section). + +

+It is also possible to control the incoming routing +information that you are prepared to accept FROM your partner +nodes. The reason this is necessary is to make sure that stuff like +mail, pings and similar commands a) go down the correct links and b) +don't loop around excessively. Again using GB7DJK as an example a typical +default input filter would be something like: + + +rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38 + + +What this does is accept node and user information for our national +network from nodes that are in our national network, but rejects such +information from anyone else. Although it doesn't explicitly say so, +by implication, any other node information (not from the UK and Eire) +is accepted. + +

+As I imagine it will take a little while to get one's head around all of +this you can study the effect of any rules that you try by watching the +debug output after having done:- + + +set/debug filter + + +After you have got tired of that, to put it back the way it was:- + + +unset/debug filter + + +General route filtering + +

+Exactly the same rules apply for general route filtering. You would +use either an accept filter or a reject filter like this ... + + +reject/route <node_call> <filter_option> + +or + +accept/route <node_call> <filter_option> + + +

+Here are some examples of route filters ... + + +rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes) +rej/route all (equiv to [very] restricted mode) +acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes) +acc/route gb7djk call gb7djk (equiv to SET/ISOLATE) + + +In practice you will either be opening the default filter out for a +partner by defining a specific filter for that callsign:- + + +acc/route gb7baa all +acc/route gb7baa input all + + +or restricting it quite a lot, in fact making it very nearly like an +isolated node, like this:- + + +acc/route pi4ehv-8 call gb7djk +rej/route pi4ehv-8 input call_dxcc 61,38 + + +This last example takes everything except UK and Eire from PI4EHV-8 +but only sends him my local configuration (just a PC19 for GB7DJK and +PC16s for my local users). + +

+It is possible to write much more complex rules, there are up +to 10 accept/reject pairs per callsign per filter. For more information +see the next section. + + +General filter rules + +

+Upto v1.44 it was not possible for the user to set their own filters. From +v1.45 though that has all changed. It is now possible to set filters for just +about anything you wish. If you have just updated from an older version of +DXSpider you will need to update your new filters. You do not need to do +anything with your old filters, they will be renamed as you update. + +

+There are 3 basic commands involved in setting and manipulating filters. These +are accept, reject and clear. First we will look +generally at filtering. There are a number of things you can filter in the +DXSpider system. They all use the same general mechanism. + +

+In general terms you can create a "reject" or an "accept" filter which can have +up to 10 lines in it. You do this using, for example ... + + +accept/spots ..... +reject/spots ..... + + +where ..... are the specific commands for that type of filter. There are filters +for spots, wwv, announce, wcy and (for sysops) connects. See each different +accept or reject command reference for more details. + +There is also a command to clear out one or more lines in a filter. They are ... + + +clear/spots 1 +clear/spots all + + +There is clear/xxxx command for each type of filter. + +

+and you can check that your filters have worked by the command ... + + +show/filter + + +

+For now we are going to use spots for the examples, but you can apply the same +principles to all types of filter. + +Types of filter + +

+There are two main types of filter, accept or reject. You +can use either to achieve the result you want dependent on your own preference +and which is more simple to do. It is pointless writing 8 lines of reject +filters when 1 accept filter would do the same thing! Each filter has 10 +lines (of any length) which are tried in order. If a line matches then the +action you have specified is taken (ie reject means ignore it and accept +means take it) + +

+If you specify reject filters, then any lines that arrive that match the filter +will be dumped but all else will be accepted. If you use an accept filter, +then ONLY the lines in the filter will be accepted and all else will be dumped. +For example if you have a single line accept filter ... + + +accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16) + + +then you will ONLY get VHF spots from or to CQ zones +14, 15 and 16. + +

+If you set a reject filter like this ... + + +reject/spots on hf/cw + + +Then you will get everything EXCEPT HF CW spots. You could make this +single filter even more flexible. For example, if you are interested in IOTA +and will work it even on CW even though normally you are not interested in +CW, then you could say ... + + +reject/spots on hf/cw and not info iota + + +But in that case you might only be interested in iota and say:- + + +accept/spots not on hf/cw or info iota + + +which achieves exactly the same thing. You should choose one or the other +until you are comfortable with the way it works. You can mix them if you +wish (actually you can have an accept AND a reject on the same line) but +don't attempt this until you are sure you know what you are doing! + +

+You can arrange your filter lines into logical units, either for your own +understanding or simply convenience. Here is an example ... + + +reject/spots 1 on hf/cw +reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16) + + +What this does is to ignore all HF CW spots and also rejects any spots on VHF +which don't either originate or spot someone in Europe. + +

+This is an example where you would use a line number (1 and 2 in this case), if +you leave the digit out, the system assumes '1'. Digits '0'-'9' are available. +This make it easier to see just what filters you have set. It also makes it +more simple to remove individual filters, during a contest for example. + +

+You will notice in the above example that the second line has brackets. Look +at the line logically. You can see there are 2 separate sections to it. We +are saying reject spots that are VHF or above APART from those in +zones 14, 15 and 16 (either spotted there or originated there). If you did +not have the brackets to separate the 2 sections, then Spider would read it +logically from the front and see a different expression entirely ... + + +(on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16 + + +The simple way to remember this is, if you use OR - use brackets. Whilst we are +here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'. + +As mentioned earlier, setting several filters can be more flexible than +simply setting one complex one. Doing it in this way means that if you want +to alter your filter you can just redefine or remove one or more lines of it or +one line. For example ... + + +reject/spots 1 on hf/ssb + + +would redefine our earlier example, or + + +clear/spots 1 + + +To remove all the filter lines in the spot filter ... + + +clear/spots all + + +Filter options + +

+You can filter in several different ways. The options are listed in the +various helpfiles for accept, reject and filter. + +Default filters + +

+Sometimes all that is needed is a general rule for node connects. This can +be done with a node_default filter. This rule will always be followed, even +if the link is isolated, unless another filter is set specifically. Default +rules can be set for nodes and users. They can be set for spots, announces, +WWV and WCY. They can also be used for hops. An example might look like +this ... + + +accept/spot node_default by_zone 14,15,16,20,33 +set/hops node_default spot 50 + + +This filter is for spots only, you could set others for announce, WWV and WCY. +This filter would work for ALL nodes unless a specific filter is written to +override it for a particular node. You can also set a user_default should +you require. It is important to note that default filters should be +considered to be "connected". By this I mean that should you override the +default filter for spots, you need to add a rule for the hops for spots also. + +Advanced filtering + +

+Once you are happy with the results you get, you may like to experiment. + +

+The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU +can be written with a mixed filter, for example ... + + +rej/spot on hf/cw +acc/spot on 0/30000 +acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16) + + +Note that the first filter has not been specified with a number. This will +automatically be assumed to be number 1. In this case, we have said reject all +HF spots in the CW section of the bands but accept all others at HF. Also +accept anything in VHF and above spotted in or by operators in the zones +14, 15 and 16. Each filter slot actually has a 'reject' slot and +an 'accept' slot. The reject slot is executed BEFORE the accept slot. + +

+It was mentioned earlier that after a reject test that doesn't match, the default +for following tests is 'accept', the reverse is true for 'accept'. In the example +what happens is that the reject is executed first, any non hf/cw spot is passed +to the accept line, which lets through everything else on HF. The next filter line +lets through just VHF/UHF spots from EU. + +Basic hop control + +

+In /spider/data you will find a file called hop_table.pl. This is the file +that controls your hop count settings. It has a set of default hops on the +various PC frames and also a set for each node you want to alter the hops for. +You may be happy with the default settings of course, but this powerful tool +can help to protect and improve the network. The file will look something +like this ... + + +# +# hop table construction +# + +package DXProt; + +# default hopcount to use +$def_hopcount = 5; + +# some variable hop counts based on message type +%hopcount = +( + 11 => 10, + 16 => 10, + 17 => 10, + 19 => 10, + 21 => 10, +); + + +# the per node hop control thingy + + +%nodehops = +( + GB7ADX => { 11 => 8, + 12 => 8, + 16 => 8, + 17 => 8, + 19 => 8, + 21 => 8, + }, + + GB7UDX => { 11 => 8, + 12 => 8, + 16 => 8, + 17 => 8, + 19 => 8, + 21 => 8, + }, + GB7BAA => { + 11 => 5, + 12 => 8, + 16 => 8, + 17 => 8, + 19 => 8, + 21 => 8, + }, +); + + +

+Each set of hops is contained within a pair of curly braces and contains a +series of PC frame types. PC11 for example is a DX spot. The figures here +are not exhaustive but should give you a good idea of how the file works. + +

+SHould any of the nodecalls include an ssid, it is important to wrap the +whole call in single quotes, like this ... + + + 'DB0FHF-15' => { + 11 => 5, + 12 => 8, + 16 => 8, + 17 => 8, + 19 => 8, + 21 => 8, + }, + + +If you do not do this, you will get errors and the file will not work as +expected. + +

+You can alter this file at any time, including whilst the cluster is running. +If you alter the file during runtime, the command load/hops will +bring your changes into effect. + +Hop Control on Specific Nodes + +

You can set a callsign specific hop count for any of the standard filter +options so:- + + +set/hops gb7djk spot 4 +set/hops node_default route 10 +set/hops gb7baa wcy 5 + + +all work on their specific area of the protocol. + +

+The set/hops command overrides any hops that you have set otherwise. + +

+You can show what hops have been set using the show/hops command. + +Isolating networks + +

+It is possible to isolate networks from each other on a "gateway" node using the + set/isolate <node_call> command. + +

+The effect of this is to partition an isolated network completely from another +node connected to your node. Your node will appear on and otherwise behave +normally on every network to which you are connected, but data from an isolated +network will not cross onto any other network or vice versa. However all the +spot, announce and WWV traffic and personal messages will still be handled +locally (because you are a real node on all connected networks), that is locally +connected users will appear on all networks and will be able to access and +receive information from all networks transparently. All routed messages will +be sent as normal, so if a user on one network knows that you are a gateway for +another network, he can still still send a talk/announce etc message via your +node and it will be routed across. + +

+If you use isolate on a node connection you will continue to receive +all information from the isolated partner, however you will not pass +any information back to the isolated node. There are times when you +would like to forward only spots across a link (maybe during a contest +for example). To do this, isolate the node in the normal way and use +an acc/spot >call< all filter to override the isolate. + +A DXSpider Filtering Tutorial + +

+There is now an excellent primer/tutorial on filtering written by Jim +Samuels, W3BG with an introduction by Dave Hawes N3RD that I strongly +suggest you read. You can read it here + + +Other filters + +Filtering Mail + +

+In the /spider/msg directory you will find a file called badmsg.pl.issue. Rename +this to badmsg.pl and edit the file. The original looks something like this .... + + + +# the list of regexes for messages that we won't store having +# received them (bear in mind that we must receive them fully before +# we can bin them) + + +# The format of each line is as follows + +# type source pattern +# P/B/F T/F/O/S regex + +# type: P - private, B - bulletin (msg), F - file (ak1a bull) +# source: T - to field, F - from field, O - origin, S - subject +# pattern: a perl regex on the field requested + +# Currently only type B and P msgs are affected by this code. +# +# The list is read from the top down, the first pattern that matches +# causes the action to be taken. + +# The pattern can be undef or 0 in which case it will always be selected +# for the action specified + + + +package DXMsg; + +@badmsg = ( +'B', 'T', 'SALE', +'B', 'T', 'WANTED', +'B', 'S', 'WANTED', +'B', 'S', 'SALE', +'B', 'S', 'WTB', +'B', 'S', 'WTS', +'B', 'T', 'FS', +); + + +

+I think this is fairly self explanatory. It is simply a list of subject +headers that we do not want to pass on to either the users of the cluster or +the other cluster nodes that we are linked to. This is usually because of +rules and regulations pertaining to items for sale etc in a particular country. + + +Filtering words from text fields in Announce, Talk and DX spots + +

+From version 1.48 onwards the interface to this has changed. You can now +use the commands set/badword to add words that you are not prepared +to see on the cluster, unset/badword to allow that word again and +show/badword to list the words that you have set. + +

+If you have a previous /spider/data/badwords, the first time you start +the node, it will read and convert this file to the new commands. The old style +file will then be removed. + +Stopping (possibly bad) DX Spots from Nodes or Spotters + +

+There are a number of commands that control whether a spot progresses +any further by regarding it as "bad" in some way. + +

+A DX Spot has a number of fields which can be checked to see whether they +contain "bad" values, they are: the DX callsign itself, the Spotter and +the Originating Node. + +

+There are a set of commands which allow the sysop to control whether a +spot continues:- + + +set/baddx +set/badspotter +set/badnode + + +These work in the same as the set/badword command, you can add +any words or callsigns or whatever to the appropriate database. For +example, to stop a spot from a particular node you do: + + +set/badnode gb7djk gb7dxc + + +a bad spotter: + + +set/badspotter b0mb p1rat nocall + + +and some bad dx: + + +set/baddx video wsjt + + +You can remove a word using the appropriate unset command +(unset/baddx, unset/badspotter, unset/badnode) or list them +using one of show/baddx, show/badspotter and +show/badnode. + +Mail + +

+DXSpider deals seamlessly with standard AK1A type mail. It supports both +personal and bulletin mail and the sysop has additional commands to ensure +that mail gets to where it is meant. DXSpider will send mail almost +immediately, assuming that the target is on line. However, only one +mail message is dealt with at any one time. If a mail message is already +being sent or recieved, then the new message will be queued until it has +finished. + +The cluster mail is automatically deleted after 30 days unless the sysop +sets the "keep" flag using the msg command. + +Personal mail + +

+Personal mail is sent using the sp command. This is actually the +default method of sending mail and so a simple s for send will do. +A full list of the send commands and options is in the command set +section, so I will not duplicate them here. + +Bulletin mail + +

+Bulletin mail is sent by using the sb command. This is one of the +most common mistakes users make when sending mail. They send a bulletin +mail with s or sp instead of sb and of course +the message never leaves the cluster. This can be rectified by the sysop +by using the msg command. + +

Bulletin addresses can be set using the Forward.pl file. + +Forward.pl + +

+DXSpider receives all and any mail sent to it without any alterations needed +in files. Because personal and bulletin mail are treated differently, there +is no need for a list of accepted bulletin addresses. It is necessary, however, +to tell the program which links accept which bulletins. For example, it is +pointless sending bulletins addresses to "UK" to any links other than UK +ones. The file that does this is called forward.pl and lives in /spider/msg. +At default, like other spider files it is named forward.pl.issue. Rename it +to forward.pl and edit the file to match your requirements. +The format is below ... + + +# +# this is an example message forwarding file for the system +# +# The format of each line is as follows +# +# type to/from/at pattern action destinations +# P/B/F T/F/A regex I/F [ call [, call ...] ] +# +# type: P - private, B - bulletin (msg), F - file (ak1a bull) +# to/from/at: T - to field, F - from field, A - home bbs, O - origin +# pattern: a perl regex on the field requested +# action: I - ignore, F - forward +# destinations: a reference to an array containing node callsigns +# +# if it is non-private and isn't in here then it won't get forwarded +# +# Currently only type B msgs are affected by this code. +# +# The list is read from the top down, the first pattern that matches +# causes the action to be taken. +# +# The pattern can be undef or 0 in which case it will always be selected +# for the action specified +# +# If the BBS list is undef or 0 and the action is 'F' (and it matches the +# pattern) then it will always be forwarded to every node that doesn't have +# it (I strongly recommend you don't use this unless you REALLY mean it, if +# you allow a new link with this on EVERY bull will be forwarded immediately +# on first connection) +# + +package DXMsg; + +@forward = ( +'B', 'T', 'LOCAL', 'F', [ qw(GB7MBC) ], +'B', 'T', 'ALL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], +'B', 'T', 'UK', 'F', [ qw(GB7BAA GB7ADX) ], +'B', 'T', 'QSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], +'B', 'T', 'QSLINF', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], +'B', 'T', 'DX', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], +'B', 'T', 'DXINFO', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], +'B', 'T', 'DXNEWS', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], +'B', 'T', 'DXQSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], +'B', 'T', 'SYSOP', 'F', [ qw(GB7BAA GB7ADX) ], +'B', 'T', '50MHZ', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ], +); + + +Simply insert a bulletin address and state in the brackets where you wish +that mail to go. For example, you can see here that mail sent to "UK" will +only be sent to the UK links and not to PA4AB-14. + +

+To force the cluster to reread the file use load/forward + +

+NB: If a user tries to send mail to a bulletin address that does not exist +in this file, they will get an error. + +The msg command + +

+The msg command is a very powerful and flexible tool for the +sysop. It allows the sysop to alter to and from fields and make other +changes to manage the cluster mail. + +Here is a full list of the various options ... + + + MSG TO - change TO callsign to + MSG FRom - change FROM callsign to + MSG PRrivate - set private flag + MSG NOPRrivate - unset private flag + MSG RR - set RR flag + MSG NORR - unset RR flag + MSG KEep - set the keep flag (message won't be deleted ever) + MSG NOKEep - unset the keep flag + MSG SUbject - change the subject to + MSG WAittime - remove any waiting time for this message + MSG NOREad - mark message as unread + MSG REad - mark message as read + MSG QUeue - queue any outstanding bulletins + MSG QUeue 1 - queue any outstanding private messages + + +These commands are simply typed from within the cluster as the sysop user. + +Message status + +

+You can check on a message from within the cluster by using the command +stat/msg. This will give you additional information on the +message number including which nodes have received it, which node it +was received from and when etc. Here is an example of the output of +the command ... + + +G0VGS de GB7MBC 28-Jan-2001 1308Z > +stat/msg 6869 + From: GB7DJK + Msg Time: 26-Jan-2001 1302Z + Msgno: 6869 + Origin: GB7DJK + Size: 8012 + Subject: AMSAT 2line KEPS 01025.AMSAT + To: UK +Got it Nodes: GB7BAA, GB7ADX + Private: 0 +Read Confirm: 0 + Times read: 0 +G0VGS de GB7MBC 28-Jan-2001 1308Z > + + +Filtering mail + +

+This is described in the section on Other filters so I will not +duplicate it here. + +Distribution lists + +

+Distribution lists are simply a list of users to send certain types of +mail to. An example of this is mail you only wish to send to other +sysops. In /spider/msg there is a directory called distro. You +put any distibution lists in here. For example, here is a file called +SYSOP.pl that caters for the UK sysops. + + +qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX + GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH + GB7DXK GB7DXI GB7DXS) + + +Any mail sent to "sysop" would only be sent to the callsigns in this list. + +BBS interface + +

+Spider provides a simple BBS interface. No input is required from the sysop +of the cluster at all. The BBS simply sets the cluster as a BBS and pushes +any required mail to the cluster. No mail can flow from Spider to the BBS, +the interface is one-way. + +

+Please be careful not to flood the cluster network with unnecessary mail. +Make sure you only send mail to the clusters that want it by using the +Forward.pl file very carefully. + +Scripts + +

+From 1.48 onwards it will become increasingly possible to control DXSpider's +operation with scripts of various kinds. + +

+The directory /spider/scripts is where it all happens and is used for several +things. Firstly it contains a file called startup that can be used to call +in any changes to the cluster from the default settings on startup. This +script is executed immediately after all initialisation of the node is done +but before any connections are possible. Examples of this include how many +spots it is possible to get with the sh/dx command, whether you want +registration/passwords to be permanently on etc. An example file is shown +below and is included in the distribution as startup.issue. + + +# +# startup script example +# +# set maximum no of spots allowed to 100 +# set/var $Spot::maxspots = 100 +# +# Set registration on +# set/var $main::reqreg = 1 +# +# Set passwords on +# set/var $main::passwdreq = 1 +# + + +

+As usual, any text behind a # is treated as a comment and not read. To use +this file, simply rename it from startup.issue to startup. In our example +above there are three options. The first option is the amount of spots that +a user can request with the sh/dx command. Normally the default is +to give 10 spots unless the user specifies more. Without this line enabled, +the maximum a user can request is 100 spots. Depending on your link quality +you may wish to enable more or less by specifying the number. + +

+The other 2 options are dealt with more fully in the security section. + +

+Secondly, it is used to store the login scripts for users and nodes. Currently +this can only be done by the sysop but it is envisaged that eventually users will +be able to set their own. An example is included in the distibution but here is +a further example. + + +# +# G0FYD +# +blank + +sh/wwv 3 +blank + +sh/dx +blank + +t g0jhc You abt? +blank + + + +The lines in between commands can simply insert a blank line or a character +such as a + sign to make the output easier to read. Simply create this script +with your favourite editor and save it with the callsign of the user as the +filename. Filenames should always be in lower case. + +

+Commands can be inserted in the same way for nodes. A node may wish a series +of commands to be issued on login, such as a merge command for example. + +

+Thirdly, there are 2 default scripts for users and nodes who do not have a +specifically defined script. These are user_default and +node_default + +Databases + +

+Spider allows the creation of local or remote databases. It supports +chained databases, allowing several different databases to be scanned +with one simple command. Importing of databases is limited at present +to the standard AK1A databases such as OBLAST and the DB0SDX QSL +database but will expand with time. + +Creating databases + +

+Creating a database could not be more simple. All the commands are +sent from the cluster prompt as the sysop user. + +To create a database you use the command dbcreate. It can +be used in 3 different ways like so .. + + +dbcreate + + +To simply create a database locally, you just tell the command the +name of the database. This does not create the actual database, it +simply defines it to say that it exists. + + +dbcreate chain [...] + + +This creates a chained database entry. The first database will be +scanned, then the second, the third etc... + + +dbcreate remote + + +This creates a remote entry. the first name field is the database +name at the remote node, then the remote switch, then the actual +node_call of the remote node, for example... + + +dbcreate buckmaster remote gb7dxc + + +Remote databases cannot be chained, however, the last database in a +chain can be a remote database. + +Importing databases + +

+The only databases that Spider can currently import are the standard +AK1A databases such as OBLAST or the DB0SDX qsl and address database. +This will be added to with time. + +To import such a database, first put the file somewhere useful like /tmp +and then issue the following command ... + + +dbimport oblast /tmp/OBLAST.FUL + + +This will update the existing local oblast database or create it if +it does not exist. + +Checking available databases + +

+Once a database is created, you will want to check that it has been +added. To do this use the dbavail command. This will +output the available databases. For example ... + + +dbavail +DB Name Location Chain +qsl Local +buck GB7ADX +hftest GB7DXM +G0VGS de GB7MBC 3-Feb-2001 1925Z > + + +Looking up databases + +

+To look for information in a defined database, simply use the dbshow +command, for example ... + + +dbshow buckmaster G0YLM + + +will show the information for the callsign G0YLM from the buckmaster +database if it exists. To make things more standard for the users +you can add an entry in the Aliases file so that it looks like a standard +show command like this ... + + +'^sh\w*/buc', 'dbshow buckmaster', 'dbshow', + + +Now you can simply use show/buckmaster or an abreviation. + +Removing databases + +

+To delete an existing database you use the dbremove command. +For example ... + + +dbremove oblast + + +would remove the oblast database and its associated datafile from the +system. There are no warnings or recovery possible from this command. +If you remove a database it ceases to exist and would have to be created +from scratch if you still required it. + +Information, files and useful programs + +MOTD + +

+One of the more important things a cluster sysop needs to do is to get +information to his users. The simplest way to do this is to have a banner +that is sent to the user on login. This is know as a "message of the day" +or "motd". To set this up, simply create a file in /spider/data called motd +and edit it to say whatever you want. It is purely a text file and will be +sent automatically to anyone logging in to the cluster. + +MOTD_NOR + +

+This message of the day file lives in the same directory as the standard +motd file but is only sent to non-registered users. Once registered they +will receive the same message as any other user. + +Downtime message + +

+If for any reason the cluster is down, maybe for upgrade or maintenance but +the machine is still running, a message can be sent to the user advising them +of the fact. This message lives in the /spider/data directory and is called +"offline". Simply create the file and edit it to say whatever you wish. +This file will be sent to a user attempting to log into the cluster when +DXSpider is not actually running. + +Other text messages + +

+You can set other text messages to be read by the user if they input the file +name. This could be for news items or maybe information for new users. +To set this up, make a directory under /spider called packclus. +Under this directory you can create files called news or newuser +for example. In fact you can create files with any names you like. These can +be listed by the user with the command .... + + +show/files + + +They can be read by the user by typing the command .... + + +type news + + +If the file they want to read is called news. You could also set +an alias for this in the Alias file to allow them just to type news + +

+You can also store other information in this directory, either directly or +nested under directories. One use for this would be to store DX bulletins +such as the OPDX bulletins. These can be listed and read by the user. +To keep things tidy, make a directory under /spider/packclus called +bulletin. Now copy any OPDX or similar bulletins into it. These +can be listed by the user in the same way as above using the show/files +command with an extension for the bulletin directory you have just created, +like this .... + + +show/files bulletin + + +

+An example would look like this .... + + +sh/files +bulletin DIR 20-Dec-1999 1715Z news 1602 14-Dec-1999 1330Z + + +You can see that in the files area (basically the packclus directory) there is a +file called news and a directory called bulletin. You can +also see that dates they were created. In the case of the file news, +you can also see the time it was last modified, a good clue as to whether the +file has been updated since you last read it. To read the file called +news you would simply issue the command .... + + +type news + + +To look what is in the bulletin directory you issue the command .... + + +show/files bulletin +opdx390 21381 29-Nov-1999 1621Z opdx390.1 1670 29-Nov-1999 1621Z +opdx390.2 2193 29-Nov-1999 1621Z opdx391 25045 29-Nov-1999 1621Z +opdx392 35969 29-Nov-1999 1621Z opdx393 15023 29-Nov-1999 1621Z +opdx394 33429 29-Nov-1999 1621Z opdx394.1 3116 29-Nov-1999 1621Z +opdx395 24319 29-Nov-1999 1621Z opdx396 32647 29-Nov-1999 1621Z +opdx396.1 5537 29-Nov-1999 1621Z opdx396.2 6242 29-Nov-1999 1621Z +opdx397 18433 29-Nov-1999 1621Z opdx398 19961 29-Nov-1999 1621Z +opdx399 17719 29-Nov-1999 1621Z opdx400 19600 29-Nov-1999 1621Z +opdx401 27738 29-Nov-1999 1621Z opdx402 18698 29-Nov-1999 1621Z +opdx403 24994 29-Nov-1999 1621Z opdx404 15685 29-Nov-1999 1621Z +opdx405 13984 29-Nov-1999 1621Z opdx405.1 4166 29-Nov-1999 1621Z +opdx406 28934 29-Nov-1999 1621Z opdx407 24153 29-Nov-1999 1621Z +opdx408 15081 29-Nov-1999 1621Z opdx409 23234 29-Nov-1999 1621Z +Press Enter to continue, A to abort (16 lines) > + + +You can now read any file in this directory using the type command, like this .... + + +type bulletin/opdx391 +Ohio/Penn DX Bulletin No. 391 +The Ohio/Penn Dx PacketCluster +DX Bulletin No. 391 +BID: $OPDX.391 +January 11, 1999 +Editor Tedd Mirgliotta, KB8NW +Provided by BARF-80 BBS Cleveland, Ohio +Online at 440-237-8208 28.8k-1200 Baud 8/N/1 (New Area Code!) +Thanks to the Northern Ohio Amateur Radio Society, Northern Ohio DX +Association, Ohio/Penn PacketCluster Network, K1XN & Golist, WB2RAJ/WB2YQH +& The 59(9) DXReport, W3UR & The Daily DX, K3TEJ, KN4UG, W4DC, NC6J, N6HR, +Press Enter to continue, A to abort (508 lines) > + + +The page length will of course depend on what you have it set to! + +The Aliases file + +

+You will find a file in /spider/cmd/ called Aliases. This is the file that +controls what a user gets when issuing a command. It is also possible to +create your own aliases for databases and files you create locally. + +

+You should not alter the original file in /spider/cmd/ but create a new file +with the same name in /spider/local_cmd. This means that any new Aliases files +that is downloaded will not overwrite your self created Aliases and also that +you do not override any new Aliases with your copy in /spider/local_cmd/. You +must remember that any files you store in /spider/local/ or /spider/local_cmd +override the originals if the same lines are used in both files. + +

+The best way of dealing with all this then is to only put your own locally +created Aliases in the copy in /spider/local_cmd. The example below is +currently in use at GB7MBC. + + + +# +# Local Aliases File +# + +package CmdAlias; + +%alias = ( + 'n' => [ + '^news$', 'type news', 'type', + ], + 's' => [ + '^sh\w*/buck$', 'show/qrz', 'show', + '^sh\w*/hftest$', 'dbshow hftest', 'dbshow', + '^sh\w*/qsl$', 'dbshow qsl', 'dbshow', + '^sh\w*/vhf$', 'dbshow vhf', 'dbshow', + '^sh\w*/vhftest$', 'dbshow vhftest', 'dbshow', + ], +) + + + +

+Each alphabetical section should be preceded by the initial letter and the section +should be wrapped in square brackets as you can see. The syntax is straightforward. +The first section on each line is the new command that will be allowed once the +alias is included. The second section is the command it is replacing and the last +section is the actual command that is being used. + +

+The eagle-eyed amongst you will have noticed that in the first section, the new +alias command has a '^' at the start and a '$' at the end. Basically these force +a perfect match on the alias. The '^' says match the beginning exactly and the +'$' says match the end exactly. This prevents unwanted and unintentional matches +with similar commands. + +

+I have 3 different types of alias in this file. At the top is an alias for 'news'. +This is a file I have created in the /spider/packclus/ directory where I can inform +users of new developments or points of interest. In it's initial form a user would +have to use the command type news. The alias allows them to simply type +news to get the info. Second is an alias for the show/qrz +command so that those users used to the original show/buck command in +AK1A will not get an error, and the rest of the lines are for locally created +databases so that a user can type show/hftest instead of having to use +the command dbshow hftest which is not as intuitive. + +

+This file is just an example and you should edit it to your own requirements. +Once created, simply issue the command load/alias at the cluster +prompt as the sysop user and the aliases should be available. + + +Console.pl + +

+In later versions of Spider a simple console program is provided for the sysop. +This has a type ahead buffer with line editing facilities and colour for spots, +announces etc. To use this program, simply use console.pl instead of client. + +

+To edit the colours, copy /spider/perl/Console.pl to /spider/local and edit the +file with your favourite editor. + +Updating kepler data + +

+Spider has a powerful and flexible show/satellite command. In order for +this to be accurate, the kepler data has to be updated regularly. In +general, this data is available as an email or via cluster mail. +Updating it is simple. First you need to export the mail message as a +file. You do this with the export command from the cluster prompt +as the sysop. For example ... + + +export 5467 /spider/perl/keps.in + + +

+would export message number 5467 as a file called keps.in in the +/spider/perl directory. + +

+Now login to a VT as sysop and cd /spider/perl. There is a command in +the perl directory called convkeps.pl. All we need to do now is +convert the file like so ... + + +./convkeps.pl keps.in + + +

+Now go back to the cluster and issue the command ... + + +load/keps + + +

+That is it! the kepler data has been updated. + +The QRZ callbook + +

+The command sh/qrz will only work once you have followed a few +simple steps. First you need to get a user ID and password from qrz.com. +Simply go to the site and create one. Secondly you need to copy the file +/spider/perl/Internet.pm to /spider/local and alter it to match your user +ID and password. You also at this point need to set $allow=1 to complete +the setup. Many thanks to Fred Lloyd, the proprieter of + for allowing this access. + +Connecting logging programs + +

+There appear to be very few logging programs out there that support telnet +especially the popular ones like LogEQF, Turbolog etc. This can make it +difficult to connect to your own cluster! +The way to do it is to make the logging program think it has a TNC attached +to a com port on the logging PC and 'push' a linux login out to it. +This is achieved very simply by the use of agetty. + +

+All that is required is to add a line in /etc/inittab to have the client +ready for a connection on the com port of your choice. Remember that in +Linux, the com ports start at ttyS0 for com1, ttyS1 for com2 etc. + + +c4:2345:respawn:/sbin/agetty -L 9600 ttyS1 + + +

+Add this after the standard runlevel lines in /etc/inittab. The above +line works on ttyS1 (com2). Now as root, issue the command telinit q +and it should be ready for connection. All that is required is a 3 wire +serial lead (tx, rx and signal ground). Tell you logging program to use +8n1 at 9600 baud and you should see a Linux login prompt. Login as normal +and then telnet from there to the cluster. + +Java Web applet + +

+In the spider tree will be a directory spider-web. This is a +neat little java web applet that can be run from a website. The applet +must run on the same machine as the cluster. The included README file is +shown below. + +

+I should comment here that the applet is precompiled, that is, ready to go. +It was compiled using JDK1.3.1. If your version is earlier than this then it +may not work. Should that be the case you need to recompile or update your +JDK. To recompile do the following ... + + +cd /spider/spider-web +rm *.class +/usr/bin/javac spiderclient.java + + +

+I have used /usr/bin/javac as an example, your path to javac may be different. + + +Spider-WEB v0.6b + +Completely based on a clx web client written in Java by dl6dbh +(ftp://clx.muc.de/pub/clx/clx-java_10130001.tgz) + +The webserver has to run on the same machine as your DxSpider software! + +It is assumed that you have Java installed. You need JDK1.3.1 at least. + +Installation instructions (Performed as root): + +Put all the files in the spider-web directory into a newly created directory +under the DocumentRoot of your websever for instance 'client'. In my case +this is: /home/httpd/html/client/ although ymmv. For Suse the correct +path should be /usr/local/httpd/htdocs/client/ for example. + +Move spider.cgi to the cgi-bin directory of your webserver, in my case that is +/home/httpd/cgi-bin/ although ymmv. For Suse the correct path should be +/usr/local/httpd/cgi-bin/ for example. + +Change the permissions of the files to ensure they are correct, obviously you +will need to use the correct path the the files according to your system: + +chmod 755 /home/httpd/html/cgi-bin/spider.cgi +chmod -R 755 /home/httpd/html/client/ + +By default the spider.cgi script should pick up your hostname (As long as this +is set correctly). If it does not or your hostname differs from the name that +you attach to the public address that you are using, then edit spider.cgi : + +# Uncomment and set the hostname manually here if the above fails. +# $HOSTNAME = "gb7mbc.spoo.org" ; +$PORT = "8000" ; + +'HOSTNAME' is the hostname of your cluster. + +'PORT' is the portnumber that you use to connect to your DxSpider via +telnet (see Listeners.pm) + +NOTE: If you can start the console but cannot connect to the cluster from it, +then it is possible that the machine you are on cannot resolve the hostname of +your cluster machine. If this is the case, you need to set your hostname +manually as above. + +You also need to set the $NODECALL variable. This prints the name of your +choosing (probably your cluster callsign) on the html page. + +You now can connect to Spider-Web via http://yourserver/cgi-bin/spider.cgi + + +Web based statistics + +

+From version 1.50, you can use the freeware software MRTG to produce +really nice graphical statistics on your web site. For an example +try . + +

+The following should help you get it all working. + +

+First you need to download the latest version of MRTG from . +You will also need the following files.. + + +libpng-1.0.14.tar.gz +zlib-1.1.4.tar.gz +gd-1.8.3.tar.gz + + +Login to your machine as the root user, put all the downloaded files +in /usr/local/src/ (or wherever you prefer) and untar and compile them. +All the information to compile and install these sources come with them. +After compilation and installation, you will find MRTG in /usr/local/mrtg-2. + +

+Now copy all the files in /usr/local/src/mrtg-2.9.22/images/ to +/spider/html/mrtg/ + +

+You now need to make 2 symbolic links like below... + + +ln -s /usr/local/mrtg-2/bin/mrtg /usr/bin/mrtg +ln -s /usr/local/mrtg-2/lib/mrtg2 /usr/lib/mrtg2 + + +

+Now login to the cluster with your sysop callsign and run the command +"mrtg all". + +

Now you are nearly there! Login as the sysop user and change to the +/spider/html/mrtg/ directory. Now run the command indexmaker as +shown below... + + +indexmaker --output stats.html --columns=1 --title "MRTG statistics for GB7DJK" ../../mrtg/mrtg.cfg + + +Changing the callsign for your own cluster callsign of course! + +

+And finally you need to login as the root user and create one last +symbolic link. Where this points will depend on where your html +documents are kept. For RedHat systems you use... + + +ln -s /home/sysop/spider/html/mrtg /home/httpd/html/mrtg + + +and for SuSE systems... + + +ln -s /home/sysop/spider/html/mrtg /usr/local/httpd/htdocs/mrtg + + +If you now point your browser to your website as below it should all +be happening! + + +http://www.xxx.xxx/mrtg/stats.html + + +Of course, to get the stats to update, you need to add some information +in the spider crontab file as below... + + +# Update stats for mrtg on website +00,05,10,15,20,25,30,35,40,45,50,55 * * * * run_cmd('mrtg all') + + +This will update the site every 5 minutes. + +Security + +

+From version 1.49 DXSpider has some additional security features. These +are not by any means meant to be exhaustive, however they do afford some +security against piracy. These two new features can be used independently +of each other or in concert to tighten the security. + +Registration + +

+The basic principle of registration is simple. If a user is not registered +by the sysop, then they have read-only access to the cluster. The only +thing they can actually send is a talk or a message to the sysop. In +order for them to be able to spot, send announces or talks etc the sysop +must register them with the set/register command, like this ... + + +set/register g0vgs + + +The user g0vgs can now fully use the cluster. In order to enable +registration, you can issue the command ... + + +set/var $main::reqreg = 1 + + +Any users that are not registered will now see the motd_nor file rather +than the motd file as discussed in the Information, files and useful +programs section. + +

+Entering this line at the prompt will only last for the time the cluster +is running of course and would not be present on a restart. To make the +change permanent, add the above line to /spider/scripts/startup. To +read more on the startup file, see the section on Information, files +and useful programs. + +

+To unregister a user use unset/register and to show the list +of registered users, use the command show/register. + +Passwords + +

+At the moment, passwords only affect users who login to a DXSpider +cluster node via telnet. If a user requires a password, they can +either set it themselves or have the sysop enter it for them by using +the set/password command. Any users who already have passwords, +such as remote sysops, will be asked for their passwords automatically +by the cluster. Using passwords in this way means that the user has a +choice on whether to have a password or not. To force the use of +passwords at login, issue the command ... + + +set/var $main::passwdreq = 1 + + +at the cluster prompt. This can also be added to the /spider/scripts/startup +file as above to make the change permanent. + +

+Of course, if you do this you will have to assign a password for each of +your users. If you were asking them to register, it is anticipated that +you would ask them to send you a message both to ask to be registered and +to give you the password they wish to use. + +

+Should a user forget their password, it can be reset by the sysop by +first removing the existing password and then setting a new one like so ... + + +unset/password g0vgs +set/password g0vgs new_password + + +CVS + +CVS from a Linux platform + +

+CVS stands for "Concurrent Versions System" and the CVS for DXSpider is held +at . This means +that it is possible to update your DXSpider installation to the latest +sources by using a few simple commands. A graphical interface to CVS for +Windows is explained in the next section. + +

+Please be aware that if you update your system using CVS, it is possible that +you could be running code that is very beta and not fully tested. There is +a possibility that it could be unstable. + +

+I am of course assuming that you have a machine with both DXSpider and +Internet access running. + +

+BEFORE YOU EVEN CONSIDER STARTING WITH THIS MAKE A BACKUP OF YOUR +ENTIRE SPIDER TREE!! + +

+Assuming you are connected to the Internet, you need to login to the +CVS repository and then update your Spider source. There are several +steps which are listed below ... + +

+First login as the user sysop. Next you need to connect to the CVS +repository. You do this with the command below ... + + +cvs -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login + + +You will get a password prompt. Simply hit return here and your machine should +return to a normal linux prompt. + +

+What happens next depends on whether you have an existing installation that +you want to update with the latest and greatest or whether you just want +to see what is there and/or run it on a new machine for testing. + +If you are installing Spider from CVS then change directory to /home/sysop + +If you are wanting to update Spider then cd to /tmp + +

+The next step will create a brand new 'spider' directory in your current +directory. + + +cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/dxspider co spider + + +This command is all on one line. + +

+Hopefully your screen should show you downloading files. The -z3 simply compresses +the download to improve speed. +When this has finished, you will have exactly the same as if you had untarred a full +tarball PLUS some extra directories and files that CVS needs to do the magic that +it does. + +

+Now if you are doing a new installation, that's it. Carry on as if you have +just downloaded and untarred the lastest tarball. + +

+If you want to upgrade your current installation then do this ... + + +tar cvfz /tmp/s.tgz spider +cd / +tar xvfzp /tmp/s.tgz + + +This is assuming you downloaded to the /tmp directory of course. + +

+NOTE: the 'p' on the end of the 'xvfz' is IMPORTANT! It keeps the permissions +correct. YOU WERE LOGGED IN AS THE USER SYSOP WEREN'T YOU????? + +Remember to recompile the C client (cd /spider/src; make) + +

+At this point the files have been upgraded. You can (usually) restart the cluster +in your own time. However, if you attempt to use any new commands or features +expect it to be fatal! At least your cluster will have been restarted then so it +will be too late to worry about it! + +

+Now the magic part! From now on when you want to update, simply connect to the +Internet and then, as the user sysop ... + + +cd /spider +cvs -z3 update -d + + +and your files will be updated. As above, remember to recompile the "C" client +if it has been updated (CVS will tell you) and restart if any of the perl scripts +have been altered or added, again, CVS will tell you. + +

+You will find any changes documented in the /spider/Changes file. + +CVS from a Windows platform + +

+After the initial setup, an update to your DXSpider software is no more than a couple +of clicks away. This section is intended to explain and illustrate the use of the +WinCVS application to update your DXSpider software. The current stable version of +WinCVS is Ver. 1.2. You can get this software at: + + + +Pick your download mirror and then install WinCVS after the download is complete. + +In this next section I have included a series of links to .jpg files to take advantage of the +picture and 1000 words equivalency. The .jpg files are in the C:\spider\html directory. If +someone using a Linux system is reading this section from boredom, the files are in +/home/sysop/spider/html. One aside, a Linux user can also get a copy of gcvs and do your updates +graphically as opposed to from the command line. The following descriptions are almost identical +between WinCvs and gcvs. The following screen shots have duplicate links, depending upon whether +you are viewing this information under the Windows or Linux operating system. + +When WinCVS is installed, running, and you are connected to the internet, the initial screen looks like: + + + +If you want, you can also look at these .jpg files with another viewer that might provide some +better clarity to the image. On the left is the directory tree for your hard disk. Notice that +the spider directory has a gray highlight. + +To start configuring WinCVS, click on Admin at the top of the screen and then Preferences. This +should get you: + + + +In the top line for CVSROOT, enter: + +anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login + + +and select + +"passwd" file on the cvs server + + +for Authentication on the General tab. + +Next, move to the right to the Ports tab. + + + +In here, check the box on the second line down for the "pserver" port. Enter a port number of 2401. + +Finally, go to the WinCvs tab all the way to the right. + + + +Enter Notepad as the viewer to open files. For the HOME folder, put "C:\spider" and click OK +because the configuration is now complete. + +You are now ready to upgrade your copy of DXSpider. Click on the greyed Spider folder +shown in the directory tree on the left of the WinCVS display. Two things should happen. The Spider +folder will be selected and the greyed-out arrow located just below the word Query in the top line will +turn to solid green. + +For anyone using gcvs under Linux, the green arrow is located on the extreme left of the display, +under the word File. A gcvs screen looks like: + + + +Click on the now green arrow to start the download process. An Update Settings box will be displayed +to which you can simply say OK. + + + +For future reference, the Update Settings box is the place where you can enter information to revert +to a prior version of DXSpider. Information on reverting to a Before Date is contained in the WinCVS +manual. + +After a short period of time, a series of file names will scroll by in the lower pane of the WinCVS +window. Eventually you should see + +*****CVS exited normally with code 0***** + + +appear in the lower pane. You're done. The updated files are in place ready for you to stop and then +restart your DXSpider. After the restart, you're running with the latest version of DXSpider. + + + +To paraphrase from the CVS section... Now the magic part! From now on when you want to update, simply +connect to the Internet and start WinCVS. + +Click on the greyed-out Spider directory in the left screen +Click on the green down arrow +Click OK on the Update Settings dialog box +Restart your Spider software + + +The DXSpider Command Reference +