55 lines
3.8 KiB
Markdown
55 lines
3.8 KiB
Markdown
# Guidelines
|
|
|
|
## General Directives
|
|
Regardless of the content of this documentation, all PSI directives have precedence and need to be applied/followed. Among others these are some of the most relevant ones regarding IT systems:
|
|
|
|
- [AW-95-06-01](https://DLS01P.PSI.CH/documents/jsp/qv?id=PSIcgc_fi20220000526102) / [AW-95-06-01e](https://DLS01P.PSI.CH/documents/jsp/qv?id=PSIcgc_fi20220000526095) Usage and Monitoring of IT Ressources at PSI
|
|
- [AA-9500-142](https://DLS01P.PSI.CH/documents/jsp/qv?pri=PSIcgc&ft=cgcDocument@STORE_MAIN_CGC&q_cgcId=ID22023011616445798386)/[AA-9500-142e](https://DLS01P.PSI.CH/documents/jsp/qv?id=PSIcgc_fi20230003212302) Handling of Software Updates
|
|
|
|
## Version Control
|
|
|
|
Everything must be in version control before being used on production systems. In particular, scripts and other software, SPEC files for packages, relevant documentation, Puppet code, etc.
|
|
|
|
|
|
## Hiera
|
|
The naming of the variables inside Hiera depends on the scope usage of the variables. The variables beeing used only inside one specific class will be named `base_class_name::variable` where `base_class_name` is the last part of class name, without the part before the last `::` separator. Example: the `permit_root_login` variable for the `profile::ssh_server` class will be named `ssh_server::permit_root_login`.
|
|
|
|
|
|
## External Code
|
|
Although the installation infrastructure makes large usage of external code the system has to avoid as much as possible dependency from external services availability. A WAN outage or a remote http server failure should not influence the installation system. For this reason, all the external code is mirrored internally in specific git repositories.
|
|
|
|
|
|
## Servers and services
|
|
Every server should support exactly one service, e.g. Puppet, or FTP. This makes the services more independent (e.g. for downtimes), simplifies the structure of the corresponding Puppet code, makes it easier to reason about the environment, and prevents conflicts regarding certain configuration settings.
|
|
|
|
### Naming Convention Nodes / Servers
|
|
|
|
Node/Server names have the form `lx-purpose-[0-9][0-9].psi.ch`, where `purpose` is the purpose of the server or the service provided by it. Example: `lx-boot-01.psi.ch` is the **boot** server
|
|
|
|
The production server always has an DNS alias `purpose.psi.ch` and clients should always use this alias to connect to the server.
|
|
|
|
When putting system names into configuration files, we always use lower case and the fully qualified domain name.
|
|
|
|
|
|
## Software Update Policy
|
|
|
|
It is in the responsibilty of the owner/administrator of a system to care about the software update policy and its application!
|
|
|
|
### Automatic Updates
|
|
|
|
By default once a week (in the night from Sunday to Monday) security updates are automatically applied. Other updates, including Kernel updates, need to be installed manually.
|
|
|
|
This is [configurable](configuration/package_updates), you may switch it off completely, make it run daily or make it install all updates.
|
|
|
|
Reboots are never done automatically.
|
|
|
|
Also for software which have been installed from other sources than RPM package repositories (like `pip` or manual install) there is no automatic update procedure.
|
|
|
|
### Snapshots
|
|
|
|
On specially protected systems where stability is more important than being up-to-date, there is the option to freeze the provided RPM package version to a specified date. Also this can be [configured in Hiera](configuration/package_repositories)(chapter "Using Specific Package Repository Snapshot"). If such a system is set by such a "Repo Tag" to a specific snapshot, the update procedure cannot get newer than the given state.
|
|
|
|
Again, this should only be done for nodes in protected networks, e.g. with access restrictions through an [ssh gateway](../services-admin-guide/ssh_gateways) and requires consent with IT Security.
|
|
|
|
|