Some time later, I got sick of gaming and made a decision to rebuild it into a self-hosting server. The PC moved from my table to an under-TV shelf in the living room. And here, glowing lights became distracting during watching TV or when we have guests sleeping in the living room. Therefore, I started searching for ways to control/disable RGB lights.

After some search, I encountered OpenRGB. It’s open-source RGB control software that is independent from manufacturer software. It supports color syncing across several devices and has a community-managed effects library. It has a long list of more than 2,500 supported devices and, hopefully for me, my Corsair Vengeance was there!

What a great piece of software, right?

It’s a shame that I needed this software only to disable RGB.

Installing OpenRGB

OpenRGB runs on Linux, macOS, and Windows. You can download the package for your operating system from the releases page.

On my Debian-based server, I downloaded the .deb package and installed it with:

sudo apt install ./OpenRGB-<version>-x86_64.deb

The package includes the required udev rules. If you use an AppImage, Flatpak, or a build from source, install the udev rules too. Without them, OpenRGB may not be able to access the RGB hardware without running as root.

Before creating the service, check that OpenRGB can detect your devices:

sudo openrgb --list-devices

Make a note of the device numbers you want to control. Mine were 0 and 1.

Configuring

I needed the RGB to turn off every time the system starts. So I ended up with the following systemd service.

First, test the command manually. 000000 is black, which turns the LEDs off. The direct mode is supported by my devices; use the output of --list-devices to check which modes yours support.

sudo openrgb -d 0 -c 000000 -m direct -d 1 -c 000000 -m direct

When that worked, I created the service below.

/etc/systemd/system/openrgb.service:

[Unit]
Description=OpenRGB control

[Service]
Type=oneshot
ExecStart=/usr/bin/openrgb -d 0 -c 000000 -m direct -d 1 -c 000000 -m direct
User=root
Group=i2c

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable openrgb
systemctl start openrgb

Now the RAM lights turn off automatically on every boot. No proprietary RGB application, no running desktop session, and no bright lights in the living room.

Final thoughts

If you have devices with RGB lights, check whether they are supported by OpenRGB. You might find a more creative use for it than I did and build some nice RGB animations.

This setup worked well for a while, but then became outdated due to the instability of USB dongles and the planned deprecation of 2G and 3G networks in Europe.

One day, I got tired of replugging USB modems and manually restarting containers, so I decided to look for a new solution.

First, I thought I would build my own device using existing 4G modules for an ESP32 or a Raspberry Pi, but I quickly discovered it would cost me a fortune to support two or more SIM cards.

Then I looked for off-the-shelf solutions. I found some cool 8/16/32+ SIM support boxes from Chinese vendors. But again, they were pricey, and I didn’t need so many SIM cards.

After that letdown, I returned to the old, forgotten idea of using a dedicated Android device for my task.

Device

I didn’t have a spare Android device at home, so I looked for a second-hand working one with two SIM slots on Wallapop.

I ended up buying a Moto E14 for €25.

I tried to root it as soon as I received it, mostly out of curiosity and to gain better control over my device. But I was unable to find a working solution for that.

So I gave up and tried to configure everything without root access.

Spoiler: I succeeded. No root was needed.

Software

I had two SIM cards, and the current setup forwarded SMS messages to different Telegram channels.

I looked for an app that would allow me to do so. I considered the telegram-sms app, but after a quick look, it seemed not to support splitting SMS messages into separate chats.

In the end, I chose to go with an android_income_sms_gateway_webhook. It does not support Telegram specifically, but it lets you configure a webhook that can call any service, including Telegram.

However, to split SMS messages from different SIM cards into separate channels, I needed to implement a webhook handler, which took Codex about five minutes.

Here is a link to the GitHub repository: github.com/alikhil/sms-forwarder-telegram-webhook

It is a simple, stupid Python web server that parses the JSON and sends two JSON requests to Telegram servers for the right channel.

I deployed the webhook handler in my homelab using Docker Compose, and it became the bridge between the Android app and Telegram:

services:
  sms-webhook:
    build: https://github.com/alikhil/sms-forwarder-telegram-webhook.git#main
    restart: always
    environment:
      DEFAULT_TARGET_CHAT_ID: -88005553535
      SIM1_TARGET_CHAT_ID: -100500
      SIM2_TARGET_CHAT_ID: -100500800
    env_file:
      - .env # includes TELEGRAM_BOT_TOKEN
    ports:
      - "8000:8000"

I configured the app to send SMS messages:

That’s it. The SMS forwarding path was working end-to-end.

Monitoring

After the pain of previous solutions, I wanted to be notified if something failed.

If I did not receive an SMS that I was expecting, I would not know that I had missed it. The app might crash, or the battery might run low.

Fortunately, the SMS gateway app supports sending heartbeats.

I set up a Uptime Kuma monitor and configured the app to send heartbeats every 5 minutes. Kuma expects a heartbeat every 5 hours.

