Split the packages, publish releases from Gitea Actions, release 0.1.0
release / release (push) Successful in 7m7s
release / release (push) Successful in 7m7s
make deb now builds two packages: jarl-cli (the CLI, its completion and the ACME hooks, no scripts) and jarl (the server), which depends on jarl-cli of the same version. Pushing a v* tag runs .gitea/workflows/release.yml: it tests, builds the tarballs, the CLI for Linux, macOS and Windows (make cli-dist) and the .debs for amd64 and arm64, then scripts/gitea-release.sh creates the Gitea release and uploads the .debs to the Debian package registry, so servers install and upgrade with apt. The stats package's inode lookup is split by OS so the CLI builds for Windows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
1 parent
293e6ddd33
commit
4d00be53c3
16 files changed
+450
-84
No files matched your search
+84
-12
@@ -12,6 +12,12 @@ to load Jarl's configuration the old one is put back automatically.
|
||||
|
||||
## 1. Build
|
||||
|
||||
Each release is already built: the Debian packages are in the Gitea
|
||||
package registry ([below](#from-the-package-registry)), and the release
|
||||
page (https://gitea.adbraun.lol/adam/jarl/releases) has the packages, the
|
||||
linux tarballs, and the CLI for Linux, macOS and Windows. Build it yourself
|
||||
for an unreleased version.
|
||||
|
||||
Jarl is two static binaries with no runtime dependencies (SQLite is
|
||||
compiled in). Building needs Go 1.27 or newer, on any machine:
|
||||
|
||||
@@ -30,23 +36,62 @@ package (below) and copy that.
|
||||
There are two ways: a Debian package, which is easiest to upgrade and
|
||||
remove, or `make install`.
|
||||
|
||||
### With the Debian package
|
||||
### With the Debian packages
|
||||
|
||||
There are two packages:
|
||||
|
||||
| Package | Holds | Install it |
|
||||
|---------|-------|-----------|
|
||||
| `jarl` | the server: `jarld`, its systemd units, the docs | on the DNS server |
|
||||
| `jarl-cli` | the `jarl` CLI, its bash completion, the ACME hooks | wherever you manage Jarl from; `jarl` depends on it |
|
||||
|
||||
#### From the package registry
|
||||
|
||||
Every release is published to Gitea's Debian registry (amd64 and arm64).
|
||||
Add it to apt once, and apt then finds `jarl-cli` by itself and
|
||||
`apt upgrade` brings new releases:
|
||||
|
||||
```sh
|
||||
make deb # dist/jarl_0.1.0_amd64.deb
|
||||
make deb DEB_ARCH=arm64 # for another architecture (also armhf, i386, ...)
|
||||
sudo apt install ./dist/jarl_0.1.0_amd64.deb
|
||||
sudo install -d /etc/apt/keyrings
|
||||
sudo curl -fsSL https://gitea.adbraun.lol/api/packages/adam/debian/repository.key -o /etc/apt/keyrings/jarl.asc
|
||||
echo "deb [signed-by=/etc/apt/keyrings/jarl.asc] https://gitea.adbraun.lol/api/packages/adam/debian stable main" \
|
||||
| sudo tee /etc/apt/sources.list.d/jarl.list
|
||||
sudo apt update
|
||||
sudo apt install jarl
|
||||
```
|
||||
|
||||
The packages are as visible as the Gitea account that owns them, not the
|
||||
repository: with a public account, apt needs no login even if the
|
||||
repository is private. For a private or limited account, give apt a token
|
||||
with the `read:package` scope in `/etc/apt/auth.conf.d/jarl.conf` (mode
|
||||
0600):
|
||||
|
||||
```
|
||||
machine gitea.adbraun.lol/api/packages/adam/debian
|
||||
login adam
|
||||
password <token>
|
||||
```
|
||||
|
||||
#### From files
|
||||
|
||||
Download the two `.deb` files from the release page, or build them:
|
||||
|
||||
```sh
|
||||
make deb # dist/jarl_0.1.0_amd64.deb and dist/jarl-cli_0.1.0_amd64.deb
|
||||
make deb DEB_ARCH=arm64 # for another architecture (also armhf, i386, ...)
|
||||
sudo apt install ./dist/jarl_0.1.0_amd64.deb ./dist/jarl-cli_0.1.0_amd64.deb
|
||||
```
|
||||
|
||||
Give apt both files: `jarl` needs `jarl-cli` of the same version.
|
||||
`make deb` needs only `dpkg-deb` (no root, no debhelper) and cross-builds
|
||||
for any architecture Go supports. apt also installs `bind9` (recommended)
|
||||
if it's missing. Installing the package:
|
||||
if it's missing. Installing the server package:
|
||||
|
||||
* puts the binaries in `/usr/bin`, bash completion in
|
||||
* puts `jarld` in `/usr/bin`, its bash completion in
|
||||
`/usr/share/bash-completion/completions`, the systemd units in
|
||||
`/usr/lib/systemd/system` (`jarl.service`, and `jarl-backup.service`
|
||||
with its daily `jarl-backup.timer`), the sysusers and tmpfiles files
|
||||
in `/usr/lib`, and the docs and contrib files in `/usr/share/doc/jarl`;
|
||||
in `/usr/lib`, and the docs in `/usr/share/doc/jarl`;
|
||||
* creates the `jarl` user (in group `bind`) and Jarl's directories, and
|
||||
writes `/etc/jarl/jarl.yaml` from the example on the first install. No
|
||||
file in `/etc` belongs to the package, so your configuration is never
|
||||
@@ -58,17 +103,44 @@ if it's missing. Installing the package:
|
||||
* doesn't start jarld: continue with [3. Configure](#3-configure), then
|
||||
`systemctl enable --now jarl` in step 8.
|
||||
|
||||
**Upgrading**: build and install the newer package the same way. A running
|
||||
jarld is restarted, and upgrades its database as it starts.
|
||||
`jarl-cli` installs `/usr/bin/jarl`, its completion, and
|
||||
`/usr/share/doc/jarl-cli` (the CLI, ACME and permissions docs, and the
|
||||
acme.sh and lego hooks in `contrib/`).
|
||||
|
||||
**Upgrading**: `sudo apt update && sudo apt upgrade` with the registry, or
|
||||
install the newer files the same way. A running
|
||||
jarld is restarted, and upgrades its database as it starts. Up to 0.1.0
|
||||
everything was one `jarl` package; installing the two new ones over it
|
||||
moves `/usr/bin/jarl` to `jarl-cli` by itself.
|
||||
|
||||
**Removing** (`sudo apt remove jarl`) stops jarld and the backup timer and
|
||||
removes the program, but named keeps running with the configuration Jarl
|
||||
removes the server (the CLI stays until you remove `jarl-cli` too), but named keeps running with the configuration Jarl
|
||||
last wrote. Even `apt purge jarl` keeps `/etc/jarl`, `/var/lib/jarl` (the
|
||||
database), `/var/backups/jarl` and the
|
||||
files in `/etc/bind/jarl`, `/var/lib/bind/jarl` and `/var/cache/bind/jarl`,
|
||||
since named.conf may still include them. Remove them by hand once named no
|
||||
longer uses them.
|
||||
|
||||
### Just the CLI, on another machine
|
||||
|
||||
To manage Jarl servers from your laptop or another server, install only
|
||||
`jarl-cli`. It needs nothing else and changes nothing on the machine (no
|
||||
users, services or directories):
|
||||
|
||||
```sh
|
||||
sudo apt install jarl-cli # with the registry above; or: sudo apt install ./jarl-cli_0.1.0_amd64.deb
|
||||
jarl config set server https://ns1.adbraun.lol:8053
|
||||
jarl config set token
|
||||
```
|
||||
|
||||
Elsewhere, download the CLI from the release page:
|
||||
`jarl-cli-<version>-<os>-<arch>` for Linux, macOS (`darwin`) and Windows
|
||||
(`.exe`), with their checksums in `SHA256SUMS`. It is one static file; put
|
||||
it in your PATH as `jarl` (on macOS, `xattr -d com.apple.quarantine jarl`
|
||||
lets an unsigned download run). `make cli-dist` builds the same files, and
|
||||
`make` builds it for this machine in `bin/`. [cli.md](cli.md)
|
||||
explains the setup, and several servers in one configuration.
|
||||
|
||||
### With make install
|
||||
|
||||
On the DNS server, as root:
|
||||
@@ -297,8 +369,8 @@ without dropping connections. More in [acme.md](acme.md).
|
||||
## Upgrading
|
||||
|
||||
```sh
|
||||
make && sudo make install
|
||||
sudo systemctl restart jarl
|
||||
sudo apt update && sudo apt upgrade # Debian packages from the registry
|
||||
make && sudo make install && sudo systemctl restart jarl # make install
|
||||
```
|
||||
|
||||
Database migrations run automatically at startup. Before an upgrade, take
|
||||
|
||||
Reference in new issue
Block a user