Common 2nd line support tasks for data.gov.uk and CKAN

Last updated: 22 Apr 2024

🚧 This doc is being updated to reflect that CKAN now runs in Kubernetes.

In the meantime, if you’re unable to figure out one of yet-to-be-updated parts, #govuk-platform-engineering will be able to help you.

This document covers some of the requests that GOV.UK Technical 2nd Line support may receive regarding data.gov.uk and CKAN (which is the publishing application behind data.gov.uk).

Separate documentation exists for publishers.

There’s also an architectural overview of data.gov.uk and a deployment guide.

ckanext-datagovuk is the primary CKAN extension behind data.gov.uk.

If you find an issue with CKAN that you believe may be a potential security vulnerability please contact security@ckan.org rather than disclosing the information publicly (as per their security policy).

If you find an issue that does not appear to be a security vulnerability you should first search the issues of the upstream CKAN repository to see if it has already been reported and if there’s a workaround. If there is not an issue, considering opening a new one or - if you know how to fix it - open a PR to resolve the problem.

Environments

There are three environments for CKAN:

Accessing data.gov.uk

Datagovuk kubernetes cluster

Publish and Find are hosted on the same AWS cluster as GOV.UK but in its own namespace - datagovuk

So to manage data.gov.uk apps you will need to add -n datagovuk to any kubectl command or run kubectl config set-context --current --namespace=datagovuk to make it the default.

You will be able to exec onto any datagovuk pod in a similar way to other GOV.UK apps.

Reindexing Find

This is done using the search:reindex rake task in Publish and will not cause any app downtime.

kubectl exec deploy/datagovuk-publish -n datagovuk -- rails 'search:reindex[500]'

This will populate a new index and rotate the index alias to point to it when it’s ready.

Perform a full re-sync from [CKAN]

The sync is normally done automatically using Sidekiq Scheduler. There may be times when you need to throw away the existing Postgres database, sync all datasets from CKAN and reindex.

This will not make any changes to the content on Find until the reindex has completed and the Elastic index is updated. This will affect data served on Publish, however this service is not currently used for publishing or editing datasets. In most cases, you should never need to do this as the sync performs incremental updates.

## drop tables in publish database so that the db setup can run
kubectl exec deploy/datagovuk-publish -n datagovuk -- bash -c 'psql $DATABASE_URL -c "DROP OWNED BY ckan;"'

# NOTE - ignore the server restart warnings after setting up the database
kubectl exec deploy/datagovuk-publish -n datagovuk -- bin/setup

## make sure the index is setup

kubectl exec deploy/datagovuk-publish -n datagovuk -- rails search:reindex

## update orgs or datasets

kubectl exec deploy/datagovuk-publish -n datagovuk -- rails runner CKAN::V26::CKANOrgSyncWorker.new.perform
kubectl exec deploy/datagovuk-publish -n datagovuk -- rails runner CKAN::V26::PackageSyncWorker.new.perform

Now run kubectl exec deploy/datagovuk-publish -n datagovuk -- bundle exec sidekiq and see the logs.

Monitoring data.gov.uk

Pingdom

Pingdom monitors https://data.gov.uk uptime and alerts PagerDuty when downtime is detected.

Sentry

Sentry monitors application errors. The Sentry pages for each app can be found on the Find and Publish app pages.

Logs

Ckan, Publish and Find send their logs to Logit. Example query: kubernetes.namespace: datagovuk AND kubernetes.container.name: find AND message: "status=404".

CDN logs for data.gov.uk are also available.

Grafana

There is a Grafana dashboard showing some metrics for datagovuk apps.

Sidekiq (Publish)

You can monitor the number of jobs in each queue using the following.

kubectl exec -it deploy/datagovuk-publish -n datagovuk -- bash
rails console
>>> Sidekiq::Queue.new.each_with_object(Hash.new(0)) {|j, h| h[j.klass] += 1 }

or on a single command line:

echo 'Sidekiq::Queue.all.map(&:size)' | k -n datagovuk exec -i deploy/datagovuk-publish -- rails c

If there are issues processing the Sidekiq queue you can also clear it (this doesn’t affect the operation of data.gov.uk):

