pombas_n/documentation
0
0 Fork 0
forked from linux/documentation
Code Pull Requests Activity

fix gitserver urls

Browse Source
This commit is contained in:
ebner committed 2025-05-07 14:34:07 +02:00
1 parent 254cca758c
commit 324146456b
32 files changed
+56 -70
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

_config.yml
+1 -1
View File
@@ -19,7 +19,7 @@ latex:
# Information about where the book exists on the web
repository:
url: https://git.psi.ch/linux-infra/documentation # The URL to your book's repository
url: https://gitea.psi.ch/linux/documentation # The URL to your book's repository
# path_to_book: documentation # Optional path to your book, relative to the repository root
branch: master # Which branch of the repository should be used when creating links (optional)
admin-guide/certificates.md
+2 -2
View File
@@ -52,8 +52,8 @@ DigiCert will send an email including instructions on how to download the certif
Our teams practice is to always create a new private key and to back it up encrypted in Gitlab, either
- in Hiera as [EYAML](https://linux.psi.ch/admin-guide/puppet/hiera.html#secret-values)
- for central infrastructure hosts GPG encrypted in their [bootstrap repository](https://git.psi.ch/linux-infra/bootstrap)
- for the rest in our [team secret store](https://git.psi.ch/linux-infra/core-linux-secrets)
- for central infrastructure hosts GPG encrypted in their [bootstrap repository](https://gitea.psi.ch/lx/bootstrap)
- for the rest in our [team secret store](https://gitea.psi.ch/lx/core-linux-secrets)
## Renew Certificate
admin-guide/configuration/access/bastion_hosts.md
+1 -1
View File
@@ -2,7 +2,7 @@
Access for the `root` user can be limited to be only allowed from certain bastion hosts.
By default this is enabled except for a few networks, see [reponsible Puppet code](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/code/modules/profile/manifests/networking/params.pp) for details.
By default this is enabled except for a few networks, see [reponsible Puppet code](https://gitea.psi.ch/puppet/puppet/src/branch/preprod/code/modules/profile/manifests/networking/params.pp) for details.
You may alternatively control the use of bastion hosts yourself by setting in Hiera the boolean value `aaa::user_bastions`.
admin-guide/configuration/files/distribute_files.md
+2 -2
View File
@@ -92,7 +92,7 @@ Example:
files::git:
/var/test/container-images:
ensure: latest
url: 'https://git.psi.ch/linux-infra/container_images.git'
url: 'https://gitea.psi.ch/linux/documentation.git'
revision: 'main'
```
@@ -183,7 +183,7 @@ As you see in above example the actual download URL is combined with `url-prefix
**Please migrate your `filecopy::files` configurations to `files::download`**
Files to download need to be placed on a git repository on `git.psi.ch` (internal) or `gitlab.psi.ch` (DMZ, Extranet, Tier3), where they need to be publicly available.
Files to download need to be placed on a git repository on `gitea.psi.ch`.
For configuration in Hiera there is the `filecopy::files` hash where the keys is the destination path of the file. And the value is another hash with following options:
admin-guide/configuration/monitoring/metrics_telegraf.md
+1 -2
View File
@@ -7,8 +7,7 @@ Following statement will enable the metrics collection:
base::enable_telegraf: true
```
By default a number of metrics are collected, including cpu, disk usage, diskio, etc.
A detailed list with the defaults can be found in [common.yaml](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml#L855) of the puppet repository.
By default a number of metrics are collected, including cpu, disk usage, diskio, etc. .
Custom metrics can also be added. (documentation to be done - please contact the Linux Core group if you need this).
admin-guide/configuration/software/package_repositories.md
+5 -5
View File
@@ -12,7 +12,7 @@ rpm_repos::default:
Note that repositories for different versions of RHEL can be added and only the fitting ones will be configured on the node.
If the package repositories are managed by a Puppet module, then it is good practice is to define a specific package repository list in [`common.yaml`](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml) and then to install it only when needed. An example is `profile::telegraf` which only installes the repositories listed in `rpm_repos::influx` when needed.
If the package repositories are managed by a Puppet module, then it is good practice is to define a specific package repository list in [`common.yaml`](https://gitea.psi.ch/puppet/puppet/src/branch/preprod/data/common.yaml) and then to install it only when needed. An example is `profile::telegraf` which only installes the repositories listed in `rpm_repos::influx` when needed.
## Package Repository Definition
@@ -43,7 +43,7 @@ Overriding the URL of a package repository definition on a stricter scope is con
If different sources are needed, define and name them appropriately. They point to one given repository and the package repository lists are the place to select what should be applied on a given node.
Also feel free to define all your package repositories in [`common.yaml`](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml).
Also feel free to define all your package repositories in [`common.yaml`](https://gitea.psi.ch/puppet/puppet/src/branch/preprod/data/common.yaml).
### Select Package Repository by OS Version
@@ -104,7 +104,7 @@ Predefined and used when needed are:
- CUDA
- Nomachine
To be added/defined in [`common.yaml`](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml)?
To be added/defined in [`common.yaml`](https://gitea.psi.ch/puppet/puppet/src/branch/preprod/data/common.yaml)?
- GPFS
- Epics (available for RHEL7)
@@ -121,12 +121,12 @@ A small list of packages managed by the Linux Team.
- latest [Real VNC Viewer](https://www.realvnc.com/en/connect/download/viewer/), recommended for VNC remote access to Windows machines
- `pli-assets` containing the PSI and the Customer Self Service logo, any hints about the source rpm are welcome
- *RHEL8*: [mod_gearman v4.0.1](https://mod-gearman.org/download/v4.0.1/rhel8/x86_64/)
- *RHEL8*: lightdm-gtk v2.0.8-3.pli, a patched lightdm-gtk-greeter ([SRPM](https://git.psi.ch/linux-infra/lightdm-gtk-rpm), [PR](https://github.com/Xubuntu/lightdm-gtk-greeter/pull/121)) which allows to limit the presented keyboard layouts
- *RHEL8*: lightdm-gtk v2.0.8-3.pli, a patched lightdm-gtk-greeter ([SRPM](https://gitea.psi.ch/linux/lightdm-gtk-rpm), [PR](https://github.com/Xubuntu/lightdm-gtk-greeter/pull/121)) which allows to limit the presented keyboard layouts
- Code Beamer Office pluging v9.5.0 managed by Gilles Martin
- storecli 007.2007.0000.0000 managed by Marc Caubet Serrabou
- [pam_single_kcm_cache PAM Module](https://github.com/paulscherrerinstitute/pam_single_kcm_cache) managed by Konrad Bucheli
- [nvidia-detect](http://elrepo.org/tiki/nvidia-detect) copied over from ElRepo to make it generally available
- [bob](https://git.psi.ch/linux-infra/bob)
- [bob](https://gitea.psi.ch/linux/bob)
## Package Repositories made Available by other PSI Groups
admin-guide/configuration/software/packages.md
+1 -1
View File
@@ -7,7 +7,7 @@ The packages automatically installed onto a system by Puppet are managed in the
The package groups itself are Hieara lists named `base::pkg_group::$USE_CASE`.
Here list all the packages you want to install.
Currently there exist the following package groups in the main [`common.yaml`](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml):
Currently there exist the following package groups in the main [`common.yaml`](https://gitea.psi.ch/puppet/puppet/src/branch/preprod/data/common.yaml):
- `base::pkg_group::system_tools` (installed by default)
- `base::pkg_group::daq_buffer`
admin-guide/deployment/basic_installation.md
+3 -3
View File
@@ -16,9 +16,9 @@ The general process for a installation is:
3. Reboot the system and trigger a PXE boot (usually by pressing F12 during
POST)
The default way to interact with sysdb is to use [bob](https://git.psi.ch/linux-infra/bob). `bob` is already set up on `lxsup.psi.ch` for general use. Remember that you need a valid Kerberos ticket before modifying a sysdb entry via `bob`.
The default way to interact with sysdb is to use [bob](https://gitea.psi.ch/linux/bob). `bob` is already set up on `lxsup.psi.ch` for general use. Remember that you need a valid Kerberos ticket before modifying a sysdb entry via `bob`.
Altenatively you many have on your workstation a local copy of `bob`. This can be done by installing the RPM from the pli-misc repository - https://repos.psi.ch/rhel8/latest/pli-misc/ or by installing the Python package manually. More details regaring `bob` can be found [here](https://git.psi.ch/linux-infra/bob).
Altenatively you many have on your workstation a local copy of `bob`. This can be done by installing the RPM from the pli-misc repository - https://repos.psi.ch/rhel8/latest/pli-misc/ or by installing the Python package manually. More details regaring `bob` can be found [here](https://gitea.psi.ch/linux/bob).
## Hardware/VM Requirements
@@ -115,7 +115,7 @@ bob node set-attr $FQDN system_disk=disk/by-path/pci-0000:a1:00.0-ata-1
#### Custom Partitioning
Partitions system are configured with a standard schema using LVM, so that they can be possibly changed afterwards.
It is also possible to customize the partitioning by using the `partitions` attribute on sysdb. See https://git.psi.ch/linux-infra/bob for more details.
It is also possible to customize the partitioning by using the `partitions` attribute on sysdb. See https://gitea.psi.ch/linux/bob for more details.
## BIOS / UEFI Boot
admin-guide/puppet/hiera.md
+3 -3
View File
@@ -35,10 +35,10 @@ The ``%{variable}`` notation is hiera specific.
## Repositories
Hiera data are organized in different repositories. These repositories are located at: https://git.psi.ch/linux-infra/hiera
Hiera data are organized in different repositories. These repositories are located at: https://gitea.psi.ch/puppet
Each __sysdb environment__ has a dedicated hiera repository, called ``data-<sydbenv>``, eg. [data-hpc]( https://git.psi.ch/linux-infra/hiera/data-hpc).
Each __sysdb environment__ has a dedicated hiera repository, called ``data-<sydbenv>``, eg. [data-hpc]( https://gitea.psi.ch/puppet/data-hpc).
The first 4 levels of the filesystem structure shown before are actually the files inside this kind of repositories.
Any change to the repo will automatically trigger a redeployment of the new version of its content on the puppet master within a few seconds from the push.
@@ -68,7 +68,7 @@ You can edit secure data inside any yaml file with the command `/opt/puppetlabs/
### Encrypt Data
To encrypting data you have to use the public key from your Hiera (`data-*`) git repository named `eyaml_public_key.pem`
For the lower layers (global, server or data) it is on the Puppet server at [`/etc/puppetlabs/keys/eyaml/public_key.pkcs7.pem`](https://git.psi.ch/linux-infra/bootstrap/-/blob/prod/instcode/puppet/puppet_server/files/crypto/public_key.pkcs7.pem).
For the lower layers (global, server or data) it is on the Puppet server at [`/etc/puppetlabs/keys/eyaml/public_key.pkcs7.pem`](https://gitea.psi.ch/lx/bootstrap/src/branch/prod/instcode/puppet/puppet_server/files/crypto/public_key.pkcs7.pem).
Beside this key you also need to have `hiera-eyaml` tool installed on your system.
admin-guide/puppet/puppet_environments.md
+2 -2
View File
@@ -1,6 +1,6 @@
# Puppet Environments
An Puppet environment is a particular version of the Puppet code/configuration. In our infrastructure an Puppet environment always corresponds to a git branch in the main puppet codebase: https://git.psi.ch/linux-infra/puppet
An Puppet environment is a particular version of the Puppet code/configuration. In our infrastructure an Puppet environment always corresponds to a git branch in the main puppet codebase: https://gitea.psi.ch/puppet/puppet
To all time our Puppet server provides two environments, __prod__ and __preprod__.
@@ -10,7 +10,7 @@ Beside the __prod__ and __preprod__ environments, development environments for f
__ON YOUR COMPUTER!__
1. Clone the puppet repository https://git.psi.ch/linux-infra/puppet
1. Clone the puppet repository https://gitea.psi.ch/puppet/puppet
2. Create a new branch with a name that matches following regex: `^[a-z]+[a-z,0-9,_]+$` (e.g. my_test_branch)
3. Do the necessary changes and commit your changes
4. Push the new branch / changes to the git server
engineering-guide/accounts-and-groups.md
+1 -1
View File
@@ -33,7 +33,7 @@ To be able to easily distinguish between the different account types, a user sha
| `unx-lx_e_users` | experiment accounts | `e22284` |
| `unx-lx_svc_users` | service accounts accounts | `svcusr-lx_test`|
The passwords for all these users are found in the [Shared Core Linux Secret Store](https://git.psi.ch/linux-infra/core-linux-secrets), except for `e22284` which is found in the [PSI e-account Password Manager](https://epwd.psi.ch/cred/detail/18556/).
The passwords for all these users are found in the [Shared Core Linux Secret Store](https://gitea.psi.ch/lx/core-linux-secrets), except for `e22284` which is found in the [PSI e-account Password Manager](https://epwd.psi.ch/cred/detail/18556/).
```{note}
unx-lx_ext_users - this group does not yet contain all ext accounts (only the ones that are currently in the scope of IAM - this should be fixed by end of January 2025
engineering-guide/icinga2.md
+3 -3
View File
@@ -15,11 +15,11 @@ We want to support monitoring of the Linux machines in Icinga2. The Icinga2 infr
## Automated Host Configuration
The Linux part of the Icinga2 Master configuration is manged using Ansible in the [`icinga_master` role in the `bootstrap` repo](https://git.psi.ch/linux-infra/bootstrap/-/tree/prod/ansible/roles/icinga_master).
The Linux part of the Icinga2 Master configuration is manged using Ansible in the [`icinga_master` role in the `bootstrap` repo](https://gitea.psi.ch/lx/bootstrap/src/branch/prod/ansible/roles/icinga_master).
For Puppet managed nodes there is an automated import pipeline using the Icinga Director. For the central infrastructure itself there is a predefined Configuration Basket snapshot which is installed by manual Ansible run.
Configuration which is shared and used by both type of systems are found in the [`awi-lx-basic` Configuration Basket](https://git.psi.ch/linux-infra/bootstrap/-/blob/prod/ansible/roles/icinga_master/files/etc/icingaweb2/psi/lx-core/Director-Basket_awi-lx-basic.json)
Configuration which is shared and used by both type of systems are found in the [`awi-lx-basic` Configuration Basket](https://gitea.psi.ch/lx/bootstrap/src/branch/prod/ansible/roles/icinga_master/templates/Director-Basket_awi-lx-sysdb.json)
### Puppet Managed Nodes
@@ -60,7 +60,7 @@ A Director import pipeline needs first a Import Source which imports the data fr
##### Director Import of Host Information
The Icinga Director import pipeline is provides as [Configuration Basket template `awi-lx-sysdb`](https://git.psi.ch/linux-infra/bootstrap/-/blob/prod/ansible/roles/icinga_master/templates/Director-Basket_awi-lx-sysdb.json).
The Icinga Director import pipeline is provides as [Configuration Basket template `awi-lx-sysdb`](https://gitea.psi.ch/lx/bootstrap/src/branch/prod/ansible/roles/icinga_master/templates/Director-Basket_awi-lx-sysdb.json).
The pipeline for host groups imports the list of sysdb host groups and the filter to select the hosts where the group name is listed in the `host.vars.host_groups` array of the host.
engineering-guide/influx.md
+2 -2
View File
@@ -1,7 +1,7 @@
# Metrics Server - Influx DB
This is puppet managed:
https://git.psi.ch/linux-infra/hiera/data-lx/blob/master/default/lx-influx-01.psi.ch.yaml
https://gitea.psi.ch/puppet/data-lx/src/branch/master/default/lx-influx-01.psi.ch.yaml
Runs the influxdb backend for the metrics.psi.ch service, as part of the telegraph, influxdb and grafana stack.
@@ -52,4 +52,4 @@ show series where "host" = 'lx-puppet-01.psi.ch'
Delete all series for a particular host:
```
DROP SERIES FROM /.*/ WHERE "host" = 'lx-puppet-01.psi.ch'
```
```
engineering-guide/infrastructure_administration.md
+2 -2
View File
@@ -2,7 +2,7 @@
## How to Grant a Access to bob/sysdb
bob is making http calls to the sysdb app. Authorization (https://git.psi.ch/linux-infra/sysdb#authentication-and-authorization) is done via krb5 tokens. Operations outside of environments (creating/changing the owner of/deleting environments) needs to be done by a sysdb admin, ie someone who is a member of the group sysdb-admins. Group membership of the authenticated users is evaluated on the OS level on sysdb.psi.ch. So group memberships can be set both locally or in the AD. This makes it a bit confusing, but both are used.
bob is making http calls to the sysdb app. Authorization (https://gitea.psi.ch/lx/sysdb#authentication-and-authorization) is done via krb5 tokens. Operations outside of environments (creating/changing the owner of/deleting environments) needs to be done by a sysdb admin, ie someone who is a member of the group sysdb-admins. Group membership of the authenticated users is evaluated on the OS level on sysdb.psi.ch. So group memberships can be set both locally or in the AD. This makes it a bit confusing, but both are used.
For the envs (bob env list), only adding and listing are implemented in bob, any other operation, like deletion or modification can only be performed in the sysdb sqlite database itself.
@@ -21,7 +21,7 @@ Generate a ssh key e.g. as follows:
ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/linux_id_ed25519
```
Use the [user ca certificate](https://git.psi.ch/linux-infra/core-linux-secrets/-/blob/main/ssh-ca/user-ca.gpg), but this is automated by pasting below function into your shell
Use the [user ca certificate](https://gitea.psi.ch/lx/core-linux-secrets/src/branch/main/ssh-ca/user-ca.gpg), but this is automated by pasting below function into your shell
```bash
function sign-user-ssh-key {
(
engineering-guide/initial_setup.md
+1 -1
View File
@@ -15,7 +15,7 @@ The steps involved to bootstrap the boot server and the repository server are th
- There are two ISOs, one ~900MB and one ~11GB (RHEL8). The smaller one is able to boot and start the installation of the system, however it requires a network based repository for the installation (i.e. the content of the unpacked ISO need to be available via http(s))
With the bigger one the system can be completely installed.
1. Generate a kickstart file for the system in the https://git.psi.ch/linux-infra/bootstrap repository
1. Generate a kickstart file for the system in the https://gitea.psi.ch/lx/bootstrap repository
- For the DMZ server the ip of the DNS server needs to be different in DMZ `--nameserver=192.168.70.5`
1. Create a new iso including the generated kickstart file via the [mkksiso](https://weldr.io/lorax/mkksiso.html) utility:
engineering-guide/ipxe.md
+1 -1
View File
@@ -92,7 +92,7 @@ The steps for building an iPXE image are
1. Clone `https://gitea.psi.ch/lx/ipxe-build`
2. Change into the new directory
3. Run the `refresh-ipxe.sh` script. This will check out the iPXE source code
mirror from `git.psi.ch`.
mirror from `gitea.psi.ch`.
4. Run the `build.sh` script. This will use the named configurations in the
`ipxe-build` repository to compile two iPXE images: `src/bin/ipxe.lkrn`
(legacy boot) and `src/bin-x86_64-efi/ipxe.efi` (UEFI).
engineering-guide/login.md
+1 -1
View File
@@ -1,3 +1,3 @@
# Login Nodes
This is a set of 3 machines which have the same DNS alias `login.psi.ch` (connection to a random machine) The machines are managed by Puppet: https://git.psi.ch/linux-infra/hiera/data-lx/blob/master/login.yaml.
This is a set of 3 machines which have the same DNS alias `login.psi.ch` (connection to a random machine) The machines are managed by Puppet: https://gitea.psi.ch/puppet/data-lx/src/branch/master/login.yaml.
engineering-guide/lxsup.md
+1 -1
View File
@@ -3,4 +3,4 @@
lxsup.psi.ch is a utility machine for our supporters. It provides a readily installed and configured `bob` as well as `ansible` command to provision and modify systems.
This is a RHEL8 machine and is fully Puppet managed:
https://git.psi.ch/linux-infra/hiera/data-lx/-/blob/master/default/lx-sup-01.psi.ch.yaml
https://gitea.psi.ch/puppet/data-lx/src/branch/master/default/lx-sup-01.psi.ch.yaml
engineering-guide/lxweb00.md
+1 -1
View File
@@ -1,7 +1,7 @@
# Repository Server - LEGACY - lxweb00
This is a RHEL7 machine and is puppet managed. The httpd configuration seem to be managed there as well:
https://git.psi.ch/linux-infra/hiera/data-lx/blob/master/default/lxweb00.psi.ch.yaml
https://gitea.psi.ch/puppet/data-lx/src/branch/master/default/lxweb00.psi.ch.yaml
Exports various paths from AFS to http(s), see /etc/httpd/conf.d/ for details.
The AFS directories exported are:
engineering-guide/metrics.md
+2 -2
View File
@@ -3,7 +3,7 @@
The Grafana frontend can be accessed via - https://metrics.psi.ch
This machine is puppet managed:
https://git.psi.ch/linux-infra/hiera/data-lx/blob/master/default/lx-metrics-01.psi.ch.yaml
https://gitea.psi.ch/puppet/data-lx/src/branch/master/default/lx-metrics-01.psi.ch.yaml
The rights for Grafana are managed with these two AD groups:
| Group | Notes |
@@ -44,4 +44,4 @@ providers:
foldersFromFilesStructure: true
```
The dashboard `.json` files need to be located then in `/var/lib/grafana/dashboards`
The dashboard `.json` files need to be located then in `/var/lib/grafana/dashboards`
engineering-guide/new_sysdb_environment.md
+2 -2
View File
@@ -112,7 +112,7 @@ In [bootstrap](https://gitea.psi.ch/lx/bootstrap)
In order to test that environment was successfully created
git clone git@git.psi.ch:linux-infra/data-<environment_name>.git
git clone git@gitea.psi.ch:puppet/data-<environment_name>.git
Add a new file <environment_name>.yaml in to the project:
@@ -128,7 +128,7 @@ After a few seconds (needs time to trigger the change), check in `puppet01.psi.c
Full real example:
git clone git@git.psi.ch:linux-infra/data-meg.git
git clone git@gitea.psi.ch:puppet/data-meg.git
cd data-meg
touch meg.yaml
git add meg.yaml
engineering-guide/puppet/modules.md
+1 -1
View File
@@ -1,6 +1,6 @@
# Modules
The repository for the Puppet role/profile modules is <https://git.psi.ch/linux-infra/puppet>.
The repository for the Puppet role/profile modules is <https://gitea.psi.ch/puppet/puppet>.
So we have some roles that are generic PSI-wide (eg. `role::server`) while
engineering-guide/puppet_server.md
+2 -2
View File
@@ -29,7 +29,7 @@ puppet agent -t --environment=xyz
## Merge Process
Merge meetings are usually held weekly. To record the meeting a https://git.psi.ch/linux-infra/org/wikis/meeting_reports/YYYY-MM-DD page is to be created based on the https://git.psi.ch/linux-infra/org/wikis/merge-meeting-guidelines template.
Merge meetings are usually held weekly.
## Modules
@@ -93,4 +93,4 @@ pdb "nodes[certname] { order by certname }"
# list environments and times of the last Puppet run
pdb "reports[certname,environment,start_time,end_time] { order by certname }"
```
```
engineering-guide/repo_server.md
+2 -2
View File
@@ -10,9 +10,9 @@ The service restart mounts the iso as a loop device into a directory of the same
Then the ipxe and grub templates of the sysdb have to be edited, to add the new version:
https://git.psi.ch/linux-infra/sysdb/blob/prod/sysdb/ipxe_template.py
https://gitea.psi.ch/lx/sysdb/src/branch/prod/sysdb/ipxe_template.py
https://git.psi.ch/linux-infra/sysdb/blob/prod/sysdb/grub_template.py
https://gitea.psi.ch/lx/sysdb/src/branch/prod/sysdb/grub_template.py
Once the change is committed, the changes have to be pulled on sysdb.psi.ch:
engineering-guide/sysdb_server.md
+1 -1
View File
@@ -1,6 +1,6 @@
# Sysdb Server
https://git.psi.ch/linux-infra/sysdb/ is pulled into /var/www/sysdb/app/ (no automation, just by hand)
https://gitea.psi.ch/lx/sysdb/ is pulled into /var/www/sysdb/app/ (no automation, just by hand)
httpd runs the service and it needs restarting, when pulling changes
engineering-guide/webhosting.md
+2 -2
View File
@@ -8,8 +8,8 @@ lx-docker-01.psi.ch lx local ipxe_installer=rhel9install network=static puppet_e
lx-docker-dmz-01.psi.ch lx local ipxe_installer=rhel9install network=static puppet_env=prod puppet_group=default puppet_role=role::server
```
Their respective hiera configurations:
https://git.psi.ch/linux-infra/hiera/data-lx/-/blob/master/default/lx-docker-01.psi.ch.yaml
https://git.psi.ch/linux-infra/hiera/data-lx/-/blob/master/default/lx-docker-dmz-01.psi.ch.yaml
https://gitea.psi.ch/puppet/data-lx/src/branch/master/default/lx-docker-01.psi.ch.yaml
https://gitea.psi.ch/puppet/data-lx/src/branch/master/default/lx-docker-dmz-01.psi.ch.yaml
Docker Compose and Nginx reverse proxy configuration
https://gitea.psi.ch/linux/WebHosting
index.md
+3 -3
View File
@@ -58,7 +58,7 @@ To access the RedHat knowledge base at https://access.redhat.com you need an acc
| __Location__ | Teams |
| __Purpose__ | Open questions/answer session to discuss general Linux topics |
| __Participants__ | Usually the people on the linux@psi.ch mailing list |
| __Meeting Minutes__ | https://git.psi.ch/linux-infra/linux-group/-/tree/master/meetings/engineering-meeting (there are not always minutes!) |
| __Meeting Minutes__ | https://gitea.psi.ch/lx/linux-group/src/branch/master/meetings/engineering-meeting (there are not always minutes!) |
### Merge Meeting
@@ -69,7 +69,7 @@ To access the RedHat knowledge base at https://access.redhat.com you need an acc
| __Location__ | Teams |
| __Purpose__ | Review new changes in the Puppet code |
| __Participants__ | Usually some of the people on the linux@psi.ch mailing list |
| __Meeting Minutes__ | https://git.psi.ch/linux-infra/linux-group/-/tree/master/meetings/merge-meeting |
| __Meeting Minutes__ | https://gitea.psi.ch/lx/linux-group/src/branch/master/meetings/merge-meeting |
### Supporter Meeting(s)
@@ -90,6 +90,6 @@ To access the RedHat knowledge base at https://access.redhat.com you need an acc
| __Location__ | Teams |
| __Purpose__ | Coordination work within the Linux core group |
| __Participants__ | Member of Linux Core group |
| __Meeting Minutes__ | https://git.psi.ch/linux-infra/linux-group/-/tree/master/meetings/group-meeting (Note: there are not always minutes!) |
| __Meeting Minutes__ | https://gitea.psi.ch/lx/linux-group/src/branch/master/meetings/group-meeting (Note: there are not always minutes!) |
services/admin-guide/nx_nomachine.md
+2 -2
View File
@@ -1,6 +1,6 @@
# NX Nomachine
All information about the nomachine service and how to troubleshoot, currently can be found here: https://git.psi.ch/nomachine/documentation
All information about the nomachine service and how to troubleshoot, currently can be found here: https://gitea.psi.ch/nomachine/nomachine_documentation
## Hiera
@@ -14,4 +14,4 @@ nomachine::profile: 'enterprise-desktop'
nomachine::license::<hostname>:
```
Which versions are available for `nomachine:profile` can be found in here: https://git.psi.ch/linux-infra/puppet/-/blob/preprod/code/modules/profile/manifests/nomachine.pp#L3
Which versions are available for `nomachine:profile` can be found in here: https://gitea.psi.ch/puppet/puppet/src/branch/preprod/code/modules/profile/manifests/nomachine.pp#L3
services/admin-guide/ssh_gateways.md
+3 -5
View File
@@ -22,9 +22,7 @@ Following communication is currently possible:
The access to a gateway is always controlled via an AD group. The name of the AD group always follows the same pattern: __unx-gw_&lt;gateway-name&gt;__. __gateway-name__ is always the part of ssh gateways name before the __-gw__ (example: sls-gw.psi.ch > unx-gw_sls).
(temporary solution) Depending on the gateway the members of the group are either managed in [DUO](https://duo.psi.ch) by the beamline scientist or via https://git.psi.ch/controls_it/unix_group_management.
However, the general baseline is that always the responsible of the protected network must approve that a user is added to the group.
The general baseline is that always the responsible of the protected network must approve that a user is added to the group.
(temporary solution) The effective update of the AD groups is currently done on gfa-admin.psi.ch via some webhooks / timers.
- /etc/systemd/system/update_ad_gw_groups.service
@@ -32,11 +30,11 @@ However, the general baseline is that always the responsible of the protected ne
The administration and management of the gateways is done via hiera:
https://git.psi.ch/linux-infra/hiera/data-lx (all the machines are in the sshgw group)
https://gitea.psi.ch/puppet/data-lx (all the machines are in the sshgw group)
## Gateway List
The list of supported gateways can be found here:
https://git.psi.ch/linux-infra/ansible/playbooks/lx_ansible/-/blob/main/inventory.yaml#L3
https://gitea.psi.ch/puppet/data-lx/src/branch/master/sshgw
## Group Membership / Access Groups
services/admin-guide/wmgt.md
+1 -6
View File
@@ -1,11 +1,9 @@
# wmgt.psi.ch
The wmgt service consists of 3 servers, wmgt01 / wmgt02 / wmgt03.
wmgt01/wmgt02 are hardware servers, wmgt03 is virtual.
The wmgt service consists of 1 server, wmgt01
The locations of the hardware servers are:
wmgt01 - location datacenter west
wmgt02 - location datacenter __east__
These systems are not Puppet managed!
@@ -27,9 +25,6 @@ We will change this workflow to a ServiceNow workflow. Tobias has to approve all
Currently the monitoring of the systems is here:
https://kibana.psi.ch/s/dcdb/app/dashboards#/view/e351a5e0-df75-11ed-97b0-67ad05d92422?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-15m,to:now))
## Administration
The repos with the necessary setup for the wmgt systems are currently located here: https://git.psi.ch/linux-infra/wmgt-tmp
## Responsibilities
Hardware responsibility is within the AIT Central Infrastructure group. This includes Hardware monitoring, replacement of broken hardware as well as information/planning for the hardware lifecycle.
services/user-guide/gitlab/gitlab.md
-6
View File
@@ -9,9 +9,3 @@ To grant an external collaborator access to a repository following steps are nee
1. Order an ext-account for your collaborator
2. Once the account is created, your collaborator need to login to gitlab.psi.ch. Important use `ext-<your-name>` as username to log in, not the external email address!
3. Grant access to the needed repositories via Manage > Members
More documentation that can be found here:
- (Gitlab) git.psi.ch
- (Container Registry) container.psi.ch
- (Git Pages) gitpages.psi.ch
services/user-guide/gmgt.md
+1 -1
View File
@@ -2,7 +2,7 @@
gmgt.psi.ch is the jumphost to reach GMGTW (WinSRV) via RDP or iLO (https:443) in the GFA managment network.
The access group is manually managed via puppet/hiera: https://git.psi.ch/linux-infra/hiera/data-lx/-/blob/master/default/lx-gmgt-01.psi.ch.yaml?ref_type=heads
The access group is manually managed via puppet/hiera: https://gitea.psi.ch/puppet/data-lx/src/branch/master/default/lx-gmgt-01.psi.ch.yaml
Access to the machine is via wmgtXX.psi.ch