bionic (5) sge_bootstrap.5.gz

Provided by: gridengine-common_8.1.9+dfsg-7build1_all bug

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).

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