LightkeeperRM (Remote Management) is a lightweight and modular drop-in replacement for maintaining servers over SSH. No additional daemons, agents or other software is needed on target hosts. LightkeeperRM will only run standard Linux commands already available on the host. You can see executed commands through debug log and on target hosts's logs (depending on setup), so it's easy to audit and debug. Lightkeeper simplifies general maintenance tasks such as upgrades, monitoring, debugging and configuration.
Agentless monitoring. Monitors hosts and certificates.
LightkeeperRM aims to be customizable, modular and easily extendable, so that it can be modified for different needs.
User-interface is compact and aims to keep only the most essential information visible. Clicking and navigating between different views is kept to a minimum.
In case you find the GUI insufficient and need to dig deeper, you can always use a button, or hotkey, for launching a terminal that logs you in through SSH.
Extensive keyboard shortcuts.
NOTE: this is currently a pre-release and still has bugs and is missing some features. Documentation is also not yet complete.
Overview of LightkeeperRM's GUI.
- Monitor status changes periodically and get alert notifications.
- Monitor certificate validity and expiration.
- Status summary in host table for quick status view
- Log viewer with regex search and hotkeys similar to less/vim.
- Text file editor for editing remote files (with built-in editor or using CLI over SSH).
- Follow console output for longer running commands such as container builds and package updates.
The idea for Lightkeeper rose from personal needs. Writing the same commands over the years can get tiresome and feel slow, even if utilizing shell's command history.
Another pain point was monitoring. Configuring and maintaining a software stack for relatively simple monitoring needs (graphs, alerts) can get needlessly heavy. Specifically, in my case, I aim to replace CollectD, InfluxDB and Grafana (although, an external DB would still be possible with Lightkeeper).
So, I started formulating an idea about a more integrated maintenance tool for power users to simplify everything. At the same time, deploying should be as simple as possible since the aim is to streamline. The plain old shell doesn't need additional daemons on the servers so Lightkeeper shouldn't either.
It is recommended to download the app from Flathub: https://flathub.org/apps/io.github.kalaksi.Lightkeeper
It's sandboxed and uses the minimum amount of permissions required.
The alternative is building from source.
flatpak-builder build --user --force-clean flatpak/io.github.kalaksi.Lightkeeper-local.yml
# If you want to install also:
flatpak-builder --user --install --force-clean build flatpak/io.github.kalaksi.Lightkeeper-local.yml
Dependencies are:
- Qt 6.4
- liboping
- libdbus
Migration to Qt6 is now done, so now you'll need these packages on Ubuntu 24.04:
- libssl-dev
- libdbus-1-3, libdbus-1-dev
- liboping0, liboping-dev
- libqt6svg6
- qt6-declarative-dev
- qml6-module-qt-labs-qmlmodels
- qml6-module-qt5compat-graphicaleffects
- qml6-module-qtqml-workerscript
- qml6-module-qtquick-controls
- qml6-module-qtquick-layouts
- qml6-module-qtquick-nativestyle
- qml6-module-qtquick-shapes
- qml6-module-qtquick-templates
- qml6-module-qtquick-window
- qml6-module-qtquick-dialogs
- qml6-module-qt-labs-platform
Building:
./build.sh
Running:
./run.sh
If you're getting error about missing qmake, you'll have to point cargo to correct qmake with .cargo/config.toml:
[env]
QMAKE = "/usr/lib/qt6/bin/qmake"
If you're using the ping monitor (not used by default), you need to give Lightkeeper binary more networking privileges:
$ setcap cap_net_raw+ep $MY_BINARY
The (current) goal is to support:
- Debian
- Ubuntu
- RHEL
- CentOS
- NixOS
- Linux in general (basic functionality for most distributions)
NOTE: There is currently an assumption that your user can run sudo without password (or has root privileges) on the target host since some commands need higher privileges.
Configuration can now be done using the graphical UI, but configuring can always be done directly through configuration files, too.
Example configuration files config.example.yml, hosts.example.yml and groups.example.yml can be found in the root of this repository.
When running without flatpak, the default configuration directory is usually ~/.config/lightkeeper and cache directory ~/.cache/lightkeeper.
With flatpak, it's the usual app specific directory: ~/.var/app/io.github.kalaksi.Lightkeeper/config and ~/.var/app/io.github.kalaksi.Lightkeeper/cache.
You can use a custom configuration directory with the -c/--config-dir option.
Log levels are controlled with environment variable RUST_LOG, so use RUST_LOG=debug.
test-env-directory contains Vagrantfiles for virtual machines and also matching configurations for testing.
You can use --config-dir to load the test configuration for manual testing. For example, ./target/debug/lightkeeper --config-dir test if building from source.
For automatic testing, run cargo test.
Copyright © 2023 kalaksi@users.noreply.github.com.
This software is licensed under GNU General Public License 3.
NOTE: If you need a non-GPL license, get in contact.
All crate dependencies contain permissive licenses (mostly MIT license).
You can check the licenses with:
cargo tree --format "{p} {l}" --prefix none
Or, to quickly see what different licenses are being used by printing only unique license strings:
cargo tree --format "{l}" --prefix none | sort | uniq
Liboping 1.10 (https://noping.cc/) is redistributed inside the flatpak package. It's a separate C library dependency needed by oping-crate and is distributed under LGPL-2.1 license.