echo 'Sidekiq::Queue.new("import").clear' | k -n datagovuk exec -i deploy/datagovuk-publish -- rails c

Analytics

Traffic for data.gov.uk is recorded using Google Analytics, in specific properties.

If a user requests analytics for data.gov.uk, we can provide them with access to an analytics dashboard. Assign tickets like this to the 3rd Line--GOV.UK Product Requests Zendesk queue.

Updating the Zendesk password for Find

The form at https://www.data.gov.uk/support uses the Zendesk API to create new tickets. If the account password expires, it’ll need updating in AWS Secrets Manager:

Get the existing govuk/dgu/datagovuk credentials from AWS Secrets Manager
Log into Zendesk using the username and password obtained from the previous step
Reset the password through the UI and copy the password to your clipboard
Update the password in AWS Secrets Manager.

Logging into the publisher

You can log into CKAN using a shared account. The credentials are available in Secrets Manager under 2ndline/datagovuk/ckan.

For commands not available via the user interface you need to kubectl exec into a CKAN pod.

Users and publishing organisations

Publishers login using their email address. A user can be a member of one or more publishing organisations, with either the ‘Admin’ or ‘Editor’ role for each organisation.

‘Admin’ users can add/remove users from their own organisation.

A ‘sysadmin’ has admin rights across all organisations.

Finding a user

When logged in as a sysadmin you can access a user list. This is useful where a user does not know their username or no longer has access to their registered email account - it is searchable by email address even though that’s not obvious.

Creating a user account

There are two methods to create a new user account:

An organisation’s ‘admin’ user can follow these instructions to invite new users to create an account. This is the preferred approach, as the organisation admin is best placed to know whether the new user should be given access.
A ‘sysadmin’ user (e.g. Technical 2nd Line) can create an account for the new user. This should only be done if the organisation has no admins, and if we can verify the authenticity of the request.
- Follow the instructions to assign users to publishers inputting the user’s email address instead of their username.
- An invite email is generated and sent to the user.

Updating a user’s email address

If a user has changed their email address (and so cannot log in) you can update the email address associated with their account:

Login to CKAN as a ‘sysadmin’ user (see above for credentials).
Search the user list for their old email address
Click the user name
Click the ‘Manage’ button.
Change the email address.
Set a temporary new password for the user (put that in the ‘Confirm password’ field too). This is required by CKAN, but you won’t use that password.
Enter your own CKAN password in the ‘Sysadmin password’ field.
Click ‘Update profile’.
Reply to the user to tell them that their email address has been changed, and that they will need to reset their password via https://ckan.publishing.service.gov.uk/user/reset

Email addresses in CKAN are case-sensitive, and this can cause problems.

For example, if a user enters a lowercase email address into the reset password form, but their stored email address is mixed case, they won’t receive the email. If this happens, tell them how it is stored and ask them to enter it with exactly the same case.

Updating a user account name

Historical usernames with non-alphanumeric or uppercase characters are no longer valid, and so users cannot log in to change their password. Usernames can only be changed directly in the database:

Follow the instructions to access the CKAN database.
Enter the following to find the user in the database SELECT * from "user" where name = 'old-username' limit 1;.
Update the username UPDATE "user" SET name = 'new-username' WHERE name = 'old-username';
Check they were updated by repeating step 2.
Reply to the user to tell them that their username has been changed and what it’s been changed to.

Creating a new publishing organisation

Login to CKAN as a ‘sysadmin’ user (see above for credentials).
Click the ‘Publishers’ button.
Click ‘Add Publisher’ and complete the form.
Follow the instructions in the section below to add a user as an ‘admin’ for the organisation (this would normally be the person making the request, so they can then add further users themselves without needing to contact support).

Assigning users to publishers (setting user permissions)

Login to CKAN as a ‘sysadmin’ user (see above for credentials).
Click the ‘Publishers’ button.
Find the user’s organisation and click on it.
Click the ‘Manage’ button.
Click the ‘Members’ tab, then the ‘Add Member’ button.
Add the user’s existing account, or enter their email address to send them an invite, ensuring you select the relevant role for the user (either admin or editor).

Users should first be asked to request addition by an admin of their organisation, if possible. This is to reduce the burden of these requests on the 2nd line team and to ensure only those with the correct authority are added as publishers.

