Relis-G: Remote Library Install System for Computational Grids Hiromasa Watanabe University of ElectroCommunications, Japan [email protected]

Hiroki Honda University of ElectroCommunications, Japan [email protected]

Yoshio Tanaka National Institute of Advanced Industrial Science and Technology, Japan [email protected]

Abstract When a grid user installs the library which is used by the GridRPC etc. to the servers distributed over a grid, the user needs to solve complicated and laborious problems, such as user’s effort to input commands for remote operation, creation of an installation package of the library for heterogeneous server systems, avoidance of redundant compilation, and observance of administration policy of each server. In order to enable the user to solve these problems easily, we propose the remote library install system, Relis-G, which is highly portable and multipurpose in the grid. Besides the function for automatic remote library installation, this system offers functions, such as automatic creation of an installation package, automatic avoidance of redundant compilation, and automatic observance of administration policy of each server. Moreover, we confirmed that this system mitigated the above-mentioned user’s burden greatly by operation tests.

1. Introduction The ”grid” is infrastructure for using computational resources distributed in global network, and researches on this topic have been carried out prosperously. The ”computational grid” is aimed at constructing large computational environment using resources of a grid. It is particularly expected to provide high calculation performance and it attracts attention as a next generation of computational infrastructure for various science technologies. To develop a grid application, GridRPC[13] system, such as Ninf/Ninf-G[28] and NetSolve[18], is used frequently, which extended the conventional RPC (Remote Procedure

Toshitsugu Yuba University of ElectroCommunications, Japan [email protected]

Mitsuhisa Sato University of Tsukuba, Japan [email protected]

Call) to the grid. This is one of the systems called grid middlewares that conceal the complexity of operation for using resources of a grid, such as authentication, resource management, and network communication. In GridRPC system, a function registered in a server is called with the argument that is transmitted from a client to the server (Chapter 5 describes the systems which the code of the function is transmitted at the calculation request time). In this method, when the function is not registered in the server, installation of the library that contains the function to the server must be performed in advance of calculation request. This “library installation” consists of the work on the server of compiling, linking the source files of a library, and registering the library as service for the computational grid. In addition, details of these works are defined by the grid middleware to be used. Until now, the library installation has been performed by a user with remote access tools, such as ssh and scp. However, this conventional method has the following problems. In the situation of using many servers, and the situation of updating a library frequently for the reasons of debugging etc., the user’s trouble for the work increases (1). To develop a library, the installation package of the library needs to be created, which can be compiled on the heterogeneous server systems of a grid (2). In some homogeneous server systems, such as PC cluster, redundant compilation of a library should be avoided in order to use the computational resources efficiently (3). Since a server is generally administered by those other than a user, the library installation must be performed along with the administration policy of each server (4). These problems of the library installation are not solved in the grid middlewares mentioned above. Moreover, the

existing automatic software distribution systems are designed for the intranet use, and not suitable for the grid environment (see Chapter 5). In this paper, we show design and implementation of the system called Relis-G which solves these problems, and reduces the user’s trouble in the library installation. This system enables the user to install a library to all servers by executing just one shell script with the files that describe the library installation environment. The features of this system are as follows. This system protects the server where the library installation is performed by the security technology that is standard in the grid (1). This system can operate on the heterogeneous computers of a grid (2). In this paper, Chapter 2 describes the design and implementation of Relis-G, Chapter 3 shows whole operation of Relis-G. Chapter 4 describes the operation test and evaluation, Chapter 5 mentions related works, then finally Chapter 6 describes the conclusion and future works of Relis-G.

2. System design and implementation This system consists of the following functions (see Figure 1). Remote library installation function : automatically installs a library to remote servers. Installation package automatic creation function : creates the installation package of a library that can be compiled on heterogeneous server systems. Compile server function : avoids redundant compilation on homogeneous server systems. Administration policy automatic observance function : adapts installation for the administration policy of a server. Logging function : logs the messages in a remote library installation. The followings are the design and implementation of these functions.

Installation Installation Package Environment Automatic Creation Function Definition File Installation Workflow src Definition File User > relis-g.sh