The values were tuned empirically because the app does not strictly follow the schedule. As I understand it, this is a technical limitation of the app running in the background.

But it is okay for me, even if I learn about a failure after twice the normal interval.

Power management

I didn’t want my Android device connected to a power supply all the time because I believed the battery health would suffer as a result.

Also, I didn’t want to connect and disconnect it manually every time. I’m an engineer, after all. It must be automated.

I wanted it to work like this:

• If the battery level is below 20%, connect the power.
• If the battery level is above 90%, disconnect the power.

I had a spare smart and controllable Shelly Plug that I could use for such automation.

I could probably use one of the Home Assistant plugins to implement it, but I don’t use Home Assistant and didn’t want to install it just for this small use case. That would be overkill.

The next step was to find Android apps that could send a webhook when the battery reached a certain level.

There were surprisingly few decent apps for this. It seems like a very niche use case.

The only thing I found was Android Remote Notify. And, of course, I couldn’t configure Shelly automation directly there.

So, Codex handled another simple webhook handler that calls the Shelly Plug API when the battery reaches a certain level.

services:
  battery-webhook:
    build: https://github.com/alikhil/android-remote-notify-webhook-handler.git#main
    restart: always
    environment:
      SHELLY_PLUG_URL: http://192.168.99.88 # Your shelly plug IP
      PORT: 8080
      LOW_BATTERY_THRESHOLD: 20
      HIGH_BATTERY_THRESHOLD: 90
    ports:
    - 8080

Only after I had configured and deployed everything did I realize the app had a major limitation: it did not have a way to trigger an alert when the battery level exceeded 90%. It only supported a lower-bound threshold.

I didn’t want to search for another solution when I was so close to completing the current one. Luckily for me, the app was open source.

I concluded that a simpler approach would be to send battery level periodically, and the webhook handler controlled the plug based on those reports.

I prompted Codex in the repository to develop the new feature.

After 15 minutes of hacking, it produced a solution. I didn’t have a full Android development setup, and I didn’t want to bloat my Mac with it.

So I asked Codex to build the APK inside Docker. Five more minutes and it was done.

I replaced the app with the custom patched build, and it worked.

I went ahead and created a pull request to upstream, and it was accepted. As a nice bonus, I no longer need to maintain a fork.

To be fair, heartbeats and battery-level webhooks were not coming on a strict schedule.

To monitor the webhook handler, I built a page that reports things like:

• When the last state was reported
• What the battery level was at that time
• The last command sent to Shelly.
• Etc.

Caveats

During webhook testing, I encountered an issue where both Android apps struggled to send requests to an insecure HTTP endpoint.

There is probably a configuration option somewhere that allows such behavior.

I simply routed the traffic through my custom domain with Let’s Encrypt certificates.

Final thoughts

It was my first time tinkering with Android, and I enjoyed it. I expected it to require more hassle.

Happy hacking!

This workaround never felt right. As an engineer, I wanted a solution that reflected the actual lifecycle of an application rather than its worst moment.

I opened an issue in the Kubernetes repository describing the problem and proposing an approach to adjust pod resources dynamically without restarts. The issue received little discussion but quietly accumulated interest over time (13 👍 emoji reaction). Every few months, an automation bot attempted to mark it as stale, and every time, I removed the label. This went on for nearly six years…

Until the release of Kubernetes 1.35 where In-Place Pod Resize feature was marked as stable.

What In-Place Pod Resize Brings

In-Place Pod Resize allows Kubernetes to update CPU and memory requests and limits without restarting pods, whenever it is safe to do so. This significantly reduces unnecessary restarts caused by resource changes, leading to fewer disruptions and more reliable workloads.

For applications whose resource needs evolve over time, especially after startup, this feature provides a long-missing building block.

Impact on VerticalPodAutoscaler

The new resizePolicy field is configured at the pod spec level. While it is technically possible to change pod resources manually, doing so does not scale. In practice, this feature should be driven by a workload controller.

At the moment, the only controller that supports in-place pod resize is the Vertical Pod Autoscaler (VPA).

There are two enhancement proposals enable this behavior:

• AEP-4016: Support for in place updates in VPA which introduces InPlaceOrRecreate update mode

• AEP-7862: CPU Startup Boost which is about temporarily boosting pod by giving more cpu during pod startup. This is conceptually similar to the approach proposed in my original issue.

Here is an example of Deployment and VPA using both AEP features:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: app
          image: my-heavy-java-app:stable
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 1000m
              memory: 1024Mi
            limits:
              cpu: 2000m
              memory: 2048Mi

---

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  resourcePolicy:
    containerPolicies:
      - containerName: "app"
        minAllowed:
          cpu: "250m"
          memory: "512Mi"
        maxAllowed:
          cpu: "3000m"
          memory: "8192Mi"
        # The CPU boosted resources can go beyond maxAllowed.
        startupBoost:
          cpu:
            type: "Factor"
            quantity: "2"

