Forem: Miklos Halasz

Why My Laptop Drained Overnight While Docked (and How a GRUB Change Fixed It)

Miklos Halasz — Mon, 09 Feb 2026 07:40:53 +0000

I experienced a confusing and frustrating issue while using a Dell WD19 USB-C dock on Ubuntu. In the evening, everything worked as expected: the laptop was charging properly, external displays were active, and the wired network was connected. The next morning the laptop battery was completely empty — even though it had remained connected to the dock the entire time.

Even more confusing, this problem did not only occur overnight. Sometimes, after the laptop woke up from sleep, the dock would continue to provide display output and network connectivity, yet would no longer supply any power. In that state, the system would quietly run on battery while appearing to be fully docked.

At first glance, this behavior seems impossible. A dock that can drive displays and provide Ethernet should also provide power. But with modern USB-C docks and Linux power management, this assumption is unfortunately not always true.

The actual problem

The root of the issue lies in how Linux handles power management during idle and suspend states, combined with how USB-C Power Delivery (PD) is negotiated.

While the laptop was idle overnight, it entered a low-power state known as s2idle (also called Modern Standby). In this state, the system is not fully asleep. The CPU is mostly idle, but many components — including USB controllers — remain logically active. This allows for fast wake-up times, but it also means devices are expected to manage their own low-power behavior correctly.

Linux, trying to reduce power usage further, enables USB autosuspend by default. Autosuspend allows the kernel to put USB devices into a low-power state when they appear idle. This works well for simple peripherals, but the WD19 dock is not a simple device. Internally, it contains a USB hub, a USB-C Power Delivery controller, a DisplayPort alt-mode controller, and a network adapter.

During the night, USB autosuspend put part of the dock into a suspended state. When that happened, the dock’s Power Delivery controller dropped the negotiated power contract. From the laptop’s perspective, external power simply disappeared. The system silently switched to battery power and continued running in s2idle until the battery was fully drained. Because the USB connection itself was never fully reset, Linux never retried power negotiation, and no warning was shown.

This is why the system looked fine before sleep, yet was dead in the morning.

The solution: disabling USB autosuspend

The fix was to disable USB autosuspend globally by altering the GRUB configuration and adding the following kernel parameter:

usbcore.autosuspend=-1

After updating GRUB and rebooting, the kernel no longer attempts to automatically suspend USB devices. As a result, the dock’s Power Delivery controller remains fully powered and active, even while the system is idle or suspended in s2idle. The power contract between the dock and the laptop stays intact, and the laptop continues charging throughout the night.

This change does not meaningfully increase power consumption. The additional power usage is negligible compared to what the dock and external monitors already consume, and system stability is significantly improved.

Where s2idle and S3 fit into this

To understand why this fix is effective, it helps to distinguish between the two common Linux sleep states.

In s2idle, the system is only partially asleep. Devices remain logically connected, and power management relies heavily on drivers behaving correctly. This is where USB-C docks often fail, because power delivery can be dropped without a full hardware reset.

In contrast, S3 sleep (also called deep sleep or suspend to RAM) fully powers down the CPU and most devices, including USB controllers. When the system wakes up, everything — including USB-C power delivery — is reinitialized from scratch. This makes S3 far more robust, especially when docks are involved.

Disabling USB autosuspend makes s2idle behave more safely by preventing the dock from entering a half-suspended state where power delivery can be lost. In many cases, this alone is sufficient and avoids the need to force S3 sleep.

Why this works reliably

By altering GRUB and disabling USB autosuspend, the system no longer allows the dock’s internal controllers to power down independently during idle. This prevents the silent loss of USB-C power delivery that caused the overnight battery drain. The dock remains fully operational, the charging contract stays active, and the laptop behaves as users naturally expect: if it is docked, it stays charged.

In short, the problem was not a faulty battery or charger, but a subtle interaction between modern Linux power states and USB-C dock firmware. A single kernel parameter was enough to restore predictable and reliable behavior.

Building a Reliable NAS and Integrating UPS Monitoring with TrueNAS and Home Assistant

Miklos Halasz — Tue, 07 Oct 2025 08:18:33 +0000

I built a NAS from spare parts — an MSI X99A Raider motherboard, a 6-core Intel Xeon CPU, 128 GB ECC DDR4 RAM, a 10G NIC, and an HBA card for the HDDs. The HDDs are configured in ZFS RAID-Z2, allowing the system to tolerate up to two simultaneous disk failures. The operating system is installed on two SSDs configured in RAID10 for redundancy.

Is it overkill for a homelab? Maybe. But I want to store my documents, family photos, and other personal data reliably, without relying on any cloud provider.

Why TrueNAS?

I think TrueNAS is an excellent choice. It offers an intuitive web interface, straightforward setup, and clear configuration options — making it ideal for homelab environments as well.

Recently, I purchased an APC UPS. While ZFS (RAID-Z2) provides strong data integrity and fault tolerance, it doesn’t protect against sudden power loss. I didn’t want to leave it to chance, so I integrated the UPS to ensure the NAS can gracefully shut down when the battery level is low.

To achieve this, I installed NUT (Network UPS Tools) on one of my Raspberry Pis, connecting the UPS via USB. The Raspberry Pi acts as the UPS server and communicates with the TrueNAS system over the network.

Configuring UPS Integration in TrueNAS

After setting up NUT on the Raspberry Pi, I logged into the TrueNAS admin interface and navigated to
System → Services → UPS (pencil icon) to configure the UPS client.

In the configuration form, I entered:

An identifier for the UPS connection
The IP address, port, and credentials for the NUT observer user

Once saved, I activated the UPS service and enabled auto-start.

This setup allows the NUT client on the TrueNAS server to monitor the UPS and automatically shut down the NAS when the UPS battery level becomes critically low.

Monitor UPS with Home Assistant

TrueNAS can run containerized applications using Docker Compose under the hood.
Some applications are available directly from the TrueNAS catalog (and only require minimal configuration), but you can also deploy custom “freestyle” applications, where you define everything manually.

If you install a catalog app but need more granular control, you can convert it to a freestyle application, giving you direct access to the underlying Docker Compose configuration.

Traefik

Because I already had multiple applications running on my TrueNAS system, I wanted to route their traffic based on hostnames rather than remembering port numbers. To achieve this, I installed Traefik as a reverse proxy using the following configuration:

networks:
  proxy:
    driver: bridge
    external: true

services:
  traefik:
    command:
      - '--api.insecure=true'
      - '--providers.docker=true'
      - '--providers.docker.network=proxy'
      - '--entrypoints.web.address=:80'
    environment:
      TZ: Europe/Brussels
    group_add:
      - 568
    hostname: proxy.homelab.arpa
    image: docker.io/library/traefik:v3
    networks:
      - proxy
    ports:
      - mode: ingress
        protocol: tcp
        published: 8080
        target: 80
      - mode: ingress
        protocol: tcp
        published: 8088
        target: 8080
      - mode: ingress
        protocol: tcp
        published: 8443
        target: 443
    pull_policy: always
    restart: always
    volumes:
      - type: bind
        source: /run/docker.sock
        target: /var/run/docker.sock

