| Development | http://staging.app4.admin.cam.ac.uk/uc/ | `rich.internal.admin.cam.ac.uk` |
All VMs are maintained by infra-sas and also host additional applications. SSH access to the VMs
can be gained by [emailing infra-sas](mailto:uisinfrastructureserversandstorage@uis.cam.ac.uk).
All applications are run by the `httpd` user, which can be `su`'d to within each VM, the password
for this user is held in the Devops 1Password instance.
## Database environments
The Legacy Card System holds a large amount of its logic within stored procedures and functions
contained within the Oracle database. The following Oracle databases exist which serve the
Legacy Card System:
| Name | Serves environment | DB Name |
| ----------- | ------------------- | -------- |
| Production | Production, Staging | CARD |
| Dev | Development | CARD_T |
Credentials for accessing both databases can be found within the Devops team's 1Password instance.
The database servers are maintained by the [DBA Team](mailto:uisdba@admin.cam.ac.uk) and are
accessible through the OCM.
## Source code
The source code for the Legacy Card System is spread over the following repositories:
| Repository | Description
| ----------- | ------------------ |
| [Webapp Server](https://gitlab.developers.cam.ac.uk/uis/devops/iam/card-database/card-system) | The source code for the 'uc' application server |
| [Webservices](https://gitlab.developers.cam.ac.uk/uis/devops/iam/card-database/legacy-card-webservices) | The source code for the card 'webservices' providing ad-hoc HTTP endpoints |
!!! danger
Both these repositories contain secrets and passwords which are used by production instances
of the service, access to them should not be granted to anyone outside UIS.
## Technologies used
The following gives an overview of the Legacy Card System is built on.
| Category | Language | Framework(s) |
| -------- | -------- | --------- |
| Client | JavaScript | Some JQuery |
| Server | Perl | [DBI](https://metacpan.org/pod/DBI) for database access |
| Database | Oracle 19c | N/A |
## Operational documentation
The following gives an overview of how the Legacy Card System is deployed and maintained.
!!! danger
Deployments to the Legacy Card System are manual and uncontrolled, therefore a deployment
should only be made where absolutely necessary, i.e. a high priority bug fix.
### How and where the Legacy Card System is deployed
The process which has been followed to make a change to **application (Perl)** code is:
* Apply the change to the development environment (`rich.internal.admin.cam.ac.uk`)
* Test that the change works as expected
* Copy the changes made into [source control](https://gitlab.developers.cam.ac.uk/uis/devops/iam/card-database/card-system/)
* Raise a merge request containing the change and ensure the change is reviewed and merged
* Copy the change on the live system (`sanders.internal.admin.cam.ac.uk`)
* Smoke test the change on live
Previously a script has been run to sync the live system from the development system
([as documented here](https://confluence.uis.cam.ac.uk/display/UC/Releasing+to+Live)). But the
code deployed to the development system has drifted from what exists in live, and so instead
the approach of cherry-picking changes between source control and the dev and live system has
been used.
The process which has been followed to make a change to **stored proceedures** code is:
*[Install and configure SQL Developer](https://www.oracle.com/uk/database/technologies/appdev/sqldeveloper-landing.html)
* On modern Macs there seems to be no way around doing this
* On Linux it's possible that [the approach documented here may work](https://medium.com/@webchad/run-oracles-sql-developer-with-docker-on-mac-d092c4b9ea78)
* Connect to the `CARD_T` database, make the required change and test
* Copy the changes made into [source control](https://gitlab.developers.cam.ac.uk/uis/devops/iam/card-database/card-system/)
* Raise a merge request containing the change and ensure the change is reviewed and merged
* Connect to the `CARD` database and apply the same change
* Smoke test the change on live
This broadly follows the approach [documented here](https://confluence.uis.cam.ac.uk/display/UC/Releasing+PLSQL+to+live),
except we keep
[the card system repository](https://gitlab.developers.cam.ac.uk/uis/devops/iam/card-database/card-system/)
as the source of truth for changes to stored procedures / database functions.
### Monitoring
!!! danger
There is no automated monitoring or alerting of the Legacy Card System. Where problems have
occurred previously, the development team has been alerted by card office or card representative
staff.
Logs from the application (Perl) scripts can be found within `ACTIVITYLOG`, `ERRORLOG` and `DEBUGLOG`
in `/home/httpd/html/uc`. Logs from database processes are scp'd nightly from the database
server and can be found in `/tmp/card_process_logs/process_logs`.
### Debugging
The Legacy Card System cannot be run locally, and therefore the development instance should be
used to trial changes and fixes. The logs detailed under `Monitoring` are the best way to diagnose
problems with the system.
### Feeds of data into the Legacy Card System
The list of feeds of data into and out of the card system
