home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Elysian Archive
/
AmigaElysianArchive.iso
/
comm
/
wizfix.lha
/
WiZFix.doc
< prev
Wrap
Text File
|
1993-07-05
|
41KB
|
1,019 lines
Page 1 WiZFix's Fantastic Manual Page 1
WiZFix
A TrapToss specific AreaManager
Version 1.00
Copyright (c) 1993
Andy Wilson
All rights reserved
This manual is intended to be read from
front to back but you already knew that.
Page 2 WiZFix's Fantastic Manual Page 2
1. Introduction
This manual describes the function, installation,
configuration and operation of WiZFix, a new mail topology
management programme written specifically for TrapToss.
Please read the manual before installing WiZFix lest great
harm may fall upon your TrapToss configuration file.
2. Overview
WiZFix is a CLI based application only, which is why it comes
without a fancy icon. The final release of WiZFix will accept
a range of CLI arguments which will be designed to allow easy
configuration during runtime.
WiZFix is a utility which allows nodes and points connected
to your system and who communicate via messages processed by
TrapToss, to automatically link in or out of message areas
according to SysOp defined security and access barriers. The
main advantage of WiZFix is that changes in the topology of
calling node/points can be made without the SysOp having to
do anything.
WiZFix not only supports the global configuration file (GCF),
hereinafter referred to as 'Fido.Cfg', as supported by TrapToss
and TrapList (and perhaps one day TrapDoor?), it actually
requires it in order to function. This therefore does away with
the normal convention of having to re-enter your node, aka, mail
directories etc.. WiZFix will not work unless your TrapToss
and TrapList data are in the MAIL: assigned directory and stored
under the file name of Fido.Cfg. Please refer to the software
manuals for TrapToss and TrapList if you need to convert your
current configuration files.
Please note that no keywords are case sensitive, but some of
them are position dependant. Additionally, at this time WiZFix
does not fully support the strict GCF specifications in that all
configuration statements and parameters must be contained on a
single line (no continuing to the next line by adding a trailing
'\').
Finally, by the very nature of WiZFix, this programme not
only reads data from the normally private TrapToss and TrapList
sections of the GCF, it actually modifies the export lines of
the AREA statements within the TrapToss section.
Page 3 WiZFix's Fantastic Manual Page 3
3. Installation
In order to install WiZFix, you must have the following minimum
files as listed below:
WiZFix - executable file
WiZFix.doc - so you know what to do!
AF.cfg - example configuration file (SEE BELOW)
MAIL: - logical assignment to your mail base
MAIL:Fido.Cfg - GCF file as described by TrapToss et al.
Additional files will also most likely be required, such as:
AreaFix.hlp - Help file for your users
Hub.txt - List of your Hub's echoes
Host.txt - Formatted list of your echoes etc.
Copy the executable 'WiZFix' to a directory in your normal
path (MAIL:Bin/ is a good place, and is also the assumed
directory).
Edit your 'MAIL:Fido.Cfg' file and append (paste) the file
AF.Cfg (which file is included in the distribution archive).
Now save your updated MAIL:Fido.Cfg file.
Now you have just one change to make: if you are a node, you
must alter any/all of your AKA addresses that you have listed in
your Fido.Cfg so that they do NOT show a point. e.g. my address
is 2:255/171 and NOT 2:255/171.0 which is how some people
incorrectly write there address Ditto 39:136/1 and NOT
39:136/1.0
(I only make you do this (a) because I'm an annoying sort of
person, and (b) in the hope that others may learn as I myself
have..:-)
The installation is complete.
4. Configuration
WiZFix is designed to work in harmony with TrapToss, and to
try to take advantage of some of the features of TrapToss which
might not be considered by other inferior packages. WiZFix can
be configured using a series of keywords which are stored in the
private AreaFix section of the MAIL:Fido.Cfg file.
The WiZFix private section is preceeded with a '[AreaFix]'
statement, in the same way that the TrapToss section is defined
using a '[TrapToss]' keyword etc., refer to your TrapToss
manual for further information.
Please note that the keywords and/or there parameters are NOT
case sensitive, but that most of them look nicer when the
keyword is in upper case. It's your choice however.
Page 4 WiZFix's Fantastic Manual Page 4
Where possible, default values for the configuration keyword
parameters have been made for you (listed in parenthesis after
the keyword function description).
4.1 Configuration Keywords
4.1.1 LOGFILE
This is where WiZFix logs its activity - you can quickly tell
who has linked into/outof what area by reading the logfile.
Currently, the log file is flushed after each line entry, but
this may change in the future.
(Default - LOGS:AreaFix.Log)
4.1.2 USETRAPLISTPW
If this keyword is specified then WiZFix will use passwords
listed in the normally private TrapList section of the Fido.Cfg
area in order to security check incoming AreaFix requests.
Many nodes (inc. myself) use the same password for both mail
and AreaFix sessions. The use of this keyword enables you to do
the same without having to laboriously copy your Traplist listed
passwords into a seperate configuration file.
To disable this feature, simply do not use the keyword.
(Default - disabled)
4.1.3 PASSWORD
This keyword is used to define the password to be used for
security checking incoming AreaFix requests. The format of the
PASSWORD statement is as per the TrapList method. i.e.:-
PASSWORD "mypvtpw" 2:255/171 39:136/1 39:136/0 2:2424/0
The above would assign the password 'mypvtpw' to the nodes
2:255/171, 39:136/1, 39:136/0, and 2:2424/0. There is no limit
on the number of nodes which can be stored on the one line, but
there is a limit to the length of each line in the Fido.Cfg
configuration file (currently 2k per line max.).
Page 5 WiZFix's Fantastic Manual Page 5
4.1.4 ALLOWCREATE
Currently not implemented.
4.1.5 PREADCONFIG
Currently not implemented.
4.1.6 HELPFILE
This is the file sent to a calling node/point that's requested
an AreaFix session (using the '-h' switch - see later). This
file would usually contain instructions on how to use WiZFix,
and what to expect from it. You can edit this to suit your
needs.
4.1.7 ZONE
It is often useful to be able to send certain data only to
certain nodes. e.g. if you run a multi-network setup, and a
point/node requests a list of areas then you might not wish to
send a list of all areas available on your system in case they
include areas from a different network. Also, if you allow
requests to be FORWARDED (see later) then it may well be that
you wish to send an AreaFix message to one node for some mail
e.g. in 'fidonet', and another in say 'amiganet'.
WiZFix solves these difficulties by allowing you to send
certain files to calling nodes depending on their ZONE address,
and to forward AreaFix requests that can't be handled by your
system to the correct upstream node.
The configuration parameters are:-
ZONE HOSTLIST HUBLIST HUBADDRESS HUBPASSWORD
Where:
ZONE = calling sites ZONE address (e.g. '2' or '39')
HOSTLIST = text file that can be sent to the requestor.
(e.g. a formatted list of available areas
available from you?)
HUBLIST = text file e.g. of echoes available from your HUB.
(This file can be sent to a user if they request
an echo list using the '-f' flag. It's also
scanned for area TAGS to see if an AreaFix msg
can be forwarded to your hub (see below)
HUBADDRESS = full 4d address of your hub (e.g. 2:255/1)
HUBPASSWORD = YOUR AreaFix session password for your hub (used
for the forwarding of AreaFix requests).
Page 6 WiZFix's Fantastic Manual Page 6
e.g.:-
ZONE 2 MAIL:Fidonet.txt MAIL:HubFido.txt 2:255/1 MAGIC
ZONE 39 MAIL:Amiganet.txt MAIL:HubAmiga.txt 39:138/1 MORE_MAGIC
If a node with an address of 2:255/1234 (i.e. ZONE 2) calls
and requests a list of available areas using the '-f' keyword,
he will receive a standard AreaFix reply, plus a copy of the file
'MAIL:Fidonet.txt' and 'MAIL:HubFido.txt'.
Additionally, If a request to link into an area fails
because the area isn't listed, and you have allowed him to
forward requests (see (NO)ALLOWFORWARDING keyword descriptions)
then the file 'MAIL:HubFido.txt' will be searched in order to
find a matching TAG name. If the TAG name is found, then
an AreaFix message will be sent to 2:255/1 using the AREAFIX
password of 'MAGIC' together with a request for a link
into the area of interest. The area will then be created in
your Fido.Cfg ('passthrough' for you) and the requesting node
and Hub will be added to the export line.
If the TAG name cannot be found in the 'Mail:HubFido.txt' file
then the request is NOT forwarded (saves your hub receiving
loads of messages with incorrectly spelt TAG names!).
Similarly, a '-f' request from 39:123/456 would cause the lists
'MAIL:Amiganet.txt' and 'MAIL:HubAmiga.txt' to be sent, and
forwarded requests to be sent to 39:138/1 using the AreaFix
password 'MORE_MAGIC' (again, subject to a matching TAG name in
the file 'MAIL:Amiganet.txt').
Each ZONE statement MUST have 5 parameters otherwise WiZFix
will complain. Use the character '*' in place of the filenames
if you don't want to send any files (over and above the standard
reply) when a request for an ECHOLIST is received.
Please note that if you use the '*' char in place of the name
for the HUBLIST then AreaFix requests cannot be forwarded to that
hub.
The forwarding of AreaFix requests from nodes and/or points is
configurable (see below).
(Default - no ZONE statements)
4.1.8 (NO)ALLOWFORWARDINGPOINTS
Gosh, what a big keyword? Perhaps I should make it smaller..
This statement allows you to specify whether requests from
points can be forwarded to the appropriate hub in order to try
and obtain a message area that you currently do not carry.
(Default - NOALLOWFORWARDINGPOINTS)
Page 7 WiZFix's Fantastic Manual Page 7
4.1.9 (NO)ALLOWFORWARDINGNODES
The same thing as per (NO)ALLOWFORWARDINGPOINTS except that
this applies to nodes.
(Default - NOALLOWFORWARDINGNODES)
4.1.10 DEFAULTLEVEL
This is the first of several keywords which can be used to
control the security of your system by allowing certain
nodes/points to have increased or decreased access.
The DEFAULTLEVEL is the access level assigned to any node or
point which has a PASSWORD PROTECTED AreaFix session with your
system (this will become a little clearer after reading the
(NO)SECURE keyword descriptor).
It is recommended that this be given a reasonably high value,
say 100. Any number from 0 to (2^32-1) can be used.
(Default - 100)
4.1.11 LEVEL
This is the second access level keyword. You can use this to
increase or decrease the access level of specified nodes/points.
The keyword takes the form: 'LEVEL FQFA <level> [Q] (or [-])'
e.g.:
LEVEL 39:138/1 65535 [-] ;High level access for him.
LEVEL 2:255/171.33 500 [Q] ;Increased access for him.
LEVEL 2:255/171.172 005 [Q] ;Decreased for this twit.
LEVEL 2:123/456.789 000 [-] ;I don't like him - BANNED!
LEVEL 2:250/320 500 [Q] ;etc.
The '[Q]' or '[-]' allows you to send (not send) a QUERY list
of areas to which the node/point is attached by using the CLI
argument ECHOLIST.
Page 8 WiZFix's Fantastic Manual Page 8
The above assigns a high access level to 39:138/1 but will not
send him an echolist unless he requests one (using the '-l'
option on the subject line of an AreaFix msg - see Chapter 5).
Point 2:255/171.33 gets increased access, whilst the twit point
2:255/171.172 has his lowered; both will receive an echolist
when I want to send them one, as well as when they want one.
Note that it is possible to assign a different access level
for different AKA's of the same system. e.g. the UK Amiganet RC
(as of May 1993) has at least two addresses: 39:138/1 and also
2:253/404 (fidonet address). I can allow 39:138/1 increased
access on my system, while at the same time keeping the fidonet
address at a relatively low level:
LEVEL 39:138/1 65535 [-]
LEVEL 2:253/404 150 [Q]
i.e. only slightly increased access for 2:253/404, and he'll
receive an echolist (of fidonet areas only) when I want him to,
but his amiganet address is given high access, and he won't be
sent a list of amiganet areas unless he requests one.
4.1.12 ECHOLEVEL
This is the third keyword which, in conjunction with
DEFAULTLEVEL and LEVEL (see above) will enable you to restrict
who can link into what areas.
Per default, each AREA tag (in MAIL:Fido.Cfg) is assigned the
DEFAULTLEVEL. This means that any PASSWORD PROTECTED AreaFix
session with a user with the default access level will be able to
link into/out of this area without the need for any
configuration by you the SysOp.
Using the ECHOLEVEL keyword, you can do one of two things: (1)
increase the level of this AREA tag, which will mean that only
priviliged users with the requisite access (i.e. greater or
equal to the ECHOLEVEL) will be able to link in/out of the area;
(2) or you could DECREASE the level of this area and thus make
it available to not only password protected AreaFix users, but
to anyone and everyone (see the (NO)SECURE keyword description
for further explanation).
This is not as daft as it might sound: suppose you host an
echo which is not available on the backbone. If you wanted
anyone to link into, you'd normally have to setup session
passwords etc.. By decreasing the access level of an area, you
could make it available to ANYONE (or to ANYONE except certain
twit points or whatever) without the need for firing up your
text editor. Thus preventing you from receiving annoying
messages from nodes/points saying 'I tried to link in, but I
was refused access'.
Page 9 WiZFix's Fantastic Manual Page 9
Note that non-password protected sessions can ONLY link into
AREA tags which have a lower access than the DEFAULTLEVEL.
Also, you should note that you can still lock certain users out
of these areas, by assigning him/her an access level (using the
LEVEL keyword) lower still.
I would anticipate that most people will use the ECHOLEVEL
keyword to restrict access to certain echoes (say, SysOp only
ones), but I thought it might be a nice feature to add, so I
added it. :-)
Valid numbers are 0 - (2^32-1).
Here's a few example ECHOLEVEL statements:
ECHOLEVEL BAD 9999999 ; No one gets this.
ECHOLEVEL DICE 10 ; Anyone can have this.
ECHOLEVEL 255_SYSOP 65535 ; SysOps only
ECHOLEVEL SYSOP_AMY 65535 ; Ditto.
ECHOLEVEL ANDROMEDA 90 ; etc.
ECHOLEVEL R13HOST 65535 ; Not many get to see this..
ECHOLEVEL P-WARE_BETA 500 ; Get it yet? :-)
If you receive an AreaFix request from a non-password
protected node/point then they would be allowed to link into
only the DICE and ANDROMEDA echoes - the others would not even
be listed to them.
If you have a particularly annoying point/node that needs
additional sorting out, then you could assign him/her an access
level (using the LEVEL keyword) less than 90 (which would ban
him from the ANDROMEDA area) or less than 10 (which would ban
him completely).
Got it?
4.1.13 (NO)SECURE
Use this keyword if you wish to allow anyone to be able to
link into the areas with an access level of less than the
DEFAULTLEVEL. i.e. in the above list, they could link into the
areas DICE and ANDROMEDA (DICE is an area I host, and ANDROMEDA
is my point area, in case you're interested. :-)
Please use this and the above keyword with care. It is
unwise to allow 'unlnowns' to link into backboned areas, as they
may be unpleasant individuals who are intent on causing you
inconvenience (say by duping mail - even unintentionally). I
recommend that you only use the INSECURE keyword when you fully
understand what it does.
(default - SECURE)
Page 10 WiZFix's Fantastic Manual Page 10
4.1.14 RESCANLEVEL
Not yet implemented.
4.1.15 RESCANPROTECT
Not yet implemented.
4.1.16 SKYTICK <path>
WiZFix supports 'file echo' lists too (i.e. TICK file areas).
The above command tells WiZFix that you're using SKYTICK. The
path following the keyword tells WiZFix where it can find the
SkyTick configuration file (usually MAIL:Tick.Cfg).
WiZFix automatically links users in/out of the SkyTick Tick.Cfg
file, and generates 'echo lists' etc. exactly as for the
Fido.Cfg.
Requests for file echoes are dealt with AFTER requests for
message echoes, which complicates matters:
o A file echo having the same name as a message echo WILL confuse
WiZFix (all requests to add/drop the area will always cause
WiZFix to work on the message area, not the file area). Other
AreaFix programmes suffer the same problem..
o Additionally, any requests for message echoes which you do not
carry will result in WiZFix searching your 'Tick.Cfg' file
BEFORE it tries to forward a request for your hub. This will,
confusingly, mean that FILE ECHOES will be linked in/out of
instead of any requests being sent to your Hub if the FILE ECHO
TAG matches the message area TAG.
It is unlikely that this will ever be a problem, and in any
case the rest of the planet will be in a similarly sorry state as
it's impossible to know whether a request is for a FILE or
MESSAGE area
4.1.17 FTICK <path>
As for SKYTICK (see 4.1.16) but for Foozle's TICK configuration
file. The quirks that apply to SKYTICK as regards identical FILE
and MESSAGE TAG names applies equally to Foozle Tick's file.
Page 11 WiZFix's Fantastic Manual Page 11
5 Operation
WiZFix works by scanning the netmail base in order to find
messages addressed to 'AreaFix'. Only messages above TrapToss'
'high water mark' are scanned, and each message can be
processed only once. (i.e. I set the RECEIVED flag for each
processed message, which is therefore ignored on subsequent
scans).
In order to allow TrapToss to work, you must run TrapToss in
either IMPORT or preferably TOSS mode. Do not use the keywords
EXPORT or SCAN until after you've allowed WiZFix to process
mail. (This is because trapToss correctly updates the 'high
water mark' after a SCAN or EXPORT, which would fool WiZFix
into thinking that all AreaFix messages have been processed).
e.g. I run WiZFix as part of my incoming mail AFTERSESSION
script. Here's a simplified version of my current
aftersession, which is called by TrapDoor after every successful
incoming call.
;
; Import mail.
;Now unpack & process the mail.
TrapToss NOSCAN
;WiZFix
WiZFix
;Now export WiZFix replies (if any!)
If WARN
TrapToss SCAN MATRIXONLY
endif
...
Note that I run TrapToss in SCAN/TOSS mode (I don't use
IMPORT/EXPORT - neither should you if you're running a node
setup).
Also note the use of the 'IF WARN' statement - WiZFix returns a
return code of 5 (WARN) IF it's processed any messages (i.e.
there are replies to send out). If it has not created any
replies, then no 'WARN' code is returned. Simple, but jolly
useful if you want to prevent TrapToss from firing up needlessly.
If all goes well, that's all you need to do to install
WiZFix. The hard bit is up to your calling nodes/points (they
have to send 'AreaFix' messages). Full details of how WiZFix
works from your calling nodes/points viewpoint are given in the
file 'AreaFix.hlp' (which is the default file sent to every
node/point that uses the '-h' keyword on the subject line).
However, it might be useful to describe the main events that
occur here:-
Firstly, a node/point sends a message to your system addressed
to AreaFix. The subject line must contain their session
password (unless you use the NOSECURE keyword), followed
optionally by several switches: '-l -q -h -r -f -u' (in any
order; some, all or none can be used).
Page 12 WiZFix's Fantastic Manual Page 12
The '-q' switch will instruct WiZFix to send a reply message
that contains a list of AREAS to which that node/point is
connected. Note, only areas containing that nodes/points
address (and NOT any of his AKA's) will be listed.
The '-l' switch will instruct WiZFix to send a list of
available areas to that node/point. The list will contain the
AREA tag names only of areas to which that node/point (a) has
access to and (b) are in the same network as the calling
node/point (there is no valid reason to automatically send a
list of amiganet conferences to a fidonet node, and vice
versa). In addition to the automatically generated list,
WiZFix will also send a text file as specified in the ZONE
HOSTLIST statement. This can contain whatever you wish, but
would normally contain a list of available areas perhaps with
descriptions? You could of course also list areas available in
other networks too.
The '-f' switch has the same effect as '-l' but also sends
a copy of your Hub's echolist (if any). I decided to make this
a separate switch as a full backbone list (which is what I use
for my Hub) is rather large, and users would get peeved PDQ if
they got one of them every time they issued a '-l'.
A '-l' and '-f' will only cause one auto-list to be sent, so
there's no need for users to remember not to use '-l' when '-f'
is used.
The '-u' switch will cause a list of echoes to which the node
is NOT linked in to be sent.
The '-h' switch instructs WiZFix to send a copy of the
HELPFILE to the calling node (this would normally explain how
to the user how use 'AreaFix' remotely).
The '-r' switch instructs WiZFix to rescan the area(s)
listed in the message. Currently, this is not implemented in
the released version, and is likely to change anyhow.
The following '%' commands can be used in the message body text
in place of the '-x' commands (the first letter of each COMMAND
is also sufficient):
%LIST, %L - same as '-l'
%QUERY, %Q - same as '-q'
%UNLINKED, %U - same as '-u'
%HELP, %H - same as '-h'
%FULL, %F - same as '-f'
Having scanned the netmail base, WiZFix will process
messages as needed and create replies as appropriate. These
will be exported to the calling node/point the next time that
TrapToss SCANs or EXPORTs mail. Please note that normal
TrapToss routing commands are not affected. So reply messages
to points can be placed on hold etc. as per normal.
Page 13 WiZFix's Fantastic Manual Page 13
If the received messages have resulted in any changes to the
Fido.Cfg file (e.g. a node/point has linked in or out of an
area) then the entire Fido.Cfg file is updated to reflect the
changes. Ditto any changes to the 'Tick.Cfg' file (if
configured).
Topology changes, as well as access/password infringements are
recorded in the log file.
WiZFix has a few built-in aliases: you can call it 'AreaFix',
'FileFix' or 'Raid' (not case sensitive). More words will be
added soon - suggest some if you want!
6 CLI arguments
Pretty sparse right now, but that will change once I'm convinced
all the bugs are dead, and the functionality is acceptable.
6.1 ECHOLIST
This will disable the normal operation of WiZFix, and will cause a
list of message/file areas to which nodes listed in your Fido.Cfg
file ([AreaFix] section) are connected. Only nodes/points which are
defined with a LEVEL statement stand a chance of receiving an
echolist, and these must have the '[Q]' option in their definition
string. So, if the following were listed in the 'Fido.Cfg':-
; Some privileged/dork users - set their access accordingly:
LEVEL 2:253/404 65535 [-] ;Trustworthy
LEVEL 2:255/171.33 500 [Q] ;Increased access for this point.
LEVEL 2:255/171.172 005 [Q] ;Decreased for this twit point.
;
then only 2:255/171.33 and 2:255/171.172 would receive an echolist.
Node 2:253/404 would only receive an echolist if (s)he sent a
specific AreaFix request.
Please note that normal AreaFix messages are NOT processed if the
ECHOLIST CLI argument is used.
Other keywords are planned, but feel free to make suggestions..
7 Example configuration
Here is a drastically cut down version of my Fido.Cfg file,
showing how I operate WiZFix. Please feel free to browse
this and use it in any way that helps you install WiZFix.
Page 14 WiZFix's Fantastic Manual Page 14
;*******************************
;* Fido.Cfg config file 27-5-93
;* NODE set-up *
;*******************************
;
Node 2:255/171
AKA 39:136/1 39:136/0 39:2424/0 2:2424/0
DOMAIN amiganet 39:136/1 39:* 40:* 41:*
DOMAIN fidonet
Origin "Andromeda, Gwent 0873-858921"
NodeListPath "Nodelist:"
Inbound "Mail:Inbound"
Outbound "Mail:Outbound"
TimeZone "BST"
[TrapToss] ;The normally PRIVATE TrapToss section
UnAttended
;CopyMsg #?
POINTNET 2424
LogLevel 5
LogFile Logs:TrapToss.Log
IOBuffersize 16384
Buffersize 1024000
BOUNCE 1:* 2:* 3:* 4:* 5:* 6:* 39:* 40:* 41:*
ScreenMode TRAPDOOR
;etc. - plus all routing/packing commands.
;key areaname directory nodes who get it
;¯¯¯ ¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Netmail MAIL_DIR MAIL:Mail/netmail
Area BAD MAIL:Mail/Bad
Area AMIGA.EUR MAIL:Mail/AMIGA.EUR 255/171 255/1
Area AMIGA_COMP MAIL:Mail/AMIGA_COMP 255/171 255/1
Area ANDROMEDA MAIL:Mail/Andromeda 255/171 253/404
Area ANNOUNCE MAIL:Mail/ANNOUNCE 255/171 255/171.8
Area BUY MAIL:Mail/BUY 255/171 255/1
Area CLUB_AMIGA MAIL:Mail/CLUB_AMIGA 255/171 255/1
Area AUDIO_AMY MAIL:Mail/AUDIO_AMY 39:136/1 39:133/1
Area BLITZ_AMY MAIL:Mail/BLITZ_AMY 39:136/1 39:133/1
area COMMS_AMY MAIL:Mail/COMMS_AMY 39:136/1 39:133/1
Area EMOD_AMY MAIL:Mail/EMOD_AMY 39:136/1 39:133/1
;
;etc. - plus all other AREAS.
;
[TrapList] ;The normally PRIVATE TrapList section
gennewstyle
deloldlists
delolddiffs
checkcrc
report nodelist:Report.txt
comment SU
Zone 2 ; zone number
Output Verbose ; print additional information
Page 15 WiZFix's Fantastic Manual Page 15
BufferSize 262144
NodeList "NODELIST" Diff "NODEDIFF" ; The weekly nodediff
Nodelist "AMYLIST" Diff "AMYDIFF" ; AmigaNet
Password "Can you" 255/171 39:136/1 39:136/0
Password "Guess" 2:250/320 39:138/14
Password "What" 2:252/309
Password "These" 2:253/167
Password "are yet?" 2:253/419 39:135/1 39:135/0
;
Dial "-" "-" ; leave "-Unpublished-" as is
Dial "44-" "0" ; UK numbers.
Dial "" "010" ; USA.
;
Cost 61 "1-" ;North America
Cost 81 "61-" ;Australia
Cost 48 "43-" ;Austria
Cost 116 "973-" ;Bahrain
;etc, etc.
;
[WiZFix] ;The new WiZFix section.
;
LOGFILE LOGS:WiZFix.Log ;My logfile.
;
SKYTICK MAIL:Tick.Cfg ;My TICK file..
;
USETRAPLISTPW ;Use TrapList passwords.
;
password "hidden" 1:234/567 ;Some additional ones..
password "guess" 39:999/999.999
;
HELPFILE MAIL:WiZFix.hlp ;My WiZFix 'Help' file
;
; Now some ZONE statements, togther with more files that can be
;sent ('*' means send nothing).
ZONE 2 * Mail:HubFidonet.txt 2:255/1 MAGIC
ZONE 39 * * 39:138/1 MORE_MAGIC
;
ALLOWFORWARDINGPOINTS ;Points can forward requests.
;
NOALLOWFORWARDINGNODES ;But nodes CAN'T.
;
DEFAULTLEVEL 100 ;Standard security level.
;
; Some privileged/dork users - set their access accordingly:
LEVEL 2:253/404 65535 [-] ;Trustworthy
LEVEL 2:255/171.33 500 [Q] ;Increased access for him.
LEVEL 2:255/171.172 005 [Q] ;Decreased for this twit.
;
; Now change the access of restricted/public areas:
ECHOLEVEL BAD 100000 ; No one gets this.
ECHOLEVEL 255_SYSOP 65535 ; SysOps only
ECHOLEVEL SYSOP_AMY 65535 ; Ditto.
ECHOLEVEL ANNOUNCE 9 ; Low access needed.
ECHOLEVEL ANDROMEDA 10 ; etc.
ECHOLEVEL JOE_PUBLIC 1 ; Free for all! :-)
;
NOSECURE ; Anyone can use WiZFix here!
Page 16 WiZFix's Fantastic Manual Page 16
8 Future
Open to suggestions..
9 Registration
WiZFix is released under a new concept, which I genuinely
hope will catch on: I have christened this new concept
'ComplicatedWare'.
In a nutshell, this is FREE to all non-Shareware programmers,
but it's Shareware to all Shareware programmers! Here's the
details:
I have a general dislike for Shareware programmers. Some of
them are of course fair and honest individuals, but for the
most part they are take your money and give little in the way
of support, or they ask for money for even the most trivial of
programmes. This is my attempt to hit back:-
If you have released ANY shareware software then to you,
WiZFix is SHAREWARE. You are obliged to send me precisely
half of what you demand from everyone else. You are entitled
to use WiZFix for a period of one week, after which you must
either register or delete the software from your system.
If you have not released any shareware software, nor required
payment for any programme distributed either electronically or
via PD libraries etc. then to you, WiZFix is *FREE*, You may
use it or not use it for as long as you want and you are not
obliged to send me anything. However, I would like to mention
that I have a minor hobby, which is the collection of postcards
from around the world: if you by chance have a spare postcard
depicting your home town and/or country then I would very much
like to receive it. :-)
SHAREWARE donations (i.e. from other SHAREWARE programmers),
and any postcards from the other decent folk on this planet
should be sent to:
Andrew Wilson
47 Plas Derwen View
Abergavenny
Gwent
NP7 9SX
UK
I genuinely hope that other programmers will become encouraged
to adopt the same attitude that I have: it's about time that
Amiga programmers started to follow the example set by some of
the kinder individuals out there, and not keep trying to
squeeze money out of fellow Amigans just because they know how
to drive a compiler.
>>>>>PROMOTE ComplicatedWare<<<<<
Page 17 WiZFix's Fantastic Manual Page 17
10 Copyright
WiZFix is copyright Andy Wilson (1993) - all rights reserved.
WiZFix may not be reverse engineered, dissassembled, de-compiled
or re-sourced at all.
11 Warranty
No warranty is expressed or implied in the use of this
software, whether it be registered or freeware, the copyright
holder, Mr Andrew Wilson, accepts no responsibility whatsoever
for any damage or harm to you, your computer, or any third party
or third party equipment no matter how such damage may transpire.
Any expense incurred directly or indirectly as a result of
using this software shall fall upon the user: YOU assume the cost
of any and all necesseary or desirable servicing, repair,
replacement or correction. Under no conditions whatsoever shall
the copyright holder be liable to any damages arising out of the
use or misuse or inability of the programme to work or function
as described above.
There is no warranty that this software is fit for the purpose
described above nor that it will operate reliably or reproducably
at any time. The user uses this programme entirely at his/her
own risk.
In a nutshell - if it goes wrong its NOT MY FAULT.
The copyright holder reserves the right to develop or not
develop this software at any time in the future, without notice.
12 Distribution
WiZFix must be distributed freely in either electronic form or
via magnetic media. No costs over and above that charged by Fred
Fish for the supply of one diskette may be charged.
WiZFix must be distributed only as a complete file archive; the
executable files must not under any conditions be compressed with
e.g. POWERPACKER or other software. Only unmodified copies of
the archive shall be distributed at all times, with all supplied
documentation etc. intact.
The distributor agrees to withdraw the distribution of WiZFix
if requested to do so by the copyright holder.
Page 18 WiZFix's Fantastic Manual Page 18
13 Acknowledgements
Many thanks to:
Iain Hibbert for his programming advice and testing of WiZFix -
may your netmail directory recover in good time..
René Hexel for TrapToss - without which this software would be
pretty useless! An excellent piece of software René and one of
the very few actually worth the registration fee! Well done and
please keep up the good work René.
Luca Spada for providing an excellent range of FREE software.
If only other Amiga programmers could follow such a lead.
Fred Waicsek for calling me and informing me of bugs, even
though he's the other side of the North Sea - thanks chum!
Roger Nordin for the useful dialogue and technical information,
and for the splendid job you've done for the Amiga community.
Thanks!
Tony Jones - nothing whatsoever to do with the development of
WiZFix, just a good friend..
Page 19 WiZFix's Fantastic Manual Page 19
ROADMAP
Section No. Title Page No
1 Introduction 2
2 Overview 2
3 Installation 3
4 Configuration 3
4.1 Configuration Keywords 4
4.1.1 LOGFILE 4
4.1.2 USETRAPLISTPW 4
4.1.3 PASSWORD 4
4.1.4 ALLOWCREATE 5
4.1.5 PREADCONFIG 5
4.1.6 HELPFILE 5
4.1.7 ZONE 5
4.1.8 (NO)ALLOWFORWARDINGPOINTS 6
4.1.9 (NO)ALLOWFORWARDINGNODES 7
4.1.10 DEFAULTLEVEL 7
4.1.11 LEVEL 7
4.1.12 ECHOLEVEL 8
4.1.13 (NO)SECURE 9
4.1.14 RESCANLEVEL 10
4.1.15 RESCANPROTECT 10
4.1.16 SKYTICK 10
4.1.17 FTICK 10
5 Operation 11
6 CLI Arguments 13
6.1 ECHOLIST 13
7 Example Configuration 14
8 Future 16
9 Registration 16
10 Copyright 17
11 Warranty 17
12 Distribution 17
13 Acknowledgements 18
RoadMap 19
* I hope to see ComplicatedWare catch on *
