sandhose
commented
1 year ago The documentation and distribution is definitely lacking. Although it is already in my todo-list to make that better in the next few weeks, contributions on that front is definitely appreciated! Feel free to ask on #matrix-auth:matrix.org if something needs to be clarified.
At some point, we were embedding all the assets in the binary, which did not scale well.
For the record, for ~production, I'm currently relying on the nightly docker images. The Docker image is a good source to know what's needed to run it, outside of the binary itself:
/usr/local/share/mas-cli/assets/has the built frontend assets/usr/local/share/mas-cli/manifest.jsonis the Vite manifest generated for the frontend/usr/local/share/mas-cli/templates/has thetemplates/folder copied as-is/usr/local/share/mas-cli/policy.wasmhas the OPA policy compiled to WASM
I'm definitely down to publish full archives with both the binary and all the assets.
About publishing versions, I'm not sure when the service will be stable enough to cut a clear version with proper changelogs between versions.
A few questions we would need to answer:
- which platform+arch are we distributing binaries for? Synapse currently does Linux and macOS, on x86_64, i686 and arm64. I think would skip i686.
- on Linux, do we build for
glibc({aarch64,x86_64}-unknown-linux-gnu) based binaries, or do we build fully-static binaries based onmusl({aarch64,x86_64}-unknown-linux-musl)? Note that in the Docker image we're usingmuslbinaries. - should we rely on system certificates for root CAs or embed them from webpki in the binary?
- should we also provide deb/rpm? It looks like it would not be that much more work if we leverage
cargo-debandcargo-generate-rpm
I have a few comments that I as an server admin notice and can possibly be improved to make it easier for the community to use the module in the future.
I will probably update the ticket in the future.
Differences in documentation
vs.
The official documentation has no infromation about: