Automating Your Network Maintenance
In this rapidly changing era of online media and Internet,
it is vital
to maintain a consistent and reliable network configuration.
article discusses number of programs a network administrator
can use to
automate the process of adding and removing users and
systems from the
network configuration databases.
Each time a network administrator adds a node to the
network a certain
number of jobs come back. This is also true when adding
users to your
network environment, either as interactive ones or "fake"
dial-in network access. As you probably have experienced
when doing the
same job over and over again, you tend to let things
slip a bit and
become somewhat careless (at least I do!). So, I've
written a few Perl
programs to help automate these jobs. When you want
to add or remove a
host or user, you just have to edit one or two files,
and the software
does the rest (almost) automagically.
Because of the variety in networks and dial-up access,
I have split up
the software into three parts. The first part takes
care of the UUCP
connections. These are used by people who want to access
while away from the office. The second part is used
for LAN access, the
"normal" way of accessing the services on
the network. The last part is
common to the first two, and is used in both cases.
Note that these
programs are still experimental and should be adapted
to your own
specific environment and needs.
I used the following networking packages:
Taylor UUCP (version 1.06.1)
Cnews (Cleanup Release, April 1995)
You can find these at a number of sites on the Internet
-- an archie or
WAIS search will point you to a spot closest to you.
I run this software on a SPARCstation with Solaris 2.4.
The Taylor UUCP
packages replace the stock Solaris UUCP, as does the
This machine does not run NIS or NIS+ as there are no
NIS clients on the
network. If you want to expand the software in this
article to support
NIS(+), please feel free to do so. If you send me these
can add them to the package.
This SPARCstation is the central network server. It
runs the stock
named, the name resolver, and our mail and news server
can contact this machine over the LAN to retrieve their
mail and read
their USEnet news. For those who are connected through
a UUCP dial-up
link, it batches all the outgoing traffic into UUCP
Almost all network maintenance is done on this machine,
so all software
will run on this machine as well. If your setup differs
from this one,
you can split up the software and divide it over the
on your network.
The Basic Structure
The basic structure of this software is simple. Adding
hosts is done by a cron job that runs every hour. Both
the UUCP and LAN
parts have their own cron job.
The host to be added or removed is put in a special
file that will be
read by this cron job. This file is called /etc/maintsite.uucp
connections and /etc/maintsite.lan for LAN connections.
this file, the cron job deletes it, so it will not run
into it on the
next round. The format for these two files is not exactly
the same, but
there are similarities.
Adding a host or user is done by preceding it with a
"+" sign. If a site
should be removed, it is preceded by a "-"
sign. Below is a simple
example for adding a UUCP host.
Example of /etc/maintsite.uucp file:
A maintsite.lan file will contain more information because
it needs to
know the IP address of the host to be added.
Example of /etc/maintsite.lan file:
The UUCP Connection
While discussing the UUCP part of the software, most
of the third or
common part will be covered as well. This common part
can also be used
in the LAN (i.e., TCP/IP) part. The complete Perl program
for UUCP hosts
is shown in Listing 1.
As said before, I use Taylor UUCP on this system. One
of the nice
features of Taylor UUCP is that it can support a number
UUCP configuration formats. It has its native, and most
format, which is a descriptive configuration that offers
features. For compatibility reasons, it supports the
format, and for true die-hards, it also supports the
V2 style. When
building Taylor UUCP you can specify which formats you
would like to
have supported. You can have more than one format supported,
definitely complicates things.
As an added bonus, Taylor UUCP comes with a special
uuconv, which enables you to convert HDB or V2 style
config files into
Taylor ones and vice versa. Because of its flexibility,
I use Taylor
format config files. However, you can easily change
the software to HDB
style, either by using the uuconv program, or by changing
Adding Hosts to the UUCP config
Adding a host to the UUCP network setup is done in several
keep things simple, only dial-in UUCP connections are
on the road are constantly on the move so they cannot
be reached at a
fixed phone number. The first step is to add the machine
to the list of
well-known UUCP hosts. These are trusted hosts that
are allowed to
dial-in and transfer data. The list of these machines
is kept in a
config file called sys in the Taylor config directory.
directory is mostly located in a subdirectory called
conf in the home
directory of the UUCP user. This conf file is the equivalent
Systems file in HDB.
Adding a host to this file is done by adding a number
lines describing the characteristics of this host. Most
characteristics are equal among the different hosts,
the sole difference
being the name of UUCP machine. To add a host, simply
fill out a
template file that is concatenated to the existing sys
file. The %s%
tokens in this template will be replaced by the actual
name of the UUCP
machine. To be able to delete a host later, the part
added will be
delimited by special comment lines that determine the
beginning and end
of a host section. The template is shown in Listing
2. As you can see, a
number of %s% tokens are present, and the beginning
and ending of this
host section are marked with START and END.
Before a change is made to the sys file, a backup is
has taught me that one backup sometimes is not enough
-- if you make the
same mistake twice you have lost the original. So, a
history is kept of
a maximum of three old sys files. The remote system
is allowed to send
and receive mail and news, plus it may upload or download
the UUCP public storage in /usr/spool/uucppublic. The
remote system is
never called (see the time configuration line). Finally,
the remote system uses for dialing in is called uu%s%.
As shown in Listing 1, adding a host is done in the
function addhost. It
will first scan the active sys file to see if the host
present. If so, it will issue a warning mail to root
and exit. If not,
it makes a backup of the sys file, opens the template,
and adds the host
to the bottom of the sys file. The function also replaces
the %s% tokens
with the name of the new system.
Before the new system can dial-in, it must be added
to the /etc/passwd
file. A UUCP connection is made by logging in and starting
UUCP shell called uucico (UUCP Copy In Copy Out). So,
for each user the
following line is added to the /etc/passwd file:
uu%s%:*:UID:GID:Dial in UUCP account for
In this line, %s% is replaced by the name of the system
The UID and GID are a unique User ID number and the
Group ID of the UUCP
group. The function adduser in Listing 1 will take care
of this. It will
first read the /etc/group file to determine the GID
of the UUCP group.
If found, it will add the user uu%s% to the group file.
It will open the
/etc/passwd file and determine the first unused UID.
It will then add
the line to the file. The account is default disabled,
as there is a "*"
in the password field, and the network or system operator
this account a secret password for security reasons.
When these two
functions are completed succesfully, the remote system
is able to dial
in. However, it still needs to be fed data, that is,
mail and news. The
next thing to do is tell the news and mail software
that they can batch
outgoing data for this new system.
Adding Hosts to the News Configuration
For CNews the configuration is stored in a number of
files in the home
directory of the news user. This also applies to INN,
but the files and
formats are different. The main configuration file for
CNews is sys.
This file contains the names and setting for systems
and defines which newsgroups are exchanged with a system.
contains an example of this sys file.
To add a host to this file, simply add a line describing
for this system. While this line is added, the %s% tokens
with the actual name of the system. In Listing 1, this
action is done in
the function addnews. This function is also called when
a host needs to
be added to the LAN configuration.
To ensure the system will batch outgoing news through
UUCP, the system
needs to be added to another configuration file, batchparms.
describes the parameters with which the batches are
created. Listing 4
contains an example.
batchparms tells the maximum size of one batch file,
whether it should
be compressed, and how the batches are sent to the remote
this case the viauux setting makes the batches go out
via UUCP. Systems
are added by appending a line describing the system
name and a default
setting for the batch parameters. This is done in function
in Listing 1.
Adding Hosts to the mail Configuration
Adding a host to UUCP for mail is also simple. The sendmail.cf
assumes that the names of all UUCP hosts are contained
in a file called
/etc/mail/sendmail.uunames, and when a UUCP host is
added, its name is
appended to this file. This change is automatically
sendmail is started to send mail to a host. All of these
done by the function addmailuucp in Listing 1.
The sendmail documentation describes how to adapt your
to read the names of UUCP hosts from a file. Previous
the sendmail program called the uunames program directly
and read the
output. In version 8, this has been abandoned due to
Once all actions have completed succesfully, a mail
is sent to root,
informing it of a succesful addition.
When a host needs to be removed, the inverse of the
above are performed. Furthermore, these actions are
performed in the
reverse order. There is one catch however. When a UUCP
host is about to
be removed, the system might still have a number of
batches waiting to
be transmitted. These batches need to be sent before
the host can be
deleted from the UUCP configuration, or else some mail
could be lost.
So, removing a host from the UUCP configuration is a
First of all, the host is removed from both the mail
configuration to prevent new batches from being created.
This is done by
the deluucpmailnews function in Listing 1. For mail,
the system name is
removed from the /etc/mail/sendmail.uunames file. For
associated lines from the sys and batchparms files are
Once this has been done, the system must wait until
the pending batches
have been sent, or until the maximum waiting time has
expired. If the
batches are still pending after 24 hours, they are removed
there are no pending batches, the function deluucp is
called, and the
host is removed from the UUCP sys file. If there are
the name of the system is stored in a file called /etc/pending.uucp.
This file is scanned each time the job is started by
cron. If the job
detects that all batches have been sent, it deletes
the host. If after
24 hours the batches are still pending, they are removed
from the queue,
and the host is removed from the UUCP configuration,
/etc/passwd and /etc/group file. Once the host is completely
mail is sent to root informing it of the successful
The LAN Connection
In a networking environment, it is common for hosts
to be connected and
disconnected from the LAN (Local Area Network), and
adding a host to a
UUCP setup can be relatively complicated. It involves
editing a number
of (not related) config files that are scattered around
Managing the LAN configuration is a better structured
process. Only a
limited number of related config files needs to be edited,
with only one
exception. The program used to perform these functions
is shown in
Listing 1. It is the same program used for the UUCP
connection. When the
program is started, it will determine its own name.
Depending on this
name, the program will either go for the UUCP configuration
or the LAN
Adding Hosts to the named
Adding hosts to the LAN configuration involves a number
of simple steps.
The host must be assigned an IP address, but fortunately
that address is
already included in the maintsite.lan file. First, you
need to add this
IP address to the named configuration files. This is
the daemon that
will resolve all IP address translation queries. These
files are stored in the directory specified in the /etc/named.boot
This file is read by the named when it is started and
to other configuration files. An example of this named.boot
shown in Listing 5.
If a host is added to the network, it must also be added
to the forward
and reverse mapping files. The forward mapping (translating
a name into
an address) is done by the named.reseau file, and the
(translating an address into a hostname) is done by
the named.rev file.
These two files are kept very simple, and they include
.data files that
contain the lists of hosts and IP addresses.
When a host is added, its information is added to one
of these .data
files. An example of the named.reseau.data is shown
in Listing 6, and an
example of named.rev.data is shown in Listing 7.
So, you add a host simply by appending the information
to both of these
files. As shown in Listing 2, this is done by the function
After the information is added to the configuration,
the named program
must be notified of the change. This is done by sending
it a HUP signal.
After receiving this signal the program will reread
file and the new data will be available.
One problem remains to be solved. The new system may
not be directly
accessible, but connected to the LAN via a router. The
only thing this
program can do is check the active routing tables in
the kernel and test
if the machine can be reached directly. If not, a mail
message is sent
to root, so he or she can adapt the routing information
in the kernel.
If you are using some sort of security software, you
need to add the
name and/or IP address of this new host to those config
files as well.
An example is the tcp_wrappers package that is used
by the inetd program
to control which hosts may connect to the system. The
tcp wrappers is stored in two files, /etc/hosts.allow
/etc/hosts.deny. These files control which hosts are
allowed and denied
access, respectively. These actions are performed by
addsecurity in Listing 1. If you are using another package,
change this function to suit your needs.
Adding Hosts to the mail Configuration
There is no need to change the mail configuration when
adding a host to
the LAN. As sendmail is configured to use named, it
detect when a new host is added to the configuration.
Adding Hosts to the news Configuration
Apart from adding the host to the sys file as described
in the UUCP
configuration, you also need to add the name of the
new host to another
file, nntp_access. This file controls which hosts may
access the news
spool through NNTP. An example of this file is shown
in Listing 8, and
this action is performed by the function addnewslan
in Listing 1.
Next, the host is added to the basic network configuration
A mail is sent to root notifying it of this successful
addition. If your
network needs more adaptations you can add functions
to the program to
Removing hosts is just as simple as adding them. The
above for adding them are reversed and executed in reverse
assume the host has already been physically disconnected
network before removing it, so no more links are open
to the host.
First, the host is removed from the nntp_access file
so it can no longer
access the news spool. This is done by function delnewslan
in Listing 1.
Then, the information is removed from the named configuration
named program is notified by the HUP signal. When both
of these tasks
are completed successfully, root is notified of the
Root must check the routing information by hand, to
make sure no excess
routes are left lingering in the kernel.
The program presented in this article is an experimental
one and is not
suited for use in a production environment. You will
need to tune it and
add more errorhandling to deal with user and system
errors. This program
does show you the techniques involved and how to apply
them in your own
programs, and combining all of these simple steps into
one program can
save a lot of manual work and creeping errors.
About the Author
Arthur Donkers graduated from the Delft Universiy of
Technology with a
degree in Electrical Engineering and a major in Computer
Since then he has worked for a number of major software
houses in the
Netherlands and participated in several major projects.
field of interest in these projects has been, and still
datacommunications, especially the integration of multivendor
networksystems. For the last four years he has worked
as an independant
consultant for his own company, Le Reseau (french for