With such configuration pod will have doubled cpu requests and limits during startup. During the boost period no resizing will happen.

Once the pod reaches the Ready state, the VPA controller scales CPU down to the currently recommended value.

After that, VPA continues operating normally, with the key difference that resource updates are applied in place whenever possible.

Limitations

Does this feature fully solve the problem described above? Only partially.

First, most application runtimes still impose fundamental constraints. Java and Python runtimes do not currently support resizing memory limits without a restart. This limitation exists outside of Kubernetes itself and is tracked in the OpenJDK project via an open ticket.

Second, Kubernetes does not yet support decreasing memory limits, even with in-place Pod Resize enabled. This is a known limitation documented in the enhancement proposal for memory limit decreases.

As a result, while in-place Pod Resize effectively addresses CPU-related startup spikes, memory resizing remains an open problem.

Final thoughts

In place Pod Resize gives a foundation for cool new features like StartupBoost and makes use of VPA more reliable. While important gaps remain, such as memory decrease support and scheduling race condition, this change represents a meaningful step forward.

For workloads with distinct startup and steady-state phases, Kubernetes is finally beginning to model reality more closely.

Why?

First of all, why should you contribute to open source?

Giving back

Everyone, from freelance engineers to Big Tech companies and even governments, uses Open Source Software (OSS). Some use it less, others more, but almost everyone depends on it in one way or another. Most of us are consumers of open source.

Contributing to OSS means giving something back. This is especially important given the many cases of projects (e.g nginx-ingress, external-secrets) being deprecated due to maintainer burnout, lack of community support, or overwhelming workloads.

It is true that some OSS projects are backed by large companies and maintained by engineers who are paid to work on them. However, the half of open source projects are still maintained by individuals in their spare time for free (source).

In this sense, contributing to OSS can be seen as a form of digital volunteering. Some companies (Criteo, Futurice) even offer paid volunteer time (VPTO) specifically for open-source contributions.

Learning

Another strong reason to contribute to open source is personal growth.

Every contribution becomes a learning opportunity because it places you inside a real, production-grade codebase rather than a controlled tutorial environment. You learn how projects are structured, how architectural decisions are made, how backward compatibility is maintained, and how trade-offs are handled in practice. Often this means working with unfamiliar tools, languages, or ecosystems, which naturally expands your technical range.

At the same time, open source strongly develops communication and collaboration skills. Issues and pull requests force you to articulate problems clearly, propose solutions in a way others can evaluate, and explain why a particular approach makes sense. Feedback from maintainers and contributors exposes you to different perspectives and constraints, requiring you to adapt, clarify, and sometimes rethink your ideas.

Because most collaboration happens asynchronously and in writing, you also improve your ability to communicate precisely and concisely. Over time, this structured, public collaboration sharpens how you discuss technical topics, handle reviews, and work effectively with distributed teams. These are the same skills required in modern engineering organizations, making open source a highly practical training ground.

Networking and professional reputation

Open source contribution naturally leads to networking, even if you are not actively trying to “network.” By participating in issues, code reviews, and pull requests, you start interacting with maintainers and contributors from different companies, countries, and levels of seniority. Over time, these repeated interactions build familiarity and trust. People begin to recognize your name, your areas of expertise, and the quality of your work.

Regular contributions can turn these lightweight interactions into professional relationships. Maintainers may invite you to collaborate more closely, grant you additional responsibilities, or even recommend you for roles on their teams. In many cases, job opportunities arise not from formal applications, but from someone already knowing how you work.

Another important, and often underestimated, benefit of open source contribution is visibility. Most professional work is hidden behind NDAs and internal repositories, making it difficult to demonstrate your real impact. Open source work, on the other hand, is public by default. Your commits, pull requests, discussions, and design decisions are all visible and attributable to you.

This public track record allows you to clearly show not only what you built or improved, but also how you collaborate, communicate, and respond to feedback. For recruiters and hiring managers, this is far more convincing than a list of skills on a résumé. In practice, open source contributions often function as a living portfolio and a long-term investment in your professional reputation.

How?

Now that you understand why contributing matters, let’s look at how to get started.

The Natural way

You might think that contributing to open source requires skills you do not have, a brilliant idea for a new library, or deep expertise in a specific domain. These beliefs often make OSS contribution feel unreachable.

That is not the case.

You do not need a revolutionary idea or special credentials. If you are an engineer who already writes code, you are capable of contributing.

Here is a simple approach: the next time you are solving a problem using an open source tool and notice that it does not work as expected (a bug) or lacks a feature you need, do not immediately abandon the tool. Use your skills, and an LLM if needed, to investigate and try to fix the issue.

If you succeed, open a pull request to the upstream repository. If you do not, create an issue and share your findings. That is still a contribution, and you will have learned something in the process.

Good first issue

