JPH05298223A - Information processing system - Google Patents

Abstract

PURPOSE:To enable a user to use the resource on a server through any client machine in the same way by controlling the local resources proper to the clients through the server and therefore securing a uniform operating environment among the clients. CONSTITUTION:This system consists of a server machine 10 which is connected to one or more client machines 20 via a network. Then the history of a constitution control file 24 of each machine 20 and the constitutional history of the machine 10 are stored in a data base 60 when a requester 23 of the machine 20 is connected to the machine 10. At the same time, the contents of the file 24 are automatically updated based on the contents of an equipment atate data base 30 of the machine 10. So that the constitution of the machine 20 is coincident with the prescribed constitution of the machine 10. Thus a fixed constitution is kept for each machine 20.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an information processing system configured by a network, and more particularly to a configuration management system for this connected device.

[0002]

2. Description of the Related Art It is widely practiced to connect a plurality of machines via a network so that the resources of one machine can be used by another machine. In such a system, a machine that provides resources is called a server, and a machine that uses resources is called a client. The client machine is a machine that can be used by itself, and can use both local resources unique to the machine and remote resources on the server.

Conventionally, the resource name used when a remote resource is used from each client machine has been defined on the local resource of the client machine. Since this information is required before connecting to the server, it must be placed on the client machine. If this remote resource management information is different for each client, if the client used by the user is changed, the server resource name will be different and the program that was used up to that point may not operate as it is. An information server that centrally manages the remote resource management information of the server is provided, and the client obtains the remote resource management information from the information server. If the client stores only the resource name of the information server, information about other remote resources can be stored in the system. It was possible to manage them uniformly.

[0004]

In the above prior art, since the remote resource management information used by the client machine is stored on the information server, it is necessary to access it through the network, and the client machine is powered on and started up. There was a problem that local information needed before the machine could access the network could not be managed. Moreover, since such local management information is independently updated in each client, it is very difficult to grasp the history of the local management information of all clients.

An object of the present invention is to manage local resources unique to a client placed on the client on the server as well, so that the operating environment of each client is aligned and the user can access the server from any client machine. It is to provide an information processing system in which the above resources can be similarly used.

Another object of the present invention is to store the history of management information of the entire system by storing the history of changes of client-specific local resources placed on the client on the server. It is to provide an information processing system.

[0007]

In order to achieve the above object, the following means are provided.

Information in which a plurality of information processing devices including a first device having information to be provided to other devices in the system and a second device provided with information from the first device are connected via a network In the processing system, the second device includes a first means for holding device configuration information, a connection to the first device, and a process for performing processing according to information provided from the first device. 2 means, and the first
The third device that manages the configuration of the second device in response to the connection request of the second device, the fourth device that stores information about the configuration of the second device, and the third device. The fifth means for correcting the contents of the first means of the second device and the sixth means for holding the fifth means are provided.

The following means are provided to achieve the above-mentioned other objects.

Information obtained by connecting a plurality of information processing devices including a first device having information to be provided to other devices in the system and a second device provided with information from the first device via a network. In the processing system, the second device includes a first means for holding device configuration information, a connection to the first device, and a process for performing processing according to information provided from the first device. 7 means are provided, and the first
Of the second device manages the history of the configuration of the second device in response to the connection request of the second device, and the ninth device holds the history of the first device of the second device. And means are provided.

[0011]

The second device is provided with the information from the first device. The first means holds information regarding the configuration of the second device. The second means makes a connection request from the second device to the first device, and manages the configuration of the second device in response to a response from the third device of the first device. The third means is the second device of the second device.
Responds to the connection request from the means, notifies the second device of the contents of the fourth means and the fifth means, and manages the configuration of the second device. The fourth means retains the desired value of the first means of the second device. The fifth means checks whether the value of the first means of the second device is equal to the value of the fourth means, and corrects the content of the first means if different. The sixth means holds the fifth means. The seventh means makes a connection request from the second device to the first device,
The contents of the first means are transmitted to the eighth means of the first device. The eighth means adds the date information to the contents of the first means sent from the seventh means and stores the date information in the ninth means. The ninth means is the first
Information in which date information is added to the contents of the means is held.

[0012]

