Nabarun Pal

About

hey@nabarun.dev — Mon, 06 Jan 2025 00:00:00 +0000

I’m Nabarun Pal, also known as palnabarun or theonlynabarun, a distributed systems engineer and open source contributor with a passion for building resilient infrastructure and fostering collaborative communities. Currently, I work on Kubernetes and cloud-native technologies, contributing to the ecosystem that powers modern distributed applications.

When I’m not deep in code or community discussions, you can find me planning my next adventure, brewing different coffee concoctions, tweaking my homelab setup, or exploring new mechanical keyboards. I believe in the power of open source to democratize technology and create opportunities for everyone to contribute and learn.

A detailed view of my speaking engagements are in the /speaking page.

What's the plan for 2022?

hey@nabarun.dev — Mon, 03 Jan 2022 21:32:11 +0530

I want to spend more time in 2022 to “Do Less!”, take things as they come, take breaks and try to travel or work on mechanical keyboards during those breaks. The time off that I took in 2021 - first half of August and last half of December, gave me a lot of breathing space and time to rethink priorities especially the first one where I partially overcame burnout due to several factors (Thanks to VMware for the generous leaves!).

Last year, I started actively taking care of my health. I jogged for ~700kms in the last quarter (Oct-Dec) although I did not jog during the time I was travelling to Bangalore/Delhi/Kolkata. I want to continue the same trend and target atleast 3000kms of jogging and a 10km run in 2022.

2021 was also when I moved back to my hometown, Agartala, and that too after a span of 9 years. I spent a lot of time with close family members and friends from school. I plan to spend more time with people who I care about and who care about me, be it in Bangalore or Agartala.

Update: Weekly Mentoring Sessions

hey@nabarun.dev — Sat, 27 Nov 2021 05:25:34 +0530

I have had the pleasure to talk with 30+ folks and help them in their journey in the field of computer science and/or growing in their career with Open Source Software. It has been an honour that so many wanted to talk to me and get my views.

For the month of December, I am going to take a break from the mentoring sessions as I will travelling on most weekends and will be out for vacation in the later half of the month.

Fret not, I will try to make up for the lost time by doubling up my commitment for January 2022. But, in case you need to urgently talk with me, drop me a ping on hey [at] nabarun [dot] dev and I will try to schedule something which works for both of us.

Wish you all a very happy December! 🎉

PS: Stay tuned to the RSS feed! There are many articles which are languishing in my drafts, I may publish a few of them.

Giving Back

hey@nabarun.dev — Sun, 18 Jul 2021 12:40:50 +0530

Update (2024): 1-on-1 mentorship sessions are currently paused. Please reach out via the contact page instead.

Over time, I have learnt a lot from the open-source software community, not just in India but from various parts of the world. I have the privilege of learning from the best software engineers in this world. A lot of great mentors have influenced me and helped me in shaping my way into OSS. These interactions were valuable to me, being a self-taught software engineer.

While talking to one junior from my alma mater, I realized there is still a gap between people wanting to get mentored and good mentors in the OSS community. There are outstanding programs like DGPLUG Summer Training which help new contributors learn how to survive in the open-source community by covering in breadth the mechanics. Still, people usually don’t discover on their own. I understand how frustrating it is to get stuck when you are exploring something. Having a mentor/partner with whom you can discuss doubts is vital in that situation.

As a way of giving back to the community that I have learned so much from, I am pledging 4 hours per week of my time to talk with folks who seek mentorship in OSS, Career journey, or, in general, talk about anything common interests.

Just go to https://calendly.com/palnabarun/1-on-1 to schedule a slot.

My journey in the Kubernetes Release Team: Part 1

hey@nabarun.dev — Thu, 10 Sep 2020 08:58:41 +0530

During this period last year, I got interested in how a new Kubernetes version is released and what goes on behind it. After some searching, I found that all of the process and the roles are well documented in the Release Team Role Handbooks.

