dc
fdb39a78a5
Adds /downloads to the Installation section, listing what each release asset is for and how to verify a download against the SHA256SUMS file the release pipeline publishes (sha256sum -c, plus certutil for Windows). The SAS 9 deployment page now links to it wherever it sends the reader to the releases page. mkdocs build passes; nav, sitemap and cross-links verified in the rendered output.
53 lines
3.0 KiB
Markdown
53 lines
3.0 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; SAS also writes nothing to disk outside the `appLoc` you point it at, and 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.
|