DEV Community: jantolentino

When Redis goes down, does your app die?

jantolentino — Sun, 27 Sep 2026 07:11:46 +0000

The Problem: The App Dies

There was an incident that caused our application to fail because our Redis cache went down. It was in the middle of moving to a larger compute instance to handle a higher load, and since we only had one replica at the time, the cache became completely unavailable.

The issue is that Laravel, by default, assumes your cache is always there. If Redis dies, the standard Cache::remember throws an exception and crashes the request with a 500 Internal Server Error. While it's terrible idea in production environment and should be addressed in different manner. I figured why not try to attempt resolving this within the software-level.

If we want to prioritize functionality over speed, we need to implement graceful degradation. This is a software design principle where, if a service like Redis fails, the system falls back to a slower but reliable method—like querying the database directly—instead of failing catastrophically. The goal is for the system to continue operating, even if it's with reduced performance.

Resilient Cache-Aside

The most straightforward way to handle this is wrapping your cache logic in a try-catch block. It’s a quick fix that looks something like this:

trait ResilientCacheAside
{
    protected function rememberSafe(string $key, Closure $callback, int $ttl = 100)
    {
        try {
            $value = Cache::get($key);
            if (!is_null($value)) return $value;
        } catch (\Exception $e) {
            \Log::error("Cache read failed: " . $e->getMessage());
        }

        $value = $callback();

        try {
            if (!is_null($value)) {
                Cache::put($key, $value, $ttl);
            }
        } catch (\Exception $e) {
            \Log::error("Cache write failed: " . $e->getMessage());
        }

        return $value;
    }
}

While this saves the app from crashing, it introduces a new problem: timeouts. The application still has to wait for the Redis connection to time out before it triggers the exception. This adds latency to every single request while the cache is down, significantly degrading the user experience.

The Circuit Breaker Pattern

A much nicer approach I liked is the Circuit Breaker pattern.

It tracks failures over time. Once a threshold is reached, the circuit opens, and the app skips the cache entirely for a set period, heading straight to the database. This eliminates the timeout delay for users. After a cooling off period, the circuit enters a half-open state to see if Redis is back up. If it is, the circuit closes and normal operations resume.

Instead of writing all this logic from scratch, I found a solid PHP library called Ganesha that handles it beautifully.

The Implementation

First, install the library:

composer require ackintosh/ganesha

Then, I created a CircuitBreakerService. One key detail here is using the APCu adapter to store the circuit state. It would introduce a circular dependency if you store your Is Redis down? logic inside the Redis itself.

class CircuitBreakerService
{
    protected array $breakers = [];

    protected function getBreaker(string $serviceKey): Ganesha
    {
        if (!isset($this->breakers[$serviceKey])) {
            $this->breakers[$serviceKey] = Builder::withRateStrategy()
                ->adapter(new Apcu()) 
                ->timeWindow(10)  // Monitor failures over the last 10 seconds
                ->failureRateThreshold(10) // Open circuit if 10% of requests fail
                ->minimumRequests(5)  // Don't trigger until at least 5 requests are made
                ->intervalToHalfOpen(15)  // Wait 15s before checking if Redis is back
                ->build();
        }
        return $this->breakers[$serviceKey];
    }

    public function execute(string $serviceKey, callable $primary, callable $fallback): mixed
    {
        $breaker = $this->getBreaker($serviceKey);

        if ($breaker->isAvailable($serviceKey)) {
            try {
                $result = $primary();
                $breaker->success($serviceKey);
                return $result;
            } catch (Throwable $e) {
                $breaker->failure($serviceKey);
                return $fallback($e);
            }
        }
        return $fallback();
    }
}

In Ganesha, the $serviceKey is just a unique string used to track the failure rate of a specific resource. By using different names (e.g., redis_cache vs external_api), you can trip the breaker for one service without affecting others.

Usage in the Application

Now, I can use this service inside my AnalyticsService to make my dashboard resilient:

public function getLowQuantityProducts(int $threshold = 10): stdClass  
{  
    return $this->circuitBreaker->execute(
        'redis_cache',
        fn() => Cache::remember("analytics.low_quantity.{$threshold}", 3600, 
            fn() => $this->productService->getLowQuantityProducts($threshold)
        ),
        fn() => $this->productService->getLowQuantityProducts($threshold)
    );
}

Testing

I tweaked the configuration a bit and reduced the values in the getBreaker method for this demonstration.

During my testing, the data was retrieved from the cache as expected while everything was healthy. Once I stopped the Redis container and refreshed the site, the app promptly switched to the database, confirming the fallback was working.

After a short while, I started the Redis container again. The circuit closed, and the app returned to normal operation, pulling data from the cache once more.

::prose-video{src="https://youtu.be/dZ4TmU6k3Eg"}
::

Final Thoughts

In testing, the transition is seamless. When Redis is up, we get the speed of the cache. When I simulate a Redis failure, the circuit trips, and the app continues to serve data from the DB without hanging on the usual timeouts.

One big limitation I realized: if you store your Sessions in Redis, this approach doesn't automatically fix those. The site would still crash if Redis goes down. Sessions are a bit more complex because Laravel's session driver is loaded very early in the request lifecycle, long before the service classes are initialized.

To handle that, we’d likely need to write a custom session driver that can fall back to the database or another store on the fly. I still need to explore that further, so that’s definitely a topic for another article.

Originally published at jantolentino.dev

