.TH ISODE-GEN 8 "09 Mar 1991"
.\" $Header: /f/osi/RCS/isode-gen.8,v 7.33 91/03/09 11:54:14 mrose Exp $
.\" $Log: isode-gen.8,v $
.\" Revision 7.33 91/03/09 11:54:14 mrose
.\" Revision 7.32 91/02/22 09:13:50 mrose
.\" Revision 7.30 91/02/12 18:28:11 mrose
.\" Revision 7.29 91/01/15 09:30:07 mrose
.\" Revision 7.28 90/12/11 10:32:45 mrose
.\" Revision 7.27 90/11/21 11:29:24 mrose
.\" Revision 7.26 90/11/11 10:48:00 mrose
.\" Revision 7.25 90/10/31 12:53:33 mrose
.\" Revision 7.24 90/10/30 14:32:48 mrose
.\" Revision 7.23 90/10/23 20:38:37 mrose
.\" Revision 7.22 90/09/10 09:57:47 mrose
.\" Revision 7.21 90/07/27 08:52:25 mrose
.\" Revision 7.20 90/07/27 08:49:45 mrose
.\" Revision 7.19 90/07/09 14:42:51 mrose
.\" Revision 7.18 90/07/09 14:30:14 mrose
.\" Revision 7.17 90/04/18 10:23:25 mrose
.\" Revision 7.16 90/04/18 08:52:33 mrose
.\" Revision 7.15 90/04/09 08:49:53 mrose
.\" Revision 7.14 90/03/05 23:04:15 mrose
.\" Revision 7.13 90/02/19 13:07:36 mrose
.\" Revision 7.12 90/01/27 10:27:48 mrose
.\" Revision 7.11 90/01/11 19:35:47 mrose
.\" Revision 7.10 90/01/11 18:33:48 mrose
.\" Revision 7.9 89/12/19 23:40:40 mrose
.\" Revision 7.8 89/12/19 23:37:41 mrose
.\" Revision 7.7 89/12/19 23:36:12 mrose
.\" Revision 7.6 89/12/19 23:34:33 mrose
.\" Revision 7.5 89/12/19 23:32:22 mrose
.\" Revision 7.4 89/12/19 09:52:43 mrose
.\" Revision 7.3 89/12/04 18:18:09 mrose
.\" Revision 7.2 89/11/30 23:50:49 mrose
.\" Revision 7.1 89/11/24 13:33:10 mrose
.\" Revision 7.0 89/11/23 21:21:30 mrose
isode\-gen \- generating the ISO Development Environment
This documentation describes how to configure, generate, and install the
ISO Development Environment.
Acquisition, use, and distribution of this module and related
materials are subject to the restrictions of a license agreement.
Consult the Preface in the \fIUser's Manual\fR for the full terms of this
You will probably want to read over this entire document first,
before typing any commands;
e.g., there are optional components described later on that require
additional settings in the configuration file.
Comments concerning this release should be directed to the mailbox
\*(lqBug\-ISODE@NISC.PSI.NET\*(rq.
Do \fBnot\fR send bug reports to the ISODE discussion group.
If you want to subscribe to the ISODE discussion group,
drop a note to \*(lqISODE-Request@NIC.DDN.MIL\*(rq.
% cp config/\fIsystem\fR.h h/config.h
% cp config/\fIsystem\fR.make config/CONFIG.make
% cp config/*.local support/
# ./make inst\-everything
This is a description of how one can bring up the ISODE.
It is assumed that you have super\-user privileges in order to (re\-)install
Super\-user privileges are not required to configure or generate this
The distribution tape contains the hierarchy for the \fB\*(VD\fR directory.
Bring the sources on\-line by changing to a directory for local sources and
First, go to the \fBconfig/\fR directory.
Select the Makefile and include-file skeletons which most closely match
\fIfile\fR \fIconfiguration\fR
bsd42 generic 4.2BSD UNIX
bsd43 generic 4.3BSD UNIX
bsd43\-rt RT/PC with 4.3BSD
bsd44 4.4BSD UNIX with OSI
ros Ridge Operating System
sunlink3 SunOS release 3 with SunLink OSI/X.25 release 5.2
sunlink4 SunOS release 4 with SunLink OSI/X.25 release 6.0
sunlink7 SunOS release 4 with SunNet OSI/X.25 release 7.0
sys52\-exos SVR2 UNIX with EXOS
sys52\-sun SVR2 UNIX emulation on SunOS release 3
sys52\-win SVR2 UNIX with WIN/TCP
The makefile skeleton has the extension \fB.make\fR,
whereas the include\-file skeleton has the extension \fB.h\fR.
Copy the makefile skeleton of your choice to \fBpickle.make\fR,
where \*(lqpickle\*(rq is the name of your system.
Now edit this file to set the following \fImake\fR variables:
.ta \w'MANOPTS 'u +\w'/usr/include/isode/ 'u
\fIvariable\fR \fIdefault\fR \fIspecifies\fR
OPTIONS options to \fIcc\fR and \fIlint\fR (e.g., -I../h)
LSOCKET libraries to link in (e.g., -lcci)
BINDIR /usr/local/bin/ where to install user programs
SBINDIR /usr/etc/ where to install administrator
ETCDIR /usr/etc/ where to install administrator files
LOGDIR /usr/tmp/ where to install log files
INCDIR /usr/include/isode/ where to install include files
LIBDIR /usr/lib/ where to install object libraries
LINTDIR /usr/lib/lint/ where to install lint libraries
SYSTEM directs how to create loader libraries
MANDIR /usr/man/ where to install man pages
MANOPTS see compat/inst-man.sh for details
\fBNOTE THAT ALL THESE DIRECTORIES MUST BE ABSOLUTE PATH NAMES
(i.e., start and end with a `/')\fR.
ln pickle.make CONFIG.make
(yes, that's \*(lqCONFIG\*(rq in uppercase and \*(lqmake\*(rq in lowercase).
Both of these files are in the \fB\*(VDconfig/\fR directory.
This latter file is the one which the software uses to configure itself
Copy the include\-file skeleton of your choice to \fBpickle.h\fR,
where \*(lqpickle\*(rq is the name of your system.
Now add any additional definitions you like (usually none).
Consult the file \fBconfig/OPTIONS\fR for a list.
ln pickle.h ../h/config.h
This latter file is the one which the software uses to configure itself
sites run with the default aliases database used
simply copy the default local configuration file to the \fBsupport/\fR
% cp aliases.local ../support/
If you have local modifications you wish to make,
either copy in your own file or edit the file
\fBsupport/aliases.local\fR as appropriate.
sites run with the default services database.
simply copy the default local configuration file to the \fBsupport/\fR
% cp services.local ../support/
If you have local modifications you wish to make,
either copy in your own file or edit the file
\fBsupport/services.local\fR as appropriate.
sites run with the default application entity database used
by the stub\-directory service.
sites should use the OSI Directory to keep track of application entities.
simply copy the default local configuration file to the \fBsupport/\fR
% cp entities.local ../support/
If you have local modifications you wish to make,
either copy in your own file or edit the file
\fBsupport/entities.local\fR as appropriate.
if you are using SunNet OSI,
it will be necessary to put an entry in your
\fBsupport/entities.local\fR file of the form:
myhost\0default\0\01.17.4.1.0\0\0#1/NS+mynsap
where \*(lqmyhost\*(rq is the name of the local machine,
and \*(lqmynsap\*(rq is the NSAP of the local machine.
For SunNet OSI 7.0 the NSAP is most easily determined by running
% /usr/sunlink/osi/etc/osirstat -n | grep ^DA
provided that the SunNet OSI osi.routed program is running. For
earlier SunLink OSI releases you can run
% xosilookup localhost CLIENT
providing that the SunLink OSI file \fB/etc/sunlink/osi/hosts\fR
has an entry defining the service for \*(lqlocalhost\*(rq called
(Note that in releases earlier than SunLink OSI 6.0,
the file is called \fB/usr/etc/osi.hosts\fR)
Note that this entry is mandatory if you are running SunLink OSI
One further note for users of a release earlier then 7.0 of SunLink OSI:
if you intend to run the standard SunLink OSI listener (osi.netd),
then you must change the TSEL used by \fItsapd\fR when it listens.
This is done in two steps:
in \fBsupport/entities.local\fR,
change your entry to read as:
myhost\0default\0\01.17.4.1.0\0\0#2/NS+mynsap
in \fBsupport/services.local\fR,
add a line that reads as:
tsap/session\0\0#2\0\0tsapd-bootstrap
which overrides the default TSEL in the \fBsupport/services.db\fR file.
Typically, sites run with the default macros database.
simply copy the default local configuration file to the \fBsupport/\fR
% cp macros.local ../support/
If you have local modifications you wish to make,
either copy in your own file or edit the file
\fBsupport/macros.local\fR as appropriate.
Typically, sites run with the default objects database.
simply copy the default local configuration file to the \fBsupport/\fR
% cp objects.local ../support/
If you have local modifications you wish to make,
either copy in your own file or edit the file
\fBsupport/objects.local\fR as appropriate.
Go to the \fB\*(VD\fR directory
Now reset the dates of the
configuration files for the system.
This is done only once per source-tree:
then generate the basic system.
do not use the \fImake\fR program supplied with the SunPro package.
It is not, contrary to any claims, compatible with the standard
note that if you are running a version of SunOS 4.0 prior to release 4.0.3,
then you may need to use the \fImake\fR program found in \fB/usr/old/\fR,
if the standard \fImake\fR your are using is the SunPro \fImake\fR.
you will need to put the old, standard \fImake\fR in \fB/usr/bin/\fR,
and you can keep the SunPro \fImake\fR in \fB/bin/\fR.
then you will probably have to type this command before starting the
you may need to increase the stacksize limitation on other systems.
some users of the RT, report needing to use
in order to get FTAM to fully compile.
The \fImake\fR command from the top-level directory
will cause a complete generation of the system.
If all goes well, proceed with the installation.
If not, complain, as there \*(lqshould be no problems\*(rq at this step.
Some files while compiling may produce a
warning: statement not reached
type ObjectDescriptor: Warning: Can't find file DSE.ph failed
Sometimes when building a loader library, you might see several
ranlib: warning: ../libisode.a(aetdbm.o): no symbol table
You might also see a few messages like:
*** Error code 1 (ignored)
As a rule, unless \fImake\fR says something like
then everything is going just fine!
Some directories may have a resident test program,
e.g., in the \fBpsap/\fR directory, there is a program called \fIpsaptest\fR.
These programs are for internal testing only,
and are not for use by \*(lqmere mortals\*(rq.
If you want to test things,
after installation run \fIisode\-test\fR (see the \fBUSER PROGRAMS\fR section).
You will need to be the super\-user to install the software.
Note that installing the software from an NFS-mounted partition
requires that you perform the installation as the super-user on the
\fItarget\fR system after changing to the source directory on the
In the directions that follow,
reference is made to some of the directories defined in the
You should substitute in the correct value,
and if SBINDIR is defined as \fB/usr/etc/\fR in the \fBCONFIG.make\fR
There are two kinds of activities:
once\-only activities that you perform the first time the software is
and each\-time activities that you perform every time the software is
The first once\-only activity is to verify that the \fItsapd\fR daemon will be
run when the machine goes multi\-user.
On Berkeley UNIX systems, add these lines to the \fB/etc/rc.local\fR file:
if [ \-f $(SBINDIR)tsapd ]; then
$(SBINDIR)tsapd & (echo \-n ' tsap') > /dev/console
On other systems, a similar procedure is followed.
on systems derived from AT&T UNIX,
the file \fB/etc/rc2\fR script might be edited.
Once you are familiar with the system,
you will likely want to run the OSI Directory and use another program,
\fIiaed\fR to invoke local services.
The section \fBDIRECTORY SERVICES\fR discusses this in greater detail.
if this is your first time,
The next once\-only activity is to verify that systems with a native
\fB/etc/services\fR file contain an entry for the tsap service
(if you have configured the ISODE to run over TCP).
to the \fB/etc/services\fR file.
If your system does not have such a file,
the software automatically compensates for this.
on Berkeley UNIX systems,
add a line to the \fB/usr/lib/crontab\fR file to invoke a
shell-script that will re-cycle the log files.
Usually, the line you add looks something like this:
0 4 * * * su daemon < $(SBINDIR)isologs
which says that the shell-script $(SBINDIR)isologs should be invoked at 4am
On other systems, a similar procedure is fllowed.
on systems derived from AT&T UNIX,
the file \fB/usr/spool/cron/crontabs/root\fR might be edited followed
There are two each\-time activities:
which does the installation.
The second each\-time activity,
is that if you are already running the ISODE,
then you will need to kill and restart the \fItsapd\fR\0(8c) daemon,
otherwise incoming connections will not be initialized correctly.
Otherwise, start the daemon now.
From the \fICShell\fR, the command might be:
# $(SBINDIR)tsapd >& /dev/null
The daemon will automatically detach.
If you do not redirect the daemon's standard\-error,
then it will not detach, instead printing messages as to what actions it
That's about it. This will install everything.
To clean-up the source tree as well,
Note that if you are planning on generating or installing FTAM or VT
or QUIPU (described below),
then you should not clean-up the source tree until after you are
finished dealing with these.
If your system is configured for TCP/IP,
and you are not already running an SNMP agent,
then you are \fBURGED\fR to immediately install the SNMP agent
distributed with the ISODE.
Consult the \fBNETWORK MANAGEMENT\fR section below.
if you are interested in discussing the ISODE with others running the software,
drop a note to the Internet mailbox
\*(lqISODE\-Request@NIC.DDN.MIL\*(rq,
and ask to be added to the \*(lqISODE@NIC.DDN.MIL\*(rq list.
If you create a file called \fB$(ETCDIR)isotailor\fR,
then you can customize the behavior of the programs which use the
Consult the \fBsupport/isotailor.5\fR file for further information.
two services are installed.
having programs \fIisoc\fR and \fIisod\fR,
is used to test out the installation of the ISODE on your system:
which runs the \fIisode\-test\fR script.
having programs \fIimisc\fR and \fIros.imisc\fR,
is a small demo service supporting things like \fIfinger\fR, \fIwho\fR and
There are additional programs in the \fBothers/\fR directory.
These aren't integral parts of the system and assume that the ISODE is already
Use at your own discretion.
.SH "REGISTERING OSI APPLICATION SERVICES"
Earlier releases of the ISODE relied on static tables to keep track of
the OSI application services offered on an end-system.
This is a problematic exercise in keeping local and remote tables synchronized.
In this release of the ISODE,
the OSI Directory can be used to manage this information,
thereby automating the synchronization process.
Once you have installed the ISODE, you must bring up a DSA.
The procedures for doing this varies, depending on your location;
consult the section "Setting up an Initial DSA" in Volume 5 of the
Once your DSA is running,
you should build the DMD for your organization.
Underneath the entry for your organization,
you should select an area where your end-system's application entities
the OSI application services available in PSI's Santa Clara office
@o=Performance Systems International
@ou=Research and Development
Note that this area may very well be different than the value of the
\*(lqlocal_DIT\*(rq in your dsaptailor file.
all the end-systems at a site will have the same "local_DIT" value,
but each of those end-systems offering OSI application services will
place those services at a different portion in the DIT
(usually somewhere underneath the \*(lqlocal_DIT\*(rq value).
By convention, all the OSI application services offered by a given
end-system are placed in the same location in the DIT, under an
applicationProcess entry with the short name of the end-system,
e.g., \*(lqcn=cheetah\*(rq.
So, using the example above, the entry
@o=Performance Systems International
@ou=Research and Development
would contain all the entries of interest.
.SS "Once-only Installation"
The \fIbootsvc\fR script will generate a shell script that will create
an applicationProcess entry and then an entry for each of the OSI
services provided by the ISODE.
you must first select the RDN for the applicationProcess entry.
Run \fIbootsvc\fR to create a script:
% support/bootsvc <<aP-name>> > run.sh
% support/bootsvc cheetah > run.sh
Note that the first line of this script is used to define the network
address where \fIiaed\fR listens for incoming connections.
only the address for the Internet community (RFC1006) is set.
If the end-system is configured for other OSI communities,
then this line should be changed accordingly, e.g.,
A="Internet=`hostname`|NS+aabbcc"
start \fIdish\fR in the background,
move to the location in the DIT where the services are to be
registered and run the script,
% setenv DISHPROC "127.0.0.1 `expr $$ + 32768`"
% bind -u <<DN of DSA Manager>>
% moveto "ou=Research and Development@ou=Santa Clara"
you need to arrange for \fIiaed\fR rather than \fItsapd\fR to run when
the machine goes multi\-user.
On Berkeley UNIX systems, replace these lines to the \fB/etc/rc.local\fR file:
if [ \-f $(SBINDIR)tsapd ]; then
$(SBINDIR)tsapd & (echo \-n ' tsap') > /dev/console
if [ \-f $(SBINDIR)iaed ]; then
$(SBINDIR)iaed -D 'ou=Research and ...@cn=services' &
(echo \-n ' iae') > /dev/console
On other systems, a similar procedure is followed.
it will connect to the Directory,
find the services contained therein,
and start listening as appropriate.
when the Directory software was installed,
this included a program called \fIdased\fR.
If you have not already done so,
edit the \fB$(ETCDIR)isotailor\fR file to have these two lines:
ns_address: Internet=domain-name+17006
where \*(lqdomain-name\*(rq is the DNS name or IP-address of the
machine which is running \fIdased\fR.
This can be a different machine than the one running the DSA,
but it's probably best to have the local DSA and \fIdased\fR running
arrange for \fIdased\fR to be started when the machine goes multi-user.
On Berkeley UNIX systems, add these lines to the \fB/etc/rc.local\fR file:
if [ \-f $(SBINDIR)dased ]; then
$(SBINDIR)dased & (echo \-n ' dase') > /dev/console
On other systems, a similar procedure is followed.
it will listen for incoming connections from initiator ISODE programs.
the initiator programs aren't loaded with the user-friendly
nameservice and the DAP, owing to the code size--instead, they talk to
edit the \fB$(ETCDIR)isotailor\fR file to have these two lines:
ns_address: Internet=domain-name+17006
where \*(lqdomain-name\*(rq is the DNS name or IP-address of the
machine which is running \fIdased\fR.
users should be able to type things such as
and \*(lqthe right thing\*(rq will happen
local users can access remote services,
even if they have not been entered into the entities database).
.SS "Adding New Services"
The installation procedures need be performed only once.
If you decide to disable a service,
simply remove the corresponding entry from the Directory.
see the Section \*(lqDefining New Services\*(rq in the \fIUser's Manual\fR.
Because the FTAM/FTP gateway is meant to appear as an FTAM entity,
the entry for this service must be placed in a different portion of
the DIT than the regular FTAM service.
As such, the \fIbootsvc\fR script will not install this service.
if you wish to run such a service, you will have to install it manually.
The entry might be something like this:
objectClass= top & quipuObject &\
applicationEntity & iSODEApplicationEntity
cn= <<whatever you want>>
presentationAddress= <<unique transport selector>>/<<end-system's NSAP>>
supportedApplicationContext= iso ftam
Look in your part of the Directory to see some examples of what these
.SH "FILE TRANSER, ACCESS AND MANAGEMENT"
if you are running the ISODE on a Berkeley or AT&T System V UNIX system,
then there is also an implementation of the ISO FTAM.
FTAM, which stands for File Transfer, Access and Management,
The implementation provided is fairly complete in the context of
the particular file services it offers.
It is a minimal implementation in as much as it offers only four core
services: transfer of text files,
transfer of binary files,
To generate FTAM, go to the \fB\*(VD\fR directory and type:
This will cause a complete generation of the FTAM libraries and programs.
If all goes well, proceed with the installation.
If not, complain as there \*(lqshould be no problems\*(rq at this step.
You will need to be the super-user to install FTAM:
This will install everything and then clean\-up the source tree.
Note that if you are planning on generating or installing the FTAM/FTP
gateway (described below),
then you should not clean-up the source tree until after you are
finished dealing with the gateway.
or if you just want an installation and no clean\-up, then use:
if you are running the ISODE on a Berkeley or AT&T System V UNIX system,
there is also an implementation of an FTAM/FTP application gateway.
The gateway is actually two programs:
one which acts as an ftam responder and an ftp client,
and the other which acts as an ftp server and an ftam initiator.
Note that the gateway currently resides at a different location
than the standard FTAM responder and FTP server.
(This may be corrected in a future release.)
Read the manual entries for \fIftamd-ftp\fR\0(8c) and
\fIftpd-ftam\fR\0(8c) for the details.
To generate the FTAM/FTAP gateway, go to the \fB\*(VD\fR directory and type:
This will cause a complete generation of the gateway.
If all goes well, proceed with the installation.
If not, complain as there \*(lqshould be no problems\*(rq at this step.
You will need to be the super-user to install the FTAM/FTP gateway:
# ./make install\-ftam-ftp
This will install everything and then clean\-up the source tree.
If you just want an installation and no clean\-up, then use:
Regardless of the command you use,
on 4.2BSD-derived systems, add this line to your \fB/etc/servers\fR file:
ftp-ftam\0\0tcp\0\0$(SBINDIR)in.ftpd-ftam
On 4.3BSD-derived systems, add this line to your \fB/etc/inetd.conf\fR file:
ftp-ftam\0\0stream\0\0tcp\0\0nowait\0\0root\0\0$(SBINDIR)in.ftpd-ftam\0\0in.ftpd-ftam
add this line to your \fB/etc/services\fR file:
if you are running the ISODE on a Berkeley UNIX system,
there is also an implementation of the ISO VT.
VT is the OSI terminal service.
The implementation provided is roughly comparable to an average telnet
To generate the VT system, go to the \fB\*(VD\fR directory and type:
This will cause a complete generation of the VT initiator and
If all goes well, proceed with the installation.
If not, complain as there \*(lqshould be no problems\*(rq at this step.
You will need to be the super-user to install VT:
This will install everything and then clean\-up the source tree.
If you just want an installation and no clean\-up, then use:
if you are running the ISODE on a Berkeley UNIX or AT&T System V UNIX system,
there is also an implementation of the OSI Directory, called QUIPU.
If you're not interested in running a Directory,
skip this text and go to the section entitled \fBGENERATING
Each host using the OSI directory implicitly runs a
Directory User Agent (DUA).
you may wish to run a Directory System Agent (DSA) on some hosts.
the instructions which follow indicate which activities are necessary
in both instances, as appropriate.
To generate QUIPU, go to the \fB\*(VD\fR directory and type:
This will cause a complete generation of the DSAP library and the DSA.
If all goes well, proceed with the installation.
If not, complain as there \*(lqshould be no problems\*(rq at this step.
You will need to be the super-user to install QUIPU:
This will install everything and then clean\-up the source tree.
If you just want an installation and no clean\-up, then use:
there is one once-only activity.
The QUIPU DSA is a \*(lqstatic responder\*(rq.
This means that it accepts new associations and managing old ones as necessary.
if you intend to run a local DSA,
it is necessary to start the \fIros.quipu\fR daemon when the
On Berkeley UNIX systems, add these lines to the \fB/etc/rc.local\fR file:
if [ \-f $(SBINDIR)ros.quipu ]; then
(cd /usr/etc/quipu-db; $(SBINDIR)ros.quipu) &
(echo \-n ' quipu') > /dev/console
(This assumes your database is in the directory \fB/usr/etc/quipu-db\fR -
On other systems, a similar procedure is followed.
If you intend to run a local DSA,
then you will need to build a Directory database.
(If you are already running QUIPU 5.0 or later,
then you've done this before and so you can skip to the next section
on \fBQUIPU TAILORING\fR.)
The database directory, by default, lives in the ETCDIR area
(usually \fB/usr/etc/\fR) under the name of \fBquipu-db/\fR.
Three prototype databases can be found in the directory
\fBothers/quipu/quipu-db/\fR.
These database files should be protected as they contain Directory passwords and
other sensitive information. The DSA needs to be able to read this
information, and so performs a setuid on execution to the UID of the owner
of the database directory.
Now customize the chosen prototype database under \fB/usr/etc/quipu-db/\fR. The
details of this database are explained in Volume 5 of the users manual.
However you should be able to derive a minimal database by following
the example structure defined for University College London in
the GB branch of the Directory tree.
Then delete the example structure for O=University College London.
If you choose to run a local DSA, now configure it.
The DSA tailors itself at runtime by reading the file \fB$(ETCDIR)quiputailor\fR.
A prototype of this file will be installed during the normal ISODE
Only one entry in the file usually needs to be changed:
Substitute the name of the DSA as it occurs in the Directory for
See \fIquiputailor\fR\0(5) for a description of the full range of
tailoring options in the \fB$(ETCDIR)quiputailor\fR file.
Now configure the various DUA programs.
These tailor themselves at runtime by reading the file
\fB$(ETCDIR)dsaptailor\fR.
A prototype of this file will be installed during the normal ISODE
Only one entry in the file usually needs to be changed:
dsa_address toucan localHost=17003
Substitute the name of your \*(lqprimary\*(rq DSA for \*(lqtoucan\*(rq
and its corresponding presentation address for the
\*(lq'0101'H/Internet+...\*(rq string.
This information can be found in the Directory on the host which is
Do not confuse the \fIdsa_address\fR used in this file with the
\fIns_address\fR used in the \fB$(ETCDIR)isotailor\fR file.
These are separate services and must live at different addresses.
See \fIquiputailor\fR\0(5) for a description of the full range of
tailoring options in the \fB$(ETCDIR)dsaptailor\fR file.
you can now start the DSA.
However, if you are already running QUIPU,
then you will need to kill and restart the QUIPU DSA.
From the \fICShell\fR, the command might be:
# $(SBINDIR)ros.quipu >& /dev/null
The daemon will automatically detach.
If you do not redirect the daemon's standard\-error,
then it will not detach, instead printing messages as to what actions it
if you are running the ISODE on a Berkeley UNIX system,
there is also an implementation of the SNMP.
Although this is not the OSI network management service,
Inasmuch as the continued survival of the Internet hinges on all nodes
becoming network manageable,
this package was developed using the ISODE and is being freely
distributed with releases of Berkeley UNIX.
It must be stressed that this package is not a complete network management
whilst \fIsnmpd\fR provides a minimal agent functionality,
there are no Network Operation Center (NOC) tools--\fIsnmpi\fR is a
To generate the SNMP system, go to the \fB\*(VD\fR directory and type:
This will cause a complete generation of the SNMP agent and the
minimal SNMP initiator program.
If all goes well, proceed with the installation.
If not, complain as there \*(lqshould be no problems\*(rq at this step.
There are two once\-only activities which must be performed prior to installation.
check your \fB/etc/services\fR file,
and verify that these three lines are present:
add these lines to the \fB/etc/rc.local\fR file:
if [ \-f $(SBINDIR)snmpd ]; then
$(SBINDIR)snmpd & (echo \-n ' snmp') > /dev/console
if [ \-f $(SBINDIR)smux.unixd \-a \-f $(SBINDIR)snmpd ]; then
$(SBINDIR)smux.unixd & (echo \-n ' smux-unix') > /dev/console
You will need to be the super-user to install SNMP:
This will install everything and then clean\-up the source tree.
If you just want an installation and no clean\-up, then use:
Regardless of the command you use,
read the comments in the \fB$(ETCDIR)snmpd.rc\fR file which will tell
you how to tailor the agent for your installation.
if you are already running the SNMP,
then you will need to kill and restart the \fIsnmpd\fR\0(8c) and SMUX
(It is best to kill \fIsmux.unixd\fR first, and then \fIsnmpd\fR.)
Otherwise, start the daemons now.
From the \fICShell\fR, the command might be:
# $(SBINDIR)snmpd >& /dev/null
# $(SBINDIR)smux.unixd >& /dev/null
The daemon will automatically detach.
If you do not redirect the daemon's standard\-error,
then it will not detach, instead printing messages as to what actions it
.SH "LIGHTWEIGHT PRESENTATION PROTOCOL"
if you are running the ISODE on a Berkeley UNIX system,
there is also an implementation of RFC1085,
the lightweight presentation protocol for TCP/IP-based internets.
To generate the LPP system, go to the \fB\*(VD\fR directory and type:
This will cause a complete generation of the LPP library and support programs.
If all goes well, proceed with the installation.
If not, complain as there \*(lqshould be no problems\*(rq at this step.
You will need to be the super-user to install the LPP system.
There are two kinds of activities:
once\-only activities that you perform the first time the software is
and each\-time activities that you perform every time the software is
The first once\-only activity is to verify that the \fIlppd\fR daemon will be
run when the machine goes multi\-user.
On Berkeley UNIX systems, add these lines to the \fB/etc/rc.local\fR file:
if [ \-f $(SBINDIR)lppd ]; then
$(SBINDIR)lppd & (echo \-n ' lpp') > /dev/console
On other systems, a similar procedure is followed.
The next once\-only activity is to verify that systems with a native
\fB/etc/services\fR file contain an entry for the miscellany service.
This is used when the ISODE miscellaneous services is run using the LPP.
to the \fB/etc/services\fR file.
If your system does not have such a file,
the software automatically compensates for this.
There are two each\-time activities:
This will install everything and then clean\-up the source tree.
If you just want an installation and no clean\-up, then use:
Regardless of the command you use,
the second each\-time activity,
is that if you are already running the LPP system,
then you will need to kill and restart the \fIlppd\fR\0(8c) daemon,
otherwise incoming connections will not be initialized correctly.
Otherwise, start the daemon now.
From the \fICShell\fR, the command might be:
# $(SBINDIR)lppd >& /dev/null
The daemon will automatically detach.
If you do not redirect the daemon's standard\-error,
then it will not detach, instead printing messages as to what actions it
.SH "GENERATING DOCUMENTATION"
The directory \fBdoc/\fR contains the documentation set for this release.
Consult the file \fBdoc/READ\-ME\fR for a description of each document.
The directory \fBdoc/ps/\fR contains PostScript versions of each document.
Usually it is easier to print the files in this directory than
generate the documentation from scratch as
the sources to these documents are in either LaTeX (for papers)
or SLiTeX (for presentations).
If you received this distribution from the network,
then the directory \fBdoc/ps/\fR does not contain any PostScript files.
There should be a separate compressed \fItar\fR file,
containing only PostScript files,
available on the machine where you retrieved this distribution.
\fIThe ISO Development Environment: User's Manual\fR
with assistance from a cast of thousands
(read the \fBPreface\fR in the \fIUser's Manual\fR)