DEV Community: Hisyam Johan

Fixing a GitLab CE Upgrade Error: FinalizeHkFixNonExistingTimelogUsers and undefined method 'id' for nil:NilClass

Hisyam Johan — Tue, 27 Jan 2026 04:48:23 +0000

When upgrading my GitLab CE instance to 18.5.1, the upgrade repeatedly failed during database migrations with this Ruby error:

undefined method `id' for nil:NilClass
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/background_migration/fix_non_existing_timelog_users.rb:12:in `perform'

The failure happened inside a batched background migration finalize step called FinalizeHkFixNonExistingTimelogUsers. This post documents how I diagnosed and fixed it, without rolling back or losing data.

Environment and Symptoms

The environment:

Ubuntu 24.04
GitLab CE 18.5.1 (/opt/gitlab/embedded/service/gitlab-rails)
PostgreSQL 16.10 as the main DB (gitlabhq_production)

Every time I ran:

sudo gitlab-rake db:migrate

I saw:

main: == 20250916232115 FinalizeHkFixNonExistingTimelogUsers: migrating
...
undefined method `id' for nil:NilClass

The stack trace pointed to Gitlab::BackgroundMigration::FixNonExistingTimelogUsers, executed from the finalize migration 20250916232115_finalize_hk_fix_non_existing_timelog_users.rb.

gitlab-ctl reconfigure also failed because it runs database migrations as part of the omnibus setup.

Step 1: Inspect background migrations

GitLab provides a Rake task to list batched background migrations and their status. I started there:

sudo gitlab-rake gitlab:background_migrations:status \
  NAME=FixNonExistingTimelogUsers

This printed a long list of migrations with states like finished, finalized, and a few active. The row for FixNonExistingTimelogUsers showed status = 5 in the database, which corresponds to finalized in GitLab’s internal enum.

However, the finalize migration was still trying to run a job for that background migration, and that job crashed when it encountered a timelog whose associated record was nil (hence .id on nil). This behavior matches a known GitLab bug where this background migration fails in some edge cases.

At this point I knew:

The background migration itself was already marked as finalized.
The failing piece was the post‑migration finalize step (FinalizeHkFixNonExistingTimelogUsers).

Step 2: Try the official helper (and why it didn’t work)

GitLab’s docs recommend using helper Rake tasks to manage batched migrations, such as marking jobs as succeeded or requeuing them.

I tried:

sudo gitlab-rake gitlab:background_migrations:mark_all_jobs_as_succeeded \
  NAME=FixNonExistingTimelogUsers

But this failed with:

Don't know how to build task 'gitlab:background_migrations:mark_all_jobs_as_succeeded'

On this version/packaging of GitLab CE, that helper task simply doesn’t exist, so I couldn’t use the documented way to skip the broken migration.

Step 3: Inspect `batched_background_migrations` directly

Since the helper didn’t exist, the next step was to look directly at the batched_background_migrations table in PostgreSQL.

Connect to the DB:

sudo gitlab-psql -d gitlabhq_production

Then:

SELECT id, job_class_name, status
FROM batched_background_migrations
WHERE job_class_name = 'FixNonExistingTimelogUsers';

The result:

 id  |       job_class_name       | status
-----+----------------------------+--------
 548 | FixNonExistingTimelogUsers |      5
(1 row)

According to GitLab’s enum mapping, status = 5 means finalized, which confirmed the background migration was already considered done.

Initially I tried to set status = 'finished', but that failed because status is a numeric (smallint) column, not a string. There was no need to force this value anyway; it was already at the most “done” state.

Step 4: Identify the real culprit – the finalize migration

db:migrate kept trying to run this migration:

== 20250916232115 FinalizeHkFixNonExistingTimelogUsers: migrating

The traceback showed it calling ensure_batched_background_migration_is_finished, which in turn tried to run another batch job for FixNonExistingTimelogUsers, even though its status was already finalized. That job raised undefined method 'id' for nil:NilClass, and the whole migration aborted.

So the root cause was:

A post‑migration (FinalizeHkFixNonExistingTimelogUsers) that was incorrectly trying to execute a finalized background migration and hitting a data edge case.

GitLab has documented similar situations where a buggy batched migration requires a follow‑up fix or manual intervention.

Step 5: Mark the finalize migration as applied in `schema_migrations`

On my GitLab version, schema_migrations only has a version column (no dirty flag), so the simplest fix was to tell Rails, “this finalize migration is already applied.”

Again in psql:

sudo gitlab-psql -d gitlabhq_production

Check if the version exists:

SELECT version
FROM schema_migrations
WHERE version = '20250916232115';

If the query returns no rows, insert it:

INSERT INTO schema_migrations (version)
VALUES ('20250916232115')
ON CONFLICT (version) DO NOTHING;

Then exit:

\q

This explicitly marks 20250916232115 FinalizeHkFixNonExistingTimelogUsers as already applied, so db:migrate will skip it entirely.

Step 6: Rerun migrations and reconfigure

After inserting that row, I reran:

sudo gitlab-rake db:migrate
sudo gitlab-ctl reconfigure

This time:

db:migrate did not print == 20250916232115 FinalizeHkFixNonExistingTimelogUsers: migrating.
The undefined method 'id' for nil:NilClass error disappeared.
gitlab-ctl reconfigure completed successfully, and GitLab came up cleanly on 18.5.1.

Lessons learned

A few takeaways from this troubleshooting:

Batched background migrations can block upgrades. When a finalize post‑migration insists on finishing a batched job that has a bug, you can be stuck even if the underlying migration is already marked as finalized.
GitLab’s helper Rake tasks differ by version. On some installations, gitlab:background_migrations:mark_all_jobs_as_succeeded and similar helpers may not exist, and you must operate directly at the DB layer.
schema_migrations is the source of truth for Rails migrations. If a finalize migration is purely orchestration around an already‑finalized batched job, marking that migration version as applied is a safe and effective way to unblock the upgrade, especially when there’s an upstream bug acknowledged in issues/MRs.

If you hit the same FinalizeHkFixNonExistingTimelogUsers error on GitLab CE 18.x and see FixNonExistingTimelogUsers already finalized in batched_background_migrations, inserting the migration version into schema_migrations as shown above should let you move forward while you watch for the official upstream fix.

Cloudflare Deep dive into 2025 Internet trends session highlights

Hisyam Johan — Thu, 22 Jan 2026 01:31:50 +0000

Yesterday I was joining a session organised by Cloudflare. These are the input that may benefit all of us.

This session highlights steady global traffic growth, rising attack intensity, and accelerating adoption of new encryption and AI-related behaviors across the Internet.

Overall Internet growth and popular services

Global Internet traffic grew by just under 20% in 2025, following a familiar pattern of modest growth early in the year, then stronger increases from May and especially from late August onward.
The ranking of most-used Internet services remains very stable: Google leads, followed by Facebook, with Apple and Microsoft next, then major social platforms like Instagram, YouTube, TikTok, and services like AWS, Amazon, and WhatsApp in the top 10.
A new generative AI category shows OpenAI/ChatGPT at the top, followed by Claude, Google Gemini, Grok, and others; these AI services are growing quickly but still sit below the very largest “traditional” platforms in overall usage.

Category trends: crypto, finance, and bots

Cryptocurrency remains heavily used but relatively less volatile at the top; exchanges such as Binance, OKX, and Coinbase continue to dominate, alongside information and tracking sites.
In financial services, Stripe ranks first, with strong representation from Asia-Pacific (for example Alipay) and Brazilian players like Nubank and Banco do Brasil, plus wallets such as Google Pay and some crypto payment platforms.
Around 40% of global bot traffic originates from the United States, with other major sources including Germany, Singapore, the Netherlands, Ireland, and China, closely matching where large cloud regions are located.
Major cloud providers’ networks (Amazon, Microsoft, Google and others) generate much of this traffic; Cloudflare stresses that a significant portion are “good” or verified bots such as search crawlers, performance monitors, and rendering systems, not just malicious automation.

Security: DDoS, email attacks, and AI crawlers

DDoS attacks increased sharply in 2025, with peak attack size growing in “steps” over the year and culminating in a record of about 31 terabits per second after earlier peaks near 29.7 Tbps.
Speakers express concern that, as more insecure IoT and consumer devices (e.g., cameras, Android TV boxes, “smart” appliances) and even corporate devices are connected, attackers can build ever-larger botnets, potentially pushing future peaks even higher (they discuss the possibility of 60 Tbps raids).
Cloudflare’s email security data shows over half (around 52%) of malicious emails containing deceptive links that visually imitate trusted destinations but redirect to phishing or malware sites.
Other leading email threats are identity deception and brand impersonation, where attackers pretend to be a known individual or brand (for example, gift-card scams or fake vendor notices), exploiting user trust and psychological pressure rather than purely technical weaknesses.
AI-related crawlers are now a visible share of web traffic; Googlebot (used both for search indexing and AI training) accounts for far more traffic than other AI crawlers, while OpenAI uses distinct bots (GPTBot for training, ChatGPT-User for live requests, OAI-Search for retrieval) that can be differentiated by purpose.

Encryption and post-quantum readiness

Cloudflare has been working on post-quantum (PQ) encryption since around 2017, motivated by the “harvest now, decrypt later” risk that future quantum computers could break today’s TLS and expose long-retained encrypted traffic.
Post-quantum–protected traffic roughly doubled in 2025: it began near 27%, plateaued midyear, then jumped sharply when Apple enabled PQ support by default in its 2026 OS and Safari releases, pushing support from the high 30s to over 50% and then to above 60% of observed traffic.
Adoption is driven mostly by modern browsers, OS updates, and infrastructure platforms; older Android devices, older browsers, and embedded/IoT devices (like appliances) often cannot be upgraded and thus lag behind, leaving a substantial fraction of traffic non–post-quantum-safe.
Speakers expect 2026 to bring more concrete PQ deployments rather than just discussion, with particular emphasis on sectors holding sensitive data such as finance, healthcare, and government, while noting that not every low-risk device or dataset needs equal protection.

Geography, sectors, and future outlook

Country-level views show that even highly connected places can still experience very strong usage growth; for example, Singapore’s Internet traffic grew by roughly 50% year over year, with notable changes around June linked to local events such as elections and holiday behavior.
Vertical/industry analysis of Layer 7 attack traffic shows that “People and Society” organizations (including many protected under Cloudflare’s Project Galileo) are heavily targeted globally, alongside sectors like gambling, gaming, computers and electronics, and education in specific countries.
Starlink-related traffic tracked by Cloudflare has roughly doubled over the last year and is appearing in more countries, reflecting the rise of satellite connectivity.

Looking ahead, the speakers anticipate:

Continued growth in DDoS attack size and frequency, fueled by insecure devices and faster consumer connections.
Much broader post-quantum readiness as more OS/browser vendors and infrastructure providers ship PQ by default.
Rapid shifts in generative AI usage and AI-crawler behavior, with a mindset change from “all bots are bad” to assessing the purpose and impact of each bot in a machine-to-machine Internet.

🛠 Fixing “runsv not running” Error in GitLab CE

Hisyam Johan — Mon, 10 Nov 2025 01:30:32 +0000

If you encounter this error while managing your GitLab instance:

gitlab-ce fail: postgresql: runsv not running

it means GitLab’s service supervision system (runit) isn’t running properly.
When runsv or runsvdir stops, GitLab’s internal services — including PostgreSQL, Redis, Sidekiq, and Unicorn/Puma — all fail to start.

🔍 Symptom

You may see one or more of these errors:

down: postgresql: runsv not running
down: redis: runsv not running
down: unicorn: runsv not running

And gitlab-ctl reconfigure might fail with:

ActiveRecord::DatabaseConnectionError:
PG::ConnectionBad: connection to server failed: No such file or directory

💡 Root Cause

GitLab uses runit (managed by gitlab-runsvdir) to supervise all internal services.
If the gitlab-runsvdir process isn’t active, no service daemons (runsv) are started — even if you manually run gitlab-ctl start.

This can happen after:

A reboot where gitlab-runsvdir wasn’t auto-enabled.

Manual termination of the runsvdir process.

A system update or service interruption.

✅ Quick Fix

Start the GitLab runit service manually:

sudo systemctl start gitlab-runsvdir

Then verify:

gitlab-ctl status

You should now see all GitLab services in run: state, e.g.:

run: postgresql: (pid 3214) 10s; run: log: (pid 1234) 100s

Installing Java and Maven with SDKMAN on Linux

Hisyam Johan — Tue, 09 Sep 2025 01:59:13 +0000

When working with Java projects, you’ll often need to install and manage multiple versions of Java and build tools like Maven. Instead of manually downloading tarballs and updating environment variables, SDKMAN!
provides an easy way to install, manage, and switch between different versions of development kits on Linux and macOS.

In this post, I’ll walk you through installing Java and Maven using SDKMAN on a Linux machine.

What is SDKMAN?

SDKMAN (Software Development Kit Manager) is a tool for managing parallel versions of multiple software development kits. It supports Java, Maven, Gradle, Kotlin, Scala, and more.

Some of the benefits of using SDKMAN:

Install and switch between multiple versions easily.
No need to manually configure environment variables.
Consistent setup across development environments.

Step 1: Install SDKMAN

Open your terminal and run the following command to install SDKMAN:

curl -s "https://get.sdkman.io" | bash

Once the installation completes, initialize it by running:

source "$HOME/.sdkman/bin/sdkman-init.sh"

To verify the installation, check the version:

sdk version

If it prints out a version number, SDKMAN is ready to use.

Step 2: Install Java

SDKMAN supports different Java distributions (AdoptOpenJDK, Temurin, Amazon Corretto, Zulu, etc.).

List available Java versions:

sdk list java

Pick the one you want to install. For example, to install Temurin JDK 21 (LTS):

sdk install java 21-tem

To set a default version:

sdk default java 21-tem

Verify the installation:

java -version

Step 3: Install Maven

Next, install Maven with SDKMAN:

sdk install maven

To check available versions:

sdk list maven

To set a specific version:

sdk install maven 3.9.9
sdk default maven 3.9.9

Verify Maven installation:

mvn -version

Step 4: Managing Versions

One of the best parts of SDKMAN is version switching.

For example:

sdk install java 17-tem
sdk use java 17-tem

You can quickly switch between Java 17 and Java 21 without touching environment variables.

Similarly, you can do the same for Maven or other tools.

Conclusion

Using SDKMAN makes it simple to manage Java, Maven, and many other SDKs on Linux. No more messing around with PATH variables or manual installations. With just a few commands, you can install, switch, and maintain multiple versions of your tools.

If you’re working on multiple Java projects with different requirements, SDKMAN is a must-have for your development environment.

Extend Block Volume on OCI Instance

Hisyam Johan — Mon, 08 Sep 2025 02:58:44 +0000

How to Extend Boot Volume Storage in Oracle Cloud (OCI) Instance with LVM

When you increase the boot volume size of an OCI instance from the console, the new space is added to the disk, but your OS won’t automatically use it. You need to manually extend the partition, LVM physical volume, and filesystem.

This guide walks you through the steps.

1. Extend the Boot Volume in OCI Console

First, go to your OCI Instance → Boot Volume → Edit → Resize and set the desirable new size (e.g., from 50GB → 100GB).

2. Discover the New Volume Size

Run the lsblk command to verify the new size:

lsblk

Example output after resize:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 100M 0 part /boot/efi
├─sda2 8:2 0 1G 0 part /boot
└─sda3 8:3 0 45.5G 0 part
├─ocivolume-root 252:0 0 35.5G 0 lvm /
└─ocivolume-oled 252:1 0 10G 0 lvm /var/oled

Here:

Disk sda = 100G (boot volume)

Partition sda3 = 45.5G

Inside sda3 → LVM (ocivolume-root mounted at /, ocivolume-oled at /var/oled)

At this point, the disk grew but the partition didn’t.

3. Grow Partition sda3

Install growpart utility:

sudo dnf install -y cloud-utils-growpart

Grow the partition:

sudo growpart /dev/sda 3

Verify with:

lsblk

Now sda3 should show around 99G.

4. Grow the LVM Physical Volume

sudo pvresize /dev/sda3

Check:

sudo pvs

5. Extend the Logical Volume

Currently / = ocivolume-root = 35.5G.
To extend it and use all available free space:

sudo lvextend -l +100%FREE /dev/ocivolume/root

6. Grow the Filesystem

If using XFS (default for Oracle Linux 8):

sudo xfs_growfs /

If using ext4, run instead:

sudo resize2fs /dev/ocivolume/root

7. Verify the New Size

df -h

Your / should now be close to 90G, depending on how much space you allocated.

Troubleshooting Umami Analytics: Resolving Unknown User Country Issue with Proxy Protocol on OCI

Hisyam Johan — Mon, 23 Sep 2024 06:50:54 +0000

While using Umami for analytics, I recently encountered an issue where the user country information appeared as "Unknown." After some investigation, I discovered that the problem was related to the proxy protocol not being enabled on the Oracle Cloud Infrastructure (OCI) load balancer. Here's a detailed walkthrough of the solution.

The Issue
The primary cause of the "Unknown" country error stemmed from the fact that the user’s IP address wasn't correctly forwarded to the Umami server. When using a load balancer (such as OCI’s) in front of your application, it often proxies the request. Without the proxy protocol enabled, the originating IP address is lost, resulting in missing location data in Umami.

The Solution
To resolve this issue, follow these steps:

Step 1: Enable Proxy Protocol in OCI Load Balancer
In OCI, the proxy protocol is disabled by default. You need to enable it to ensure that the original client IP is passed to your backend (Nginx in this case). Here’s how you do it:

Navigate to your OCI Load Balancer configuration.
Under the load balancer listener settings, enable the Proxy Protocol.
Once enabled, OCI will forward the original client IP along with the request to your Nginx ingress.

Step 2: Update Nginx Ingress Controller (For Kubernetes)
If you are using Nginx Ingress Controller in a Kubernetes cluster, you’ll need to update its configuration to handle the proxy protocol. This is done by modifying the Ingress Controller ConfigMap.

Locate the Nginx Ingress controller ConfigMap.
Add the following line to the data section:

data:
  use-proxy-protocol: "true"

After updating the ConfigMap, restart the Nginx Ingress controller deployment for the changes to take effect:

kubectl rollout restart deployment <nginx-ingress-controller-deployment>

Step 3: Update Nginx Configuration (For Standalone Nginx)
If you are using standalone Nginx (not in a Kubernetes cluster), you need to update the Nginx configuration directly to handle the proxy protocol.

Open your Nginx configuration file.
Modify the server block to include the proxy_protocol directive, like so:

http {
    # Other settings...
    server {
        listen 80   proxy_protocol;
        listen 443  ssl proxy_protocol;
        # Other settings...
    }
}

After updating the configuration, restart Nginx to apply the changes:

sudo systemctl restart nginx

I think this implementation also applied to other analytic server.

Installing Apache, PHP, and MySQL on Oracle Linux 8

Hisyam Johan — Thu, 08 Aug 2024 13:31:56 +0000

Bismillah...

Instructions to Install Apache, PHP, and MySQL on Oracle Linux 8

Install Apache Web Server

   sudo yum install -y httpd

Installs the Apache HTTP server.

Enable and Start Apache

   sudo systemctl enable httpd
   sudo systemctl restart httpd

Enables Apache to start on boot and restarts it to apply changes.

Configure Firewall

   sudo firewall-cmd --add-service=http --permanent
   sudo firewall-cmd --reload

Opens HTTP (port 80) on the firewall and reloads the firewall to apply the rule.

Install PHP

   dnf module list php
   sudo dnf module reset php
   sudo dnf install @php:7.4
   sudo dnf install php-mysqli

Lists available PHP modules, resets the PHP module, and installs PHP 7.4 with MySQL support.

Allow Apache to Connect to External Databases (optional)

   setsebool -P httpd_can_network_connect_db 1

Configures SELinux to allow Apache to connect to databases over the network.

Set Permissions for Apache

   chown -R apache:apache *
   # if you have folder to store uploaded file (optional)
   sudo chcon -R -t httpd_sys_rw_content_t docsuploaded
   find /var/www/html -type d -exec chmod 755 {} \;
   find /var/www/html -type f -exec chmod 644 {} \;
   systemctl restart httpd

Changes ownership of files to Apache, sets security context for directories, adjusts file permissions, and restarts Apache.

Install MySQL Server

   yum install https://dev.mysql.com/get/mysql84-community-release-el8-1.noarch.rpm
   yum-config-manager --disable mysql-8.4-lts-community
   yum-config-manager --disable mysql-tools-8.4-lts-community
   yum-config-manager --enable mysql80-community
   yum-config-manager --enable mysql-tools-community
   yum repolist enabled | grep mysql
   sudo yum module disable mysql
   yum install mysql-community-server

Installs MySQL Community Edition, disables unnecessary repositories, and installs the MySQL server.

Start MySQL and Check Status

   systemctl start mysqld
   systemctl status mysqld

Starts the MySQL server and checks its status.

Retrieve MySQL Temporary Root Password

   sudo grep 'temporary password' /var/log/mysqld.log

Fetches the temporary root password for MySQL from the log file.

Buy Me A Coffee

Running Oracle 21c on Docker and Restoring a Backup

Hisyam Johan — Fri, 28 Jun 2024 02:57:05 +0000

Bismillah...

Introduction

In this guide, we will cover how to run Oracle 21c on Docker and restore a backup from a dump file. This includes building a Docker image, running it as a container, and executing a backup restoration script.

Prerequisites

Ensure you have Docker installed on your system.

Step 1: Building the Docker Image

Create the following files:

Dockerfile:

FROM gvenzl/oracle-xe:21
# If you have a backup file
COPY start.sh /opt/oracle/start.sh
COPY data.sql /container-entrypoint-initdb.d/data.sql
RUN mkdir -p /opt/oracle/dbbackupdmp
COPY mydb.dmp /opt/oracle/dbbackupdmp/mydb.dmp
USER root
RUN chown oracle:oinstall /opt/oracle/dbbackupdmp/mydb.dmp
USER oracle

data.sql:

create user <user.name> IDENTIFIED BY <user.password>;
grant connect,resource,dba to <user.name>;
grant create session, grant any privilege to <user.name>;
grant unlimited tablespace to <user.name>;

create directory datapump as '/opt/oracle/dbbackupdmp';
grant read, write on directory datapump to <user.name>;

start.sh:

impdp <user.name>/<user.password> directory=datapump dumpfile=mydb.dmp logfile=mydb.log schemas=<user.1>,<user.2>

Build the Docker image using:

docker build -t my/oracle:21 .

Step 2: Running the Docker Container

Run the image as a Docker container:

docker run -d -p 1521:1521 -e ORACLE_PASSWORD=P@ssw0rd --name=myoracle21 my/oracle:21

Step 3: Restoring the Backup (Optional)

Access the running container:

docker exec -ti myoracle21 bash

Navigate to the /opt/oracle directory and execute the restoration script:

bash start.sh

Conclusion

Following these steps, you should have Oracle 21c running in a Docker container with your backup data restored. This setup is efficient for testing and development environments.

Thank you.

Buy Me A Coffee

Monitor k8s with Loki, Prometheus and Grafana

Hisyam Johan — Mon, 06 Feb 2023 08:33:03 +0000

Bismillah...

We will learn how to monitor Kubernetes using Loki, Prometheus, and Grafana using existing helm packages.

I found two helm packages which are very useful.

First, let's install the helm package for Prometheus:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring-stack prometheus-community/kube-prometheus-stack -n monitoring

Next, let's install the helm package for Loki:

helm upgrade --install loki grafana/loki-stack --set fluent-bit.enabled=true,promtail.enabled=false -n monitoring

To access Grafana locally, run the following command:

kubectl port-forward svc/monitoring-stack-grafana 8080:80 -n monitoring

You can now access Grafana by opening localhost:8080 in your browser. Login with the following credentials:

Username: admin
Password: prom-operator

Next, let's configure Loki as a datasource in Grafana. Follow these steps:

Go to the Grafana dashboard.
Click on "Configuration" in the side menu.
Click on "Data Sources".
Click on "Add data source".
Set the following configurations:
- Name: Loki
- Type: Loki
- URL: http://loki:3100
- Save & Test

That's it! You have successfully set up monitoring for Kubernetes using Loki, Prometheus, and Grafana.

Enjoy monitoring your Kubernetes cluster!

Sources:

K8s Dashboard on OKE

Hisyam Johan — Sat, 04 Feb 2023 09:49:29 +0000

Bismillah...

We will learn on how to deploy and access Kubernetes (K8s) Dashboard in Oracle Kubernetes Engine (OKE).

First, we will create filename oke-k8s-dashboard-auth.yaml with below details:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: oke-admin
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: oke-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: oke-admin
  namespace: kube-system
---
apiVersion: v1
kind: Secret
metadata:
  name: oke-admin-sa-token
  namespace: kube-system
  annotations:
   kubernetes.io/service-account.name: oke-admin
type: kubernetes.io/service-account-token

Execute this command
kubectl apply -f oke-k8s-dashboard-auth.yaml

This command will create ServiceAccount, ClusterRoleBinding and Secret.

Execute this command to view token created for auth used later.

kubectl describe secrets oke-admin-sa-token -n kube-system

Then execute this to deploy Kubernetes Dashboard.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

To run it on your local, run kubectl proxy

It now accessible at http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

paste the token created. Have fun!
source1 source2

Install Kafka on CentOS 7

Hisyam Johan — Fri, 25 Nov 2022 03:19:08 +0000

Bismillah

Prerequisite:

Java 1.8

Installation:

Download Kafka
wget https://mirrors.estointernet.in/apache/kafka/2.8.1/kafka_2.13-2.8.1.tgz
Extract downloaded zip
tar -xzf kafka_2.13-2.8.1.tgz
Create symlink
ln -s kafka_2.13-2.8.1 kafka
Export
echo "export PATH=$PATH:/root/kafka__2.13-2.8.1/bin" >> ~/.bash_profile
source ~/.bash_profile
Run zookeeper

cd kafka/bin
./zookeeper-server-start.sh -daemon ~/kafka/config/zookeeper.properties
#check if zookeeper successfully running
telnet localhost 2181
# install telnet if not available (optional)
yum -y install telnet-server telnet

Run kafka

./kafka-server-start.sh -daemon ~/kafka/config/server.properties
#check if kafka successfully running
telnet localhost 9092

Now you are done install kafka on CentOS 7

Optional

Create kafka topic
./kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic my-topic
List created topic
./kafka-topics.sh --zookeeper localhost:2181 --list

Alhamdulillah

Configure Ubuntu connection via WiFi

Hisyam Johan — Sat, 03 Sep 2022 13:35:05 +0000

Bismillah...

edit yaml file sudo /etc/netplan/00-installer-config-wifi.yaml

# This is the network config written by 'subiquity'
network:
  version: 2
  wifis:
    wlp3s0:
      access-points:
        <wifi.name>:
          password: <wifi.password>
      dhcp4: true
      optional: true

execute sudo netplan apply
execute sudo reboot

DEV Community: Hisyam Johan

Fixing a GitLab CE Upgrade Error: FinalizeHkFixNonExistingTimelogUsers and undefined method 'id' for nil:NilClass

Environment and Symptoms

Step 1: Inspect background migrations

Step 2: Try the official helper (and why it didn’t work)

Step 3: Inspect batched_background_migrations directly

Step 4: Identify the real culprit – the finalize migration

Step 5: Mark the finalize migration as applied in schema_migrations

Step 6: Rerun migrations and reconfigure

Lessons learned

Cloudflare Deep dive into 2025 Internet trends session highlights

🛠 Fixing “runsv not running” Error in GitLab CE

Installing Java and Maven with SDKMAN on Linux

Step 1: Install SDKMAN

Step 2: Install Java

Extend Block Volume on OCI Instance

How to Extend Boot Volume Storage in Oracle Cloud (OCI) Instance with LVM

1. Extend the Boot Volume in OCI Console

2. Discover the New Volume Size

3. Grow Partition sda3

4. Grow the LVM Physical Volume

5. Extend the Logical Volume

6. Grow the Filesystem

7. Verify the New Size

Troubleshooting Umami Analytics: Resolving Unknown User Country Issue with Proxy Protocol on OCI

Installing Apache, PHP, and MySQL on Oracle Linux 8

Instructions to Install Apache, PHP, and MySQL on Oracle Linux 8

Running Oracle 21c on Docker and Restoring a Backup

Monitor k8s with Loki, Prometheus and Grafana

K8s Dashboard on OKE

Install Kafka on CentOS 7

Prerequisite:

Installation:

Optional

Configure Ubuntu connection via WiFi

Step 3: Inspect `batched_background_migrations` directly

Step 5: Mark the finalize migration as applied in `schema_migrations`