I read through all of them to understand the process, why there are so many roles and what responsibilities each team is entrusted with. All of that sounded pretty interesting to me. All the teams did an amazing work and were equally crucial for the well functioning of a Kubernetes Release cycle. I got specifically interested with the Enhancements and CI Signal teams. I started to dig how can I lend my hand to the efforts.

Shadow Roles

With the role handbooks, I got to know of the Release Team Shadow Program which is aimed at mentoring new contributors and training them to be the next leads of the Kubernetes Release Team. The shadows are expected to learn from the leads and fill in wherever necessary. You can think of these positions as “trainee/intern” roles at your workplace. This was just a primer on the program. You can read more on the link.

Okay. I know where to start with. But how?

Turns out it requires a marginal amount of effort, bucket loads of curiosity and time commitment to apply for the Shadow Program. The Release Team at the start of every release cycle pushes out a public form for inviting applications to the shadow roles.

Taking the plunge

I took the initiative and filled the form with my interests and thoughts. And few days later I, along with other shadows, was welcomed by MrBobbyTables to my first involvement with the Release Team. 🎉

The next few months were just like a roller coaster ride. The team that I was shadowing for was the Enhancements Team and our work was to shepherd features for the Kubernetes release and maintain the status of Kubernetes Enhancements Proposals, aka, KEP(s).

The role involved understanding each outstanding KEP, pinging respective OWNERS if the enhancement would be graduating in the current release cycle, and keeping track whether the enhancements are satisfying the requirements for the release.

Here were a few takeaways that I took while working on the team:

Knowledge of what is involved when adding a feature into Kubernetes!!!
Reading through an enourmous amount of KEPs, I got to know about the features themselves
Communicating effectively with others and breaking the ice
A lot of GitHub triage skills and tricks
Tricks of wrangling data on a spreadsheet 😉

I will write about the complete lifecycle of a Kubernetes Enhancement Proposal in a future article.

We released Kubernetes 1.17 : The Chillest Release (Yes! That is the release theme 😃) after all the efforts of the 1.17 release team. The last release of the year is usually the most chilled out and is a bit short due to the December vacation.

The whole team became akin to a family for me spending all that effort into ensuring a smooth release. We, the Enhancements Team (Bob, Jeremy, Anna, Kristin), even got together at KubeCon San Diego to meet up physically.

The Next Steps

After Kubernetes 1.17, I signed up again for the Kubernetes 1.18 team for Enhancements to get more exposure to the KEP landscape. This time Jeremy was leading the Enhancements Team. It was fun again to work with the enhancements team (Jeremy, Kirsten, Heba, John), all the same just this time there were new shadows along with me compared to last time.

This release cycle was mostly the same for me other than I was a bit more involved than the last time having served on the team previously. And, after all the hard work of the 1.18 release team, we were treated to a quarky Kubernetes 1.18 ⭐.

Graduating to be the Enhancements Lead 🚀

Aaaaaand after a splendid 1.18, Jeremy nominated me to be the Enhancements Lead for Kubernetes 1.19 Release Team. I was stoked to get the opportunity and at the same time scared if I can do full justice to the responsibility bestowed upon me. The knowledge of the role while working with Bob and Jeremy in the previous release teams gave me the confidence that I can fulfill the responsibilities of the role.

This release cycle eventually became special in many ways. We were hit by a deadly pandemic which changed a lot of things in our life. The release cycle was extended to 5 months instead of the usual 12 weeks cadence. The pandemic and various other factors shaved off quite a bit of the usual bandwidth the community had previously. These times were very crucial for the whole world and the team didn’t want to put undue additional pressure on the amazing contributors that we have.

The shadows that I selected for the Enhancements Team spanned 12 and a half hours of timezone and created an amazing round the earth coverage for the team. This meant no team member had to toil in their odd times of the day. I take this opportunity to thank again all the enhancements shadows - Kirsten, Harsha, Miroslaw and John for their efforts even in such hard times.

