V5 → V7 Migration Analysis

[simongray]

The below text is an AI-generated summary of the current state of the migration to v7. It was given free reign to the server and the old dokuwiki page for clarin-dspace as input.

V5 → V7 Migration Analysis

Architecture change

Layer	V5	V7
Frontend	Java XMLUI (Cocoon/XSLT), served via Tomcat + AJP→Nginx	Angular (Node.js SSR), Docker container, proxied via Nginx
Backend	Monolithic DSpace 5.x WAR in Tomcat	Spring Boot REST API, Docker container
DB	PostgreSQL on host (dspace + dspace-utils databases)	PostgreSQL in Docker container, single dspace schema (CLARIN license tables merged in)
Search	Solr on host	Solr in Docker container
Config	local.properties + overlay build-time substitution	local.cfg volume-mounted into the backend container
Scheduler	Host cron calling make update_oai etc. in Makefile	Host cron calling docker exec dspace1 /dspace/bin/dspace <cmd>

---

Already working in V7

• Shibboleth/AAI login — nginx vhost, FastCGI sockets, ApplicationOverride in shibboleth2.xml, DiscoJuice JS (SHIBBOLETH.md documents all fixes applied)
• OAI-PMH with CMDI — endpoint live at /server/oai/request, cmdi prefix confirmed in ListMetadataFormats
• Handle prefix — 20.500.12115 set in local.cfg, port 2641 exposed from the backend container
• SMTP — smtprelay.adm.ku.dk configured in local.cfg
• CLARIN-specific modules — license management, bitstream authorization, citation, Matomo analytics (inherited from ufal/dspace-angular fork)
• Nginx bot-blocking, fail2ban, ModSecurity — still in place from v5 (on the host Nginx)

---

Still needs migration

1. Handle Server — not initialized (HIGH)

/data/dspace7/handle-server/ is empty. The handle server process needs to be initialized inside the container before the repository can mint or resolve handles under 20.500.12115.

Handle data is clean and ready for migration. A full audit of the v7 handle table was performed:

• 49 handles carry the correct 20.500.12115/... prefix: 1 community, 2 collections, and 46 items. This matches v5's 52 handles (the 3-handle gap is accounted for by items deleted in v5 that were correctly not migrated).
• 23 items carry the default 123456789/2-* prefix. These are test/intermediary items created during v7 setup — none of them appear in the v5 repository. They do not need correct handles and are harmless to the handle server migration.
• 47 orphaned handle rows (no linked resource) are dead weight but also harmless.

Migration steps:

1. Stop the v5 handle server (sudo systemctl stop handle-server)
2. Copy key material from /opt/clarindk-dspace/installation/handle-server/ into /data/dspace7/handle-server/ — at minimum admpriv.bin, the public key, and sitebndl.zip
3. Restart the dspace1 container — the ufal/dspace image starts the handle server automatically on startup when the directory is populated
4. Verify: echo "" | nc -w2 127.0.0.1 2641

The docker-compose.override.yml already mounts /data/dspace7/handle-server:/dspace/handle-server, so state will persist. Port 2641 (TCP+UDP) is already exposed at 127.0.0.1:2641.

Important: copy the v5 key material rather than generating a new keypair — the private key in admpriv.bin is what proves ownership of prefix 20.500.12115 to CNRI. Generating fresh keys would require re-registering with CNRI and waiting for the global registry to update.

Note on running both simultaneously: v5 and v7 handle servers both want port 2641 on the same host and cannot coexist. Stop v5 first, then start v7. There will be a brief window (seconds to a minute) where handle resolution fails externally — do this outside business hours.

2. Cron jobs — entirely missing for V7 (HIGH)

/etc/cron.d/dspace still runs all v5 tasks against /opt/clarindk-dspace. There are no v7 equivalents. The v7 commands are:

V5 task	V7 equivalent
make update_oai	docker exec dspace1 /dspace/bin/dspace oai import -c
make update_statistics	docker exec dspace1 /dspace/bin/dspace stat-general
make update_sitemap	Handled by internal Quartz scheduler (sitemap.cron in dspace.cfg), or run manually
make lift_embargos	docker exec dspace1 /dspace/bin/dspace embargo-lifter
make send_info (weekly report)	No direct equivalent in v7; was a CLARIN-specific Makefile target
PostgreSQL dumps	docker exec dspacedb1 pg_dump -U dspace dspace > /data/dspace7/db-dumps/dspace.$(date +%F).sql

The sitemap and solr-database-resync now have internal Quartz schedulers already enabled in dspace.cfg. OAI import, embargo lifting, and DB dumps still need host cron entries.

3. Backup scripts — point to v5 paths (HIGH)

Both /usr/local/sbin/dspace-aip-backup and /usr/local/sbin/rsnapshot-assetstore still reference:

• /opt/clarindk-dspace/installation/bin/dspace → should be docker exec dspace1 /dspace/bin/dspace
• /data/clarindk-dspace/assetstore/ → v7 assetstore is /data/dspace7/assetstore/
• No v7 backup directory under /data/backup/ exists yet

The PostgreSQL dump approach also changes: v7's DB is in the dspacedb1 container (accessible at 127.0.0.1:5431), not the host postgres.

4. SAML metadata registration for dspace.clarin.dk (MEDIUM)

The Shibboleth SP is registered in SPF-SPs-metadata with entityID https://repository.clarin.dk/shibboleth. The v7 site at dspace.clarin.dk uses an ApplicationOverride with the same entityID but a new ACS endpoint (defaultACSIndex="5").

That ACS index 5 must exist in the published SAML metadata. Confirm the metadata includes https://dspace.clarin.dk/Shibboleth.sso/SAML2/POST as an AssertionConsumerService. If not, submit a PR to add it — without it, the WAYF/CLARIN federation will not deliver assertions to the new URL.

5. OAI-PMH index updates not automated (MEDIUM)

The OAI-PMH endpoint is live and CMDI-capable, but the Solr-backed OAI index only updates when dspace oai import is run. Without a cron job (see item 2), new submissions will not appear in VLO harvests.

6. Log rotation for Docker containers (LOW)

V5 had logrotate configured for Nginx and Tomcat logs. V7 backend logs go to /data/dspace7/logs/ (bind mount). Those need a logrotate rule. Docker daemon log rotation should also be configured in /etc/docker/daemon.json.

7. robots.txt (LOW)

V5 had a custom robots.txt at the repository root. V7's Angular frontend serves its own default — verify it is adequate or add a custom one in the nginx vhost.

---

Items that do not need migration

• dspace-utils database — the CLARIN license tables (license_definition, license_resource_mapping, etc.) are now integrated into the main DSpace schema in v7. No separate DB needed.
• Tomcat, AJP connector — replaced by Docker + reverse proxy to Node.js.
• XMLUI overlays / messages_da.xml — v7 uses a completely different i18n approach (JSON5 files, documented in CLARIN-DK-CUSTOMIZATION.md).
• ROME/Atom RSS fix — v7's REST API handles feeds differently; the ROME patch was v5-specific.
• Cocoon/Sitemap errors — v5-specific, gone entirely in v7.
• ModSecurity, fail2ban, bot-blocking — already on the host Nginx, unchanged.
• SMTP config — done in local.cfg.

[simongray]

Re 4: I already took care of this by submitting new metadata to the third party that includes the new URI as an alternative path. We can (in principle) use both once the system has been fully migrated.

[simongray]

Re 1: the handle server is fully migrated as of 1ae73fc

[simongray]

Re 2 + 5: cron jobs are set up as of 4752b24

[simongray]

Re 3: backup scripts migrated as of 97efeae

[simongray]

Re 6: log rotation set up as of 2414271

[simongray]

All done as of 01041df