bootstrap.5

NAME

       bootstrap - Grid Engine bootstrap file

DESCRIPTION

       bootstrap contains parameters that are needed for the startup of Grid
       Engine components.  It is created during the sge_qmaster installation.
       Modifying bootstrap in a running system is not supported.

FORMAT

       The paragraphs that follow provide brief descriptions of the individual
       parameters that comprise the bootstrap configuration for a Grid Engine
       cluster:

   admin_user
       Administrative user account used by Grid Engine for all internal file
       handling (status spooling, message logging, etc.). Can be used in cases
       where the root account does not have the corresponding file access
       permissions (e.g. on a shared file system without global root
       read/write access).

       As a parameter set at installation time, changing admin_user in a
       running system is not supported. Changing it manually on a shut-down
       cluster is possible, but if access to the Grid Engine spooling area is
       interrupted, this will result in unpredictable behavior.

       The admin_user parameter has no default value, but instead it is
       defined during the master installation procedure.

   default_domain
       Only needed if your Grid Engine cluster covers hosts belonging to more
       than a single DNS domain. In this case it can be used if your hostname
       resolving yields both qualified and unqualified hostnames for the hosts
       in one of the DNS domains.  The value of default_domain is appended to
       the unqualified hostname to define a fully qualified hostname.  The
       default_domain parameter will have no effect if ignore_fqdn is set to
       "true".

       As a parameter set at installation time, changing default_domain in a
       running system is not supported. The default for default_domain is
       "none", in which case it will not be used.

   ignore_fqdn
       Ignore fully qualified domain name component of hostnames. Should be
       set if all hosts belonging to a Grid Engine cluster are part of a
       single DNS domain. It is switched on if set to either "true" or "1".
       Switching it on may solve problems with load reports due to different
       hostname resolutions across the cluster.

       As a parameter set at installation time, changing ignore_fqdn in a
       running system is not supported. The default for ignore_fqdn is "true".

   spooling_method
       Defines how sge_qmaster(8) writes its configuration and the status
       information of a running cluster.

       The available spooling methods are berkeleydb and classic.

   spooling_lib
       The name of a shared library containing the spooling_method to be
       loaded at sge_qmaster(8) initialization time.  The extension
       characterizing a shared library (.so, .sl, .dylib etc.) is not
       contained in spooling_lib.  The value should be the full filename less
       the extension, unless the shared library resides somewhere where the
       system will normally find it.

       If spooling_method was set to berkeleydb during installation,
       spooling_lib is set to libspoolb, and if classic was chosen as
       spooling_method, spooling_lib is set to libspoolc.

       Not all operating systems allow the dynamic loading of libraries. On
       these platforms a certain spooling method (default: berkeleydb) is
       compiled into the binaries and the parameter spooling_lib will be
       ignored.

   spooling_params
       Defines parameters of the chosen spooling method that are needed to
       initialize the spooling framework, e.g. to open database files.

       The spooling parameters value for spooling method berkeleydb is
         [rpc_server:]database directory[;options]
       e.g. "/opt/sge/default/spool/qmaster/spooldb" for spooling to a local
       filesystem, or "myhost:sge" for spooling over a Berkeley DB RPC server.

       rpc_server is obsolete since recent BDB versions don't support RPC and
       support has been removed from Grid Engine; it must be replaced if it
       occurs in an old configuration before an upgrade.  database directory
       is the directory containing the spool files, and options is a list of
       options for the database.  Currently the only valid value for options
       is private, which means to open the database with the DB_PRIVATE flag
       to specify that it is only accessed by a single process.  This allows
       the database directory to be on an NFSv3 filesystem (as opposed to an
       NFSv4 one, which is otherwise necessary), but it is unsafe to access it
       with any other program.  In particular, this means that the backup
       script (inst_sge -bup), similar scripts using the DB utilities,
       spooledit etc., must not be used while qmaster is running with
       berkeleydb spooling.

       For spooling method classic the spooling parameters take the form
       common_dir;qmaster spool dir, e.g.
       /sge/default/common;/sge/default/spool/qmaster.

   binary_path
       The directory path where the Grid Engine binaries reside. It is used
       within Grid Engine components to locate and startup other Grid Engine
       programs.

       The path name given here is searched for binaries as well as any
       directory below with a directory name equal to the current operating
       system architecture. Therefore, /usr/SGE/bin will work for all
       architectures, if the corresponding binaries are located in
       subdirectories named aix51, lx-amd64, lx-x86, hp11, hp11-64, sol-amd64,
       sol-sparc etc.

       The default location for the binary path is <sge_root>/bin

   qmaster_spool_dir
       The location where the master spool directory resides. Only the
       sge_qmaster(8) and sge_shadowd(8) need to have access to this
       directory.  The master spool directory - in particular the job_scripts
       directory and the messages log file - may become quite large, depending
       on the size of the cluster and the number of jobs. Be sure to allocate
       enough disk space and regularly clean off the log files, e.g. via a
       cron(8) job.

       As a parameter set at installation time, changing qmaster_spool_dir in
       a running system is not supported.

       The default location for the master spool directory is
       <sge_root>/<cell>/spool/qmaster.

   security_mode
       The security mode defines the set of security features the installed
       cluster is using, as a comma-separated list.

       Possible security mode settings are "none", "afs", "dce", "kerberos",
       "csp", "munge" (no additional security, AFS, DCE/GSSAPI,
       Kerberos/GSSAPI, X.509 certificate-based security, and MUNGE
       authentication  <http://dun.github.io/munge/>).    Their   availability
       depends on how Grid Engine was built/installed.

       The  "dce"  and  "kerberos"  methods are nearly equivalent, calling the
       GSSAPI security modules in the same way, whether they  were  built  for
       Kerberos/GSSAPI  or  DCE/GSSAPI,  except  that  "dce"  runs the program
       $SGE_ROOT/utilbin/$ARCH/starter_cred as  a  wrapper  for  the  shepherd
       unless NO_SECURITY is specified in execd_params in sge_conf(5).

       Only  the  CSP  and MUNGE methods are currently properly functional and
       safe (from the point of view of not  exposing  credentials  generally).
       Both  provide  user  authentication,  preventing impersonation of other
       users.  CSP requires certificates to be generated  for  each  user  and
       available on each host which the user can access; it is appropriate for
       a loosely coupled system, e.g. including desktop systems,  particularly
       as   it   protects  the  communication  stream  as  well  as  providing
       authentication.  MUNGE is appropriate  in  the  security  domain  of  a
       tightly  coupled system, such as a normal cluster, and allows operation
       with enforce_user=auto (see sge_conf(5);) it requires the munged daemon
       to  be  running  on each host, with a shared secret and doesn't encrypt
       the communication.

       NB.  Do not use AFS security without some means of user authentication,
       otherwise it is possible to submit jobs as another user and steal their
       credential from a job running on the same node.

   listener_threads
       The  number  of  listener  threads  (defaults  set  by   installation).
       Increasing   this  and/or  worker_threads  (below)  to  use  additional
       cores/hardware threads on the master host may  improve  performance  in
       demanding cases.

   worker_threads
       The number of qmaster worker threads (defaults set by installation).

   scheduler_threads
       The  number  of qmaster scheduler threads (allowed: 0-1, default set by
       installation: 1, off: 0; see qconf(1) -kt/-at option).

   jvm_threads
       The number of JVM threads (allowed: 0-1, default set  by  installation,
       off: 0).

COPYRIGHT

       See sge_intro(1) for a full statement of rights and permissions.



SGE 8.1.3pre                      2012-04-26                      BOOTSTRAP(5)