Logging Function

Remote Library Installation Shell Script

Compile Server Function Compile

src lib Compile Server

Register×4

src lib

lib

Module Repository

Calculation Server Compile Register

src lib

Server

Administration Policy Automatic Observance Function Figure 1. Structure of Relis-G

• It is used as a defacto standard in many institutions of grid research. • It has the security infrastructure GSI (Grid Security Infrastructure) that is based on the public key cryptosystem and the X.509 certificate. Also the GSI has single sign-on function. • It has the GRAM (Globus Resource Allocation Manager) function for remote process creation and the GridFTP function for file transfers. This function was implemented by the Bourne shell script for the following reasons. • It has high portability on the heterogeneous computers of a grid. • It enables parallel installation to multiple servers to be implemented easily by forking process. • It fits for implementing this function by combining commands of the remote access tools mentioned above.

• It uses user authentication (including single sign-on) mechanism for remote server access. • It is operable on heterogeneous computer environment.

This function uses user-defined text files to receive the information about library installation environment. This style is suitable in the development process of a grid application that a shell is used as a terminal in many cases. The files are the installation environment definition file and the installation workflow definition file. This separation is based on that the definition of installation workflow (command sequence for installation) does not change by the server environment and can be reused while same grid middleware is used. Details of these files are as follows.

In order to realize these features, this function is implemented as follows. This function employs the Globus Toolkit 2[7] which has the properties described below as to the remote access.

Installation environment definition file. This file describes information about the server environment where library installation is performed.

2.1. Remote library installation function This function offers the basic functionalities for the remote library installation. This function must have the following features.

This file is written in XML, because the high readability in the tree structure of XML is useful for a user to describe many setting items. The contents of this file are as follows (see Figure2). • Settings about the way to build a library (about 11 lines) in line 3: shows the path where the source files of a library exist, options of the installation package automatic creation function, and the installation workflow definition file to be used (after-mentioned). A user must describe this setup information irrespective of the server environment. • Settings about module repositories (after-mentioned) (6 lines per one host) in line 15: shows information for accessing the GRAM and GridFTP services on each module repository remotely. A user must describe this setup information for every module repository. • Settings about servers (6 lines per one host) in line 25: shows information for accessing the GRAM and GridFTP services on each server remotely. A user must describe this setup information for every server. In this file, a regular expression like “node[0-7]. abc.com” can be used for the host names of servers. By this expression, a user can easily perform library installation to every node in case that the disk space in a cluster environment is not shared by the NFS. To process this file, the program which reads this file and writes out the contents in a shell script format was developed by the Java language using the lightweight XML parser library Crimson[4]. This program also performs the extraction of the above-mentioned regular expression. Implementation by the Java is suitable for the heterogeneous computer environment of a grid in point of platform independency. Moreover, the requirement of the Java VM on a client host does not become a serious obstacle. Installation workflow definition file. This file is proposed in this research, and it describes the installation workflow (command sequence for installation) unified between grid middlewares. By this file, this system can be used as a multipurpose automatic software distribution system in a grid. In order that this system can perform an arbitrary installation workflow, the command sequence for the installation needs to be described by the format unified between grid middlewares. The format of this file was designed to fulfill the following requirements. • It must not be dependent on a shell. In order to make a workflow diverted into various workflow processors easily, it needs to use abstract



Figure 2. An example of installation environment definition file



Figure 3. An example of installation workflow definition file

process expression. And, a user should not be forced to know the format of shell script. • It must use refined specification for describing an installation process. It needs to enable a user to describe an installation process easily. The contents of this file are as follows (see Figure3). • Description of each command (about 3 lines per one command) tag in line 6: imitates the tasks (Exec, Copy, etc.) of the build file of Apache Ant[1]. The format of that is useful for command expression that is independent from a shell. • Description of a control flow between commands (about 2 lines per one flow) tag in line 5 that surrounds a group of commands: imitates the structure activities (Sequence, While, etc.) of Business Process Execution Language BPEL4WS[2]. BPEL4WS is refined very much to describe a business process in a very natural manner. • Division of a group of tasks (about 4 lines) tag in line 4 which surrounds a group of control flows: describes a group of tasks which is divided into the flows performed on a compile server and the flows on a calculation server for the compile server function. The files that should be transmitted from a compile server to a calculation server are specified by the tag in line 16.

