Introduction
From January 2025 we no longer have any joint maintenance of our workstations, so while we try to provide some general guidelines and pointers for the transition, this information will become outdated at some point. Thus, if you read this it is important that you both talk to your PI and read up a bit good practices how to install and maintain a Linux installation.
There are two particularly important points to keep in mind:
- Security. The SciLifeLab network is maintained by KTH, which actually exposes all machines completely to the internet by default. This is great in many ways (e.g. bandwidth, services), but it also means any machine you set up is fully exposed to hackers, botnets and all other security threats. It is your responsibility to ensure your machine is secure and does not pose a threat to others on our network, e.g. if it is hacked and used to hack other machines.
- Data safety. With great power comes great responsibility. Your local machine is not backed up, so you need to talk to your PI about where you store copies of valuable data. In general, once you leave the lab your machine will be reinstalled and all data stored locally will be erased.
Now, to help you a bit in the transition, we provide a brief installation guide written for Ubuntu 24.04. If you have problems or need help, you will need to consult the internet or ask your PI.
This should be quite straight forward to apply this to other distributions, but no guarantees. Some of the preparations could be done in the installer itself, but we find command line tools more reliable and the results are reproducible. Code blocks here show commands that are entered in a terminal (if the line starts with a $ sign) and exemplary output of the command.
Desktop environment and boot type
There are several desktop environments available (Gnome, KDE, Xfce, …) and for most of them there is a customized live-DVD image available (Ubuntu GNOME, Kubuntu, Xubuntu, …). Download whichever one you like and use dd to write it on a USB pen drive. Most BIOS support bringing up a boot menu by pressing a key (e.g. F11), or you can enter the BIOS (usually DEL or F2) and select a one-time boot override. You might see something like “UEFI USB” and “USB“. If you see both, choose the UEFI USB boot option. Boot the live system (e.g. select “Try Ubuntu“). Modern motherboards have UEFI firmware instead of the legacy BIOS, but many may still use the legacy mode as fallback. The partitions that have to be created depend on which mode is used. To check in which mode your motherboard decided to boot in the end, open a terminal and look at the kernel messages:
$ dmesg | grep -i EFI
[ 0.000000] efi: EFI v2.31 by American Megatrends
If you see a line similar to the one above you managed to boot in UEFI mode. Also check if there are files in the directory /sys/firmware/efi/efivars/. If that directory or the parent directory do not exist, you likely booted in legacy mode or your system does not support UEFI (unlikely in 2024!) . Now that we confirmed the boot mode (UEFI or legacy BIOS) let us get started.
Installing the OS
Security
A challenge with modern OS distributions (including Linux) is that they often come with numerous services enabled, e.g. for printing, sharing files, remote logins, etc. Each such service responds to a “port” (e.g. port 22 for ssh). KTH (that operates the SciLifeLab network) is very liberal and fully exposes our workstations to the internet – but this means every such open port is a potential security hole.
There are a couple of ways to reduce this risk, and you might want to use them all:
- Never create accounts with simple passwords, not even for a short amount of time. There are automated brute-force login attempts happening all the time.
- Only enable the very few services you absolutely need. A service that is turned off cannot be hacked. You can even consider turning of “sshd” if you don’t need to login remotely.
- Use a firewall to disable access from other machines, or machines outside the local SciLifeLab network. For Ubuntu the default is UFW which can be enabled easily. You might need to start by reading up on firewalls in general, and checking the IP range of the local machines.
- Install a package such as “fail2ban”. This package will monitor incoming ssh connections, and when the wrong password has been tried a couple of times there will be (increasing) delays before the user is allowed to try again. After a few hours it will automatically reset, so you won’t lock yourself out permanently if you mistype. You will find instructions for this below.
- Make sure you install OS security updates (preferably automated, e.g. via
unattended-upgrades), and only use an OS new enough to actually get security updates. The so-called LTS releases of Ubuntu get security updates for ~5 years, but non-LTS versions only have a lifespan of 9 months!
Partition the hard drive
This will delete all data on the drive so be careful to pick the right one. If in doubt check the output of
$ sudo lshw -short -class disk
H/W path Device Class Description
====================================================
/0/4/0.0.0 /dev/sda disk 2TB ST2000VX000-1CU1
/0/100/2.2/0/1 /dev/nvme0n1 disk 1024GB NVMe disk
Note the somewhat unusual naming of NVMe disks. They support multiple so called namespaces, and the default namespace has id 1. Therefor the device that will be partitioned is called nvme0n1. nvme0 for the first NVMe disk in the system, and n1 for the default namespace with id 1 on that device. If your workstation has multiple hard drives installed there will be even more disks – and you might need to alter the BIOS settings to select what disk to boot from.
If the hard drive has been used before, existing swap or LVM partitions might have been activated by the live system automatically. Deactivate all of them to avoid problems during installation.
$ sudo swapoff -a
$ sudo vgchange -an
Then start the partitioning program (make sure /dev/nvme0n1 is the correct drive, see lshw command above)
$ sudo gdisk /dev/nvme0n1
Then do the following (enter the letter or value denoted, DEF means just press ENTER to confirm the default value):
- create an empty GUID partition table (o)
- on UEFI systems: add an EFI system partition (n, DEF, 2048, +255M, ef00)
on BIOS systems: add a BIOS boot partition (n, DEF, 2048, +255M, ef02) - add a Linux LVM partition (n, DEF, DEF, DEF, 8e00)
- write table to disk and exit (w)
NB: 255 MiB is oversized for a BIOS boot partition but it is convenient to have the same layout if you switch to an UEFI system at some point (then you only have to change the partition type). The number 255 is due to the fact that the first partition starts at 1MiB and it can be beneficial for SSDs to align the other partitions to 4 MiB boundaries due to the storage cell layout in the SSD. 255+1=256 is still good if that value changes to larger powers of 2 in the future.
Create LVM volumes
Using LVM volumes for /, swap, /home and so on offers much more flexibility than using plain partitions. First we have to create the physical volume, then the volume group and finally the volumes. The size of the volumes below is just a suggestion for a 1 TB disk. Feel free to use different values. But leave some free space if you do not need everything. You might want to create additional volumes at some point. An ext4 file system can be grown even when it is mounted, so making a volume larger later on is not a problem. Shrinking a volume on the other hand is more complicated. The separate volumes for /home, /tmp and /var are just a suggestion. Having a dedicated /boot partition used to be common, but GRUB2 has LVM support for probably a decade at this point, hence that should not be necessary.
$ sudo pvcreate /dev/nvme0n1p2
$ sudo vgcreate vgroot /dev/nvme0n1p2
$ sudo lvcreate -n lvroot -L 75G vgroot
$ sudo lvcreate -n lvvar -L 20G vgroot
$ sudo lvcreate -n lvswap -L 5G vgroot
$ sudo lvcreate -n lvscratch -L 500G vgroot
If you install more hard drives later on and want to add them to an existing volume group (vg0 in this example), do the following. First figure out which device file is associated with the new drive by using lshw (in the example below it is /dev/sdc). Then use gdisk to create a single partition on the drive (as above without step 2). Then you create the physical volume on that partition and add the physical volume to the existing volume group. Check the number of free data blocks (physical extends), create the logical volume (important: the device name in the end ensures that all data blocks will be allocated on the physical volume sdc1, otherwise you might end up with a logical volume that is spread over two disks), create a filesystem on the logical volume; modify /etc/fstab and then mount the filesystem:
$ sudo lshw -short -class disk
$ sudo gdisk /dev/sdc
$ sudo pvcreate /dev/sdc1
$ sudo vgextend vg0 /dev/sdc1
$ sudo pvdisplay /dev/sdc1
[...]
Free PE 1430791
[...]
$ sudo lvcreate -n data2 vg0 -l 1430791 /dev/sdc1
$ sudo mkfs.ext4 -L DATA2 /dev/mapper/vg0-data2
$ sudo vi /etc/fstab
$ sudo mount -a
****
Install Ubuntu
Note that the installer for Ubuntu 24.04 currently does not show LVM volumes, so it is not possible to install with that one to a LVM volume. Check this bug report to see if the situation has changed. A somewhat annoying but simple workaround is to install Ubuntu 22.04 and then upgrade to 24.04.
Now that the preparations are done start the installer. When you reach the “Installation type” dialogue select “something else (create or resize partitions yourself …)“. You will then see the previously created LVM volumes. Change each volume according to the following table:
| Device | Type | Mount_point |
| /dev/mapper/vgroot-sysroot | ext4 | / |
| /dev/mapper/vgroot-var | ext4 | /var |
| /dev/mapper/vgroot-scratch | ext4 | /scratch |
| /dev/mapper/vgroot-swap | swap | |
| /dev/nvme0n1p1 | fat32 | /boot/efi |
Device for boot loader installation: /dev/nvme0n1. Then select “Install now“.
Now the installation is straightforward. The local user that is created in the process should have the username ‘localadmin’. Chose a safe password and tell one of the admins about it so we can change it later on. When the installation is finished, reboot.
System configuration
This section documents the configuration of our workstations in the lab. The LDAP and NFS servers are only accessible from there, so this configuration does not make sense for your own computer!
OpenSSH
If a SSH server is installed, also install fail2ban. The office computers are on a public KTH network, so you can expect automated brute-force break-in attempts.
TODO: expand on open ports, security, no simple passwords etc..
$ sudo apt-get install fail2ban
Then you might want to add an AllowUsers line to /etc/ssh/sshd_config to restrict who can log in remotely to your machine. For changes to take effect you have to restart ssh:
$ sudo systemctl restart ssh
UFW firewall
In Ubuntu the Uncomplicated Firewall (UFW) is installed by default, but not enabled. A simple configuration would be to enable it and only allow SSH from anywhere in the world.
$ sudo ufw allow from any to any app OpenSSH comment "allow SSH from anywhere"
$ sudo ufw enable
But since SciLifeLab provides a VPN service, a more restricted configuration could be to only allow access to SSH from these VPN servers, and our Biophysics network.
$ sudo ufw allow from 130.237.250.4/30 to any app OpenSSH comment "allow SSH from VPN nodes"
$ sudo ufw allow from 130.237.11.128/26 to any app OpenSSH comment "allow SSH from Biophysics subnet"
$ sudo ufw enable
Of course this second set of commands only makes sense if you haven’t already created the rule from the first example that allows SSH from anywhere.
User accounts
As part of moving to individually maintained workstations, we are also deprecating the centrally managed user accounts and home directory file server. You will need to create accounts for each user on each machine they will need to access, and arrange for local data storage – including home directories.
While computers usually work well, errors happen, so we strongly recommend planning for what you will do WHEN, not IF, your hard drive breaks or the computer is stolen. Where have you placed the second copy of the all the important data that corresponds to four years of work for your PhD thesis?
Ultimately, the PI in each group is responsible for safeguarding data needed to reproduce e.g. publications, so talk to your team lead about how to organize this.
Deprecated – configuration of network user accounts
This information might be useful to aid debugging of the machines we still have connected to central user accounts, but please do not configure new machines using central user accounts – the home directories and backups will be retired in fall 2025.
Local user and group ID ranges
After installation, we should change the defaults for local users. The LDAP accounts use the uid range 10000 to 20000. To avoid clashes for local users we edit /etc/adduser.conf and set:
# FIRST_[GU]ID to LAST_[GU]ID inclusive is the range of UIDs of dynamically
# allocated user accounts/groups.
FIRST_UID=1000
LAST_UID=9999
FIRST_GID=1000
LAST_GID=9999
Configure LDAP, NFS & Kerberos
We need LDAP, NFS and Kerberos (optional). These are the current names of Ubuntu packages, but depending on the version or distribution you might need to find the relevant or updated packages to install:
$ sudo apt-get install libpam-krb5 krb5-user ldap-auth-client nss-updatedb nfs-client autofs
| default Kerberos realm | TCBLAB.ORG |
| kdc | ldap.biophysics.kth.se |
| admin server | ldap.biophysics.kth.se |
| uri | ldaps://ldap.biophysics.kth.se:636/ |
| base DN | cn=compat,dc=tcblab,dc=org |
| ldap_version | 3 |
| local root DB admin | No |
| server requires login | No |
If you made a typo and need to run this configuration dialog again, use
$ sudo dpkg-reconfigure ldap-auth-config
Add these entries to /etc/krb5.conf:
[realms]
TCBLAB.ORG = {
kdc = ldap.biophysics.kth.se
admin_server = ldap.biophysics.kth.se
}
[domain_realm]
scilifelab.se = TCBLAB.ORG
.scilifelab.se = TCBLAB.ORG
tcblab.org = TCBLAB.ORG
.tcblab.org = TCBLAB.ORG
biophysics.kth.se = TCBLAB.ORG
.biophysics.kth.se = TCBLAB.ORG
Enable LDAP
In order to reduce load on the LDAP server we set up a local copy of the user information (user account metadata, not your home directory!) that gets synced on a regular basis. First create the initial copy:
$ sudo nss_updatedb ldap
passwd... done.
group... done.
Then create the file /etc/cron.hourly/nss_updatedb with the following content:
#!/bin/bash
sleep $((RANDOM*120/32767)) && /usr/sbin/nss_updatedb ldap | logger -t nss_updatedb
And mark it as executable:
$ sudo chmod +x /etc/cron.hourly/nss_updatedb
Set the passwd and group entries in /etc/nsswitch.conf to:
passwd: files db systemd
group: files db systemd
When you run the command getent passwd you should now see all network users.
Alternative LDAP configuration:
Instead of syncing a local copy one can instead use the caching daemon unscd.
$ sudo apt-get install unscd
The passwd and group entries in /etc/nsswitch.conf then need to be:
passwd: files ldap systemd
group: files ldap systemd
Also in this case you can verify that you see all network users when running the command getent passwd.
Configure sudo
Create the file /etc/sudoers.d/tcblab with the following line:
%linuxadmins ALL=(ALL) ALL
and set the correct mode on the file
$ sudo chmod 0440 /etc/sudoers.d/tcblab
To give yourself proper admin permission on the system, add your LDAP user to a few local groups. As localadmin run:
$ sudo usermod YOUR_USERNAME -a -G adm,lpadmin,lxd,plugdev,sudo
NFS home and software directories
Now create the mount points for nethome and the shared software installations, then set up automount:
$ sudo mkdir /opt/tcbsys
$ sudo mkdir /opt/cryoem
$ sudo mkdir /nethome
Then create the file /etc/auto.master.d/nethome.autofs with the following content:
/nethome /etc/auto.nethome -nobrowse
Then file /etc/auto.nethome:
+auto.nethome
* -fstype=nfs,nfsvers=4,noacl,port=2049,proto=tcp,_netdev,fsc fs.biophysics.kth.se:/export/nethome/&
The file /etc/auto.master.d/opt.autofs:
/- file:/etc/auto.opt
And the file /etc/auto.opt:
/opt/tcbsys -fstype=nfs,nfsvers=4,noacl,port=2049,proto=tcp,ro,soft,_netdev,fsc fs.biophysics.kth.se:/export/tcbsys
/opt/cryoem -fstype=nfs,nfsvers=4,noacl,port=2049,proto=tcp,ro,soft,_netdev,fsc fs.biophysics.kth.se:/export/cryoem
Then restart autofs:
$ sudo systemctl restart autofs.service
Tell apparmor about home directories in /nethome by running:
$ sudo dpkg-reconfigure apparmor
and enter “/nethome/” in the dialog. And also configure snap for a different home directory location:
$ sudo snap set system homedirs=/nethome
Configure Display Manager
To configure the display manager create the file /etc/lightdm/lightdm.conf.d/99-custom.conf with the following content:
[SeatDefaults]
greeter-show-manual-login=true
greeter-show-remote-login=false
greeter-hide-users=true
greeter-allow-guest=false
allow-guest=false
and restart lightdm:
$ sudo systemctl restart lightdm.service
NB: LightDM is the default for Ubuntu and Xubuntu, other Ubuntu flavors may come with a different display manager by default.
If you’d prefer your default language to be English rather than Swedish, run
$ update-locale LANG=en_US.UTF-8
Known issues
If graphical login hangs for LDAP users (killing gsettings process makes login continue), install unscd. Or check here for other solutions:
https://bugs.launchpad.net/ubuntu/+source/at-spi2-core/+bug/870874
