|
Web-Based Headend Provisioning Agent
First web-based multi-DHCP server management interface
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: August 15, 1997
Note: For help designing your provisioning system or developing tools to help you audit/test the performance your applications contact Birds-Eye.Net.
Overview:
The following document describes the Web-Based Headend Provisioning
Agent. The Headend Provisioning Agent (HPA) provides a common user interface to the
address provisioning system for the purpose of continued expansion and maintenance of the
network and also enables localized BOOTP services for legacy headend nodes and provides a
basis on which to distribute provisioning services.
The HPA replaces a complex command line interface (and or vendor provided GUI
interface), LANCity’s LCn, and spreadsheet based IP address management that are
required to maintain day-to-day operations of the address provisioning server(s). HPA
manages the DHCP/BOOTP/TFTP server(s) by overlaying a simple point-and-click user
interface along with translated system calls that significantly streamline daily
operations. The HPA also provides multi-level user access for distributed server
management, intelligent configuration network validation and checking, and a database for
organizing networks, policies, service groups, statically mapped headend nodes, static IP
address, custom DNS names, and custom configurations in a meaningful (plain English
fashion). Lastly, HPA limits the number of individuals who need access to the actual
provisioning server for modifications.
Operation:
The primary functions of HPA can be accessed via the main interface
shown in Figure 1.0. Through this interface, nearly all configuration settings of the
Provisioning server(s) can be modified (note that new networks are activated manually as
they require the Provisioning server to be shut down and re-started however this
functionality is being currently added to HPA). This interface is only accessible once a
correct username and password are entered.
Figure 1.0 HPA’s main interface.
Figure 1.0 shows all the available options on the HPA interface. The number of these
options (buttons) that will be displayed for each user is dependent on the privileges they
have been assigned. For example:
- Most people will not see the "Delete" or "Add" option.
Modifying networks and policies is a bit more involved because they are related to one
another. For each headend its best to create three policy configuration files (state,
headend_1 and state, headend_2 and state, headend_renumber). These files allow a larger
grouping of all the networks that serve a particular headend. Within the policy
configuration dns servers, lease time, renewal time and log servers are defined. This is
the most basic information needed to setup a policy and must be created first. Figure 1.4
shows an example of a completed policy configuration.
Figure 1.1 Network policy interface
Once the policy configurations are created, networks can be added. The network
interface permits various aspects of a network to be defined together (primary subnets,
secondary subnets, dynamic ranges, DNS configurations, MD5 file info, and gateway DNS
names). In fact, HPA goes so far as defining a "network" as a collection of
related configurations. In this way, HPA is able to perform in one step what would take
several (15-20) steps in any other DHCP server interface. Figure 1.5 shows and example of
the network interface. The initial step is to select the headend where network resides and
what use network serves. The Use menu allows the network to join a larger group for
reporting purposes. The Network, Gateway, and Subnet Mask, Location, and Remarks complete
the network definition. The subnet mask drop down lists available subnet masks in the form
of subnet mask, bits, number of class C networks, and number of hosts. Note that each
network submitted to HPA encounters a series of checks through its built-in subnet
calculator. If the network for some reason fails one of the checks an error is reported
back to the user to aid in the correction condition which generated the error. For example
some of the error detection build into HPA includes the following:
- Network bounds checking
– No static IP address or gateway can be entered into
HPA unless the network which contains that IP address already exists.
- Network bit mask checking
– Networks entered into HPA must agree with their
subnet mask.
- Network validation
– Each new network entered must not intrude on nor contain
any existing network defined within HPA.
- Network duplication checking
– Each new network entered will be unique with
respect to that which is currently entered into HPA.
This level of error checking enables HPA to protect against incorrect configurations
from striking the HPA database or production DHCP server(s). Entering configurations
without error checking can result in DHCP server shut down and time consuming
troubleshooting of complex DHCP configurations and mappings. If a network is to be
configured on the server (as opposed to merely used to connect to routers thus just
reserved to protect against future use) the Use DHCP checkbox will inform HPA to relay
this network information onto the DHCP server. In the DHCP section the policy is selected
(enabling the all the parameters entered into that policy configuration to be inherited by
this network) and the dynamic range and any secondary network(s) are also entered. The
dynamic range listed is the one that is actually configured on the server.
HPA allows up to three different dynamic IP ranges to be defined. Each one of these
ranges have a different meaning to HPA according to what version of DHCP server product
you are configuring with HPA. The standard use is that the "primary" dynamic
range is associated with the primary network defined on the router or gateway. Customer
networks normally utilize routable networks as their primary and reserve non-routable
networks (i.e. net 10) for secondary networks. HPA assumes this is the case and is
programmed to handle this standard case with no configuration. The two allowed secondaries
have a intended purpose and "work best" if this intended purpose is followed.
The intended purpose is that the first secondary is primarily for the support of cable
modems or equipment that does not require a routable IP address. The second secondary
network is reserved for the support of statically mapped headed bridges and
auto-provisioning support. Any second secondary dynamic range defined is assumed that
auto-provisioning is enabled.
Since this interface can also create network specific MD5 files for legacy modems
(mimic the functionality of LANCity’s LCn) this functionality can be activated by
selecting the Generate MD5 files checkbox. Here, the default MD5 file is selected and all
RF network parameters associated with MD5 file creation are entered. The default MD5 file
is given to registered or un-registered clients that are not associated with a service
group or some other MD5 file. Selecting this checkbox will cause HPA to create a directory
on the TFTP server and all MD5 files defined in HPA’s bootfile to be created on the
web server and transported over to the TFTP server to the correct directory (this
directory is determined by the headend name and network name). HPA is also equipped to
configure several different server configurations. These configurations are listed below:
- Single DHCP server
- Single DHCP server acting with multiple dynamic ranges (using subnet groups)
- Dual DHCP servers, optimizing one for DHCP and the other for BOOTP/DHCP for cable modems
- Dual DHCP servers, optimizing one for DHCP and the other for BOOTP/DHCP for cable modems
and auto-provisioning
All the above configurations have the ability to support a TFTP server either co-hosted
by one of the DHCP servers or completely separate.
If using a single DHCP server to configure multiple dynamic ranges, HPA performs subnet
grouping automatically. Subnet grouping is performed as follows:
- Primary Network reserved for PCs
- Secondary Network [1] reserved for CMs
- Secondary Network [2] reserved for auto-provisioning (optional)
Subnet grouping support requires certain minimum DHCP server versions. These options of
which servers are being used is configured through HPA’s shared profile.
Figure 1.2 Network interface
One of the most useful portions of this interface is the ability to swap malfunctioning
legacy headend reference nodes (LCh/e). To swap an LCh, simply select the desired node
from the pick list as shown in Figure 1.1. Note that if you select more than one column
(say Headend Nodes and Custom) or more than one node you will get an error. For
convenience, each node is listed by its headend, state, and city (unless a different
listing scheme is selected). HPA can list nodes by the format below or by physical
location in the headend (i.e. row number, rack number, unit number).
Figure 1.3 Modifying a headend reference node.
Once the desired headend node is selected, click on the
"Modify" button to edit the database entry for that node. Figure 1.2 shows a
sample node entry for a headend node. To change out the LCh, replace the characters in the
mac address of the "existing" LCh with the characters of the
"replacement" LCh.
Figure 1.4 Modify Node Interface
Once the mac address is entered, double-check the LCh mac address (the interface
will not allow you to type in a duplicate mac address [return an error] or one that has
already been registered on the server) to make sure no typos exist. If the new mac address
is correct, click the "Make Changes" button to deprovision the previous LCh and
provision the new LCh. If the process does not encounter any problems, a prompt saying
that the node is modified will confirm that all the changes have been made (changes to
headend nodes are available on the server in a minute). Adding and modifying headend nodes
has one additional feature with is the ability to generate DNS entries for the headend
nodes. This is an optional feature and can be enabled or disabled for each node using the
checkbox. When the checkbox has an "x" in it the DNS entries will be generated,
other wise that node will not have a DNS entry generated.
As a result of adding, modifying, or deleting a
headend node several tasks are accomplished. Adding devices is a restricted function and
requires a high userlevel. In the case of adding a new device (modem):
- Device’s mac address is checked locally and on the server for duplicates
(duplicates are not allowed).
- Device’s name (headend, city, state, and node are checked for duplicates)
– this also ensures that the DNS names generated for all nodes will be unique.
- Device’s IP address is checked against other IP address’s known to check for
duplicates (includes checking network, router, and broadcast address of know networks).
- IP address is checked against all known networks (will not allow the assignment of an IP
address to a network that does not exist or falls into a dynamic range).
- The headend modem’s mac address is registered on the server
- An entry for this device is added to the dhcpcap file mapping its ip address and
bootfile to its mac address (this is currently how Join requires statically mapped to be
entered – when available this interface will configure other types of servers).
- Generate a DNS entry for this device – if check box is selected.
- An entry in the log file indicates the addition that took place: who added, what record,
and when it occurred.
Modify function accomplishes varying tasks depending what information is modified. Note
that this function is restricted in varying degrees by individual (enabling modification
of some or all of the fields based on userlevel). In the case of modifying an existing
device:
- If the mac address is changed, the new mac address is checked locally and on the server
for duplication. If is not duplicated, the previous mac address is deregistered on the
server and the new mac address is registered followed by an update to the provisioning
server.
- If the headend, city, or node, ip address information is changed the new
settings will be checked for duplication. If there is no duplication (and the ip address
is in the range of static addresses) a new dhcpcap file will be delivered to the
provisioning server. DNS will also be updated (if checked).
- All modifications are logged into a file that indicates the modification that took
place: who modified, what record, when it occurred, and what in the record was changed.
Deleting a device requires the highest userlevel. Deleting an existing device
performs the following tasks:
- Since the permission to delete is held with the username, only registered users can
delete devices (the userlevel also restricts individuals from having this functionality).
- When a device is deleted its entry is removed from the database, its mac
address is deregisted, and the dhcpcap and DNS files are updated.
- All deletions are logged in a file the indicates who deleted the entry, what was
deleted, and when it was deleted.
In Figure 1.0 you will also notice there is a "Custom" section. This section
is for configuring "Custom" devices like giving a modem a static IP address,
different service level (throughput), or preloading mac addresses into a customized MD5
file. In Figure 1.3 the modem listed will receive the symmetric configuration file
(1.5M/1.5M) as opposed to the basic (1.5M/300K) that is given by default to authorized
modems. The Unique Name is a field meant to further identify the custom entry (usually the
business name or the site). One important limitation of the Unique Name is that it
cannot be one of the following restricted names (node, network, headend, custom, other)
– if one of these names is entered it will be rejected by the interface. If a Static
IP is entered the modem would also assume that IP address when it booted. The remaining
portion of the Custom interface is reserved for prestuffing (multi-user modems). If
preloading is selected, a couple things need to be added to generate a customized MD5 file
for the modem to download. First the network where the customer resides needs to be
selected. This tells the interface where to place the file on the TFTP directory. Lastly,
up to four (1-4) mac addresses must be entered so they can be stuffed into the MD5 file
during creation. If stuffing less than 4 mac addresses leave the remaining fields with
zeros (0…). The mac address preloading checkbox controls the existence of the
customized MD5 file. If its checked, the file is created, if its unselected no file will
be created, and if transitions from selected to unselected the customized file will be
deleted (but the mac addresses will remain with the customized record – just
inactive).
Figure 1.5 Modify Custom Interface.
Similar to the modify headend nodes, the "Make Changes" button applies the
changes made to the modify interface and updates the Provisioning sever with this data (in
this case the file was edited using the "View" as opposed to "Modify"
so the "Make Changes" option is unavailable).
Since the "Custom Modem" section is only intended to accommodate non-standard
modem configurations, another type of entry exists to satisfy non-modem entries (mainly
centralize checkout/in static IP addresses). The "Static IP" list in Figure 1.0
shows devices that checked out a static IP address from the database. These entries can be
viewed, modified, and deleted through the same way as headend nodes and custom
configurations. However, static entries are unique to other entries in that they represent
something other than a modem (router, proxy, server, perhaps even a vanity DNS name).
Figure 1.6 Static Entry Interface
The static entry interface in Figure 1.6 allows each entry in the "Static IP"
list to be viewed or modified. Through this interface, the entry’s city and state are
added along with its IP address, Unique Name, Hardware Address, and Remarks. This above
example shows information needed to complete a typical static IP address entry. Additional
option of static IP address entries is the use of generating DNS entries. Normally a
centralized database is required to generate non-duplicate names for DNS but because of
some rules previously applied (restricted characters) to other lists of DNS names two or
more independent lists can coexist if they apply similar rules to ensure uniqueness
between lists. The idea here is to require every DNS Name and CNAME to contain a
particular character that is restricted by the other DNS list. Once this is done, the
static IP entries DNS information can be updated along with other DNS entries (headend
node entries) in a single shot.
The HPA bootfile contains the service group data that defines each MD5 file that HPA
knows how to create. Maintaining service classes or service groups is provided through a
selection item in the main display called Service Classes. When this item is modified, and
the user level appropriate for editing service classes associated with the existing user,
the display shown in Figure 1.7 is displayed.
Figure 1.7 Service class maintenance area
Modifying service classes with HPA is very easy but should be done with extreme caution
(reason why service class access requires the highest userlevel). Note that service
classes map back to individual client service group registrations. Therefore, changing the
name of a service class can render that class as well as all its subscribers inoperative.
In the case where a service class does not exist, the users subscribed to it will fall
back to the default service defined by the network in which they reside. One should use
this interface only with direction from those in charge of service definition.
Figure 1.8 Service class editor
In cases where service classes must be modified, each individual service class listed
previously (Figure 1.7) can be edited. The service class editor provides a controlled
interface to modifying only allowed (supported) options (as noted by all drop down
fields). A goal of the service class editor is to provide commonality between editing
service classes for legacy and DOCSIS cable modems. Since HPA inherently supports legacy
and DOCSIS being able to configure both service classes at the same time enables HPA to
align service definitions for both modem types.
As are result of consolidating information on all the networks, headend nodes, custom
configurations, and static IP addresses this web application contains a wealth of
information that is very useful to daily operations. For this reason, some basic reporting
functionality is available.
Figure 1.9 Reports Interface
Figure 1.9 represents the interface for generating
reports. This interface allows various levels of reporting from summary down to individual
networks (the sophistication/capabilities of the current reporting was generated from the
operations group but will inevitably grow as more information is entered). Currently there
are three types of reporting: summary, by headend, and by network. The number of networks
included in the report depend on whether Net10 is included in the reports (Net10 doubles
the size of most of the reports). Figure 2.0 represents a portion of a summary report.
Figure 2.0 IP address summary report
Figure 2.1 represents a report either by headend or network. The main difference
between these two reports would be the amount of information contained (number of networks
represented in the report). The "by headend" report would include all networks
associated with a particular headend where as the "by network" would only
include a single network. The purpose of these reports is two fold:
- Show each individual IP address of networks and all devices associated with them.
- Allow free IP addresses to be checked out.
From this report static IP addresses can be checked out simply by selecting one of the
free addresses which are hyper-linked to the "Add Static" function. Through this
process free addresses can be sought out and associated with a particular device.
Figure 2.1 Network IP address report
Detail:
Figure 2.2 provides a glimpse of the files and communications that surround the HPA
structure. The HPA consists of 6 basic parts (/userdb/Provisioning, Locks directory,
dhcpcap.dat, DHCP Provisioning Server Communication, BOOTP Provisioning Server
Communication, log files, MD5 file generation). Each of these parts will be addressed
separately below:
Figure 2.2 Headend Provisioning Agent Structure
/userdb/Provisioning:
The source files located in /web/usrdb/Provisioning consist of several flat file type
data. For the most part they are self explanatory (listing of cities in file city, listing
of states in file state, etc). The exceptions are user.db, headend, and bootfile. These
files (currently being converted into real database files) contain other information
specific to each entry. For example, one entry in the headend file would look like:
Form: headend name|hostname|ip address of machine
zionhill|znbootp01|24.128.44.9
This file allows the process to correctly address the headend BOOTP servers. The
user.db file has the same form where each entry has several fields. Currently the
passwords are in plain text but once this file is moved over to a database this file will
be converted to binary. For example one entry in the user.db file would look like:
Form: username|password|userlevel
bahlmann|I4got|500
The userlevel provides information for the multi-level access using the following
information:
Userlevel Equivalent Access/Authorization (Group intended)
100 View Only! (Interested parties)
150 Modify Headend Nodes (Headend Technicians)
200 Modify Custom Configurations (Senior Installers)
250 Add Headend Nodes and change IP address on nodes (Broadband Engineers)
300 Modify Headend Groups (Network Engineers)
500 Access All Options including Delete (Administrator)
600 Modify service group configurations
In this configuration, as the userlevel is increased, individuals will have
authorization to change anything with a userlevel equal to or less than theirs. The
bootfile file contains detailed information about service levels. For example, one entry
in the bootfile would look like:
Form:
sid|sname|dsbw|usbw|apriority|btraffic|hrn|mens|ftype|filter|swfilename|
111100|basic|1500|300|3|1|No|1|LANCity|IP/DHCP||
The bootfile provides information to the provisioning interface and the MD5 file
creation scripts using the following information:
Field Equivalent Functionality
sid Key field for each service <must be unique thus the use of 1111..>
sname Name of the service parameter <basic|headend|symmetric|best|etc.>
dsbw Downstream rate in bits per second <10000|1500|300>
usbw Upstream rate in bits per second <1000|1500|300>
apriority Access priority of service <3=low, 2=normal, 1=high>
Note: anything less than symmetric should have low priority
btraffic Number of overflow packets opportunities allowed:
<0=1pkt, 1=21pkts, 2=43pkts, 3=65pkts, 4=87pkts>
hrn Type of LANCity Device: <No: Not a HRN, Yes=Is a HRN>
mens Maximum ethernet nodes supported (no. CPE CM can learn)
ftype Type of modem file is intended <LANCity, DOCSIS, both>
filter Filter type <none, IP, IP/SP, IP/DHCP, IP/DHCP/NetBEUI>
swfilename Name of file to auto-upgrade to (if any)
Each entry in the bootfile represents a valid service group offering. Thus, when
creating new networks or re-generating all bootfiles, any service level that is completely
defined in the bootfile will have legacy MD5 files created for it (i.e. if an entry only
contains an Index and service name, MD5 files will not be created for it). This bandwidth
option will also show up in the custom area where different throughputs are selected.
Lock File:
Since currently, all the data is stored in a flat file, some restrictions must be in
place to prevent simultaneous modifications that could corrupt the data in this file. The
use of a master lock and a record lock restricts simultaneous changes to the database. The
record lock is intended to lock a particular record from simultaneous changes and the
master lock is intended to protect the main data file from simultaneous writes.
The record lock is implemented when a record is selected in the main interface (Figure
1.0) and the modify button is selected. The record lock consists of creating a lock file
for that record associating the checkout time and the owner. When this record is modified
and applied ("Make Changes" button is selected in the interface) this record
lock continues until one of the following occurs:
- Record is modified and the database is updated successfully
- The record is not modified and the user cancels the modify operation
- Another person attempts to modify the record (in the case of if the user leaves this web
document – surfs elsewhere) past the modify expiration time (an amount of time set
for the modification to take place) in which case the record lock assumes a new modified
time and owner (the current modified expiration time is 10 minutes).
The master lock protects the data file (dhcpcap.dat) by only allowing one update to
happen at a time. If multiple requests to update the data file occur they each wait for
the opportunity to lock the file perform their update and then unlock the file. Since
updates are not frequent with data of this nature this form file locking is more than
adequate.
Database:
As stated earlier, the data (dhcpcap.dat) is currently a flat file (pipe delimited).
The flat file is used for simplicity as well as speed (much faster access and queries
through Perl than using a UNIX database). Although the database is in plain text it should
not be edited by hand. This is because, the Perl script (hpa.pl) thoroughly checks each
entry before its allowed to enter the database. HPA also assigns a unique key to each and
every entry which is critical to referencing that item in future operations and handling
that item using record locking. Since any hand entries would not go through these steps, a
simple modification may corrupt the database. Probably the most useful checking is done on
the Provisioning server to ensure this device is not previously provisioned and internal
checking within the database to ensure the entry is unique.
Provisioning Server Communication:
During any changes (Add or Modify) to the hpa database, a communication path is opened
between the web server and the provisioning server. This communication consists of a
sequence of rsh commands (run as user "nobody") that de/register mac addresses
and update the files on the main provisioning server. The current provisioning server
continually checks the file modification date of the bootptab file (dhcpcap) re-reading it
after any changes. This allows changes to the LCh provisioning to be a matter of
de/registering the mac addresses of the modems and updating the dhcpcap file. Registering
and de-registering mac addresses are aided by the use of various scripts located in the
/opt/bin directory. These scripts take mac addresses as arguments and submit them to the
provisioning server. A useful function of these scripts is that they confirm each action
within the server returning information about the success or failure of the action. For
example if the requested action was to delete a registered mac address, the script would
first check if the mac address was registered, if it was, it would try to deregister it,
and then follow up by checking to see that it was de-registered. If the requested action
was not successful, the proper error text is returned and fed back to the user. Once the
mac address has been submitted to the Provisioning Sever, some trivial effort is made to
ensure the dhcpcap file that is copied onto the Provisioning Server is intact before it
replaces the working dhcpcap file. This checking consists of copying over two files
(dhcpcap.web1 & dhcpcap.web2), checking for differences, and updating the working
dhcpcap file only if the two copied files are identical. This additional step of moving
two copies of the dhcpcap file is done to ensure this file is indeed complete. This file
is critical to the configuration of Join and must be absolutely correct to enable intended
operation of the server.
Having DNS entries for headend nodes has proved very useful in troubleshooting and
installations. Since the headend nodes do not have a IP address lease (dynamic address)
associated with them they cannot obtain a dns entry using the current process of using
Remedy, the provisioning server, and the dns script nor would it be feasible to have them
manually entered. Instead, HPA generates dns entries for each LCh/e based on its location
and IP address. The following represents an example entry for one LCh:
MA-Newton-4 IN CNAME nd-hrn-newton4
nd-hrn-newton4 IN A 24.128.36.11
Note that it is critical the file permissions and ownership of the
dhcpcap files be maintained for the HPA to successfully update the main provisioning
server. The required file permissions of dhcpcap, dhcpcap.web1, dhcpcap.web2, and
henodes.dns files located in /etc/join should be "-rw-rw-r—" or 664 chmod.
The proper owner of this file should be "nobody" using chgrp.
Log Files:
There are several log files that track the use of the HPA interface. These logs track
logins errors and MD5 file creation process. The log file provides a way of monitoring the
use of the HPA. Currently, the detail of the log file is somewhat lacking but it does
provide enough information to track down and correct improper use of the interface. These
logs can be viewed by clicking on the view log button and selecting which log you want to
view. The resulting display will show the last 50 lines of entries into the log file.
Profile:
Nearly all aspects of the installation and configuration have been rolled into
configuring the ".profile.pl" file. This file contains all the "machine
specific" parameters that must be set in order for the web script to function. Each
setting in the profile is commented and one can use existing entries as a model.
Server Setup:
To set up this server several things must be done to make the web script
operational. These actions will enable the CGI script hpa.pl to communicate with the
necessary machines. One key setup step is to make sure the path "/web" is able
to get to the root (home) directory of the web server root directory. The easiest way to
accomplish this is to make a symbolic link from a file located at "/web" to
point to the actual web home directory. Once the ".profile.pl" file is edited,
the remaining setup involves allowing user "nobody" to communicate with the DHCP
and BOOTP servers. To do this each remote server must have the following added:
(servername is the web server’s NIS name)
- Create a "/.rhosts" file with the following entries
- servername nobody
- servername root
- Create a "/etc/hosts.equiv" file with the following entry:
- Make sure servername is in the "/etc/hosts" file
- If using tcp wrappers, also add the servername to "/etc/hosts.allow"
- If the server has a TFTP directory that the web server must update, the TFTP directory
structure must be OWNED by user "nobody".
- Create the following files: dhcpcap.web1, dhcpcap.web2 & henodes.dns and place them
in /etc/join. Change the owner of these files to nobody (chown nobody dhcpcap*) and (chown
nobody henodes.dns). Change the permissions of the dhcpcap files (dhcpcap, dhcpcap.web1,
& dhcpcap.web2) to readwrite (chmod 644 dhcpcap*).
Troubleshooting:
One of the easiest ways to troubleshoot the functionality of the web
script is to run them as user nobody (su -l nobody). This way you can send commands
similar to that of the web scripts and they should work.
Discussion Items:
- Access to this site will become an issue of much debate (inside or outside the
firewall?). Because of the power one has in effecting service to working customers it has
all the makings of restricted use. I would argue that unless the right people can get to
it at the right time the point of having such a site is useless. Its been my experience
that when people need to use this site, they come (surf) into the site looking like
customers. Restricting access to headend technicians and operations type staff who
ordinarily have the power of effecting the service of customers seems appropriate.
- Security presents some difficult problems with respect to this interface.
While multi-level user access is implemented within the interface, access to this site
should be limited and closely monitored via certificates. Use of certificates would enable
encryption of the passwords across public networks. In the current release of the HPA,
selected individuals that have access to this site must first enter a username and
password to enter the web server, and then an additional username and password to enter
the provisioning agent. In most cases these are two different passwords.
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.
|