Forklift - Text based GUI utility for dealing with containers
an invention by andreabenini
Updated almost 2 years ago. 6 hacker ♥️. 3 followers.

Project Description

This is a simple and handy text based GUI utility for dealing with boring and repetitive tasks while managing containers.
If you usually manage them in your daily activities you'll surely deal a lot with the CLI and execute repetitive commands for: building images, creating containers, running, killing and stopping them all the time.

It doesn't really matter if you are a Developer, a DevOps or a SRE; most of your time might be spent on the CLI for deleting/respawning/starting new instances for your favorite product.
You can surely do it from a GUI or editor (vscode, eclipse, ...) but it might be messy if you're managing them remotely through SSH and all you have at your disposal is just your trusty text-only shell connection.

That's the reason for this simple, quick, text-only curses based utility, no matter if containers are running on a remote machine, locally or if you prefer a specific Window Manager. I expressly don't want to rely on X11/Wayland, infinite dependencies (or keep them to the bare minimum) and it has to be text-only and usable from a remote shell.
This utility relies on: python (+yaml) and curses bindings (just plain curses, no extra widgets required).
It is not a fully fledged solution but rather a small and quick tool for running boring tasks, you'll still use docker/podman of your choice but you don't want to be annoyed by usual and repetitive commands (docker ps -a; docker kill ; docker start).

That's what this utility is about.

Goal for this Hackweek

Building a working tool for dealing with boring and repetitive tasks:

  • Totally independent from: docker, podman, LXD (planned)
  • Not related to kubernetes, orchestrators or pods, just "simple" containers. Targeted to personal workstations and workflows, no matter if local or on a remote ssh shell
  • Stop/Start/Kill container
  • Build containers from Images
  • Build images from Containerfile/Docker file
  • Delete images and container quickly without ps+rm+rmi commands
  • A simple and quick curses based cli gui to be used with fewer keys
  • Running locally or through a SSH remote connection should be the same

Resources

git repository: https://github.com/andreabenini/podmaster/tree/main/forklift/
This is a brand new idea with no prior source code or fork from an existing tool.
I want to develop the idea and have a prototype at the end of the Hack Week

keywords

text gui, command line, utility, curses, shell, container, python, podman, docker, ssh, remote

Looking for hackers with the skills:

containers podman docker console curses python

This project is part of:

Hack Week 23