An embodiment of the present invention will be described with reference to the drawings.

FIG. 1 is a system configuration diagram of the present invention. This system is composed of a server machine 10 and one or more client machines 20 connected via a network. The server machine 10, as shown in FIG.
PU (processing device) 1001, memory 1002, disk controller 1003, network controller 10
04, the server disk device 11. CP
U1001 controls the entire server machine 10. The memory 1002 stores programs and data. The disk controller 1003 controls the server disk device 11. The network controller 1004 controls the access of the server machine 10 to the network. The server disk device 11 stores programs and data. As in the server machine 10, the client machine 20 is also composed of a CPU 2001, a memory 2002, a disk controller 2003, a network controller 1004, and a client disk device 21, as shown in FIG. Each function is the same. Although only one client machine is shown in FIG. 1, the present invention can be applied in the same manner even when there are a plurality of client machines.

On the other hand, on the server machine 10, a server OS (operating system) 12 for controlling the entire server machine 10 is operating. Similarly, on the client machine 20, a client OS 22 that controls the entire client machine 20 is operating. It should be noted that the server machine 10 and the client machine 20 do not have to have the same configuration, and even if they have the same configuration, no problem will occur. The requester 23 operates again on the client machine 20. The requester 23 is a program and processes an access request to the server machine 10 from another program on the client machine 20.
The processing contents of the requester 23 will be described later. A configuration control file 24 is placed on the client disk device 21. The system configuration of the client machine 20 is described in the configuration control file 24. When the client machine 20 is started up, the client OS 22 reads the contents of the configuration control file 24 and determines the configuration of the client machine 20 according to the contents. ..

A configuration example of the configuration control file is shown in FIG.
In the configuration control file, set values for each item of the system configuration are described in the format of "item name = item value". The system configuration items include, for example, file buffer size, device driver, network drive name, and the like.

The responder 13 operates on the server machine 10. The responder 13 communicates with the requester 23 on the client machine 20 via the network and manages the configuration of the client machine 20.

A device status database 30, a device change procedure database 40 and a configuration history database 60 are placed on the server disk device 11. The device status database 30 stores the configuration information of the client machine 20, and the device change procedure database 40 stores the configuration change program 50 which is a program operating on the client machine 20. The configuration history database 60 stores a history of past changes made to the configuration control file 24 on the client machine 20.

FIG. 5 shows an example of the configuration of the device status database 30. The device status database 30 includes a client type field 3010, an item name field 3020, an item value field 3030, and an item attribute field 3040.
Fields exist, and each field value is composed of an arbitrary number of entries as a set. Each entry indicates a value to be taken for each item name in the configuration control file for each type of client machine 20 and an attribute value regarding the changing method. As the value of the item attribute field 3040, there are three types of forced change, inquiry, and warning, and the processing when the item value is different is shown. The forced change means unconditionally changing the setting value of the client to the value of the item value field 3030 of the device status database 30,
Similarly, an inquiry indicates that the user is inquired and the change is made only when the permission is obtained, and a warning indicates that the user is warned and the value is not changed.

FIG. 6 shows a configuration example of the device change procedure database 40. The device change procedure database 40 includes a client type field 4010 and an item name field 40.
20 and each field of the procedure name field 4030 are present, and each field value is composed of an arbitrary number of entries as a set. Each entry holds the method of changing the value of each item in the configuration control file for each type of client machine 20. Client type field 401
0 and the item name field 4020 store values corresponding to the client type field 3010 and the item name field 3020 in the device status database 30. On the other hand, the procedure name field 4030 stores the configuration change program 50.

FIG. 7 shows a configuration example of the configuration history database 60. The configuration history database 60 has a client identifier field 6010 and a storage date field 602.
There are 0, a change date field 6030, and a configuration file content field 6040, and each field value is composed of an arbitrary number of entries as a set. The client identifier field 6010 stores a client identifier that is a value for uniquely identifying each client machine 20. Storage date field 60
Reference numeral 20 indicates the date when the contents of the configuration control file were stored in the configuration history database 60, and the change date field 6
030 indicates the date when the stored configuration control file was last changed. The configuration file content field 6040 stores the content of the configuration control file 24.

