The Config-Center is created to configure all of the GRM
components. To give the user the possibility to add a certain
component to a system and to setup an automatic configuration issues.
The Config-Center is a combination of 2 processes. The first process
is the “collecting” part which also contains the gui-mode. This
part fetches all userinput and collects them within a DataModel which
can be stored to a file. The second part is the configuration
executor. The process takes the collected user input from the
DataModel or if the input was stored to file, from the file and
configures a system using this input. This part can be also called
the automatic configuration.
The Config-Center provides different
switches. These switches will be static, but additional switches for
additional features are possible.
The currently supported switches are:
--log: is used for debugging and logging issues. It supports
different logging levels. The logging output will be written to
standard out.
(gui and auto mode)
-- state <filename>: is used for automatic configuration.
Using this switch in GUI mode, all settings will be stored into the
given <filename>. In combination with AUTO mode, the userinput
will be read from the statefile <filename>.
--mode <mode>: sets the installer mode. Currently supported
are GUI (interactive) mode and AUTO (noninteractive) mode. The
default is GUI
During installation the following directory stucture and
configuration is created:
Bootstrap configuration:
The bootstrapping includes, the
creation of complete (local) directory structure, setting up the
Security System, creating the parent startup configuration
file,
installing the startup scripts and booting/starting the jvm
where the Security Component is running on.
Executor configuration:
The executor component will be
configured and registered to the statup configuration, missing
directories will be created. If the Security Component runs not
locally
the Config-Center will fetch all necessary certificates
and files.
Resource Provider configuration
The
Resource Provider component will be configured and registered to the
statup configuration, missing directories will be created. If the
Security Component runs not locally
the Config-Center will fetch
all necessary certificates and files.
Service Container configuration
The Service Container
component will be configured and registered to the statup
configuration, missing directories will be created. If the Security
Component runs not locally
the Config-Center will fetch all
necessary certificates and files.
OS Dispatcher/ N1Sm Adapter configuration
The OS
Dispatcher/ N1Sm Adapterr component will be configured and
registered to the statup configuration, missing directories will be
created. If the Security Component runs not locally the
Config-Center will fetch all necessary certificates and files.
OS Provisioner configuration
The OS Provisioner component
will be configured and registered to the statup configuration,
missing directories will be created. If the Security Component runs
not locally the Config-Center will fetch all necessary certificates
and files.
The following diagram shows the
directory structure which will be created by the Control-Center
Directory structure
<GRM_DIST> (root user)
|
+-- bin
| +--- gconf
| +--- gstat
|
+-- man
| +--- man1
| +-- gconf.1
| +-- gstat.1
|
+-- lib
| +-- Haithabu.jar
| (may be grm_common.jar, grm_security.jar, grm_sc.jar, ...)
| +-- ext
| +-- nis.jar (JNDI nis provider, needed by JNDILoginModule)
| +-- ldap.jar (JNDI ldap provider, needed by JNDILoginModule)
| +-- <pam-login>.jar (PAMLoginModule)
+-- grm_util
| +-- install_grm
| +-- templates
| +-- jaas.config.template
| +-- java.policy.template
| +-- logging.properties.template
| +-- roles.config.template
| +-- rcgrm.sh.template (startup script for parent startup service)
<GRM_ETC> (admin user)
+-- logging.properties
<GRM_SHARED> (admin user)
+-- config
| +-- config.xml (global configuration)
| +-- startup_logging.properties (logging configuration for ParentStartupService)
| +-- logging.properties (default logging configuration for child jvms, used
| | if <GRM_ETC>/logging.properties is not available)
| +-- <configuration name>
| +-- config.xml
|
+-- run
| +-- <component identifier>_<host>_<interface>
+-- security
| +-- java.policy
| +-- jaas.config
| +-- roles.config
| +-- ca
<GRM_VAR> (root user)
+-- lib
| +-- (contains native libs for a jvm instance)
+-- log (admin user)
| +-- vm?_<host>.log
|
+-- run (admin user)
| +-- vm?.pid
+-- security (root user)
| +-- ca
| +-- daemons
| +-- users
+-- spool (admin user)
| +-- <component identifier>
|
+-- tmp (admin user)
| +-- <component identifier>
This diagram show the dependencies to Gridengine. The Hedeby components and the Control-Center are using libraries which are provided by a gridengine system. This means for the user, that for each Hedeby installation, a gridengine installation must be available. There is not need for a running grindengine installation, copiing the binaries is enough.
Dependencies to Gridengine
<SGE_DIST> == <SGE_ROOT>
|
+-- lib
| +-- jgdi.jar (java wrapper for gdi)
| +-- sge_ca.jar (java wrapper for sge_ca script)
| +-- sge_juti.jar (getpid for java, ...)
| +-- <arch>
| +-- libsge_juti.so (native parts of sge_juti.jar)
| +-- libjgdi.so (SGE, native parts of jgdi.jar)
| +-- libdrmaa.so (SGE)
| +-- libsll.so (SGE)
| +-- libcrypto.so (SGE)
|
+-- util
| +-- arch (SGE)
| +-- sgeCA (SGE)
| +-- sge_ca (SGE)
|
+-- utilbin
| +-- <arch>
| +-- adminrun (used by sge_ca)
| +-- infotext (used by sge_ca)
| +-- authuser