If everything you use works perfectly and you do not notice any gaps, you can take a more deliberate approach.

Make a list of projects you like, use, or want to learn more about. Browse their open issues and look for ones labeled “good first issue” or similar. Pick something that matches your current skill level and try to tackle it.

If your list is short or you cannot find suitable issues, there are also curated lists of projects actively looking for contributors.

• https://goodfirstissue.dev/
• https://forgoodfirstissue.github.com/
• https://goodfirstissues.com/

Summary

Open source is great, but keeping it that way requires people to contribute. It is not hard or unreachable. Anyone can do it, and the community needs more people like you. Start small, pick a project you love, and take your first step

The problem

As engineer who works with kubernetes everyday I use kubectl a lot. Actually, more than 50% of my terminal history commands are related to kubernetes. Here is a top 10 commands:

1	2079  46.7611%    kubectl
2	425   9.55915%    git
3	324   7.28745%    helm
4	156   3.50877%    cd
5	146   3.28385%    ssh
6	130   2.92398%    kctx
7	114   2.5641%     kns
8	80    1.79937%    gcloud-auth
9	78    1.75439%    curl
10	66    1.48448%    docker
...

Run this command if you are curious what about yours the most popular commands in terminal history.

I use kubectl to check status of the pods, delete orphaned resources, trigger sync on ExternalSecrets and much more. When I realized half my terminal history was just kubectl commands, I thought — there must be a better way to find things in Kubernetes without chaining pipes with grep / awk / xargs. And I imagined how nice it would be to have a UNIX find-like tool — something that lets you search for exactly what you need in the cluster and then perform actions directly on the matching resources. I searched for a krew plugin like this but there was not any. For that reason, I decided to develop one!

Development

I used sample-cli-plugin as a starting point. Its clean repository structure and straightforward design make it a great reference for working with the Kubernetes API. Additionally, it allows easy reuse of the extensive Kubernetes client libraries.

Almost everything in the Kubernetes ecosystem is written in Go, and this plugin is no exception — which is great, as it allows building binaries for a wide range of CPU architectures and operating systems.

Features overview

Filters

Find by resource name using regex

kubectl fd pods -r dev

Find pods with restarted containers

kubectl fd pods --restarted

Find pods with image matching regex

kubectl fd pods --image bitnami

Find pods by status

kubectl fd pods --status Pending

Find pods running on nodes matching regex

kubectl fd pods --node '*spot'

Find any resource by custom condition

Use jq filter to find any resource by any custom condition. kubectl-find uses gojq implementation of jq.

# find Services with trafficDistribution set to PreferClose
kubectl fd svc -j '.spec.trafficDistribution == "PreferClose"'

# find pods with unset nodeSelector
kubectl fd pods -j '.spec.nodeSelector == null' -A

# find pods with undefined resources
kubectl fd pods -j 'any( .spec.containers[]; .resources == {} )' -A

Actions

By default, fd will print found resources to Stdout. However, there flags that you can provide to perform action on found resources:

• --delete - to delete them
• --patch - to patch with provided JSON
• --exec - to run command on pods

Getting started

Use krew to install the plugin:

krew install fd

What’s next

I’m currently working on adding:

• JSON/YAML output format
• More filters
• Saved queries

If you’re tired of writing long kubectl | grep | xargs chains, give kubectl fd a try — it’s already saved me countless keystrokes.

Check out the repo ⭐ github.com/alikhil/kubectl-find and share your ideas or issues — I’d love to hear how you use it!

Update (August 2026): ingress-nginx is being retired. For a new installation, use the Gateway API, Traefik, OAuth2 Proxy, and Pocket ID version of this guide. Keep reading only if you are maintaining an existing ingress-nginx setup.

What we have

We have a Kubernetes cluster with several web services deployed for internal use.

What we want to achieve

We want to expose our internal web services to the Internet, but restrict access by requiring authorization. Access should be granted only to users authenticated through our Identity Provider (such as Google, GitHub, Keycloak, etc.).

Assumptions

For simplicity, let’s assume that both ingress-nginx and cert-manager are already deployed in the cluster.

I will use Pocket ID as Identity Provider in this tutorial. Configuration slightly differs for different providers. Check the official documentation for your provider.

For the examples in this guide, I’ll use my alikhil.dev domain:

– pocket-id.k8s.alikhil.dev - will be used for Pocket ID

• k8s.alikhil.dev - will be used for oauth2-proxy. I recommend to have higher domain for oauth2-proxy service for easier cookie setup.

• *.k8s.alikhil.dev - reserved for services deployed for internal usage

Preparation

DNS

I have added two DNS records:

1. A record for k8s.alikhil.dev pointing to ingress-nginx LoadBalancer IP address in the cluster (kubectl get svc -n ingress-nginx | grep LoadBalancer)
2. CNAME record for *.k8s.alikhil.dev pointing to k8s.alikhil.dev

