Run a self-hosted SQL IDE on Fedora with LibreDB Studio

Team Workflows Fedora Magazine
1

Article Summary:

Install a self-hosted, browser-based SQL IDE on Fedora from the project’s RPM, run it as a systemd service, and be straight with the reader about where that packaging still falls short.

Article Description:

The article would take a reader from a fresh Fedora machine to a working database client they open in a browser on their own network, using nothing but Fedora and one RPM.

Flow:

  1. What a self-hosted database client is, and why you might want one instead of a desktop app or a vendor’s cloud console.
  2. Installing from the project’s RPM. It is not in the Fedora repositories and there is no COPR build, so the article shows the download, the sha256 check, and dnf install of a local file. It also says plainly that the package ships a checksum and no GPG signature today, and what that means for the reader.
  3. The systemd unit that comes in the package: systemctl enable --now libredb-studio, where the SQLite state lives, and what journalctl -u libredb-studio shows when it refuses to start.
  4. Reaching it from another machine: firewall-cmd for the port, and the SELinux behaviour on a default install.
  5. Connecting it to a local PostgreSQL and a local MariaDB, both installed from Fedora’s own packages, so every step in the article can be reproduced on one Fedora box.

What I would not dress up. The package bundles its own Node.js runtime instead of depending on Fedora’s nodejs. That keeps the install to a single command and it is the wrong answer by Fedora packaging guidelines. The article would say so, link the packaging file, and leave the reader able to judge it.

Facts behind the pitch: MIT licensed, x86_64 and aarch64 RPMs published with every release, current version 0.17.0, eighteen database drivers of its own with further engines reachable over those same wire protocols.

I am a first-time contributor here. I opened issue 81 on the magazine forge on 21 September and rlengland pointed me to this forum, so this is that proposal in the place it belongs. If the angle is wrong for the Magazine, or if walking readers through a third-party RPM is not something the Magazine wants to do, I would rather hear that than have it sit.

I have read and understand the Ai-Assisted Contributions Policy

For Editor Use Only

Editor:

Image Editor:

Publication Date:

Preview Link:

2

This article sounds OK to me. +1. Thanks!

… Installing from the project’s RPM. It is not in the Fedora repositories and there is no COPR build …

Can this be installed under Toolbox or some other container to provide some sandboxing?

3

Welcome to the Magazine, @libredb
Please note the earlier question/suggestion from @glb.

If you have any questions please communicate them with replies on this topic. When you have something ready for review in WordPress Engine, let us know that here, as well. A link to the preview would be sufficient.

Thanks for volunteering your time and effort.

4

Toolbox, no: there is no systemd in it, so the unit never starts, and the unit is the point of the RPM.

Rootless podman, yes: ghcr.io/libredb/libredb-studio. I will cover that as the sandboxed alternative.

The RPM is not unsandboxed either, which I should have said in the pitch. The shipped unit uses DynamicUser, ProtectSystem=strict, ProtectHome, PrivateTmp, the ProtectKernel* set and an empty CapabilityBoundingSet, and binds to 127.0.0.1. One exception, stated rather than hidden: MemoryDenyWriteExecute is off, because V8 needs it.

Thanks, that makes the article better.