Each entry stores the value of the configuration control file 24 on the client machine 20 at a certain point in time, and a collection of a series of entries having the same client identifier value becomes the history of the client.

Next, the processing contents of the requester 23 and the responder 13 will be described.

FIG. 8 is a flowchart of the requester 23. The requester 23 first sends a connection request to the server machine 10 in step 2301. The connection request is sent including the client identifier and the client type. Then, in step 2302, it waits for a response from the server. When the response is returned, the process proceeds to step 2303 to check the response content. If the content is "connection permitted", the process proceeds to step 2304, and if not, it is regarded as a connection failure and the requester 23
Ends the process. In step 2304, the client side history update processing is performed, then in step 2305, the client side configuration update processing is performed, and the client side history update processing is performed again. Then, in step 2306, the server is notified of “connection completed”, and the requester 23 determines that the connection is successful.
Ends the process. The contents of the client side history update process and the client side configuration update process will be described later. The client-side history update process is performed twice in the requester 23, but the first history update is to leave a history of changes that the user may have made before connection, and the second history update is This is to leave a history of changes made by the immediately preceding configuration update process.

FIG. 9 shows a flowchart of the responder 13. The responder 13 first waits for a connection request from the client in step 1301. When a connection request is received, the process proceeds to step 1302 to check the content of the connection request. If the connection request is not accepted, the process proceeds to step 1304 to reply "not connectable" to the client, and returns to step 1301 to return to the next step. Wait for a connection request. If the connection request is accepted, the process proceeds to step 1303 to reply "connection permitted" to the client, and the process proceeds to step 1305 to wait for the request from the client. When the request is received, the process proceeds to step 1306, the content of the request is determined, and the process proceeds to the corresponding step. If the request content is "start history update", the flow advances to step 1307 to perform server-side history update processing. After the processing is completed, the process returns to step 1305,
Wait for the next request.

If the requested content is "configuration update start", the flow advances to step 1308 to perform server-side configuration update processing. After the processing is completed, the process returns to step 1305 to wait for the next request. If the request content is “connection completed”, the connection processing from one client has been completed, so the process returns to step 1301 and waits again for a connection request. In addition,
The contents of the server-side history update processing and the server-side configuration update processing will be described later.

Next, the contents of the history update processing on the client side and the server side will be described.

FIG. 10 shows a flowchart of the client side history update processing. In the client side history update processing, first, in step 2330, "start history update" is sent to the server. Next, in step 2331, the file change date of the configuration control file 24 on the client machine 20 is transmitted to the server, and in step 2332, a reply from the server is waited for. If there is a reply, the process proceeds to step 2333 to determine the content of the reply. If the reply is "update unnecessary", the client-side history update processing ends. If the reply is "update required", the process proceeds to step 2334, the content of the configuration control file 24 is transmitted to the server, registration in the configuration history database 60 is requested, and the client-side history update process ends.

FIG. 11 is a flowchart of the server side history update processing. First, the server side history update process is step 1
At 330, the file change date of the configuration control file 24 sent at step 2331 on the client side is received.
Next, the file modification date sent in step 1331 is compared with the latest value of the file modification date field 6030 of the corresponding entry in the configuration history database 60, and if the sent date is newer, step Thirteen
33, otherwise go to step 1332.
Here, the corresponding entry is an entry in which the value of the client identifier field 6010 of the entry is equal to the client identifier of the client sent at the time of connection request. In step 1332, since it is not necessary to update the contents of the configuration history database 60, "no update required" is sent to the client, and the server-side history update process is terminated. In step 1333, “update required” is transmitted to the client, and in step 1334, the contents of the configuration control file 24 transmitted in step 2334 on the client side are received. Then, the contents received in step 1335 are registered in the configuration history database 60, and the server-side history update processing ends. Registration is done by adding a new entry, and does not update the contents of conventional entries.

Next, the contents of the configuration update processing on the client side and the server side will be described.