Using fstab instead of autofs for a samba share

jantolentino — Sun, 27 Sep 2026 07:11:12 +0000

A few weeks ago, I borrowed a Raspberry Pi 4B from a friend. Since it wasn't going to be used for a while, I decided to set up a network storage for our home network. It seemed like the most practical use for the Pi.

The Problemo

Everything was working great until today. After a quick look at the service status, here's what I was dealing with:

Sep 14 03:06:13 homeserver systemd[1]: Starting smb.service - Samba SMB Daemon...
Sep 14 03:06:14 homeserver systemd[1]: Started smb.service - Samba SMB Daemon.
Sep 14 03:06:26 homeserver smbd[2421]: [2025/09/14 03:06:26.137220,  0] ../../source3/smbd/smb2_service.c:746(make_connection_snum)
Sep 14 03:06:26 homeserver smbd[2421]:   make_connection_snum: canonicalize_connect_path failed for service SharedDrive, path /mnt/jantolentino_Drive/jantolentino_Drive
Sep 14 10:21:14 homeserver smbd[3609]: [2025/09/14 10:21:14.823284,  0] ../../source3/smbd/smb2_service.c:746(make_connection_snum)
Sep 14 10:21:14 homeserver smbd[3609]:   make_connection_snum: canonicalize_connect_path failed for service SharedDrive, path /mnt/jantolentino_Drive/jantolentino_Drive
Sep 14 10:22:21 homeserver smbd[3740]: [2025/09/14 10:22:21.111827,  0] ../../source3/smbd/smb2_service.c:746(make_connection_snum)
Sep 14 10:22:21 homeserver smbd[3740]:   make_connection_snum: canonicalize_connect_path failed for service SharedDrive, path /mnt/jantolentino_Drive/jantolentino_Drive

The key error is canonicalize_connect_path failed, which pointed to an issue with Samba accessing the drive's path.

Initial setup

The Raspberry Pi 4 has Fedora Server 38 running on it. I installed Samba, configured the firewall, and assigned a static IP address to the device on my network.

I did, however, run into a couple of snags setting up the external storage. My drive is formatted with BTRFS and encrypted with a passphrase. I discovered two headaches:

External drives often unmount automatically after a period of inactivity to save power and extend their lifespan.
When my encrypted drive unmounts, it needs the passphrase to be unlocked and mounted again.

Having to manually enter my password every time the drive went idle would defeat the purpose of an always-on network share. Plus, I'm not always on a computer which I can easily access the server's terminal.

After some reading online, I found a two-part solution: autofs and crypttab. The autofs service automatically remounts a drive when it's accessed, which works perfectly with Samba. To handle the password issue, crypttab securely "caches" the passphrase and uses it to unlock the drive when needed.

This setup gave me an awesome network storage solution that worked flawlessly for a few weeks. Until today.

Where It Went Wrong

After some digging, it looked like a race condition. The Samba service was trying to access the share before autofs had finished unlocking and mounting the encrypted drive. This timing issue was the root of the problem. Because Samba couldn't find the path, it failed.

I needed a different approach that wouldn't have this race condition.

The Fix: fstab

As it turns out, a much simpler solution is already built into Fedora (oops): fstab. It's powerful enough to handle everything I needed by ensuring the drive is mounted at boot time, well before Samba starts.

First, I had to undo my autofs configuration.

# Remove autofs and its config
sudo dnf remove autofs
sudo rm /etc/auto.jantolentino_Drive

Next, I created a permanent mount point for the drive.

sudo mkdir -p /mnt/jantolentino_Drive

Configuring fstab was surprisingly easy. I just added the following line:

# /etc/fstab
/dev/mapper/jantolentino_Drive /mnt/jantolentino_Drive btrfs defaults,nofail 0 2

The nofail option is important here; it prevents the system from hanging during boot if the drive isn't connected.

Finally, I updated my Samba configuration to use the new static mount point.

[jantolentino_share]
  comment = SharedDrive
  path = /mnt/jantolentino_Drive

Then, a quick reboot.

The Result

We now have a working setup again. This approach feels much more stable, and hopefully, it works for the long run

jantolentino@homeserver:~$ sudo systemctl status smb.service
[sudo] password for jantolentino:
● smb.service - Samba SMB Daemon
     Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Mon 2025-09-15 00:00:43 EDT; 2 months 21 days ago
 Invocation: 346b968c905f4c2ebd09a4e14162382e
       Docs: man:smbd(8)
             man:samba(7)
             man:smb.conf(5)
   Main PID: 1453 (smbd)
     Status: "smbd: ready to serve connections..."
      Tasks: 3 (limit: 4124)
     Memory: 2.5G (peak: 2.8G)
        CPU: 4min 59.375s
     CGroup: /system.slice/smb.service
             ├─1453 /usr/bin/smbd --foreground --no-process-group
             ├─1511 /usr/bin/smbd --foreground --no-process-group
             └─1512 /usr/bin/smbd --foreground --no-process-group

Sep 15 00:00:42 homeserver systemd[1]: Starting smb.service - Samba SMB Daemon...
Sep 15 00:00:43 homeserver systemd[1]: Started smb.service - Samba SMB Daemon.

Final Thoughts

There are probably other ways to approach this, but I'm happy that things are in a better state and my files are secure. I also scheduled some BTRFS maintenance jobs like scrubbing to keep the drive healthy. I'll probably look more into my setup. But for now, everything's well.

Originally published at jantolentino.dev

