gitea-pages/engineering-guide/infrastructure_systems.md

Infrastructure Systems

List of systems and their primary role:

Core Infrastructure:

• boot.psi.ch - TFTP server for PXE booting

• sysdb.psi.ch - Runs sysdb, providing the dynamic iPXE, Grub and kickstart files

• puppet.psi.ch - puppet.psi.ch - Puppet server

• repos.psi.ch - Repository server

• lx-sync-01.psi.ch - System to mirror external yum repositories / packages / ...

• lxweb00 - http://linux.web.psi.ch - legacy - 129.129.190.46 - Exports further repositories from AFS

Additional Infrastructure

Sysdb Access:

• lxsup - Standard node for the linux support, primarily to run bob

Monitoring:

• Icinga2 - automatic integration into Icinga2
• lx-influx-01.psi.ch - Influx database server
• lx-metrics-01.psi.ch - https://metrics.psi.ch - Grafana frontend for Influx

Enduser Systems

• login.psi.ch - Set of nodes for enduser use
• cpw.psi.ch - Node to change passwords

SSH Certificates / Signing Public User Keys

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, but this is automated by pasting below function into your shell

function sign-user-ssh-key {
    (
        name="$1"
        pubkey="$2"

        # let the private key flow through a named pipe
        # so it never ends up on the file system

        umask 077
        pipe_base="$(mktemp)" # MacOS does not know about --dry-run
        pipe="${pipe_base}.pipe"
        echo "mkfifo '$pipe'"
        mkfifo "$pipe" || return 1
        [ -p "$pipe" ] || return 1
        echo "pass ssh-ca/user-ca > '$pipe' &"
        pass ssh-ca/user-ca > "$pipe" &
        echo "ssh-keygen -s '$pipe' -I '$name' -n '$name' -V +55w '$pubkey'"
        ssh-keygen -s "$pipe" -I "$name" -n "$name" -V +55w "$pubkey"
        echo "rm '$pipe' '$pipe_base'"
        rm "$pipe" "$pipe_base"
    )
}

and run it with the user name as principal and the public key file

sign-user-ssh-key $PRINCIPAL $PUBKEY_FILE

More details on how this works can be found in this article: https://engineering.fb.com/2016/09/12/security/scalable-and-secure-access-with-ssh/

Unix Groups

Currently we have following AD groups to grant access to certain services/systems:

Group	Notes
unx-lx_eng	Member of linux engineering - used to give access to management NFS filesystem, sysdb, ...
unx-lx_support	used to give Linux supporters access to systems/services
unx-puppet_adm -	associated with lxdev environment/systems
unx-puppet_dev	developer of puppet code
unx-puppet_usr	user of puppet (i.e. need access to linux-infra group/repos)
unx-lx_users	all personal linux accounts at PSI (directly updated from SAP)
unx-lx_grafana_adm	Grafana Administrators
unx-lx_grafana_edi	Group with Grafana editor rights

These two groups are used within Service now to assign tickets:

Group
itsm-linux
itsm-linux_2nd

Access VM infrastructure for linux core employees:

Group	Notes
VC_Admins_Linux	Access to the PSI VM Infrastructure

AD Users

Group	Notes
lx-netops-api	(keytab) Used to access the netops api
lx_ad_join	(keytab) Used to join a machine to AD
linux_ldap ????	was registered by Derek (he is noted as responsible in AD) - used for ????