USER of ADVANCED & ADMINISTRATIVE FEATURES
This section is devoted to the OWNER (administrative operator) of the site. The sysop starts, controls progress, adjusts characteristics, and terminates jnos sessions. Management of drive space (content), review of logs, analysis of traces, and directing change for users, is the purview of the administrative user. This Manual contains the commands and their descriptions for using and operating a JNOS tcp/ip and ax.25 packet switch, BBS, and network node. Also contained in this manual is information about the FORWARD.BBS, REWRITE, ALIAS, and USERS files used in a JNOS installation.
STARTING JNOS
Jnos operates as one of many tasks on a Linux platform and may be started automatically at boot time (a deamon) or manually. The present design dictates jnos have root privileges, thus the root user starts jnos, or jnos may be started under sudo root by a non-root user. On a DOS platform, jnos is the only task that matters. More precisely, as a single-user platform DOS permits other tasks than jnos while jnos is not running, and permits jnos to begin other tasks while it is running.
Site considerations will dictate the details of starting jnos. A section in HostConfiguration is dedicated to setting that detail. In most cases the sysop user has the ability to adjust CommandLineParms and EnvironmentVars for changes in circumstances.
BE CAREFUL !!! THE NEXT COMMANDS WILL CAUSE THE DXP OR SCS TO START SWITCHING YOUR HF RADIO TRANSMIT ON AND OFF AT REGULAR INTERVALS. IN OTHER WORDS, MAKE SURE YOU HAVE YOUR HF EQUIPMENT SETUP PROPERLY. I'M NOT TO BLAME FOR DAMAGE CAUSED BY YOU FAILING TO FOLLOW PROPER PROCEDURES FOR SETTING UP YOUR HF EQUIPMENT. YOU HAVE BEEN WARNED !!! ALSO, BECAUSE THIS IS EXPERIMENTAL, I DISCOURAGE UNATTENDED FORWARDS ![tbd]
Starting Automatically
On a multi-user platform numerous approaches are available to start jnos at boot time. Should jnos crash it can be automatically restarted. AutoStartJnos treats this subject in detail, but one determining factor for using some approaches is that the sysop console is not immediately available. The console may be reached with the extra steps of establishing a telnet session followed by the @ command and sysop password.
On the DOS platform, one method will start jnos automatically at boot time. Automatic starting under DOS is detailed in AutoexecNosFile.
Starting Manually
On the linux platform it is typical to use one multi-session console to start jnos and serve as the status display for the sysop. It is a favorite of this author to set variables and parameters into a scipt in /root/bin directory so that jnos may be started with the simple command:
...# jn
Once started, the sysop has the option of using another multi-console to telnet open a bbs session.
The most basic of description of the start up process is: operating as user “root”, change directory to the installed root jnos directory (typically /jnos). As administrator, you might take this moment to check file conditions and perform some of the routine stuff. Then issue the command:
...# jnos -d /jnos
where jnos is the executable, -d specifies the root directory, and further choice of parameters will vary.
Manually starting on a DOS platform requires [tbd].
CONSOLE: STATUS DISPLAY
The number of status lines displayed can be set with the '-uX' commands line option. A '-u0' turns it off. Default is '-u3'. JNOS now has a (up to) 3-line status display which shows:
- On the first line: time of day, heap and core free memory, number of connections to the active servers. Then a list of active sessions, where sessions with data waiting are blinking.
- The 2nd line shows: the users connected to the bbs. {Eg: BBS: *w0rli johan #ka7ehk !n7ifj} A prefixed status symbol in front of each user shows one of the following:
prefix
user is
none
idle
*
a bbs
@
in sysop mode
!
gatewayed out
#
reading or sending mail
=
transferring data (up/download)
^
in convers or sysop-chat mode
?
in none of the above, but not idle...
- On the 3rd line is: data depending on the current sysop session. Always displayed are the current session number and type.
- If the sessions are network connections, displayed are remote connection name, tx-queue (bytes for tcp, packets for ax.25), and state of the connection. It then shows the retry timer, with current time left, and initial value.
- In 'repeat', 'more' or 'look' sessions, the 3rd line show the command, filename or user/socket for the session.
NOTE: if tracing is enabled, this will 'bleed' through the status window. This is NOT a bug, but is inherent to the way tracing works in JNOS. (It would take a major rewrite to fix.) The status window is rebuilt about twice a second to overcome this.
SYSOP COMMAND LANGUAGE
Sysop commands are entered on the sysop console and/or are input in scripts. Scripts are used for initialization and termination of jnos, plus may be involked by the source command. The complete command set available to the Sysop is found on SysopCommands page in detail and also briefly on SysopCrib page intended for use as a reminder after printing.
Command abbreviation is supported, for example: "ax25" and "ax" produce the same result. All commands and many subcommands may be abbreviated. You only need type enough of a command's name to distinguish it from others that begin with the same series of letters. Parameters, however, must be typed in full. It is good form to not abbreviate in scripts, but to use it during keyboard entry. Be advised: abbreviation can lead to ambiguity when a full knowledge of the vocabulary is not remembered. You are warned...
Some commands may not be available depending on administrator choice at compile time. Here is a portion of a command table for access to command syntax detail for often used word commands:
|
|||||||||
Some commands initiate an independant concurent process called a "session". The session establishes it's own display screen and is the I/O display while it is processing, then it is removed when the session terminates and the original screen is restored. The session may be escaped from by the <F10> key, then returned to at a later time by the session command. Commands like help, ftp, convers, and finger, are examples of such commands. The console status display line #1shows the list of sessions active at the moment.
ROUTINE ACTIVITIES
Certain configuration data and admin tasks are required for a jnos site. There are also some advanced user features available only to privileged sysop users. Once the host is prepared and jnos is installed as described exsewhere, then configuration and user management becomes a focus.
Monitor System Status
As a suggestion, develop a habit of reviewing operation with helper scripts. The jnos_stat-1 contains many commands well suited to showing the sysop how things are going. As an experiment, invoke the jnos_stat-1 as a script with one (or both) of the commands:
...> source jnos_stat-1 ...> source jnos_stat-1 > jnos_stat.txt
Now I expect you will find this particular script is not applicable because it produces too much output. If you redirect the output to a file for inspection at a later moment, some "echo" commands need to be added to aid readability. By creating selected scripts, and perhaps executing them using the "at" command periodically, a sysop may develop a feel for operation suitability.
Monitoring status leads into optimization and troubleshooting activities described at various places on this wiki. Here are some ways to measure the health of the jnos application from the console. Good health is demonstrated for jnos when:
COMMAND |
REPLY |
PRIORITY |
ax25 status |
seldom shows status "recovery" and often 0 queues |
high |
tcp view |
shows active links with low retry/receive & retry/send ratios |
high |
netrom status |
seldom shows "reconnect" and often 0 queues |
medium |
conv link |
status connected and TXqueue 0 |
medium |
mbox status |
users of the BBS server (abbreviated list on sysop term line 2) |
low |
Initiate mail and file transfers
While much email transfer activity may be fully automated, some mail and all file transfer remains manual. Automatic transfers do not honor courteous RF channel use so full automation is not probably wise. Also, some sites simply do not want automated stations to access them.
SMTP & POP over TCP/IP
Sending mail from a jnos BBS session or from a mail reader on a LAN to a remote jnos node initiates an automatic SMTP transfer process. Similarly using POP to poll for existence of mail and pulling it in. As long as the TCP/IP network can establish an end-to-end link the transfer will happen. When the transfer can not complete, the protocols may try again later. And yes, these protocols may be "kicked" to initiate them manually.
AX.25 Mail forwarding
There is no natural event like "send" to initiate mail transfer via AX.25 network similar to SMTP. Transfer can be automated by timer, and initiated manually to push out mail with a mailbox-to-mailbox transfer to a specific target BBS (if you find messages or bulletins waiting to be sent to the remote station). Forward simply with something like this:
...> mbox kick wu3v
If you have no traffic to forward TO a remote BBS station, but you want to find out if there is any mail to pull in from a remote BBS, then initiate a reverse forward (to pick up anything from THEM) by this:
...> mbox kick Vo1xc
Note : the first letter is CAPITALIZED in the callsign. When the first character of the remote station is capitalized, jnos reverses the forwarding process.
Believe it or not, that's all there is to it! Note : It is good operating practice to stay away from the generic 'mbox kick' and instead kicks only to individual stations (for the HF forwarding especially).
For winlink Mail forwarding
[Feb 2008] Mail forwarding is no longer available at this time because WinLink requires B2F protocol [not a jonos option] rather than offering it as an optional protocol. Watch the NOS forum for developments in restoring this feature.
Email may be forwarded to and retrieved from WinLink network VHF telpac nodes and HF nodes when propagation permits. The process is a variation on the AX.25 transfer above. While much of email transport is fully automated, exchange with WinLink sites remains manual. See the tutorial WinLink2kMail for useage. Reminder: WinLink is a popular high-volume service so please limit any experimentation.
File transfers via FTP
When FTP server is configured, file transfers in and out is a normal method for system maintenance. Moving data of interest to the local community is a possibility using the techniques that follow. [tbd]
User passwords and permissions
New users post personal ID information into UsersDatFile when they are not recognised during the login process. At that time default permissions are inserted into the user information entry. The UsersDatFile may need editing to remove typo errors at login and other errors in useage. A useful tool for reviewing this file is:
... spool]# mv users.dat users.dat.old ; sort users.dat.old > users.dat
while jnos is not active (adapt this unix command to fit DOS as needed).
The roll of the sysop is to revise the the permission scheme to satisfy site needs by revising the FtpusersFile and PopusersFile content. Each user is defined on one line, the sysop might choose to revise, delete, or insert new lines.
Watching the log and trace data
Be warned, the JNOS log will get filled up with the HF stuff. It's there on purpose to help me see how things are running. If you run into problems, try and explain them to me as detailed as possible, and include the JNOS log for me to analyze. Another hint while you are forwarding with a remote station (AFTER you connect to them, or they have connected to you through the HF server), you can use the command, 'look <callsign>', from the sysop (F10) console, and actually follow the entire FBB forward session as it moves along. This is a great way to learn the FBB protocol. Sometimes this information can be helpful to me as well. This is far from perfect, but I'm quite happy with the progress so far. That's it for now. Have fun, let me know what you think, feedback is very welcome. I don't care if it's good, bad, or ugly, or critical of design, or whatever. It won't get better if people don't bother telling me what the issues are.
Trace data management
There are a lot of personal preference and physical space constraints behind this issue. Need-to-know drives the selection of trace setup. ./trace is the default destination directory intended for storage of trace data, and user familiarity with platform utilities and search tools aids in where-to-find the information contained in the trace files.
For the purposes of this manual, it is suggested to trace the minimum data consistent with need-to-know, and place review on a calendar to manage file size and space available. Files that are too large become a burden to analyse so begin tracing into new files as tools dictate. Drive space can become a premium so delete old stuff where digging into performance history is no longer feasible.
TROUBLESHOOTING STRATAGY
The objective of this section is to suggest approaches to troubleshooting or debugging the installation. Troubleshooting differs in priority from optimization but both activities are the perview of the sysop.
- For instantiation or initialization and termination of the software, [tbd]
- For radio links, trouble may present as total failure to communicate or with a high level of re-tries or status similar to "recovery". Once reliable communication with the partner(s) is obtained by watching status feedback then these parameters may be tuned by using optimization techniques. It is also well to watch non-partner stations to help avoid QRM by mistakes of others.
- Check received audio: clarity, level, noise, in the case of HV tuned on frequency. Start at the radio audio on both ends of the link to obtain clear signal, with FM for example "full quieting".
Check TNC demodulator using the CALIBRATE command. The preferred signal detection "CD" parameter is SOFTWARE and requires equalization and no squelch to be correct. Please see John Ackermann's (N8UR) fine paper on: Let's Not Forget Layer One!`
http://www.febo.com/packet/layer-one- Check the optimization parameters and set them generously. Set tunable parameters arbitrarily high or conservative.
- For LAN interfaces, [tbd]
- For Internet interface beyond a bridge router, [tbd]
What to do about crashing
Jnos 2.0e is remarkably stable, and has demonstrated continuous operation for months at a time. Other versions are also stable, but application crashing does happen. As sysop, each crash must be treated during the restarting process. For sysops wanting to help the developers de-bug the application VE4KLM has established a BugFixHelp protocol. Minimal effort simply requires rebooting the application to restart jnos.