Install Pocket ID

helm repo add anza-labs https://anza-labs.github.io/charts
helm upgrade --install pocket-id anza-labs/pocket-id -f ./values/pocket-id.yaml

persistence:
  data:
    enabled: true

ingress:
  # -- Specifies whether ingress should be enabled.
  enabled: true
  # -- Ingress class name.
  className: "nginx"
  # -- Annotations to add to the ingress.
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    kubernetes.io/ingress.allow-http: "true"
    kubernetes.io/tls-acme: "true"
  # -- Ingress host configuration.
  host: pocket-id.k8s.alikhil.dev
  paths:
    - path: /
      pathType: ImplementationSpecific
  # -- List of TLS configurations for the ingress.
  tls:
   - secretName: pocket-id-tls
     hosts:
       - pocket-id.k8s.alikhil.dev

Configure PocketID

Go to https://pocket-id.k8s.alikhil.dev/signup/setup and set initial configuration for Pocket ID.

Then add your passkey.

Create developers group and add yourself to the list of members.

After that, go to OIDC clients page and create one for oauth2-proxy. Set proper callback url.

Save generated Client ID and Client Secret for later use.

Installing oauth2-proxy

I am using raw k8s secrets in this tutorial, but I highly recommend storing secrets in Vault or similar services and use External Secretes Operator to deliver them to kubernetes.

kubectl create secret generic oauth2-proxy-secrets --from-literal=client-id=$CLIENT_ID --from-literal=client-secret=$CLIENT_SECRET --from-literal=cookie-secret=$(openssl rand -base64 32 | head -c 32 | base64)

helm repo add oauth2-proxy https://oauth2-proxy.github.io/manifests
helm install oauth2-proxy oauth2-proxy/oauth2-proxy -f values/oauth2-proxy.yaml

# Oauth client configuration specifics
config:
  existingSecret: oauth2-proxy-secrets

  cookieName: "general-oauth2"
  # Default configuration, to be overridden
  configFile: |-
    email_domains = [ "*" ]
    upstreams = [ "file:///dev/null" ]
    skip_provider_button = true
    allowed_groups = [ "developers", "admins" ]
    cookie_secure = false
    cookie_domains = [".k8s.alikhil.dev", "k8s.alikhil.dev"]
    whitelist_domains = [ "*.k8s.alikhil.dev", "k8s.alikhil.dev" ]
    cookie_samesite = "lax"
    cookie_csrf_per_request = true
    cookie_csrf_expire = "15m"
    pass_access_token = true
    pass_authorization_header = true
    provider = "oidc"
    provider_display_name = "PocketID"
    reverse_proxy = true
    scope = "openid profile email groups"
    session_store_type = "redis"
    set_xauthrequest = true
    set_authorization_header = true
    silence_ping_logging = true
    skip_auth_preflight = true
    ssl_insecure_skip_verify = true
    ssl_upstream_insecure_skip_verify = true
    insecure_oidc_allow_unverified_email = true
    oidc_issuer_url = "https://pocket-id.k8s.alikhil.dev"
    redirect_url = "https://k8s.alikhil.dev/oauth2/callback"
    # to reduce log amount
    request_logging = false


ingress:
  enabled: true
  className: nginx
  path: /
  # Only used if API capabilities (networking.k8s.io/v1) allow it
  pathType: ImplementationSpecific
  # Used to create an Ingress record.
  hosts:
    - k8s.alikhil.dev
  labels: {}
  annotations:
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: '*'
    nginx.ingress.kubernetes.io/enable-cors: 'true'
    kubernetes.io/ingress.allow-http: "false"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  tls:
    # Secrets must be manually created in the namespace.
    - secretName: oauth2-proxy-tls
      hosts:
        - k8s.alikhil.dev

# Configure the session storage type, between cookie and redis
sessionStorage:
  # Can be one of the supported session storage cookie|redis
  type: redis
  redis:
    existingSecret: ""
    password: ""
    passwordKey: "redis-password"
    clientType: "standalone"

# Enables and configure the automatic deployment of the redis subchart
redis:
  # provision an instance of the redis sub-chart
  enabled: true
  architecture: standalone
  auth:
    enabled: false
  master:
    persistence:
      enabled: false

    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 1
      memory: 1Gi

Testing

Install whoami

To check oauth2-proxy we need a dummy service. I will use whoami helm chart for this.

helm repo add cowboysysop https://cowboysysop.github.io/charts/
helm install whoami cowboysysop/whoami

ingress:
  enabled: true
  ingressClassName: nginx
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    kubernetes.io/ingress.allow-http: "true"
    kubernetes.io/tls-acme: "true"
    # put oauth2-proxy domain here
    nginx.ingress.kubernetes.io/auth-signin: "https://k8s.alikhil.dev/oauth2/start?rd=https://$host$request_uri$is_args$args"
    # service-name.namespace-name
    nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy.oauth-example.svc.cluster.local:80/oauth2/auth
  hosts:
  - host: whoami.k8s.alikhil.dev
    paths:
    - /
  tls:
  - hosts:
    - whoami.k8s.alikhil.dev
    secretName: whoami-cert

