Support
Support
.deb, .rpm and .tar.gz builds.
Every Linux artefact is GPG-signed. Verifying is optional but takes about a minute, and it is the only way to know a download has not been altered in transit or on a mirror.
Substitute the version you actually downloaded for 3.10.0-rc.8
throughout.
The public key is downloadable without signing in, so it can be fetched straight onto a server:
curl -fsSLO https://support.pukka-j.com/pukka-j-signing-key.asc
Check it is the right key before importing it.
--show-keys inspects the file without touching your keyring:
gpg --show-keys --with-fingerprint pukka-j-signing-key.ascExpected output:
pub rsa4096 2026-08-04 [SC]
F0AC 083B B3A9 14C4 86ED E60F 507F 2A9D AA57 07B1
uid Pukka-J Ltd (Package Signing) <support@pukka-j.com>
This fingerprint check is the whole trust decision. Everything
below rests on it. The fingerprint above is served over HTTPS by this portal; if
what gpg reports disagrees with it, stop and contact support.
.deb) and the generic tarball (.tar.gz)
Both use a detached signature — the .asc file next to the
download on the portal — checked with gpg, so the key needs to
be in GPG's own keyring first:
gpg --import pukka-j-signing-key.ascgpg --verify pukkaj-nexus_3.10.0~rc.8-1.0_amd64.deb.asc \
pukkaj-nexus_3.10.0~rc.8-1.0_amd64.debYou want to see:
gpg: Good signature from "Pukka-J Ltd (Package Signing) <support@pukka-j.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Good signature is the pass. The WARNING is
expected and is not a failure.
The two lines say different things. The first is cryptographic: the file is intact and was signed by the holder of that key. The second is about provenance: GnuPG has the key but no record of you having decided it belongs to Pukka-J. Every third-party key produces this until you say otherwise, and GnuPG does not consult certificate authorities, so no commercial certificate would remove it either.
If the signature does not verify, do not install. Re-download, and if it fails again contact support.
Only do this once you have checked the fingerprint above.
If you have your own GPG key:
gpg --lsign-key F0AC083BB3A914C486EDE60F507F2A9DAA5707B1This records a local, non-exportable certification: it stays on your machine and does not vouch for the key to anyone else.
If you do not have a GPG key of your own, --lsign-key will fail with
no default secret key. Set ownership trust instead:
echo "F0AC083BB3A914C486EDE60F507F2A9DAA5707B1:6:" | gpg --import-ownertrust
Either way gpg --verify afterwards reports [full] or
[ultimate] and no warning.
The RPM file is signed, so there is no separate .asc file.
sudo rpm --import pukka-j-signing-key.asc
rpm --checksig pukkaj-nexus-3.10.0-rc.8.x86_64.rpmExpected:
pukkaj-nexus-3.10.0-rc.8.x86_64.rpm: digests signatures OK
rpm has no web-of-trust concept, so importing is the trust
decision and there is no warning to silence.
digests signatures NOT OK, or output mentioning
MISSING KEYS, means the key was not imported or the file is not
intact — do not install.
For a server build or CI, do not modify the trust database at all. Pin the key fingerprint directly and let the exit code decide:
gpg --status-fd 1 --verify pukkaj-nexus_3.10.0~rc.8-1.0_amd64.deb.asc \
pukkaj-nexus_3.10.0~rc.8-1.0_amd64.deb 2>/dev/null \
| grep -q '^\[GNUPG:\] VALIDSIG F0AC083BB3A914C486EDE60F507F2A9DAA5707B1 ' \
|| { echo "SIGNATURE CHECK FAILED - not installing" >&2; exit 1; }This is preferable to the interactive check because it asserts the exact key that signed the file and there is no trust-database state to get wrong.
sudo apt install ./pukkaj-nexus_3.10.0~rc.8-1.0_amd64.debTwo details that catch people out:
./ is required. Without it apt looks for a
package named pukkaj-nexus_...deb in the configured
repositories and fails;
apt, not dpkg -i, which allows an adduser
dependency to be resolved rather than simply reported.
sudo rpm --install ./pukkaj-nexus-3.10.0-rc.8.x86_64.rpmUnpack wherever you intend to run it. The tarball has no maintainer scripts, so the directory layout, service unit and system user described below are not created for you.
ls -l /opt/pukkaj/nexusThis must be a symlink resolving to the versioned payload directory. The two package formats name that directory differently, and both are correct:
| Installed from | Expected symlink target |
|---|---|
.deb |
/opt/pukkaj/nexus-3.10.0-rc.8 |
.rpm |
/opt/pukkaj/nexus-3.10.0 |
The RPM directory carries no -rc.8 suffix because RPM splits a version
into a version and a release, and the pre-release part becomes the release. So an RPM
install of 3.10.0-rc.8 lays its payload down under
/opt/pukkaj/nexus-3.10.0. That is expected, not a broken install.
What matters either way is that the symlink resolves. If it is missing or dangling the package did not configure correctly — capture the output of the install command and contact support.
Where things live:
| Path | Contents | Preserved on upgrade |
|---|---|---|
/opt/pukkaj/nexus |
Symlink to the installed version | Repointed on upgrade |
/opt/pukkaj/nexus-<version> |
Application payload and bundled Java runtime | Replaced |
/etc/pukkaj/nexus/deployment.properties |
Main configuration | Yes |
/var/lib/pukkaj/nexus |
Runtime configuration, docs, icons | Yes; defaults are refreshed |
/data/pukkaj/nexus |
Image data | Yes |
/var/log/Pukka-j/Nexus/Logs |
Logs | Yes |
The package creates a system user and group pukkaj, and installs a
pukkaj_nexus.service unit.
The service is deliberately not enabled or started by the installer, so that configuration can be reviewed first. To enable and start the service, run:
sudo systemctl enable --now pukkaj_nexus
systemctl status pukkaj_nexus
Configuration under /etc/pukkaj/nexus and data under
/data/pukkaj/nexus are preserved. The
/opt/pukkaj/nexus symlink is repointed at the new version.
Note how pre-release versions are numbered. A release candidate is published as
3.10.0~rc.8, with a tilde, and the tilde sorts before
the final 3.10.0. That is deliberate: it means the final release is
correctly seen as an upgrade from any of its release candidates. A version using a
hyphen there would sort above the final release and strand you on the
pre-release.
Verify and install the newer package the same way as a fresh install; there is no need to remove the old one first.
sudo apt install ./pukkaj-nexus_3.10.0-1.0_amd64.debUse the RPM upgrade flag to install the newer package, verifying it as before. There is no need to remove the old one first.
sudo rpm --upgrade ./pukkaj-nexus-3.10.0-1.0.x86_64.rpm
One exception, for early beta testers. Very briefly the RPM was
published under the package name nexus instead of
pukkaj-nexus. Because rpm matches upgrades on the package
name, upgrading will not replace it: both packages claim the same files and
rpm stops with a conflict. Check, and remove the old one if it is there:
rpm -q nexus # "package nexus is not installed" means you are unaffected
sudo rpm --erase nexus
sudo rpm --install ./pukkaj-nexus-3.10.0-1.0.x86_64.rpm
Erasing keeps a deployment.properties you have edited, but as
deployment.properties.rpmsave — see
Removing — so copy your settings back afterwards. Your
image data under /data/pukkaj/nexus is not touched.
Neither package manager removes your image data under
/data/pukkaj/nexus. Delete it by hand if you really intend to.
sudo apt remove pukkaj-nexus # leaves configuration and data
sudo apt purge pukkaj-nexus # also removes logs, the system user, and /opt symlinkssudo rpm --erase pukkaj-nexus
rpm treats configuration differently from apt remove. An
unmodified /etc/pukkaj/nexus/deployment.properties is removed on erase; a
modified one is kept alongside as
deployment.properties.rpmsave. There is no purge equivalent.
Include in any support request:
gpg --verify or rpm -K command;ls -l /opt/pukkaj/ and systemctl status pukkaj_nexus
where relevant.