 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to computer software and computer
network management. More specifically, the present invention relates to
server-based management software and software registration in a computer
network.
2. Discussion of Related Art
In recent years, computer networks have grown not only in size, such as
number of users or geographical coverage, but also in terms of the types
of services and protocols a single network can provide and support. Many
computer networks allow end-users access to all types of services, such as
perusing news services or accessing the Internet, and do not restrict
users to one mandatory or required network communication protocol. With
the proliferation of services available on some computer networks is the
increasing burden on system or network administrators of managing those
services. A system administrator now typically has to install and manage
software on several servers where each server typically hosts or provides
one or more services to network users. Depending on the size of the
network and the number of services, the day-to-day management, for
example, installing, upgrading, and trouble-shooting, the software behind
these services can become a tedious, error-prone, and time-consuming task
for a system administrator. This is particularly true with regard to
system administrators who are not familiar with the network, the servers,
or the configuration of those servers.
In a large-scale computer network that provides many types of services and
applications as described above, there are typically several or many
server machines accessible by end-users or clients. The fact that there
are multiple servers on the network is usually transparent to a typical
end-user who is not normally concerned with the physical configuration of
the network. A system administrator responsible for managing a computer
network normally does so from a server and console, generically described
as an administration server, such as a Web server. FIG. 1 is a block
diagram of a computer network having multiple servers accessible by
end-users and connected to an administration server not configured with
the automated management capabilities of the present invention. A computer
network 102 has an administrator console shown as client 104 connected to
a Web or administrator server 106. Connected to Web server 106 are
multiple "service" servers 108. From the perspective of administration
server 106, servers 108 are referred to as management clients. Although
from an end-user's perspective, they are simply servers, where each server
may have a particular function or provide a particular service.
When an update, installation, or any type of maintenance is done on
application software residing on one of the servers 108 or a new server is
added to network 102, the system administrator must modify software on
administration server 106 accordingly. For example, if a new feature is
installed on an existing mail server or a new mail server is being added,
the administrator must note or remember the location and other information
of the new feature or server at the time of the update. The administrator
installs a new application on a server 110. This information, including
the location of any management modules of the new application, which can
be in the form of a Uniform Resource Locator, must then be entered at
console 104. Once manually entered at administrator console 104, the
information needed to manage the new software or server is reflected on
administrator server 106. At this stage the location of any management
modules on server 110 are available to the system administrator from
administrator console 104. The new mail feature from the example cannot be
managed or properly configured by end users until it is "registered" with
the administrator server 106. Administration server 106 must know where to
find the management modules associated with the new mail feature on
management clients 108 before end-users can begin using the software.
This is an inefficient process for the administrator and inconvenient for
end-users who have come to expect new applications on their networks to be
available for use as soon as possible. This process is also error-prone
since the administrator has to perform manual or non-automated tasks such
as writing down information on the new feature or server during
installation, which must later be entered at a administrator console. This
problem is exacerbated if there are dozens of servers, each with many
applications (e.g. 30 is not unusual), that have frequent updates,
corrections, or new versions that need to be installed in a timely and
accurate manner. In this type of setting, managing network services can
not only be inefficient, time-consuming, and error-prone, but impractical.
One problem with present Web server based networks typically having
multiple service hosts is designing and implementing a user authentication
mechanism. A Web server based computer network, or any type of computer
network, must have an authentication protocol or mechanism to ensure that
a user can perform only those operations or access those files the user is
authorized to perform or access. In the case of managing services on the
multiple service hosts, there can be more than one system administrator
responsible for maintaining the services on those hosts. It is possible
that certain administrators are not given complete authorization to
perform all possible operations on the Web server and the service hosts,
which may only be given to, for example, a senior or "super" system
administrator. Thus, since managing services on the hosts is an
administration task done through an administration interface, some type of
user authentication is necessary.
Although authentication does exist for Web-based networks, present
implementations and designs for user authorization are inefficient and
repetitive. The authentication referred to here is the verification and
authorization of system or network administrators for managing services on
service hosts in a network from a browser on an administration console.
Typically each service on a service host and its one or more management
modules have different authentication mechanisms or standards. There is no
clear standard on a protocol or process for implementing authentication
and access control in a distributed manner on a Web server based system. A
system administrator must re-authenticate every time the administrator
signs on to a service host since the service hosts are not in
communication with each other. A browser program can be run on a client
running any type of operating system, thus, the browser being used by the
administrator may not be on a UNIX-based client and may not have a known
UNIX identity. Since the browser does not have a known UNIX identity, an
identity cannot be communicated from one service host to other service
hosts. Thus, a system administrator must go through an authentication
process for each service host since the administrator does not have a
single or globally recognized identity.
Therefore, it would be desirable to manage end-user application software
and services available on a computer network from a central location by
having any necessary software for managing those applications and services
automatically registered at the central location during installation and
accessible from a well-known location. It would also be desirable to have
an authentication mechanism that provides for single sign on that
functions within the environment of a Web server and that server's
existing system of user identity and access control. Further, it would be
desirable to achieve this from a central location and by assigning a
universal identity to a user managing services from a browser in a
Web-server based network.
SUMMARY OF THE INVENTION
To achieve the foregoing, and in accordance with the purpose of the present
invention, a method of managing computer network services in a network
from a central management console is described. In one aspect of the
invention, a service is installed on a service host computer, of which
there may be several in the network. Data relating to the management
module is stored in a predetermined location, such as a well-known
directory, associated with the service host computer. The data relating to
the management module is retrieved from the predetermined location on the
service host computer using a management console program residing on an
administration server computer. The data relating to the management module
is stored in a storage area accessible by the management console program
residing on the administration server computer thereby facilitating
modification of the service installed on the service host computer from
the administration server computer.
In a preferred embodiment, the service installed on the host server
computer has a service segment and a management module, where the
management module stores management data relating to the service and is
stored in the predetermined or well-known directory on the service host
computer. In another preferred embodiment, the management console program
is accessed on the administration server through an administration console
having a display monitor that contains a Web browser and a user interface.
In yet another preferred embodiment, the management data relating to a
service is registered by being placed in a configuration file and storing
the configuration file in the predetermined location. In yet another
preferred embodiment, service code associated with the service is
installed in a service portion on the host service computer and the
management module is stored in a management portion of the host service
computer. In yet another preferred embodiment, storing data relating to
the management module in a predetermined location involves assigning an
identifier to the management module, determining a type associated with
the module, assigning a descriptive name for the service, determining a
specific location of the module, and saving this data in a component
configuration file in the predetermined location.
In yet another embodiment of the present invention, the predetermined
location is searched for one or more configuration files associated with
one or more services desired to be registered. In yet another embodiment
of the present invention, a program executer connected to the
administration server computer is initiated for executing commands and
transferring service-related data between the administration server
computer and the service host computer.
In another aspect of the present invention, a system for managing services
in a computer network from a central console on an administration server
having an administration console is described. In a preferred embodiment,
the system includes a host server computer installed with a computer
service that has a management module. A management data storage mechanism
stores management data relating to the service in a predetermined location
associated with the host server computer. A data retriever obtains the
management data relating to the service from the predetermined location
associated with the host server computer using a central service manager
program residing on the administration server computer. Another management
data storage mechanism stores the management data relating to the service
in a data repository, such as a database, accessible by the central
service manager program residing on the administration server computer
thereby facilitating management of the service installed on the host
server computer from the administration server computer.
In another aspect of the present invention a system for managing services
in a computer network from a management console program is described. The
system includes an administration server under the control of an
administration server program having a management console program and an
interface mechanism for communicating data and executing commands
remotely. Multiple host servers under the control of a host server program
contain a management module segment and a specified directory for holding
configuration files relating to the management module. A client computer
is connected to the administration server and is able to communicate data
with the management console program on the administration server. A memory
component stores data associated with the services and accessible by the
administration server and each of the multiple host servers.
In another aspect of the present invention a method of managing the
registration of services in a computer network that has an administration
server and at least one service host computer that is separate from the
administration server is described. The administration server receives a
service identifier corresponding to a service desired to be registered and
residing on the service host computer. The service host computer is
interrogated to determine whether the service has been registered. Service
management files related to the service are copied to the administration
server when it is determined that the service has not been registered. The
service management files related to the service is stored in a persistent
global database accessible by the administration server and the service
host computer. This allows management of the service by accessing and
modifying management data in the service management files through the
administration server.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention, together with further advantages thereof, may best be
understood by reference to the following description taken in conjunction
with the accompanying drawings in which:
FIG. 1 is a block diagram of a computer network having multiple servers
accessible by end-users and connected to an administration server not
configured with the automated management capabilities of the present
invention.
FIG. 2 is a block diagram of server side components of a computer network
in accordance with one embodiment of the present invention.
FIG. 3 is a flowchart showing an overview of a process for registering a
new service on a network in accordance with one embodiment of the present
invention.
FIG. 4 is a flowchart showing in greater detail step 304 of FIG. 3 of
registering a service in accordance with one embodiment of the present
invention.
FIG. 5 is a flowchart showing in greater detail step 306 of FIG. 3 in
accordance with one embodiment of the present invention.
FIGS. 6a and 6b are screen shots of a graphical user interface displayed on
the browser host in accordance with one embodiment of the present
invention.
FIG. 7 is a screen shot of a graphical user interface relating to the
access control and authentication of a user of the management console
program in accordance with one embodiment of the present invention.
FIGS. 8a and 8b are flowcharts of a process for enforcing access control
and authorization in the management control program in accordance with one
embodiment of the present invention.
FIG. 9 is a flowchart showing in greater detail step 806 of FIG. 8a.
FIG. 10 is a block diagram of a typical computer system suitable for
implementing an embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Reference will now be made in detail to a preferred embodiment of the
invention. An example of the preferred embodiment is illustrated in the
accompanying drawings. While the invention will be described in
conjunction with a preferred embodiment, it will be understood that it is
not intended to limit the invention to one preferred embodiment. To the
contrary, it is intended to cover alternatives, modifications, and
equivalents as may be included within the spirit and scope of the
invention as defined by the appended claims.
A method and system for managing software applications and services from a
central location in a computer network is described in the various
drawings. In a large-scale computer network having multiple servers and a
large end-user base, managing applications and software on the network is
a time-consuming and error-prone task. Typically, a system administrator
installs a new application or service on a service host, i.e., one of the
network servers which is normally done at the server. Information relating
to management of the application, in particular the location and names of
files of management modules, are manually noted by the system
administrator. This information is then entered on an administrator server
through an administrator console. Once the location of the new application
management module is known to the administrator sever, for example a Web
server, end-users can access the new application. This process becomes
cumbersome and inefficient when there are many servers on the network,
each having many applications that require frequent updating, modifying or
replacing. This problem is particularly acute from the end-user's
perspective in that the expectation that an application be available for
use soon after it is received is high. The non-automated two-step process
described increases the time before an application can be available to
users on the network.
The present invention is a method of automating the process of registering
new applications and services at a central management location, such as a
Web server, thereby reducing the amount of information the system
administrator must remember and making a service available to end-users
sooner. In the described embodiment, the present invention involves having
a management console program residing on an administration server that
manages other servers or service hosts on the network, also referred to as
management clients in the sense that these servers are "clients" of the
administration server. The described embodiment also includes a persistent
storage area containing a database for storing management information and
uses (e.g. system or network administrators) authentication information
relating to the services on the service hosts and a "well-known" directory
associated with each management client. In other preferred embodiments,
described in more detail below, the storage areas, for example, can be
distributed over the network, instead of being associated with only one
server. In another preferred embodiment, the management console program
does not reside entirely on the administration server, but can also be
distributed between the server and an administrator client machine. These
components are shown in FIG. 2.
FIG. 2 is a block diagram of server side components of a computer network
in accordance with one embodiment of the present invention. A server-side
configuration 200 of a complete network (not shown) can be viewed as
having two sections, a section 202 representing an administration side and
a section 204 representing network servers, or service hosts. Not shown in
FIG. 2 are the network end-users on client machines which can typically
access network servers 206 to provide services or for running
applications, or performing other network operations. Although the
end-users of a computer network are one of the beneficiaries of the
present invention in that services and applications on the network are
available to them sooner and do not go down as often, in the described
embodiment the invention is used by a system administrator or network
manager (i.e., the user).
In the described embodiment, management clients 206 are managed through a
Web server 208. In other preferred embodiments, server 208 can be another
type of server, such as a more generic administration server, or be a
server that has other functions depending on the size of the network and
the capacity of the server. In any case, server 208 in the network has the
role of managing management clients 206. One feature of server 208 is that
it contains a management console program 210, described in greater detail
below. Another feature of Web server 208 is that it has access to a
persistent storage area database 212 that stores service management module
information. Web server 208 communicates with storage 212 through the
light-weight directory access protocol (LDAP) 214. In other preferred
embodiments, other data access protocols can be used between server 208
and storage area 212. Storage area 212 is also accessible by management
clients 206. Persistent storage 212 is a reliable database that stores
data, in the described embodiment, in a hierarchical format. In other
preferred embodiments, the database can be in relational database format
or store data in an object-oriented type data repository. In addition, in
other preferred embodiments, storage 212 can be distributed across
persistent storage areas part of management clients 206, Web server 208,
and other persistent storage mediums available to the network and
accessible by the servers.
As mentioned, the present invention is used primarily by a system
administrator. The administrator accesses server 208 through a special
client administrator console 216. In the described embodiment, console 216
is equipped with a Web-based browser program that allows the administrator
to access server 208 and, more specifically, use management console
program 210 and storage area 212. Server 208 can also be referred to as a
management console host from the perspective of browser host 216. As will
be described in greater detail below, a system administrator can use
browser host 216 to manage software applications and services on
management clients 206.
Management clients 206 can include all or some of the servers on the
network. Those that are managed by a system administrator through Web
server 208 communicate with storage 212 via LDAP. Each management client
has one or more services shown at 218 and one or more corresponding
management modules shown at 220 on service host 207. When a new service is
installed or an existing service is upgraded, an entry in management
module area 220 is altered. As described in greater detail below, this
alteration is reflected in corresponding entries in persistent storage
212. Although services 218 are shown separately from management modules
220 in FIG. 2, the two components are integral to each other. In other
words, a service's management module is integrally bound with the main
body or functional modules of the service. However, the two components
still have separate roles. Management modules 220 are stored in
configuration files, a configuration component directory is described in
greater detail below. In other preferred embodiments the information in
management modules 220 can be stored in other formats such as a database
or a standard directory that also contains other non-management files.
The remaining components in FIG. 2 relating to the management console
program address authentication and access control features. Management
console program 210 has an authentication layer 222 that performs user
verification and authorization functions described in greater detail with
regard to FIGS. 7 to 9 below. Associated with console host 208 is a Common
Gateway Interface, or CGI program, used by a Web server to execute
programs. In the described embodiment, a CGI program 224 is used to
execute programs from console host 208 and is logically divided in to two
parts: a management console CGI 226 and a servlet CGI 228. Management
console CGI 226 communicates with management console program 208 and is
discussed in greater detail with respect to FIGS. 8a and 8b. Servlet CGI
228 communicates authentication data from console host 208 to the service
hosts 206, and is a component well known in the art.
On service hosts 206 is a corresponding authentication and access control
layer 230 that is part of management module component 220. Authentication
layer 230 receives data from console host 208 through servlet CGI 228.
These components are used to ensure that a system administrator logging on
to use the management console program to manage particular services is
authorized to manage those services and also allows a "super" system
administrator to add and delete administrators and particular privileges
in the management console framework. In the described embodiment, this
functionality is illustrated through a graphical user interface shown in
FIG. 7. Service hosts 206 re-authenticate a user's access control and
authorization with persistent data storage 212.
FIG. 3 is a flowchart showing an overview of a process for registering a
new service on a network in accordance with one embodiment of the present
invention. The flowchart shows the steps taken by a system administrator
when registering either a new service, upgrading a service, or adding a
new management client to the network. At step 302 a service is installed
on a particular management client. This is typically done through a client
machine functioning as a browser host and is usually performed by a system
administrator. A management module, associated with the service, is a
segment of executable code that is also installed on the management
client. An example of a management module on a mail server is a module
indicating a maximum quota per end-user; that is, the maximum amount of
memory a user can take up. Another example is a Web server owned by an ISP
(Internet service provider) that hosts web sites for its customers. In
this context a management module can manage the addition of a new Web site
on the Web server.
The management module can be one of several types. In the described
embodiment, the types of management modules are browser-based, X-based,
and command line. A browser-based management module is associated with an
application that is executed in a Web browser. It is anticipated that a
large majority of the application types will be applications that run in a
Web browser. An X-based management module is typically associated with a
stand alone application that is run based on the X-protocol, a component
of the UNIX operating system. These applications are generally not run
from within a browser but from the operating system shell. It is derived
from standard and well-known X-windows, a UNIX-based graphical user
interface. A command line management module is associated with an
application which is managed using command lines, but can be embedded and
executed from a Web browser. A command line may or may not have runtime
parameters as is described below. Examples of command line commands are
"ls" (obtain a list of files), "whoami" (return information on current
user), and "ps" (provide information on performance status) In other
preferred embodiments other types of management modules can be installed.
At step 304 the system administrator registers the service and management
modules on the management client. In the described embodiment this is done
by running a command referred to as mc_reg on the management client. By
registering the service and management modules, the administration server
(server 208 in FIG. 2) is informed of what type of module is being
installed. Typically, a system administrator registers several new
services on various management clients. Thus, steps 302 and 304 are
repeated for several services on various management clients. Once a
service is registered on a service host, certain files referred to as
component configuration files storing management data are created and
stored in a component configuration directory on the service host. Step
304 is described in greater detail with respect to FIG. 4.
At step 306 a "discover" routine is initiated through a graphical user
associated interface associated with management console program 210 and is
run on a service host. This routine allows the management console program
to register a particular service host. The system administrator, for
example through browser host 216, instructs the management console to go
to a particular service host or group of service hosts and check to see
what has been registered. In the described embodiment this is done by the
management console by checking a well-known directory referred to as the
component configuration directory on the service hosts indicated by the
system administrator. Step 306 is described in greater detail in FIG. 5.
In a preferred embodiment the discover routine can be run locally on the
service host at the time the service is being installed at step 302. The
service host can then broadcast the results of the remote or auto discover
to the management console program. In the described embodiment, the system
administrator can tell the management console to go register all the
service hosts that were recently modified, upgraded, or newly added by the
administrator. In the described embodiment, the management console program
proceeds to check those service hosts and will register any updates by
checking the component configuration directory. Once all the modified
service hosts have been registered, end-users can begin using the services
or applications and the registration process is complete.
FIG. 4 is a flowchart showing in greater detail step 304 of FIG. 3 of
registering a service in accordance with one embodiment of the present
invention. Step 304 introduced the process of registering a new service on
a service host so that the management console can later discover that the
a new service has been registered on that host as instructed by a system
administrator. At step 402 the service or application type is identified
to the service host. As described above, in the described embodiment, a
service can be one of three types: browser-based, X-based, and command
line. In other preferred embodiments, additional types can be entered. In
the described embodiment, this step is performed on the service host and
is one way of informing the management console of the application type. In
other preferred embodiments, this information can be entered at the
browser host. Information inputted at the service host after step 402
depends on the type of service identified. If the service is Web-based,
the flowchart proceeds with step 404. At step 404 the system administrator
enters the location of the service's management module on the service
host. In the case of Web-based services, the location is typically in the
form of a Uniform Resource Locator, or URL. At step 406 the service type
and the URL of the management module is saved as parameters in a
well-known location on the service host. In the described embodiment,
these two items of information, referred to as components, are saved in a
UNIX file referred to as a component configuration file in the directory
referred to as a component configuration directory. In other preferred
embodiments, other directories on the service host can be used to store
these components.
At step 408 the two components contained in a service management module are
assigned component identifiers. In the described embodiment, this consists
of two parts: (1) a unique identifier (such as a Solaris package name,
e.g. SUNWFIP), and (2) a version number. Thus, the URL and the service
type components are assigned a component identifier and saved in a file in
the component configuration directory. In addition a "user friendly" name
for the service, which up to this point has been a unique but lengthy and
cryptic name, is entered. This user friendly name is the name that will be
displayed on the graphical user interface, described in greater detail
with respect to FIG. 6 below. At step 420 the data or components described
in steps 406 and 408 are stored in an appropriate file in the component
configuration directory. Thus, after step 420 all the information needed
to perform step 306 of FIG. 3 (the "discovery" process) for a Web-based
type service is stored in an appropriate file at a well-known directory
and the process is complete.
Returning to step 402, if the service type is X-based, control proceeds
with step 410. As described above, an X-based type service is typica | | |