Check the authenticity of a request before adding a user as a publisher (i.e. make sure they actually belong to the department they want to publish for, bearing in mind that some parent organisations may publish on behalf of child organisations, e.g. BEIS can publish for the Civil Nuclear Police Authority).

Datasets

Viewing a log of dataset activity

A log of publisher activity on a dataset is available by inserting /activity into the dataset’s URL, such as https://ckan.publishing.service.gov.uk/dataset/activity/monthly_statistics_of_building_materials_and_components.

Deleting (or withdrawing) a dataset

Users are not permitted to remove their own datasets. There are a limited number of circumstances in which a dataset will be withdrawn. This is to be done by Technical 2nd Line, following a request from the publisher.

Datasets are never hard-deleted (known as “purged” in CKAN), instead they are given the state “deleted” (a soft-deletion), which removes them from the public-facing site but allows them to be viewed through the CKAN publishing interface. Soft-deleted datasets can be undeleted.

Before making any deletions, check that the person making the request actually belongs to the organisation which owns the document (or are from a superseding department, e.g. someone from BEIS could request withdrawal of a dataset published by BIS).

Deleting a dataset

Login to CKAN as a ‘sysadmin’ user (see above for credentials).
Navigate to the relevant dataset (use the ‘Datasets’ button).
Click the ‘Manage’ button.
Click the red ‘Delete’ button.
Once withdrawn, it will take up to 30 minutes to sync across to data.gov.uk and clear the cache.

The ‘Delete’ button is not available for draft datasets. To soft-delete a draft dataset, follow the above steps, but manually change /edit/ to /delete/ in the URL of the ‘Manage’ page for the dataset.

You can bulk soft-delete datasets using these instructions.

A dataset is wrong in some way

Responsibility for individual datasets lies with the publishing organisation. Unless it’s clearly a data.gov.uk problem (eg a dataset page is returning an error response when it shouldn’t be), users reporting a problem with a dataset should be directed to the publisher.

This is a generic response for such cases:

Thanks for getting in touch.

Individual datasets are the responsibility of the publishing organisation, rather than the data.gov.uk team. This means that you’ll need to get in touch with the publishing organisation directly to request any changes to the dataset.

Contact details for each dataset are towards the bottom of the dataset page.

I hope that helps. I’ll close this ticket now.

Different number of datasets in CKAN to data.gov.uk

Determine the number of datasets in CKAN using the API:

https://data.gov.uk/api/3/search/dataset

Determine the number of datasets in the Publish Postgres database using the Rails console.

kubectl exec -it deploy/datagovuk-publish -n datagovuk -- bash
rails console
>>> Dataset.count

If these numbers match, but the number of datasets served on data.gov.uk is still different, identify the number of published datasets in the Postgres database:

kubectl exec -it deploy/datagovuk-publish -n datagovuk -- bash
rails console
>>> Dataset.published.count

All datasets that are available through the CKAN API will be marked as public in the Postgres database. Therefore, if you get a different number of datasets, you should mark them all as published in the Postgres database.

kubectl exec -it deploy/datagovuk-publish -n datagovuk -- bash
rails console
>>> Dataset.update(status: 'published')

A reindex is then needed to update the status with the Elastic instance that serves data.gov.uk.

Datasets published in CKAN are not appearing on data.gov.uk

Check the Sidekiq queue (see monitoring section) to ensure the queue length is not too long. You should not see more jobs than the number of datasets in CKAN.

If the queue is too long, you should clear the queue. The next sync process will repopulate the queue with any relevant datasets that require updating.

Accessing withdrawn content

If a user is asking for data that is no longer publicly available, e.g. a withdrawn dataset, they should email the organisation that originally published the dataset. You can find an email address for the organisation on CKAN.

Using the CKAN api

It can be useful to access the CKAN API when debugging or resolving issues. Note that the responses may be different depending on your access permissions.

Where relevant, the number of results returned defaults to 10. Use a rows parameter to change this:

https://data.gov.uk/api/action/package_search?fq=organization%3Acabinet-office&rows=200

Queries can use the package ID or name (the slug):

