Singularity to Apptainer renaming
Singularity has been renamed to Apptainer in 2022 due to legal constraints. In general, just the name has changed and all options are the same. Replacing the command `singularity` with `apptainer` should work on updated systems.
Use Case: You are building your own container and want to renew your Kerberos and AFS tickets/tokens from inside your container.
When you run a container un-contained or contained (–-contain) with filesystems mounted explicitly (let's say a networkk FS like AFS or some remote NFS), e.g.,
singularity shell --contain --bind /afs:/afs ...
the files/mount namespaces will be accessible in your container environment. However, you probably will not be able to renew a Kerberos ticket and/or AFS token from inside the container.
To do so, you need to connect your container to more resources of your host environment (and install the necessary tools to speak to Kerberos or AFS).
For other container engines as Docker the steps should be similar.
The various bind mounts in the following are not necessary, if you run the container without '--contain' (but of course '--contain' makes the separation between host and container cleaner)
Kerberos
Prerequisites
Install in your container the Kerberos client package, e.g., for Scientific Linux 6 it is
> cat Singularity
...
yum install -y krb5-workstation
...
check the right package for other distributions and releases. After rebuilding you container, also mount your host's Kerberos config into it (assuming that your host belongs already to a Kerberos realm)
> singularity ... --contain ... --bind /etc/krb5.conf:/etc/krb5.conf ...
(if you cannot mount the file ontop of the default config in the container, rebuild the container with the default config in the container being removed). If your host has additional configs in /etc/krb5.conf.d, might be worth a try to bind it also into the container.
Kerberos Tickets
Your Kerberos credentials are either kept in a file or probably (for more current kernels) in the kernel keyring - check the Kerberos environment variable in your host env
> echo $KRB5CCNAME
FILE:/tmp/krb5cc_MYUID_RNDSTRNG
If you run with --contain and want to use these credentials also in your container, mount also the credential ticket file (here: /tmp/krb5cc_MYUID_RNDSTRNG) into the container and let the variable in the container point to it (without --contain your host's /tmp should be natively be accessible).
> singularity ... --contain ... --bind /etc/krb5.conf:/etc/krb5.conf --bind $(echo ${KRB5CCNAME} | cut -d ":" -f2):/myticket.krb ...
> container > export KRB5CCNAME="FILE:/myticket.krb"
else you can put the credential file on another path, that is also available in the container, e.g.,
> kinit -f -p -A YOURUSERNAME@DESY.DE -c ${HOME}/myticket.krb
> container > export KRB5CCNAME="FILE:${HOME}/myticket.krb"
Now you should be able to view, request or renew tickets from inside your container
> container > klist
> container > kinit -f -p -A YOURUSERNAME@DESY.DE
(for debugging ther kerberos tools' -c flag is your friend, which can be pointed to a path differing from the default set in the environment variable)
AFS
Prerequisites
Install in your container the AFS client package - for example, in SL6 its name is
openafs-1.6-sl-client
As you will probably derive your AFS token from a Kerberos ticket, you will probably need the Kerberos parts as prerequisite.
AFS Tokens
AFS is a bit more fiddly than Kerberos since it is explicitly a kernel module, i.e., it depends on the host kernel (and since containers are just namespaces on the kernel, in the container as well outside the kernel API is the 'host one').
AFS does not store it's credentials in a file but in a pseudo-device, i.e., the client tools talk to the kernel module via this pseudo-file thing so we have to make it available also in the container
> singularity shell ... --contain ... --bind /etc/krb5.conf:/etc/krb5.conf --bind /proc/fs/openafs/afs_ioctl:/proc/fs/openafs/afs_ioctl --bind /usr/vice/etc:/usr/vice/etc ...
(probably you will not need /usr/vice/etc as current AFS versions should more be DNS based - presumably, there should be no need to mount system AFS configs into the container as /etc/openafs/ or /etc/sysconfig/afs)
With /proc/fs/openafs/afs_ioctl available in the container's namespace, you should be able to obtain a fresh token
> container > kinit -f -p -A YOURUSERNAME@YOUR.CELL; aklog -c YOUR.CELL