After those tense & tough 5 months firefighting a lot of issues, the 1.19 release team released Kubernetes 1.19: Accentuate the Paw-sitive. You can read about the release on the Kubernetes Blog and the upcoming Kubernetes 1.19 Release Webinar where I will be presenting along with the 1.19 Release Lead Taylor and the 1.19 Communications Lead Max.

With that, my watch ended over the Release Enhancements Team and it was time to hand over the baton to next lead. :peace:

I was very happy to nominate Kirsten to succeed me as the next Enhancements Lead of the Release Team. 🎉

Along with that it was time for me to graduate to my next role. I look forward to working with Jeremy, Savitha and Daniel for Kubernetes 1.20. I will be shadowing the Release Lead for Kubernetes 1.20. 😎

How can you get involved? 🙌

The last release of the year, Kubernetes 1.20, is going to be published in December. The Release Team is looking out for folks for the shadow roles. All you need to do is go ahead, read the role handbooks, figure out which role interests you the best and then fill the form. We ask every prospect to fill the form because we want to know if the release team would be a good fit for you and to find the right role for you in the Release Team.

The applications will be open until End of Day Friday, September 11, 2020 Pacific Time.

Still in doubt? 🔍

I would say just go ahead and volunteer for the shadow roles. 🚢

Feel free to contact me on Twitter at @theonlynabarun, or on the Kubernetes Slack, in case you have anything to ask.

Quick References

Update since the original version

I wrote this article over 6 months back and since then led the Kubernetes 1.21 Release Team. I plan to write about my experience leading the Release Team in the near future. Do subscribe to the RSS feed for updates.

Rubber Ducks: My trusted companions

hey@nabarun.dev — Sat, 22 Aug 2020 23:25:06 +0530

There are times when I find myself stuck when solving any problem. This deadlock can arise due to several factors. Sometimes I need a new perspective of the problem. Sometimes I just need to go through my approach with a fresh mind.

I can ping my colleagues to get new perspectives or explain to them what I am trying to achieve. But, not always can I find someone to listen to me since everyone is busy with their work.

What I do in those situations is either

Write down my approach on a piece of paper in the simplest terms, or
Talk to my Rubber Ducks about the approach assuming that the ducks have ZERO knowledge about what I am doing.

I learned about the Rubber Duck debugging paradigm when reading The Pragmatic Programmer by Andrew Hunt and David Thomas. It is a gem of a book. I feel every software engineer looking to excel in their art should read the book. They discuss this method in the Debugging chapter of the book. The idea to find the cause of a problem by explaining it in very simple terms to someone else. The other person listening to you shouldn’t speak a word and should just nod to what you are saying. This simple exercise of explaining your approach in very well defined and atomic steps can give you new insights to your problem.

Obviously you can’t have someone with you all the time to just listen to you. And here comes the importance of inanimate objects that can’t speak. They are the ideal ones that you can explain your problem to. There are some positive effects like they won’t ever judge you, they are always with you no matter what happens. Having said all that, I want to introduce you to my rubber ducks:

In the front row is Goldie, then Zee, then Captain Kube and the tall bloke is Phippy. The whole gang is known as Phippy and Friends. They are always on my table looking over me and listen to me whenever I want to speak to them. I know it’s a bit intimidating someone looking at you all the time, but eventually you get along with them. 😉

Do note that this method works for me, but not necessarily would it work for everyone. I always ask people to find their own debugging comfort zone.

Running Tor Proxy with Docker

hey@nabarun.dev — Sun, 05 Jul 2020 15:45:06 +0530

Today I was testing dns-tor-proxy which required a SOCKS5 Tor proxy and realized I never ran a Tor service on my current machine. I use Tor browser almost daily for browsing websites I have absolutely no trust on, but not the standalone Tor proxy. In this article, I will try to set one up using the system package as well as inside a Docker container.

What is a Tor proxy?