Source files gcc -E -M Names of included library headers are acquired Feature checks of compilation environment which should be performed are guessed from the header names Autoconf input files such as configure.in, Makefile.in, config.h.in autoconf configure script Figure 4. Installation package automatic creation function

To process this file, the program which reads this file and writes out the command sequence equivalent to it in a shell script format was developed by the Java language using Crimson like the case of the installation environment definition file. In advance of the execution of an installation workflow, the value of an environment variable may have to be defined which is peculiar to each server, such as the installation path of the grid middleware etc. In this case, the name of the environment variable is specified in this file as the tag in line 3. This system uses the administration policy automatic observance function (see Section 2.4) to get the value of the environment variable.

2.2. Installation package automatic creation function In order to enable a library to be compiled on the heterogeneous server systems of a grid, this function creates the files for building a library, such as configure script and Makefile. In heterogeneous server systems, the individual method for compiling a library may be needed for each server (ex. a specific compiling option is needed on a specific system). For building a library, the build files (especially a configure script) that perform such a compilation procedure need to be created. In this function, a configure script is created by the GNU autoconf[8] which creates it automatically from a specific input file. And, the input file of the autoconf is created by this function from the source files of a library. At this time, the feature checks of compilation environment that should be performed are deduced by the names of the library headers included in the source files (see Figure4). This is be-

cause we judged that the machine dependencies of source files are mostly originated in use of external libraries. This function employs the configure script for constructing an installation package, because it is highly portable in the heterogeneous server systems of a grid.

2.3. Compile server function This function automatically performs library compilation on compile server, transmits and registers the library to other servers (calculation servers) (see Figure5). By this function, redundant compilation of a library can be avoided. For homogeneous server systems, such as clusters distributed over the multiple sites, this function is very useful to use them efficiently. It is necessary to solve the following problems to realize this function. 1. The specification method of the compile server corresponding to a calculation server, and the acquisition method of the information for accessing a compile server

2. Compile and Transfer Library File 1. Transfer Source Files src

Client

Compile

src lib Compile Server

Register

lib Calculation Server 1 Register

lib Calculation Server 2

src lib Module Repository

Register

3. Transfer Library File and Register

lib Calculation Server 3

Figure 5. Compile server function Where should I install a library ? /home/watanabe Client Install a library under /home/watanabe

MDS Server

2. The arrangement method of a server for file transfers For the first problem, this function inquires of the administration policy information database of a calculation server about the compile server corresponding to the calculation server in the library installation (see Section 2.4). If the information for accessing to a compile server cannot be acquired by our method, this function performs the compilation and registration of a library on a calculation server as usual. For the second problem, this function requires at least one server of the GridFTP as a going point for transmitting a library file between servers. We call this host as module repository. It is needed that it can be accessed from the both sides of a client and a server, and that an arbitrary file can be uploaded / downloaded there by a user’s authority. In a module repository, since multiple remote installation work may be done simultaneously, each library is distinguished and managed with the following information. • • • • •

User name Library name Library version number Date of executing installation Host name of the compile server

2.4. Administration policy automatic observance function This function automatically gets the administration policy information of a computational resource, and performs library installation along with it.

Figure 6. Administration policy automatic observance function In this function, the administration policy information of a computational resource is managed in a database of the information providing service called MDS (LDAP database accessed through the GSI) included in the Globus Toolkit. And this function is implemented in the following procedure (see Figure6). • In advance, the administrator of a computational resource registers the administration policy information for library installation into the MDS on that resource. The administrator can use the shell script offered by this function that performs the registration work automatically. • Just before executing installation, this system uses the MDS search command (grid-info-search) and gets the administration policy information from the MDS by a user’s authority. Then this system installs the library along with the administration policy information. The administration policy information on a calculation server is as follows, but it can be extended from now on if needed. • Path of the top folder for the library installation (libraries are distinguished by the user name, the library name, and the library version number under this folder) • Information for accessing its compile server • Value of the environment variable that is needed for