Perform test

Go to whoami url and check if oauth2-proxy redirects you to Pocket ID like in the demo:

Troubleshooting

Takeaways

Later, when you need to protect any service in Kubernetes with oauth2-proxy, you simply need to add two annotations to your Ingress resource:

annotations:
  nginx.ingress.kubernetes.io/auth-signin: "https://k8s.alikhil.dev/oauth2/start?rd=https://$host$request_uri$is_args$args"
  nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy.oauth-example.svc.cluster.local:80/oauth2/auth

Tested with: MikroTik hEX S (RB760iGS) · RouterOS 7.x · Ubuntu 22.04 LTS · WireGuard hub-and-spoke topology

Requirements

What I have

• A Mikrotik Hex S router with a dynamic public IP address.

• Services in a cloud VM (Ubuntu 22) with a static public IP address.

• Services in a VM on my home network.

• Clients - laptops and phones - that need to access the services in my home and cloud network.

What I want

• Clients outside of my home network should be able to access services both on my home and cloud network.

• Only traffic to my home and cloud network should be routed through the VPN.

• Clients inside my home network should be able to access services on my cloud network without additional configuration.

• No external centralized service should be used.

• No open ports on my home router.

Implementation

Nowadays, there are plenty of VPN solutions like zero-tier and tailscale. However, I think they are too bloated for my humble needs and WireGuard is more than enough for that.

Because of last requirement, it’s obvious that traffic to home network should be routed though my cloud server.
So, I will use WireGuard to create a tunnel between mikrotik router and cloud server.
This way, I can access my home network from anywhere without exposing any ports on my home router.

I. Initial configuration of WireGuard on cloud VM

For the sake of reproducibility and simplicity I will use vanilla wireguard and configure it on OS level, not in docker container.

1. Install wireguard on Ubuntu 22.04

sudo apt update
sudo apt install wireguard -y

# Edit the configuration file
sudo nano /etc/sysctl.conf
# Find and uncomment the line:
net.ipv4.ip_forward=1
# Save and exit

# Then apply the changes:
sudo sysctl -p

2. Create public and private key

sudo su -
cd /etc/wireguard
# Generate private and public keys
wg genkey | tee privatekey | wg pubkey > publickey

# Check the keys
cat privatekey
cat publickey

3. Create the configuration file

I will use 172.16.10.0/24 subnet for Wireguard network.

sudo nano /etc/wireguard/wg0.conf
# Add the following lines:
[Interface]
Address = 172.16.10.1/24
ListenPort = 27277 # You can choose any port you want
Privatekey = <your_private_key> # from previous step

# These are placeholder lines for next steps, keep them commented for now
# # Mikrotik peer
# [Peer]
# AllowedIPs = 172.16.10.0/24,192.168.0.0/16
# PublicKey = mikrotik public key

# # client peer
# [Peer]
# AllowedIPs = 172.16.10.2/32
# PublicKey = first client device public key

# CRTL+X: save and exit

# Change the permissions of the configuration file
chmod 600 wg0.conf

4. Start the WireGuard interface

# Enable service to start on boot
systemctl enable wg-quick@wg0.service
systemctl daemon-reload

# Start the service
systemctl start wg-quick@wg0
# Check wg status
wg

It should show the interface is up like this

More commands to check the status of the service:

# Check the status of the service
systemctl status wg-quick@wg0
# Restart the service if needed
systemctl restart wg-quick@wg0

II. MikroTik hEX S WireGuard setup

I will use Mikrotik command line interface (CLI) to configure the router. You can use Winbox or WebFig if you prefer.

1. Create WireGuard interface

# Create WireGuard interface and it will automatically generate private and public keys
/interface wireguard add listen-port=13231 mtu=1420 name=cloud-wg
# Add the IP address to the interface
/ip add address=172.16.10.3/24 interface=cloud-wg network=172.16.10.0

# Print the keys, you will need only the public key later
/interface/wireguard/print

2. Create the peer

Here we add cloud vm as a peer to the Mikrotik router’s wireguard. The public key of the cloud server is needed here.

# In allowed-address we add IP ranges which will be routed through this peer
# 172.21.0.0/16 - subnet of docker containers on cloud server
# 172.16.10.0/16 - subnet of wireguard network
/interface wireguard peers add allowed-address=172.16.10.0/24,172.21.0.0/16 \
    endpoint-address=cloud.vm.ip.address \
    endpoint-port=27277 \
    interface=cloud-wg \
    public-key="PUT CLOUD SERVER PUBLIC KEY HERE" \
    name=peer1 persistent-keepalive=25s