FIG. 12 is a flowchart of the client side configuration update process. The client side configuration update processing first sends "configuration update start" to the server in step 2350, and waits for a response from the server in step 2351. If there is a response, the process proceeds to step 2352 to check the response content. If the response is "update end", the server side configuration update processing is ended as it is. If the response is “update execution”, the process proceeds to step 2353 to receive the item setting value from the server,
In step 2354, the item attribute value is received. Subsequently, in step 2355, the configuration changing program 50 is similarly received from the server, and in step 2356, the configuration changing program 50 received in the previous step is executed using the item setting value and the item attribute value received previously as parameters. The contents of the configuration change program 50 will be described later. When the execution of the configuration change program 50 is completed, the process proceeds to step 2357, "update complete" is transmitted to the server to update one configuration item, and the process returns to step 2351 to wait for a response again.

FIG. 13 is a flowchart of the server side configuration update process. First, the server side configuration update process is step 1
At 350, the device status database 30 is searched for an entry in which the value of the client type field 3010 is equal to the value of the client type of the client sent at the time of the connection request. Subsequently, in step 1351, the search result is determined, and if not found, the process proceeds to step 1358. If the entry is found, the process proceeds to step 1352 to send "update execution" to the client. Then, in step 1353, the value of the item value field 2030 is sent to the client. This value is received in step 2353 on the client side described above. Then, step 135
The value of the item attribute field of the entry found in 4 is sent to the client. This value is received in step 2354 on the client side described above. Then, in step 1355, the configuration change program 50 is sent to the client. This value is received in step 2355 on the client side described above. The configuration change program to be sent is obtained by the following method. Device status database 30
Item name field 3020 of the found entry in
Value in the device change procedure database 40 is used as a key, and the value of the procedure name field 4030 of the entry in which the values of the client type field 4010 and the item name field 4020 match is configured. The change program 50. Then, in step 1356, the client waits for a response. When the client receives the "update completed" sent in step 2357, the process proceeds to step 1357, and the device status database 30 is searched for the next entry in which the value of the client type field 3010 matches.
Then, the process returns to step 1351 to continue the process according to the search result. If no entry is found as a result of the search, "update end" is sent to the client in step 1358, and the server side configuration update process is ended.

Next, the processing contents of the configuration change program 50 will be described.

FIG. 14 is a flow chart of the configuration changing program 50. The configuration change program 50 is step 5
At 001, the value of the current configuration item is first acquired. The value is acquired by issuing a system call to the client OS 22 to make an inquiry. Then, in step 5002, the item value passed as the parameter is compared with the current value,
If they match, there is no need to change them, and the configuration change program is terminated. If they do not match, the process proceeds to step 5003 to check the value of the item attribute passed as a parameter. If the value is forcibly changed, the process proceeds to step 5007, if it is an inquiry, to step 5005, and if it is a warning, to step 5004.

In the case of a warning, in step 5004, a warning message indicating that the item values are different is displayed to the user, and the configuration changing program is terminated without changing the values. In the case of inquiry, step 5005 inquires of the user whether or not to change the item value, and inputs the user's reply. If there is a response from the user, the process proceeds to step 5006 to check the response content, and if the user replies that there is no change, the configuration change program is ended as it is. On the other hand, if the user replies that the configuration has been changed, the process advances to step 5007 to change the contents of the configuration control file 24 and terminate the configuration change program. In the case of forced change, the process proceeds to step 5007, and the configuration control file 24
Change the contents of and finish the configuration change program. The change is done by rewriting the character string of the file contents, as in the normal text editing process. Since the configuration change program 50 is a program executed on the client 20,
Even if the logical flow of processing is the same, the program differs for each client type. Further, since the concrete process of obtaining the current value in step 5001 and the process of changing the item value in step 5007 may be different for each item, the configuration changing program 50 causes the device change procedure database 40 to store the client type and the item name. By transferring the program registered corresponding to the above to the client and executing it, it is possible to change any configuration item of any client.

As described above, in the above embodiment, when the requester 23 on the client machine 20 connects to the server machine 10, the history of the configuration control file 24 on the client machine 20 is stored in the configuration history database on the server machine 10. 60, and automatically stores the configuration control file 24 on the client machine 20 according to the contents of the device state database 30 on the server machine 10.
Is updated so that the device configuration of the client machine 20 matches the configuration defined on the server machine 10, it is possible to always keep the configuration of each client machine 20 constant without the user's intervention. This can reduce erroneous operations by the user and reduce the load on the network administrator.