Before installation, I created the Docker bridge network for Traefik to communicate with other containers:

docker network create --driver=bridge proxy

I then attached the Traefik container to this network.
For simplicity, I’m currently running without TLS, so I enabled insecure API access and allowed Traefik’s Docker provider to automatically discover containers. The Docker socket is mounted as a bind volume, giving Traefik visibility into running containers.

Using pull_policy: always ensures the container automatically updates to the latest Traefik v3 image on restart.

Home Assistant

Below is an excerpt from the Home Assistant Docker Compose configuration:

networks:
  homeassistant:
    driver: bridge
  proxy:
    driver: bridge
    external: true

services:
  home-assistant:
    labels:
      - traefik.enable=true
      - traefik.http.routers.homeassistant.entrypoints=web
      - traefik.http.routers.homeassistant.rule=Host(`homeassistant.homelab.arpa`)
      - traefik.http.routers.homeassistant.service=homa-svc
      - traefik.http.services.homa-svc.loadbalancer.server.port=30103
    networks:
      - proxy
      - homeassistant

  postgres:
    ...
    networks:
      - homeassistant

I installed Home Assistant from the TrueNAS catalog and then converted it to a custom app (via the three-dot menu → Convert to custom app). This allowed me to edit its Docker Compose configuration directly, as shown above.

I attached the proxy network so Traefik could route traffic to the container, and created an additional homeassistant network for internal communication with the PostgreSQL database. This separation keeps database traffic isolated from the proxy network.

Next, I added Traefik labels to enable routing based on hostname.

However, after setting everything up, accessing the Home Assistant dashboard returned an HTTP 400 (Bad Request) error. The fix was documented here:
Home Assistant (400 Bad Request) Docker + Proxy – Solution

To resolve the issue, I updated Home Assistant’s configuration file located at
/mnt/.ix-apps/app_mounts/home-assistant/config/configuration.yaml:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - <Subnet of the proxy Docker network, e.g. 172.27.0.0/24 or Traefik’s IP>

After restarting the Home Assistant service, the dashboard loaded correctly.

Monitoring

With everything connected, I created a Home Assistant card to display the UPS status.
Here’s the YAML configuration for the dashboard card:

type: vertical-stack
title: Server Room Rack UPS
cards:
  - type: history-graph
    entities:
      - name: Status
        entity: sensor.rack_ups_1_status
    hours_to_show: 4
  - type: horizontal-stack
    cards:
      - type: gauge
        entity: sensor.rack_ups_1_load
        name: UPS Load
        severity:
          green: 0
          yellow: 70
          red: 90
      - type: gauge
        entity: sensor.rack_ups_1_battery_charge
        name: Battery Charge
        severity:
          green: 50
          yellow: 20
          red: 0

This dashboard displays the UPS status (e.g., on battery, charging, etc.), current battery level, and load percentage in real time.

Summary:
This setup provides a robust and self-contained NAS system with:

Fault-tolerant ZFS RAID-Z2 storage
Power-loss protection through UPS integration
Automated monitoring and alerting via Home Assistant
Flexible hostname-based routing through Traefik

It’s a powerful, reliable homelab configuration — and best of all, it’s completely under my control.

Install NUT on RaspberryPi with AlmaLinux

Miklos Halasz — Mon, 06 Oct 2025 20:18:57 +0000

I run one of my Raspberry Pi devices with AlmaLinux, installed on an external SSD connected through one of the USB 3 ports. This setup provides better performance and reliability compared to running from an SD card.

I followed Jeff Geerling’s guide to install the Network UPS Tools (NUT) server on the Pi to monitor my UPS. However, since AlmaLinux differs from Debian-based distributions, I needed to perform several additional steps to make everything work properly.

Tweak SELinux Flags

AlmaLinux enforces SELinux (Security-Enhanced Linux) by default, which provides a robust layer of system security. However, it also restricts services like httpd (installed automatically with nut-server) from performing certain network operations by default.

To allow the httpd service to connect to external ports, run:

sudo setsebool -P httpd_can_network_connect on

This permanently sets the SELinux boolean that enables outbound network connections for httpd.

Configure the Firewall

AlmaLinux uses firewalld with a default deny-all policy, meaning all incoming connections are blocked unless explicitly allowed.

By default, the NUT web interface (served by httpd) listens on port 8808, so this port must be opened in the firewall:

sudo firewall-cmd --permanent --add-port=8808/tcp --zone=public
sudo firewall-cmd --reload

After reloading, connections to port 8808/tcp will be permitted in the public zone.

Start the Driver

At this stage, the installation appeared to be successful — but the NUT server wouldn’t start. Checking the logs with journalctl revealed that the UPS driver hadn’t initialized.

I found a helpful Reddit thread explaining that the driver must start before the NUT server. That made sense, so I manually started the services in the correct order:

sudo upsdrvctl start
sudo systemctl start nut-server

And voilà — everything started working:

$ upsdrvctl status
Network UPS Tools upsdrvctl - UPS driver controller 2.8.3 release
UPSNAME              UPSDRV     RUNNING PF_PID  S_RESPONSIVE    S_PID   S_STATUS
office-ups       usbhid-ups     RUNNING 702     RESPONSIVE      702     "OL"

However — there’s always a “but.” 😄
After rebooting the Raspberry Pi, the services didn’t start automatically. Some additional configuration was needed to ensure the NUT driver and related services started on boot.

Enable Required Services on Boot

To ensure that the NUT driver and enumerator start automatically after a reboot, I enabled several related systemd services:

# Pull in NUT’s umbrella target (often required)
sudo systemctl enable --now nut.target

# Keep the looped enumerator running
sudo systemctl enable --now nut-driver-enumerator-daemon.service

# Optional but recommended: restart driver on ups.conf changes
sudo systemctl enable --now nut-driver-enumerator-daemon-activator.path

Additionally, I modified the nut-driver-enumerator-daemon.service unit file to delay startup until the network was fully online and to ensure it used a safe start delay for the UPS driver:

[Unit]
Requires=network-online.target
After=network-online.target

[Service]
ConditionPathExists=/etc/ups/ups.conf
ExecStart=
ExecStart=/usr/libexec/nut-driver-enumerator.sh --daemon-after=60

The --daemon-after=60 option ensures that the NUT driver starts 60 seconds after boot, giving the system and connected USB devices time to initialize properly.

After these adjustments, the NUT server started reliably on every boot, running cleanly and consistently.

Now my NAS and other connected systems are protected — if a power outage occurs, the NUT server communicates with the UPS and ensures all devices shut down gracefully.

Useful Links

Bridged Networking on Fedora Workstation for Virtual Machines

Miklos Halasz — Mon, 30 Jun 2025 09:42:17 +0000

When running virtual machines on Fedora Workstation, one common requirement is allowing them to communicate directly with your local network (LAN)—as if they were physical machines. The default NAT-based networking isolates them, which is fine for outbound traffic, but insufficient when inbound access or LAN integration is needed.

