X-Git-Url: http://scm.dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;ds=sidebyside;f=html%2Fadminmanual-3.html;h=d9f1170268dd823af303d19e58357faf59b39fa4;hb=dba22e4ea40bf62f79365833edbfcc38d6cf8847;hp=c107446e525e4b95932447ef6859ebf4fba57f45;hpb=09f90105aa04bc675d50b42fa59013a8291696b0;p=spider.git diff --git a/html/adminmanual-3.html b/html/adminmanual-3.html index c107446e..d9f11702 100644 --- a/html/adminmanual-3.html +++ b/html/adminmanual-3.html @@ -2,344 +2,209 @@
-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. +
+
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 ... +
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.
-
-
-default * * * * * * - sysop /spider/src/client client %u ax25
-
-
--
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 .... -
-
-
-spdlogin 8000/tcp # spider anonymous login port
-
-
-Then add a line in /etc/inetd.conf like this .... -
-
-
-spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
-
-
--
This needs to be added above the standard services such as ftp, telnet etc. -Once this is done, you need to restart inetd like this .... -
-
-
-killall -HUP inetd
-
-
--
-
Now login as sysop and cd spider/perl. You can test that spider -is accepting telnet logins by issuing the following command .... -
-
-
-client.pl login telnet
-
-
-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. -
-
Assuming all is well, then try a telnet from your linux console .... -
-
-
-telnet localhost 8000
-
-
--
You should now get the login prompt and be able to login as before. -
-
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. -
-
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 ... -
-
-
-set/node (AK1A type)
-set/spider
-set/dxnet
-set/clx
-
-
--
For now, we will assume that the cluster we are going to connect to is an -AK1A type node. -
-
Start up the cluster as you did before and login as the sysop with client.pl. -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 ... -
-
-
-set/node gb7baa
-
-
+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.
-
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. +
Bulletin addresses can be set using the Forward.pl file.
-
That is now set, it is as simple as that. To prove it, login on yet another -console as sysop and issue the command ... -
-
-
-client.pl gb7baa (using the callsign you set as a node)
-
-
--
You should get an initialisation string from DXSpider like this ... -
-
-
-client.pl gb7baa
-PC38^GB7MBC^~
-
-
-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. -
-
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. -
-
The connect scripts consist of lines which start with the following keywords -or symbols:- -
-
- -# All lines starting with a # are ignored, as are completely - blank lines. - -timeout timeout 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. - -abort abort 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. +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) +# -connect connect followed by ax25 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! +package DXMsg; -' ' 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. - -client client 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]). ---
There are many possible ways to configure the script but here are two examples, -one for a NETRom/AX25 connect and one for tcp/ip. -
-
+-
-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 +@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
-
--
-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 ---
Both these examples assume that everything is set up properly at the other end. -You will find other examples in the /spider/examples directory. -
-
3.5 Starting the connection +
3.4 The msg command
-You start the connection, from within a sysop enabled cluster login, by typing -in the word connect followed by a script name like this .... -
-
--
-G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1 -connection to GB7DJK-1 started -G0VGS de GB7MBC 13-Dec-1998 2043Z > --This will start a connection using the script called gb7djk-1. You can -follow the connection by watching the term or console from where you started -cluster.pl. You should see something like this ... -
-
--
-<- 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 ---
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 -before 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 ... +
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 ...
+
-'connect' '' + 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 messagesThese commands are simply typed from within the cluster as the sysop user.
-
In a script, this might look like ... +
3.5 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 ...
-timeout 35 -abort (Busy|Sorry|Fail) -connect telnet mary 3000 -'ogin:' 'gb7mbc' -'>' 'telnet 44.131.93.96 7305' -'connect' '' +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 >-
3.6 Telnet echo +
3.6 Filtering mail
-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. -
-
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 8000, this negotiation does -not happen and therefore no echo should be present. +
This is described in the section on Other filters so I will not +duplicate it here.
-
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 ... +
3.7 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.
-
-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' '' +qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX + GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH + GB7DXK GB7DXI GB7DXS)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. +
Any mail sent to "sysop" would only be sent to the callsigns in this list.
+
3.8 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.
Next