Uptime Kuma on Fedora with Podman Quadlet

jantolentino — Sun, 27 Sep 2026 07:11:11 +0000

Over the weekend, I decided to set up Uptime Kuma on my mini-server. I needed a quick way to monitor some important work services, and Uptime Kuma’s Slack notifications make it easy to get alerts directly in our channel whenever something goes down.

While I was at it, I figured it was the perfect time to learn Podman Quadlet. I have recently learned as a neat way to manage containers using declarative files (similar to Kubernetes YAML) that automatically generate systemd services so your apps start at boot and stay running.

Installing Podman

First, make sure Podman is ready to go. On my Fedora machine, that’s just a quick:

sudo dnf update -y && sudo dnf install podman -y

Project Organization

I like to keep my tools organized under an infrastructure directory.

mkdir -p ~/infrastructure/uptime-kuma/data
cd ~/infrastructure/uptime-kuma

We’re creating a data directory here to mount as a volume so our Uptime Kuma configuration persists even if the container restarts.

Handling SELinux Permissions

Since Fedora is strict about security, you need to tell SELinux that the container is allowed to write to your local data folder.

chcon -t container_file_t -R ~/infrastructure/uptime-kuma/data

Using :Z in a YAML hostPath isn't standard K8s syntax (unlike what we commonly find in Docker Compose files), so this manual chcon approach is a reliable way to ensure the container has write access.

Creating the Kubernetes YAML

Next, create a file named uptime-kuma.yaml. This defines the pod and the container.

apiVersion: v1
kind: Pod
metadata:
  name: uptime-kuma-pod
spec:
  containers:
  - name: uptime-kuma
    image: lscr.io/linuxserver/uptime-kuma:latest
    ports:
    - containerPort: 3001
      hostPort: 3001 ## You can change this port
    env:
    - name: TZ
      value: "Asia/Manila"
    volumeMounts:
    - mountPath: /app/data
      name: kuma-data
  volumes:
  - name: kuma-data
    hostPath:
      path: /home/jantolentino/infrastructure/uptime-kuma/data ## Change this path
      type: Directory

Moving to Quadlet (Systemd Integration)

Instead of just running podman kube play, we’ll use a Quadlet .kube file. This tells systemd to manage the Kubernetes YAML we just wrote.

First, create the Quadlet directory if it doesn't exist:

mkdir -p ~/.config/containers/systemd

Now, create a file named uptime-kuma.kube inside that folder:

[Unit]
Description=Uptime Kuma Service
Wants=network-online.target
After=network-online.target

[Kube]
## Path to your Kubernetes YAML
Yaml=/home/jantolentino/infrastructure/uptime-kuma/uptime-kuma.yaml

[Install]
WantedBy=default.target

Activating the Service

The awesome part is that when you reload the systemd daemon, Podman’s Quadlet generator sees your .kube file and creates a real systemd service automatically.

## Refresh systemd to find the new Quadlet
systemctl --user daemon-reload

## Start and enable the service
systemctl --user enable --now uptime-kuma.service

Enable "Linger"

By default, "user" services stop when you log out. Since this is a server, we want it to run 24/7 even without an active SSH session. Use the loginctl command to enable "lingering":

loginctl enable-linger jantolentino

Now your Uptime Kuma instance will start automatically as soon as the server boots up. No more manual starts needed!

Originally published at jantolentino.dev

Testing scheduled jobs using faketime

jantolentino — Sun, 27 Sep 2026 07:10:36 +0000

Recently, I was tasked with testing some scheduled exports to investigate a defect. Unit tests should have caught it, but something else was going on. I had to simulate a real execution in a container by faking its internal clock.

This is where I utilized faketime.

faketime is a tool that manipulates system time for a specific program without changing the system's actual time. It works by intercepting the system calls a program makes to get the current date and time, allowing you to run programs as if it were a different date and time.

Check for the faketime package

First, you need to make sure the faketime package is available in your container image, as it's not commonly included. To confirm that the library file exists, you can run:

podman exec -it {container_name} find / -name libfaketime.so.1

If that command finds the library file (e.g., at /usr/lib/faketime/libfaketime.so.1), you're good to go. Otherwise, you'll have to install it.

Usage

So how do you use it? It's actually pretty simple.

podman exec -it {container_name} sh -c "LD_PRELOAD=/usr/lib/faketime/libfaketime.so.1 FAKETIME_NO_CACHE=1 FAKETIME=\"$(date -u -d '30 days ago' '+%Y-%m-%d 00:01:00')\" php artisan schedule:work"

What's being passed here are:

LD_PRELOAD: Tells the shell to load the faketime library before running the command.
FAKETIME_NO_CACHE: Prevents the time from being cached, which is important for testing.
FAKETIME: Sets the exact time you want to simulate. In this case, I'm using date to get a formatted string for "30 days ago at 1:00 AM UTC."

Since I was testing an export, I had to make sure it worked on a daily, monthly, and yearly basis. Using this command, I could just change the date string to simulate any scenario. This was a really interesting and effective way to test.

Originally published at jantolentino.dev

Suspend, Background, Disown

jantolentino — Sun, 27 Sep 2026 07:10:34 +0000

I'm currently working on a hobby project, using crawlers to download media files for a dataset. Some of these are large files that also need preprocessing. Instead of building a whole system to manage this, I'm just creating simple scripts to handle them one at a time.

