Using Uptime Kuma to Monitor My Systems

I've been curious about monitoring systems and didn't want to use something overbearing, such as Zabbix.

One reason that I monitor the r/docker subreddit is because I sometimes see folks posting about the containers and tools that they use.  Someone posted about Uptime Kuma recently and I examined it.

I LOVE DOCKER because it's super easy to deploy tools such as Uptime Kuma and test them.  I was able to deploy Uptime Kuma within minutes and loved what I saw.

I'm now using it to monitor all my tools, mainly my LAN containers and servers, as well as my external containers and web servers.  As well, I'm monitoring to ensure my SSH ports are up and connectable on my Linode host (and the port that I use to shell into my home system that has a port exposed to the internet).

I even tested different versions of Uptime Kuma.  I love that it's simple yet is also capable.  I don't want to mess with agents and I can monitor my systems with Uptime Kuma without using agents.

My Linode Web Server is Now Serving Both Domains, Utilizing Containers!

I got a bit bored today and felt that I could tackle testing a Docker container to leverage Let's Encrypt SSLs.

As usual, I wanted to leverage AI and, since I had major success with little problems with Gemini last go-around, I used it again.

The First Domain:

I started with wigglit.com.  As I already had a compose file to work with and I'd previously tested running containerized Wordpress on the Linode, it was a rather easy start.  I shared the file with Gemini and ask what needed to be added/changed.  The compose file enabled an Nginx-based sidecar to handle SSL termination (and the domain was already set up for use).  That was the biggest change.

Well, when I tried to access the site, I couldn't - I was geting "502 Bad Gateway" errors.  As well, SSL was not working.  I checked the logs and saw many 404 errors, not just from my public IP but from other IPs, too.  I'd copied over a pre-existing copy of the Wordpress site and I think some permissions were borked - the new compose file didn't like something within my new workspace.  I found that the file ownership and permissions were jacked, and even after sorting that out, I still had issues - while the gateway errors were resolved, and I could now see server code 200s in the logs, the pages being served lacked content (they were blank).

Instead of waiting for Gemini to further help with this, I decided to just create a new workspace but without the copy of the Wordpress content I was previously using.  I started from scratch, to test.  Well, the test worked. I immediately got the Wordpress setup page, and I set up a quick default page, knowing I was just going to retrieve an offsite backup (yes, I keep backups).  It took maybe 15 minutes to get a recent copy of the site (minus a week of data).  And, on top of that, SSL was working!

So, the Wordpress site is now running, as a container, and using SSL.  It's not like I hadn't done this before, but when I last had things containerized, it wasn't leveraging an SSL.  As well, I was running two domains through Apache and didn't know how to run both using a container.  When I'd run the container, it would get in the way of running the other site using a different domain.  While I'd discovered how to run both outside of Docker, I was still researching if I could do it with Docker.

The Second Domain:

My other domain is unixfool.us.  It it a plain static website with very old content.  I use it mainly to archive and share photos.  As it is just sharing pictures, I don't really need it to leverage SSL.  Eventually, I will enable SSL with that domain, but for now, I just need it running, 

I gave Gemini instructions to leverage the same compose file to get unixfool.us to serve pages, via basic HTTP.  Gemini gave me an updated compose file so that I could leverage that Nginx proxy with unixfool.us, even via port 80.  This one was easy, as all I really had to do was point the compose file to where the website content was located on the server.

Gemini screwed up at this point, though.  I'd asked it to give me the updates to the existing compose file that would enable unixfool.us to work.  It actually changed login credentials for Wordpress, in addition to giving me what I asked.  I had to compare both files to see the discrepancies, but I also had a hint, because I'd tried to run the compose file and saw some DB errors - I suspected credentials had changed.  This is why it's important to always check AI output - never fully trust it.  Trust but also verify.

After I fixed the credentials, I was able to access both websites while both were running as Docker containers.  The sites are fast!

I do have a question about the SSL certificate, though.  It expires in 3 months.  With the old setup, I had a cron job running that was supposed to renew the certificate before it expired....that setup was before the new setup that leverages Docker.  I think all I have to do is restart the container sometime before the 3 months expires, but I'm not sure.  I may have to research further about this (or I can just test this out next week - checking to see if the cert is recreated when I shut down and restart the container, keeping track of the "issued on" and "expiring on" dates).

This project was fun, though...seriously!

UPDATE:  I researched the certificate renewal and the https-portal (the reverse proxy) container actually runs a cron job that periodically checks the SSL expiry and will renew the certificate 30 days before expiration.