https://data.gov.uk/api/3/action/package_search?q=id:1e465255-7c45-4860-bf4b-991c151d4ce7
returns the same as
https://data.gov.uk/api/3/action/package_search?q=name:population-of-england-and-wales-by-ethnicity

There’s some API documentation aimed at general users of data.gov.uk. Here are some more complex examples of using the API:

# Retrieve full details about a package (dataset)
 https://data.gov.uk/api/3/action/package_search?q=name:population-of-england-and-wales-by-ethnicity

# Find all packages created during a specific timeframe
 https://data.gov.uk/api/3/action/package_search?q=metadata_created:[2021-06-01T00:00:00Z%20TO%202021-06-30T00:00:00Z]

# Find all packages modified during a specific timeframe
 https://data.gov.uk/api/3/action/package_search?q=metadata_modified:[2021-06-01T00:00:00Z%20TO%202021-06-30T00:00:00Z]

# Count all packages and list a sample
 https://data.gov.uk/api/3/search/dataset?fl=id,dataset_type,name,title,extras_guid,extras_harvest_source_title,extras_harvest_object_id&q=state:active%20and%20dataset_type:dataset

# Count harvested packages and list a sample
 https://data.gov.uk/api/3/search/dataset?fl=id,state,dataset_type,name,title,extras_guid,extras_harvest_source_title,extras_harvest_object_id&q=state:active%20and%20extras_harvest_object_id:[""%20TO%20*]%20and%20dataset_type:dataset

# Count manually published packages and list a sample
 https://data.gov.uk/api/3/search/dataset?fl=id,dataset_type,name,title,extras_guid,extras_harvest_source_title,extras_harvest_object_id&q=state:active%20and%20-extras_harvest_object_id:*%20and%20dataset_type:dataset

# Count packages harvested in last 7 days and list a sample
 https://ckan.publishing.service.gov.uk/api/search/dataset?fl=id,state,dataset_type,name,title,extras_guid,extras_harvest_source_title,extras_harvest_object_id&q=state:active%20and%20extras_harvest_object_id:[%22%22%20TO%20*]%20and%20dataset_type:dataset%20and%20metadata_modified:[NOW-7DAY/DAY%20TO%20NOW]&limit=20

# Count packages manually published in the last 7 days and list a sample
 https://data.gov.uk/api/3/search/dataset?fl=id,dataset_type,name,title,extras_guid,extras_harvest_source_title,extras_harvest_object_id&q=state:active%20and%20-extras_harvest_object_id:*%20and%20dataset_type:dataset%20and%20metadata_modified:[NOW-7DAY/DAY%20TO%20NOW]

# Count packages from Daily harvest sources and list a sample
 https://data.gov.uk/api/3/search/dataset?fl=id,metadata_modified,dataset_type,name,title,extras_guid,extras_harvest_source_title,extras_harvest_object_id,extras_frequency-of-update&q=state:active%20and%20extras_harvest_object_id:%5B%22%22%20TO%20*%5D%20and%20frequency-of-update:daily%20and%20dataset_type:dataset

# List all publishers
 https://data.gov.uk/api/3/action/organization_list

# View a publisher record
 https://data.gov.uk/api/3/action/organization_show?id=government-digital-service

# List datasets from a specific publisher
 https://data.gov.uk/api/3/action/package_search?q=organization:hull-city-council

Organogram publishing

Organograms are files that visualise the people structure of an organisation. They’re split into two files: one for senior staff (grades SCS1, SCS2 and SCS3, or equivalent) and another for junior staff (all other grades). The senior staff file is more detailed than the junior staff file, with staff names included for posts classified as grades SCS2 and SCS3.

Organograms are the only datasets on data.gov.uk where we host the data itself, rather than linking to an external resource.

The data files are hosted in a S3 bucket (named datagovuk-integration-ckan-organogram, datagovuk-staging-ckan-organogram or datagovuk-production-ckan-organogram, depending on the environment).

There’s guidance for users on publishing organograms.

XLS to CSV Conversion

Publishers upload their organograms as an Excel (XLS) file that contains macros. A script converts these to the two CSV files (junior staff and senior staff).

Publishers must select the correct ‘Schema Vocabulary’ for their organogram dataset (i.e. one of the two ‘organisation structure’ values) in order for the upload option to become available and for the conversion script to run.