Given the volume of data I'm working with, I realized the scripts were going to take a long time to run on my mini-server. So, I needed to run them as background processes.

In the past, I've always relied on nohup or tmux for this kind of thing. But today, I remembered a neat trick I recently learned.

Suspend the Process

It turns out you can suspend a process that's already running. While your script or command is active, just press CTRL + Z. You'll get a message like this:

[1]+  Stopped  (your command)

The [1] is the job number of the process.

Resume in the Background

After you suspend the process, you can type bg and hit enter. This command will resume the job, but it will run in the background now.

[1]+ (your command) &

It will confirm that it's running in the background, usually with a message ending in that notable ampersand (&).

Disown the Process

This is the most important part of the trick. The process is still attached to your current shell session, so you need to detach (or disown) it. The main reason I always stuck with nohup in the past was to prevent the process from stopping when I logged out.

To disown it, you simply enter:

disown -h %1

The %1 refers to the job number. Now the process is fully independent of your session.

What's wrong with nohup?

Nothing, really. The main difference is you use nohup before you start a process. The trick above lets you do it after a process is already running. That's what makes it so neat!

Final Thoughts

Of course, tmux detached sessions still rule, but for simple things like this, I find this is a handy trick. It's especially useful when I'm on a server that doesn't have tmux installed and I don't have permission to add it. Meh.

Originally published at jantolentino.dev

No measurement, no optimization

jantolentino — Sun, 27 Sep 2026 07:10:01 +0000

No measurement, no optimization.

There's a common saying in programming: "Don't optimize what you haven't measured yet." You can only truly appreciate this advice when you experience it yourself. And I definitely did.

I'm always looking forward to projects where I can optimize the code after the first release. It's really satisfying to refine code and make it cleaner and more efficient. But I've learned the hard way that optimizing without measuring the performance changes can be a disaster, especially with my limited experience. Most of our performance issues stem from database queries, not from our program’s architecture.

After our initial release, there were two queries that I had to write separately because of how complex they were. I planned to optimize them after the release, and I thought combining them would be more efficient. I tested it, and everything looked fine—the output was the same and there were no issues.

Feeling good about my work, I submitted a merge request late that day and waited for feedback. The next day, I saw that no one had reviewed it yet. My curiosity took over, and I decided to measure the performance myself, hoping to validate my work. It didn't.

I opened Postman and sent 100 requests to calculate the average response time. It wasn't the best approach, but it would get the job done. The new implementation had a higher overall response time. While some requests were faster than the old version, there were also significant spikes. Ultimately, it wasn’t better at all. I had actually made it worse.

I closed my merge request and noted that the code was flawed and could cause performance issues. After digging into it, I realized I had overlooked how crucial it was to understand the structure of the data and its data types, which had an unforeseen impact on performance.

Even so, it was a valuable experience that I genuinely enjoyed. I learned more about Laravel performance tools, discovered how useful Postman is for this kind of work, and gained experience researching potential performance regressions.

Ultimately, optimizing based on instinct is just the beginning. You still need to back it up with accurate measurements. As they say, you can only call it optimized if you have the benchmarks to prove it!

Originally published at jantolentino.dev

New Portfolio in the Works

jantolentino — Sun, 27 Sep 2026 07:09:59 +0000

New Portfolio in the Works.

I’ve always wanted a cool, chibi-style profile picture for my portfolio, but I've never been good at drawing. I even tried paying for art commissions, but nothing really worked out. So, my portfolio always ended with text for the logo.

Then, OpenAI released a new Ghibli-style image generator, and it could turn any portrait photo into Ghibli-style art! I got so excited and tried it right away.

Ghibi-style generated via OpenAI

And it's awesome! I got inspired to immediately start designing a portfolio landing page. I checked my Pinterest boards, looking at old pins and searching for new ideas. I found this amazing portfolio design on Figma and was instantly captivated.

Design inspiration from Figma community by 三秋十李Sergio.

I really liked the vibe of it. I’ve never been good at putting into words what I like about this, but I think it’s the modern and techy style that’s capturing me.

Right away, I knew this was the style I wanted to try next. The original design was a bit too detailed and cold for me, and I wanted something a little warmer, so that's what I went for.

Even though I’m more intuitive when designing in Figma, I still use Inkscape for my casual projects. It gives me more flexibility with gradients and tools that make it easy to create design elements. After sitting for hours, nudging shapes pixel by pixel, I finally made my not-so-final draft. Honestly, I'm really happy with how it turned out! There's still a lot to fix and improve, and I'll definitely work on the legibility, but I'm already pretty happy with the look. It's far from done, but it's really coming along.

The text are tight and I was exploring the design for the next section. I didn't commit to this though

Finally, I was satisfied with this. Some elements are too thin but it's getting there.

I've even been trying to make it work on different screen sizes, which has turned out to be a big challenge. I'll probably have to keep exploring the layout next time. Here's a little peek at how the mobile version is looking. I've also been playing with animations, like making the background fade in slowly, and it turned out pretty cool!

Mobile-version in development of the new design

I don't plan on replacing my current site with this, but it’s nice to see a new design coming together. I'll host it on a separate site once I have the time. More than anything, I’m just happy and excited about this sudden inspiration and the joy of building this design as an experiment.

Originally published at jantolentino.dev

Installing and setting up Postgres in Ubuntu

jantolentino — Sun, 27 Sep 2026 07:09:25 +0000