A Tor proxy is a SOCKS5 proxy which routes your traffic through the Tor network. The Tor network ensures that any traffic originating from inside the network gets routed through atleast 3 random relays before exiting through the exit node.

It helps you to anonymize traffic, block trackers and, prevent surveillance amongst other benefits. If you are wondering who should use Tor, the answer is every person who cares about their privacy. You can read more about the architecture here.

Arch Linux

Tor is available in the Arch package repository and can be simply installed by:

# Install Tor
$ sudo pacman -S tor
...
# Start the service
$ sudo systemctl start tor

# Check whether the service is running
$ sudo netstat -tunlp | grep tor
tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN 3808529/tor

We see above that installing tor through pacman set up the systemd service as well. Jump to Using the proxy for the demo.

Debian/Ubuntu

The packages in the Debian ecosystem are often outdated. To get the latest version, one almost always needs to add third-party package repositories. I am not going into detail how to install Tor in that ecosystem, since there are a lot of distribution/version combinations. The steps are well detailed in the official Tor installation docs.

Docker

We will be building a very lightweight Docker image to reduce footprint.

Let’s start with the Tor configuration,

SocksPort 0.0.0.0:9050

The above should get one started with the defaults. Feel free to change the port to whatever you like. The address being listened should be 0.0.0.0 as we would be accessing the server from outside the docker container.

# set alpine as the base image of the Dockerfile
FROM alpine:latest

# update the package repository and install Tor
RUN apk update && apk add tor

# Copy over the torrc created above and set the owner to `tor`
COPY torrc /etc/tor/torrc
RUN chown -R tor /etc/tor

# Set `tor` as the default user during the container runtime
USER tor

# Set `tor` as the entrypoint for the image
ENTRYPOINT ["tor"]

# Set the default container command
# This can be overridden later when running a container
CMD ["-f", "/etc/tor/torrc"]

Let’s build the image now.

$ docker build -t palnabarun/tor .
Sending build context to Docker daemon 67.58kB
Step 1/6 : FROM alpine:latest
 ---> a24bb4013296
Step 2/6 : RUN apk update && apk add tor
 ---> Using cache
 ---> a5ea632ba987
Step 3/6 : COPY torrc /etc/tor/torrc
 ---> 5b351b9847bc
Step 4/6 : RUN chown -R tor /etc/tor
 ---> Running in 1f6950f03475
Removing intermediate container 1f6950f03475
 ---> 060ded5c532c
Step 5/6 : USER tor
 ---> Running in aa0553be76dc
Removing intermediate container aa0553be76dc
 ---> d763c1181285
Step 6/6 : ENTRYPOINT ["tor"]
 ---> Running in 97fd7f9ee693
Removing intermediate container 97fd7f9ee693
 ---> 13c889f5b018
Successfully built 13c889f5b018
Successfully tagged palnabarun/tor:latest

You might also be wondering what is the image size?

$ docker image ls | grep palnabarun/tor
palnabarun/tor latest 13c889f5b018 About a minute ago 21.1MB

The image is just a mere 21.1MB. Building docker images using Alpine Linux as base results in a very lightweight image.

Let’s run the proxy.

$ docker run \
 --rm \
 --detach \
 --name tor \
 --publish 9050:9050 \ # change the port to whatever you put in the torrc
 palnabarun/tor
aef03d84628b

$ docker ps | grep tor
aef03d84628b palnabarun/tor "tor" 31 seconds ago Up 30 seconds 0.0.0.0:9050->9050/tcp tor

After sometime the Tor proxy will succesfully establish a Tor circuit and it will be ready to use.

The Tor config and Dockerfile can be found here and there is a ready to consume image on Docker Hub

Using the proxy

Let’s test whether the proxy is working correctly by some simple curl calls.

The request below is not going through the proxy and hence would show your ISP provided IP address.

$ curl https://check.torproject.org/api/ip
{"IsTor":false,"IP":"49.30.XX.XX"}

Now, if we specify the Tor proxy when making the request, the IP address would be different.