This post walks through setting up a Linux bridge interface using nmcli, explains what’s going on behind the scenes, and introduces key networking concepts like bridge slaves and virtual routing bridges (VRBs). If you're using KVM, QEMU, or libvirt for virtualization, this is essential knowledge.

Why I Needed a Bridge

I had VMs running on Fedora 42, and I wanted them to:

Get an IP address from my home DHCP server (like other devices on the LAN)
Be accessible via their own IP addresses from any other machine on the network
Act like any other physical device in the network

To achieve this, I needed bridged networking, which effectively connects the VM to the same Layer 2 network as the host’s physical Ethernet.

Configuration Steps

Here’s what I ran to set up the bridge using nmcli:

nmcli connection delete localan
nmcli con add ifname br0 type bridge autoconnect yes con-name br0 ipv4.method auto
nmcli con add type bridge-slave autoconnect yes con-name br-slave-eno1 ifname eno1 master br0
nmcli connection up br0

These steps:

Delete the old connection managing the physical interface (eno1)
Create a new bridge interface named br0
Attach eno1 to the bridge as a slave
Bring up the bridge

Once complete, I configured my virtual machines to use br0 as their network interface.

Why Was the Existing Connection Deleted?

The default profile (localan) was already managing eno1. NetworkManager does not allow a device to be controlled by multiple profiles simultaneously. Before you can enslave a physical interface to a bridge, it must be released from any existing configuration.

This is a critical step. Without removing the existing connection, adding eno1 to the bridge would fail.

What Is a Bridge Interface?

A bridge interface acts like a virtual switch at Layer 2 (Data Link Layer). It connects multiple network interfaces and forwards Ethernet frames between them.

In this setup:

br0 acts like a virtual switch.
The physical NIC (eno1) is a port on that switch.
Virtual machines are plugged into the same switch, gaining full LAN access.

The bridge itself is the only interface that receives an IP address. The physical NIC becomes a passive conduit—passing traffic between the bridge and the network.

What Does "Controller Waiting for Ports" Mean?

When activating the bridge, NetworkManager returned:

$ nmcli connection up br0
Connection successfully activated (controller waiting for ports) (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/25)

This message means that br0 is active but waiting for its slave interfaces (like eno1) to become fully ready—i.e., for link negotiation to complete. It’s typically harmless and resolves within seconds.

What Are Bridge Slaves and Why Are They Needed?

Any device added to a bridge is called a slave. Slaves pass data to and from the bridge but no longer operate independently.

In our case, eno1 became a bridge slave of br0. This means:

It no longer gets its own IP address.
It merely passes packets between the bridge and the physical network.
All IP configuration is now handled by the bridge (br0).

This setup allows your virtual machines, which are also connected to the bridge, to be treated like independent physical devices on the network.

Why a Bridge Is Needed for VM LAN Access

By default, virtualization platforms like libvirt configure VMs with NAT-based networking. This allows VMs to access the internet but keeps them isolated from the LAN.

To make a VM accessible from other devices on your network—via ping, SSH, or services—you need a bridge. It gives the VM a direct Layer 2 path to the LAN, enabling:

IP address assignment from the LAN’s DHCP server
Direct access to and from any device on the LAN

What’s Happening Behind the Scenes?

Here’s a high-level overview:

Bridge creation (br0) defines a virtual switch.
Physical NIC (eno1) is enslaved to br0, losing its own IP.
Bridge gets an IP address and becomes the primary network device.
VMs are connected to br0, making them peers on the LAN.

Linux handles the bridging logic via kernel modules. NetworkManager coordinates the configuration, making nmcli a powerful and reliable tool for managing this setup.

A Quick Word on Virtual Routing Bridges (VRB)

A Virtual Routing Bridge (VRB) is a more advanced networking concept used in cloud or SDN environments. Unlike a standard bridge that only operates at Layer 2, a VRB combines Layer 2 bridging with Layer 3 routing.

This means a VRB can:

Route between VLANs or subnets
Apply policies and firewall rules
Act as both a switch and a router

VRBs are used in complex setups like OpenStack or Kubernetes CNI plugins. For most homelab or desktop VM scenarios, a standard Linux bridge is simpler, faster, and entirely sufficient.

Conclusion

Setting up bridged networking on Fedora using nmcli is a clean and efficient way to allow VMs to function as full citizens of your LAN. Once configured, it just works—and avoids the limitations of NAT-based networking.

Whether you're running development servers, containers, or full VM stacks, understanding Linux bridges is essential knowledge for any modern Linux user managing a virtualized environment.

Terraform: Infrastructure as Code or Just a Fancy Wrapper?

Miklos Halasz — Sun, 29 Jun 2025 08:59:24 +0000

I developed a healthy skepticism for tools that claim to make life easier by abstracting "complexity". Terraform is one of those tools.

It’s become something of a standard in the DevOps world. And I get why—it’s clean, declarative, and integrates well into GitOps and CI/CD workflows. It tracks state, it has a vibrant ecosystem of modules, and it supports everything from AWS to VMware to local libvirt. But despite its power, Terraform isn’t magic. In fact, it’s often just a more elegant wrapper around the APIs and CLI tools I was already using.

Let’s talk about what Terraform does well, and more importantly, where the abstraction leaks.

A Unified Language—But Not Really

One of the biggest marketing points behind Terraform is its "unified language" for infrastructure. You're told you can write a VM definition once and simply switch providers—from local libvirt to AWS or GCP—without changing much.

But here's the reality: you will change almost everything.

The configuration syntax may be consistent in terms of how blocks and attributes are defined, but the actual resource models between providers are completely different. For a virtual machine, AWS expects an AMI ID and an instance type. Libvirt wants memory and CPU counts and a reference to a QCOW2 image. That’s not a minor difference. It’s a complete redefinition of what a "machine" even is.

In practice, you don’t get portability. You get familiarity with the tooling syntax, but you still have to learn every provider's API model. At that point, are you really gaining anything over just writing some shell scripts for virsh or awscli, especially if you're only using one platform anyway?

The Wrapper Dilemma

Terraform doesn’t manage infrastructure by itself. It's just a structured way to call the APIs of your underlying tools. Whether that’s the AWS EC2 API, the Proxmox REST interface, or the local libvirt sockets, it depends on "providers"—which are essentially plugins maintained by HashiCorp or the community.

That dependency chain introduces friction. If Proxmox changes something in its API and the provider hasn't caught up yet, you’re stuck. You either wait for a fix or fork the provider yourself. It could be frustrating when you're blocked from using a feature that is technically available, just not exposed yet in Terraform.

With traditional shell scripts, you’d just call the new feature directly. It may be ugly, but it works now. That immediacy is something that I miss when relying on Terraform.

Easier Than Bash, Until It’s Not

I’ll be honest: writing infrastructure logic in HCL (HashiCorp Configuration Language) is much more pleasant than hacking away at brittle Bash scripts with a million conditionals and jq parsers. Terraform gives you a structured, declarative way to define your environment. That’s a win.