the library installation

2.5. Logging function This function outputs result of installation work as a log file for every server. If the library installation failed, this function outputs the cause of the failure (ex. failure of file transfer), and the name of the server where the failure has been occurred. In case of error on building a library file, this function saves the content of standard output and standard error output in the execution of the installation workflow. These files are used for a user to pursue the result of library installation. The paths of the log files are specified by a user when the shell script of this system is called.

2.6. Adaptability The notes for using this system are as follows. • This system can be used not only for the installation of GridRPC library but for that of MPI application program. • If installation workflows differ between servers, the installation environment definition file and the installation workflow definition file must be created newly. This is because only one installation workflow can be applied for one group of servers for the installation in this system. • In case of linking the library that can be run only on a specific server owing to the software license etc., the compile server function should not be used. In that case, in advance of the library installation, a user needs to grasp that such library is linked, and to describe the installation environment definition file so that the compile server function may not be used.

2.7. Countermeasure for the case the Globus Toolkit is not available In this system, instead of the Globus Toolkit, ssh and scp can be used for the installation work. And, single sign-on function is realized by ssh-agent. In the administration policy automatic observance function, a https server can be used instead of the MDS. In that case, different points from the case of the MDS are as follows. The path of the root certificate of the certificate authority (CA) of the server is specified in the installation environment definition file (1). A https client offered by this system is used instead of the MDS search command (2).

3. Whole operation This chapter shows how the functions described in Chapter 2 operate as a whole.

Firstly, the administrator of each computational resource registers its administration policy information to the MDS on that resource in advance. And, a user does the next work. 1. Prepares the source files of a library. 2. Creates an installation environment definition file and an installation workflow definition file. 3. Executes grid-proxy-init command on a client host, and draws up a proxy certificate. 4. Launches the shell script of this system. The operation performed in the shell script of this system is as follows (see Figure1). 1. (Outputs the logs of the following operation at any time.) 2. Reads the installation environment definition file and the installation workflow definition file. 3. If required, creates an installation package automatically. 4. Acquires the administration policy information on each resource from the MDS. 5. Transmits the source files to a module repository. 6. Performs remote command execution to a compile server so that the compile server downloads the source files from the module repository, compiles them, and uploads the library file to the module repository. 7. Performs remote command execution to each calculation server so that each calculation server downloads the library file from the module repository and registers it.

4. Operation test and evaluation 4.1. Operation test environment Operation test of this system was performed on the following condition using computers of Table1 for reproducing the grid whose calculation servers are heterogeneous and contain cluster environment. • One host in site 1 was used as a client host, all twelve hosts in Table1 were used as server hosts to be installed. Moreover, one host in site 1 was used as a module repository. • The library to be installed contains only one function of matrix multiplication, applying Ninf-G as a GridRPC system. • In the source file of a library, the socket library that has machine dependency in the compile method is included, and the installation package automatic creation function was used.

Table 1. Operation test environment. Site 1 (University of Electro-Communications) Globus Toolkit 2.4.3, Ninf-G Ver. 1.1.1, RedHat Linux 7.3 (x 5) Globus Toolkit 2.4.3, Ninf-G Ver. 1.1.1, Solaris 8 (x 1) OpenSSH 3.1p1, Ninf-G Ver. 1.1.1, RedHat Linux 7.3 (x 1) Site 2 (National Institute of Advanced Industrial Science and Technology) OpenSSH 3.6.1p2, Ninf-G Ver. 1.1.1, RedHat Linux 7.3 (x 5)

• Compile server for each server was set up so that four redundant compilations in site 1 and four redundant compilations in site 2 were avoided (see Section 2.4). And, the compile server function was used. • The host names of four calculation servers of site 1 and four calculation servers of site 2 had consecutive numbers. Then describing settings for them has done shortly by using a regular expression in the installation environment definition file. • Not only the Globus Toolkit, but ssh and scp were used as remote accessing tools (see Section 2.7). • A log file and an error output folder were specified, and the logging function was used. • The installation environment definition file and the installation workflow definition file for this test are shown in Figure2 (51 lines) and Figure3 (24 lines).