$ curl --socks5 127.0.0.1:9050 https://check.torproject.org/api/ip
{"IsTor":true,"IP":"185.220.XXX.XXX"}

Also, notice the value of IsTor in both the cases, the service running at check.torproject.org knows whether the traffic was routed through the Tor network.

The very same proxy can be used in your browser by going to the Network Settings and changing to a manual proxy configuration. I, however, highly recommend to use the Tor browser if you just want to browse the internet through Tor.

Note: The IP addresses are partially redacted for privacy reasons.

If you are like me who cherishes reading RFCs, check out the following links

It's always DNS!

hey@nabarun.dev — Tue, 30 Jun 2020 00:00:00 +0000

Context

I was running Airflow inside a Kubernetes cluster but the Airflow pods were not able to connect with the PostgreSQL database running inside the cluster. The following was consistently seen in the Airflow logs, although the postgres-airflow service was up and running.

sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) could not translate host
name "postgres-airflow" to address: Temporary failure in name resolution

For the rest of this post, we will assume that all the user run components inside the cluster are running perfectly and focus on what is causing the name resolution errors.

The whole story

I use kind for testing and playing around with Kubernetes workloads. I spin up clusters with any specific Kubernetes version as and when needed. The Kubernetes cluster I spun up was running Kubernetes 1.15.7 using the following KinD configuration.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
 image: kindest/node:v1.15.7@sha256:e2df133f80ef633c53c0200114fce2ed5e1f6947477dbc83261a6a921169488d
- role: worker
 image: kindest/node:v1.15.7@sha256:e2df133f80ef633c53c0200114fce2ed5e1f6947477dbc83261a6a921169488d
- role: worker
 image: kindest/node:v1.15.7@sha256:e2df133f80ef633c53c0200114fce2ed5e1f6947477dbc83261a6a921169488d

I know that this is a deprecated version on Kubernetes. But, since the workloads I am testing will be deployed on GKE, I need to get to the closest upstream configuration.

Digging deeper using dig (Yes! That was intentional), I found that pods inside the cluster were not able to communicate with each other using the Kubernetes Service Discovery and even to the outside world.

debug ~ $ dig postgres-airflow.default.svc.cluster.local

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> postgres-airflow.default.svc.cluster.local
;; global options: +cmd
;; connection timed out; no servers could be reached

debug ~ $ dig naba.run

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> naba.run
;; global options: +cmd
;; connection timed out; no servers could be reached

Pinging the pod/service IP was working fine which meant issues with kube-proxy can be eliminated. The next thing came to my mind was DNS. It’s always DNS right? 😉

Image Source: https://www.reddit.com/r/sysadmin/comments/34ag51/its_always_dns/

Looking at the CoreDNS pods, it was pretty evident that they are erroring out and something wrong is happening.

$ kubectl -n kube-system get pods -l k8s-app=kube-dns
NAME READY STATUS RESTARTS AGE
coredns-5d4dd4b4db-kmmsf 0/1 CrashLoopBackOff 262 22h
coredns-5d4dd4b4db-lnqjb 0/1 CrashLoopBackOff 262 22h

Next, I fetched logs of one of the pods.

$ kubectl -n kube-system logs coredns-5d4dd4b4db-lnqjb
.:53
2020-06-30T07:24:33.638Z [INFO] CoreDNS-1.3.1
2020-06-30T07:24:33.639Z [INFO] linux/amd64, go1.11.4, 6b56a9c
CoreDNS-1.3.1
linux/amd64, go1.11.4, 6b56a9c
2020-06-30T07:24:33.639Z [INFO] plugin/reload: Running configuration MD5 = 5d5369fbc12f985709b924e721217843
2020-06-30T07:24:33.641Z [FATAL] plugin/loop: Loop (127.0.0.1:59596 -> :53) detected for zone ".", see https://coredns.io/plugins/loop#troubleshooting. Query: "HINFO 41198296958627012.1538475969163399818."

