bootstrap (5) - Linux Manuals
bootstrap: xxQS_NAMExx bootstrap file
NAME
bootstrap - xxQS_NAMExx bootstrap file
DESCRIPTION
bootstrap contains parameters that are needed for the startup of xxQS_NAMExx components. It is created during the xxqs_name_sxx_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 xxQS_NAMExx cluster:admin_user
Administrative user account used by xxQS_NAMExx 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 xxQS_NAMExx 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 xxQS_NAMExx 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 xxQS_NAMExx 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 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 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 is obsolete since recent BDB versions don't support
RPC and support has been removed from xxQS_NAMExx; 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.
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/xxQS_NAME_Sxx/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
<xxqs_name_sxx_root>/bin
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 <xxqs_name_sxx_root>/<cell>/spool/qmaster.
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 <URL: http://dun.github.io/munge/ >).
Their availability depends on how xxQS_NAMExx 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
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
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.
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.
binary_path
The directory path where the xxQS_NAMExx binaries reside. It is used within
xxQS_NAMExx components to locate and startup other xxQS_NAMExx programs.
qmaster_spool_dir
The location where the master spool directory resides. Only the
and
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.
security_mode
The security mode defines the set of security features the installed
cluster is using, as a comma-separated list.
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
-kt/-at option).
jvm_threads
The number of JVM threads (allowed: 0-1, default set by installation, off: 0).
COPYRIGHT
See
for a full statement of rights and permissions.