Further, since the history of the configuration control file 24 on the client machine 20 is automatically stored in the configuration history database 60 on the server machine 10, the configuration control on all the client machines 20 at an arbitrary time point is performed. It becomes possible to reproduce the contents of the file 24, and it becomes easy to investigate the cause when a failure occurs.

[0037]

As described above, according to the present invention,
Since the local management information placed on the client is also automatically updated according to the information on the server, it is possible to provide an information processing system that prevents the occurrence of malfunction due to the difference in the environment of each client.

Further, since the history of local management information of each client is held on the server, it is possible to reproduce the management information at an arbitrary time point, and it is possible to provide an information processing system in which trouble countermeasures can be facilitated.

[Brief description of drawings]

FIG. 1 is a system configuration diagram of an embodiment of the present invention.

FIG. 2 is a block diagram of a server machine.

FIG. 3 is a block diagram of a client machine.

FIG. 4 is a configuration diagram of a configuration control file.

FIG. 5 is a configuration diagram of a device status database.

FIG. 6 is a configuration diagram of a device change procedure database.

FIG. 7 is a configuration diagram of a configuration history database.

FIG. 8 is a flowchart of a requester.

FIG. 9 is a flowchart of a responder.

FIG. 10 is a flowchart of client-side history update processing.

FIG. 11 is a flowchart of server-side history update processing.

FIG. 12 is a flowchart of a client side configuration update process.

FIG. 13 is a flowchart of server-side configuration update processing.

FIG. 14 is a flowchart of a configuration change program.

[Explanation of symbols]

 10 ... Server machine, 12 ... Server OS, 13 ... Responder, 20 ... Client machine, 22 ... Client OS, 23 ... Requester, 24 ... Configuration control file, 30 ... Device status database, 40 ... Device change procedure database, 50 ... Configuration Control program, 60 ... Configuration history database.

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Hideaki Ishida, Inventor Hideaki Ishida, 292 Yoshida-cho, Totsuka-ku, Yokohama, Kanagawa, Ltd. Inside the Microelectronics Device Development Laboratory, Hitachi, Ltd. (72) Keiichi Nakane 292 Yoshida-cho, Totsuka-ku, Yokohama-shi, Kanagawa Bunch Co., Ltd. Microelectronics Device Development Laboratory, Hitachi, Ltd.

Claims (4)

[Claims] 1. A plurality of information processing devices including a first device having information to be provided to other devices in the system and a second device provided with information from the first device are connected by a network. In the information processing system described above, the second device is connected to the first means for holding device configuration information and the first device, and processing is performed in accordance with the information provided from the first device. And a second means for providing the first device with a third means for managing the configuration of the second device in response to the connection request for the second device, and the configuration of the second device. A fourth means for storing information, a fifth means for correcting the contents of the first means of the second device, and a sixth means for holding the fifth means are provided. Information processing system. 2. In an information processing system in which a server device that provides resources to another device and a client device that uses the resources of the server device are connected by a network, the configuration of the device is described in the client device. A configuration control file and a requester that makes a connection request to the server device are provided, and the server device receives a connection request from the device status database that holds the configuration information of the client device and the client device, An information processing system, comprising: a responder for notifying the contents of the device status database, wherein the requester changes the contents of the configuration control file according to the contents notified by the responder. 3. A plurality of information processing devices including a first device having information to be provided to other devices in the system and a second device provided with information from the first device are connected by a network. In the information processing system described above, the second device is connected to the first means for holding device configuration information and the first device, and processing is performed in accordance with the information provided from the first device. An eighth means for managing the history of the configuration of the second device in response to the connection request of the second device, and the second device. An information processing system, comprising: a ninth means for holding a history of the first means. 4. An information processing system in which a server device that provides resources to another device and a client device that uses the resources of the server device are connected by a network, and the configuration of the device is described in the client device. A requester for making a connection request to the configuration control file and the server device is provided, and a requester for notifying the contents of the configuration control file to the server device is provided, and the server device holds history information of the configuration control file of the client device. A configuration history database,
An information processing system comprising: a responder that receives a connection request from the client device and registers the content of the configuration control file notified from the client device in the configuration history database as history information.