Voila! The error itself pointed me to the troubleshooting documentation. This kind of error logging is pretty rare to be honest and I would love to see it in more projects.

Coming back to the problem at hand, the loop plugin detects DNS forwarding loops and raises an error. Now, in order to see why a loop is forming, we have to look at the CoreDNS configuration.

.:53 {
 errors
 health
 kubernetes cluster.local in-addr.arpa ip6.arpa {
 pods insecure
 upstream
 fallthrough in-addr.arpa ip6.arpa
 ttl 30
 }
 prometheus :9153
 forward . /etc/resolv.conf
 cache 30
 loop
 reload
 loadbalance
}

So, any DNS request to this CoreDNS server is first processed by the kubernetes plugin and if the domain name does not match the in cluster domain patterns, the request is forwarded to the next plugin in the chain, which in this case is forward. This is a pretty simplified explanation about what is happening. A detailed explanation can be found in the CoreDNS manual.

forward . /etc/resolv.conf configures the forward plugin to use the hosts resolver configuration for DNS resolution. Let’s have a look at what it is in that file.

$ kubectl -n kube-system cp coredns-5d4dd4b4db-lnqjb:/etc/resolv.conf resolv.conf
error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "c3d8909904e9c6ced0a41e73133c1f6acf5517edd29ed866918dc3001eb6df02": OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"tar\": executable file not found in $PATH": unknown

Bummer! The CoreDNS docker image used here doesn’t have the tools we need to find the files. But, let’s try to inspect the CoreDNS deployment. Kubernetes has a way to define what would be the contents of /etc/resolv.conf and that is the dnsPolicy field in a container specification. (More on this in later articles)

$ kubectl -n kube-system get deployments/coredns -o yaml | grep "dnsPolicy"
 dnsPolicy: Default

When dnsPolicy is set to Default, the containers use DNS configuration of the Kubernetes node they are sheduled to. KinD runs all the nodes as Docker containers. Let’s see what’s in there:

$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a561ebab4938 kindest/node:v1.15.7 "/usr/local/bin/entr…" 30 hours ago Up 30 hours airflow-worker2
7150659a691a kindest/node:v1.15.7 "/usr/local/bin/entr…" 30 hours ago Up 30 hours 127.0.0.1:35725->6443/tcp airflow-control-plane
f2f2e47b4a41 kindest/node:v1.15.7 "/usr/local/bin/entr…" 30 hours ago Up 30 hours airflow-worker

$ docker exec airflow-control-plane cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0

The nameserver specified is a localhost loopback which is implying that the resolver for the hosts aka Kubernetes node is CoreDNS itself. This creates a circular dependency in DNS resolution and that is caught by the CoreDNS loop plugin.

I resorted to a quick fix by changing the recursive resolver used by CoreDNS to 8.8.8.8, by modifiying the Corefile as follows and restarting CoreDNS.

 .:53 {
 errors
 health
 kubernetes cluster.local in-addr.arpa ip6.arpa {
 pods insecure
 upstream
 fallthrough in-addr.arpa ip6.arpa
 ttl 30
 }
 prometheus :9153
- forward . /etc/resolv.conf
+ forward . 8.8.8.8
 cache 30
 loop
 reload
 loadbalance
 }

CoreDNS pods are now running without errors and DNS resolution is working as expected.

debug ~ # dig +short postgres-airflow.default.svc.cluster.local
10.98.135.99

Now, the fix I did is not the perfect one. Any new containers created by Kubernetes with dnsPolicy: Default will still face the same issue. The ideal way is to ask the resolver in the OS distribution used for nodes to not use localhost loopback for DNS resolution or use a custom resolver configuration and specifying the path to kubelet.

Final Thoughts

It was fun trying to dive up into the problem and understand the basics of why DNS resolution was failing.

The whole debugging process is meant to describe a thought process how you can debug an issue like this in a complex system. Straight forward answers can be found in the debugging sections here and here.

Hello World