But that only goes so far. The moment you need to express logic Terraform doesn't support natively—loops beyond what for_each or count can handle, or conditional resources that depend on multiple variables—you end up writing external tooling anyway. That’s when the clean declarative abstraction starts to feel a lot like YAML with lipstick.

State Management: A Blessing and a Curse

One of Terraform’s key strengths is that it tracks the state of your infrastructure. It knows what you created, what changed, and what needs to be destroyed. This makes terraform plan and terraform apply very powerful, especially when you're working in teams.

But that state file is also a liability. Lose it, and you're flying blind. Mismanage it, and you can destroy production resources. Using remote backends like S3 or Git backends helps, but the whole concept of syncing and locking state adds a layer of fragility that simply doesn't exist when you're managing things manually.

When Terraform Works Best

Despite my criticisms, I do use Terraform. It shines in environments where infrastructure is complex, distributed, and managed by teams. It’s excellent when used to define cloud resources, manage networking, integrate with CI pipelines, and implement GitOps workflows. The repeatability and visibility into planned changes are things no ad-hoc shell script can give you cleanly.

If you’re spinning up identical environments across dev, staging, and production, Terraform’s modules and workspaces are a godsend. And if your team spans different roles (devs, ops, SREs), the shared syntax helps build common ground.

Final Thoughts

Terraform is a powerful tool, but it’s not the abstraction layer it’s often sold as. It doesn’t free you from learning your infrastructure platform—in fact, it requires that you know the platform well enough to map its concepts into Terraform’s provider model.

It's not a silver bullet. It's an elegant tool for automating and tracking infrastructure, especially in cloud-native environments. But for someone like me, who grew up close to the bare metal and still sees the value in understanding what’s under the hood, Terraform is best thought of as a structured wrapper with lifecycle management—not a replacement for knowing how things work.

Use it when it fits, but don’t be afraid to reach for virsh, awscli, or even plain Bash when you need control Terraform doesn’t yet expose.

Jakarta validation annotations on the wrong place

Miklos Halasz — Fri, 13 Jun 2025 18:37:48 +0000

During work on my current project I tried to find the optimal solution how to validate the arguments of some service level methods. I don't want to write every time an if clause for nullcheck or add additional validation logic, for example ensure a numeric value not to be less then 0.

I added jakarta.validation annotations as you can see below, but first on the implementations of the functions. During the build this error was thrown:

HV000151: A method overriding another method must not redefine the parameter constraint configuration ...

This occurs when you define validation annotations on a method parameter that overrides a method from an interface or superclass that already has validation constraints. Jakarta Bean Validation enforces constraints defined by interfaces or base classes and does not allow the redefinition of constraints on overridden methods.

Why does this happen?

Bean Validation requires consistency in method-level constraints between interfaces (or parent classes) and their implementations. If your interface method parameters have no constraints, your implementation methods cannot introduce them. If the interface method parameters have constraints, your implementation must match them exactly.

How to fix it:

You have a couple of choices:

1. Move constraints to the interface (recommended):
Define your validation annotations directly in the interface.

public interface MyService {
    void performAction(@NotNull String input);
}

public class MyServiceImpl implements MyService {
    @Override
    public void performAction(String input) {
        // Implementation code
    }
}

This clearly defines constraints at the interface level and ensures all implementations have consistent constraints.

2. Use constraints only in the implementation class:
If your interface doesn't specify constraints, and you still want constraints in your implementation, you should avoid parameter constraints on overridden methods. Instead, you can use field-level validation or manually validate parameters within the method body.

Example using manual validation:

public class MyServiceImpl implements MyService {
    @Override
    public void performAction(String input) {
        if (input == null) {
            throw new IllegalArgumentException("input must not be null");
        }
        // Implementation code
    }
}

Alternatively, move constraints to fields or separate objects.

3. Separate constraints into DTOs or dedicated validated objects:
This is a robust, widely used approach.

public interface MyService {
    void performAction(ActionRequest request);
}

public class ActionRequest {
    @NotNull
    private String input;

    // getters, setters
}

public class MyServiceImpl implements MyService {
    @Override
    public void performAction(@Valid ActionRequest request) {
        // Implementation
    }
}

This approach clearly separates concerns and validation logic into dedicated classes, avoiding the original issue.

Recommended Best Practice:

Usually, constraints belong clearly at the interface or domain model level, or within DTOs/request objects. Defining constraints in interfaces or separate request objects ensures clear, reusable, and maintainable validation logic.

Summary of the best solution:

Define constraints in interfaces if they logically apply to all implementations.
Use DTO/request classes with annotations if constraints vary or if method signatures should remain clean.
Avoid redefining constraints at the implementation method directly.

This will effectively resolve the error and ensure a clear, maintainable validation strategy.

10 Real-World DevOps Team Lead Scenarios and How to Master Them

Miklos Halasz — Fri, 13 Jun 2025 18:32:38 +0000

As part of my journey into leadership in the DevOps space, I recently walked through ten common but complex scenarios that a DevOps Team Lead might face.

Note: These scenarios were generated by ChatGPT at my request as part of preparing for a DevOps Team Lead interview. The answers and strategies are entirely my own, reflecting how I would handle each situation.

1. Junior Engineers Relying Too Much on Seniors

Challenge: Two junior engineers were constantly blocking senior engineers with minor requests.

Approach: I initiated 1:1s to understand their blockers and assess if the tasks assigned to them matched their current skill level. I discovered they often lacked confidence or context. To balance support and senior focus time, I introduced scheduled daily sync slots for juniors to raise their questions in batches. I also encouraged them to maintain a simple 'engineering diary' to document recurring issues and solutions. Over time, these diaries would evolve into lightweight internal documentation. For the long term, I planned structured mentoring sessions and a gradual introduction of pair programming to accelerate their learning.

2. A Team Bypasses CI/CD for Direct Production Pushes

Challenge: A backend team was deploying directly to production, ignoring DevOps pipelines.

Approach: I set up a conversation with their lead developers to understand their reasoning. It turned out their perception of our pipeline was that it was slow and overly rigid. I took their feedback seriously and initiated a performance audit on our CI/CD system. We made targeted improvements — including caching, parallel steps, and clearer logging — and communicated those changes back. I also held a knowledge-sharing session to explain the purpose of each stage in the pipeline, showing how it protects quality and security. When necessary, I escalated recurring issues to leadership, framing it as a risk management concern, not a power struggle.

3. Handling an Outage and a Critical Security CVE Simultaneously

Challenge: An outage occurred while a critical container CVE was discovered.

Approach: I triaged the issues by impact — production outages take precedence. I assembled an incident response team and assigned clear roles: incident commander, communications lead, and engineers on fix duty. I shielded the team from non-essential noise and kept leadership updated at regular intervals. Meanwhile, I scoped the CVE’s risk profile: Was it actively exploitable? What environments were affected? I documented its severity and began drafting a patching plan. Once the outage was resolved and we had breathing room, we immediately prioritized the CVE, patched it across all environments, and updated our base images and image scanning automation to catch similar issues earlier.