At work, we handle a lot of short-term projects, typically lasting 3-8 weeks. These projects don't require a complex deployment setup. Instead, we deploy each project on a single VPS instance, with all the stacks bundled together on the same system.

Sure, it's a single point of failure and not the ideal setup, it however matches our clients’ budget and allows us to deliver quickly. Luckily, we've never faced a catastrophic failure with this approach (yet).

In these types of projects, which come and go, each one is deployed on its own VPS. Which also means I set up a DB instance on each VPS. Honestly, this routine task could be scripted, but I actually enjoy doing it manually.

Overall, the routine involves installing the packages, ensuring they're running and will restart on reboot or failure, setting up the users, creating a database, and granting user privileges to the database. Depending on the circumstances, additional configuration might be needed if necessary or requested. However, this routine is what I consider the minimum or baseline.

It's worth noting that I'm mostly deploying on Ubuntu systems, so some commands are specific to this distro.

Installing the Postgres

The PostgreSQL package is available in the main repository, so it can be installed with the following command:

$ sudo apt install postgres postgresql-contrib

Once installed, PostgreSQL is available on your system, but it isn't running yet!

PostgreSQL service up and running

The PostgreSQL process is managed by systemd. After installation, a systemd service unit file is provided. You just need to start the service and enable it to start on reboot.

To start the PostgreSQL service, simply enter the command:

$ sudo systemctl start postgres.service

You can verify that it is running using the status command in systemctl.

To ensure that the PostgreSQL service automatically starts on reboot, use the following command:

$ sudo systemctl enable postgres.service

Now that you have a PostgreSQL instance up and running, the next step is to set up users to connect to it.

Creating a new user

Out of the box, after installing the PostgreSQL package, a postgres user is created with administrative privileges by default.
To create a new DB user, you need to switch to the postgres user. You can do this with the following command:

$ sudo su postgres

You can confirm if the switch was successful by checking your username with the following command:

$ whoami

To create a new DB user, run the createuser command. It will prompt you for the role name and ask if the new role should be a superuser. Enter y to confirm if you want the new role to have superuser privileges.

$ createuser –interative
  Enter name of role to add: {{username}}
  Shall the new role be a superuser? (y/n) y

Creating a new database

Creating a new database is very easy. Simply use the following command:

$ createdb {{database_name}}

Once that's done, you have created a new database. However, the new user doesn't have privileges to access or modify the database yet. To grant these permissions, you can use an SQL query to assign the appropriate privileges to your user.

Enter psql to start a session where you can run SQL queries:

$ psql
GRANT CONNECT ON DATABASE {{database_name}} T O {{username}};
GRANT pg_read_all_data TO {{username}};
GRANT pg_write_all_data TO {{username}};

This grants the user permission to connect to the database and provides read and write access to all the data in the database.

Authenticating user

Currently, the user you just created has been granted access to connect to the database. However, you still need to log in as that user.

There are several types of authentication you can use to connect, depending on your use case. For this routine, I use password-based authentication to connect to the PostgreSQL instance.

What I typically do is set or change the password for the newly created user. As the postgres user, which has the highest authority, you can do this with the following SQL command:

ALTER USER {{username}} WITH PASSWORD '{{new_password}}';

Once that's done, you can exit the SQL shell and then exit the postgres user shell. This requires two exit commands:

\q exit

Others

There are easier ways to set up Postgres, but I find using Docker images more efficient. It's quick and simple. For large-scale server deployments, Ansible scripts are often a better option.

Reference Notes

Originally published at jantolentino.dev

Hello, world!

jantolentino — Sun, 27 Sep 2026 07:09:23 +0000

Finally! My personal blog pings the world of the internet with a hearty "Hello, world!"

It honestly took me a while to buckle down and do it, but after a bunch of pins on Pinterest and checking out other people's sites, I finally crafted a design I'm really happy with.

I’ve always wanted a place where I could write about my interests and share my experiences with unusual technologies I find online. I want to also improve my writing and communication skills. So, putting up a personal blog felt like a great way to improve.

I had a lot to figure out before I built the site. I explored different frontend frameworks, researched which cloud hosting providers were cheap and reliable, and planned out how to get a seamless deployment.

In the end, I went with NuxtJS and VueJS for the frontend. Working with VueJS is fantastic, and I'm really enjoying the experience. I stored the project in GitLab and used its CI/CD to automatically build a Docker image and deploy it to a VPS I bought from Digital Ocean. For security and diagnostics, I also added Cloudflare to protect and optimize the server. I think my site is pretty well-configured at this point.

There are still a lot of features I need to add, like view components for code blocks, lists, and cards. But now that I’ve taken the hardest first step, I'm confident the rest will be a lot smoother.

There's so much to learn and so much to enjoy. I plan to write about every moment I spend building my hobby projects. This personal site is just the beginning.

Originally published at jantolentino.dev

Getting the Function Keys Back on a Realme Book i5

jantolentino — Sun, 27 Sep 2026 07:08:50 +0000

A few years ago, I bought a Realme Book i5 for work. I bought it because it was slim, the display was nice, and it was a great lightweight machine to work on away from my desk.

There was one problem I didn't expect. I use it mostly to write code, which means I constantly use the F1–F12 keys. On this laptop, the top row defaults to media keys, and I can't trigger the real F-keys without holding the Fn key. Unlike laptops from Lenovo that let you flip an Fn lock, this laptop has no such option.

Working around this friction