Connecting to CKAN via kubectl exec

For commands not available via the user interface you must exec onto a CKAN pod:

kubectl exec -it deploy/ckan-ckan -n datagovuk -- bash

Most of the commands to interact with CKAN use the ckan CLI.

Once connected to the ckan pod, the commands can be run using the ckan CLI, a list of them can be discovered:

ckan [COMMAND]

If you need to view the CKAN configuration it is located at /config/production.ini which has been set to the CKAN_INI environment variable.

Initialising the database

There may be times when you need to start with an empty database (e.g. on integration). The following commands will create the relevant schema for core CKAN and the harvesting extension on integration.

ckan db init
ckan harvester initdb

Accessing the database

To open a PostgreSQL console to run queries on the CKAN database from a CKAN pod:

psql $CKAN_SQLALCHEMY_URL

Creating a system administrator account

ckan sysadmin add USERNAME email=EMAIL_ADDRESS

You’ll be prompted twice for a password.

Removing a system administrator account

ckan sysadmin remove USERNAME

Listing users

ckan user list

Viewing a user

ckan user show USERNAME

Adding a user

ckan user add USERNAME email=EMAIL_ADDRESS

Removing a user

ckan user remove USERNAME

Changing a user’s password

ckan user setpass USERNAME

Changing a publisher (organisation) name

Change the name in the CKAN UI then reindex that publisher:

ckan search-index rebuild [PUBLISHER]

Purging a dataset

Where commands mention DATASET_NAME, this should either be the slug for the dataset, or the UUID.

ckan dataset purge DATASET_NAME

Bulk deleting datasets

This needs to be done on the CKAN machine, since [the deletion API is protected from external access][ckan-api-404]. Your API key is required, which can be obtained from your user profile in the CKAN web interface. You might need to change the limit to the number of datasets that can be deleted - otherwise the deletion may appear to work in CKAN but the changes won’t make it through to data.gov.uk and subsequent publish jobs could be blocked.

Put a list of dataset slugs or GUIDs in a text file, with one dataset per line, then run the following:

while read p; do curl --request POST --data "{\"id\": \"$p\"}" --header "Authorization: <your_api_key>" http://localhost:<ckan_port>/api/3/action/package_delete; done < list_of_ids.txt

After deleting or purging a dataset, it will take up to 10 minutes to update on data.gov.uk, due to the sync process.

Exporting a list of datasets to CSV

You can get a list all datasets (including those which have been soft-deleted) for an organisation by exporting a CSV from the database.

Find the id of the organisation you want via an API call, eg:

https://data.gov.uk/api/3/action/organization_show?id=environment-agency

Follow the instructions to access the database
This query will list all datasets for the Environment Agency, with the number of records for each, and export the result to a CSV file.

\pset format csv

SELECT package.name, package.title, package.url, package.state, COUNT(resource.package_id) as num_resources FROM package LEFT JOIN resource ON (resource.package_id = package.id) WHERE package.owner_org='11c51f05-a8bf-4f58-9b95-7ab55f9546d7' GROUP BY package.id)

You can then use scp-pull from the govuk-connect tool to download the file.

Rebuilding the search index

CKAN uses Solr for its search index, and occasionally you may need to refresh the index, or rebuild it from scratch.

Refresh the entire search index (this adds/removes datasets, but does not clear the index first):

ckan search-index rebuild -r

Rebuild the entire search index (this deletes the index before re-indexing begins):

ckan search-index rebuild

Rebuilding the entire search index immediately removes all records from the search before re-indexing begins. No datasets will be served from the package_search API endpoint until the re-index has completed. This command should therefore only be used as a last resort since it will cause the sync process to assume there is no data for a period of time.

Only reindex those packages that are not currently indexed:

ckan search-index -o rebuild

Harvesting

Harvesting is where data is automatically imported to data.gov.uk without a publisher having to manually enter it via the web interface. This can be set to run automatically at specified periods, or run manually on-demand.

Although harvesters can mostly be managed from the user interface, it can be easier to perform these tasks from the command line.

Listing current harvest jobs

This returns a list of currently running jobs, including the JOB_ID needed to cancel jobs.