4. Breaking Down Silos in a Disconnected DevOps Team

Challenge: A siloed DevOps team with tribal knowledge and no documentation.

Approach: I started by holding 1:1 meetings with each team member to understand their roles, tools they maintained, and workflows they followed. I asked everyone to start logging their daily tasks and edge cases into a shared internal wiki. Then, I introduced biweekly "Knowledge Share Days," where engineers gave 10-15 minute walkthroughs of tools, configs, or lessons learned. To reinforce the behavior, I tied documentation and internal knowledge sharing to team OKRs. Over time, this shifted the team from isolated individuals to a learning-oriented, cross-skilled unit.

5. A Brilliant Engineer with Poor Team Behavior

Challenge: A senior engineer was dismissive and critical, affecting team morale.

Approach: I had a candid 1:1 to explore the source of their frustration. I found they felt overburdened and underappreciated. I acknowledged their technical value but also explained clearly how their communication style was damaging junior growth and team trust. I encouraged them to take on a mentorship role — not as extra work, but as a chance to shape our engineering culture. I supported them in improving soft skills through informal coaching and clear feedback. If they had continued being disruptive, I had a plan to escalate with HR and formalize a behavior improvement plan.

6. Convincing Leadership to Adopt a New Build Tool

Challenge: Engineering wanted to migrate pipelines to a new build tool, but product leadership was hesitant.

Approach: I proposed running a proof of concept (PoC) on an internal tool that wasn’t customer-facing. I collaborated with a willing dev lead to migrate the project, documented every step, captured pain points, and measured build performance before and after. I also recorded developer feedback on clarity, speed, and ease of use. Using this evidence, I created a pitch deck that compared the current and proposed tools, showed the migration playbook, and presented a phased rollout plan. I highlighted risk mitigation, dev velocity improvements, and long-term maintenance savings to product leadership.

7. Enabling Developer Self-Service at Scale

Challenge: Reduce DevOps bottlenecks by empowering devs with self-service tooling.

Approach: I started by identifying key personas who would use the platform: backend devs, QA, data engineers. I conducted workflow mapping sessions and internal surveys to uncover repetitive or ticket-based requests — provisioning environments, triggering builds, creating dashboards. We prioritized quick wins and built an MVP using Backstage, backed by Terraform automation and GitOps where possible. I documented the entire workflow, published how-to guides, and measured impact with KPIs like time-to-onboard and support ticket volume. Developer feedback loops helped shape future iterations and ensured the tools were truly enabling.

8. Explaining DevOps to Non-Technical Stakeholders

Challenge: Communicating DevOps value to execs and PMs.

Approach: I framed DevOps not as a toolset, but as a culture and capability — a way of enabling product delivery by aligning dev, ops, and security. I kept technical jargon to a minimum and focused on how DevOps improves release reliability, lead time, and resilience. I used real numbers — deployments per week, MTTR, incidents avoided — and tied them to business outcomes: faster time-to-market, fewer outages, more secure products. I presented our roadmap in terms of impact, not implementation, and encouraged questions so stakeholders felt included and informed.

9. Integrating Security Without Slowing Down Developers

Challenge: Security tools were slowing down CI/CD pipelines.

Approach: I first audited our existing tooling and classified it by complexity and runtime cost. I proposed a tiered model: run SAST and dependency checks on every PR, nightly DAST and container scans on the dev branch, and deeper compliance scans before release. I reviewed the feedback from developers and iterated to improve speed and false positive handling. I emphasized security as part of quality — a shared responsibility, not overhead. I tracked and reported on the number of critical issues caught early and improved scan completion rates as KPIs.

10. Building and Sustaining a High-Performing DevOps Team

Challenge: Defining what makes a DevOps team truly high-performing.

Approach: A high-performing DevOps team acts as a platform enabler, not a ticket resolver. It drives automation, champions best practices, and acts as a multiplier for engineering throughput. I look for signs like high deployment frequency, fast MTTR, strong documentation, and visible team ownership. To sustain performance, I prioritize onboarding, mentorship, internal docs, and setting clear expectations. I track burnout risk, encourage retrospectives, and rotate responsibilities to prevent silos. My goal is a team that’s curious, collaborative, and always evolving — one that grows capability, not just velocity.

Final Thoughts

Leading a DevOps team isn’t just about tools — it’s about people, empathy, systems thinking, and cross-functional communication. These scenarios reflect how I think through challenges, advocate for the team, and align technical goals with organizational strategy.

If you’re on the path to leadership or already there, I hope these reflections help you level up your own approach.

Aspect Oriented Programming in JAVA

Miklos Halasz — Wed, 11 Jun 2025 07:57:03 +0000

Today, I explored Aspect-Oriented Programming (AOP), particularly its application within a Spring Boot context for handling cross-cutting concerns. Initially, I described a use-case from my Spring Boot application, where various operations — like changing job properties, uploading attachments, or deleting resources — trigger events that should be audited and logged consistently. My goal was to find patterns for handling these events effectively.

One of the first term that I met and needed some clarification was the cross-cutting concerns. It refers to common functionalities repeated across various layers or modules of an application, such as logging, auditing, transaction management, and security checks. The essential benefit of AOP is to encapsulate these repetitive tasks in one place and then apply them wherever necessary, keeping the main business logic clean.

After that I had an "AHAaa" moment about Spring Boot:

"Spring Boot with annotation-based configuration is essentially a combination of annotations and AOP."

And indeed. Spring Boot heavily relies on declarative programming using annotations (e.g., @Service, @Autowired, @Transactional) to manage cross-cutting concerns seamlessly. This declarative, annotation-driven paradigm is a significant aspect of Spring’s philosophy.

To illustrate how to practically apply these concepts, I decided to build a simple audit logging system leveraging custom annotations and AOP. I created an entity named AuditLog for logging audit information, structured as follows:

@Entity
public class AuditLog {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;
    private String action;
    private LocalDateTime timestamp;

    @Column(length = 2000)
    private String details;

    // Constructors, getters, setters omitted for brevity
}

This entity stores basic details like the user responsible for the action, the type of action, the timestamp, and additional information (e.g., method parameters).

Next, I introduced a Spring Data JPA repository for persisting these logs:

public interface AuditLogRepository extends JpaRepository<AuditLog, Long> {
}

To easily trigger audit logs from specific methods, I created a custom annotation named @Auditable:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Auditable {
    String action();
}

The core of my AOP-based logging system is the AuditAspect class, defined as follows:

@Aspect
@Component
public class AuditAspect {

    private final AuditLogRepository auditLogRepository;

    public AuditAspect(AuditLogRepository auditLogRepository) {
        this.auditLogRepository = auditLogRepository;
    }

    @AfterReturning(pointcut = "@annotation(auditable)", returning = "result")
    public void logAudit(JoinPoint joinPoint, Auditable auditable, Object result) {
        String username = getCurrentUser(); // placeholder for real user retrieval logic
        String action = auditable.action();
        String details = Arrays.stream(joinPoint.getArgs())
                .map(arg -> arg != null ? arg.toString() : "null")
                .collect(Collectors.joining(", "));

        AuditLog log = new AuditLog();
        log.setUsername(username);
        log.setAction(action);
        log.setTimestamp(LocalDateTime.now());
        log.setDetails(details);

        auditLogRepository.save(log);
    }