My first thought was to remap the keys with evremap. But this wasn't as easy as I thought. When I checked for raw input with evtest, the F1 to F12 keys didn't send any events at all unless the Fn key was held down.

This was disappointing, so I opted to remap a few Fn keys that I use frequently—such as F12 to trigger "find references" in my IDE. Often, I'd just resort to working with an external keyboard when necessary.

Digging into the firmware

Nonetheless, I was convinced that a toggle existed somewhere, because inside the UEFI setup screen, the F-keys behave like normal F-keys by default. My theory was that once the kernel loads during boot, something flips them to media mode. That led me to suspect the firmware.

At that point, I browsed for the BIOS file online, decompiled it, and read through the disassembly manually, looking for the flag that set the top-row mode. Given that I had no idea what to look for in the first place, I never found it, even after searching for a bunch of strings I suspected might be related. Eventually, I shelved the project and moved on.

Picking it back up with Claude Code

I came back to it recently with Claude Code and my old archived dump. Hoping it could help me find what I was looking for, I pointed it at the extracted files, let it review everything I had, and had it work through the ACPI tables.

After a few hours of going back and forth, it finally landed on something that actually made sense.

Over the course of this, I learned that flashing the BIOS was not an option since the firmware is signed and protected. But I didn't actually need to touch the firmware. Instead, Linux can load custom ACPI tables from the initramfs at boot and apply the override I needed. That was good enough for me.

From Claude Code's investigation, we gathered that the EC exposes three fields that control the Fn key behavior: FNSP, FNRV, and MFNM. Setting them to FNSP = 0, FNRV = 1, and MFNM = 0 forces the standard F-key mode. It took quite a while to find the right combo to finally get this behavior.

Now, the plan was to write those values at boot through a supplemental SSDT. To apply this, we create a dummy device in the system bus (\_SB) with its own _INI method. During the initialization phase, this custom device will run its method and flip the EC fields.

The fix

First, note that the kernel needs a CONFIG_ACPI_TABLE_UPGRADE configuration enabled.

Write the SSDT

Create a new file and name it fnfix.dsl:

DefinitionBlock ("", "SSDT", 2, "REALME", "FNFIX", 0x00000001)
{
    // Reference the existing Embedded Controller and its fields
    External (\_SB.PC00.LPCB.H_EC, DeviceObj)
    External (\_SB.PC00.LPCB.H_EC.FNSP, FieldUnitObj)
    External (\_SB.PC00.LPCB.H_EC.FNRV, FieldUnitObj)
    External (\_SB.PC00.LPCB.H_EC.MFNM, FieldUnitObj)

    Scope (\_SB)
    {
        Device (FNFX)
        {
            Name (_HID, "REAL0001") // Custom Hardware ID

            // Runs once during ACPI initialization
            Method (_INI, 0, NotSerialized)
            {
                \_SB.PC00.LPCB.H_EC.FNSP = 0
                \_SB.PC00.LPCB.H_EC.FNRV = 1
                \_SB.PC00.LPCB.H_EC.MFNM = 0
            }
        }
    }
}

Compile

Compile using iasl, which produces fnfix.aml.

iasl fnfix.dsl

Now package the AML the way the kernel expects it.

mkdir -p kernel/firmware/acpi
cp fnfix.aml kernel/firmware/acpi/
find kernel | cpio -H newc -o > acpi_override.img
sudo cp acpi_override.img /boot/

Load it before the main initramfs

We need to make sure that the ACPI image is the first initrd the bootloader loads, ahead of the normal initramfs.

Depending on the bootloader, we simply append it before the main image. For example:

title   Linux
linux   /vmlinuz-linux
initrd  /acpi_override.img
initrd  /initramfs-linux.img
options root=UUID=xxxx-xxxx-xxxx rw

Finally, we can reboot.

The kernel loads the overlay, the dummy device's _INI method runs during initialization, and the top row sends real F1-F12 events without needing to hold the Fn key!

Originally published at jantolentino.dev

Getting into the world of Ansible

jantolentino — Sun, 27 Sep 2026 07:08:48 +0000

Getting into the world of Ansible

Ever since I started exploring DevOps, I’ve always loved the idea of automating server setups with a single script. I have a strong interest for scaling web services to handle high traffic while ensuring stable uptime.

For a long time, the closest tool I've been aware of was Ansible. However, it always had a steep learning curve for me, and I didn't have much free time to invest in it. Plus, paying for extra servers just to tinker with felt a bit expensive, and I wasn't interested enough to mess with local virtualization.

Lately, thanks to AI tools, the barrier to entry for Ansible feels much lower. Getting explanations and answers to specific problems is so much easier now.

So, with my humble homelab setup, I decided to explore migrating my current apps and manage them with Ansible instead.

Getting Started and Early Retrospective

Not knowing where to begin, I asked Gemini to outline the basic topics I needed to understand. Grasping the core concepts of tasks, playbooks, vaults, variables, and inventories was straightforward. The overwhelming parts were modules, roles, and how to organize the files.

I understood the fundamental purpose of roles and how they manage complexity and reduce redundancy by packaging tasks into reusable components. However, it conflicted with my personal preference. Roles exponentially increased the complexity of my folder structure. As someone who likes to keep things simple and flat—much like C projects usually do—it was tricky for me to accept. So, I decided to skip roles for now and stick to a near flat structure.