Table 2. Installation time in the conventional method at the operation test environment Number of characters which should be inputted correctly Number of mistake correction characters Total number of the inputted characters Keyboard input time Total number of input commands Computer processing time Installation time

2741 182 2923 48min.43sec. 121 1min.22sec. 50min.5sec.

twelve, calculation of installation time was performed assuming that two or more server groups exist by the same percentage as Table1. Installation time was calculated as the sum of the keyboard input time which is spent by the user’s keyboard input such as command input, and the computer processing time which is spent by a computer to perform ordered computational operation. Keyboard input time is calculated based on the following assumption. • The input time per character is 1 second. • The frequency of an input mistake is 1 time to 30 characters. The computer processing time was calculated as the sum of the time spent by each command which was measured by the gettimeofday function.

4.2. Operation test result

4.3. Evaluation by the comparison of installation time

Details of installation time Detailed installation time in the conventional method at the operation test environment (Table1) is shown in Table2. In the conventional method, it is assumed that multiple installation are performed sequentially. Detailed installation time in this system at the same environment is shown in Table3. If there is no dependency in use of a library file which occurs with using compile server, this system performs multiple installation automatically in parallel. Table3 shows that the keyboard input time for creating definition files occupies the great portion of the installation time of this system.

The conventional method and this system should be compared in point of the time spent by installation work (we call this installation time). The installation environment is same as the operation test in Section 4.1. When the number of servers exceeds

Comparison of installation time with many servers Installation time of the conventional method and this system with more servers than the operation test environment are calculated based on the measured data of the operation test. The calculated result is shown in Figure7.

As a result of operation test, we confirmed that this system had performed the remote library installation to all servers successfully along with the above-mentioned settings. Moreover, we confirmed that the installation package created automatically could be compiled on heterogeneous server environment. In addition, in the installation environment definition file, the burden of describing was saved by 8 hosts (48 lines) by using a regular expression for the host names of servers.

Conventional method Relis-G Relis-G (Without reusing definition files) Relis-G (Without outlining) Table 3. Installation time in Relis-G at the operation test environment Use compile server function Number of characters for commands which should be inputted correctly Number of characters of installation environment definition file Number of characters of installation workflow definition file Number of mistake correction characters Total number of the inputted characters Keyboard input time

yes

no

180

180

1571

1572

679

679

162

162

2592

2593

43min. 12sec. 4

43min. 13sec. 4