    private String getCurrentUser() {
        return "system"; // replace later with integration like Spring Security
    }
}

Here, I leveraged Spring AOP's @AfterReturning advice, which executes after the successful completion of the annotated method. This approach conveniently provides access to the method's return value (result). For instance, annotating methods with @Auditable automatically generates audit entries whenever the methods run successfully.

An example usage in a business service looks like this:

@Service
public class JobService {

    @Auditable(action = "Updated job property")
    public void updateJob(Job job) {
        // business logic
    }

    @Auditable(action = "Uploaded attachment")
    public void uploadAttachment(Long jobId, MultipartFile file) {
        // business logic
    }
}

Through this setup, audit logging becomes clean, consistent, and easily maintainable.

Later, I sought deeper insights into the mechanics of Spring AOP annotations. Besides @AfterReturning, I learned other essential annotations:

@Before: Executes before the method runs.
@AfterThrowing: Executes if the method throws an exception.
@After: Executes after method execution, regardless of the outcome.
@Around: Provides complete control, allowing me to manipulate method arguments, return values, or even bypass method execution entirely.

Moreover, the JoinPoint object provided by Spring AOP contains metadata about the current execution point, including the method name, parameters, target object, and the context where the aspect is triggered.

For example, a simple logging aspect using a JoinPoint could look like:

@Before("execution(* com.example.service.*.*(..))")
public void logBeforeMethod(JoinPoint joinPoint) {
    System.out.println("Calling method: " + joinPoint.getSignature().getName());
    System.out.println("Arguments: " + Arrays.toString(joinPoint.getArgs()));
}

Thus, Spring AOP elegantly facilitates handling cross-cutting concerns declaratively and transparently.

In summary, today's exploration reinforced the understanding that:

Cross-cutting concerns represent repeated functionalities across the system, ideally abstracted out.
Aspect-Oriented Programming neatly addresses these concerns.
Spring Boot extensively utilizes annotation-driven AOP, making development declarative, readable, and maintainable.

Finally, I noted that a well-designed audit logging system in Spring Boot can significantly benefit from AOP’s flexibility, readability, and simplicity.

Remote access with RustDesk

Miklos Halasz — Fri, 25 Apr 2025 17:56:36 +0000

Recently I traveled abroad and need a solution to use my workstation. I tried the RustDesk remote desktop. It needs a self-hosted server if you don't want to use their cloud solution and yet I don't want to :) So after I created a virtual machine on my Proxmox host with the official suggested hardware capabilities and installed an OS (AlmaLinux), I went through the following steps described below:

Create user for running the server

I made a group and user named rustdesk on that system and created the /home/rustdesk/.config/containers/systemd/ path because I wanted to run the server containerized with Podman handled by Systemd.

groupadd --gid 990 --system rustdesk
useradd --system --create-home --gid 990 rustdesk
sudo -u rustdesk mkdir -p /home/rustdesk/.config/containers/systemd/

Because the server have to be start at boot I enabled lingering for the rustdesk user so in this way it doesn't need an active session.

loginctl enable-linger rustdesk

Configure firewall

Based on the official documentation RustDesk needs a couple port to communicate with clients. I created a service named rustdesk and add ports to it. Later assign the newly created service to the public zone.

firewall-cmd --permanent --new-service=rustdesk
firewall-cmd --permanent --service=rustdesk --set-description='Ports which are necessary to operate with rustdesk'
firewall-cmd --permanent --service=rustdesk --add-port=21115/tcp
firewall-cmd --permanent --service=rustdesk --add-port=21116/tcp
firewall-cmd --permanent --service=rustdesk --add-port=21116/udp
firewall-cmd --permanent --service=rustdesk --add-port=21118/tcp
firewall-cmd --permanent --service=rustdesk --add-port=21117/tcp
firewall-cmd --permanent --service=rustdesk --add-port=21119/tcp
firewall-cmd --permanent --zone=public --add-service=rustdesk
firewall-cmd --reload

Check the firewall configuration

If you want to check the completed settings you can list the services assigned to the public zone and list the opened ports of the service.

firewall-cmd --zone=public --list-services
firewall-cmd --service=rustdesk --get-ports

Create systemd resources

Podman has a great integration with systemd. You can create and configure containers, volumes and networking. I did not mind the networking in this configuration, but I wanted to persist the /root folder as the official documentation suggested. Because I only needed a simple volume I just created the rustdesk-hbbs.volume and rustdesk-hbbr.volume files under the /home/rustdesk/.config/containers/systemd/ with the following content:

[Volume]

Based on the configuration above the tool Quadlet - that installed alongside Podman - creates the appropriate systemd configurations and the end of the process a podman volume creates on the machine.

In the next step I created the configuration for the server containers. It's like n ordinary systemd service file, but it has an extra section named [Container]. The possible configurations are described here: podman-systemd.unit (5). You can notice I used the standard Restart parameter under the [Service] section to configure when should the container restarts. You can find more information about the configurations here: systemd.service

`hbbs.container`

[Unit]
Description=Rustdesk HBBS cotnainer
After=local-fs.target

[Container]
AutoUpdate=registry
Image=ghcr.io/rustdesk/rustdesk-server:latest
ContainerName=hbbs
PublishPort=21115:21115
PublishPort=21116:21116
PublishPort=21116:21116/udp
PublishPort=21118:21118
Volume=rustdesk-hbbs.volume:/root
Exec=hbbs

[Service]
Restart=on-failure

[Install]
WantedBy=multi-user.target default.target

`hbbr.container`

[Unit]
Description=Rustdesk HBBR cotnainer
After=local-fs.target

[Container]
AutoUpdate=registry
Image=ghcr.io/rustdesk/rustdesk-server:latest
ContainerName=hbbr
PublishPort=21117:21117
PublishPort=21119:21119
Volume=rustdesk-hbbr.volume:/root
Exec=hbbr

[Service]
Restart=on-failure

[Install]
WantedBy=multi-user.target default.target

Start the application

I struggled to start application and but found the following post on StackOverflow:

systemd 248 (released March 2021) introduced support for the syntax -M myuser@ for specifying another user.
sudo systemctl --user -M myuser@ start ap@inst1
A side-note: If you want to get an interactive login shell for the user myuser
sudo machinectl shell myuser@

On my fresh installed AlmaLinux Podman complained about only few user namespaces were allowed, so I increased the number of the namespaces, and enabled IP forwarding for the containers. I edited directly the /etc/sysctl.conf file, and add / changed the following properties

net.ipv4.ip_forward = 1
user.max_user_namespaces = 15000

After that I reloaded the settings and started the services in the name of the user rustdesk.

systemctl --user -M rustdesk@ daemon-reload
systemctl --user -M rustdesk@ start hbbs.service
systemctl --user -M rustdesk@ start hbbr.service

