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.

       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://munge.googlecode.com/⟩).  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.