Modules, on the other hand, are vast. I felt like I had to memorize dozens of them to get started, which felt restricting. Thankfully, most of what I needed fell under the ansible.builtin namespace, so I didn’t have to worry too much about third-party modules just yet.

Migrating Uptime Kuma for Testing

I have a mini-server at home and a VPS hosted in Hetzner. I call them my home node and cloud node, respectively.

I previously moved my Uptime Kuma instance to the cloud_nodes to ensure it actually stays up. It wouldn't be very useful if it crashed during a power or internet outage at home. Since Uptime Kuma is the simplest app in my stack, I decided to use it as the test subject for my Ansible migration.

Prerequisites

First, you need a master node. This is the workstation that reaches out and accesses your servers. In my case, I used my primary PC.

You also need to make sure you can SSH into those servers. Ideally, set up your SSH private keys to skip the hassle of typing or maintaining passwords. My servers and my workstation are all connected via Tailscale, which securely bridges the connections and makes routing incredibly simple.

Setting Up the Project

To start an Ansible project, you basically need four things: a configuration file (ansible.cfg), a list of your servers (inventory.yml), a main playbook to run tasks (site.yml), and the task files themselves.

First, I defined inventory.yml, which lists my actual servers. In its simplest form, it looks like this:

---
all:
  children:
    home_nodes:
      hosts:
        p1_server:
          ansible_host: <tailscale IP>
          ansible_user: jantolentino
    cloud_nodes:
      hosts:
        p2_server:
          ansible_host: <tailscale IP>
          ansible_user: jantolentino

Next, I created the ansible.cfg configuration file:

[defaults]
inventory = inventory.yml
host_key_checking = False
stdout_callback = default
result_format = yaml
roles_path = roles
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_facts
fact_caching_timeout = 86400

[ssh_connection]
pipelining = True

I enabled pipelining to speed things up. It ensures that Ansible doesn't create a brand new SSH connection for every single task, which drastically lowers execution time. The other configurations mostly help with troubleshooting or caching.

With the foundation set, it was time to write the actual instructions. I started by creating my main entry point, site.yml:

---
- name: Build home infrastructure
  import_playbook: playbooks/home_infra.yml

Before migrating Uptime Kuma, I wanted to make sure my workstation could actually command the servers. So, I created a simple "ping" task under a tasks directory named ping.yml:

---
- name: Ping host to verify connectivity
  ansible.builtin.ping:

Finally, I tied it all together by creating a playbook specifically for the home_nodes to define what should execute on those servers in playbooks/home_nodes.yml:

---
- name: Manage home infrastructure apps
  hosts: home_nodes
  tasks:
    - name: Ping server
      ansible.builtin.include_tasks: ../tasks/ping.yml

Testing the Basics

To run the tasks, the command is:

ansible-playbook -i inventory.yml site.yml

This runs the ping task against all servers defined in the inventory. You can limit it to a specific group or node by adding the --limit flag, like this:

ansible-playbook -i inventory.yml site.yml --limit home_nodes

Running the ansible-playbook command to ping the server

The Migration Plan

Now for the actual migration. I wanted to add my Uptime Kuma instance to this setup.

Thankfully, I had previously deployed my apps using Podman Quadlets. This declarative approach made my Ansible migration plan much easier to execute. Note that Uptime Kuma was already running on the Hetzner server. My goal was simply to define its state in Ansible so I could manage it moving forward, not to destroy and recreate the instance.

Ansible should ensure the instance is configured correctly without causing data loss unless explicitly intended.

My task outline looked like this:

Copy the Quadlet files to the server.
Create the necessary application directories.
Run a dry-run to ensure the Quadlet syntax is valid.
Reload systemd to generate the service file.
Start or restart the application service.

Here is what my quadlet_setup.yml roughly looks like:

---
# Assertions
- name: Ensure app_name is provided
  ansible.builtin.assert:
    that:
      - app_name is defined
    fail_msg: "Error: You must specify 'app_name' when including this task file."

- name: Enable user lingering
  ansible.builtin.command: "loginctl enable-linger {{ ansible_user }}"
  args:
    creates: "/var/lib/systemd/linger/{{ ansible_user }}"
  become: true
  tags:
    - setup

- name: Copy quadlet configuration files
  ansible.builtin.template:
    src: "../quadlets/{{ item }}"
    dest: "/home/{{ ansible_user }}/.config/containers/systemd/{{ item | basename }}"
    owner: "{{ ansible_user }}"
    group: "{{ ansible_user }}"
    mode: "0644"
  loop: "{{ quadlet_files | default([]) }}"
  register: quadlet_templates

- name: Dry-run Quadlet files to check syntax
  ansible.builtin.command:
    cmd: /usr/libexec/podman/quadlet -dryrun -user
  register: quadlet_check
  changed_when: false

- name: Ensure the application directory exists
  ansible.builtin.file:
    path: "{{ item }}"
    state: directory
    owner: "{{ ansible_user }}"
    group: "{{ ansible_user }}"
    mode: "0755"
  loop: "{{ app_directories | default([]) }}"
  tags:
    - setup

- name: Reload systemd (user) and start service
  ansible.builtin.systemd_service:
    name: "{{ app_name }}.service"
    state: started
    enabled: true
    daemon_reload: true
    scope: user
  become: true
  become_user: "{{ ansible_user }}"
  vars:
    ansible_become_flags: "-i"

