From a83ebb835bc53d03269cde86be9d48c6a8b894f1 Mon Sep 17 00:00:00 2001 From: ebner Date: Wed, 7 Aug 2024 14:58:04 +0200 Subject: [PATCH] removed obsolete docs --- _toc.yml | 5 -- .../authentication-authorization.rst | 17 ----- admin-guide/architecture/overview.rst | 55 ---------------- admin-guide/architecture/security.rst | 35 ---------- .../architecture/services-cron-etc.rst | 35 ---------- admin-guide/architecture/version-control.rst | 66 ------------------- 6 files changed, 213 deletions(-) delete mode 100644 admin-guide/architecture/authentication-authorization.rst delete mode 100644 admin-guide/architecture/overview.rst delete mode 100644 admin-guide/architecture/security.rst delete mode 100644 admin-guide/architecture/services-cron-etc.rst delete mode 100644 admin-guide/architecture/version-control.rst diff --git a/_toc.yml b/_toc.yml index 538f26f0..4165ebf0 100644 --- a/_toc.yml +++ b/_toc.yml @@ -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: diff --git a/admin-guide/architecture/authentication-authorization.rst b/admin-guide/architecture/authentication-authorization.rst deleted file mode 100644 index a8ed7bcc..00000000 --- a/admin-guide/architecture/authentication-authorization.rst +++ /dev/null @@ -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). diff --git a/admin-guide/architecture/overview.rst b/admin-guide/architecture/overview.rst deleted file mode 100644 index edabc167..00000000 --- a/admin-guide/architecture/overview.rst +++ /dev/null @@ -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 `_ for configuration management on Linux -systems. Configuration data is managed using `Hiera -`_. - -Scripts are generally written in bash or Python. diff --git a/admin-guide/architecture/security.rst b/admin-guide/architecture/security.rst deleted file mode 100644 index b99b3324..00000000 --- a/admin-guide/architecture/security.rst +++ /dev/null @@ -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 diff --git a/admin-guide/architecture/services-cron-etc.rst b/admin-guide/architecture/services-cron-etc.rst deleted file mode 100644 index 62db8eec..00000000 --- a/admin-guide/architecture/services-cron-etc.rst +++ /dev/null @@ -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. diff --git a/admin-guide/architecture/version-control.rst b/admin-guide/architecture/version-control.rst deleted file mode 100644 index f7d68b5e..00000000 --- a/admin-guide/architecture/version-control.rst +++ /dev/null @@ -1,66 +0,0 @@ -Version control ---------------- - -We use the internal `PSI Gitlab server `_ 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.