Home
Latest News
Downloads
Repositories

Docs
Quick guide
Wiki
Npemwin manual
Article for Geo Quarterly
Live
Nbsp Live
Npemwin Live
Npstats Live
Signal Monitor
Related Sites
OpenNoaaport
iNoaaport
| Pool
iEmwin | Pool

Support
Problem reports
Group
Contact


Configuration

The configuration of the nbspd daemon is controlled by the file /usr/local/etc/nbsp/nbspd.conf and several other files in that same directory. Most of the optional features such as the processing filters, the web server and the emwin werver can be enabled or disabled individually simply by appropriate settings in the /usr/local/etc/nbsp/features.conf. The explanations given below are mostly for reference.

The program also accepts a few command line options, which are documented in ``man nbspd'' page, but they are intended to be used for debugging purposes and their use is not supported. For example, an alternate configuration file can be used by passing its location with the [-c configfile] switch. Also, if invoked with the [-C] switch, the program will just write the compiled-in default values of all the parameters and exit. While these alternatives can be used for particular purposes, their use in production installations is not recommended and not supported. This manual explains the use of the configuration file.

While there are quite a few options, all of them have default values so that the program can run even without the configuration file. In the sample configuration file provided, all those options are commented out, and all include a comment of what they mean. The value shown in the file is the default value compiled-in. Many of the options need not be changed at all, except for fine-tunning the performance of the program in special situations. The rest of these instructions explains the most common options in the configuration file.

Basic

In the minimal configuration, the program assembles and decodes the noaaport data fragments and stores them in the spool directory. As already explained, that is all. The first step to modify this behaviour is to make a copy of the sample configuration file and name it ``/usr/local/etc/nbsp/nbspd.conf''.

The language used by the configuration file is tcl. Any language construct can be used to fully exploit its power, but the elementary instruction for modifying an option is to set a variable to some value. Some examples and explanations follow.

Most of the other useful options have to do with enabling either the server module and/or the filter module, which we start to dicsuss next.

Emwin compatible

Configuring nbsp to run in emwin-compatible mode is simple because it has been designed keeping in mind that capability. In essence, only one configuration variable must be set in the configuration file, and some directories and files must be created. Specifically the steps are the following:

With this configuration, nbsp will do two things, in addition to the default operation of storing the received files in the spool directory. On one hand, setting the variable servertype to a non-zero value enables the server, and the particular value 4 indicates that it should transmit to those clients the files in emwin-compatible format. The variable servertype can take other values, which are described in the master-slave configuration section. The listening port is 1000 by default, but that can be configured by setting the variable serverport. The servertype variable can be set to other values to enable other protocols for the transmissions, in place or in addition to the emwin-like transmissions.

On the other hand, the presence of the emwin ``rc'' files enables the required filters, which take the original text, satellite and optionally the radar files from the spool directories, massage them and save them in the txt, sat and rad directories in a format ready for trasmission. The satellite images are saved as png and jpg files, the radar images as gif files, which can be viewed by any web browser and many image manipulation programs, while the text files are just plain text. The satellite images are transmitted as jpg files. In more advanced configurations of the server machine, these directories can be exported to other machines by NFS or samba.

Gempak compatible

In addition to, or instead of, the emwin-like server, the system can be configured to process the files and save them in a directory tree and file format as gempak expects them. There are several possible ways to set this up. For example, in our own setup, nbsp on one hand, and gempak on the other, are installed in two different computers. These more advanced configurations are not covered in these notes. The instructions that follow describe the installation of gempak in the same nbsp computer.

The gempak software must have been installed. Actually, to process the text and generate satellite images the gempak software is not needed; nbsp processes those files itself. But to process other types of data files, and to generate radar images and satellite images with maps, it depends on the gempak decoders being installed.

The simplest way to install Gempak is to use the gpak package which is available in this site. It will install and configure Gempak using the native package management tools of the host operating system, which permits making upgrades straightforwardly. If Gempak is installed in this way, it only remains to enable the Gempak filter. For that, the variable feature(gempakfilter) must be set in the features.conf file in the nbsp configuration directory. No further configuration steps are required.

The remainder of these instructions are for those that prefer to install Gempak manually rather then through the gpak package.

If gempak is installed in

/home/gempak/NAWIPS
then the programs live in the directory
/home/gempak/NAWIPS/os/OS/bin
where OS stands for the operating system name of the computer; i.e., linux or freebsd. If gempak is installed in a different directory (e.g., /home/gempak/GEMPAK5.9.1), then the most convenient option is to make a link inside the /home/gempak directory:
cd /home/gempak
ln -s GEMPAK5.9.1 NAWIPS
The decoders sometimes need data files that live in some other directories, such as
/home/gempak/NAWIPS/gempak/{data,tables,...}
The rest of these instructions assume that the gempak installation looks as above.

In the nbsp side, the gempak filter must be enabled. This is achieved by setting the variable feature(gempakfilter) in the features.conf file. Furthermore, the variables gempak(homedir) and gempak(bindir) in the file filters.conf must be redefined appropriately (e.g., by changing /usr/local/lib to /home). The following files in the configuration directory /usr/local/etc/nbsp are also required:

Sample files for all these already exist in that directory, and it is not necessary to edit them, nor to modify the main configuration file nbspd.conf in any way, unless the default setting are not suitable. The default settings are such that the gempak data files are saved in the directory
/var/noaaport/data/gempak
and in the end it will be populated with the subdirectories such as
/var/noaaport/data/gempak/{images,model,nexrad,nwx,...}