UPDATE:  I ended up going down a rabbit hole of remediation issues, as the unixfool.us site wasn't allowing viewing of the images (fixed with an .htaccess entry); also had an issue where Wordpress wasn't allowing uploads of images bigger than 2 MB, which took a LONG time to remedy, as AI kept giving me the wrong suggestions (both Gemini AND ChatGPT) - I ended up conducting a Google search to find the answer.  Again, I had to add environment variables to the .htaccess file in the folder where the wp-config.php resides, but even so, the docker instance of Wordpress doesn't allow large pixel sets - I had to adjust the file size to reduce the pixel count.

UPDATE:  Annnnnd...I thought I was done but found that the image I was using (was using wordpress:latest) was using an older version of PHP (v8.2).  Wordpress was showing it as a security issue.  Instead of waiting to be hacked, I decided to see if the official Wordpress Docker repository had an image with a later version.  I tried version php8.4-apache, which got rid of the security alert, then I saw that there was an image for php8.5-apache, which I settled on.  I'll watch to see if this image is problematic.

UPDATE:  In conducting next-day checks, I noticed that 2FA stopped working (I'm using native 2FA).  I had to disable it and then re-enable it, which meant I had to re-enter the QR code in my authenticator app.  This was a bit annoying to see occur, because it meant that my account didn't have 2FA the past 12+ hours, but it's fixed now.

UPDATE (3/31/2026):  I've created a few posts now and have noticed that the website is posting a lot faster than it was before I containerized it.  I didn't do before and after performance checks, sadly, but it's definitely faster.

I Just Set Up a Web Server to Use an SSL Cert, Using Let's Encrypt!

Yesterday, I was bored and had been contemplating setting up one of my public web sites to use an SSL certificate.

While most business websites use SSL certificates, SSL certs aren't really mandatory for use in just serving web content for reading purposes.  I've been using Apache to serve web pages a LONG time and never felt the need to enable HTTPS, as it wasn't required.  That changed when I found that I wanted my website to be more noticeable within search engine results.  To place higher within search engine results, HTTPS is required to be used on the web server that is serving the content.

As I host my own server, my options were to set up my own SSL certificate or to buy an SSL certificate for use with my server.  I decided to set up and deploy my own.

I used this link's instructions (I used CertBot, which uses Let's Encrypt, which I'll reference as LE) to set everything up.  Keep in mind that I'm using Ubuntu 25.10 to host my server, using Linode as a server.

After I built the certificates, I had a difficult time determining how to leverage them.  I initially tried using a WordPress plugin to import the certificate, but I tried like 5 different plugins and neither worked.  I then pivoted and tried a different method - I'm running Apache to serve Wordpress, so I set up the Apache config file to use HTTPS and pointed Apache to the LE certs.  I then used an SSL checker to check that everything was working.  It was.

Afterward, I then set up a cron job to renew the certs automatically.

Now, when I check the browser for indications that the website is using SSL, there's no lock icon that I can see, but I researched and saw that I also had to ensure the website's prior content wasn't using HTTP links to intneral server content, so I used some Wordpress tools to search and change HTTP links pointing to my web server to use HTTPS.  I also saw that a lot of my plugins and themes are using HTTP links that that's supposed to be a no-no for HTTPS compliance - I can't control how plugin providers construct their plugins, so I'm not sure what to do with that.

I think I'm going to enable SSL with with my other domain, as well (unixfool.us).

Eventually, I plan to replace my Wordpress website with a docker instance.  I'd need to research how to use SSL certs within a docker compose YML file.  I'm thinking it should be pretty straight-forward.  The only thing I can think of that might be an issue is the automatic renewal bit (the bit where I added a cron job to renew the certificate).

UPDATE (1/20/2026):  I just checked again and I can now see that the web page (https://wigglit.com) is showing as secure!  

Containerized Nextcloud & Owncloud

I've been using Nextcloud for several years.  I prefer Owncloud but Owncloud, IMO, is pretty arcane.  The con for Nextcloud is that it feels heavy and is slow.

Nextcloud is a PITA to maintain via snaps in Ubuntu.  Something is always breaking or not working properly and most of those issues tend to be related to snaps.

I decided to try Nextcloud via containers.  I am very surprised - it feels light and quick in comparison to installing natively on HDD.  The host system has an SSD.  I deployed it via Portainer, but I had to butcher someone  else's docker compose YML file.  The file looks ugly but I've a running system.  This is my second attempt at deploying Nextcloud as a container - the first attempt had DB access issues that I was having a difficult time sorting.

Even when importing files (videos, pictures, and music) into Nextcloud, there was less of a system load.

For now, I'll monitor the system while using it with a small subset of data (it currently has 40 GB of files).  I don't want to spend the effort of moving a massive amount of files only for the instance to die (I do have persistent volumes enabled for the container, though).  The app container is consuming 4 GB of memory, though - that's a bit high, IMO...not sure if it's experiencing a memory leak, as it's using 4 GB while idle.

UPDATE (11/14/2025):

I decided to try to deploy a containerized Owncloud instance.  The compose YML file was a bit more beefy.  It was copied from the Owncloud documentation.  

I had to deploy this one from CLI, for now...I ran into an issue that I need to sort out - once I sort it out, I'll redeploy using Portainer.

I did run into an environment setting issue.  OWNCLOUD_TRUSTED_DOMAINS needed an IP value (IP of the server itself) - the documentation is vague on this and I found the answer from within a bug report.

I thought that a containerized Nextcloud instance was quick - this server is even quicker than a containerized Nextcloud instance.

I will have a bake-off of these two instances, but I suspect I'll be again adopting Owncloud as a docker cloud app.

UPDATE (11/17/2025):

One thing that is super weird is that Owncloud won't allow uploading of directories.  To upload a directory of MP3s, for example, I've to create a folder named, "MP3s" and then upload all the files within the MP3 directory.  WTF?!  

Note that I can move folders if I use the Owncloud client software.  I'm not wanting to install the client software on every system I have.  It's like they're actively fighting to not have a directory upload feature.  With Nextcloud (and Google Drive, and OneDrive), I just have to select the folder and the whole folder is treated as an object (meaning, the the directory and it's contents will be uploaded/downloaded).  It's damned silly not to include it.  

I think I ran into the same issue years ago when I used Owncloud (like 7+ years ago!).  I researched and someone said, well it works with Google...blame the browser creators (double-WTF?!)  Nah...I'm blaming Owncloud because things like that are silly and if they're doing things like this, what else are they doing within the code?  It looks like Owncloud decided for me which to use (and it's not Owncloud).  

I'm glad I didn't manually install it, only to see the lack of directory uploading.  

Which Mac Will Be My Next System?

I've always been curious about the Mac Studio and I'd initially had that on my list of must-have systems until the new Mac Mini M4s came out.

I now have tentative plans to buy the Mac Mini M4.  I want to use that system to heavy-lift creation of my videos, as well as to maybe utilize it for housing of my Docker containers.

I love my current M1 Mini but it is a base model and I'm somewhat limited in the above-mentioned use cases.  While I can crunch video footage, I usually have to kill all other resource-intensive running processes when doing that.  I've not even tried to use Docker containers on that system, since running multiple containers usually requires a somewhat robust system (plus there's some system overhead since Docker can't natively run on Mac systems).

The real difference between the Studio and Mini would be ports and connectivity to peripherals, which would be extremely beneficial.  

As well, you can better spec out a Studio, as the platform is designed to be more open-ended as it relates to performance.  UPDATE:  Nope!!  I was wrong - I can spec out more RAM and undercut the price (drastically) of a somewhat similarly spec'd Studio.

So, my dilemma is, which one would be better for me, a high spec (lots of memory) Mini or a decently spec'd Studio?

I'm Now Managing My Docker Containers Using Portainer

Every once in awhile, I end up breaking my container setups because I sometimes get confused with all the layers and config settings (and I don't even have all that many containers), so I began to investigate management alternatives.

Of course, I'm still leveraging a locally managed Linux system (Ubuntu) to run my containers.  I've not tried to install containers on Mac hosts and I'm not even going to try with Windows.  From what I understand, I've to use a VM to run Linux on a Mac host, or use Docker Desktop.  I'd rather just use native Linux since I'm a Linux power user...anything else appears to drastically add complications, plus it's kind of stupid to install Linux on a VM when I've a bunch of Linux hosts that I can immediately leverage.

I decided to try Portainer after watching some usage videos.  It was super-simple to get it running (it's containerized) and it was super easy to shut down my existing containers and run them on Portainer - I just copied each compose.yml into Portainer to set them up as containers.  While I could see the pre-Portainer container (before I'd shut them down), they were only partially manageable with Portainer.  Building them under Portainer gave me full control, though.

As well, I found where Portainer keeps it's underlying files so that I could leverage them (if need be).  I also keep copies of my compose.yml files (I do not use Git or GitHub for my files - yet).

I'm currently using five containers (three for Wordpress, one for Pi-hole, and one for Portainer), which allows me to use Portainer's community license setup, but I've also found that I can manage the currently running containers (all five) from Portainer, without licensing agents.

Portainer is something I'm going to be using as much as possible.  I haven't even tried the other solutions but Portainer gives me a more comprehensive method of managing my containers and I'm less confused with it than via CLI; I don't even need to experiment with the other solutions.  Yes, I can manage the containers natively, via CLI (as I was doing prior to using Portainer), but I'd rather not, especially as I run more stacks (I've recently started using Nextcloud and Owncloud containers - a bake-off).  I'm finding as I manage more containers, I sometimes get lost in the thick of them.  With Portainer, I'm less lost.

Pihole & Docker FTW!

I'd been planning to mess with Pihole but didn't want to mess with a Rasberry Pi.  I did some research and found that I'd the option to install Pihole on a running Linux system.  While looking at what that entailed, I also found that I could easily do it with Docker, too.

I've been running a Ubuntu system for a while now.  It is mainly a box I set up for use with NextCloud.  I hate NextCloud and stopped using it and the Ubuntu system.  The system was pretty much idle until I decided to set up a Wordpress instance in Docker for development of my Wordpress site that's on my Linode instance.  Whenever I'm trying something new in Wordpress, I test it on my Dockerized Wordpress instance first.  Eventually I'll work on replacing the Wordpress instance on my Linode host with a Dockerized instance.

Since I already have Docker set up on the Ubuntu box, I decided to give Pihole a spin in Docker.

I used this website to set up Pihole in Docker.  The whole setup was quick and painless.  In fact, my Wordpress setup uses three different Docker containers, and with Pihole now running, I'm now using four containers on that Ubuntu host.  None of them are consuming resources (thus far).

I'm now testing Pihole.  I'm totally unfamiliar with it but it doesn't appear to be a high maintenance setup.  At some point, I'll want to back up the Pihole configs, though, so I won't have to spend a lot of time setting it up again (when/if I end up blowing away the instance).

I've several hosts on my LAN using the Pihole setup and my daughter is trying it, as well.  She had a Rasberry Pi and was planning to install Pihole on it, but I told her that this is far simpler - she should use the Pi for something else, IMO.

I've added some ad lists (block lists and some whitelisting), as well.

The biggest pain as far as adware goes is Youtube, and I don't think Pihole is going to be able to block Youtube ads when using the Youtube app.  I've had some luck blocking Youtube ads on my Macbook, but I view videos on the browser when using that notebook (and I've the uBlock Origin browser extension installed in MS Edge).

Docker, Wordpress, and Linode

Maybe a week ago, I decided to refresh my Linode instance.  I'd been using Ubuntu 16.04 LTS on it the past 10 years.  16.04 has been unsupported for quite a while now, but I was being lazy while still watching the server for possible compromises (the server was locked down very well).

Initially, I'd planned on a slow rollover to Ubuntu 24.04 LTS, by deploying a new host and slowly migrating over to it from the old server.  One day, I just said, "fuck it" and started from scratch.  I kept my old disk volume and mounted it to the new host so that I could grab old data whenever I needed it...having config files from the old host would help me when reinstalling the software I was using on the old host.

The plan was to migrate my two Wordpress sites to the new host but today I tried running Wordpress on Docker on an old Dell XPS 8930 and it worked well.  I first tried to just get to the point where Wordpress could install onto it.  I then tried to restore a backup of one Wordpress site onto the Dockerized Wordpress instance and I was immediately successful.  It happened so quickly that I spent the rest of the day testing it, to the point that I decided to do the same thing on the 24.04 server tonight.  It's now up and running and I've already been posting to it.  I'll monitor it the next few days and will probably back it up, tear down the whole thing, and then try some different setups, such as trying to run both Wordpress sites from one set of containers (the problem is, I need both Wordpress sites to be serving on port 80 and there's only one port 80 on the server.

Currently the setup is using three small containers (one for MySQL, one for Wordpress, and one for phpmyadmin).  I leveraged the YAML files of two other nerds, using both to build my own YAML file, which I used to pull the images and configure the containers.  I ran in to issues more than a few times, but between what I learned last year on acloud.guru and trial and error, it wasn't all that difficult.  What I haven't done (YET) is build my own dockerfiles.

I usually also use the Linode host as a file server (sharing pictures with friends and forums), and I was doing that using Apache, so that's a 3rd application that I'd need to use port 80...not sure how I'm going to set all this up, but the neat thing about Docker is that I can blow it away and start over (keeping my .yml compose files to work with and tweak), again and again, until I get it right.

This was the first time outside of training that I used Docker and I honestly should've been using it a long time ago.

I actually had a lot of fun doing this.

UPDATE (7/28/2024):

I'm having some issues trying to determine how to host two sites on one Dockerized Wordpress setup.  I can probably use the muti-site Wordpress setup but I need to study up on how to alter the wp-config file using the docker-compose.yml file.

Or, I can probably just run two Docker setups, one for my firearms blog and one for my car blog.

I also want to be able to share my many pictures and files using Apache, but found that I can't run Apache AND Worpdress, as both use port 80.  I may have to use some type of proxying.

Lastly, I can just reinstall Wordpress in a non-Dockerized fashion, while experimenting with Wordpress in Docker.  This is probably the more reasonable approach, as I can study up how to leverage Docker at my own leisure but have a production (and native) Wordpress setup.