CSCWiki - User contributions [en]

Matrix

2025-10-29T02:00:38Z

K95ma: /* Discord Instructions */ fix

Matrix

2025-10-29T01:57:23Z

K95ma: /* Discord Instructions */ italic

Matrix

2025-10-29T01:56:15Z

K95ma: /* Discord Instructions */ fix

Matrix

2025-10-29T01:55:56Z

K95ma: /* Discord Instructions */ +

Template:Code

2025-10-29T01:55:11Z

K95ma: copied template from https://en.wikipedia.org/w/index.php?title=Template:Code&action=history; see url for attribution

{{#tag:syntaxhighlight|{{{code|{{{1}}}}}}|lang={{{lang|{{{2|text}}}}}}|class={{{class|}}}|style={{{style|}}}|inline=1}}

Matrix

2025-10-29T01:53:31Z

K95ma: +

Matrix

2025-10-26T21:18:23Z

K95ma: /* Matrix Installation */ -

Matrix

2025-10-26T20:59:44Z

K95ma: +

NixOS

2025-09-29T04:23:38Z

K95ma: +

We're trying to explore different options for running services, and '''NixOS on Proxmox containers''' is one of them. Here's how it is supposed to work:

* '''Malleable''': it should be relatively easy to modify an existing service config, update software version, and migrate one software to another, as everything are written in Nix configuration files.
* '''Recoverable''': NixOS keeps old copies of the system, which can be reverted if we see any immediate issues.
* '''Discoverable''': Services are located in one canonical, centralized location. This reduces the time needed to find the specific config for a specific software, and also makes it easy for someone to know what services are running.
* '''Replicable''': As NixOS service configuration files are written in a human readable format, anyone wishing to use the "normal" way to configure their service should be able to understand how to setup their service in a similar way.
* '''Trackable''': Easy to manage and track changes using Git, maybe even with CI.

=== Setting up a Proxmox VM ===

If there isn't a template already, use https://hydra.nixos.org/job/nixos/release-25.05/nixos.proxmoxLXC.x86_64-linux (replace 25.05 with the latest release)

Use "Create CT", do not use the SSH config, and setup a root password. Then use the console on the web interface to login as root (press enter if you see a blank screen) and configure SSH from there.

Matrix

2025-09-18T02:50:09Z

K95ma: +

We are currently setting up a test server for Matrix. We use Synapse. If everything goes well, we will set up a production Matrix server.

== Server Setup ==

We are currently running Matrix on a Proxmox LXE container on <code>citric-acid</code>. Ask Siracha for the credentials to access Proxmox and the VM.

== Matrix Installation ==

We are using NixOS, so use the following config (might be a bit messy) to setup both Synapse, Nginx, and PostgreSQL:

'''Note''': We could have used <code>recommendedProxySettings = true</code> which sets most of the <code>X-Forwarded-For</code> headers correctly. However, this is a reverse proxy behind a reverse proxy (Nginx on citric acid -> Nginx on the container -> Synapse) so <code>X-Forwarded-Proto</code> has to be always set to https. I'm sure there is a better way to do this.

<pre>
{ pkgs, lib, config, ... }:
let
fqdn = "matrix.${config.networking.domain}";
clientConfig = {
"m.homeserver".base_url = "https://${fqdn}";
"m.identity_server" = {};
};
serverConfig."m.server" = "${fqdn}:443";
mkWellKnown = data: ''
add_header Content-Type application/json;
add_header Access-Control-Allow-Origin *;
return 200 '${builtins.toJSON data}';
'';
extraCfg = pkgs.writeText "synapse-extra-config.yaml" ''
'';
in {
networking.firewall = {
enable = true;
allowedTCPPorts = [ 80 8008 ];
};
networking.domain = "csclub.uwaterloo.ca";

services.postgresql = {
enable = true;
initialScript = pkgs.writeText "synapse-init.sql" ''
CREATE ROLE "matrix-synapse" WITH LOGIN PASSWORD 'synapse';
CREATE DATABASE "matrix-synapse" WITH OWNER "matrix-synapse"
TEMPLATE template0
LC_COLLATE = "C"
LC_CTYPE = "C";
'';
dataDir = "/data/postgresql";
};

services.nginx = {
enable = true;
# recommendedProxySettings = true;
virtualHosts = {
"csclub.uwaterloo.ca" = {
locations."/".extraConfig = ''
return 404;
'';
locations."= /.well-known/matrix/server".extraConfig = mkWellKnown serverConfig;
locations."= /.well-known/matrix/client".extraConfig = mkWellKnown clientConfig;
};
"${fqdn}" = {
locations."/".extraConfig = ''
return 404;
'';
locations."/_matrix".proxyPass = "http://[::1]:8008";
locations."/_matrix".extraConfig = ''
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
'';
locations."/_synapse/client".proxyPass = "http://[::1]:8008";
locations."/_synapse/client".extraConfig = ''
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
'';
};
};
};

services.matrix-synapse = {
enable = true;
extraConfigFiles = [ extraCfg ];
dataDir = "/data/matrix-synapse";
settings = {
server_name = config.networking.domain;
public_baseurl = "https://matrix.csclub.uwaterloo.ca/";
listeners = [
{
port = 8008;
bind_addresses = [ "::1" ];
type = "http";
tls = false;
x_forwarded = true;
resources = [
{
names = [ "client" ]; # no federation
compress = true;
}
];
}
];

oidc_providers = [
{
idp_id = "keycloak";
idp_name = "CSC";
issuer = "https://keycloak.csclub.uwaterloo.ca/realms/csc";
client_id = "synapse";
client_secret = "xxxx"; # fill the client secret from keycloak here
scopes = [ "openid" "profile" ];
user_mapping_provider.config = {
localpart_template = "{{ user.preferred_username }}";
display_name_template = "{{ user.name }}";
};

}
];
registration_shared_secret = "xxxxx";
enable_registration = true;
enable_registration_captcha = false;
registration_requires_token = true;
};
};
}
</pre>

== Testing ==

Go to https://app.cinny.in/login/matrix.csclub.uwaterloo.ca, and click "Continue with CSC".

Proxmox

2025-09-16T02:22:47Z

K95ma: +

The Proxmox Vitural Environment (as of 2025-09-15) lives on the citric-acid machine and can be accessed via https://citric-acid.csclub.uwaterloo.ca:8006.

== Setting up Proxmox ==
To setup proxmox, from `Server View`, open the `Datacenter` page. Then go to `Permissions -> Realms`.

Then just make sure pam is setup lol

== Networking ==
There are two ways to do networking: network bridge and NAT. Network bridge will put the container/virtual machine on the CSC network (basically side-by-side to proxmox itself), while NAT will encapsulate the container/VM inside a private subnet that is only visible to proxmox host itself.

For services that only exposes HTTP/HTTPS, NAT is more desirable since multiple services can share a host nginx instance, only requiring the host IP to have 80/443 port opened to the Internet, thus saving some IP address in our pool and save some trips to the IST for firewall exemption. But for services that requires custom ports to be opened (for example, BigBlueButton requires a range of UDP ports to be exposed for relaying video streams), using the network bridge and giving the container/VM its own public IP might be easier.

Currently, <code>vmbr0</code> is used for bridged network and <code>vmbr1</code> is used for NAT (see [https://pve.proxmox.com/wiki/Network_Configuration#sysadmin_network_masquerading Proxmox's wiki on NAT networking] for setup instruction). <code>vmbr0</code> uses the CSC DHCP server, so you can use DHCP there, but <code>vmbr1</code> requires manual IP assignment.

Note that only using <code>vmbr1</code> requires you to use SSH ProxyJump via citric-acid to access the inner container, as it wouldn't have a public IP.

Keycloak

2025-09-16T01:20:31Z

K95ma: fix

We are using [https://www.keycloak.org/ Keycloak] for web SSO (Single Sign-On). Clients may use Keycloak for authenticating users via SAML or OIDC (OpenID Connect).

* Admin login: https://keycloak.csclub.uwaterloo.ca/admin
* Regular user login: https://keycloak.csclub.uwaterloo.ca/realms/csc/account
* OIDC Auto Discovery URL: https://keycloak.csclub.uwaterloo.ca/realms/csc/.well-known/openid-configuration

== Prerequisites ==
OK so before we get started, there's this really useful feature in Keycloak called "Conditional user attribute" which allows you to create a flow which branches based on attributes a user may have. For some reason, this is enabled in the test suite for Keycloak, but is not available from the main application. So we're going to compile and inject it ourselves.

Clone https://git.csclub.uwaterloo.ca/public/keycloak-spi and run <code>mvn clean package</code>. This will create a JAR file called csc-keycloak-spi.jar in the target directory; upload this to somewhere where it can be easily downloaded, e.g. your www directory.

== Database setup ==
Go to biloba or chamomile, run <code>mysql</code>, and run the following:
<pre>
CREATE USER 'keycloak' IDENTIFIED BY 'replace_this_password';
CREATE DATABASE keycloak CHARACTER SET utf8 COLLATE utf8_unicode_ci;
GRANT ALL PRIVILEGES ON keycloak.* TO 'keycloak';
FLUSH PRIVILEGES;
</pre>

== Kubernetes setup ==
We are running Keycloak on Kubernetes. This introduces some complications because it gets reverse proxied twice, and we also can't (or at least shouldn't) modify the filesystem of the Pod where it's running, since that Pod can get destroyed at any time. We still need to load that JAR file we just created, though, so we're going to place it into a PersistentVolume instead. We're going to do this by first creating a PersistentVolumeClaim, then claiming it in a temporary Pod which we'll use for shell access:
<pre>
cat <<EOF | kubectl apply -f
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
namespace: syscom
name: keycloak-spi-pvc
spec:
storageClassName: cloudstack-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Mi
---
apiVersion: v1
kind: Pod
metadata:
namespace: syscom
name: temp-pod
spec:
containers:
- name: temp
image: alpine
volumeMounts:
- mountPath: "/data"
name: keycloak-spi-pv
stdin: true
stdinOnce: true
tty: true
volumes:
- name: keycloak-spi-pv
persistentVolumeClaim:
claimName: keycloak-spi-pvc
EOF
</pre>
Run <code>kubectl -n syscom get pods</code> a few times to check if the pod is ready; once it is, attach to it:
<pre>
kubectl -n syscom exec -it temp-pod -- sh
cd /data
mkdir keycloak-spi
chmod a+w keycloak-spi
cd keycloak-spi
wget https://csclub.uwaterloo.ca/~merenber/csc-keycloak-spi.jar
exit
</pre>
Now delete the pod since we don't need it anymore:
<pre>
kubectl -n syscom delete pod temp-pod
</pre>
Create some secrets (use the MySQL password which you chose earlier):
<pre>
kubectl -n syscom create secret generic keycloak-secret \
--from-literal=DB_USER=some_user \
--from-literal=DB_PASSWORD=some_password \
--from-literal=KEYCLOAK_USER=some_user \
--from-literal=KEYCLOAK_PASSWORD=some_password
</pre>
Now apply the main manifest:
<pre>
kubectl apply -f https://git.csclub.uwaterloo.ca/cloud/manifests/raw/branch/master/keycloak.yaml
</pre>

== DNS setup ==
From Infoblox, make keycloak.csclub.uwaterloo.ca a CNAME for rr-public-cloud.csclub.uwaterloo.ca; that record points to biloba and chamomile, which know how to reverse proxy requests to Kubernetes.

== NGINX setup ==
Pretty standard stuff:
<pre>
server {
listen 80;
listen [::]:80;
server_name keycloak.csclub.uwaterloo.ca;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name keycloak.csclub.uwaterloo.ca;
ssl_certificate /etc/ssl/private/csclub.uwaterloo.ca.chain;
ssl_certificate_key /etc/ssl/private/csclub.uwaterloo.ca.key;

location / {
proxy_pass http://k8s;
}
include proxy_params;

access_log /var/log/nginx/keycloak-access.log;
error_log /var/log/nginx/keycloak-error.log;
}
</pre>
Also make sure you have the following snippet in /etc/nginx/proxy_params:
<pre>
# Increase buffer size
# See https://ma.ttias.be/nginx-proxy-upstream-sent-big-header-reading-response-header-upstream/
proxy_buffer_size 128k;
proxy_buffers 4 256k;
</pre>
Don't forget to enable the site and reload NGINX on both chamomile and biloba.

== Web UI setup ==
If all went well, you should now be able to visit https://keycloak.csclub.uwaterloo.ca from your browser.
Create a new realm called 'csc'. Set the Display Name to 'Computer Science Club'.

=== Realm settings ===
From the web UI, go to 'Realm Settings', click the Login tab, and disable 'Login with email'.

Now click on the 'Tokens' tab. Set 'SSO Session Idle' and 'SSO Session Max' to 120 days each. You can optionally do this for the Master realm as well.

Now click on the 'Email' tab.

* Set 'Host' to 'mail.csclub.uwaterloo.ca'.
* Set 'From Display Name' to 'Keycloak'.
* Set 'From' to 'no-reply@csclub.uwaterloo.ca'.
* Set 'Reply To Display Name' to 'Systems Committee'.
* Set 'Reply To' to 'syscom@csclub.uwaterloo.ca'.
* Set 'Envelope From' to 'keycloak@csclub.uwaterloo.ca'.
* Enable StartTLS.

=== Authentication Settings ===
Click on 'Authentication' from the panel on the left-hand side.

==== Flows ====
Click on the 'Flows' tab and select the 'Browser' flow from the dropdown. Create a copy called 'CSC Browser' and make it look like this:
<pre>
Cookie (Alternative)
CSC Browser Forms (Alternative)
Username Password Form (Required)
CSC Membership Check (Conditional)
Condition - User Attribute (Required)
Deny Access (Required)
OTP Form (Required)
</pre>
The condition should be whether a user has the attribute 'shadowExpire' set to '1'. Set the error message in 'Deny Access' to something reasonable (this gets displayed to users).

Screenshot:
[[File:Keycloak_CSC_Browser_Flow.png]]

Select the 'First Broker Login' flow and create a copy called 'CSC First Broker Login'. This will be invoked when a user signs in with an Identity Provider, and the IdP user ID is not linked to a Keycloak user. Make the flow look like this:
<pre>
Review Profile (Disabled)
User Creation or Linking (Required)
Detect Existing Broker User (Required)
Automatically Set Existing User (Required)
CSC Membership Check (Conditional)
Condition - User Attribute (Required)
Deny Access (Required)
</pre>

Finally, create a new flow called 'CSC Browser - IdP post-login'. This will be invoked when a user signs in with an IdP, and the IdP user ID has already been linked to a Keycloak user. Make it look like this:
<pre>
CSC Membership Check - IdP Post-login (Conditional)
Condition - User Attribute (Membership expired - IdP post-login) (Required)
Deny Access (Denied because membership expired - IdP post-login) (Required)
Allow Access
</pre>
Note that the last step needs to be 'Allow Access'.

==== Bindings ====
Click on the 'Bindings' tab and set 'Browser Flow' to 'CSC Browser'.

==== Required Actions ====
Click on the 'Required Actions' tab and disable the following:

* Update Password
* Update Profile
* Delete Account

=== User Federation ===
Click on 'User Federation' from the left-hand panel and select 'ldap'. Configure it as follows:

* Edit Mode: READ_ONLY
* Vendor: Other
* Username LDAP attribute: uid
* RDN LDAP attribute: uid
* UUID LDAP attribute: entryUUID
* User Object Classes: member
* Connection URL: ldaps://ldap1.csclub.uwaterloo.ca ldaps://ldap2.csclub.uwaterloo.ca
* Users DN: ou=People,dc=csclub,dc=uwaterloo,dc=ca
* Custom User LDAP Filter: (objectClass=member)
* Search Scope: One Level
* Bind Type: none

Under Sync Settings, enable Changed Users Full Sync. Set the Changed Users Sync Period to something reasonable (should be at least once a day).

Click on Mappers, click 'email', and set the LDAP Attribute to 'mailLocalAddress'. Also set the LDAP Attribute for 'First Name' to 'givenName'.

Create a new mapper of type 'user-attribute-ldap-mapper'. Set 'User Model Attribute' and 'LDAP Attribute' to 'shadowExpire'. Enable 'Always Read Value From LDAP'.

Now click the 'Synchronize all users' button from the main LDAP configuration page. This will take a few minutes so be patient.

=== Identity Providers ===
We are going to use [[ADFS]] for identity brokering. The idea is to allow members to login using their CSC credentials or their UW credentials.

==== SAML Passthrough ====
I created a monstrosity called [https://git.csclub.uwaterloo.ca/merenber/saml-passthrough saml-passthrough]. The idea is to protect a SAML IdP behind another SAML IdP (ADFS). So basically SAML-inside-SAML.

The reason why we need this is because we can't change the AssertionConsumerService endpoint URL which we originally submitted to IST (if we really wanted to, we could submit another form, but that requires assistance from a faculty member, and it's just a big PiTA). This also allows us to multiplex ADFS information to multiple Keycloak realms, if necessary.

Anywho, the instructions for setting it up are in the README (it's just a FastCGI application). It should be running on caffeine right now under /srv/saml-passthrough. It's configured to download SP metadata from Keycloak at startup, so if you update the SP certificate in Keycloak, make sure to restart the saml-passthrough service.

Now, back to the Keycloak UI. Click 'Identity Providers' from the left-hand side, and add a SAML provider. Set the following:

* Alias: adfs
* Display Name: University of Waterloo (ADFS)
* First Login Flow: CSC First Login Flow
* Post Login Flow: CSC Browser - IdP post-login
* Sync Mode: legacy
* Service Provider Entity ID: https://keycloak.csclub.uwaterloo.ca/auth/realms/csc
* Single Sign-On Service URL: https://csclub.uwaterloo.ca/keycloak/saml/sso
* Principal Type: Attribute [Friendly Name]
* Principal Attribute: uid
* HTTP-POST Binding Response: ON
* Want AuthnRequests Signed: ON
* Want Assertions Signed: ON
* Validate Signature: ON
* Validating X509 certificates: download the content of https://csclub.uwaterloo.ca/keycloak/saml/metadata and copy and paste the value inside the <code><X509Certificate></code> tag.

That X509 certificate will expire in January 2032; before then, make sure you do the following:

* create a new keypair in /srv/saml-passthrough on caffeine
* restart the saml-passthrough service
* update the 'Validating X509 certificates' field in Keycloak

Keycloak's SP certificate (which can be viewed from Realm Settings -> Keys -> Providers -> rsa-generated) will expire in December 2031; before then, make sure you upload a new keypair (just choose 'rsa-generated' from the 'Add keystore' dropdown), then restart the saml-passthrough service on caffeine.

== Testing ==
Here's a test OIDC application which you can use to verify that everything is working: https://www.keycloak.org/app/#url=https://keycloak.csclub.uwaterloo.ca/&realm=csc&client=test

Keycloak

2025-09-16T01:05:24Z

K95ma: /* Testing */ fix

We are using [https://www.keycloak.org/ Keycloak] for web SSO (Single Sign-On). Clients may use Keycloak for authenticating users via SAML or OIDC (OpenID Connect).

* Admin login: https://keycloak.csclub.uwaterloo.ca/auth/admin
* Regular user login: https://keycloak.csclub.uwaterloo.ca/auth/realms/csc/account
* OIDC Auto Discovery URL: https://keycloak.csclub.uwaterloo.ca/auth/realms/csc/.well-known/openid-configuration

== Prerequisites ==
OK so before we get started, there's this really useful feature in Keycloak called "Conditional user attribute" which allows you to create a flow which branches based on attributes a user may have. For some reason, this is enabled in the test suite for Keycloak, but is not available from the main application. So we're going to compile and inject it ourselves.

Clone https://git.csclub.uwaterloo.ca/public/keycloak-spi and run <code>mvn clean package</code>. This will create a JAR file called csc-keycloak-spi.jar in the target directory; upload this to somewhere where it can be easily downloaded, e.g. your www directory.

== Database setup ==
Go to biloba or chamomile, run <code>mysql</code>, and run the following:
<pre>
CREATE USER 'keycloak' IDENTIFIED BY 'replace_this_password';
CREATE DATABASE keycloak CHARACTER SET utf8 COLLATE utf8_unicode_ci;
GRANT ALL PRIVILEGES ON keycloak.* TO 'keycloak';
FLUSH PRIVILEGES;
</pre>

== Kubernetes setup ==
We are running Keycloak on Kubernetes. This introduces some complications because it gets reverse proxied twice, and we also can't (or at least shouldn't) modify the filesystem of the Pod where it's running, since that Pod can get destroyed at any time. We still need to load that JAR file we just created, though, so we're going to place it into a PersistentVolume instead. We're going to do this by first creating a PersistentVolumeClaim, then claiming it in a temporary Pod which we'll use for shell access:
<pre>
cat <<EOF | kubectl apply -f
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
namespace: syscom
name: keycloak-spi-pvc
spec:
storageClassName: cloudstack-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Mi
---
apiVersion: v1
kind: Pod
metadata:
namespace: syscom
name: temp-pod
spec:
containers:
- name: temp
image: alpine
volumeMounts:
- mountPath: "/data"
name: keycloak-spi-pv
stdin: true
stdinOnce: true
tty: true
volumes:
- name: keycloak-spi-pv
persistentVolumeClaim:
claimName: keycloak-spi-pvc
EOF
</pre>
Run <code>kubectl -n syscom get pods</code> a few times to check if the pod is ready; once it is, attach to it:
<pre>
kubectl -n syscom exec -it temp-pod -- sh
cd /data
mkdir keycloak-spi
chmod a+w keycloak-spi
cd keycloak-spi
wget https://csclub.uwaterloo.ca/~merenber/csc-keycloak-spi.jar
exit
</pre>
Now delete the pod since we don't need it anymore:
<pre>
kubectl -n syscom delete pod temp-pod
</pre>
Create some secrets (use the MySQL password which you chose earlier):
<pre>
kubectl -n syscom create secret generic keycloak-secret \
--from-literal=DB_USER=some_user \
--from-literal=DB_PASSWORD=some_password \
--from-literal=KEYCLOAK_USER=some_user \
--from-literal=KEYCLOAK_PASSWORD=some_password
</pre>
Now apply the main manifest:
<pre>
kubectl apply -f https://git.csclub.uwaterloo.ca/cloud/manifests/raw/branch/master/keycloak.yaml
</pre>

== DNS setup ==
From Infoblox, make keycloak.csclub.uwaterloo.ca a CNAME for rr-public-cloud.csclub.uwaterloo.ca; that record points to biloba and chamomile, which know how to reverse proxy requests to Kubernetes.

== NGINX setup ==
Pretty standard stuff:
<pre>
server {
listen 80;
listen [::]:80;
server_name keycloak.csclub.uwaterloo.ca;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name keycloak.csclub.uwaterloo.ca;
ssl_certificate /etc/ssl/private/csclub.uwaterloo.ca.chain;
ssl_certificate_key /etc/ssl/private/csclub.uwaterloo.ca.key;

location / {
proxy_pass http://k8s;
}
include proxy_params;

access_log /var/log/nginx/keycloak-access.log;
error_log /var/log/nginx/keycloak-error.log;
}
</pre>
Also make sure you have the following snippet in /etc/nginx/proxy_params:
<pre>
# Increase buffer size
# See https://ma.ttias.be/nginx-proxy-upstream-sent-big-header-reading-response-header-upstream/
proxy_buffer_size 128k;
proxy_buffers 4 256k;
</pre>
Don't forget to enable the site and reload NGINX on both chamomile and biloba.

== Web UI setup ==
If all went well, you should now be able to visit https://keycloak.csclub.uwaterloo.ca from your browser.
Create a new realm called 'csc'. Set the Display Name to 'Computer Science Club'.

=== Realm settings ===
From the web UI, go to 'Realm Settings', click the Login tab, and disable 'Login with email'.

Now click on the 'Tokens' tab. Set 'SSO Session Idle' and 'SSO Session Max' to 120 days each. You can optionally do this for the Master realm as well.

Now click on the 'Email' tab.

* Set 'Host' to 'mail.csclub.uwaterloo.ca'.
* Set 'From Display Name' to 'Keycloak'.
* Set 'From' to 'no-reply@csclub.uwaterloo.ca'.
* Set 'Reply To Display Name' to 'Systems Committee'.
* Set 'Reply To' to 'syscom@csclub.uwaterloo.ca'.
* Set 'Envelope From' to 'keycloak@csclub.uwaterloo.ca'.
* Enable StartTLS.

=== Authentication Settings ===
Click on 'Authentication' from the panel on the left-hand side.

==== Flows ====
Click on the 'Flows' tab and select the 'Browser' flow from the dropdown. Create a copy called 'CSC Browser' and make it look like this:
<pre>
Cookie (Alternative)
CSC Browser Forms (Alternative)
Username Password Form (Required)
CSC Membership Check (Conditional)
Condition - User Attribute (Required)
Deny Access (Required)
OTP Form (Required)
</pre>
The condition should be whether a user has the attribute 'shadowExpire' set to '1'. Set the error message in 'Deny Access' to something reasonable (this gets displayed to users).

Screenshot:
[[File:Keycloak_CSC_Browser_Flow.png]]

Select the 'First Broker Login' flow and create a copy called 'CSC First Broker Login'. This will be invoked when a user signs in with an Identity Provider, and the IdP user ID is not linked to a Keycloak user. Make the flow look like this:
<pre>
Review Profile (Disabled)
User Creation or Linking (Required)
Detect Existing Broker User (Required)
Automatically Set Existing User (Required)
CSC Membership Check (Conditional)
Condition - User Attribute (Required)
Deny Access (Required)
</pre>

Finally, create a new flow called 'CSC Browser - IdP post-login'. This will be invoked when a user signs in with an IdP, and the IdP user ID has already been linked to a Keycloak user. Make it look like this:
<pre>
CSC Membership Check - IdP Post-login (Conditional)
Condition - User Attribute (Membership expired - IdP post-login) (Required)
Deny Access (Denied because membership expired - IdP post-login) (Required)
Allow Access
</pre>
Note that the last step needs to be 'Allow Access'.

==== Bindings ====
Click on the 'Bindings' tab and set 'Browser Flow' to 'CSC Browser'.

==== Required Actions ====
Click on the 'Required Actions' tab and disable the following:

* Update Password
* Update Profile
* Delete Account

=== User Federation ===
Click on 'User Federation' from the left-hand panel and select 'ldap'. Configure it as follows:

* Edit Mode: READ_ONLY
* Vendor: Other
* Username LDAP attribute: uid
* RDN LDAP attribute: uid
* UUID LDAP attribute: entryUUID
* User Object Classes: member
* Connection URL: ldaps://ldap1.csclub.uwaterloo.ca ldaps://ldap2.csclub.uwaterloo.ca
* Users DN: ou=People,dc=csclub,dc=uwaterloo,dc=ca
* Custom User LDAP Filter: (objectClass=member)
* Search Scope: One Level
* Bind Type: none

Under Sync Settings, enable Changed Users Full Sync. Set the Changed Users Sync Period to something reasonable (should be at least once a day).

Click on Mappers, click 'email', and set the LDAP Attribute to 'mailLocalAddress'. Also set the LDAP Attribute for 'First Name' to 'givenName'.

Create a new mapper of type 'user-attribute-ldap-mapper'. Set 'User Model Attribute' and 'LDAP Attribute' to 'shadowExpire'. Enable 'Always Read Value From LDAP'.

Now click the 'Synchronize all users' button from the main LDAP configuration page. This will take a few minutes so be patient.

=== Identity Providers ===
We are going to use [[ADFS]] for identity brokering. The idea is to allow members to login using their CSC credentials or their UW credentials.

==== SAML Passthrough ====
I created a monstrosity called [https://git.csclub.uwaterloo.ca/merenber/saml-passthrough saml-passthrough]. The idea is to protect a SAML IdP behind another SAML IdP (ADFS). So basically SAML-inside-SAML.

The reason why we need this is because we can't change the AssertionConsumerService endpoint URL which we originally submitted to IST (if we really wanted to, we could submit another form, but that requires assistance from a faculty member, and it's just a big PiTA). This also allows us to multiplex ADFS information to multiple Keycloak realms, if necessary.

Anywho, the instructions for setting it up are in the README (it's just a FastCGI application). It should be running on caffeine right now under /srv/saml-passthrough. It's configured to download SP metadata from Keycloak at startup, so if you update the SP certificate in Keycloak, make sure to restart the saml-passthrough service.

Now, back to the Keycloak UI. Click 'Identity Providers' from the left-hand side, and add a SAML provider. Set the following:

* Alias: adfs
* Display Name: University of Waterloo (ADFS)
* First Login Flow: CSC First Login Flow
* Post Login Flow: CSC Browser - IdP post-login
* Sync Mode: legacy
* Service Provider Entity ID: https://keycloak.csclub.uwaterloo.ca/auth/realms/csc
* Single Sign-On Service URL: https://csclub.uwaterloo.ca/keycloak/saml/sso
* Principal Type: Attribute [Friendly Name]
* Principal Attribute: uid
* HTTP-POST Binding Response: ON
* Want AuthnRequests Signed: ON
* Want Assertions Signed: ON
* Validate Signature: ON
* Validating X509 certificates: download the content of https://csclub.uwaterloo.ca/keycloak/saml/metadata and copy and paste the value inside the <code><X509Certificate></code> tag.

That X509 certificate will expire in January 2032; before then, make sure you do the following:

* create a new keypair in /srv/saml-passthrough on caffeine
* restart the saml-passthrough service
* update the 'Validating X509 certificates' field in Keycloak

Keycloak's SP certificate (which can be viewed from Realm Settings -> Keys -> Providers -> rsa-generated) will expire in December 2031; before then, make sure you upload a new keypair (just choose 'rsa-generated' from the 'Add keystore' dropdown), then restart the saml-passthrough service on caffeine.

== Testing ==
Here's a test OIDC application which you can use to verify that everything is working: https://www.keycloak.org/app/#url=https://keycloak.csclub.uwaterloo.ca/&realm=csc&client=test

User:K95ma

2025-09-13T01:54:11Z

K95ma: Created page with "Termcom guy"

Termcom guy

LDAP

2025-09-10T00:58:05Z

K95ma: /* Querying LDAP */ fix command

We use [http://www.openldap.org/ OpenLDAP] for directory services. Our primary LDAP server is [[Machine_List#auth1|auth1]] and our secondary LDAP server is [[Machine_List#auth2|auth2]].

=== ehashman's Guide to Setting up OpenLDAP on Debian ===

Welcome to my nightmare.

==== What is LDAP? ====

<blockquote>'''LDAP:''' Lightweight Directory Access Protocol

An open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. — [https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol Wikipedia: LDAP]
</blockquote>
In this case, "directory" refers to the user directory, like on an old-school Rolodex. Many groups use LDAP to maintain their user directory, including the University (the "WatIAM" identity management system), the Computer Science Club, and even the UW Amateur Radio Club.

This is a guide documenting how to set up LDAP on a Debian Linux system.

==== First steps ====

<ul>
<li>Ensure that openldap is installed on the machine:
<pre># apt-get install slapd ldap-utils</pre></li>
<li>Debian will do a lot of magic and set up a skeleton LDAP server and get it running. We need to configure that further.</li>
<li>Let's set up logging before we forget. Create the following files in <code>/var/log</code>:
<pre># mkdir /var/log/ldap
# touch /var/log/ldap.log</pre></li>
<li>Set ownership correctly:
<pre># chown openldap:openldap /var/log/ldap</pre></li>
<li>Set up rsyslog to dump the LDAP logs into <code>/var/log/ldap.log</code> by adding the following lines:
<pre># vim /etc/rsyslog.conf
...
# Grab ldap logs, don't duplicate in syslog
local4.* /var/log/ldap.log</pre></li>
<li>Set up log rotation for these by creating the file [https://git.uwaterloo.ca/wics/documentation/blob/master/ldap/logrotate.d.ldap <code>/etc/logrotate.d/ldap</code>] with the following contents:
<pre>/var/log/ldap/*log {
weekly
missingok
rotate 1000
compress
delaycompress
notifempty
create 0640 openldap adm
postrotate
if [ -f /var/run/slapd/slapd.pid ]; then
/etc/init.d/slapd restart >/dev/null 2>&1
fi
endscript
}

/var/log/ldap.log {
weekly
missingok
rotate 24
compress
delaycompress
notifempty
}</pre></li>
<li>As of OpenLDAP 2.4, it doesn't actually create a config file for us. Apparently, this is a "feature": LDAP maintainers think we should want to set this up via dynamic queries. We don't, so the first thing we need is our [https://git.uwaterloo.ca/wics/documentation/blob/master/ldap/slapd.conf <code>slapd.conf</code>] file.</li></ul>

===== Building <code>slapd.conf</code> from scratch =====

<ul>
<li>Get a copy to work with:
<pre># scp uid@auth1.csclub.uwaterloo.ca:/etc/ldap/slapd.conf /etc/ldap/ ## you need CSC root for this</pre></li>
<li>You'll want to comment out the TLS lines, and anything referring to Kerberos and access for now. You'll also want to comment out lines specifically referring to syscom and office staff.</li>
<li>Make sure you remove the reference to <code>nonMemberTerm</code> as an index, as we're going to remove this field.</li>
<li>You'll also need to generate a root password for the LDAP to bootstrap auth, like so:
<pre># slappasswd
New password:
Re-enter new password:
{SSHA}longhash</pre></li>
<li>Add this line below <code>rootdn</code> in the <code>slapd.conf</code>:
<pre>rootpw {SSHA}longhash</pre></li>
<li>Now we want to edit all instances of "csclub" to be "wics" instead, e.g.:
<pre>suffix "dc=wics,dc=uwaterloo,dc=ca"
rootdn "cn=root,dc=wics,dc=uwaterloo,dc=ca"</pre></li>
<li>Next, we need to grab all the relevant schemas:
<pre>scp -r uid@auth1.csclub.uwaterloo.ca:/etc/ldap/schema/ /tmp/schemas</pre></li>
<li>Use the include directives to help you find the ones you need. I noticed we were missing <code>sudo.schema</code>, <code>csc.schema</code>, and <code>rfc2307bis.schema</code>.</li>
<li>Open up the [https://git.uwaterloo.ca/wics/documentation/blob/master/ldap/csc.schema <code>csc.schema</code>] for editing; we're not using it verbatim. Remove the attributes <code>studentid</code> and <code>nonMemberTerm</code> and the objectclass <code>club</code>. Also make sure you change the OID so we don't clash with the CSC. Because we didn't want to go through the process of requesting a [http://pen.iana.org/pen/PenApplication.page PEN number], we chose arbitrarily to use 26338, which belongs to IWICS Inc.</li>
<li>We also need to can the auto-generated config files, so do that:
<pre># rm -rf /etc/openldap/slapd.d/*</pre></li>
<li>Also nuke the auto-generated database:
<pre># rm /var/lib/ldap/__db.*</pre></li>
<li>Configure the database:
<pre># cp /usr/share/slapd/DB_CONFIG /var/lib/ldap/
# chown openldap:openldap /var/lib/ldap/DB_CONFIG </pre></li>
<li>Now we can generate the new configuration files:
<pre># slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d/</pre></li>
<li>And ensure that the permissions are all set correctly, lest this break something:
<pre># chown -R openldap:openldap /etc/ldap/slapd.d</pre></li>
<li>If at this point you get a nasty error, such as
<pre>5657d4db hdb_db_open: database "dc=wics,dc=uwaterloo,dc=ca": db_open(/var/lib/ldap/id2entry.bdb) failed: No such file or directory (2).
5657d4db backend_startup_one (type=hdb, suffix="dc=wics,dc=uwaterloo,dc=ca"): bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)</pre>
Just try restarting slapd, and see if that fixes the problem:
<pre># service slapd stop
# service slapd start</pre></li>
<li>Congratulations! Your LDAP service is now configured and running.</li></ul>

==== Getting TLS Up and Running ====

<ul>
<li>Now that we have our LDAP service, we'll want to be able to serve encrypted traffic. This is especially important for any remote access, since binding to LDAP (i.e. sending it a password for auth) occurs over plaintext, and we don't want to leak our admin password.</li>
<li>Our first step is to copy our SSL certificates into the correct places. Public ones go into <code>/etc/ssl/certs/</code> and private ones go into <code>/etc/ssl/private/</code>.</li>
<li>Since the LDAP daemon needs to be able to read our private cert, we need to grant LDAP access to the private folder:
<pre># chgrp openldap /etc/ssl/private
# chmod g+x /etc/ssl/private</pre></li>
<li>Next, uncomment the TLS-related settings in <code>slapd.conf</code>. These are <code>TLSCertificateFile</code> (the public cert), <code>TLSCertificateKeyFile</code> (the private key), <code>TLSCACertificateFile</code> (the intermediate CA cert), and <code>TLSVerifyClient</code> (set to "allow").
<pre># enable TLS connections
TLSCertificateFile /etc/ssl/certs/wics-wildcard.crt
TLSCertificateKeyFile /etc/ssl/private/wics-wildcard.key

# enable TLS client authentication
TLSCACertificateFile /etc/ssl/certs/GlobalSign_Intermediate_Root_SHA256_G2.pem
TLSVerifyClient allow</pre></li>
<li>Update all your LDAP settings:
<pre># rm -rf /etc/openldap/slapd.d/*
# slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d/
# chown -R openldap:openldap /etc/ldap/slapd.d</pre></li>
<li>And last, ensure that LDAP will actually serve <code>ldaps://</code> by modifying the init script variables in <code>/etc/default/</code>:
<pre># vim /etc/default/slapd
...
SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"
...</pre></li>
<li>Now you can restart the LDAP server:
<pre># service slapd restart</pre></li>
<li>And assuming this is successful, test to ensure LDAP is serving on port 636 for <code>ldaps://</code>:
<pre># netstat -ntaup
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 22847/slapd
tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 22847/slapd </pre></li></ul>

==== Populating the Database ====

Now you'll need to start adding objects to the database. While we'll want to mostly do this programmatically, there are a few entries we'll need to bootstrap.

===== Root Entries =====

<ul>
<li>Start by creating a file [https://git.uwaterloo.ca/wics/documentation/blob/master/ldap/tree.ldif <code>tree.ldif</code>] to create a few necessary "roots" in our LDAP tree, with the contents:
<pre>dn: dc=wics,dc=uwaterloo,dc=ca
objectClass: dcObject
objectClass: organization
o: Women in Computer Science
dc: wics

dn: ou=People,dc=wics,dc=uwaterloo,dc=ca
objectClass: organizationalUnit
ou: People

dn: ou=Group,dc=wics,dc=uwaterloo,dc=ca
objectClass: organizationalUnit
ou: Group</pre></li>
<li>Now attempt an LDAP add, using the password you set earlier:
<pre># ldapadd -cxWD cn=root,dc=wics,dc=uwaterloo,dc=ca -f tree.ldif
Enter LDAP Password:
adding new entry "dc=wics,dc=uwaterloo,dc=ca"

adding new entry "ou=People,dc=wics,dc=uwaterloo,dc=ca"

adding new entry "ou=Group,dc=wics,dc=uwaterloo,dc=ca"</pre></li>
<li>Test that everything turned out okay, by performing a query of the entire database:
<pre># ldapsearch -x -h localhost
# extended LDIF
#
# LDAPv3
# base <dc=wics,dc=uwaterloo,dc=ca> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# wics.uwaterloo.ca
dn: dc=wics,dc=uwaterloo,dc=ca
objectClass: dcObject
objectClass: organization
o: Women in Computer Science
dc: wics

# People, wics.uwaterloo.ca
dn: ou=People,dc=wics,dc=uwaterloo,dc=ca
objectClass: organizationalUnit
ou: People

# Group, wics.uwaterloo.ca
dn: ou=Group,dc=wics,dc=uwaterloo,dc=ca
objectClass: organizationalUnit
ou: Group

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3</pre></li></ul>

===== Users and Groups =====

<ul>
<li>Next, add users to track the current GID and UID. This will save us from querying the entire database every time we make a new user or group. Create this file, [https://git.uwaterloo.ca/wics/documentation/blob/master/ldap/nextxid.ldif <code>nextxid.ldif</code>]:
<pre>dn: uid=nextuid,ou=People,dc=wics,dc=uwaterloo,dc=ca
cn: nextuid
objectClass: account
objectClass: posixAccount
objectClass: top
uidNumber: 20000
gidNumber: 20000
homeDirectory: /dev/null

dn: cn=nextgid,ou=Group,dc=wics,dc=uwaterloo,dc=ca
objectClass: group
objectClass: posixGroup
objectClass: top
gidNumber: 10000</pre>
You'll see here that our first GID is 10000 and our first UID is 20000.</li>
<li>Now add them, like you did with the roots of the tree:
<pre># ldapadd -cxWD cn=root,dc=wics,dc=uwaterloo,dc=ca -f nextxid.ldif
Enter LDAP Password:
adding new entry "uid=nextuid,ou=People,dc=wics,dc=uwaterloo,dc=ca"

adding new entry "cn=nextgid,ou=Group,dc=wics,dc=uwaterloo,dc=ca"</pre></li></ul>

===== Special <code>sudo</code> Entries =====

<ul>
<li>We also need to add a sudoers OU with a defaults object for default sudo settings. We also need entries for syscom, such that members of the syscom group can use sudo on all hosts, and for termcom, whose members can use sudo on only the office terminals. Call this one [https://git.uwaterloo.ca/wics/documentation/blob/master/ldap/sudoers.ldif <code>sudoers.ldif</code>]:
<pre>dn: ou=SUDOers,dc=wics,dc=uwaterloo,dc=ca
objectClass: organizationalUnit
ou: SUDOers

dn: cn=defaults,ou=SUDOers,dc=wics,dc=uwaterloo,dc=ca
objectClass: top
objectClass: sudoRole
cn: defaults
sudoOption: !lecture
sudoOption: env_reset
sudoOption: listpw=never
sudoOption: mailto="wics-sys@lists.uwaterloo.ca"
sudoOption: shell_noargs

dn: cn=%syscom,ou=SUDOers,dc=wics,dc=uwaterloo,dc=ca
objectClass: top
objectClass: sudoRole
cn: %syscom
sudoUser: %syscom
sudoHost: ALL
sudoCommand: ALL
sudoRunAsUser: ALL

dn: cn=%termcom,ou=SUDOers,dc=wics,dc=uwaterloo,dc=ca
objectClass: top
objectClass: sudoRole
cn: %termcom
sudoUser: %termcom
sudoHost: honk
sudoHost: hiss
sudoHost: gosling
sudoCommand: ALL
sudoRunAsUser: ALL</pre></li>
<li>Now add them:
<pre># ldapadd -cxWD cn=root,dc=wics,dc=uwaterloo,dc=ca -f sudoers.ldif
Enter LDAP Password:
adding new entry "ou=SUDOers,dc=wics,dc=uwaterloo,dc=ca"

adding new entry "cn=defaults,ou=SUDOers,dc=wics,dc=uwaterloo,dc=ca"

adding new entry "cn=%syscom,ou=SUDOers,dc=wics,dc=uwaterloo,dc=ca"

adding new entry "cn=%termcom,ou=SUDOers,dc=wics,dc=uwaterloo,dc=ca"</pre></li>
<li>Last, add some special local groups via [https://git.uwaterloo.ca/wics/documentation/blob/master/ldap/local-groups.ldif <code>local-groups.ldif</code>]:
<pre># ldapadd -cxWD cn=root,dc=wics,dc=uwaterloo,dc=ca -f local-groups.ldif</pre>
The local groups are special because they usually are present on all systems, but we want to be able to add users to them at the LDAP level. For instance, the audio group controls access to sound equipment, and the adm group controls log read access.</li>
<li>That's all the entries we have to add manually! Now we can use software for the rest. See [[weo|<code>ceo</code>]] for more details.</li></ul>

=== Querying LDAP ===

There are many tools available for issuing LDAP queries. Queries should be issued to <tt>ldap1.csclub.uwaterloo.ca</tt>. The search base you almost certainly want is <tt>dc=csclub,dc=uwaterloo,dc=ca</tt>. Read access is available without authentication; [[Kerberos]] is used to authenticate commands which require it.

Example:

ldapsearch -x -H ldap://ldap1.csclub.uwaterloo.ca -b dc=csclub,dc=uwaterloo,dc=ca uid=ctdalek

The <tt>-x</tt> option causes <tt>ldapsearch</tt> to switch to simple authentication rather than trying to authenticate via SASL (which will fail if you do not have a Kerberos ticket).

The University LDAP server (uwldap.uwaterloo.ca) can also be queried like this. Again, use "simple authentication" as read access is available (from on campus) without authentication. SASL authentication will fail without additional parameters.

Example:

ldapsearch -x -H ldap://uwldap.uwaterloo.ca -b dc=uwaterloo,dc=ca "cn=Prabhakar Ragde"

=== Replication ===

While <tt>ldap1.csclub.uwaterloo.ca</tt> ([[Machine_List#auth1|auth1]]) is the LDAP master, an up-to-date replica is available on <tt>ldap2.csclub.uwaterloo.ca</tt> ([[Machine_List#auth2|auth2]]).

In order to replicate changes from the master, the slave maintains an authenticated connection to the master which provides it with full read access to all changes.

Specifically, <tt>/etc/systemd/system/k5start-slapd.service</tt> maintains an active Kerberos ticket for <tt>ldap/auth2.csclub.uwaterloo.ca@CSCLUB.UWATERLOO.CA</tt> in <tt>/var/run/slapd/krb5cc</tt>. This is then used to authenticate the slave to the server, who maps this principal to <tt>cn=ldap-slave,dc=csclub,dc=uwaterloo,dc=ca</tt>, which in turn has full read privileges.

In the event of master failure, all hosts should fail LDAP reads seamlessly over to the slave.

[[Category:Software]]

=== Modifying LDAP entry ===

Editing entries can be easily done with <code>ldapvi</code>. First search for the entry using <code>ldapsearch</code> like above, and change <code>ldapsearch -x</code> to <code>ldapvi -Y GSSAPI</code> to make your edits.

Note that if your <tt>EDITOR</tt> enviroment is set to something not avaliable it will give out errors like

error (misc.c line 180): No such file or directory
editor died
error (ldapvi.c line 83): No such file or directory

This can be fixed by something like

EDITOR=vi ldapvi ******

==== Changing a user's username ====

Only a member of the Systems Committee can change a user's username. '''At all times, a user's username must match the user's username in WatIAM.'''

All changes to an account MUST be done in person so that identity can be confirmed. If a member cannot attend in person, then an alternate method of identity verification may be chosen by the Systems Administrator.

# Edit entries in LDAP (<code>ldapvi -Y GSSAPI</code>)
#* Find and replace the user's old username with the new one (<code>%s/$OLD/$NEW/g</code>)
# Change the user's Kerberos principal (on auth1 using <code>kadmin</code>, <code>renprinc $OLD $NEW</code>)
# Move the user's home directory (on phosphoric-acid, <code>mv /users/$OLD /users/$NEW</code>)
# Modify the user's ~/.forward file if their old username is in it.
# Change the user's csc-general (and csc-industry, if subscribed) email address for <code>$OLD@csclub.uwaterloo.ca</code> to <code>$NEW@csclub.uwaterloo.ca</code>
#* https://mailman.csclub.uwaterloo.ca/admin/csc-general
# If the user has vhosts on caffeine, update them to point to their new username

If the user's account has been around for a while, and they request it, forward email from their old username to their new one.

# Edit <code>/etc/aliases</code> on mail. <code>$OLD: $NEW</code>
# Run <code>newaliases</code>

MediaWiki

2025-09-10T00:38:29Z

K95ma: f

CSC's MediaWiki instance is located at <code>/var/lib/mediawiki</code> on [[Machine List#caffeine|caffeine]].

MediaWiki

2025-09-10T00:37:57Z

K95ma: +

CSC's MediaWiki instance is located at {{code|/var/lib/mediawiki}} on [[Machine List#caffeine|caffeine]].