# Here is a tricky part
# Routing rule for subnet of wireguard network is added automatically on adding IP address to the interface
# But we need to add explicitly the route for docker containers subnet
# You may need to adjust the distance and routing-table values
/ip route disabled=no distance=1 dst-address=172.21.0.0/16 gateway=cloud-wg routing-table=main scope=30 suppress-hw-offload=no target-scope=10

III. Add WireGuard peer (VM)

sudo nano /etc/wireguard/wg0.conf
# Uncomment the lines for Mikrotik peer
# Mikrotik peer
[Peer]
AllowedIPs = 172.16.10.0/24,192.168.0.0/16
PublicKey = mikrotik public key

# Save and exit

# Restart the WireGuard service
sudo systemctl restart wg-quick@wg0
# Check if changes are applied
wg show

You should see the Mikrotik peer in the list of peers.

# ping wireguard IP of cloud server
ping 172.16.10.1

# resolve google.com via adguard container on cloud vm
put [resolve google.com server 172.21.0.114]

# ping wireguard IP of Mikrotik router
ping 172.168.10.3

# resolve google.com via adguard container on home adguard
dig google.com @192.168.11.2

# ping wireguard IP of cloud server
ping 172.16.10.1

# resolve google.com via adguard container on cloud adguard
dig google.com @172.121.0.114

IV. Add first client device as a peer

I recommend you to use your smartphone as first client device, because it can work from both home WiFi and mobile data. This way you can test the connection from both networks.

Also, install on your smartphone:

• WireGuard app (iOS, Android)
• Network debugging app (iOS, Android)

1. Create keys for the client

Install Wireguard app for your client OS.

Then, generate public and private keys on the device, for that create config from scratch in the app and then click on Generate keypair button.

Or you can generate keys on the cloud server and then copy them to the client device.

wg genkey | tee peer-privatekey | wg pubkey > peer-publickey

2. Add the client as a peer to WireGuard config on cloud server

On the cloud server, edit the WireGuard config file and add the client as a peer.

Each time increment previous peer address by 1.

sudo nano /etc/wireguard/wg0.conf
# Uncomment the lines for client peer
# client peer
[Peer]
AllowedIPs = 172.16.10.2/32
PublicKey = put public key

# CRTL+X: save and exit

# Restart the WireGuard service
sudo systemctl restart wg-quick@wg0

# Check if changes are applied
wg show

3. Continue configuring the client device

You already have public and private keys for the client device, other configuration parameters are:

Interface

• Address - Its address in the WireGuard subnet. Put the same address you set in the AllowedIPs field in the previous step.
• DNS servers - if you have adguard/pihole running on the cloud server, you can use it as a DNS server. Put its IP address here.
• MTU and ListenPort - you can leave them empty, they will be set automatically.

Peer

• Endpoint - cloud server IP address and port (27277)
• Public key - public key of the cloud server
• AllowedIPs - here we put all subnets that we want to access from this current client device

Here is an example of the configuration file for the client device:

[Interface]
PrivateKey = private-key-of-client-device
Address = 172.16.10.2/32
DNS = 172.21.0.114 # IP of adguard container on cloud server

[Peer]
PublicKey = public-key-of-cloud-server
AllowedIPs = 192.168.0.0/16, 172.16.10.0/24, 172.21.0.0/16 # subnets of home, cloud and wireguard network
Endpoint = ip.of.cloud.servner:27277

That’s it! Disconnect your device from the home Wi-Fi, switch to mobile data and connect to the VPN.

Then try to:

• ping the cloud server and Mikrotik router IP addresses in wireguard subnet.
• check ports of services in docker containers on cloud and home server VM.

ping cloud	ping home	check adguard port

V. Troubleshooting

VI. Bonus. DNS configuration

Since I have 2 adguard instances and I use them as DNS servers everywhere, I will add DNS records for accessing my services:

• *.cloud.domain.com - pointing to traefik docker container on cloud server
• *.home.domain.com - pointing to traefik docker container on home server

Thus, I can access my services using domain names instead of IP addresses.

Final thoughts

I hope this tutorial was helpful for you. I will keep it updated if I find any issues or improvements.

If you have any questions or suggestions, feel free to leave a comment below.

Credits to @laroberto for their guide on LAN access with WireGuard. I followed it to set up the initial configuration and then adapted it to my needs.

Recommended reading

• Storing and Using Secrets in MikroTik RouterOS — how to avoid hardcoding passwords and tokens in your RouterOS scripts.

Today I want to share with you another reason why you should avoid using http.DefaultClient in your code.

The Story

As an SRE at Criteo, I both read and write code. Last week, I worked on patching Updatecli — an upgrade automation tool written in Go.

The patch itself was just ~15 lines of code. But then I spent three days debugging a strange authorization bug in an unrelated part of the code.

It happened because of code like this:

client := http.DefaultClient
client.Transport = &transport.PrivateToken{
    Token: s.Token,
    Base:  client.Client.Transport,
}

