forked from Controls/gitea-pages
removed obsolete docs
This commit is contained in:
@@ -28,12 +28,7 @@ chapters:
|
||||
sections:
|
||||
- file: admin-guide/architecture
|
||||
sections:
|
||||
- file: admin-guide/architecture/overview
|
||||
- file: admin-guide/architecture/accounts-and-groups
|
||||
- file: admin-guide/architecture/authentication-authorization
|
||||
- file: admin-guide/architecture/services-cron-etc
|
||||
- file: admin-guide/architecture/version-control
|
||||
- file: admin-guide/architecture/security
|
||||
- file: admin-guide/architecture/active-directory
|
||||
- file: admin-guide/configuration
|
||||
sections:
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
Authentication and authorization
|
||||
================================
|
||||
|
||||
We use/support the following authentication mechanisms:
|
||||
|
||||
- SSH keys/certificates
|
||||
- Kerberos tickets (AD)
|
||||
- Password (checked against AD), not for the ``root`` account
|
||||
|
||||
Login is restricted to certain users and groups on each system. This is
|
||||
implemented locally using :manpage:`pam_access(8)`.
|
||||
|
||||
Shared Credentials
|
||||
------------------
|
||||
|
||||
Shared credentials should be avoided, eg. by using ``.k5login`` or
|
||||
``AuthorizedPrincipalsFile`` (see :manpage:`sshd_config(5)` for details).
|
||||
@@ -1,55 +0,0 @@
|
||||
Overview
|
||||
========
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
This guide is written using jupyterbook that accepts both ReStructured Text files (that's the system that was used initially)
|
||||
and Markdown.
|
||||
|
||||
Deployment
|
||||
----------
|
||||
|
||||
We generally deploy systems using PXE/Kickstart, even VMs. There is a VM
|
||||
template, but it only defines the standard hardware/VM settings. No software is
|
||||
pre-installed.
|
||||
|
||||
We use an iPXE image, which retrieves its client-specific configuration from a
|
||||
web service, which also generates the client-specific Kickstart file.
|
||||
|
||||
For systems where network booting isn't possible, eg. because DHCP isn't
|
||||
available, we can boot from USB as well.
|
||||
|
||||
The installation process is very roughly:
|
||||
|
||||
1. Install a minimal system plus the Puppet agent using Kickstart
|
||||
2. Reboot
|
||||
3. On first boot, run Puppet, which installs/configures the rest
|
||||
|
||||
|
||||
OS, Software, and Licenses
|
||||
--------------------------
|
||||
|
||||
We use Red Hat Enterprise Linux 7 (aka RHEL 7). The licenses are provided by
|
||||
ETHZ, and we mirror the software from their Satellite server locally. We do not
|
||||
have direct access to Red Hat support, but we can access the Red Hat customer
|
||||
portal.
|
||||
|
||||
In addition to RHEL, we use/make available the following:
|
||||
|
||||
- EPEL (all of it)
|
||||
- ELREPO (mostly for the Nvidia drivers)
|
||||
- Puppet
|
||||
- NoMachine
|
||||
|
||||
In addition there are several internal repositories.
|
||||
|
||||
|
||||
Configuration Management and Automation
|
||||
---------------------------------------
|
||||
|
||||
We use `Puppet <https://puppet.com>`_ for configuration management on Linux
|
||||
systems. Configuration data is managed using `Hiera
|
||||
<https://puppet.com/docs/puppet/5.3/hiera_intro.html>`_.
|
||||
|
||||
Scripts are generally written in bash or Python.
|
||||
@@ -1,35 +0,0 @@
|
||||
==========
|
||||
Security
|
||||
==========
|
||||
|
||||
Access Control
|
||||
--------------
|
||||
|
||||
Access control on systems is done using ``pam_access``, ``pam_listfile``, etc.
|
||||
By default, remote access is only granted to certain users/groups configured in
|
||||
Hiera (see ``profile::aaa`` for details). Local access is currently
|
||||
unrestricted, ie. every valid PSI Linux account can log in locally.
|
||||
|
||||
|
||||
``root`` login
|
||||
--------------
|
||||
|
||||
- only with keys/Kerberos tickets
|
||||
- only through bastion hosts (wmgt*, two-factor auth) by default
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
SELinux
|
||||
-------
|
||||
|
||||
- depends on the role, enforcing by default, enforcing on all infrastructure
|
||||
systems
|
||||
|
||||
|
||||
Firewall/tcpwrappers
|
||||
--------------------
|
||||
|
||||
- tcpwrappers yes
|
||||
- firewall no
|
||||
@@ -1,35 +0,0 @@
|
||||
=========
|
||||
systemd
|
||||
=========
|
||||
|
||||
|
||||
SysV init scripts
|
||||
-----------------
|
||||
|
||||
We only use SysV init scripts if systemd unit files are not provided by the
|
||||
software in question. Our own services are all configured through systemd unit
|
||||
files.
|
||||
|
||||
|
||||
``cron`` vs. systemd timers
|
||||
---------------------------
|
||||
|
||||
While we start/enable cron by default, we use systemd timers for everything. The
|
||||
advantages are:
|
||||
|
||||
- unified view with other system entities, eg. services, mounts, devices
|
||||
- easy log filtering with ``journalctl -u TIMER``
|
||||
- easy introspection via ``systemctl list-timers``, ``systemctl cat TIMER``,
|
||||
etc.
|
||||
|
||||
|
||||
Mounts
|
||||
------
|
||||
|
||||
Mounts, including automounts, are configured in /etc/fstab. Generating the mount
|
||||
units directly leads to certain difficulties (SELinux problems which we never
|
||||
quite figured out, stale mount unit files when the mountpoint changes, etc).
|
||||
Automounts can be configured by adding ``x-systemd.automount`` to the mount
|
||||
options.
|
||||
|
||||
We do start the ``autofs`` service on some systems, to provide the ``-net`` map.
|
||||
@@ -1,66 +0,0 @@
|
||||
Version control
|
||||
---------------
|
||||
|
||||
We use the internal `PSI Gitlab server <https://git.psi.ch/>`_ for version
|
||||
control. On this server we use a single repository group (``linux-infra``) for
|
||||
all infrastructure-related repositories, because this way a number of things
|
||||
have to be configured only once, e.g. members. In addition milestones and labels
|
||||
are group-wide concepts in Gitlab, and it is very useful to have those apply to
|
||||
all repositories. Finally it is easy to see all issues and merge requests for a
|
||||
repository group.
|
||||
|
||||
|
||||
Repositories
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Our repositories are configured in the following way:
|
||||
|
||||
The ``puppet`` repository
|
||||
.........................
|
||||
|
||||
- Fast-forward merges only
|
||||
|
||||
This keeps the history linear without merge commits, which makes it easier to
|
||||
read.
|
||||
|
||||
- Merges to ``prod`` or ``preprod`` require one approval
|
||||
|
||||
- Approval is revoked when further changes are pushed to an already approved
|
||||
merge request.
|
||||
|
||||
- The default branch is called ``prod``. There is no ``master`` branch.
|
||||
- The ``prod`` branch is protected.
|
||||
- The ``preprod`` branch is protected.
|
||||
|
||||
|
||||
Hiera repositories
|
||||
..................
|
||||
|
||||
These repositories contain Hiera data. There is exactly one repository per sysdb
|
||||
environment. The repository for environment ``foo`` is called ``data-foo``.
|
||||
|
||||
Access is granted to the owner and admins of the corresponding sysdb environment.
|
||||
|
||||
|
||||
Development workflow
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We steer development through Gitlab issues.
|
||||
|
||||
For every change, be it a new feature, bug fix, or improvement, we create an
|
||||
issue on the relevant repository. Issues that have broader implications and do
|
||||
not naturally belong to a code repository, go into the ``org`` repository. An
|
||||
example would be a change of the development workflow or repository
|
||||
authorization.
|
||||
|
||||
When starting work on a change, the developer first assigns the issue to
|
||||
themselves.
|
||||
|
||||
Once the developer has finished development and tested the change, they rebase
|
||||
their changes to the ``prod`` branch, push the changes to a new branch, and
|
||||
opens a merge request to the ``preprod`` branch. Each issue ``#N`` being fixed
|
||||
must be mentioned at the start of the commit message in the form ``Fix #N``.
|
||||
|
||||
Other developers will review the merge request. If they approve it, either the
|
||||
approving or the original developer may accept it, which will trigger the actual
|
||||
merge.
|
||||
Reference in New Issue
Block a user