SOFTWARE INSTALLATION

Contents

In the beginning and before configuration, the software load module plus the basic execution directory structure used by jnos execution module must be installed. Both sorce code library and precompiled modules are available to the administrator for installation. Clearly, if the precompiled set of options is suitable to the situation, putting up a precompiled jnos aplication on a suitable platform is the easier approach. Do be aware jnos history is that precompiled versions become available less often than source versions.

It is considered "normal" to begin the jnos experience by installing a precompiled system from a developer with his choice of defaults. After some success with jnos it is "normal" to patch the source as needed and compile a more optimised version. Except for the most simplistic off-the-air first attempt with jnos, additional configuration steps are needed to tailor for the site (consider the most basic need for change - use your own legal call, not the default that comes with the software, it can lead to serious trouble).

There are several NOS varients in use, each developed along a unique feature path. System requirements are normally shown for each nos varient by the software creator or distributor. Platform requirements for Jnos2.0 may be found at VE4KLM as an example.

EXAMPLE PLATFORMS

The details described in this section are needed to create a suitable platform. Before studying the detail, it seems appropriate to explore some of the existing platform examples.

DOS is the root of it all. NOS began there and still supports the platform. See: PlatDos page.
Slackware is used by the developer. It is considered one of the best hack platforms Linux has to offer. See PlatSlack page.
Fedora is used by the wiki guy. It is considered industrial strength on the leading edge. See: PlatFc page.
Ubuntu is used by some. It is more bleeding edge development, suited to multimode desktop. See: PlatUbuntu page.
Win is a development issue. Stay tuned for a mature platform. See: PlatWin page.

PRE-COMPILED LINUX INSTALLER

With the advent of jnos2.0d, one installation process was simplified to answering a few scripted questions. The process includes downloading a percompiled version of jnos, followed by executing a script included with the package. SoftInstallerVe4klm yeilds a starter jnos node. It is suitable now for use and refinement within limits by improving only the configuration data.

Others have done similar treatments for software installation. The MI-DRG in Michigan USA has developed a canned package including versions of network specific specific configuration files so the product installation fits nicely into the DRG network. In this case, the load-and-go thinking is modified by email occationally to reload the routing table with network changes, thus a net is maintained by this method. The InstallDrgDos page describes the process of loading software from the standard distribution on a DOS platform.

SOURCE CODE INSTALLATION

When the features require adjustment, or other factors require more customization, the jnos source may be downloaded and modified. In addition, some patches and fixes are distributed in source form much earlier than available in precompiled form.

Installing from source is well explained using generally available unix tools. SoftCompileVe4klm is Maiko's 2.0d instructions. If a considerable amount of experimentation or development is contimplated, use of a IDE (Integrated Development Environment) should be considered to simplify the effort.

Once a compiled load module is created it may be placed as needed for execution upon the next jnos start-up. As in other cases, it is good practice to archive previous versions as a fall-back option. The operating system shows modificatin dates as part of the directory structure, however it is suggested that each site establish it's own naming scheme. Consider naming retired versions as "jnos2.0d.1.a" where "1" are numbers for specific changes, and "a" are letters for the various completed steps in the process, all based on released version "jnos2.0d" determined by Maiko. It is a simple process of (linux version):

[root@host jnos]# mv jnos2 jnos2.0d.1.a
[root@host jnos]# cp (path)/jnos2 jnos2

from the source directory (path).

The InstallSourceDos Page describes the compilation process for the DOS platform.

SERVICES CONFIGURATION

Detail application configuration is done by setting various switches at compile time in the source file config.h that contains the array of configuration flags. Detail discussion and samples are found in ConfigHFile page. Another good practice is to perfect compilation and test the entire procedure including the load module using distributed material exactly before any modification. After the compilation procedure is stable, proceed to adjust the source.

Numerous example config.h files suggest a starting point. The names and description suggest their origin and use in the distribution by Maiko VE4KLM:

config.h - typical jnos2 pre-compiled distributions (may not be exact) at VE4KLM
asyconf.h - another set used by WG7J
distconf.h - This is the configuration as distributed by WG7J
gwconfig.h - the set used for wg7j.ece.orst.edu gateway
bbsconf.h - configuration for wa7tas.or.usa.noam BBS
unixconf.h - n5knx full Linux configuration for Jnos
users.h - an end user configuration suggestion
homeslip.h - home.wg7j.ampr.org site configuration