In order to view the data using gempak in the same computer, the final step is to let the gempak viewers know where the data files have been saved. This can be done again in several ways. Two possibilities are:

As already mentioned, other configurations are possible, including those in which the gempak software is installed in one computer while nbsp and the the data files are stored in a different computer. In such cases, the data directory is exported/imported from one to the other by some means; e.g., NFS.

Digatmos compatible

The files can be saved in a form that they can be used (imported/loaded) by the Digital Atmosphere (DA) program. DA runs on windows, so this setup involves configuring the noaport server to export the data directory via samba. Two steps are involved: (1) the dafilter must be installed, and (2) samba must be configured. The installation of the dafilter is discussed in the Filters section. The complete instruction for configuring a samba server is beyond the scope of these notes. We only mention that the relevant portion of the samba configuration file smb.conf must contain an entry such as

[noaaport]
   comment = nbsp digital atmosphere interface
   path = /var/noaaport/data/digatmos
   public = yes
where ``/var/noaaport/data/digatmos'' is the directory in the server where the dafilter will save the files in the DA format.

Web compatible

nbsp can save the files in a format such that they can be readily displayed by web browsers. This is accomplished by the installation and activation of the rstfilter. The instructions for the rstfilter are given in the Filters section.

nbsp has a built-in web server, enabled by default, which listens on port 8015. It's main purpose is to display some statistics that nbsp keeps about its internal status, but by default it also serves the text, radar and satellite images, created by the rstfilter mentioned above, without any further configuration. It is of course possible to use also an external web server.

News compatible

nbsp can distribute the received files by nntp. This is accomplished by enabling one or both of two filters. The nntpfilter sends the raw data files, as they are received from the noaaport data stream, while the rstnntpfilter send the postprocessed text, radar ans satellite images. This capability requires the installation and configuration of a news (nntp) server software. Our reference system for a news gateway is inn, which is well-tested and robust.

The full details of the configuration of the news server is outside the scope of this guide. However, an nbsp-news working configuration can be setup by installing the nbsp-news package which is available from the software section of our site. More information about the setup is also given in the Projects section. The explanations given below are kept here for reference purposes, but they are all the necessary steps are taken by the nbsp-news package installation.

Assuming that the new server has been installed and configured to received posting from the local machine, all that is required to enable the nntp gateway is to install one or both of the relevant filters. The nntpfilter is installed by including it in the filterlist variable in the nbspd.conf configuration file and installing is associated rc file nntpfilter.rc. This filter will distribute the raw data files as they are saved in the nbsp spool directory. The nntp distribution of the text files, as well as the radar and satellite images is enabled by setting the variable rstnntpfilter_enable in the rstfilter.conf configuration file.

LDM compatible

nbsp can insert the received files in an ldm queue, allowing further distribution and/or processing of the files by an ldm process in the usual way (via a properly configured pqact.conf). This is accomplished by enabling the ldmfilter in the nbspd.conf file in nbsp. In addition, it requires that a small program nbsp2ldm be installed.

The installation of nbsp2ldm is simple. If nbsp is installed from a package (rpm or tbz), there will be a file nbsp2ldm.tgz in the nbsp documentation directory that contains the required file and instructions for building and installing the nbsp2ldm program.

PAN compatible

The ``PAN'' (Product Arrival Notification) server (a term borrowed from the Unisys prodman manual) is one mechanism for notifying another computer or computers when a particular file is received. This allows a setup in which one or several computers wait for a message indicating that a particular product file has been received and saved in the spool directory by nbsp, so they can go and get it for further special processing. The nbsp computer can export by NFS, http or other means the spool directory, and the client computers can read just the file or request it by http or whatever have been set up.

In nbsp the PAN server is implemented using the panfilter, and the notification is a UDP transmission. The panfilter has an rc file panfilter.rc where the rules for deciding what files to send and to whom are defined. When a given file is received and it matches a rule, the panfilter sends the client computer(s) a message containing the wmo header, the awips id if it is in the file, and the name of the file. With that information the client computer can construct the appropriate path or url to get the file and do what it wants with it.

The file panfilter.rc-ex in the distribution contains detailed explanations and examples, and the files ``nbspudpread.pl'' and ``nbspudpread.tcl'' (in the nbsp documentation directory ``/usr/local/share/doc'') are two simple udp reader examples.

RSS compatible

RSS feeds for the text files are generated by the rssfilter. It is enabled in the default package installation. It is template-based, and the templates and other options can be set in that filter's configuration files.

The feeds are accessible from the built-in web server interface.

Master-Slave configuration

nbsp can run in three modes: standalone, master and slave. A slave can in turn act as a master to other slaves. Everything that is described elsewhere in this manual assumes that nbsp is running in standalone mode. In this mode, reading from noaaport and processing the files takes place in the same computer. The alternative to this is a master-slave setup, involving two computers, and it is described here. In this setup, reading from noaaport is done by the master computer, and processing is done by the slave.

Master setup

There is no special setup to configure nbsp in master mode, but it must be allowed to receive connection requests from the slaves. For this the configuration file features.conf must contain the setting

set feature(nbs1server) 1

If it is dedired to delegate all the processing to the slave computer(s), then in the file nbspd.conf

set filterlist ""
can be set in order to disable all the filters.

Slave setup

Setting up the slave requires the following directives in the configuration file:

set feedmode 2
set mastername "mastername.domainname"
where mastername.domainname should be replaced with the correct name of the master computer.

There are a few other variables that control the behaviour of the slave. They have have reasonable default values, but they can be modified in the configuration file if desired, as explained in the sample configuration file provided with this documentation.