CERN Web Redirector

A service for providing HTTP redirections from cern.ch/* (including cern.ch/go/*) and go.cern/*.

API Documentation

This service replaces the unmaintained WebRedirector written in C#.

Repository layout

• chart contains the Helm chart used for deploying the application
• app contains the source code for building various components of the application
• app/api/README.md contains the documentation for the API
• app/README.md contains instructions for application development and set up of the necessary environment

Architecture

Environments

We are currently deploying in 2 environments:

• qa environment: web-redirector-v2-qa.web.cern.ch
  • PaaS Project
  • Application registration with web-services-portal-admins as an admin group, registered as a "public" client.
  • DBOD instance
  • Database name (and username): web_redirector_v2_qa
• production environments:
  • separate deployments for cern.ch and go.cern
  • PaaS Project with openshift-admins as an admin group
  • Application registration for cern.ch with web-services-portal-admins as an admin group, registered as a "public" client
  • Application registration for go.cern with web-services-portal-admins as an admin group, registered as a "public" client
  • DBOD instance
  • Database names (and usernames): cern_ch, go_cern

For the production environment we need to annotate the project with paas.okd.cern.ch/block-reserved-hostnames: "false".

We need to allow token exchange permissions between the web redirector and the web services portal via the Application Portal. In the web redirector's application registration:

• Select SSO Registration and click on the lock icon.
• Grant token exchange permissions to web services portal (prod or dev depending on the case).

Each of the application registrations has two roles:

• default: mapped to all authenticated users, Minimum Level Of Assurance: EduGain with SIRTIFI
• admin-role: mapped to web-services-portal-admins and openshift-admins

The HELM_VALUES_FILE for each deployment is stored in GitLab CI/CD variables.

How to setup an environment from scratch

• Create a paas project: https://webservices-portal.web.cern.ch/paas. If it's an official project, set the category to Official and after creation add openshift-admins as Administrator group.
• Request a postgres instance from DBOD: https://resources.web.cern.ch/resources/Manage/DbOnDemand/Resources.aspx
• Store the admin password of the instance in a Gitlab CI variable called DBOD_ADMIN_PASSWORD (scoped to the relevant environment).
• Create a database, user and grant permissions: CREATE DATABASE <DB_NAME>;, CREATE USER <USER_NAME> WITH PASSWORD <PASSWORD>; (use pwgen 30 to generate an appropriate password), GRANT CONNECT, CREATE, TEMPORARY ON DATABASE <DB_NAME> TO <USER_NAME>;.
• Add the following line in the pg_hba.conf file of the DBOD instance: host <DB_NAME> <USER_NAME> 0.0.0.0/0 md5
• Create an Image Pull Secret following https://paas.docs.cern.ch/2._Deploy_Applications/Deploy_Docker_Image/1-deploy-private-docker/#generating-a-token-to-pull-images-from-gitlab-registry-gitlab-registrycernch.
• Create an OPENSHIFT_TOKEN and add it to GitLab CI vars:

# create a new service account:
oc create serviceaccount gitlab-ci-deployer
# assign appropriate permissions to the new service account:
oc policy add-role-to-user registry-editor -z gitlab-ci-deployer
oc policy add-role-to-user edit -z gitlab-ci-deployer

# extract the access token of the service account:
oc serviceaccounts get-token gitlab-ci-deployer

• Create a new application in the Application Portal and configure the corresponding SSO registration as a public client ("My application cannot store a client secret safely"). Create an additional role called admin-role and map it to the groups web-services-portal-admins and openshift-admins. Add the Application Identifier in the $HELM_VALUES_FILE as env.oidcAudience.

Reserved slugs

The reserved site names (slugs) were stored in the legacy database.

For the new CERN Web Redirector, we extracted the reserved slugs from the legacy database into a file and mounted them to the server application with a configmap.

In case a reserved site name needs to be added or removed, please update the reserved_slugs.txt file and re-deploy the application.

Current DNS / Loadbalancer setup

As of March 2023, we are using the following setup since we need a single IPv4/IPv6 IP for the cern.ch DNS record (so-called "Apex" records cannot use CNAMEs).

• www.cern.ch DNS record has been removed from IP Aliases of webrlb02.cern.ch.
• www.cern.ch DNS record has been added in IP Aliases of drupal8lb01.
• IP addresses for cern.ch point to 188.184.37.219 / 2001:1458:201:b0::100:1b (= drupal8lb01). Related ticket: RQF2264975.

Note that this also means that the IP addresses seen (and logged) by the web redirector server are not the real client IPs, but only the IPs of the Drupal loadbalancers. If necessary, the real IP can be found in their HTTP access logs.

Custom alerts

We are deploying custom alerts as part of the Helm chart following https://paas.docs.cern.ch/7._Monitoring/1-metrics/#defining-custom-alerts.

In order to deploy the alerts, we need to set monitoring.enabled: true in values.yaml.

New releases

We manage new releases by creating a new tag from a specific commit SHA. The new tag can be created:

• either through the GitLab Interface
• or using git

git tag -a deploy-2023-04-04 5a14f36 -m "Deployment 2023-04-04"
git push --tags origin master

After the creation of the tag, the tagged image is being built and the deployments to production can be manually triggered.

Note that when merging to master, we automatically deploy to the QA instance.