zimoch/Controls-docs
0
0
Fork 0
forked from Controls/gitea-pages
Code Pull Requests Actions Activity

move documentation to the right place

Browse Source
This commit is contained in:
buchel_k
2024-10-04 10:58:05 +02:00
parent 4bca76909d
commit 497ccc3e0b
4 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
admin-guide/accounts-and-groups.md
-129
View File
@@ -1,129 +0,0 @@
# Accounts
Linux accounts are generally stored and managed in Active Directory.
```{note}
Current user (uid) and group (gid) ranges can be found here: [UID and GID Management](_static/UID_and_GID.pdf)
```
## Account Types
There are several types of accounts, which are usually indicated by a
prefix or suffix:
- Normal accounts. No prefix or suffix. Older accounts are just last
names, newer accounts are LASTNAME_X, where X is the first letter of
the given name.
- Global accounts. These have a `gac-` prefix. There are only a
handful of these on Linux so far, due to concerns about the lack of
login restrictions.
- Administrator accounts. Marked with an `-adm` suffix.
- External users. These start with an `ext-` prefix and are provided
to external users, ie. those who are not PSI employees.
- Service accounts. These come with an `svcusr-` prefix and are used
for running services.
Official documentation on PSI IT account naming convention can be found [here](https://psi.service-now.com/psisp?sys_kb_id=c498a3cb1bff68502c5940498b4bcb44&id=kb_article_view&sysparm_rank=1&sysparm_tsqueryId=4877d78687cc1d10bc150d830cbb3540)
## UID Allocation
| UID | GID | |
|-------------------------|-------------------------|-------------------------------|
| 0 - 1000 | 100 - 1000 | local users / groups manually |
| 1000 - 9999 | 110 - 9999 | old AD accounts manually |
| 10000 - 29999 | 10000 - 29999 | e-accounts / p-groups Experiment prov. tool |
| 30000 - 65534 | 30000 - 65534 | new AD users / groups /external AD accounts OM msSFU30UidNumber |
| 70000 - 120000 | 70000 - 120000 | e-accounts / p-groups Experiment prov. tool |
| 123458 - 150000 | -10000 - -4294967296 | local AFS users / groups AFS |
| 200000 - 400000 | 200000 - 400000 | new AD users / groups /external AD accounts IAM msSFU30UidNumber |
| 2000000000 - 4294967296 | 2000000000 - 4294967296 | sub UID / GID for containers local Linux systems / local Windows subsystems for Linux |
## LDAP Attribute Mapping
| Attribute | LDAP Attribute |
|-----------|------------------------|
| username | `msSFU30Name` |
| UID | `msSFU30UidNumber` |
| GID | `msSFU30GidNumber` |
| home | `msSFU30HomeDirectory` |
| shell | `msSFU30LoginShell` |
## Primary Groups
At PSI the user-private group scheme (UPG), the default on Red Hat
distributions, is **not** used. Instead, every user\'s primary group is
usually one specific to the group/department the user is working for,
eg. `unx-ait`.
Users for whom there is no natural choice of primary group are assigned
`unx-nogroup`.
## Low GIDs
A number of groups have very low GIDs (\<500), in particular:
unx-fkt:*:101:
unx-lke:*:110:
unx-abe:*:120:stingelin
unx-aea:*:130:
unx-lmu:*:140:
unx-lem:*:141:
unx-muesr:*:150:
unx-asm:*:210:
unx-lrp:*:220:
unx-zrp:*:221:
unx-ash:*:230:
unx-ppt:*:280:
unx-pmr:*:290:
unx-cmt:*:301:
unx-lfk:*:310:
unx-lch:*:320:
unx-lns:*:330:
unx-lap:*:340:
unx-lmn:*:350:
unx-asq:*:360:
unx-crpp:*:370:
unx-psq:*:380:
unx-psz:*:390:
unx-gabe:*:402:
unx-lrs:*:410:
unx-lth:*:420:
unx-lwv:*:430:
unx-les:*:440:
unx-dtp:*:451:
unx-lsu:*:490:
## Shells
We support bash, and we also try to keep tcsh working.
Currently bash, tcsh, and sh are used. The form for ordering accounts
also offers `/bin/ksh` and `/bin/zsh`. The most popular by far is bash.
## Special Accounts
### `linux_ldap`: query LDAP
The [linux_ldap]{.title-ref} account has read-only permissions on a
limited subset of the LDAP attributes. It is used by
[nslcd]{.title-ref}, for example, to query LDAP for users\' uid, gid,
etc.
The password should not be shared unnecessarily, but it does not need to
be specifically protected either. In fact, in earlier releases of
Scientific Linux it was necessary to have [/etc/nslcd.conf]{.title-ref},
which contains the password, world-readable.
This account **must not** be given additional access or privileges.
### `linuxadjoin.psi.ch@D.PSI.CH`
This account is a pure AD account (ie it doesn\'t have Unix attributes
like uid), which is used to manage computer objects in AD automatically.
In particular, it is used to precreate computer objects to allow
password-less AD joins.
The account is only used on the Puppet server and has no (known)
password. Instead a keytab is used to get a valid Kerberos ticket.
admin-guide/active-directory.md
-64
View File
@@ -1,64 +0,0 @@
# Active Directory
## Kerberos Realm and Settings
The AD domain (ie the Kerberos realm) is D.PSI.CH, **not** PSI.CH. The maximum
lifetime of a ticket is about a day, and a ticket can be renewed for about a
week.
## Domain Controllers
In most networks `d.psi.ch` resolves to the correct names/IPs. One exception
is the DMZ.
The domain controllers that are used internally are:
- `dc00`
- `dc01`
- `dc02`
In the DMZ we need to use these instead:
- `rodc00`
- `rodc01`
It is important to note that the SSL certificates for the internal DCs are
**not** signed for `dc0n.psi.ch`, but `dc0n.d.psi.ch` (note the extra `d`).
In certain contexts (eg in [`sssd.conf(5)`](https://linux.die.net/man/5/sssd.conf)) specifying the DCs as
`dc0n.psi.ch` fails because of this.
## Linux Computer Objects
Computer objects for Linux systems are created in
`OU=linux,OU=servers,OU=psi,DC=d,DC=psi,DC=ch`. We currently do not distinguish
between servers and workstations in AD (unlike the Windows team), as the
distinction isn't clear and it wouldn't help us anyway (as we don't use AD group
policies).
We perform the join password-less, by pre-creating the computer object using a
script running on the Puppet master.
As the AD only support [computer account aka NetBIOS names with maximum 15 characters](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/naming-conventions-for-computer-domain-site-ou#netbios-computer-names) it shortens longer hostnames down to the first 15 characters. This is a bit unfortunate as this name has to be unique as it serves as primary identifier in the AD.
To work around this limitation we use a different NetBIOS name if the hostname is longer than 15 characters which is less prone to collisions ([inspiration](https://www.beyondtrust.com/docs/ad-bridge/how-to/delegate-domain-join-privileges/ad-naming-limitations.htm)).
The actual NetBIOS name we use for these hosts is the first 7 characters of the name, then a `-` followed by the last 7 characters of the SHA256 hash of the fully qualified domain name. To check the NetBIOS name of a given host run
```
klist -t -k /etc/krb5.keytab
```
and look at the first entry, here for an example with a sufficiently short name:
```
15 07.03.2023 09:23:02 PUPPET01$@D.PSI.CH
```
here `lx-sysdb-test-00.psi.ch` which gets a hashed NetBIOS hostname
```
3 05/12/23 08:39:15 lx-sysd-3563a67$@D.PSI.CH
```
or `merlin-export-01.psi.ch` which has an automatically shortend NetBIOS name which was joined before we started to use the hashed NetBIOS hostnames:
```
7 29.10.2019 11:24:04 MERLIN-EXPORT-0$@D.PSI.CH
```
admin-guide/custom_repositories.md
+90
View File
@@ -0,0 +1,90 @@
# Custom RPM Repositories
It is possible to manage own RPM repositories which are accessible inside PSI.
If you need one please contact the Linux Core team (linux-eng@psi.ch).
To setup the your custom repository/ies we need following information:
- Name of the repository
- Do you want to have your repository available for __all__ RHEL major versions (i.e. all RHEL major versions will see the same packages) or do you need a repository for each RHEL major version (i.e. you can have different packages for each RHEL major version)?
## Usage
On `lxsup.psi.ch` you can easily access this data on `/packages_misc`.
The backend for these custom repos is on a NFS4 share. This share can be mounted from __lx-fs:/packages_misc__
On __Linux__ systems you should be able to mount the share like this
```bash
mount -t nfs4 -o sec=krb5 lx-fs.psi.ch:/packages_misc /mnt
```
On __MacOS__ you could mount and access the share like this:
```bash
mount_nfs -o sec=krb5,nfsvers=4 lx-fs.psi.ch:/packages_misc ~/some_directory
```
(on __Windows__ - it should be/is also possible with Windows >=10 to mount the NFS4 share- https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mount - details to be added here)
Once your folder/folders is/are created and your are autorized to write into these folders you can place RPMs and files into that directory/directories
__Important__: Once mounted, to be able to change things on the filesystem you have to have a valid kerberosticket for your PSI user.
```
kinit <username>@D.PSI.CH
# or on standard PSI linux systems
kinit
```
## Overview
Custom repositories are provided by the central repository server as all other repositories. They will be available on the URL
```
https://repos.psi.ch/<os>/latest/<repository_name>
```
The custom repositories are snapshotted and tagged as any other repository.
Inside __hiera__ please use the URL:
```
https://$lx_reposerver/<os>/$lx_repo_tag/<repository_name>
```
This ensures that the systems will always use the correct repository server url to access the repositories. (e.g. in the DMZ/extranet the DNS hostname of the repository is different ...)
The content of the custom repositories are managed on a a dedicated NFS4 share. On this share groups can have different folders where they place/manage their rpms. These RPMs are periodically synced to the main repository share (i.e. every 15 minutes), so what you see on the `packages_misc` is not exactly what will end up on the repository server. Upon sync the repository will be automatically build via the create-repo command.
The structure of the share is usually as follows:
```
<base>/<repository name>
# content in the case of one repo for all major RHEL version
/rhel7
/rhel8
/rhle9 # in case of different repo for major RHEL version
```
The access control is done by a Unix group usually named `unx-<something>_adm` (most of the time this is a group that also gives access to hiera repos)
## Preparation for new Custom RPM Repository (by Linux Team)
The `packages_misc` share is only root writeable from lx-sync-01.psi.ch. Therefore the initial setup needs to be done there.
Creation of a new repo (on lx-sync-01 in `/packages_misc`):
```
cd /packages_misc
mkdir <reponame>
chgrp 35588 <reponame> ## We need to use the numeric group id here as lx-sync is not directly connected to AD
chmod g+w <reponame>
chmod g+s <reponame>
```
To sync the repo and make it available there needs to be a sync config added to https://git.psi.ch/linux-infra/rpm-repo-utils/-/tree/main/etc?ref_type=heads
(inside the __*-misc__ directories)
After adding this config the changes need to be deployed on lx-sync-01.psi.ch.
(either bootstrap/ansible or a manual `git pull` in `/opt/rpm-repo-utils/`)