3.8 KiB
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 / AW-95-06-01e Usage and Monitoring of IT Ressources at PSI
- AA-9500-142/AA-9500-142e 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, 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(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 and requires consent with IT Security.