Total number of input commands 0.35sec. Computer processing 0.35sec. time other than this system Details of processing time of this system Initialization 0.57sec. 0.57sec. 0.54sec. Converting and reading 0.55sec. installation environment definition file 0.55sec. Converting and reading 0.55sec. installation workflow definition file Creating installation 1.13sec. 1.13sec. package Retrieving administra- 10.63sec. 4.83sec. tion policy 29.86sec. 15.98sec. (Parallel) Installation 0.01sec. 0.01sec. Finalization 43sec. 23sec. Computer processing time 43min. 43min. Installation time 55sec. 36sec.

]. 200 ni m [e 150 m it no 100 tia l 50 tas nI 0

4

8

12

24

36

Number of servers Figure 7. Installation time in the conventional method and Relis-G Figure7 shows that, without reusing definition files (compared with the next paragraph), when the number of servers is twelve or more, the installation time of this system is shorter than the conventional method. Effect of reusing definition files In this system, once an installation environment definition file and an installation workflow definition file are created, they can be reused when installing again to the same installation environment. Installation time of this system with reusing the definition files is shown in Figure7. This result shows that, when a user updates a library frequently for the reasons of debugging etc., this system greatly mitigates the user’s burden in installation of the second henceforth. Effect of outlining installation environment definition file In installation environment definition file, settings to the servers can be described shortly using a regular expression when using same remote access methods for multiple servers, such as a remote access tool (see Section 2.1). Installation time of this system when this outlining is not used is shown in Figure7. This result shows that installation time of this system is greatly reduced by outlining installation environment definition file. Effect of compile server function on computer processing time In compile server function, until a library file is created on a compile server and transferred to a module repository, the installation shell script which is running on a calculation server waits. The amount of increases of total com-

Difference of computer processing time Minimum waiting time on a calculation server Average waiting time on a calculation server Maximum waiting time on a calculation server 50 45 40 35 30 25 20 15 10 5 0

45

ert up m oc fo ec ne re ffi D

40

.]c 35 se[ 30 e im t 25 gn 20 is se 15 co rp 10

5 0 4

8

12

24

Number of servers

.] a cse no r[ e evr m ti se gn on iti ti a alu W cl ca

36

Figure 8. Impact of the compile server function to the installation time puter processing time by these process is shown in Figure8. The waiting time on a calculation server is also shown in Figure8. This result shows the following two things. Computer processing time becomes long about 3 to 43 seconds. The main causes of this are the transfer of a library file and the inquiry about the compile server corresponding to a calculation server by the administration policy automatic observance function (1). The waiting time on a calculation server does not change by the number of the servers. And, it is about an average of 5 seconds (2).

5. Related works As the system which makes installation of a program to computers easy, automatic software distribution systems used in the intranet such as office PCs exist[6, 20, 10, 21, 22, 27, 15, 24, 5]. However, these systems are not suitable for the grid as follows. The security mechanism based on technology required for the grid, such as SSL, is not arranged on a server (1). They are not implemented for operation on heterogeneous computers (2). Since distribution of compiled software is assumed, they cannot support compilation of the software on heterogeneous computers (3). In the existing software installation package automatic creation systems[12, 29, 9, 17, 26] , such as InstallShield, there is nothing that automatically creates the installation package which can be compiled on the heterogeneous server systems of a grid like this system. PCT4G[23] is a grid portal construction toolkit which a user can install a library to servers. It implemented remote installation by the Globus Toolkit and a shell script like this system. In this system, an installation workflow is described as an installation workflow definition file which

is not dependent on a shell, but, in PCT4G, it is described as a shell script. Moreover, some functions are not included in PCT4G, such as automatic creation of installation package for heterogeneous server systems, automatic avoidance of redundant compilation, and automatic observance of administration policy of a server. In addition, Since there is no function like the installation environment definition file that a user can describe the information on installation procedure shortly, in a situation with many servers, the burden of an installation executor becomes large. There are the grid middlewares which transmit program code to a server automatically at the calculation request time[25, 11]. In these systems, there is the strong point that a user does not need to perform any explicit program installation work, and can perform easily the distribution of program to servers. However, these systems have some problems. For example, only the program written in the Java language can be executed. Moreover, it is difficult for these systems to distribute a program efficiently combining highly efficient data transfer technology like the GridFTP. A part of other grid middlewares also offers the function of transmitting a program automatically[18, 3, 14, 19]. However, in those any, there are unsolved problems, such as compilation of a program in heterogeneous server systems.

6. Conclusions and Future works We designed and implemented the remote library install system Relis-G. In the development process of a grid application, this system enables a user to perform laborious library installation work easily, without logging in to servers which is the conventional method. This system offers high convenience on the occasion of execution of the program which uses a grid middleware such as GridRPC, and it makes it possible to use the grid more easily and efficiently which attracts attention as a next-generation high performance computation infrastructure. Future works for this system are as follows. • Efficient installation in updating a library by transferring only updated files • Supporting writing of an installation environment definition file • Combined use with the existing library automatic tuning systems • Automatic execution of library installation on computation request • Combined use with the directive-based grid programming environment OpenGR[16] • Application of this system into grid portals • Correspondence to OGSA (Open Grid Service Architecture) by implementing as a grid service

Acknowledgement The authors truly thank for providing a lot of advices and help on this work to Mr.Satoshi Sekiguchi, who is a director of Grid Technology Research Center of National Institute of Advanced Industrial Science and Technology, and also thank to Mr. Motonori Hirano of Software Research Associates, Inc.

References [1] Apache Ant Project. http://ant.apache.org/. [2] Business Process Execution Language for Web Services. http://www.ibm.com/developerworks/library/ws-bpel/. [3] Condor. http://www.cs.wisc.edu/condor/. [4] Crimson. http://xml.apache.org/crimson/. [5] Digital Factory Inc., Kondara MNU/Linux HPC 2.0. http://www.digitalfactory.co.jp/. [6] FUJITSU LIMITED, Systemwalker. http://systemwalker.fujitsu.com/jp/. [7] Globus Toolkit. http://www.globus.org/. [8] GNU autoconf. http://www.gnu.org/software/autoconf/. [9] GrapeCity Inc., InstallStudio. http://www.grapecity.com/. [10] Hammock Corporation, PALLET CONTROL. http://www.hammock.jp/pallet/. [11] H.Nakada, S.Matsuoka, and S.Sekiguchi. A Java-based Programming Environment for the Grid: Jojo. IPSJ Transactions on Advanced Computing Systems, 44(SIG 11):46–56, 2003. [12] InstallShield Software Corporation. http://www.installshield.com/. [13] K.Seimour, H.Nakada, S.Matsuoka, J. Dongarra, C.Lee, and H.Casanova. Overview of GridRPC: A Remote Procedure Call API for Grid Computing. In Proceedings of Grid Computing - Grid 2002, pages 274–278, 2002. [14] Legion. http://www.cs.virginia.edu/˜legion/. [15] M.Fujiu and K.Hakozaki. Development of Application Installer using JavaT M Distributed Object. In IPSJ SIGNotes Distributed System and internet Management technology, number 015-005, pages 25–30, 1999.

[16] M.Hirano, M.Sato, and Y.Tanaka. Opengr: A directivebased grid programming environment. In Proceedings of 5th International Symposium, ISHPC 2003, pages 552–563. International Workshop on OpenMP: Experiences and Implementations, 2003. [17] MindVision Software, Installer VISE. http://www.mindvision.com/. [18] NetSolve. http://icl.cs.utk.edu/netsolve/. [19] Nimrod. http://www.csse.monash.edu.au/˜davida/ nimrod.html/. [20] Novell Inc., ZENworks 6. http://www.novell.co.jp/. [21] Quality Corporation, QND Plus. http://www.quality.co.jp/. [22] S.Arakawa, K.Tanaka, M.Takeda, and Y.Matsui. Development of Software Distribution System RSU. In IPSJ SIGNotes Distributed Processing System, volume 1994, 1994. [23] S.Shirasuna, T.Suzumura, H.Nakada, and S.Matsuoka. Development of A Grid Portal Construction Toolkit (PCT4G) Supporting Application Installation and Data Distribution/Update. In IPSJ SIG Technical Reports 2003-HPC-95, SWoPP 2003, pages 173–178, 2003. [24] S.Tezuka, K.Kihara, S.Miyake, H.Furukawa, S.Morobayashi, and Y.Tsuyuki. PC-LAN Construction Support Tool: Easy Installer. IPSJ Journal, 37(02013):300–311, 1996. [25] T.Suzumura, S.Matsuoka, and H.Nakada. A Jini-based Computing Portal System. In Proceedings of SC2001, November 2001. [26] Wise Solutions Inc., Wise Installation System. http://www.wise.com/. [27] Y.Takamiya, A.Manabe, and S.Matsuoka. Lucie: A Fast Installation and Administration Tool for Large-scaled Clusters. In IPSJ Transactions on Advanced Computing Systems, volume 44, 2003. [28] Y.Tanaka, H.Nakada, S.Sekiguchi, T. Suzumura, and S.Matsuoka. Ninf-G: A Reference Implementation of RPC-based Programming Middleware for Grid Computing. Journal of Grid Computing, 1(1):41–51, 2003. http://ninf.apgrid.org/. [29] Zero G Software Inc., InstallAnywhere. http://www.zerog.com/.