Since http.DefaultClient is a reference, not a value:

var DefaultClient = &Client{}

The code above is effectively the same as:

http.DefaultClient.Transport = &transport.PrivateToken{
    Token: s.Token,
    Base:  http.DefaultClient.Transport,
}

Later, in a third-party library, I found this:

if opts.Client == nil {
    opts.Client = http.DefaultClient
}

The Fix

To prevent this, I had to change the code to:

client := &http.Client{}
client.Transport = &transport.PrivateToken{
    Token: s.Token,
    Base:  client.Transport,
}

As a result, the patched client with the authorization transport got injected into the third-party library, causing unexpected failures.

Bugs like this are hard to catch just by reading the code, since they involve global state mutation. But could they be detected by linters?

What do you think? How do you find or prevent such issues in your projects?

If you’re dealing with multiple SIM cards and want to receive SMS in Telegram, I have a straightforward approach. You’ll need a Linux machine that’s always online, connected to the internet, and about $10.

What You’ll Need

• A physical SIM card
• A USB modem that’s supported by the Gammu library
• A Telegram bot token, chat or channel ID
• A Linux machine with a free USB port
• Docker and Docker Compose installed

Finding the Right Modem

If you have a USB modem at home, check if it’s supported by Gammu.

For our purposes, we don’t need an expensive 4G modem with advanced features. Any basic 2G/3G modem will work, and these are easy to find at a discounted price on sites like eBay or Wallapop.

Search for “Huawei USB modem,” sort by price, and look for unlocked options or ones with compatible firmware.

For instance:

Next, go to the Gammu website and look up the device. Make sure it appears on the list and that “SMS” is included in the “Supported features” column:

If the device meets these requirements, it’s good to go!

Setup Instructions

Before starting the setup, it’s best to connect the modem with the SIM card already inserted to your PC and check that it’s functioning properly.

Identify Device Path

Run the following command to identify the device path:

tree /dev/serial/by-id/

You should see a paths similar to:

/dev/serial/by-id
├── usb-HUAWEI_HUAWEI_Mobile-if00-port0 -> ../../ttyUSB0
├── usb-HUAWEI_HUAWEI_Mobile-if02-port0 -> ../../ttyUSB1
├── usb-HUAWEI_HUAWEI_Mobile-if03-port0 -> ../../ttyUSB2

Choose a path that ends with ttyUSB0, in my case it’s /dev/serial/by-id/usb-HUAWEI_HUAWEI_Mobile-if00-port0.

Running the Service

Using Docker Compose, set up your configuration:

services:
  gammu:
    image: ghcr.io/alikhil/sms-to-telegram:latest
    volumes:
    - type: bind
      source: /dev/serial/by-id/usb-HUAWEI_HUAWEI_Mobile-if00-port0 # Change this to your device path
      target: /dev/modem
    privileged: true
    environment:
      - BOT_TOKEN=<put your telegram bot token here>
      - PIN=<your sim card pin>
      - CHAT_ID=<telegram chat/channel ID>
      - DEVICE=/dev/modem
      - PROTOCOL=at
    cap_add:
    - NET_ADMIN
    - SYS_MODULE

Save the configuration to a docker-compose.yml file and run:

docker compose up -d
docker compose logs -f gammu

If everything is set up correctly, you should see the following log messages:

gammu-1  | Fri 2024/10/04 17:50:56 gammu-smsd[12]: Created POSIX RW shared memory at 0x7fcf90b21000
gammu-1  | Fri 2024/10/04 17:50:56 gammu-smsd[12]: Starting phone communication...
gammu-1  | Fri 2024/10/04 17:55:30 gammu-smsd[12]: Ignoring incoming SMS info as not a Status Report in SR memory.
gammu-1  | Fri 2024/10/04 17:55:33 gammu-smsd[12]: Read 1 messages
gammu-1  | Fri 2024/10/04 17:55:33 gammu-smsd[12]: Received IN20241004_195517_00_Celerity_00.txt
gammu-1  | Fri 2024/10/04 17:55:33 gammu-smsd[13]: Starting run on receive: /etc/sms_to_telegram.sh IN20241004_195517_00_Celerity_00.txt
gammu-1  | Fri 2024/10/04 17:55:33 gammu-smsd[12]: Process finished successfully

To test SMS reception, you can use free online SMS-sending services (search for “send SMS for free”) or try logging into Telegram, your bank account, etc.

How It Works

The Gammu library provides a unified interface for working with phones and modems from various manufacturers.

On top of that, there’s the Gammu SMS Daemon, which receives SMS messages and triggers a custom script—in our case, script to send the messages to Telegram.

Final Thoughts

Thanks to @kutovoys for the idea and Docker image!

This is a simple, affordable, and scalable solution—especially if you’re into self-hosting.

This post was originally written for vas3k.club.