ckan harvester jobs

It may be faster to run a SQL query to get the ID of a specific harvest job. You can do this by running the command from Accessing the database and passing a -c argument:

<psql_ckan_production_command> -c "SELECT id FROM harvest_source WHERE name = '[NAME]'"

Finding the harvest source of a dataset

The harvest source of a dataset can be found using the CKAN API, using the dataset’s slug:

https://ckan.publishing.service.gov.uk/api/3/action/package_show?id=<slug>

In the response there should be harvest_source_id and harvest_source_title fields.

Getting the status of a harvester

Login to CKAN as a ‘sysadmin’ user (see above for credentials).
Click the ‘Harvest’ button and find the relevant harvester.
You will see a list of the datasets imported by this harvest source.
Click the ‘Admin’ button to get the status.
A summary of the current status will be shown. Individual runs (and any error messages) can be accessed from the ‘Jobs’ tab.

Restart a harvest job

Follow the steps to get the status of a harvester.
If the harvester is currently running, click the ‘Stop’ button. Once it’s stopped, or if it’s not currently running, click the ‘Reharvest’ button. You’ll know if the harvester is running because the ‘Reharvest’ button will be disabled.

If the harvest job is hanging and the ‘Stop’ button is not responding, you’ll have to log on to the ckan machine to restart it:

Exec into the ckan pod as above
Run the harvest job manually - ckan harvester run-test <harvest source>
- where harvest source is from the url of the harvest source page, e.g. defra-metadata-catalogue-harvest

Cancelling a harvest job

Follow the steps to get the status of a harvester.
Click the ‘Stop’ button to stop it.

Sometimes a harvest job can get stuck and not complete, and can’t be cancelled through the UI. You can get the JOB_ID from the harvest dashboard under “Last Harvest Job” (or from Listing current harvest jobs).

Cancel the job by running:

ckan harvester job-abort JOB_ID

This can also be done by running SQL:

<psql_ckan_production_command> -c "UPDATE harvest_job SET finished = NOW(), status = 'Finished' WHERE source_id = '[UUID]' AND NOT status = 'Finished';"

Purging all currently queued tasks

If there’s a schedule clash and the system is too busy, it may be necessary to purge the queues used in the various stages of harvesting.

WARNING

This command will empty the Redis queues

ckan harvester purge-queues

Restarting the harvest service

The harvesting process runs as single pod. If the harvesting process crashes, the pod will terminate and a new pod should automatically be started. If the pod continues to crash you will probably need to look at the pod to investigate what is going on, it could be something like it is using an incorrect image or not connecting to the solr service.

$ kubectl describe pod deploy/ckan-ckan -n datagovuk

You can also check whether the process is still running by checking the logs on the ckan-gather and ckan-fetch pods:

$ kubectl logs deploy/ckan-gather -n datagovuk
$ kubectl logs deploy/ckan-fetch -n datagovuk

Or you can check that the pods are all showing as running:

$ kubectl get pods -n datagovuk | grep -E "ckan-gather|ckan-fetch"

If any of the pods are not showing as Running, you may need to investigate why they are not Running. It is best to use the kubectl describe command to give you an idea as to the cause of the error:

$ kubectl describe pod deploy/ckan-gather -n datagovuk"

This will give you some information on the health of the pod, one reason for a pod to fail is because it is not picking up the latest image in which case you can check that the relevant image has been pushed up by visiting these pages:

CKAN - https://github.com/alphagov/ckanext-datagovuk/pkgs/container/ckan PYCSW - https://github.com/alphagov/ckanext-datagovuk/pkgs/container/pycsw Solr - https://github.com/alphagov/ckanext-datagovuk/pkgs/container/solr

‘Gather’ jobs retrieve the identifiers of the updated datasets and create jobs in the fetch queue. To restart a failing pod just delete it:

$ kubectl delete pod deploy/ckan-gather -n datagovuk

‘Fetch’ jobs retrieve the datasets from the remote source and perform the relevant updates in CKAN. To restart a failing pod just delete it:

$ kubectl delete pod deploy/ckan-fetch -n datagovuk

Managing cronjob pods

There are a number of cronjob pods which run periodically, you can give the list of cronjob pods using this command:

