dc
4316f519c4
The integrity section claimed SAS writes nothing to disk outside the appLoc. The appLoc is the SAS Folder the stored processes or jobs are deployed into (metadata), so it is not a disk location at all - the only physical location the deployment programs write to is the Data Controller location (dcLoc) configured at first launch.
53 lines
3.1 KiB
Markdown
53 lines
3.1 KiB
Markdown
---
|
|
layout: article
|
|
title: DC Downloads
|
|
description: Data Controller release assets and how to verify them
|
|
---
|
|
|
|
# Downloads
|
|
|
|
Data Controller releases are published on the [releases page](https://git.datacontroller.io/dc/dc/releases) of the source repository. Every release carries the same set of assets:
|
|
|
|
| Asset | Use |
|
|
|---|---|
|
|
| `frontend.zip` | The pre-built web frontend, for deployments that serve the frontend from a web server (SAS 9 full deploy, Viya separated deploy) |
|
|
| `sas9.sas` | SAS 9 full deployment program (stored processes + frontend registration) |
|
|
| `demostream_sas9.sas` | SAS 9 streaming deployment program (demos and evaluations) |
|
|
| `viya.sas` | Viya streaming deployment program (backend + frontend) |
|
|
| `viya_noweb.sas` | Viya separated deployment program (backend only) |
|
|
| `viya_noweb.json` | The Viya backend services as a SASjs Drive JSON deployment bundle |
|
|
| `sasjs_server.json.zip` | SASjs Server deployment bundle (all services, for [SASjs Server](https://server.sasjs.io) deployments) |
|
|
| `SHA256SUMS` | SHA-256 checksums for every asset above |
|
|
|
|
Which asset you need depends on the deployment route - see [SAS 9 Deployment](/dci-deploysas9) or [SAS Viya Deployment](/deploy-viya).
|
|
|
|
## Verifying a download
|
|
|
|
Every asset is covered by the `SHA256SUMS` file, which the release pipeline generates over the exact files it uploads. To verify a download:
|
|
|
|
1. Download the asset (for example `frontend.zip`) from the [releases page](https://git.datacontroller.io/dc/dc/releases).
|
|
2. Download `SHA256SUMS` from the same release into the same folder.
|
|
3. Run the check:
|
|
|
|
```bash
|
|
sha256sum --check SHA256SUMS --ignore-missing
|
|
```
|
|
|
|
Each asset that matches reports `OK`. The `--ignore-missing` flag means you only need the files you actually downloaded - the check skips assets you did not fetch.
|
|
|
|
On Windows, `certutil` can compute the hash of a single file for comparison against the value listed in `SHA256SUMS`:
|
|
|
|
```
|
|
certutil -hashfile frontend.zip SHA256
|
|
```
|
|
|
|
### What the checksum proves
|
|
|
|
A matching checksum confirms the asset is byte-for-byte the file the release pipeline uploaded. It catches corrupted and tampered downloads - interrupted transfers, proxies or mirrors that altered the file in transit.
|
|
|
|
It is not a cryptographic signature. The hashes travel in the same release as the files they cover, so they protect the download path, not the release itself: a compromise of the forge would allow both the asset and its checksum to be altered together. For download integrity - the typical concern when fetching deployment artifacts over the internet - it is the standard check.
|
|
|
|
## Integrity inside SAS
|
|
|
|
The SAS deployment programs embed the frontend and services as generated SAS code. Once `%inc`'d, their integrity is established by the check above at download time. They deploy the stored processes or jobs into the SAS Folder you nominate (`appLoc`) - a metadata location, not physical disk - and the only physical location they write to is the Data Controller location (`dcLoc`) you configure. The programs can be [reviewed in full](https://code.datacontroller.io) (or in the [source repository](https://git.datacontroller.io/dc/dc)) before you run them.
|