Activity

  • almost 2 years ago: socon liked this project.
  • about 2 years ago: FridayKetchup liked this project.
  • about 2 years ago: amunoz liked this project.
  • about 2 years ago: jzerebecki liked this project.
  • about 2 years ago: andreabenini added keyword "console" to this project.
  • about 2 years ago: andreabenini added keyword "curses" to this project.
  • about 2 years ago: andreabenini added keyword "python" to this project.
  • about 2 years ago: andreabenini added keyword "podman" to this project.
  • about 2 years ago: andreabenini added keyword "docker" to this project.
  • about 2 years ago: andreabenini added keyword "containers" to this project.
  • about 2 years ago: gleidi joined this project.
  • about 2 years ago: gleidi liked this project.
  • about 2 years ago: andreabenini started this project.
  • about 2 years ago: andreabenini liked this project.
  • about 2 years ago: andreabenini originated this project.


    • Comments

    • andreabenini
      about 2 years ago by andreabenini | Reply

      I'll use comment section to post general updates and features.

      • General purpose widgets are in place, maybe they need some refinement but are stable enough for the project, I'm now using: messagebox, inputbox, menu, confirm box
      • Container image management is now working and I'm able to build new images while parking the program's curses interface
      • Container listing and general action items (start/attach, kill, rename, delete) are now working
      • Container listing is suitable for personal desktop usage, not really usable on a fully fledged server with hundreds or thousand containers. No container search feature (yet, but planned)
      • Storing configurations in yaml file (easy to read and you can also add comments in it)
      • docker and podman are fully supported (and tested), never tried LXD or other container managers. I'm now planning to support docker and podman because they basically have the same interface and commands, if necessity arises I'll add something else too.
      • I'll publish curses widgets today, barebone (but working) main utility tomorrow after the tests. I'm now using the python testunit module to suit them all. I'm still without external dependencies, libraries or whatsoever and I'm still working to keep them away; the project has to be simple and without deps (or a required virtual environment) to keep it to the bare minimum.

    • andreabenini
      about 2 years ago by andreabenini | Reply

      Project info, sample configs and contrib materials are already in the github repo. Rushing on test units for the utility, v0.1 (stable) will be released today ahead in schedule

    • andreabenini
      about 2 years ago by andreabenini | Reply

      Project published, download everything from https://github.com/andreabenini/podmaster/tree/main/forklift/ Still testing and adding basic functionalities but it's now live and working

    • andreabenini
      about 2 years ago by andreabenini | Reply

      The utility is straight simple but some documentation is still necessary, just some markdown and a couple of screenshots.

    • andreabenini
      about 2 years ago by andreabenini | Reply

      Project is working, I've deployed locally for further improvements and in my VM where the real work is. I'm using it locally for further development, test-units checks, local stuff. Remotely on my production machine and it's now working. Constant updates are frequent when new features or comments arise but you can consider it usable. Publishing the package on Pypi is an installation feature coming real soon, feel free to use it right now.

    • andreabenini
      almost 2 years ago by andreabenini | Reply

      v0.2.4 released.
      See CHANGELOG file, updated documentation and a small video in the git repository. Mostly bug fixing and few small new features. Feature freeze at the moment because I'm now focusing on the Pypi catalog for a really smart installation. If someone does not want to get the repo cloned from github, the next version will address pypi specifically. I'm still planning to add LXD, probably just for the sake of doing it because I have never had a single request for it. For personal usage (not orchestration) adding lxd might give me almost a 100% coverage (ubuntu users mostly). Feel free to submit patches and comments on github.

    • socon
      almost 2 years ago by socon | Reply

      Looks like a great project and is aligned with the vision to manage containers for Dolomite, but I wonder why Python. We are trying to reduce the dependency on Python for ALP.

      • andreabenini
        about 1 year ago by andreabenini | Reply

        I'm a bad person and discovered your comment right now, I apologize about it. Python was picked up to create a small and quick project barely in just that week, that's the main reason for it. I was able to create a working project quickly and maybe it was one of the reasons why I won. I have developed it a little bit more as you can see, this project has now NO python lib deps at all. no libraries like curses or other external libs, I've even rewrote a couple of things to avoid adding pyyaml (which is not included by default). Required libs are always default included ones so virtualenv is not required, basically: subprocess, json, argparse, math and few more..

        I can quite easily rewrite it with Go if you're still interested, one self included binary for every architecture is probably better and surely faster too

    Similar Projects

    Technical talks at universities by agamez

    Description

    This project aims to empower the next generation of tech professionals by offering hands-on workshops on containerization and Kubernetes, with a strong focus on open-source technologies. By providing practical experience with these cutting-edge tools and fostering a deep understanding of open-source principles, we aim to bridge the gap between academia and industry.

    For now, the scope is limited to Spanish universities, since we already have the contacts and have started some conversations.

    Goals

    • Technical Skill Development: equip students with the fundamental knowledge and skills to build, deploy, and manage containerized applications using open-source tools like Kubernetes.
    • Open-Source Mindset: foster a passion for open-source software, encouraging students to contribute to open-source projects and collaborate with the global developer community.
    • Career Readiness: prepare students for industry-relevant roles by exposing them to real-world use cases, best practices, and open-source in companies.

    Resources

    • Instructors: experienced open-source professionals with deep knowledge of containerization and Kubernetes.
    • SUSE Expertise: leverage SUSE's expertise in open-source technologies to provide insights into industry trends and best practices.

    Rewrite Distrobox in go (POC) by fabriziosestito

    Description

    Rewriting Distrobox in Go.

    Main benefits:

    • Easier to maintain and to test
    • Adapter pattern for different container backends (LXC, systemd-nspawn, etc.)

    Goals

    • Build a minimal starting point with core commands
    • Keep the CLI interface compatible: existing users shouldn't notice any difference
    • Use a clean Go architecture with adapters for different container backends
    • Keep dependencies minimal and binary size small
    • Benchmark against the original shell script

    Resources

    • Upstream project: https://github.com/89luca89/distrobox/
    • Distrobox site: https://distrobox.it/
    • ArchWiki: https://wiki.archlinux.org/title/Distrobox

    Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy

    Description

    The Mission: Decentralized & Sovereign Messaging

    FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com

    In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.

    However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.

    Why This Matters

    A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:

    • Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
    • Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
    • Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.

    By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.

    Goals

    As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.

    Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:

    • Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
    • Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
    • Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
    • Allow the use of bind or remote mounted volumes for shared data (/var/vmail, DKIM keys, TLS certs, etc.).
    • Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.

    By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol

    Resources

    Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy

    Description

    The Mission: Decentralized & Sovereign Messaging

    FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com

    In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.

    However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.

    Why This Matters

    A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:

    • Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
    • Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
    • Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.

    By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.

    Goals

    As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.

    Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:

    • Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
    • Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
    • Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
    • Allow the use of bind or remote mounted volumes for shared data (/var/vmail, DKIM keys, TLS certs, etc.).
    • Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.

    By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol

    Resources

    Enhance git-sha-verify: A tool to checkout validated git hashes by gpathak

    Description

    git-sha-verify is a simple shell utility to verify and checkout trusted git commits signed using GPG key. This tool helps ensure that only authorized or validated commit hashes are checked out from a git repository, supporting better code integrity and security within the workflow.

    Supports:

    • Verifying commit authenticity signed using gpg key
    • Checking out trusted commits

    Ideal for teams and projects where the integrity of git history is crucial.

    Goals

    A minimal python code of the shell script exists as a pull request.

    The goal of this hackweek is to:

    • Add more unit tests
    • Make the python code modular
    • DONE: Add code coverage if possible

    Resources

    Bring to Cockpit + System Roles capabilities from YAST by miguelpc

    Bring to Cockpit + System Roles features from YAST

    Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.

    Goals

    The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.

    Resources

    A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit

    Linux System Roles:

    First meeting Hackweek catchup

    Song Search with CLAP by gcolangiuli

    Description

    Contrastive Language-Audio Pretraining (CLAP) is an open-source library that enables the training of a neural network on both Audio and Text descriptions, making it possible to search for Audio using a Text input. Several pre-trained models for song search are already available on huggingface

    SUSE Hackweek AI Song Search

    Goals

    Evaluate how CLAP can be used for song searching and determine which types of queries yield the best results by developing a Minimum Viable Product (MVP) in Python. Based on the results of this MVP, future steps could include:

    • Music Tagging;
    • Free text search;
    • Integration with an LLM (for example, with MCP or the OpenAI API) for music suggestions based on your own library.

    The code for this project will be entirely written using AI to better explore and demonstrate AI capabilities.

    Resources

    Improve chore and screen time doc generator script `wochenplaner` by gniebler

    Description

    I wrote a little Python script to generate PDF docs, which can be used to track daily chore completion and screen time usage for several people, with one page per person/week.

    I named this script wochenplaner and have been using it for a few months now.

    It needs some improvements and adjustments in how the screen time should be tracked and how chores are displayed.

    Goals

    • Fix chore field separation lines
    • Change screen time tracking logic from "global" (week-long) to daily subtraction and weekly addition of remainders (more intuitive than current "weekly time budget method)
    • Add logic to fill in chore fields/lines, ideally with pictures, falling back to text.

    Resources

    tbd (Gitlab repo)

    Improvements to osc (especially with regards to the Git workflow) by mcepl

    Description

    There is plenty of hacking on osc, where we could spent some fun time. I would like to see a solution for https://github.com/openSUSE/osc/issues/2006 (which is sufficiently non-serious, that it could be part of HackWeek project).