Configure the clients

In the settings menu of the application use the hostname or IP address of the RustDesk service. For the ID Server use the 21116 port and for the Relay server the 21117 port. During the startup the HBBS service generate a keypair, and in the Key field I inserted the content of the public key. It can be found under the path /home/rustdesk/.local/share/containers/storage/volumes/systemd-rustdesk-hbbs/_data/id_ed25519.pub

Additional Technical Notes:

User Namespaces and Networking: I had to increase the maximum allowed user namespaces on my system. This is necessary for containers to run securely with their own isolated environments. If you’re not familiar with namespaces, they essentially provide a layer of isolation between processes, which is crucial for container security.
Podman Networking: While I didn’t configure custom networking in this setup, it's an important aspect of containerized applications. You might want to define a specific network for your containers if you need them to communicate with other systems outside the host.

Furter readings

Generate JAVA code from OpenAPI specification

Miklos Halasz — Tue, 15 Apr 2025 14:46:23 +0000

Recently, I started a project and I chose Gradle as the build tool. In this project, I had to integrate with an external service that has an API documented in OpenAPI format. So, first of all, I had to import the OpenAPI Generator plugin into my project.

Import `Generator` plugin

plugins {
    id("java-library")
    id("org.openapi.generator") version "7.12.0"
}

Plugin configuration

After importing the plugin, some configuration was needed.

openApiGenerate {
    generatorName.set("spring")
    inputSpec.set("$projectDir/src/main/resources/openapi/center-api-v1.yaml")    
    outputDir.set("${layout.buildDirectory.get()}/generated")
    validateSpec.set(true)

    modelPackage.set("com.example.my-project.model")
    generateModelDocumentation.set(false)

    configOptions.set(
        mapOf(
            "dateLibrary" to "java8",
            "useJakartaEE" to "true",
            "useRuntimeException" to "true",
            "useSpringBoot3" to "true",
        )
    )
}

I set the generator to spring. The generatorName setting controls what kind of code gets generated based on the OpenAPI spec — essentially, it determines the language and framework you're targeting. This setting influences the structure of the generated code, its dependencies, annotations and libraries it uses.
With inputSpec I specified the absolute path of the OpenAPI configuration.
outputDir property tells openapi-generator where to the generated code.
I wanted to ensure the OpenAPI specification is valid, so I set validateSpec to true.
With the modelPackage property, I specified where the tool should place the generated model classes. I didn't specify the apiPackage property, because I only needed the DTOs.
Through the configOptions you can set many additional properties. Here's a breakdown of what I used:
- dateLibrary set to java8 tells the generator tool to use LocalDate and LocalDateTime to store temporal data.
- useJakartaEEset to true ensures the generated code uses the jakarta.* namespace instead of javax.*.
- useRuntimeException set to true instructs the generator to use unchecked exceptions in the generated code.
- useSpringBoot3 set to true is a essential because I used SpringBoot 3.x in this project. Spring Boot 3 dropped support for the old javax.* namespace in favor of jakarta.* (a change introduced with Jakarta EE 9+). Without this flag, the generated code might use outdated annotations and could fail to compile. Additionally, it adjusts dependencies and code structure to align with Spring Boot 3 requirements, making the generated code ready to use out of the box.

Further tweaks

I configured the compileJava task to automatically run the openApiGenerate task. This way, running the build task will generate appropriate JAVA from the OpenAPI specification every time.

tasks.named<JavaCompile>("compileJava") {
    dependsOn(tasks.named("openApiGenerate"))
}

Last, but not least, I had to configure the source sets. Without this configuration, the generated code would be outside of the compiler's scope. The following code snippet adds the directory containing the generated code to put the project's sources.

sourceSets {
    main {
        java {
            srcDir("${layout.buildDirectory.get()}/generated/src/main/java")
        }
    }
}

List `sourceSets`

This snippet is just a helpful trick. If you're relatively new to Gralde - like I am - and want to check what's in the sourceSets after applying the above settings, you can use the following snippet:

tasks.register("printSourceSetInfo", DefaultTask::class) {
    // Get the names and source directories at configuration time
    val sourceSetInfo = (project.extensions.getByName("sourceSets") as SourceSetContainer)
        .associate { sourceSet ->
            sourceSet.name to sourceSet.allSource.srcDirs.map(File::getAbsolutePath)
        }

    doLast {
        sourceSetInfo.forEach { (name, srcDirs) ->
            println("SourceSet: $name")
            srcDirs.forEach { dir ->
                println("  -> $dir")
            }
        }
    }
}

This registers a task named printSourceSetInfo, fetches information about the current sourceSets, and prints each set's name along with its associated source directories.

Resources:

How to configure OpenID authentication in Proxmox VE

Miklos Halasz — Wed, 09 Apr 2025 09:56:02 +0000

In my homelab, I installed Keycloak because I thought it would be fun to use SSO login for all my locally installed services.

I'm using Proxmox VE as my hypervisor platform, and it also offers the option to use an OpenID provider—in my case, Keycloak. The settings are fairly straightforward, but I ran into a few pitfalls. Let me describe those first:

Check the CA certificates

I use a self-signed CA to create TLS key pairs for my local services. The CA must be installed on both the Keycloak server and the Proxmox nodes. Until I configured the CA correctly, I kept getting a mysterious HTTP 500 error in the Proxmox UI when I wanted to use the OIDC login option, and there were no useful logs in either Proxmox or Keycloak.

Install CA on AlmaLinux

Keycloak is installed on AlmaLinux in my homelab. I copied the CA chain into /etc/pki/ca-trust/source/anchors/ and ran the update-ca-trust command as root.

Install CA on Debian

Proxmox VE is based on Debian. It stores trusted CA certificates in the /usr/share/ca-certificates/ directory. I copied my CA file there and ran the update-ca-certificates command.

Initially, I used a .pem file, but it wasn't recognized until I renamed it to .crt.

Use the correct issuer URL

In many tutorials people suggest use the following URL: https://auth.arpa/auth/realms/<realm-name> but the Keycloak dropped the auth/ part out of the URL around the beginning of 2023. So the correct URL is: https://auth.arpa/realms/<realm-name>

Proxmox Forum

Keycloak configuration

In Keycloak I created a Realm that connects to an Active Directory server. Then I configured a Client for the Proxmox. I didn't provided any description about the properties that I set because the Keycloak UI have some nice description for every of them.

1. Create a new realm

In the Keycloak UI in the left side there's the realm selector. If you click on the dropdown the Create realm button appears. Click on it!

Then specify the Realm name and click on the create button:

Ensure the newly created realm is selected.

2. Setup ActiveDirectory as provider

On the navigation bar on the left side click on the User federation and click on Add LDAP providers.

These are the settings that I specified:

General options
- UI display name: Choose a name that you like
- Vendor: Should be Active Directory
Connection and authentication settings
- Connection URL: IP address of the Active Directory. Don't forget to add the protocol (ldap:// or ldaps://).
- Bind type: simple
- Bind DN: The DN of the user that Keycloak can use to run queries in AD
- Bind credentials: password of the bind user
LDAP searching and updating
- Edit mode: READ_ONLY
- Users DN: the distinguished name of the org. unit where the users are stored. E.g.: OU=Users,DC=homelab,DC=be,DC=local
- Username LDAP attribute: sAMAccountName
- RDN LDAP attribute: cn
- UUID LDAP attribute: objectGUID
- User object classes: person, organizationalPerson, user

I left the other settings on their default values.

3. Create a client for Proxmox

Select the Clients option from the menu sidebar, and click on the Create client button;

General settings
- Client type: OpenID Connect
- Cliend ID: Choose an ID for the client. You can reference the client later from proxmox with this ID.
Capability config:
- Client authentication: turn on
- Authorization: turn on
Login settings:
- Root URL: https://proxmox.homelab.arpa:8006/
- Home URL: https://proxmox.homelab.arpa:8006/
- Valid redirect URIs: https://proxmox.homelab.arpa:8006/*
- Web origins: *

And click on the Save button.

Official documentation

Proxmox configuration

Create new realm

To create a new real in Proxmox I used the pveum command.

pveum realm add keycloak \
    --type openid \
    --issuer-url  https://auth.homelab.arpa/realms/active-directory \
    --client-id XXXX \
    --client-key YYYY \
    --username-claim username
    --autocreate 1

I turned on the autocreate property because Proxmox needs users that exists in its own database. And after the login the users created automatically based on the provided information by Keycloak and you don't have to create them manually

More about proxmox user management

Grant permissions

Create a group for the administrators

pveum group add admin -comment "System Administrators"

Grant administrator privileges for the group

pveum acl modify / -group admin -role PVEAdmin

Add the users from the newly created OpenID realm to the group

pveum user modify jhon.doe@keycloak -group admin

Validate, check user permissions

pveum user permissions john.doe@keycloak

How to build containerized JAVA application

Miklos Halasz — Tue, 08 Apr 2025 13:01:18 +0000

Take this multi-stage Dockerfile:

FROM eclipse-temurin:21-jdk-ubi9-minimal AS builder

ARG APP_VERSION
WORKDIR /application/

COPY build/libs/app-${APP_VERSION}.jar app.jar

RUN java -Djarmode=tools -jar app.jar extract --layers --launcher

################
FROM eclipse-temurin:21.0.6_7-jre-ubi9-minimal

WORKDIR /opt/app/

ENV TZ=Europe/Budapest

COPY --from=builder /application/app/dependencies/          ./
COPY --from=builder /application/app/snapshot-dependencies/ ./
COPY --from=builder /application/app/spring-boot-loader/    ./
COPY --from=builder /application/app/application            ./

ENTRYPOINT exec java ${JAVA_OPTS} org.springframework.boot.loader.launch.JarLauncher

With this Dockerfile, you can build reproducible container images. It's layered, which means that if you change only the application code, the layers containing the dependencies remain untouched. This saves both space in the image registry and network bandwidth.

The builder stage uses JDK 21 as the base image and copies the fat (or uber) JAR from the host machine's filesystem, where it was previously built. We use the extract command in this stage to explode the JAR into separate folders. These folders are then copied into the second stage, with one COPY command per folder—ensuring each set of files goes into its own layer.

The second stage uses only the JRE as a base, since we just need the runtime environment to launch the application.

To run the application, I defined the ENTRYPOINT instruction. I used the exec form to ensure the Java process runs as PID 1 inside the container. This is important because, if you wrap the command in a shell script, the script would be PID 1 instead, and when the container is stopped, the shell might not properly forward termination signals to your application—causing the app to shut down abruptly. That can lead to data loss and other issues. See explanation on StackOverflow

My spellchecker complained that I wasn’t using the JSON array syntax for ENTRYPOINT, like this:

ENTRYPOINT ["exec", "java", "${JAVA_OPTS}", "org.springframework.boot.loader.launch.JarLauncher"]

However, if I used this form, it would fail. In the JSON array form, the ${JAVA_OPTS} variable is not resolved—it is passed literally. The result would be:

exec java ${JAVA_OPTS} org.springframework.boot.loader.launch.JarLauncher

Which is not what we want.

Forem: Miklos Halasz

Why My Laptop Drained Overnight While Docked (and How a GRUB Change Fixed It)

The actual problem

The solution: disabling USB autosuspend

Where s2idle and S3 fit into this

Why this works reliably

Building a Reliable NAS and Integrating UPS Monitoring with TrueNAS and Home Assistant

Why TrueNAS?

Configuring UPS Integration in TrueNAS

Monitor UPS with Home Assistant

Traefik

Home Assistant

Monitoring

Install NUT on RaspberryPi with AlmaLinux

Tweak SELinux Flags

Configure the Firewall

Start the Driver

Enable Required Services on Boot

Useful Links

Bridged Networking on Fedora Workstation for Virtual Machines

Why I Needed a Bridge

Configuration Steps

Why Was the Existing Connection Deleted?

What Is a Bridge Interface?

What Does "Controller Waiting for Ports" Mean?

What Are Bridge Slaves and Why Are They Needed?

Why a Bridge Is Needed for VM LAN Access

What’s Happening Behind the Scenes?

A Quick Word on Virtual Routing Bridges (VRB)

Conclusion

Further Reading:

Terraform: Infrastructure as Code or Just a Fancy Wrapper?

A Unified Language—But Not Really

The Wrapper Dilemma

Easier Than Bash, Until It’s Not

State Management: A Blessing and a Curse

When Terraform Works Best

Final Thoughts

Jakarta validation annotations on the wrong place

Why does this happen?

How to fix it:

Recommended Best Practice:

10 Real-World DevOps Team Lead Scenarios and How to Master Them

1. Junior Engineers Relying Too Much on Seniors

2. A Team Bypasses CI/CD for Direct Production Pushes

3. Handling an Outage and a Critical Security CVE Simultaneously

4. Breaking Down Silos in a Disconnected DevOps Team

5. A Brilliant Engineer with Poor Team Behavior

6. Convincing Leadership to Adopt a New Build Tool

7. Enabling Developer Self-Service at Scale

8. Explaining DevOps to Non-Technical Stakeholders

9. Integrating Security Without Slowing Down Developers

10. Building and Sustaining a High-Performing DevOps Team

Final Thoughts

Aspect Oriented Programming in JAVA

Remote access with RustDesk

Create user for running the server

Configure firewall

Check the firewall configuration

Create systemd resources

hbbs.container

hbbr.container

Start the application

Configure the clients

Additional Technical Notes:

Furter readings

Generate JAVA code from OpenAPI specification

Import Generator plugin

Plugin configuration

Further tweaks

List sourceSets

Resources:

How to configure OpenID authentication in Proxmox VE

Check the CA certificates

Install CA on AlmaLinux

Install CA on Debian

Use the correct issuer URL

Keycloak configuration

1. Create a new realm

2. Setup ActiveDirectory as provider

`hbbs.container`

`hbbr.container`

Import `Generator` plugin

List `sourceSets`