- name: Restart service if configuration changed
  ansible.builtin.systemd_service:
    name: "{{ app_name }}.service"
    state: restarted
    scope: user
  become: true
  become_user: "{{ ansible_user }}"
  vars:
    ansible_become_flags: "-i"
  when: (quadlet_templates.changed | default(false)) or (app_config_changed | default(false))

Getting this right made me appreciate two specific Ansible features: tags and become.

Because I used tags, I can skip certain tasks. For example, I don’t need to enable user lingering every single time I run the playbook. I can just add --skip-tags setup to my command to save time. And whenever a task needed root privileges, become handled it perfectly. I just pass the -K flag when running the playbook so it prompts for my sudo password.

With all of that logic in place, I finally ran it. Naturally, there were a few issues to fix along the way, mostly typos in my container or network files. Running /usr/libexec/podman/quadlet -dryrun -user was the key for catching those errors early.

Ansible ad-hoc commands helped me check the system state, though sometimes just SSHing directly into the server was faster for debugging.

Running the ansible-playbook command with an error

Teardown: Decommissioning the App

I was also curious about how to cleanly destroy the instance if I ever needed to decommission it. I created a tasks/quadlet_remove.yml file:

---
# Assertions
- name: Ensure app_name is defined
  ansible.builtin.assert:
    that:
      - app_name is defined and app_name | length > 0
      - quadlet_files is defined and quadlet_files | length > 0
    fail_msg: "CRITICAL ERROR: 'app_name' and 'quadlet_files' must be provided."
    success_msg: "Check passed. Proceeding with the removal of {{ app_name }}."

# Teardown
- name: Stop and disable the systemd (user) service
  ansible.builtin.systemd_service:
    name: "{{ app_name }}.service"
    scope: user
    state: stopped
    enabled: false
  become: true
  become_user: "{{ ansible_user }}"
  vars:
    ansible_become_flags: "-i"
  failed_when: false

- name: Forcefully purge remaining active or broken container states
  ansible.builtin.command: "podman rm -f {{ app_name }}"
  changed_when: true
  failed_when: false

- name: Cleanup Quadlet definition files from systemd directory
  ansible.builtin.file:
    path: "/home/{{ ansible_user }}/.config/containers/systemd/{{ item | basename }}"
    state: absent
  loop: "{{ quadlet_files }}"

- name: Force systemd (user) daemon to reload and flush generated services
  ansible.builtin.systemd_service:
    daemon_reload: true
    scope: user
  become: true
  become_user: "{{ ansible_user }}"
  vars:
    ansible_become_flags: "-i"

- name: Permanently remove application storage directories from host
  ansible.builtin.file:
    path: "{{ item }}"
    state: absent
  loop: "{{ app_directories | default([]) }}"
  become: true
  tags:
    - destroy-data

To remove the app and clean up, I simply swap out quadlet_setup.yml for quadlet_remove.yml in my playbook.

Looking Forward

There are still a few things left to explore. I want to figure out how to autonomously back up application data and find a straightforward way to roll back deployments if something breaks. I plan to dedicate more time to that soon.

Also, as the project grows, I’ll likely have to bite the bullet and dive into roles and Ansible's Jinja2 template engine to keep things manageable.

But for now, I successfully brought Uptime Kuma under Ansible's control. Next up is migrating the rest of my apps. I currently manage my environment variables using Doppler, so getting Doppler tokens to securely pull variables into these servers via Ansible will be my next big hurdle.

Cheers!

Originally published at jantolentino.dev

I got my Associate Cloud Engineer Certification!

jantolentino — Sun, 27 Sep 2026 07:08:17 +0000

I finally did it—I passed my Associate Cloud Engineer Certification exam! The journey had a lot of ups and downs, and ironically, they weren't even related to the exam itself. Honestly, the biggest challenge was finding enough time to review and do the study sessions.

Back in March, I saw an email about a "Get Certified" program and was immediately interested. I really wanted to learn more about opportunities in the cloud, so I applied with my work email, which turned out to be a good move.

Early promotional email I received from GCP

A few days later, I got a confirmation email that I was in. The program included some really helpful review sessions. They gave me the confidence I needed to tackle the exam. As the sessions went on, it got a bit trickier to keep up. We had a lot of mixed discussions about the basics, principles, and different Google Cloud products. We often focused on which software was better for specific use cases. GCP has many solutions for a single problem, but each one has its own nuances in terms of pricing, reliability, maintenance, and others. These discussions were honestly super insightful.

We also covered topics like setting up virtual machines, routers, and load balancing. We learned how to store different types of data and how to follow security best practices. I was already familiar with most of these processes, but not with how to navigate Google Cloud's specific software. I didn't have much experience with that before.

I had to rely on diagrams to fully grasp the concepts (URL Map & Forwarding Rules)

Looking back, the hands-on labs were what helped me the most. They were awesome! They gave me a deeper understanding of how to actually manage and configure things in the cloud. They even covered the basics, like how to navigate the cloud's webpage, which is so simple yet so helpful when you don't know where to find things. We were often told the exam wasn't very technical; it was more essential to gain better understanding the available products, principles, best practices, especially with real-world examples. Even so, the program gave me the necessary experience and skills to deliver scalable solutions and setting up things in the cloud.

Almost three months went by, and with my no-cost voucher about to expire at the end of May, I finally took the exam. Today, after what felt like an endless two-day wait, I got my results! All those months of studying and learning paid off. Now, it's on to the next adventure: Cloud Architect! Wish me luck!

My official certification from Credly

Originally published at jantolentino.dev