Again from Maiko's site:

It is suggested that a new owner might initially compile with the distribution config.h if only to validate  development on the host system.  Once the development process is proven, then begin the steps leading to the appropriate options for use on the target install.  It follows that cataloging various versions of config.h is recommended by this author.

And yet again, consider naming config.h versions similar to load module archive naming.

HOST FILE STRUCTURE - name, path, & format

JNOS contains a couple methods for assigning file location. File structure is somewhat dependant on operating system platform and backup and security methods applied to the site. All the jnos files are tabulated in HostFileSystemGlobal. References to various directories and files are found thoughout the wiki where their location and content affect performance.

The first method is applied in FilesCFile prior to compilation and used mostly for highly customized installations. The source distribution containes a file named "files.c" for administrator modification prior to compilation to set new site defaults. Do note that revision distributions require treatment for this file in the same context as any local source patches. It might be useful to compare pervious versions with site versions using tools like "diff" each time a new source distribution is acquired.

The second method is applied in NosCfgFile after compilation at start-up time to override defaults set during compilation. This permits operational adjustment of the defaults for the site and is quite useful when fitting a pre-compiled distribution on to the site. This file can be useful to document the jnos footprint on the computer filesystems if it is updated with comments in step with adjustments to FilesCFile. See the original for detail.

PATCHES TO SOURCE CODE

The objective of this wiki is to document jnos software, of any version. Therefore every user and developer is invited to adjust the content of this wiki where it is appropriate to reflect the on-going development of this software. Places are provided for present and superseded content. Every attempt to describe introduction and retirement of features by revision number is welcome.

Various Internet sources are available for released software and patches. This wiki is an appropriate spot to announce and provide links to all developments, further it is sometimes used to distribute selected patches to releases in the SoftwarePatch page. It is good practice to announce the exact software condition using MotdFile or HelpInfoFile or similar choice visible to the interested user.

WHY THE BINARY IS SO LARGE

Note that my makefile has debugging turned on, so any 'jnos' binary you compile will be large (because it contains debuggin info). If you are not at all interested in debugging, then you can reduce the size of the 'jnos' binary using the following command :
    strip jnos
which will strip out the debugging information and symbol table.

Many circumstances are better served with debugging information, so strip with care...

For DOS Binaries

Maybe you have too much compiled in? Jnos has many many features, most of which do not apply to your particular station. Some experimentation with the config.h may be in order. For the first step, if you don't recognize a particular server or protocol, try removing it! Some places to watch out for are the servers. Do you need NNTP? Do you need a POP3 server? Do you need the ability to attach SCC cards and the like? Remove it!

HARDWARE

OK - you are about to turn on and get ready for packet radio communication. Not much is said here about the hardware that is assembled for the task. There are a few things that are worth just a little conversation. IF and when one of these rears it's ugly head, it will take your attention off Jnos until it gets fixed...

Grounding

A good ground helps protect life limb and happiness. It does not solve all the issues though. While a radio user may pick up a mic and be quite successful at voice communication, digital equipment is less tolerant of stray RF and it may complain under the same conditions that voice was fine. It may even change the outcome of communication, like what 30-meter RF does to my keyboard. The source of trouble is not radiated from the antenna, it is coming back from the ground. Balanced systems (dipole?) are much easier to manage than asymetrical systems (long wire) for example.

In extreme cases, you may even damage your computer hardware with a poor ground. Many serial ports over the years have been killed by RF seeking it's way from the radio up the serial line. Plus, if your station is to be left unattended, do you really want the unpredictability stray R.F. can cause?

Tuning

While VHF FM tuning simply requires being close to frequency and keeping the modulation level in a small band, HF SSB tuning adds several more complications. Because a frequency variation will cause a tone shift, the use of an analysis tool makes tuning easier, try a "waterfall" display. Deeper than that, some TNCs may be set for the tone pairs and two users may both be successful with different tuning formulas. So perhaps take what is heard with a grain of salt?