hey@nabarun.dev — Sat, 20 Jun 2020 00:00:00 +0000

It has been some time (a long time, in reality 😩) that I wanted to start writing blogs about things that I learn and implement.

Taking the extra time during the lockdown as an opportunity, I am planning to write a post atleast every week.

Gaming Setup

hey@nabarun.dev — Mon, 01 Jan 0001 00:00:00 +0000

This is the hardware configuration of my gaming/home workstation setup. (Note: Some are affiliate links)

Category	Details
CPU	Intel Core i7 12700K 3.6 Ghz 8P+4E
Motherboard	ASUS TUF Gaming Z690-PLUS WIFI D4
RAM	2 x Corsair Vengeance 16GB DDR4-3200 RGB
GPU	Nvidia RTX 3080 Founders Edition
OS Drive	Samsung 980 PRO 1TB
Home Drive	Samsung 970 EVO Plus 2TB
HDD	2 x Seagate Barracuda 4TB
Case	NZXT H7 Flow
Power Supply	Corsair RM 850 80 Plus Gold
AIO Cooler	Corsair H150 RGB
Speakers	Samsung HW-C45E/XL 2.1
Display	LG 27UL550 27" 4K
Display	Dell U2720Q 27" 4K (This one is discontinued. The newer variant is U2723QE)
Keyboard	Monsgeek M1 / ePBT Kavala / Boba U4T. Read more on the keyboards page.
Dock	Dell D6000
Headphones	Sony WH-1000XM5
Mouse	Logitech MX Master 3
Webcam	Logitech C930e
Monitor Stand	Sunon Dual LED Monitor Stand - Spring Mount
UPS	APC BX1100C-IN 1100VA
Operation System	Windows 11 Pro / PopOS!

Console

I own a Sony PS5 Disc Edition to play Sony exclusives. I am a big fan of the Horizon series, Ghosts of Tsushima, and the Uncharted series.

I have a PS4 Slim 1TB Edition that I don’t play on anymore. If anyone wants to buy it, reach out to me.

Handheld

I also have a Nintendo Switch to play FIFA and Legends of Zelda on the go.

Homelab

hey@nabarun.dev — Mon, 01 Jan 0001 00:00:00 +0000

Currently I am prototyping all Homelab services on a Raspberry Pi 3 and playing around with NixOS for configuration management. Plan is to run a few services behind a Tailscale network and expose all services internally to the Tailscale network and some public facing services on the web.

TODO

Learn NixOS.
Buy cheap commodity hardware to run computer nodes for fun
Build a mini-ITX or similar form factor PC with decent enough compute and high amounts of storage
Run services to enhance life
Run backup services

Keyboards

hey@nabarun.dev — Mon, 01 Jan 0001 00:00:00 +0000

I have quite a few mechanical keyboards. Only two of them are pre-built keyboards but have hot swap switch sockets.

Currently I use a Monsgeek M1 and Ikki68 Aurora R2 as my primary keyboards. Former is at home, latter is at my office.

TODO

Add a component list
Add more details of currently built configuration
Add photos of builds

Trips

hey@nabarun.dev — Mon, 01 Jan 0001 00:00:00 +0000

Some of my notable trips across time.

Note: This page is still WIP. I plan to expand details of each of these trips as blog posts.

2024

Munnar, Kerala, India
Malta
Vatican City
San Marino
Italy
Monaco
France

2023

Kazakhstan
Uzbekistan
USA
Goa, India
Ooty, TN, India
Turkey ✨
Azerbaijan 🚗
Germany
Austria
Liechtenstein
Switzerland
Luxembourg
Varkala, Kerala, India
Malaysia
Thailand

2022

Belgium
Netherlands
Spain
France

2021

:virus:

2020

:virus:

2019

USA
Spain

2018

Singapore
Rishikesh, Uttarakhand, India
Shimla, Himachal Pradesh, India

Note: I will add trips from 2017 and before when I get to detailing them.