$ kubectl get cronjobs -n datagovuk

Sometimes they will get into a state where they are hanging. If this happens check their health by running a kubectl describe:

$ kubectl describe cronjob/ckan-harvester-run -n datagovuk

When running a kubectl get pods -n datagovuk command to view all running pods you will be able to see all completed and running pods. If there are a number of running cronjob pods they might be hanging due to things like a failure to pull the image. In this case you should delete the cronjob so that it gets redeployed rather than remove the pod as this will simply recreate the pod and not clear up the hanging pods.

$ kubectl delete cronjob ckan-harvester-run -n datagovuk

The `csw` endpoint

The csw endpoint is available at https://data.gov.uk/csw which redirects to https://ckan.publishing.service.gov.uk/csw.

`csw` endpoint unavailable

If it is not showing xml with an error Missing keyword: service you can check that the pycsw pod is running:

$ kubectl get pods -n datagovuk | grep pycsw

If no running pods are found then you can start investigating why by running this command:

$ kubectl describe deploy/ckan-pycsw -n datagovuk

Delete the pycsw pod if it is not clear why it is failing as this can sometimes help it restart successfully.

It is worth checking the pycsw logs to investigate why it failed:

$ kubectl logs deploy/ckan-pycsw -n datagovuk

You can get a summary of csw records available from this url https://ckan.publishing.service.gov.uk/csw?service=CSW&version=2.0.2&request=GetRecords&typenames=csw:Record&elementsetname=brief

Syncing the `csw` records with `ckan` datasets

Normally the sync between csw and ckan will start at 6am each day, but in case it should fail or if the sync needs to happen sooner you can manually trigger the sync after Solr has been reindexed.

$ ckan ckan-pycsw load -p /config/pycsw.cfg -u http://ckan-ckan:5000

Map previews

Map previews on data.gov.uk have been deprecated. Map preview links are no longer available and existing map preview pages will have a note about them being deprecated.

The Ordnance Survey API that sat behind this service was turned off. We also conducted an audit of the use of map previews, which showed that less than 1% of requests were to map preview datasets and of the 6% of map preview datasets available on DGU, only 2% were working as expected.

Register a brownfield dataset

See the supporting manual.

CKAN on Staging environment responds with Nginx 504 timeout:

CKAN on the Staging environment can sometime respond with a 504 error, due to it timing out when connecting to the database as there are too many connections. The current limit is 1000, usually the number of connections should be under 100.

SELECT rolname, rolconnlimit FROM pg_roles WHERE rolname='ckan';

Changing the connection limit

The connection limit can be updated, but should not exceed the hard limit of around 3000.

ALTER USER ckan WITH CONNECTION LIMIT 1001;

Trying to log on to the database will result in this error:

FATAL:  too many connections for role "ckan"

View the number of connections and types of queries:

SELECT COUNT(*) FROM pg_stat_activity WHERE datname = 'ckan_production';

In the past, during an overnight sync one of the queries has been found to cause a large number of db connections. This captures part of that query and uses it to target the pid:

SELECT pid FROM pg_stat_activity WHERE datname = 'ckan_production' and query LIKE 'SELECT "user".password AS user_password%';

Cancelling these queries

SELECT pg_cancel_backend(pid)
FROM pg_stat_activity
WHERE pid IN
(SELECT pid
FROM pg_stat_activity
WHERE datname = 'ckan_production' and query LIKE 'SELECT "user".password AS user_password%');

Identifying long running queries

SELECT
pid,
now() - pg_stat_activity.query_start AS duration,
query,
state
FROM pg_stat_activity
WHERE
(now() - pg_stat_activity.query_start) > interval '5 minutes' AND
datname = 'ckan_production';

Cancelling long running queries

This will take a few seconds to be processed

SELECT pg_cancel_backend(pid)
FROM pg_stat_activity
WHERE
(now() - pg_stat_activity.query_start) > interval '5 minutes' AND
state = 'active' AND
datname = 'ckan_production';

If cancelling does not work you can terminate the query. This must be used with caution as it may cause the database to restart to recover consistency.

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE
(now() - pg_stat_activity.query_start) > interval '5 minutes' AND
state = 'active' AND
datname = 'ckan_production';