pombas_n/documentation
0
0 Fork 0
forked from linux/documentation
Code Pull Requests Activity

update outdated documentation

Browse Source
This commit is contained in:
buchel_k committed 2025-04-04 10:10:37 +02:00
1 parent 459b914f55
commit a9990e4682
11 files changed
+5 -491
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

engineering-guide/puppet/profiles/afs_client.rst
-51
View File
@@ -1,51 +0,0 @@
``profile::afs_client``
============================
This module installs and configures the OpenAFS client.
On systems using AFS it is necessary to have the AFS kernel module for the
running kernel installed. This module installs the AFS kernel module for
**every** installed kernel (usually up to 3). Therefore it is recommended to run
Puppet after (kernel) updates.
Note: Simply including this profile is usually **not** enough to enable AFS on a
system. It is also necessary to enable AFS support when including
``profile::aaa``. The latter makes sure that AD is used for authentication and
configures PAM to automatically create and renew AFS tokens.
Parameters
----------
=============================== ======== ================================================
**Name** **Type** **Default**
------------------------------- -------- ------------------------------------------------
enable_dynroot bool hiera('afs_client::enable_dynroot')
min_cache_size int hiera('afs_client::min_cache_size')
mountpoint string hiera('afs_client::mountpoint')
root_volume string hiera('afs_client::root_volume')
=============================== ======== ================================================
``enable_dynroot``
~~~~~~~~~~~~~~~~~~
``min_cache_size``
~~~~~~~~~~~~~~~~~~
The minimum size for the local AFS cache. If the cache is smaller than this,
Puppet will try to resize the logical volume =lv_openafs=, otherwise Puppet will
leave it alone.
``mountpoint``
~~~~~~~~~~~~~~
Defines the mountpoint for the AFS filesystem.
``root_volume``
~~~~~~~~~~~~~~~
The name of the root volume to mount.
engineering-guide/puppet/profiles/ganglia_client.rst
-36
View File
@@ -1,36 +0,0 @@
``profile::ganglia_client``
============================
This module installs and configures Ganglia's gmond.
Parameters
----------
=============================== ======== ================================================
**Name** **Type** **Default**
------------------------------- -------- ------------------------------------------------
grid string hiera('ganglia::grid')
cluster string hiera('ganglia_client::cluster')
n/a hash hiera('ganglia::grid_${GRID}')
=============================== ======== ================================================
``grid``
~~~~~~~~
The name of the Ganglia grid the client is a part of.
``cluster``
~~~~~~~~~~~
The name of the Ganglia cluster within the grid the client is a part of.
``grid_${GRID}``
~~~~~~~~~~~~~~~~
The definition of the grid. See the :doc:`ganglia_server documentation
<../profiles/ganglia_server>` for details.
engineering-guide/puppet/profiles/ganglia_server.rst
-104
View File
@@ -1,104 +0,0 @@
``profile::ganglia_server``
===========================
This module configures the following Ganglia server components:
- the web interface (using Apache)
- one gmond for each cluster to be monitored by this server
The latter is a little unusual. Normally, the gmonds collecting the data for
each cluster, which are then queried by gmetad, are part of the cluster. The
implementation chosen by this module makes it easier to deal with firewalls.
Parameters
----------
=============================== ======== ================================================
**Name** **Type** **Default**
------------------------------- -------- ------------------------------------------------
grid string hiera('ganglia::grid')
grid_${GRID} hash hiera('ganglia::grid_${GRID}')
=============================== ======== ================================================
``grid``
~~~~~~~~
This string identifies the grid (ie the collection of clusters) this server
monitors. The definition of the grid is taken from the Hiera value
``grid_${GRID}``.
``grid_${GRID}``
~~~~~~~~~~~~~~~~
The definition of the Ganglia grid this server is responsible for. It is a hash
containing the following keys:
``name``
,,,,,,,,
The name of the grid as used in the web interface.
``ui``
,,,,,,
The FQDN of the server hosting the web UI and collecting the data for the grid.
A system with role ``ganglia_server`` will compare its own FQDN to this value
and fail if they are not equal. Clients will need this value to know where they
they should send their metrics.
``clusters``
,,,,,,,,,,,,
A hash of cluster definitions. The keys are the IDs of the clusters, ie. what a
client expects to find in ``ganglia::cluster``. The values are hashes containing
the following attributes:
``name``
........
The user-friendly name of the cluster to be used in the web UI.
``port``
........
The port used within the cluster. The first cluster should use 8649 (the Ganglia
standard port), the next cluster should use 8650, and so on.
Examples
--------
Suppose we have a Ganglia grid for Swissfel (sysdb_env == swissfel).
The we could put the following in Hiera.
In ``swissfel.yaml`` we would define grid, say ``sfel``, and set the grid for
all systems in the ``swissfel`` environment to ``sfel``::
ganglia::grid: 'sfel'
ganglia::grid_sfel:
name: 'SwissFEL'
ui: 'gmeta00.psi.ch'
clusters:
'sf-daqbuf':
name: 'DAQ Buffers'
port: 8649
'sf-athos'
name: 'Athos Beamline Systems'
port: 8650
In the ``swissfel/daqbuf.yaml`` we would then set the cluster to ``sf-daqbuf``::
ganglia::cluster: 'sf-daqbuf'
In ``swissfel/athos.yaml`` on the other hand, we would set the cluster to
``sf-athos``::
ganglia::cluster: 'sf-athos'
engineering-guide/puppet/profiles/log_client.rst
-93
View File
@@ -1,93 +0,0 @@
``profile::log_client``
=======================
This module manages the local logging-related configuration.
It can make the journal permanent, enable or disable legacy configuration files
(e.g. ``/var/log/messages``), and configure log forwarding.
Parameters
----------
============================ ======== ==================================================
**Name** **Type** **Default**
---------------------------- -------- --------------------------------------------------
forward_to list hiera('log_client::forward_to', [])
legacy_logs bool hiera('log_client::legacy_logs')
persistent_journal bool hiera('log_client::persistent_journal')
journal_system_keep_free string hiera('log_client::journal_system_keep_free')
journal_system_max_file_size string hiera('log_client::journal_system_max_file_size')
journal_system_max_use string hiera('log_client::journal_system_max_use')
============================ ======== ==================================================
``journal_system_keep_free``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
How much space `systemd-journald(8) <https://www.freedesktop.org/software/systemd/man/systemd-journald.html>`_ should keep free for non-journal
use in ``/var/log``. In addition to the syntax described in
`journald.conf(5) <https://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse=>`_ (bytes or use K, M, G, T, P, E as units) we also support percentages, ie ``'25%'`` means that
the journal will leave at least 25% of ``/var/log`` for other uses.
Note that for the use of a percentage limit ``/var/log`` must be an separate partition, else absolute values need to be set.
``journal_system_max_file_size``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The maximum size of individual journal files.
``journal_system_max_use``
~~~~~~~~~~~~~~~~~~~~~~~~~~
The maximum amount of space that the journal is allowed to use. In addition to
the syntax described in `journald.conf(5) <https://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse=>`_ (bytes or use K, M, G, T, P, E as units) we also support percentages,
ie ``'50%'`` means that the journal can use at most 50% of ``/var/log``.
Note that for the use of a percentage limit ``/var/log`` must be an separate partition, else absolute values need to be set.
``forward_to``
~~~~~~~~~~~~~~
An array of FQDNs, possibly prefixed with ``@`` for enabling TCP and followed by
a port number. Log messages are forwarded to all entries in this list.
``legacy_logs``
~~~~~~~~~~~~~~~
A boolean controlling whether the legacy log files (``/var/log/messages`` etc)
should be created (true) or not (false).
``persistent_journal``
~~~~~~~~~~~~~~~~~~~~~~
A boolean controlling whether the journal should be persistent (true) or not
(false).
Examples
--------
This profile is included in the base role. To customize the log_client in a
role, do this::
class role::some_role () {
class {'role::base':
include_log_client => false,
...
}
class {'profile::log_client':
legacy_logs => false,
persistent_journal => true,
}
In Hiera, configure forwarding to ``log1`` using UDP on port 1514 and to
``log2`` using TCP (on port 514)::
log_client::forward_to:
- 'log1.psi.ch:1514'
- '@log2.psi.ch'
engineering-guide/puppet/profiles/log_server.rst
-25
View File
@@ -1,25 +0,0 @@
``profile::log_server``
=============================
Parameters
----------
======== ========= =================================
**Name** **Type** **Default**
-------- --------- ---------------------------------
base_dir string hiera('log_server::base_log_dir')
rules list hiera('log_server::rules')
======== ========= =================================
``base_dir``
~~~~~~~~~~~~
This parameter designates the directory where the log data is stored.
``rules``
~~~~~~~~~
A list of rules to add to the end of ``/etc/rsyslog.conf``.
engineering-guide/puppet/profiles/mta.rst
-16
View File
@@ -1,16 +0,0 @@
``profile::mta``
================
This module manages configures the system's MTA, currently
:manpage:`postfix(1)`. At the moment it only configures a relay host and
restricts access to the loopback interface.
Parameters
----------
``relay``
~~~~~~~~~
The FQDN of a host that all outgoing mail will be forwarded to for delivery.
engineering-guide/puppet/profiles/nvidia.rst
-37
View File
@@ -1,37 +0,0 @@
``profile::nvidia``
===================
The purpose of this module is to install the NVIDIA drivers. If NVIDIA GPU cards are
detected with the facter ``pci_devices.gpu.nvidia``, automatically the ``profile::nvidia``
class will be called. The ``class profile::platform`` is responsible for calling this profile::
if ( $facts['pci_devices']['gpu']['nvidia'].size > 0 ) {
class { 'profile::nvidia':; }
}
By default the profile only installs the GPU drivers, which can be disabled setting ``nvidia::driver::enable`` to ``false``.
To enable CUDA installation ``nvidia::cuda::enable`` must be set to ``true`` (default
is ``false``).
Parameters
----------
============= ======== =======================================================
**Name** **Type** **Default**
------------- -------- -------------------------------------------------------
dgx boolean $::productname ? { /^DGX.*/ => true, default => false }
driver_enable boolean hiera('nvidia::driver::enable', true)
cuda_enable boolean hiera('nvidia::cuda::enable', true)
============= ======== =======================================================
``driver_enable``
~~~~~~~~~~~~~~~~~
Install the Nvidia GPU drivers. By default is ``true``.
``cuda_enable``
~~~~~~~~~~~~~~~
By default is ``false``. Set to ``true`` if you want to install CUDA.
engineering-guide/puppet/profiles/platform.rst
-47
View File
@@ -1,47 +0,0 @@
``profile::platform``
=====================
The purpose of this ``profile`` is to install specific components depending on the hardware components
and hardware/platform type.
Currently, for ``vmware`` machines no actions are performed. For ``physical`` machines some actions will
be performed depending on the parameter settings (see below).
Also, according to the facter ``manufacturer``, some specific actions can be triggered. Currently only
``HP``/``HPE`` hardware is considered.
Other options such like NVIDIA or Infiniband card detection are possible. Whenever detected, it will call
the corresponding class and will perform required actions.
Parameters
----------
================= ========== ===========
**Name** **Type** **Default**
----------------- ---------- -----------
enable_rasdaemon bool
enable_smartd bool
================= ========== ===========
``enable_rasdaemon``
~~~~~~~~~~~~~~~~~~~~
When set to ``true``, will install and enable the ``rasdaemon`` service.
``enable_smartd``
~~~~~~~~~~~~~~~~~
When set to ``true``, will install and enable the ``smartmontools`` (``smartd``) service.
Facts
-----
When some specific facts are detected, it will trigger some actions.
===================================== =============== ==============================================
**Fact** **Value(s)** **Action description**
------------------------------------- --------------- ----------------------------------------------
``manufacturer`` ``HP``|``HPE`` ``include profile::platform::hewlett_packard``
``['pci_devices']['gpu']['nvidia']`` count > 0 ``include profile::nvidia``
``['pci_devices']['ib']['mellanox']`` count > 0 ``include profile::infiniband``
===================================== =============== ==============================================
engineering-guide/puppet/profiles/pmodules.rst
-54
View File
@@ -1,54 +0,0 @@
``profile::pmodules``
=====================
This module manages the `AIT Pmodules
<https://amas.psi.ch/Pmodules/wiki/Pmodules>`_.
It automatically enables Pmodules for all users with
1. a UID >= 1000
2. a username **not** ending in ``-adm``
This makes sure that local service accounts, root, and administrator accounts do
not use Pmodules automatically.
Parameters
----------
================== ======== ==============================
**Name** **Type** **Default**
------------------ -------- ------------------------------
basedir string hiera('pmodules::basedir')
================== ======== ==============================
``basedir``
~~~~~~~~~~~
The subdirectory of ``/afs/psi.ch/sys/`` where the modules can be found, e.g.
``psi.x86_64_slp6`` or ``psi.ra``.
Examples
--------
This profile is included in the base role, but disabled. To enable Pmodules
simply pass ``enable_pmodules => true`` when including the base role::
class role::some_role () {
class {'role::base':
enable_pmodules => true,
...
}
...
To customize the base directory, include ``pmodules`` separately::
class role::some_role () {
include role::base
class {'profile::pmodules':
basedir => 'psi.ra',
}
...
engineering-guide/puppet/profiles/puppet_client.rst
-23
View File
@@ -1,23 +0,0 @@
``profile::puppet_client``
==========================
Parameters
----------
========== ========= =========================
**Name** **Type** **Default**
---------- --------- -------------------------
exec_time string ``05:00:00 -- 08:00:00``
========== ========= =========================
``exec_time``
~~~~~~~~~~~~~
Defines a time window during which Puppet will run every day. The exact time
depends on the FQDN of the system (see below), ensuring that on each system the
timing is consistent and predictable, but across a group of systems using the
same time window the exact times are distributed uniformly.
The syntax is ``HH:MM:SS -- HH:MM:SS``.
engineering-guide/puppet/profiles/serial_console.rst
+5 -5
View File
@@ -7,12 +7,12 @@ Configures the serial console on physical systems.
Parameters
----------
========= ========= ============
========= ========= ============================================
**Name** **Type** **Default**
--------- --------- ------------
device string ``ttyS0``
rate integer 115200
========= ========= ============
--------- --------- --------------------------------------------
device string ``hiera('serial_console::device', 'ttyS0')``
rate integer ``hiera('serial_console::rate', 115200)``
========= ========= ============================================
``device``