The following is a first attempt at an FAQ list. If you would like to add anything to this list or you think that something is incorrect then please send mail to support@xtel.co.uk. ----------CUT HERE---------- This is the Frequently Asked Questions (FAQ) list for ISODE, PP, and QUIPU. This list is based on support queries sent to the X-Tel support desk. If you would like to add anything to this list or have any other comments, please send them to support@xtel.co.uk Compiled by Jason P. Kitchen Mon Feb 1 09:07:42 GMT 1993 CONTENTS 1. "No tailoring for 'splitter' channel" in norm logs. 2. What are the most update versions of ISODE, PP, etc. ? 3. How can I get the SunNet 7 patch and what does it fix ? 4. Delivery Reports get stuck in the shell channel. 5. Quipu generates the error message "tai_string failed nameserver" on start up. 6. Error message "TNetListen failed: no supported network address" is generated when tsapd starts. 7. Shared library warnings 8. Internal error for community "XXX" errors 9. Setting up PP as a central mail hub. 10. How to delete messages from PP's queue 11. dummy.log file grows very quickly 12. Keeping PP's tables up to date (UK) 13. How to set up NTP (UK) 14. Cannot find my own 'official' name error 15. Why do postal addresses get truncated to 30 characters in ISODE-8/QUIPU-8 ? 16. Performance of PP 17. What protocols does ISODE support at each layer ? 18. Which platforms have ISODE and PP been ported to ? 19. PPMS Beta availability 20. Disabling MTA's using the lconsole 21. How do I get XUA ? 22. How to configure User Friendly Naming (UFN) 23. Changing colours in XT-DUA and other X applications 24. How to configure licensing for X-Tel products (Flexlm) 25. Flexlm licensing problems 26. Connecting authenticated to the QMGR using MTAconsole, lconsole, etc. 27. Configuring ISODE for RFC-1006 28. How to install the JNT PP binary distribution 29. Configuring PP for X.400(88) -------------------------------------------------------------------------------- 1. "No tailoring for 'splitter' channel" in norm logs. This message is seen in PP's norm logs when the splitter channel is used in PP-6.0. The messages can be ignored as they are spurious. But if they irritate then a patch is available from X-Tel (bug reference pp-6.0-003). -------------------------------------------------------------------------------- 2. What are the most update versions of ISODE, PP, etc. ? 1. Public Domain PP 6.0 ISODE/QUIPU 8.0 2. UK Academic Community JNT Binary PP 1.5 JNT Binary ISODE 8.0.3 JNT XUA 1.0 (includes ppms) JNT PPMS 1.1 (source) 3. X-Tel Products XT-PP 1.0 XT-QUIPU 1.0 XT-DUA 1.0 XT-MUA 1.0 -------------------------------------------------------------------------------- 3. How can I get the SunNet 7 patch and what does it fix ? This is available from X-Tel as follows: Anonymous FTP from xtel.co.uk: Login: anonymous Password: anything you like File: /pickup/100328-10.tar.Z NIFTP from xtel.co.uk: Login: guest Password: your email address File: /pickup/100328-10.tar.Z FTAM from xtel: Login: anon File: /pickup/100328-10.tar.Z Note that it is not possible to do an `ls' in the pickup directory. Simply `cd' to the directory and use `get' to retrieve the patch distribution. The patch fixes a problem which caused Quipu to get itself into a tight loop. For further information see the readme in the patch distribution. -------------------------------------------------------------------------------- 4. Delivery Reports get stuck in the shell channel. The usual cause of this behaviour is a misconfiguration of the shell channel (or any other channel which is not capable of handling delivery reports) in the tailor file. Make sure that drchan=dr2rfc is set on the shell channel in the PP tailor file. -------------------------------------------------------------------------------- 5. Quipu generates the error message "tai_string failed nameserver" on start up. This is caused by an attempt to set the "nameserver" variable in the quiputailor file. This option is no longer supported and so the line beginning "nameserver..." should be removed from quiputailor. -------------------------------------------------------------------------------- 6. Error message "TNetListen failed: no supported network address" is generated when tsapd starts. This message usually means that you have not specified an NSAP for tsapd to listen on. Use the -N flag or set the local_nsap variable in isotailor specify the NSAP address. See the man page for further details. If you have specified an NSAP then it is possible that you will also need to set the following variables in isotailor: default_nsap_community: JanetNS nsap_default_stack: CONS -------------------------------------------------------------------------------- 7. Shared library warnings ld.so: warning: /usr/local/lib/libdsap.so.80.0 has older revision than expected 2 This error message is caused by a SunOs "feature" and can usually be ignored. However, if you wish to get rid of the messages you can do this by creating a symbolic link from the expected library name to the actual name, for example: ln -s /usr/local/lib/libdsap.so.80.0 /usr/local/lib/libdsap.so.80.2 (Note that some SMTP servers, especially pc-based servers barf on the library message so it is necessary put it in a link as described above). -------------------------------------------------------------------------------- 8. Internal error for community "XXX" errors Errors of this type mean that there is no macro defined for "XXX" in the isomacros file. A common cause of this error is misconfiguration of the ETCPATH variable in isotailor. Either the variable is not set at all or it is incorrectly set. The error messages simply mean that no definition of the variable/macro can be found in the ISODE tailor files. It may also indicate that the isomacros file cannot be read for some other reason (e.g. file is corrupted). internal error for community "realNS" internal error for community "Int-X25" internal error for community "Internet" internal error for community "Janet" internal error for community "localTCP" internal error for community "IXI" invalid community name "WIN" unknown community name "WIN" for variable ts_communities bad community name "Int-X25" for variable default_x25_community bad community name "Internet" for variable default_tcp_community Quipu failure (-1): Cannot open tailor file -------------------------------------------------------------------------------- 9. Setting up PP as a central mail hub. This example shows how a central mail hub can be configured to forward mail to users on other machines. In this example the central mail machine, lancaster is known as xtel.co.uk to the outside world. In the pp tailor file the following definitions are required: loc_dom_mta: lancaster.xtel.co.uk loc_dom_site: xtel.co.uk The internal domain vulcan.xtel.co.uk is hidden by the central mail hub. Messages sent to users at xtel all have the form: i.surname@xtel.co.uk. These users have their mailboxes on various machines. In this example we will consider two users: 1. j.kitchen (username jpk) has his mailbox on the machine vulcan. 2. f.bloggs has his mailbox on the central mail machine lancaster. In the domain table you need to include the following entries: vulcan.xtel.co.uk: local=vulcan xtel.co.uk:local This says that the messages sent to the domain vulcan should be recognised as local. The alias and user information is contained in the tables vulcan-aliases and vulcan-users. The channel table needs the following entry: vulcan.xtel.co.uk: vulcan(smtp) This means that messages to be sent to the machine vulcan should be sent via the smtp channel. The domain xtel is defined as local. In the users table enter the name of the mail user. This is the name of the user in the mail address: e.g. j.kitchen@xtel.co.uk: j.kitchen: 822-local vulcan.xtel.co.uk f.bloggs: 822-local lancaster.xtel.co.uk This says that messages to j.kitchen should be delivered by 822-local on the machine vulcan.xtel.co.uk. In the aliases table, specify the address which messages to j.kitchen should actually be delivered to: j.kitchen: synonym jpk@vulcan.xtel.co.uk 822 fred:synonym f.bloggs In vulcan-users: jpk: 822-local vulcan.xtel.co.uk vulcan-aliases: jpk: synonym j.kitchen@xtel.co.uk 822 external The external qualifier ensures that no looping occurs -------------------------------------------------------------------------------- 10. How to delete messages from PP's queue A quick and nasty way to do this is to edit the addr file of the message. Change all the "status=pend" and "status=dliv" to "status=done". The message will be removed from the queue the next time that it is polled. Alternatively you could create a script like this to do the work for you: #!/bin/csh -f # rmsg # Script to delete a message from PP's queues. # rmsg msg_number set PPQUEUEDIR=/u3/spool/pp/queues set TMPDIR=/var/tmp if (`whoami` != pp && `whoami` != root) then echo You must be pp or superuser exit 1 endif if ($#argv != 1) then echo Usage: $0 message_number exit 1 endif set msg_num=$1 set msg_dir=$PPQUEUEDIR/msg.$msg_num set addr_file=$msg_dir/addr set tmp_file=$TMPDIR/$msg_num if (! -d $msg_dir) then echo Message $msg_num does not exist exit 1 endif # Change all the status=pend and status=dliv to status=done cat $addr_file | sed 's/status=pend/status=done/g' | \ sed 's/status=dliv/status=done/g' >$tmp_file mv $addr_file $addr_file.old mv $tmp_file $addr_file -------------------------------------------------------------------------------- 11. dummy.log file grows very quickly The dummy.log file is used between the time a new PP process starts up and the completion of the processing of the pp tailor file. If some of the logging levels are set to all in isotailor then the log can grow very rapidly. The solution to this problem is to set the logging level to something specific. For example, change: x25level all To: x25level: exception -------------------------------------------------------------------------------- 12. Keeping PP's tables up to date (UK) Jason P. Kitchen X-Tel Services Limited December 1992 The following note explains the information that needs to be kept up to date in PP's tables. There are also suggestions on how you can do this automatically. This information is aimed primarily at the UK academic community but the underlying principles should apply to other email communities too. Sources of data There are two main sources of master tables in the UK - the NRS at Salford and the MHS Relay at ULCC. The NRS is able to provide a regularly updated file named DERFIL3 which contains large amounts of raw routing data for the UK's internal domains. This information can be processed automatically (to produce *.df3 files) and merged with local routing information (loc.* files) to produce PP's tables. The MHS Relay provides a number of files which contain international routing information (the ukac files). These are updated on a less frequent basis to DERFIL3 (once a month). Here is a summary of the sources for each of the major PP tables: domain: Function: used by submit to derive fully qualified domain from short forms or aliases and to obtain the routing information for that domain. Sources: domain.df3, loc.domain or: Function: used to provide normalisation and routing for X.400 addresses in the same way that the domain table does for RFC-822 addresses. Sources: or.df3, loc.or, or.ukac channel: Function: submit uses the channel table to find out which channel should be used to send mail on to the final destination (or to a relaying MTA). The destination is identified by the mta entries in eith the or or domain tables. Sources: channel.df3, loc.channel x400out88: Function: used by outgoing x40088 channel to map a hostname onto the information required for addressing and connecting to the remote MTA. Sources: ch-x400out.df3, loc.ch-x400out88 x400in88: Function: used by the incoming x40088 channel to map the OSI calling address of the remote MTA onto the MTA name and related information. Sources: ch-x400in.df3, loc.ch-x400out88 rfc2or: Function: used to map RFC-822 addresses to X.400 addresses using the mappings defined in RFC-1148. Sources: rfc2or.ukac or2rfc: Function: used to map X.400 OR addresses to RFC-822 addresses using the mappings defined in RFC-1148. Sources: or2rfc.ukac rfc1148gate: Function: use in cases where an RFC-822 message is to be relayed across an X.400 link. Sources: rfc1148gate.ukac Building the tables automatically The tables mentioned above can be built manually by moving the DERFIL3 file to the tables/master directory and typing "make install" in the directory above (tables). However, you will probably prefer to let the machine do this automatically. The following steps provide some hints on how to do this: 1. Create a cron entry for pp as follows: 30 8 * * * /xtel/pp/bin/pp.nightly 30 4 * * * /xtel/pp/bin/nrs-fetch This says run the script nrs-fetch every day at 4.30am and the pp.nightly script at 8.30am every day. 2. The nrs-fetch script looks like this: #! /bin/sh #nrs-fetch if ftpq -l | grep -s DERFIL3 then exit 0 else getdf3 /xtel/u3/pp/tables/master/DERFIL3 fi This script first of all checks that there are no other DERFIL3 fetches pending (ftpq) and then runs the getdf3 script. 3. The getdf3 script looks like this: #!/bin/sh #getdf3 cpf -b -Uanon -panon 'OSIDB>DERFIL3'@uk.ac.nrs ${1-DERFIL3} This uses an NIFTP Blue Book transfer to retrieve the DERFIL3 file. NOTE: you will most likely need to replace the cpf and ftpq commands with commands from the particular implementation of the blue book protocols you have at your site. A popular implementation is hhcp. 4. The pp.nightly script looks like this: #!/bin/sh pp.nightly cd /u3/pp/tables if make install then cp $T/master/DERFIL3 $T/master/DERFIL3.save fi This is a fragment of the pp.nightly script supplied with the JNT binary distribution of PP. It simply performs a make install on the tables so that the new DERFIL3 file is processed and the resulting tables installed. Other tables DERFIL3 keeps the tables mentioned above up to date for the UK's internal domains. There are also other files which are use to keep the international routing up to date. These are available from mhs-relay and are updated on a monthly basis. -------------------------------------------------------------------------------- 13. How to set up NTP (UK) The following is a message received from Rodney Tillotson: Here is what /usr/adm/ntp.conf says: # ntp.conf precision -7 # 2**-7 for 100Hz, local clock precision # this is an example. # Choose an unused NSAP which will route to your machine. # osilisten JanetNS=050605031522 # NSAP for the ULCC master clock: #peer OSI:JanetNS=050605031621 server OSI:JanetNS=050605031621 logfile /usr/spool/ntp/log logclock yes driftfile /usr/spool/ntp/drift Note the different formats for the listen and call addresses. The ULCC NSAP is cunningly chosen (in the JNT range) so that it's already mapped to a DTE in the NRS in some other context, I think. If you're using the PP DERFIL3 tools that means it will be in your X.25 routing tables without further effort. The same is likely to be true for your listen NSAP. You can suit yourself about the logfile and driftfile pathnames. If you are going to use those two you will have to create the directory /usr/spool/ntp, by typing (as root) machine# mkdir /usr/spool/ntp machine# You need this in ETCDIR/isobjects: "ntp pci" 1.17.4.3.99.2.1 "ntp" 1.17.4.3.99.2.2 - but look out, I just made up those two OIDs and there's probably a proper way to do that. It may not matter what the numbers are. You will also need something like this in /etc/rc.local, to start the service when the machine boots: # if [ -f /usr/adm/ntp.conf ]; then /usr/local/lib/pp/cmds/ntpd echo 'start ntp' fi # The logfile grows fairly fast, because every few minutes it logs three lines like this: 9/ 9 16:56:26 ntpd 00124 (#0 ) clock: select peer JNTNSAP=05031621 stratum 2 was UNSYNCED 9/ 9 17:00:43 ntpd 00124 (#0 ) adjust: STEP JNTNSAP=05031621 st 3 off 0.693001 drft 0.090890 cmpl 0.021331 9/ 9 17:00:43 ntpd 00124 (#0 ) Lost NTP peer JNTNSAP=05031621 There must be a way to tinker with the logging, which I haven't investigated. The README used to give the wrong directory for the config file but I think that's fixed now. I hope that's everything. Rodney. -------------------------------------------------------------------------------- 14. Cannot find my own 'official' name error This message and similar ones mean that the loc_dom_mta hostname specified in PP's tailor file cannot be found in DNS, NIS, hosts tables or whatever your system's hostname command uses to resolve hostnames. -------------------------------------------------------------------------------- 15. Why do postal addresses get truncated to 30 characters in ISODE-8/QUIPU-8 ? In ISODE-7.0 postal addresses of up to 60 characters were allowed. However, this was not in keeping with the standards documentation which specified a maximum of 30 characters. Therefore this was changed in ISODE-8.0 to make this conform to the standards. -------------------------------------------------------------------------------- 16. Performance of PP The following figures were collected from various people around the net. We have not been able to verify or test these figures - so not guarentees are given or implied. PP Benchmark Summary (sorted) Model Disc M/s Notes ------------------------------------------------------------------------------- Sun 4/490 TMPFS 84.75 Sun 4/460 TMPFS 69.44 Sun SSII TMPFS 57.04 Sun 4/460 IPI + Prestoserve 15.37 No fsync/flock Sun 4/460 IPI + Prestoserve 10.98 No fsync Sun 4/470 IPI 10.27 Sun 4/460 IPI + Prestoserve 9.86 Sun 4/460 IPI + Prestoserve 9.53 No flock Sun 4/280 TMPFS 6.02 Load Avrg 7 IBM RS/6000 ??? 4.92 No fsync Sequent S81 (20) DCC 4.83 IBM RS/6000 ??? 4.22 No fsync IBM RS/6000 ??? 4.18 IBM RS/6000 ??? 4.13 No flock/fsync Sun SS2 SCSI + Presto 3.75 No fsync Sun SS2 SCSI + Presto 3.56 Dec 5500 RA90 + Prestoserve 3.13 IBM RS/6000 ??? 2.92 No flock IBM RS/6000 ??? 2.88 Sun 4/490 IPI 2.77 No fsync Sun SS2 SCSI 2.65 No fsync Sun SSII NFS to 4/470 with presto 2.64 Sun 4/490 IPI 2.19 Sun SS2 SCSI 2.17 Sun SSII SCSI 1.96 No fsync IBM 3090/300 ??? 1.95 No fsync Sun 4/330 SCSI 1.91 Idle, no fsync Sun 4/460 IPI 1.87 IBM 3090/300 ??? 1.82 Sun 4/490 IPI 1.65 No fsync ICL DRS6000 ??? 1.61 No fsync Sun 4/330 SCSI 1.58 Idle Machine Dec 5000 RZ56 1.56 Sun 4/280 SMD + SMD4 1.56 Dec 5500 RZ57 1.55 No fsync Sun 4/390 IPI 1.55 Load Avrg 2 Convex C220 IPI 1.51 ICL DRS6000 ??? 1.44 Sun SSII SCSI 1.43 Sun SSII SCSI 1.42 Sequent S81 (20) 4way DCC 1.39 Sun 3/280 SMD 1.39 Dec 5000 SCSI 1.38 No fsync Dec ?? SCSI 1.37 Sun 3 XY 1.36 No fsync Dec 5500 RZ57 1.33 Sun 4/330 SCSI 1.32 No fsync Sun 4/490 IPI 1.32 Sun SLC SCSI 1.30 No flock/fsync DEC MV 3600 RA82 1.29 Load Avrg 2 HP 9000/720 ??? 1.27 No fsync/flock November 10, 1992 - 2 - PP Benchmark Summary (sorted) Model Disc M/s Notes Unisys U6000 SCSI 1.27 No fsync Sun SLC SCSI 1.26 No fsync Unisys U6000 SCSI 1.24 Sun 3 XY 1.21 ICL DRS3000 SCSI 1.18 No fsync Sun IPC SCSI 1.18 Dec 5000 SCSI 1.17 Dec 5849 (4cpu) RA90 1.17 Sun 4/280 SMD 1.17 Load Avrg 7 Sun 4/330 SCSI 1.17 Sun 4/490 IPI 1.17 Sun 4/490 SCSI 1.16 No fsync Sun SLC SCSI 1.15 No flock Sun SSII NFS to SCSI 1.14 DEC 5400 RA90 1.13 Load Avrg 5 Sun 4/330 XD 1.13 Busy, no fsync Sun SLC SCSI 1.13 Sun 4/330 CDC Sabre 1.10 No fsync Sun 4/490 SCSI 1.10 Sun 4/330 XD 1.09 Busy Machine Dec ?? SCSI 1.08 No fsync Sun 3/60 SCSI 1.05 Load Avrg 1 Sun 4/330 CDC Sabre 1.05 ICL DRS3000 SCSI 1.01 HP 9000/720 ??? 1.00 Sun IPC SCSI 0.97 No fsync Sun 4/330 SCSI 0.93 Busy machine Sun 4/330 SCSI 0.92 Busy, no fsync Sony 3250 ??? 0.86 No flock Sun SS2 No presto 0.85 Sun IPC SCSI 0.80 Sun 4/330 SMD 0.68 Load Avrg 7 Sun 386i SCSI 0.63 Sun 4/330 SCSI 0.61 Load Avrg 7 DEC MV-II RVD 0.54 Load Avrg 3 Sun SLC NFS to IPI 0.42 HP 9000/370 ?? 0.37 Load Avrg 6 Sun SLC NFS to IPI 0.31 No flock/fsync MIPS Magnum 3000/33 SCSI MIPS Magnum 3000/33 SCSI No fsync November 10, 1992 -------------------------------------------------------------------------------- 17. What protocols does ISODE support at each layer ? ISODE implements the top four layers of the ISO OSI Reference Model. The following protocols are implemented: 7 (Application): ACSE, ROS, RTS 6 (Presentation): normal, X.410 5 (Session): session versions 1 and 2 4 (Transport): CLNS, CONS, (RFC-1006/TCP-IP, X.25) ISODE builds on the network services provided by the machine it is built on. See the FAQ on supported platforms for further information. -------------------------------------------------------------------------------- 18. Which platforms have ISODE and PP been ported to ? ISODE and PP Platforms ____________________________________________________________________ Machine OS ISODE PP Stacks Notes ____________________________________________________________________ ??? BSD/386 7.0 6.0 TCP ____________________________________________________________________ CCUR 6000 RTU 5.0 7.0 Yes! TCP 1 ____________________________________________________________________ CCUR 6000 RTU 6.0 7.0 Yes! TCP 2 X25 CLNS ____________________________________________________________________ CDC 4000 Series EP/IX 1.3.2 6.6+ TCP 3 EP/IX 1.4.1 CLNS X25 ____________________________________________________________________ COMPAQ 386/25 SCO Unix 5.2 6.0 TCP ____________________________________________________________________ COMPAQ 386 BSD 7.0 TCP 4 X25 ____________________________________________________________________ Convex C120 ConvexOS 8.1 7.0 TCP 5 ____________________________________________________________________ DEC Vax 2nd Berkeley Network rel 7.0 TCP X25 CLNS ____________________________________________________________________ DEC DECnet-ULTRIX V5.0 7.0 TCP 6 CLNS ____________________________________________________________________ DEC Ultrix 3.1D 7.0 5.2 TCP 7 Ultrix 4.0 X25 Ultrix 4.1 ____________________________________________________________ DEC Ultrix 4.2 7.0 TCP X25 CLNS ____________________________________________________________ DEC VMS v5.x 7.0 TCP X25 ____________________________________________________________ DG Avion DGUX 4.30 7.0 TCP 8 ____________________________________________________________ Encore Multimax 3xx UMAX V 2.2h 6.0 TCP 9 Encore Multimax 5xx ____________________________________________________________ Encore NP1 UTX/32 3.1a 7.0 TCP 10 X25 ____________________________________________________________ Encore PN6000 UTX/32 2.1b 6.0 TCP 9 Encore PN9000 X25 ____________________________________________________________ HP/9000/3xx HP/UX 6.0 7.0 TCP 11 HP-UX 7.05 B ____________________________________________________________ HP/9000/8xx HP-UX 7.00 7.0 Yes! TCP 11 X25 ____________________________________________________________ IBM 3090 AIX/370 1.2.1 7.0 TCP 12 ____________________________________________________________ IBM PS/2 AIX 1.2.1 6.7 TCP 13 ____________________________________________________________ IBM RS/6000 AIX 3.2 8.0 6.0 TCP X25 ____________________________________________________________ ICL DRS/6000 8.0 5.2 TCP 14 X25 ________________________________________________________________________ Interactive Interactive 5.4.0.3 7.0 TCP ________________________________________________________________________ Macintosh A/UX 2.0.1 7.0 TCP ________________________________________________________________________ Macintosh MacOS V6.x 7.0 TCP 15 ________________________________________________________________________ Mips 4_52 ATT_V3_0 7.0 5.2 TCP 16 ________________________________________________________________________ NCR 3400 SVR4 Unix 7.0 TCP 17 ________________________________________________________________________ NeXT 7.0 5.2 TCP 18 ________________________________________________________________________ ORION/Clipper 6.8 TCP ________________________________________________________________________ Olivetti LSX-3020 X/OS 2.1 6.7b 5.0 TCP 1 X25 ________________________________________________________________________ Pyramid 9800 OSx 5.1 (4.3BSD/SVR3.2) 7.0 5.2 TCP 19 Pyramid MIS ________________________________________________________________________ SEQUENT DYNIX V3.0.18 7.0 TCP 8 ________________________________________________________________________ Silicon Graphics IRIS IRIS 3.2.2 7.0 TCP 20 ________________________________________________________________________ Silicon Graphics IRIS IRIS 4.01 7.0 TCP 21 ________________________________________________________________________ Solbourne Series 5/600 OS/MP 4.1 7.0 TCP ________________________________________________________________________ Sony News-1750 NEWS-OS 3.3 6.8 TCP NEWS-OS 4.0c ________________________________________________________________________ Sony News-3250 System V.4 7.0 5.2 TCP ________________________________________________________________________ Sun4 SunOS 4.1 8.0 6.0 TCP Sun3 SunOS 4.1.1 X25 SunOS 4.0.3c CONS CLNS ________________________________________________________________________ 1: NOT SNMP or VT 2: little tested 3: Official upper layer 4: prototype only! 5: Planned port 6: Being worked on! 7: 3.1D binaries compiled under 4.2 8: Only QUIPU confirmed 9: Not QUIPU 10: Need -Dregister= in CONFIG.make 11: Need bug-fix no. 5 from bug-isode@xtel.co.uk. not SNMP,VT or FTAM-FTP gateway 12: No VT,QUIPU not tested 13: Models 80 and 95 14: NOT SNMP or VT,PP and X.25 requires patches available from X-Tel 15: Using MacTCP 16: Only QUIPU tested,built using BSD43 config 17: Need Wollongong(WIN) TCP/IP and /etc/shadow fixes from bug-isode@xtel.co.uk 18: Need bug-fix no. 6 from bug-isode@xtel.co.uk 19: built using BSD config,no VT or SNMP 20: ISODE only,minor Makefile fixes required 21: Not SNMP or VT The above tables do not refer to beta releases of ISODE and PP more recent than the public ISODE-7.0 or PP-5.2 releases. The above table is generated from reports sent to bug-isode and pp-support. There is no guarentee the information is correct. -------------------------------------------------------------------------------- 19. PPMS Beta availability A N N O U N C E M E N T This is a PPMS BETA release. It is known as PPMS BETA 1.0 PPMS is a Message Store (MS) that is : o Designed to go with the PP MTA. o Provides a user with capabilities for message storage in accordance with ISO/IEC 10021-5 (CCITT X.413) and ISO/IEC 10021-7 (CCITT X.420). o Provides access for User Agents (UAs), both for UAs co-located with PPMS through the procedural interface, and for remote UAs using either the P7 protocol or an enhancement of P7 called PP-P7. o Provides a general procedural interface through which users who write their own UAs are able to use PPMS. This enables a UA to operate in either remote or co-located mode. o Able to run on a range of UNIX and UNIX-like operating systems, in particular : SUNOS, Ultrix, and BSD. No kernel modifications are required. Please note that : o No User Agents (UAs) are included with PPMS. However, procedural access to the MS is documented, to encourage others to write or to port UAs. Two existing UAs have been tested with PPMS. They are : o XUA (An X-Windows UA) available from X-Tel Services Ltd. RFC 822 support@xtel.co.uk X.400 S=support; O=XTEL; PRMD=X-Tel Services; ADMD= ;C=GB; o WhiteMail (A PC UA for Microsoft Windows) available from Edinburgh University RFC 822 rainbow@edinburgh.ac.uk X.400 S=rainbow; O=edinburgh; PRMD=UK.AC; ADMD= ; C=GB; o PPMS BETA 1.0 requires ISODE 8.0. Releases of ISODE before 8.0 cannot be used as alternatives. o PPMS BETA 1.0 requires PP 6.0. Releases of PP before 6.0 cannot be used as alternatives. o PPMS has a problem supporting address : RFC 822 JNT-PPMS@XTEL.CO.UK X.400 S=JNT-PPMS; O=XTEL; PRMD=X-Tel Services; ADMD= ; C=GB; Bug reports (and fixes) are welcome. o The discussion group PPMS-PEOPLE@CS.UCL.AC.UK is used as an open forum on PPMS; Contact PPMS-PEOPLE-REQUEST@CS.UCL.AC.UK to be added to this list. o The primary documentation for this release consists of a PPMS Manual (approx 400 pages). The sources to the manual are in postscript. LICENCE AGREEMENT PPMS has been funded by the UK Government Department of Education with the intention that it should be made available to the UK and International Academic and Research Community as free as possible of charge and restriction. However, copyright is retained by the UK Science and Engineering Research Council ("the Council") on behalf of the Joint Network Team (JNT). PPMS may be used subject to the following Licence Agreement: a) This software and any developments may be used for the User's internal operations only and not for resale or profit. b) The authors will not be held liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in action of contract, negligence or other tortuous action, arising out of or in connection with, the use or performance of the software. Further, the authors shall not be held liable for any damages, costs, charges and expenses arising from or incurred by reason of any infringement or alleged infringement of copyright in consequence of the use or possession of the software or documentation by the user. c) If the software and any developments are intended to be used for resale or profit then the Licensee shall seek the advance authorisation of the Council and shall also confirm that any resultant product shall be made available free of any licence charge to the UK Academic and Research Community as defined by CHEST. d) In the event that the Licensee is unable to accept the terms relating to use of resultant products as specified in sub-clause c) above then the Licensee may propose alternative terms to cover use of the software and developments for the Council's consideration. Such proposals shall be assessed by the Council in terms of benefit to the UK and International Academic and Research Community. DISTRIBUTION SITE FTAM on JANET or PSS The PPMS binaries are available by FTAM at X-Tel Services Ltd, over X.25 using JANET (DTE 000021001029) or PSS (DTE 235110201034) with TSEL 259 (ASCII encoding). Use the \anon" user-identity and retrieve the files : o pickup/ppms1.0.bin.tar.Z (the tar image of the ppms binaries run through the compress program) o pickup/ppms1.0.doc.tar.Z (the tar image of the ppms documentation in postscript run through the compress program) FTP Use anonymous FTP to xtel.co.uk [128.249.9.1] to retrieve the files o pickup/ppms1.0.bin.tar.Z (the tar image of the ppms binaries run through the compress program) o pickup/ppms1.0.doc.tar.Z (the tar image of the ppms documentation in postscript run through the compress program) SUPPORT (PLUS TAPE AND DOCUMENTATION) A UK company is to provide support for PPMS - X-Tel Services Ltd. This company provides an update service, general assistance and site specific support. Postal Address X-Tel Services Ltd. University Park, Nottingham, NG7 2RD UK Telephone +44 602-514600 Fax +44 602-790278 Support Address jnt-ppms@xtel.co.uk Tape and Documentation sales@xtel.co.uk -------------------------------------------------------------------------------- 20. Disabling MTA's using the lconsole It is possible to disable an MTA so that messages are not sent from your MTA to the one specified. However this does not work as expected. For example: omega% lconsole -Q omega -u pp password (omega:pp): Connecting to omega...succeeded omega> disable mta smtp arts.qmw.ac.uk omega> q omega% mail bmp@arts.qmw.ac.uk >> Message msg.00454-0 transfered to 1 recipients 12/ 4 18:43:13 smtp 00457 (pp ) Closing connection to arts.qmw.ac.uk This is because of a deficiency in the way that the qmgr operates. There must be a message on the MTA before you can disable the MTA. -------------------------------------------------------------------------------- 21. How do I get XUA ? A N N O U N C E M E N T This is the first release of XUA - a highly functional MOTIS/X.400 1988+ User Agent. XUA allows users to compose, read and manage X.400 messages containing a number of separate body parts, each part potentially of a different media type. XUA includes the following features: o Folders - allowing mail to be managed in a structured manner o Address Book - allowing access to frequently used addresses (includes support of X.500 lookup) o Collections - allow message selection by feature (e.g. sender address) o Stationery - allowing customisation of message forms XUA has been jointly developed by X-Tel Services Ltd. and Nottingham University Communication Research Group with funding support from the UK Government Department of Education. REQUIREMENTS FOR XUA Version 1.0.0 Sun SPARC architecture This version of XUA is designed to be co-located with the PP Message Transfer Agent and its associated message store (PPMS). (A subsequent version currently in beta will interwork remotely over P7 with other '88/92 compliant message stores.) This release is designed to run on Sun SPARC architecture with OS version 4.1.x. LICENCE AGREEMENT In order to promote the use of OSI based applications this version of the XUA product is openly available for operational use by the UK and International Academic Research communities. A licence to use the software can be obtained by anyone within these communities. (NB: after installation, a run-time licence key must be obtained from X-Tel.) XUA may be used subject to the following Licence Agreement: a) This software may only be used for the User's internal operations and not for resale or profit. b) X-Tel and Nottingham University will not be held liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in action of contract, negligence or other tortuous action, arising out of or in connection with, the use or performance of the software. Further, the authors shall not be held liable for any damages, costs, charges and expenses arising from or incurred by reason of any infringement or alleged infringement of copyright in consequence of the use or possession of the software or documentation by the user. DISTRIBUTION SITE FTAM on JANET or PSS The XUA binaries are available by FTAM at X-Tel Services Ltd, over X.25 using JANET (DTE 000021001029) or PSS (DTE 235110201034) with TSEL 259 (ASCII encoding). Use the "anon" user-identity and retrieve the files : o pickup/xua1.0.bin.tar.Z (the tar image of the xua binaries run through the compress program) FTP Use anonymous FTP to xtel.co.uk [128.243.9.1] to retrieve the files o pickup/xua1.0.bin.tar.Z (the tar image of the ppms binaries run through the compress program) 3666995 Jan 8 09:44 pickup/xua1.0.bin.tar.Z UK ACADEMIC SUPPORT Support arrangements for this release of XUA are being made for the UK Academic Community. However, as these arrangements have not yet been finalised, the support can only be on a best effort basis. Email support for this community can obtained from X-Tel Services at the following email address: X.400 c=GB;A= ;P=X-Tel Services;O=XTel;S=xua-support; RFC 822 xua-support@xtel.co.uk OTHER SUPPORT Other academic communities can obtain support by arrangement with X-Tel. Contact details for X-Tel are as follows: Postal Address X-Tel Services Ltd. University Park, Nottingham, NG7 2RD UK Telephone +44 602-514600 Fax +44 602-790278 Support Address c=GB;A= ;P=X-Tel Services;O=XTel;S=xua-support; xua-support@xtel.co.uk Commercial Enquiries sales@xtel.co.uk -------------------------------------------------------------------------------- 22. How to configure User Friendly Naming (UFN) There are a number of problems with the UFN algorithm as defined in the original papers on this topic. There are two UFN configuration files - a system wide one called "ufnrc" located in the ISODE etc directory e.g. /usr/local/etc/ufnrc and a personal one found in ~/.ufnrc. The personal one overrides the system one. The installation script for xtdua and xtquipu installs a system wide ufnrc. The ufnrc tells the search algorithm which part(s) of the DIT to search based on the number of components in the ufn. The file contains a number of lines of the form: ############################################################################### # # Syntax: # # [ "," ] ":" # ::= A digit 0 - 9 # ::= A digit 0 - 9, or "+" -- + means 'or more' # ::= [ ] # ::= " # DN ::= A Quipu stye Distinguished name # ############################################################################### For example, the X-Tel ufnrc looks like: 1: c=GB@o=X-Tel Services Ltd c=GB c=GB@o=Nottingham University@ou=Academic Departments@ou=Computer Science - 2: c=GB c=GB@o=Nottingham University c=GB@o=X-Tel Services Ltd - 3,+: - c=GB c=GB@o=Nottingham University What this means is that if the ufn has 1 component, e.g. "graeme", the ufn algorithm will first start looking from c=GB@o=X-Tel Services Ltd if no exact matches are found then the search will continue from c=GB and thence to c=GB@o=Nottingham University@ou=Academic Departments@ou=Computer Science and finally from the root of the DIT - If the ufn has 2 components, e.g. "graeme,xtel" , then the order is c=GB c=GB@o=Nottingham University c=GB@o=X-Tel Services Ltd - and finally if the ufn has 3 or more components e.g "graeme,xtel,gb" then the following order is used. - c=GB c=GB@o=Nottingham University -------------------------------------------------------------------------------- 23. Changing colours in XT-DUA and other X applications Before you start changing the colours of your X application you should note that colour is always a problem because firstly it is very subjective - so your likes may be someone elses dislikes. Secondly colours vary quite a lot across display types. It is usually best to change the default colours in the user's personal defaults file which is in ~/app-name or $XAPPLRESDIR/app-name where "app-name" is the X application name. Note that this is case sensitive - the current application names for X-Tel products are: XTdua Mtaconsole (MTAconsole for PP versions previous to 6.0) XTmua XUA The basic format of the defaults file is: app-name*resource: resource_setting For example in XTdua you may have: XTdua*foreground: slate blue XTdua*background: cornsilk1 For a list of the colours that your X-Server has, see the file /usr/lib/X11/rgb.txt. To see what they look like use the xcolors application. There are many other resources besides colours that can be configured in this way. For example, button labels and accelerators may be changed from the user's defaults file. However it is usually best to use the applications hardwired defaults unless it is really necessary to change them. -------------------------------------------------------------------------------- 24. How to configure licensing for X-Tel products (Flexlm) X-Tel's products are protected using the Flexlm license manager product from Highland Software. The information in this technical note is based on the "Flexible License Manager Programmer Manual" version 2.1 and covers the following areas: 1. Format of the license file 2. License Administration Tools 3. Vendor Daemon Configuration The license management system is made up of a controlling license daemon (lmgrd) and one or more daemons which are supplied by vendors to protect their products. X-Tel's is named XTeld. Both these daemons are configured using a license file and additionally the vendor daemon may be configured through the vendor daemon configuration file. 1. Format of the license file The license file, usually named license.dat, consists of any number of SERVER lines followed by any number of DAEMON lines followed by one or more FEATURE lines. The SERVER line is used to indicate which node the license server may run on. It is also used by user applications to find out which host it needs to connect to obtain a license. A typical SERVER line may look like this: SERVER lancaster 550044c6 1700 This means that for an application to obtain a license it must connect to the host "lancaster" on port 1700. "lancaster" in this case is the host name of the machine as returned by the Unix hostname command. The hexadecimal number in the third field is the machine's hostid. The license server may only run on a machine which has this hostid. The DAEMON line is used to give information about a vendor daemon. A typical DAEMON line would look like this: DAEMON XTel /usr/local/etc/XTeld This simply gives the path to the executable of the vendor daemon XTel. It is possible to have many other DAEMON lines each supplied by a different vendor. In addition it is possible to specify defaults relating to each particular vendor daemon. This is done by adding a further path to the end of the DAEMON line, for example: DAEMON ACME /usr/local/etc/ACMEd /usr/local/etc/flexlm_daemon.options This species a path to the ACME daemon and also a path to a configuration file which relates to applications which use the ACME daemon. This configuration file may be used to reserve licenses, set timeouts, and so on - for further information see the section on end user license administration. The FEATURE line species the access permissions for the licensed application. An example of a FEATURE line is: FEATURE xtmua XTel 1.000 1-jan-00 20 AB2660519D4F86E96CD2 "X-Tel" Where: "xtmua" - the name of the application this feature is for "XTel" - the name of the vendor daemon the application should connect to "1.000" - the version number of the application "1-jan-00" - the date that the application license expires (year zero indicates that it never expires) "AB266...." - the encryption code - this unlocks the application "X-Tel" - a bit of text supplied by the vendor 2. License Administration Tools There are a number of tools shipped with X-Tel's licensed products which make license administration easier. These are: 2.1 lmstat This program allows the user to monitor the status of all licensing activity. The available flags are: -a Display everything -A List all active licenses -c license_file Use license_file (default is to use the environment variable LM_LICENSE_FILE) -S [DAEMON] List all users of DAEMONs features -f [feature] List all users of feature(s) -l [regexp] List all users of matching licenses -s [server] Display the status of server node(s) -t value Set lmstat timeout to "value" An example of it's use is: lmstat -c /usr/local/etc/license.dat -a lmstat - Copyright (C) 1989, 1990, 1991, Highland Software, Inc. Flexible License Manager status on Tue 1/19/93 12:34 License server status: lancaster: license server UP (MASTER) Vendor daemon status (on lancaster): XTel: UP Feature usage info: Users of xtdua: (Total of 4 licenses available) gal at lancaster on /dev/ttyp4 (v1.000), started Tue 1/19/93 at Users of xtmua: (Total of 20 licenses available) snk at vulcan on /dev/tty (v1.000), started Mon 1/18/93 at 16:38 gal at vulcan on /dev/ttyp1 (v1.000), started Tue 1/19/93 at 7:44 chris at vulcan on /dev/tty (v1.000), started Tue 1/19/93 at 12:28 2.2 lmdown Shuts down all license daemons (lmgrd and vendor daemons) gracefully. The usage is: lmdown IMPORTANT: The systems administrator should protect this program so that ordinary users cannot use it. 2.3 lmremove Allows the system administrator to remove a user's license for a specified application. This is sometimes necessary where the user was running an application on a machine that subsequently crashed. The usage is: lmremove [-c license_file] feature user host [display] The command removes all instances of "user" on node "host" (on display "display") from the pool of available licenses for "feature". 2.4 lmreread This utility forces the license daemon to reread the license file and implement any changes that have been made. All existing vendor daemons will also be signalled to reread the file. Usage: lmreread [-c license_file] 3. Vendor Daemon Configuration Licensing may be configured through the daemon options file. This is specifed as the fourth field on the DAEMON line in the license file. Each line in the daemon options file begins with one of the following keywords: RESERVE, INCLUDE, EXCLUDE, GROUP, TIMEOUT, NOLOG, REPORTLOG. 3.1 RESERVE The RESERVE keyword is used to reserve a license for a specified user, host, display, or group. Groups are defined using the GROUP keyword. The syntax of a RESERVE line is as follows: RESERVE number feature { USER | HOST | DISPLAY | GROUP } name Here are a few examples: RESERVE 1 xtdua USER jason -- reserves one xtdua license for user jason RESERVE 5 xtmua HOST vampire -- reserves 5 xtmua licenses for the host vampire 3.2 INCLUDE / EXCLUDE The INCLUDE and EXCLUDE keywords allow you to explicitly allow / prevent access to a feature for a particular user, host, display, or group. The syntax is: INCLUDE feature { USER | HOST | DISPLAY | GROUP } name EXCLUDE feature { USER | HOST | DISPLAY | GROUP } name Some examples: INCLUDE xtdua USER jason -- allows jason to run xtdua INCLUDE xtmua HOST vulcan -- allows users on vulcan to run xtdua EXCLUDE xtdua USER fred -- prevents fred running xtdua EXCLUDE xtmua GROUP xtel -- prevents users in the group xtel from -- running xtmua 3.3 TIMEOUT The TIMEOUT keyword is used to specify how long an instance of an application may remain inactive before it's license is returned to the pool of free licences. Syntax: TIMEOUT feature timeout_in_seconds 3.4 NOLOG This keyword is used to filter out messages from the vendor daemon log file. The syntax is as follows: NOLOG { IN | OUT | DENIED | QUEUED } Example: NOLOG IN -- filters out all messages relating to license returned to -- the pool 3.5 REPORTLOG This is used to specify the name of the vendor daemon log file. For example, 3.6 REPORTLOG /var/tmp/XTel.log If a "+" is placed before the filename, it is opened in append mode. -------------------------------------------------------------------------------- 25. Flexlm licensing problems 1. The log files All of the license daemons generate log files with the same format. Each logging line is of the form: mm/dd hh:mm (DAEMON NAME) message Where: "mm/dd hh:mm" is the date and time that the message was logged "DAEMON NAME" is the name of the daemon that generated the message "message" is the text of the message 2. Error messages The following is a list of common error messages. If you see other error messages please contact the support desk. DENIED: N feature to user (mm/dd/yy hh:mm) This means that the named "user" was denied access to "N" licenses of "feature". If you find that you are seeing lots of these messages it may be time to purchase more licenses (sales@xtel.co.uk). EXITING DUE TO SIGNAL nnn EXITING with code nnn The reason why a daemon exited (e.g. it was sent SIGKILL by the Unix kill command). EXPIRED: feature This means that the named feature or application has expired. If you have a temporary license then please contact our support desk for a full license. hostname: Not a valid server host, exiting This usually means that the hostname field in the license.dat file does not match that returned by the hostname command. If the hostname is correct, make sure it is reading the correct license file by setting LM_LICENSE_FILE or by using the -c flag. hostname: Wrong hostid, exiting The hostid in the license file does not match that returned by the hostid command. Make sure you are using the correct license file. BAD CODE for feature_name The specified feature name has a bad encryption code. This is rare but is almost certainly our mistake. Please contact the support desk. lost lock, exiting Error closing lock file Unable to re-open lock file The vendor daemon has a problem with it's lock file. This is usually caused by an attempt to run more than one instance of the same vendor daemon. Locate the other daemon and kill -9 it. No license data for "feat", feature unsupported There is no FEATURE line for "feat". You probably haven't installed the license information from X-Tel. No features to serve! You have a license file with no FEATURE lines in it. You probably haven't installed X-Tel's licensing information in the license file. 2. Bugs 2.1 IBM AIX short hostids The lmhostid command strips off ALL the leading zeros on an IBM AIX hostid as it assumes that the actual hostid never has a leading zero. The fix is to change any four digit hostid to a five digit one by adding a leading zero. 2.2 Sun Managers Information (sun-managers@rice.edu) [I didn't ask sun-managers, but spent quite some time and quite some knowledgable people on this. I think this information is nice-to-have when you get into the FlexLM license server business, so I hope some will profit from the effort I made] As we all know and complain about, SUN has unbundled its C-compiler in solaris 2.x. The compiler is now sold separately, and is protected with a floating license server. The license server stuff they use is not made by SUN, but by Highland Digital, and is called 'FlexLM'. It consists of a generic server (called lmgrd) and vendor-specific license servers, i.e. multiple vendors can use this license-server independently. At least, that is what the glossies say. But it isn't that easy! We already had an lmgrd running. It was used for ABEL by data-io. The license software provided was version 1.50. The sunpro-compilers now also have this software. It is version 2.26d. I merged this software with the (older) ABEL license stuff, but the result didn't work: If I used the new (sun) lmgrd, the ABEL license would not come up, if I used the old (data-io) lmgrd, the SUN licenses would not come up. The solution was quite simple after all: 1. Use the new software, except the vendor-specific daemon (for which no new version exists) 2. Add an (undocumented!) -b flag at the end of the lmgrd command line. This enables backward-compatibility. Note that there is no mention of this flag in the sparcworks installation manual! 3. The licenses now should come up. You cannot check the 'old' daemons with the new 'lmstat' command; use the old 'lmstat' for that. I.e.: use the NEW lmgrd, but the OLD utilities! 4. Complain to the vendor why they have not upgraded their stuff yet. Ver 1.5 seems to be 3 years old.. Phone numbers of Highland Digital: tech support +1 408 255 0274, sales etc +1 415 493 8550. I would like to thank Guido Raymakers and Jo Meier of Sun Netherlands, Jack Peeters of SIMAC, and Highland tech support for their joined effort to make this work. I spent all weekend on this, so I hope this does help some other people. Geert Jan BTW:I received a postscript manual for this software. Ask if you want a copy. ------- End of Forwarded Message -------------------------------------------------------------------------------- 26. Connecting authenticated to the QMGR using MTAconsole, lconsole, etc. By default the QMGR does not have a password set. This means that you cannot connect authenticated to qmgr using the lconsole or MTAconsole programs and therefore it is not possible to use some of the facilities such as restarting channels which require authentication. To register a password for the qmgr perform the following steps: 1. Use mkpasswd in PP's cmds/tools directory to create an encrypted password. 2. Enter the following information in auth.qmgr: :passwd=,rights=full e.g. lancaster% mkpasswd Password: jqa3T84ap2bSM lancaster% vi auth.qmgr lancaster% cat auth.qmgr pp:passwd=jqa3T84ap2bSM,rights=full -------------------------------------------------------------------------------- 27. Configuring ISODE for RFC-1006 RFC-1006 specifies a means of running OSI applications over a TCP/IP stack rather than an OSI stack. This is now an Internet standard for achieving this functionality. It is hoped that adoption of this approach in the UK academic community will help to achieve greater connectivity between UK DSA's and those in Europe and (especially) the USA. This FAQ is directed particularly at the UK academic community and the QUIPU DSA but should also prove a useful starting point for anyone wanting to configure ISODE for RFC-1006. 1. Configuring the isotailor file In the isotailor file change the value of the ts_communities variable to include the value "Internet". For example: ts_communities: JanetNS Janet IXI Internet Note that the ordering of values for this variable is important as this is the order in which calls to DSA's will be made - so in the example above, if the DSA being called has a JanetNS presentation address, this will be tried first. In the UK academic community, the value "Internet" should be placed at the end of this line as this is a requirement given in the document "Piloting the use of RFC1006 in the UK academic community" (IPTAG/92/52) by R.A. Day of the Joint Network Team. Also in the isotailor file add the value "tcp" to the ts_stacks variable. For example: ts_stacks: x25-84 x25 tcp NOTE: if ts_stacks is not defined in the isotailor file or if it is defined and has a value of "all", this step is not necessary. That is all that is required to configure ISODE. You must now configure the applications to make use of Internet addresses. The following example shows how to configure the X.500 DSA, QUIPU to listen on an Internet address. 2. Configuring a DSA to listen on an Internet address. This is achieved by editing the file DSA.real and adding the internet address as a value for the presentationAddress attribute. For example: presentationAddress= JanetNS=0210021900017000 | Janet=00002100102998 | IXI=20433450210398 | Internet=128.243.9.1+17004 Restart the DSA using one of the following methods: a) From dish use the command dsacontrol -restart b) Kill the process ros.quipu and restart the DSA from the command line. Testing There are a number of ways of checking that the DSA is in fact listening on the Internet address you have specified: a) In the logs (quipu.log) you should see the following message: DSA c=gb@cn=Vampire Bat has started on Internet=128.243.9.1+17004 b) Use dish to connect to the DSA using the Internet address: dish -c Internet=128.243.9.1+17004 -------------------------------------------------------------------------------- 28. How to install the JNT PP binary distribution The JNT binary distribution of PP is designed to be easier to install and configure than the source code version. It is designed particularly for sites that have one of the X-Tel configured Sun 4/330's but should work on other Sun's running the required OS level (see below). 1. Pre-Requisites The distribution is based on the following prerequisites.: o JNT configured SUN 4/330 with the X-Tel disk layout. However it should work on other Sun's o SunOS 4.1.1 operating system. It is also known to run under SunOs 4.1.2. o SunNet X.25 version 7.0 with patch 100328-10 o Sun Coloured Book software o ISODE binary distribution 2. Components The distribution contains all of the basic PP programs and channels but is preconfigured to a greater extent than a fresh installation from source. However, various components have been omitted such as the DECNet channel, X.400(84) configuration, the source code, and Unix-NIFTP (except for the parts that are needed for greybook). 3. Installation 3.1 mkdir /u3/pp-bdist 3.2 cd /u3/pp-bdist 3.3 Get the PP binary distribution - see instructions in another FAQ. 3.4 Untar it: uncompress -c pp-bdist.tar.Z | tar xvf - 3.5 Run the installation script as root ./install.sh The following is an example of an installation session. Example replies to questions are marked with five asterisks (*****): This installation script will install several binaries in various places. The binaries expect the following directories to exist: /usr/spool/pp /usr/spool/niftp /usr/local/lib/niftp /usr/local/bin These directories will be created as links unless they already exist. If you wish alternative disk space to be used, you should arrange for symbolic links to point to this space from these directories e.g., ln -s /usr/spool/pp /u3/spool/pp-6.0 This process will also overwrite the files /etc/niftptailor /etc/pptailor Is it ok to proceed with the above parameters? [y/n] y ***** What is your sites full name E.g., xtel.co.uk or cs.ucl.ac.uk default is noname: xtel.co.uk ***** What is your machines full name E.g., vulcan.xtel.co.uk, bells.cs.ucl.ac.uk etc default is dir1.xtel.co.uk: [ENTER] ***** That is the end of the questions - the rest of ths installation should proceed without any further intervention - unless existing files are going to be overwritten. 4. Post installation procedures There are still a number of things that you need to do before you have a running system. 4.1 Greybook If you are going to be running greybook then you will need to edit /etc/niftptailor and place you JANET address on the NET line. For example: NET janet queue=qj, address="000021001029/%E%X%D/%T" Edit /etc/ybts-auth: /xtel/u3/pp/cmds/chans/pj:ftp.mail:* 4.2 Add local information Add the local information to the loc.* files in the tables/master directory. For example, to add information about local users you edit the files loc.users, loc.aliases, loc.chlocal. To add information about routing to local hosts, edit the files loc.domain and loc.channel. When you add information to tables or modify the tailor file you should run ckconfig and rectify any problems reported. 4.3 X.400(88) Configuration If you are going to be running X.400(88) you will need to run either tsapd or iaed. To run the the x40088 channel from tsapd place the following line in the PP start up script (either pp.start or pp.startaspp): tsapd -N your_machines_nsap > /dev/null 2>&1 For further information on setting up X.400(88) connections see the seperate FAQ. 4.4 Starting up PP It is usually best to start PP from the file /etc/rc.local which is run on system startup. You should add something like this to rc.local: if [ -f /usr/local/lib/pp/cmds/pp.startaspp ]; then /usr/local/lib/pp/cmds/pp.startaspp & echo -n ' pp' fi or alternatively if [ -f /usr/local/lib/pp/cmds/pp.start ]; then /usr/local/lib/pp/cmds/pp.start & echo -n ' pp' fi The pp.start script attempts to run pptsapd and qmgr as root (if run from rc.local) whereas pp.startaspp will first of do an su to the pp user. -------------------------------------------------------------------------------- 29. Configuring PP for X.400(88) Jason P. Kitchen, January 1993 This document outlines the procedures that are necessary to set up an X.400(88) connection using the PP mail system. It assumes that the JNT binary distribution is being used within the UK academic community. However the underlying priciples apply to other network communities and versions of PP. 1. Tables for X.400 channels There are two channel tables. One for inbound, the other for outbound named ch.x400in88 and ch.x400out88. These are created by combining the local information from loc.ch.x400[in|out]88 and the NRS derived information in ch-x400[in|out].df3. You should always edit the loc.* files in tables/master rather than the ch.x400* files themselves - otherwise when you rebuild the tables any modifications you have made will be overwritten. [ For information on the or, or2rfc, rfc2or, rfc1148gate tables please see the FAQ "Keeping PP's tables up to date" or see the PP manual ]. The outbound table is keyed by the mta name (derived from the channel table) whereas the inbound table is keyed by presentation address (in the installed tables this is presented in string encoded format, i.e. DCC+.....etc.). However you may use macros to represent presentation addresses in the loc.ch.x400in84 table. Both tables share the same RHS syntax, which is composed of key=value pairs. An entry for the pseudo-host "default" can be used to set default (local) parameters. This entry is created automatically during installation of the JNT PP binary distribution and is set to: *********** 2. Setting up outgoing X.400(88) connections In the JNT binary distribution the ch.x400out88 table is built automatically by combining the local definitions in loc.ch.x400out88 and the NRS derived ch.x400out88.df3. In the UK it is often not necessary to add anything further to the outgoing table. However, you may want to add connection information about local non-NRS registered MTA's or information about sites which cannot be routed through mhs-relay. 2.1 Example X.400(88) outbound channel table Here is a typical fragment of the ch.x400out88 table: # local definitions default:lpass=" ",lmta="UK.CO.XTEL",type=1988 # NRS derived definitions computer-lab.cambridge.ac.uk:rpsap='JanetNS=00828990561577',rpass=" ", rmta="UK.AC.CAMBRIDGE.COMPUTER-LAB" directory.edinburgh.ac.uk:rpsap='"10021"/JanetNS=0150001000005315', rpass=" ",rmta="UK.AC.EDINBURGH.DIRECTORY leicester.ac.uk:rpsap='"10021"/JanetNS=0212901740011588',rpass=" ", rmta="UK.AC.LEICESTER" Note that the above lines have been folded for clarity. 2.2 Adding further connection information To add information about a remote MTA that cannot be reached using the current information in the tables, you will need the following details from the remote site: o The remote address of the MTA - for example 00828991234589 (NSAP) o The transport selector for X.400(88) connections - e.g. 10021 The above information makes up the presentation service access point (PSAP). Using the above example, it would be specified as: rpsap='"10021"/JanetNS=00828991234589' o The remote MTA password - a common one is a single space. o The remote MTA name - for example "UK.CO.ACME-LIMITED" The remote MTA password and MTA name are used in the initiating handshake between your MTA and the remote MTA which gives you authenication to transfer messages to the MTA. The complete entry in ch.x400out88 looks like this: acme-limited.co.uk:rpsap='"10021"/JanetNS=00828991234589',rpass=" ", rmta="UK.CO.ACME-LIMITED" The left hand side of this entry "acme-limited.co.uk" is the locally defined name for the remote MTA. This is the name that is specifed in the OR or domain table's mta field. For example: O$ACME.PRMD$ACME LIMITED.ADMD$MARK400.C$GB:mta acme-limited.co.uk 2.3 Testing outgoing connections The lowest level test is to run the channel itself in a debugging mode. This allows testing of basic connectivity. For example: x400out88 ping -c x40088 -m mta Where "x40088" specifies the channel (as named in the pp tailor file) to use and "mta" is the key of the MTA in the ch.x400out88 table. The result of the command is shown in the x400out88 log. For example the command, x400out88 ping -c x40088 -m leicester.ac.uk may produce the following results in the x400out88 log (some lines folded to improve clarity): 1/27 12:15:35 x40088 18256 (pp ) Connecting (RTS 88 mode) to site leicester.ac.uk 1/27 12:15:35 x40088 18256 (pp ) PSAP is "10021"/JanetNS=0212901740011588 / "597"/JanetNS=0210021900015000| Internet=0.0.0.0|LOCAL-ETHER=0.0.0.0| Janet=000021001029|Int-X25(80)=235110201034 1/27 12:15:36 x400out8 18256 (pp ) connection 6 to 38826110000212901740011588 1/27 12:15:39 x40088 18256 (pp ) Connected Sucessfully 1/27 12:15:40 x400out8 18256 (pp ) connection 6 closed, 304/197 octets sent/recv 1/27 12:15:40 x40088 18256 (pp ) Connection successfully terminated A common error message is: 1/27 12:24:40 x40088 18412 (pp ) rplose (MECH, 'Non authoritative failure, no reference found') 1/27 12:24:40 x40088 18412 (pp ) Can't find connect information for leicester/none 1/27 12:24:40 x40088 18412 (pp ) Connection badly terminated This means that no information about "leicester" can be found in the tables. 3. Setting up incoming X.400(88) connections In the JNT binary distribution the ch.x400in88 table is built automatically by combining the local definitions in loc.ch.x400in88 and the NRS derived ch.x400in88.df3. These are then processed through nsapexpand to remove macros and convert them to DCC+ format. In the UK it is often not necessary to add anything further to the incoming table. However, you may want to add information about local non-NRS registered MTA's or information about other sites that connect to you but are not registered in the NRS and cannot route messages to you through an ADMD. 3.1 Example X.400(88) inbound channel table # local definitions default:lpass=pimms,lmta="UK.CO.XTEL" #NRS derived definitions TELEX+00737346+RFC-1006+03+128.232.0.56:rmta="UK.AC.CAMBRIDGE.COMPUTER-LAB", rpass=" ",rname=computer-lab.cambridge.ac.uk" "10021"/DCC+826+d110000150001000005315:rname="directory.edinburgh.ac.uk", rpass=" ",rmta="UK.AC.EDINBURGH.DIRECTORY" DCC+826+d110000212901740011588:rname="leicester.ac.uk",rpass=" ",rmta="UK.AC.LEICESTER" Note: in the loc.ch.x400in88 table you can use macros rather than the horrible TELEX..... stuff. For example, if leicester.ac.uk was not defined in the NRS then you may have the following in loc.ch.x400in88: "10021"/JanetNS=0212901740011588:rname="leicester.ac.uk",rpass=" ",rmta="UK.AC.LEICESTER" 3.2 Adding further connection information To accept calls from an MTA which is not currently in the ch.x400in88 table you must first of all give your connection information to the remote site if they do not already have it, i.e. o Local MTA name: the lmta field on the default line of ch.x400in88. o The network address and transport selector for your machine / X.400(88) service. o Your MTA's password - the lpass field of the default entry in ch.x400in88. Once the remote site has this information, get them to connect to you. The incoming X.400(88) log file will give you all the information you require for the loc.ch.x400in88 table. For example, 1/27 13:00:48 x400in88 04435 (#67) Starting x40088 (via X400 (1988) (PP-6.0)) 1/27 13:00:49 x400in88 04435 (#67) RT-OPEN.INDICATION: <4, mono, initiator, .. 1/27 13:00:49 x400in88 04435 (#67) ACSE: <4, 2.6.0.1.6, <,,,>, <,,,>, 0> 1/27 13:00:49 x400in88 04435 (#67) PSAP: <4, Internet=128.232.1.80+2594, "592"/Internet=128.232.1.80+102, -1, 2034, 2147479332> 1/27 13:00:49 x400in88 04435 (#67) Connection from key='TELEX+00728722+RFC-1006+03+128.232.1.80' /'Internet=128.232.1.80' mta='freddie' passwd=' '(OCTS) 1/27 13:00:49 x400in88 04435 (#67) No information found in the X.400 incoming tables 1/27 13:00:49 x400in88 04435 (#67) rts_decode_request failed 1/27 13:00:49 x400in88 04435 (#67) Connection aborted This message gives you the PSAP (in macro and expanded form), the remote MTA name and the password, allowing you to place the following information in the incoming loc.ch.x400in88: "592"/Internet=128.232.1.80:rmta=freddie,rpass="",rname="freddie.co.uk" Where "freddie.ac.uk" is the key into the outgoing X.400(88) table. 3.3 TSAPD or IAED ? The inbound X.400(88) channel must be started automatically when an X.400 call is made to the machine. There are two ways of doing this - either by using tsapd or by using iaed (preferred method). 3.3.1 Transport Service Access Point Daemon (TSAPD) method Tsapd is a server daemon which listens for OSI connections to the machine. The transport selector of the incoming call is used to select the appropriate service from the isoservices file. So an entry such as the following should be in isoservices: "tsap/p1" "10021" /usr/local/lib/pp/cmds/chans/x400in88 (This line is installed automatically be the JNT binary distribution). To start up tsapd place the following line in your pp startup script: tsapd -N machines_nsap_address 3.3.2 Isode Application Entity Daemon (IAED) method Like tsapd, iaed is a server daemon which listens for OSI connections to the machine. The difference is that iaed gets it's configuration information from the X.500 Directory Service rather than from the command line or from a static configuration file. To set up iaed you first of all need to set up an entry of object class iSODEApplicationEntity in the Directory. For example, the following entry may be placed below cn=lancaster: cn= xtel-mta objectClass= top & applicationEntity & quipuObject & iSODEApplicationEntity description= An MTA for my site presentationAddress="597"/Internet=128.243.9.1|Janet=00002100102999|IXI=20433450210399 execVector= /xtel/u3/pp/cmds/chans/x400in88 -c x400in88 -n (For further information on adding entries to the Directory, please see the QUIPU manual). Then iaed would be started up as follows from /etc/rc.local: if [ -f /usr/local/etc/iaed ]; then /usr/local/etc/iaed -D 'cn=lancaster' -u '@c=GB@o=X-Tel Services Ltd@cn=lancaster' > /dev/null 2>&1 & fi 3.4 Testing incoming X.400(88) calls You can test that incoming calls are being accepted by pinging your own machine. For example: x400out88 ping -m xtel.co.uk -c x40088 A typical successful ping is as follows: 1/27 12:35:36 x400in88 18656 (#9 ) Starting x40088 (X400 (1988)) 1/27 12:35:36 x400in88 18656 (#9 ) rts_init_1988 () 1/27 12:35:37 x400in88 18656 (#9 ) RT-OPEN.INDICATION: <12, mono, initiator, 0x2ec64> 1/27 12:35:37 x400in88 18656 (#9 ) ACSE: <12, 2.5.4.3, <{ { { 2.5.4.6, "GB" } }, { { 2.5.4.10, "X-Tel Services Ltd" } }, { { 2.5.4.3, "lancaster" }}, { { 2.5.4.3, "xtel-mta" } } },,,>, <,,,>, 0> . . . 1/27 12:35:39 x400in88 18656 (#9 ) parameter_checks( 'UK.CO.XTEL', ' ', 'true') 1/27 12:35:39 x400in88 18656 (#9 ) parameter_checks MTA=UK.CO.XTEL, P= 1/27 12:35:39 x400in88 18656 (#9 ) rts_encode_result 1/27 12:35:39 x400in88 18656 (#9 ) encode Bind Argument successful! 1/27 12:35:39 x400in88 18656 (#9 ) Normal disconnect You should also ask someone at another site to do a test ping to your MTA. --------------------------------------------------------------------------------