-
Notifications
You must be signed in to change notification settings - Fork 0
Usage Deb
silo publish ./hello_1.0-1_amd64.deb --repo myrepo --channel stableThe format is inferred from the .deb extension; pass --format deb to be explicit. Publishing is gRPC/CLI-only — there is no HTTP publish path for deb.
silo serves one component (main) and one suite per channel — the suite name is the channel itself. A real Debian archive can carry several components and several suites sharing one pool; silo's channel already plays that role, so it offers exactly one of each rather than a second axis to configure.
apt's one-line sources.list format puts credentials in the source URL, the same HTTP Basic convention dnf/apk use elsewhere on this wiki — the username is ignored, the token goes entirely in the password field:
# /etc/apt/sources.list.d/silo.list
deb [signed-by=/etc/apt/keyrings/silo.gpg] http://silo:silo_xxxxxxxxxxxx_yyyy...@silo.internal:8080/myrepo/stable stable main
The suite (stable, the third field) and the stable in the URL are two different things a client picks independently — apt appends dists/<suite>/... to the base URL itself — but silo answers for the channel named in the URL regardless of what suite string a client sends, so keeping them identical is the least confusing convention rather than a requirement.
signed-by= is required whenever a key is configured (see Signing, below) — without it apt refuses to trust anything under this source. Without a key configured, drop [signed-by=...] entirely.
Once the repo is public (silo repo set myrepo --mode=public, see Usage), drop the credential from the URL:
deb [signed-by=/etc/apt/keyrings/silo.gpg] http://silo.internal:8080/myrepo/stable stable main
Reads work with no credential. Publishing still requires a write-scoped token regardless of repo mode.
An Architecture: all package is folded into every concrete architecture's Packages file at index-build time, the same idea as apk's noarch and pacman's any — apt only ever fetches its own architecture's tree. Unlike apk and pacman, this fold happens at publish time rather than request time: apt's Release file enumerates every architecture's Packages* at once, so silo needs a real publish to some concrete architecture before an all package becomes visible anywhere. A repo that has only ever received all publishes serves no binary-<arch> directory at all, and its packages stay unreachable until a concrete-architecture package is published alongside them.
If the server has signing.gpg configured (see Setup) — the same key RPM uses, not a separate one — Release gets a detached armored signature (Release.gpg) and a clearsigned InRelease (Release's body and signature folded into one document, the form most apt deployments prefer today). Both exist whenever the key is configured; neither exists otherwise.
mkdir -p /etc/apt/keyrings
curl -fsS https://silo.example.com/RPM-GPG-KEY-silo | gpg --dearmor -o /etc/apt/keyrings/silo.gpgGET /RPM-GPG-KEY-silo is the same unauthenticated endpoint Usage-RPM describes — one key signs every repo the server serves, dnf and apt alike. apt's signed-by= wants a binary (dearmored) keyring rather than the armored form the endpoint serves, hence gpg --dearmor.