Kubernetes, often referred to as K8s, is an open-source container orchestration platform that helps users deploy, scale and manage containerised workloads. It has become ubiquitous with cloud-native technologies and after over a decade of development has one of the most thriving open source communities. Contributions to the project are deployed on thousands of systems around the world and the first step to contributing is setting up the local development environment.

Now, Kubernetes is a pretty large project and setting up the development environment might not be trivial. Still, the Kubernetes community has provided a helpful resource which walks through the steps to get a development environment setup. But like many other projects in the cloud native space, it's very much Linux centric. Windows users like me might feel a bit lost.

But, it's not too complicated if you have WSL2. Developing on Windows directly is not worth it as the projects rely on a lot of tooling that Windows doesn't have. Yes, one could use MinGW or an alternative but it's not worth the hassle that might crop up later. Hence developing on WSL2 is the best option. If you are already using WSL2, you might already have a distribution installed. Although, one can start setting up the development environment in the same distribution. My advice is to create a separate distribution for K8s development. This will ensure that the development environment is isolated and is not impacted by other uses of WSL2.

Setup the WSL2 Distro

The first step is to create the WSL2 distribution that will contain the development environment. This step can be performed in multiple ways depending on your existing setup.

1. If you have never used WSL2 before, see the documentation for instructions on how to get started.
2. If you have used WSL2 before, you probably have an existing distribution already installed. In that case, install a new distribution from the store.
   1. If you have already installed the distribution you want earlier, you will not be able to create another instance. In that case, you will need to download the distribution and install it manually.
   2. If you haven't already installed the distribution, my suggestion is to install the distribution and export it. Then re-import the distribution with a new name and uninstall the distribution that was installed from the store. This way, this distribution can be re-installed in the future.
3. Once the distribution is up and running, ensure you are logged in as a non-root user.

Going forward, we are using Ubuntu 24.04.1.

Setup Docker Desktop

K8s also need Docker to be present inside the WSL2 instance. The easiest way to do this is to install Docker Desktop in Windows and enable integration with the WSL distribution. See the documentation for instructions.

Setup the WSL2 Environment

Now it's time to login to the WSL2 distribution and set it up.

1. We will start by installing the GNU tools.

   sudo apt update
   sudo apt install build-essential
   

2. Next, we will install jq.

   sudo apt install jq
   

3. Since Kubernetes is written in Go, we need to install it. It's important that the correct version of Go is installed depending on the version of K8s that going to be built. See the notes in the community resource on how to find that out. Install the required version of Go by following the instructions.

4. K8s uses pyyaml for some verification tests. It needs to be installed using Python but before that, the installed version of Python needs to be configured.

   sudo apt install python3-pip
   sudo apt install python3-venv
   
   python3 -m venv .k8s-venv
   source .k8s-venv/bin/activate
   

   This installs pip and venv for the Python that comes pre-installed. It also creates and activates a virtual environment. This is needed as the Python that is pre-installed recommends to install all packages in a virtual environment instead of globally. Once that's done, we can go ahead and install pyyaml.

   pip install pyyaml
   

5. Finally time to clone the Kubernetes git repository. Make sure you fork the repository first before cloning it.

   git clone git@github.com:<username>/kubernetes.git
   cd kubernetes
   

   Make sure to replace <username> with your the GitHub username where the fork is located.

6. Finally, we install etcd.

   ./hack/install-etcd.sh
   

   This script will instruct you to make a change to your PATH. To make
   this permanent, add this to your .bashrc or login script:

   export PATH="$PATH:/home/<username>/kubernetes/third_party/etcd"
   

   Again replace <username> with your current WSL username.

And that's it! You should have your development environment all setup. Try running the command make from the terminal and it should build the project.

Recently, while working on a game development project, I needed to create a landscape. I found the landscape tools in Unreal Engine 5 to be unsatisfactory for what I wanted to create. That is when I came across Gaea, a node based terrain design tool. It had a free plan that was enough for me so I went ahead and downloaded it. I generated the landscape I was happy with, thanks to the help of the Gaea community, and then came across probably one of the most common questions people have with Gaea and Unreal Engine 5; How to export the terrain from Gaea into Unreal Engine 5 and scale correctly? I believe I have found a nice workflow so here's a short post detailing it.

Version of software used

1. Gaea Version 1.3.2 Community
2. Unreal Engine 5.3.2

Basic points to keep in mind

Before we start, there are a few things to keep in mind about Unreal Engine.

1. The heightmap's height is calculated by using values between -256 and 255.992, stored with 16-bit precision. So, roughly, there is a range of 512 in the Z-axis.
2. The default scale is 100. This is because Unreal Engine's default units are in centimeter and expect the heightmap's values to be in metres. For eg. a value of 0 in the heightmap is -512cm when the scale is 1. Most heightmap's are made in metres and so, for things to make sense, the default is set to 100.
3. Unreal Engine has some pre-defined landscape sizes/resolutions that are not exactly 1024 or 2048. The list of recommended landscape sizes can be found here. For our purpose in the rest of the blog, we will use 1009 x 1009.

Basic configuration in Gaea

Before you start working on a new Gaea project, set up the "Terrain Definition" parameters. These can be modified in an existing project too but that will change the terrain. The values should be as such:

Scale: Use the landscape size that is selected. Since we selected 1009 x 1009 as the landscape size, we will use that as the scale.
Height: For our height, we will use 512.

Build configuration in Gaea

Now, once we have built our terrain, it's time to build and export the heightmap. We will use the following configuration:

File format: .png
Resolution: 1009
Range: Raw

And we will start building our heightmap. The built heightmap will be in our file system. We will import the .png file in Unreal Engine 5.

Landscape import configuration in Unreal Engine 5

Finally, time to import the heightmap into Unreal Engine 5 and generate the landscape. Assuming we already have a level created, we will need to go to the Landscape mode. In the "Manage" mode, we can create a New landscape and select the "Import from File" mode.

We will use the following options in the fields:

Heightmap File: The built .png file.
Location: 0.0, 0.0, 25600.0
Scale: 100.0, 100.0, 100.0
Section Size: 63x63 Quads
Sections Per Component: 1x1 Section
Number of Components: 16, 16
Overall Resolutions: 1009, 1009

Click on "Import" to start the import. We should see the terrain imported with the correct scale and the bottom-most point of the terrain right on the XY plane.

And with that, we have what we wanted.

I want a hiiiigh landscape!

So, in the above steps, I have mentioned keeping the "Height" in Gaea's "Terrain Definition" at 512. That means that the highest you can build is 512m. But what if you want to build higher? That should not be a problem. One can technically use whatever height Gaea supports. I have used 512m to keep things simple. If you want to use another height, just multiply the height by 100 and divide that by 512 and use the result in the Z-axis scale. For eg. if we set the height in Gaea at 1000, we should set the scale as 195.3125. This calculation comes from the fact that 512m in Gaea refers to a scale value of 100 in Unreal Engine. Moreover, the Z-axis value of the location needs to be updated in a similar ratio. To get the value multiply 256 with the Z-axis scale. In this case, we get 50000.0 so that's what we put to locate the bottom of the landscape at z=0.

Using a sea level

If the landscape in Gaea uses the Sea node to simulate a sea level, then one can import the landscape into Unreal Engine keeping the sea level at z=0. After getting the sea level in percentage from Gaea, subtract this as a ratio from 1 and then multiply by the value of the bottom of the landscape. For eg. in the previous case, if the sea level was 10%, then the location on the Z-axis would have been 50000 multiplied by 0.9 to get 45000.0. This would ensure that the sea level is at z=0.

That should be all. I hope it helps someone looking for a way to get the 2 working nicely. Let me know if something can be improved.

I run a couple of blogs using Ghost and running on a Digital Ocean droplet and today I had to go through the arduous task of upgrading it. I am not exaggerating when I say arduous as it was anything but trivial. Initially, I started by upgrading the Ghost instances in place but soon I realised that it was going to be more of a pain than I wanted. You see, I had set up my blog more than 5 years back using the formerly 1-click installation of Ghost (now called marketplace image installation) and in my infinite wisdom neglected to upgrade the installation. And thus I found that it was still running on Ubuntu 18.04 and Node 14. So, I decided that instead of spending hours trying to upgrade from the latest v4 to v5 of Ghost and potentially ruining the installation and crying in a corner in misery, I could just spin up a droplet, install Ghost afresh, and restore a backup. A genius idea I must say!

But first some system information:

Source system:

1. Ubuntu 18.04.6 with 1 vCPU and 1GB RAM
2. Ghost CLI 1.25.3 and Ghost 4.48.9
3. Themed with Casper 4.7.4

Destination system:

1. Ubuntu 22.04.3 with 1 vCPU and 2GB RAM
2. Ghost CLI 1.25.3 and Ghost 5.79.3
3. Themed with Casper 5.7.0

I expected things to be an easy affair but soon I was proved wrong when I realised that the Digital Ocean marketplace image itself doesn't support multi instance Ghost installations.

After spending over 24 hours researching and bringing up and destroying droplets over and over again to get the results I wanted, I finally found out the perfect steps to create a multi instance setup when starting from a marketplace image and how to migrate an existing setup to the new one. Hopefully, this will save some time for someone.

Backup Source Blogs

Perform the following steps in the source droplet.

1. Switch to the ghost-mgr user.

   sudo -i -u ghost-mgr
   

2. Go to each directory where Ghost is installed. For our purposes, we will assume /var/www/sayak. One can go to the directories by the following command.

   cd /var/www/sayak
   

3. Run the backup command using the ghost CLI in each directory.

   ghost backup
   

   This will generate a .zip file for each backed up directory.
4. Download the backups to a local system. We will need them shortly.
5. Turn off the droplet from the Digital Ocean control panel or run the following in the terminal to shut down the droplet

   poweroff
   

6. Take a snapshot of the droplet from Digital Ocean. Taking a snapshot means that in case something horrible happens, we can create a fresh droplet from the snapshot.
7. Turn on the droplet from the Digital Ocean control panel once the snapshot is done.

Change the URL of the source blogs

Once we start setting up the destination droplet, we will need to give the URLs of the blogs. This means we will need to change the DNS of our domains to the destination droplet's IP address which means we will no longer be able to access the source blogs.

However, it is helpful to have access to the source blogs even after the destination blogs are up and running. One can use both of them to compare differences and make small changes in the destination blogs as necessary. This is the case when the themes have breaking changes.

1. Create a new DNS entry for the source blogs. In our case, we will make it old.sayakm.me.
2. SSH into the source droplet and switch to the ghost-mgr user.

   sudo -i -u ghost-mgr
   

3. Go to each directory where Ghost is installed. For our purposes, we will assume /var/www/sayak. One can go to the directories by the following command.

   cd /var/www/sayak
   

4. Run the ghost config command in each directory to update the URL in the configuration.

   ghost config url https://old.sayakm.me
   

   This will generate an output confirming the success.

   Successfully set 'url' to 'https://old.sayakm.me'
   

5. Next, run the setup command to update the Nginx and SSL configuration in each directory

   ghost setup nginx
   

   This will give an output as such

   ✔ Setting up Nginx
   

   And

   ghost setup ssl
   

   This will ask for your email which will be used to generate the SSL certificate only. Provide it which will give this output

   ? Enter your email (For SSL Certificate) youremail@gmail.com
   ✔ Setting up SSL
   

6. Finally, restart each Ghost installation using the following command

   ghost restart
   

   On success, we will get

   ✔ Restarting Ghost
   

Setup the destination blog

Now, it's time to setup the destination droplet and blogs.

1. Create the destination droplet in Digital Ocean with the Ghost Marketplace image.
2. Once the droplet gets created, update the IP of the existing blog domains to the IPs of the new droplet.
3. Now access the droplet using SSH. The Ghost CLI will start initialising the droplet with the default Ghost installation. We don't want this installation but we do want some of the bootstrapping it does. So, we will provide our options carefully.
4. The configuration will pause to ask for the blog URL and SSL certificate email. Provide a generic URL that is not controlled as we don't need an SSL certificate to be generated. Here's what the output will look like. Of course, the SSL step will fail. That's expected and fine.

   ✔ Checking system Node.js version - found v18.17.1
   ✔ Checking current folder permissions
   ✔ Checking memory availability
   ✔ Checking free space
   ✔ Checking for latest Ghost version
   ✔ Setting up install directory
   ✔ Downloading and installing Ghost v5.79.3
   ✔ Finishing install process
   ? Enter your blog URL: https://example.com
   ✔ Configuring Ghost
   ✔ Setting up instance
   + sudo useradd --system --user-group ghost
   + sudo chown -R ghost:ghost /var/www/ghost/content
   ✔ Setting up "ghost" system user
   ✔ Setting up "ghost" mysql user
   + sudo mv /tmp/example-com/example.com.conf /etc/nginx/sites-available/example.com.conf
   + sudo ln -sf /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/example.com.conf
   + sudo nginx -s reload
   ✔ Setting up Nginx
   ? Enter your email (For SSL Certificate) youremail@gmail.com
   + sudo mkdir -p /etc/letsencrypt
   + sudo ./acme.sh --install --home /etc/letsencrypt
   + sudo /etc/letsencrypt/acme.sh --issue --home /etc/letsencrypt --server letsencrypt --domain example.com --webroot /var/www/ghost/system/nginx-root --reloadcmd "nginx -s reload" --accountemail youremail@gmail.com --keylength 2048
   ✖ Setting up SSL
   + sudo mv /tmp/example-com/ghost_example-com.service /lib/systemd/system/ghost_example-com.service
   + sudo systemctl daemon-reload
   ✔ Setting up Systemd
   + sudo systemctl is-active ghost_example-com
   + sudo systemctl start ghost_example-com
   + sudo systemctl is-enabled ghost_example-com
   + sudo systemctl enable ghost_example-com --quiet
   ✔ Starting Ghost
   One or more errors occurred.
   

5. A directory /var/www/ghost will be created. Get into the directory using

   cd /var/www/ghost
   

6. We get the configuration details of this installation using

   cat config.production.json
   

   The output will look like the following

   {
     "url": "https://example.com",
     "server": {
       "port": 2368,
       "host": "127.0.0.1"
     },
     "database": {
       "client": "mysql",
       "connection": {
         "host": "127.0.0.1",
         "user": "ghost-69",
         "password": "thepassword",
         "port": 3306,
         "database": "ghost_production"
       }
     },
     "mail": {
       "transport": "Direct"
     },
     "logging": {
       "transports": [
         "file",
         "stdout"
       ]
     },
     "process": "systemd",
     "paths": {
       "contentPath": "/var/www/ghost/content"
     }
   }
   

   Note the property of database.connection.host, database.connection.user and database.connection.password.
7. Switch to the ghost-mgr user.

   sudo -i -u ghost-mgr
   

8. Go to each directory where Ghost is installed using the following command.

   cd /var/www/ghost
   

9. Next, uninstall this Ghost instance using

   ghost uninstall
   

   This will result in the following output

   ? Are you sure you want to do this? Yes
   + sudo systemctl is-active ghost_example-com
   + sudo systemctl stop ghost_example-com
   + sudo systemctl is-enabled ghost_example-com
   + sudo systemctl disable ghost_example-com --quiet
   ✔ Stopping Ghost
   + sudo rm -rf /var/www/ghost/content
   ✔ Removing content folder
   + sudo rm -f /etc/nginx/sites-available/example.com.conf
   + sudo rm -f /etc/nginx/sites-enabled/example.com.conf
   + sudo nginx -s reload
   + sudo rm /lib/systemd/system/ghost_example-com.service
   ✔ Removing related configuration
   ✔ Removing Ghost installation
   

   This will also mean that all contents of the /var/www/ghost will be removed

Next, we will need to create directories for each of our blogs. The following steps will need to be followed for each of the blog instances. I will note only the first one.

1. Ensure you are in root user.

2. Create a directory for the Ghost instance that's going to be created.

   cd /var/www
   mkdir sayak
   

3. Modify the permissions of this directory to ensure that the ghost-mgr user can access it.

   chown ghost-mgr:ghost-mgr /var/www/sayak
   chmod 775 /var/www/sayak
   

4. Before we install Ghost, we will need to ensure that the database it needs is already present. The Ghost startup creates a database called ghost_production for the pre-created instance. For new instances, this is not automatically created but we will use that database as a template for our new database. We will need to login to MySQL as the root user and for that, we need that password.

   Thankfully, it's already present in the file /root/.digitialocean_password. Once we get the password from the file, we will login to MySQL as the root user.

   cat /root/.digitialocean_password
   

   This will display the password. Copy it to the clipboard.

   mysql -p
   

   This will prompt for the password so paste it from the clipboard.
   This should get you logged into MySQL's console.

5. First, we will check what databases are present

   SHOW DATABASES;
   

   We should get an output like

   +--------------------+
   | Database           |
   +--------------------+
   | ghost_production   |
   | information_schema |
   | mysql              |
   | performance_schema |
   | sys                |
   +--------------------+
   

6. We will also check what users are present and what kind of grants are provided to the ghost-69 user that we found from the database.connection.user property of the config.production.json file.

   SELECT user FROM mysql.user;
   

   We should get an output like

   +------------------+
   | user             |
   +------------------+
   | ghost-69         |
   | root             |
   | debian-sys-maint |
   | mysql.infoschema |
   | mysql.session    |
   | mysql.sys        |
   | root             |
   +------------------+
   

   Run the following command to check the grants provided to the user ghost-69 using the host found in the database.connection.host property of the config.production.json file.

   SHOW GRANTS FOR 'ghost-69'@'127.0.0.1';
   

   which will result in an output of

   +------------------------------------------------------------------------+
   | Grants for ghost-69@127.0.0.1                                          |
   +------------------------------------------------------------------------+
   | GRANT USAGE ON *.* TO `ghost-69`@`127.0.0.1`                           |
   | GRANT ALL PRIVILEGES ON `ghost_production`.* TO `ghost-69`@`127.0.0.1` |
   +------------------------------------------------------------------------+
   

7. Since the directory we created in /var/www was sayak, we will create a database named sayak_prod as that is the default naming convention of Ghost. We will also grant privileges to the user ghost-69.

   CREATE DATABASE sayak_prod;
   GRANT ALL PRIVILEGES ON sayak_prod.* TO 'ghost-69'@'127.0.0.1';
   

   We will verify by running

   SHOW GRANTS FOR 'ghost-69'@'127.0.0.1';
   

   which will result in an output of

   +------------------------------------------------------------------------+
   | Grants for ghost-69@127.0.0.1                                          |
   +------------------------------------------------------------------------+
   | GRANT USAGE ON *.* TO `ghost-69`@`127.0.0.1`                           |
   | GRANT ALL PRIVILEGES ON `ghost_production`.* TO `ghost-69`@`127.0.0.1` |
   | GRANT ALL PRIVILEGES ON `sayak_prod`.* TO `ghost-69`@`127.0.0.1`       |
   +------------------------------------------------------------------------+
   

8. Finally, we can exit MySQL

   exit
   

Finally, we can get around to installing Ghost.

1. Switch to the ghost-mgr user.

   sudo -i -u ghost-mgr
   

2. Go to the directory where Ghost is to be installed.

   cd /var/www/sayak
   

3. Finally, install Ghost

   ghost install
   

   There will be prompts for multiple questions

   ✔ Checking system Node.js version - found v18.17.1
   ✔ Checking current folder permissions
   ✔ Checking memory availability
   ✔ Checking free space
   ✔ Checking for latest Ghost version
   ✔ Setting up install directory
   ✔ Downloading and installing Ghost v5.79.3
   ✔ Finishing install process
   ? Enter your blog URL: https://sayakm.me
   ? Enter your MySQL hostname: 127.0.0.1
   ? Enter your MySQL username: sayak-69
   ? Enter your MySQL password: [hidden]
   ? Enter your Ghost database name: sayak_prod
   ✔ Configuring Ghost
   ✔ Setting up instance
   + sudo chown -R ghost:ghost /var/www/sayak/content
   ✔ Setting up "ghost" system user
   ℹ Setting up "ghost" mysql user [skipped]
   ? Do you wish to set up Nginx? Yes
   + sudo mv /tmp/sayakm-me/sayakm.me.conf /etc/nginx/sites-available/sayakm.me.conf
   + sudo ln -sf /etc/nginx/sites-available/sayakm.me.conf /etc/nginx/sites-enabled/sayakm.me.conf
   + sudo nginx -s reload
   ✔ Setting up Nginx
   ? Do you wish to set up SSL? Yes
   ? Enter your email (For SSL Certificate) mukhopadhyaysayak@gmail.com
   + sudo /etc/letsencrypt/acme.sh --upgrade --home /etc/letsencrypt
   + sudo /etc/letsencrypt/acme.sh --issue --home /etc/letsencrypt --server letsencrypt --domain sayakm.me --webroot /var/www/sayak/system/nginx-root --reloadcmd "nginx -s reload" --accountemail mukhopadhyaysayak@gmail.com --keylength 2048
   + sudo mv /tmp/sayakm-me/sayakm.me-ssl.conf /etc/nginx/sites-available/sayakm.me-ssl.conf
   + sudo ln -sf /etc/nginx/sites-available/sayakm.me-ssl.conf /etc/nginx/sites-enabled/sayakm.me-ssl.conf
   + sudo nginx -s reload
   ✔ Setting up SSL
   ? Do you wish to set up Systemd? Yes
   + sudo mv /tmp/sayakm-me/ghost_sayakm-me.service /lib/systemd/system/ghost_sayakm-me.service
   + sudo systemctl daemon-reload
   ✔ Setting up Systemd
   + sudo systemctl is-active ghost_sayakm-me
   ? Do you want to start Ghost? Yes
   + sudo systemctl start ghost_sayakm-me
   + sudo systemctl is-enabled ghost_cmdrgarud-blog
   + sudo systemctl enable ghost_cmdrgarud-blog --quiet
   ✔ Starting Ghost
   
   Ghost was installed successfully! To complete setup of your publication, visit:
   
       https://sayakm.me/ghost/
   

4. Finally, verify that the blog is running

   ghost ls
   

   which should give an output of

   ┌────────────────┬────────────────────┬─────────┬──────────────────────┬────────────────────────┬──────┬─────────────────┐
   │ Name           │ Location           │ Version │ Status               │ URL                    │ Port │ Process Manager │
   ├────────────────┼────────────────────┼─────────┼──────────────────────┼────────────────────────┼──────┼─────────────────┤
   │ sayakm-me      │ /var/www/sayak     │ 5.79.3  │ running (production) │ https://sayakm.me      │ 2369 │ systemd         │
   └────────────────┴────────────────────┴─────────┴──────────────────────┴────────────────────────┴──────┴─────────────────┘
   

And with that, the destination Ghost blog is up and running. Now to follow the above steps for each blog you need to migrate!

Importing from backup

Now wait! We have the destination blog running but we are yet to transfer the data. That's a simpler part and is already documented by the folks at Ghost but for the sake of completeness, I will reiterate them.

1. Copy the backups present in the local system to a location in the destination droplet.
2. Ensure you are in the Ghost installation directory, for eg. /var/www/sayak. If not, head to it using

   cd /var/www/sayak
   

3. Unzip the backups to the content directory and provide permissions to the ghost user to access all the contents within it.

   sudo unzip /location-of-backup-zip-file.zip -d content
   sudo chown -R ghost:ghost content
   

4. Switch to the ghost-mgr user

   sudo -i -u ghost-mgr
   

5. Go to the directory where Ghost is installed.

   cd /var/www/ghost
   

6. Restart the Ghost instance to load all the changes

   ghost restart
   

7. Now, we will need to restore the data to the database. We can find a json file in /var/www/sayak/content/data. This will be the source of the restore. To restore run

   ghost import content/data/the-json-file.json
   

   This will ask for an admin password. Provide the password that was used for the admin account in the source blog.
8. Restart the Ghost instance again to ensure database changes are loaded.

   ghost restart
   

9. Open the Ghost web admin portal and one should see all their content and settings.

Updating profile images

This step should not be needed but looks like for some reason, the admin profile image and the cover image aren't getting restored. The trivial way to fix it is to upload the images again in the web admin portal but I am nitpicky and don't want to re-upload images already present in the server. And yes, I checked, the files are there but the database entries are empty. So, we are going to fix that!

For this, we need a few info.

1. The MySQL ghost username. We have been using ghost-69 so that's what it will be.
2. The Password for the above username. We have used thepassword as an example.
3. The MySQL hostname. It's 127.0.0.1 as noted earlier.
4. In the json file present in /var/www/sayak/content/data, need to get the values of profile_image and cover_image from db.data.users key. The values should start with https://sayakm.me/content/images. Either or both can even be null. If both are null then the following steps don't need to be followed and you are done!

Once we have them, we can go ahead with updating the database.

1. Login to MySQL as the ghost-69 user.

   mysql -u 'ghost-69' -h '127.0.0.1' -p
   

   When prompted provide the password.
2. Activate the sayak_prod database.

   USE sayak_prod;
   

3. We will check the users table to verify the problem

   SELECT id, name, profile_image, cover_image FROM users;
   

   This should give an output like

   +----+-------+---------------+-------------+
   | id | name  | profile_image | cover_image |
   +----+-------+---------------+-------------+
   | 1  | Sayak | NULL          | NULL        |
   +----+-------+---------------+-------------+
   

   Those 2 fields should not be NULL if you had profile and cover images earlier.
4. To fix it, we will run the following command

   UPDATE users SET profile_image = 'value-from-the-profile_image-key', cover_image = 'value-from-the-cover_image-key' WHERE id=1;
   

   If one of profile_image or cover_image in the JSON file is null, don't include that in the above SQL. For eg. if profile_image is not null but cover_image is null in the JSON file, the SQL command should instead be

   UPDATE users SET profile_image = 'value-from-the-profile_image-key' WHERE id=1;
   

And with that, we are finally done! Your blog should be ready to use with everything as it was before, with a few caveats and oddities.

Caveats and oddities

1. Your theme might reset to whatever Ghost considers default. Just changing back to the earlier theme should be enough to fix that.
2. The admin panel might go back to light mode if you were a dark mode user.
3. If the theme has undergone a major change, prepare for things to break, especially if you have injected scripts and styles.

And well, that's all folks! I hope this saves some time for future folks. Remember, this is what my experience has been and Ghost moves fast and things mentioned here might not work in the future. Still, I would be happy to improve, just tweet me, or was it X me🤔.

The last few years have been been draining. The constant lockdowns along with the persistent existential threat sucked all my enthusiasm out of me. Nothing felt interesting anymore, not even gaming, one of the few joys of my life. I tried my hand at a lot of things, but nothing was interesting enough to keep me at it for long.

That is until I decided to try my hand at game development.

Now, I am a professional developer so writing code is no big thing for me. And thinking that I dove right into the murky waters. A few years back, I had tried using Unity and even made a couple of prototypes, but nothing fancy. This time, I decided that one way of keeping things interesting is to have a goal. And the goal has to be good enough to keep working towards it. So, I decided to work on a game idea that I had, slightly complicated but interesting nonetheless. And felt the Unreal Engine would be a better choice for something serious.

First, I started by researching on the tools I would need. I downloaded Unreal Engine 5 and Blender. I had some experience with Blender but that was around 9 years ago. I also downloaded Krita for designing the props. With the tools there, I started with my first Blueprint. I imported a mannequin from the UE store and realised that if I wanted to animate them, I need a gun.

So, off I went to design a carbine! And that is when I came to know about Hard Surface workflows in Blender. And it brought me such happiness! Learning about the non destructive workflows for modelling reminded me about all the CAD software I had used in the past (I have a background in Mechanical Engineering).

But that joy was short lived as I soon found all the difficulties around using only booleans. The biggest pain being bevelling. Applying a bevel to an edge that underwent a boolean operation is possible, but I can't modify the edge weight of such an edge. And it has been making me mad. I keep thinking how easy it would have been in a CAD program like an ex I can't forget about.

But, I really don't want to give up and start modelling in a CAD right now. I really want to do this the "right" way and it seems like no one uses a CAD for game development. So, once I find the resolve to apply the cutter, I will do it and then bevel manually.

I don't think programming the game is going to be as challenging for me as the other tasks like modelling. This gun itself has already taken me over 2 weeks of modelling work and 2 weeks of designing in Krita. It seems like its going to take at least 2 weeks more before I am anywhere close to finish modelling it. Moreover, I am mostly working on this in my free time and weekends (I have a full time job!).

I am planning to blog about my progress in this game without giving too much away. This is the first post so expect more of them in the future.

Now back to figuring out if I can bevel that edge not destructively!

I have been working on Kubernetes at work for a little less than a year but my job mostly involved setting up a managed cluster by a cloud provider and deploying applications and tools on said clusters. I hadn't had the opportunity to set up a cluster by myself. But, I always wanted to setup a bare metal cluster one day.

Why bare metal, you say? Well, using VMs to set up a cluster didn't seem right as a lot of the networking would still be managed. I wanted to get my hands dirty with the difficult bits. This is where the Raspberry Pis come in. I had been eyeing to buy some pis to do a project for sometime but never got around it and this seemed like the perfect opportunity.

Getting Started

Hardware needed

1. Raspberry Pi 4B 8GB - 6 units - note 1
2. Power adapters for Raspberry Pis - 6 units - note 2
3. Unmanaged switch with minimum 7 ports - note 3
4. Ethernet cables - 6 units - note 4
5. Ethernet cable - 1 unit - note 5
6. 6 layer Raspberry Pi rack - note 6
7. 32 GB microSD cards - 6 units
8. Keyboard - note 7
9. Monitor - note 7
10. HDMI to micro HDMI cable - note 7
11. PC with microSD slot or microSD adapter

Software needed

1. Raspberry Pi Imager - https://www.raspberrypi.com/software/
2. Windows Susbsystem for Linux (WSL2) - note 8
3. Ubuntu 20.04.3-raspberry pi distribution - note 9

Notes regarding the above requirements

1. You can use models with 4GB of RAM too but anything below that is cutting it close.
2. You can instead use a 6 port USB power supply but ensure that it can provide a minimum of 91.8W. You will also need 6 units of USB cables with Type-C port for the Raspberry Pi side.
3. You can also use a managed switch but I can't guarantee the below steps will work.
4. Try to get short cables to have a compact solutions.
5. This cable will connect your router to the switch so get a size that works for you.
6. Or use multiple cases or keep them lying on the desk, doesn't really matter but having a cluster case can make the setup very compact.
7. You might not need to connect your Pi with a keyboard and monitor if you can directly SSH into it at first boot. You would need to have a PC anyway.
8. Not really needed if your primary system is not Windows, or if you are comfortable using ssh in Windows or want to use a better terminal.
9. Not needed to be downloaded manually.

Setup

The 6 Raspberry Pis will be used for creating 3 control plane nodes and 3 worker nodes. All of them will be running Ubuntu 20.04.3 and will be using containerd as the container runtime. We will be using Kubeadm to install Kubernetes in a Highly Available, stacked etcd topology.

Initialise microSD cards

First, we will need to setup our microSD cards. For this, we will use the Raspberry PI Imager and we will install Ubuntu 20.04.3 on all our microSD cards.

Insert each microSD card into your computer's card reader and do the following for each card.

Open the Raspberry Pi Imager software and click the CHOOSE OS button.

Then in the list, click on Other General Purpose OS.

Select Ubuntu in the next screen.

Then select Ubuntu Server 20.04.3 LTS (RPI 3/4/400). Ensure that you are selecting the one marked 64-bit and support for arm64 architecture.

Then click on CHOOSE SD CARD. A window should popup listing in the removable drives inserted. Carefully choose the drive which maps to your microSD card. Then click on WRITE. Once the writing is completed, you can eject the microSD card and proceed with writing the next card.

# Place "config.txt" changes (dtparam, dtoverlay, disable_overscan, etc.) in
# this file. Please refer to the README file for a description of the various
# configuration files on the boot partition.

hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=82

The values for hdmi_group and hdmi_mode might differ based on your needs. If you are connecting a monitor, use hdmi_group=2. If you are connecting a TV instead, use hdmi_group=1. To find out the hdmi_mode for yourself, check https://www.raspberrypi.com/documentation/computers/config_txt.html#hdmi_mode

When you have written all the cards you can pop them in into each of your Pis. Don't power on the Pis as of yet. Connect the Pis to the switch using the ethernet cables and ensure that the switch is connected to the router. Then, turn on each Pi and proceed with the Network setup.

Network Setup

Once the Pis are turned on, connect the monitor and keyboard to each Pi in turn and proceed as follows:

1. Change the hostname by sudo hostnamectl set-hostname clstr-01-cp-01. This will change the file /etc/hostname to add the hostname to it.
   The hostname file only keeps track of the system hostname and should not be a FQDN.

2. Open /etc/hosts and add the following:

   127.0.1.1 clstr-01-cp-01 clstr-01-cp-01.sayakm.me
   

   So the complete file looks like

   127.0.0.1 localhost
   127.0.1.1 clstr-01-cp-01 clstr-01-cp-01.sayakm.me
   
   # The following lines are desirable for IPV6 capable hosts
   ::1 ip6-localhost ip6-loopback
   fe00::0 ip6-localnet
   ff00:0 ip6-mcastprefix
   ff02::1 ip6-allnodes
   ff02::2 ip6-allrouters
   ff02::3 ip6-allhosts
   

   This will ensure that calling by the hostname or the FQDN from within the system will loopback.

3. The next files to be changed will be done using netplan. This tool updates the resolv.conf via a symlink so DON'T update resolv.conf. Moreover, dhcpcd.conf doesn't exist in Ubuntu so DHCP config needs to be changed from netplan which updates /run/systemd/network so that it is flushed and recreated at boot. So, /etc/systemd/network/ doesn't have anything. To configure netplan, create a new file /etc/netplan/60-static-ip.yaml. This will override the existing file that we don't want to change. Add the following to the file

   network:
       version: 2
       ethernets:
           eth0:
               dhcp4: no
               addresses: [192.168.0.50/24]
               gateway4: 192.168.0.1
               nameservers:
                   addresses: [8.8.8.8,8.8.4.4,1.1.1.1,1.0.0.1]
   

   The above turns off DHCP. That means we need to manually configure what gateway and nameservers to use, as this was earlier provided by the DHCP server. The addresses clause is not only setting the static IP but also setting the subnet mask. The gateway is taken from the router properties. The nameservers are from Google and Cloudflare. Finally do sudo netplan apply to commit these changes.

4. Finally we will update the etc/hosts file so that the FQDNs are resolved properly when called from cluster to cluster. Add the following to the file in each cluster

   192.168.0.50 clstr-01-cp-01 clstr-01-cp-01.sayakm.me
   192.168.0.51 clstr-01-cp-02 clstr-01-cp-02.sayakm.me
   192.168.0.52 clstr-01-cp-03 clstr-01-cp-03.sayakm.me
   192.168.0.100 clstr-01-nd-01 clstr-01-cp-01.sayakm.me
   192.168.0.101 clstr-01-nd-02 clstr-01-cp-02.sayakm.me
   192.168.0.102 clstr-01-nd-03 clstr-01-cp-03.sayakm.me
   

   so that the file finally looks like this

   127.0.0.1 localhost
   127.0.1.1 clstr-01-cp-01 clstr-01-cp-01.sayakm.me
   
   # The following lines are desirable for IPv6 capable hosts
   ::1 ip6-localhost ip6-loopback
   fe00::0 ip6-localnet
   ff00::0 ip6-mcastprefix
   ff02::1 ip6-allnodes
   ff02::2 ip6-allrouters
   ff02::3 ip6-allhosts
   
   192.168.0.50 clstr-01-cp-01 clstr-01-cp-01.sayakm.me
   192.168.0.51 clstr-01-cp-02 clstr-01-cp-02.sayakm.me
   192.168.0.52 clstr-01-cp-03 clstr-01-cp-03.sayakm.me
   192.168.0.100 clstr-01-nd-01 clstr-01-cp-01.sayakm.me
   192.168.0.101 clstr-01-nd-02 clstr-01-cp-02.sayakm.me
   192.168.0.102 clstr-01-nd-03 clstr-01-cp-03.sayakm.me
   

5. Now we start installing k8s related stuff. Start with containerd CRE. Run

   sudo apt-get update
   sudo apt-get install containerd
   

   Next, we have to initialise the default config if not present. Check if the folder /etc/containerd exists. If not, create it.

   sudo mkdir -p /etc/containerd
   

   Then create the config.toml file.

   containerd config default | sudo tee /etc/containerd/config.toml
   

   Next, we need to use systemd cgroup driver in the config file with runc. Update the above config.toml file with

   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
   ...
   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
       SystemdCgroup = true
   

   The restart the containerd service.

   sudo systemctl restart containerd
   

6. We need to load some networking modules for iptables to work. Load the br_netfilter module.

   sudo modprobe br_netfilter
   

   We also need to ensure that this module is alwasys loaded on boot. So add it to a file in the modules-load.d folder.

   cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
   overlay
   br_netfilter
   EOF
   

   Then to ensure that the node iptables correctly see bridged traffic, we need to add the following to the /etc/sysctl.d/k8s.conf. Also reload sysctl.

   cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
   net.bridge.bridge-nf-call-ip6tables = 1
   net.ipv4.ip_forward                 = 1
   net.bridge.bridge-nf-call-iptables  = 1
   EOF
   sudo sysctl --system
   

   Restart the containerd server.

   sudo systemctl restart containerd
   

7. Now we are ghoing to install kubernetes and related packages. Start by
   updating the packages and installing apt-transport-https and curl. Then add the GPG key of the repo.

   sudo apt-get update
   sudo apt-get install -y apt-transport-https ca-certificates curl
   sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
   

   Then add the Kubernetes apt repository. This repo still doesn't have a folder newer than xenial.

   echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
   

   Then install kubelet, kubeadm, and kubectl and pin their versions.

   sudo apt-get update
   sudo apt-get install kubelet kubeadm kubectl
   sudo apt-mark hold kubelet kubeadm kubectl
   

   The last command is used to ensure that upgrades don't change their versions.

8. It is also important to have swap disabled permanently. It is already disabled if you have 8GB RAM during installation. If it's not disabled, disable it using the following

   sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
   sudo swapoff -a
   

9. Next we need to ensure if the memory cgroups are enabled. To check, use cat /proc/cgroups and see of the value of enabled for memory is 1 or not. If not, we have to edit the file /boot/firmware/cmdline.txt and add the following to the end of the line

   cgroup_enable=memory
   

   Then reboot the system. After the reboot, check again if the value of enabled for memory is 1 or not.

10. (FIRST MASTER ONLY) The next steps include setting the system up for a Highly Available Control Plane. This neccesitates the presence of a Load Balancer and in this case we are going to use a software best Load Balancer called kube-vip. To install kube-vip, first we need to create a config file which will be used to convert it into a manifest which will be use by kubeadm while initialising to create a static pod of kube-vip. Start by pulling the image of kube-vip and creating an alias to run the container.

    sudo ctr images pull  ghcr.io/kube-vip/kube-vip:v0.4.0
    alias kube-vip="sudo ctr run --rm --net-host ghcr.io/kube-vip/kube-vip:v0.4.0 vip /kube-vip"
    

    You can optionally permanently store the above alias in the ~/.bash_aliases.

    echo alias kube-vip=\"sudo ctr run --rm --net-host ghcr.io/kube-vip/kube-vip:v0.4.0 vip /kube-vip\" | tee -a ~/.bash_aliases
    
    . ~/.bashrc
    

11. (FIRST MASTER ONLY) Next generate the manifest for the static pod. We are turning on HA for the control plane, and load balancers for both the control plane and the worker nodes.

    kube-vip manifest pod \
        --interface eth0 \
        --vip 192.168.0.150 \
        --controlplane \
        --services \
        --arp \
        --leaderElection \
        --enableLoadBalancer | sudo tee /etc/kubernetes/manifests/kube-vip.yaml
    

12. (FIRST MASTER ONLY) Finally, we initialise the cluster using kubeadm init. We need to ensure that the installed kubernetes version is the same as kubeadm. So, first do

    KUBE_VERSION=$(sudo kubeadm version -o short)
    

    Then, initialise the cluster

    sudo kubeadm init --control-plane-endpoint "192.168.0.150:6443" --upload-certs --kubernetes-version=$KUBE_VERSION --pod-network-cidr=10.244.0.0/16
    

    --control-plane-endpoint is the IP address of the load balancer as set earlier in kube-vip.

    --upload-certs is used to upload the certificates to the kubernetes cluster automatically without us needing to supply them.

    --kubernetes-version is the version of kubernetes that you are using so that newer versions are not automatically used.

    --pod-network-cidr is the CIDR block for the pod network. This is necessary for Flannel to work.

    The output should look something like this:

    [init] Using Kubernetes version: v1.22.2
    [preflight] Running pre-flight checks
            [WARNING SystemVerification]: missing optional cgroups: hugetlb
    [preflight] Pulling images required for setting up a Kubernetes cluster
    [preflight] This might take a minute or two, depending on the speed of your internet connection
    [preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
    [certs] Using certificateDir folder "/etc/kubernetes/pki"
    [certs] Generating "ca" certificate and key
    [certs] Generating "apiserver" certificate and key
    [certs] apiserver serving cert is signed for DNS names [clstr-01-cp-01 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.50 192.168.0.150]
    [certs] Generating "apiserver-kubelet-client" certificate and key
    [certs] Generating "front-proxy-ca" certificate and key
    [certs] Generating "front-proxy-client" certificate and key
    [certs] Generating "etcd/ca" certificate and key
    [certs] Generating "etcd/server" certificate and key
    [certs] etcd/server serving cert is signed for DNS names [clstr-01-cp-01 localhost] and IPs [192.168.0.50 127.0.0.1 ::1]
    [certs] Generating "etcd/peer" certificate and key
    [certs] etcd/peer serving cert is signed for DNS names [clstr-01-cp-01 localhost] and IPs [192.168.0.50 127.0.0.1 ::1]
    [certs] Generating "etcd/healthcheck-client" certificate and key
    [certs] Generating "apiserver-etcd-client" certificate and key
    [certs] Generating "sa" key and public key
    [kubeconfig] Using kubeconfig folder "/etc/kubernetes"
    [kubeconfig] Writing "admin.conf" kubeconfig file
    [kubeconfig] Writing "kubelet.conf" kubeconfig file
    [kubeconfig] Writing "controller-manager.conf" kubeconfig file
    [kubeconfig] Writing "scheduler.conf" kubeconfig file
    [kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
    [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
    [kubelet-start] Starting the kubelet
    [control-plane] Using manifest folder "/etc/kubernetes/manifests"
    [control-plane] Creating static Pod manifest for "kube-apiserver"
    [control-plane] Creating static Pod manifest for "kube-controller-manager"
    [control-plane] Creating static Pod manifest for "kube-scheduler"
    [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
    [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
    [apiclient] All control plane components are healthy after 29.562791 seconds
    [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
    [kubelet] Creating a ConfigMap "kubelet-config-1.22" in namespace kube-system with the configuration for the kubelets in the cluster
    [upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
    [upload-certs] Using certificate key:
    feb5064c88b7e3a154b5deb1d6fb379036e7a4b76862fcf08c742db7031624d9
    [mark-control-plane] Marking the node clstr-01-cp-01 as control-plane by adding the labels: [node-role.kubernetes.io/master(deprecated) node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
    [mark-control-plane] Marking the node clstr-01-cp-01 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
    [bootstrap-token] Using token: 39w134.5w0n8s3ktz63rv47
    [bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
    [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
    [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
    [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
    [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
    [bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
    [kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
    [addons] Applied essential addon: CoreDNS
    [addons] Applied essential addon: kube-proxy
    
    Your Kubernetes control-plane has initialized successfully!
    
    To start using your cluster, you need to run the following as a regular user:
    
    mkdir -p $HOME/.kube
    sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    sudo chown $(id -u):$(id -g) $HOME/.kube/config
    
    Alternatively, if you are the root user, you can run:
    
    export KUBECONFIG=/etc/kubernetes/admin.conf
    
    You should now deploy a pod network to the cluster.
    Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
    https://kubernetes.io/docs/concepts/cluster-administration/addons/
    
    You can now join any number of the control-plane node running the following command on each as root:
    
    kubeadm join 192.168.0.150:6443 --token REDACTED \
            --discovery-token-ca-cert-hash sha256:REDACTED \
            --control-plane --certificate-key REDACTED
    
    Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
    As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
    "kubeadm init phase upload-certs --upload-certs" to reload certs afterward.
    
    Then you can join any number of worker nodes by running the following on each as root:
    
    kubeadm join 192.168.0.150:6443 --token REDACTED \
            --discovery-token-ca-cert-hash sha256:REDACTED
    

    The token has a TTL of 24 hours and the uploded certs will be deleted in two hours. So, if the other nodes are to be joined later than that, we need to re-generate the token and upload the certs again.

    a. First, check if tokens are available

    sudo kubeadm token list
    

    If nothing is shown, proceed with generatiung the token. Else, we can use the token which has a usage of authentication,signing

    sudo kubeadm token create
    

    b. If during kubeadm join, any certificate errors come up, re-upload the certificates using

    sudo kubeadm init phase upload-certs --upload-certs
    

13. (OTHER MASTER ONLY) If you want to add additional control plane nodes, you can use the kubeadm join command:

    KUBE_VERSION=$(sudo kubeadm version -o short)
    

    Then, join the cluster

    sudo kubeadm join 192.168.0.150:6443 --token REDACTED --discovery-token-ca-cert-hash sha256:REDACTED --control-plane --certificate-key feb5064c88b7e3a154b5deb1d6fb379036e7a4b76862fcf08c742db7031624d9
    

    The output should look something like this:

    [preflight] Running pre-flight checks
        [WARNING SystemVerification]: missing optional cgroups: hugetlb
    [preflight] Reading configuration from the cluster...
    [preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
    [preflight] Running pre-flight checks before initializing the new control plane instance
    [preflight] Pulling images required for setting up a Kubernetes cluster
    [preflight] This might take a minute or two, depending on the speed of your internet connection
    [preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
    [download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
    [certs] Using certificateDir folder "/etc/kubernetes/pki"
    [certs] Generating "front-proxy-client" certificate and key
    [certs] Generating "etcd/server" certificate and key
    [certs] etcd/server serving cert is signed for DNS names [clstr-01-cp-03 localhost] and IPs [192.168.0.52 127.0.0.1 ::1]
    [certs] Generating "etcd/peer" certificate and key
    [certs] etcd/peer serving cert is signed for DNS names [clstr-01-cp-03 localhost] and IPs [192.168.0.52 127.0.0.1 ::1]
    [certs] Generating "etcd/healthcheck-client" certificate and key
    [certs] Generating "apiserver-etcd-client" certificate and key
    [certs] Generating "apiserver" certificate and key
    [certs] apiserver serving cert is signed for DNS names [clstr-01-cp-03 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.52 192.168.0.150]
    [certs] Generating "apiserver-kubelet-client" certificate and key
    [certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
    [certs] Using the existing "sa" key
    [kubeconfig] Generating kubeconfig files
    [kubeconfig] Using kubeconfig folder "/etc/kubernetes"
    [kubeconfig] Writing "admin.conf" kubeconfig file
    [kubeconfig] Writing "controller-manager.conf" kubeconfig file
    [kubeconfig] Writing "scheduler.conf" kubeconfig file
    [control-plane] Using manifest folder "/etc/kubernetes/manifests"
    [control-plane] Creating static Pod manifest for "kube-apiserver"
    [control-plane] Creating static Pod manifest for "kube-controller-manager"
    [control-plane] Creating static Pod manifest for "kube-scheduler"
    [check-etcd] Checking that the etcd cluster is healthy
    [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
    [kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
    [kubelet-start] Starting the kubelet
    [kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
    [etcd] Announced new etcd member joining to the existing etcd cluster
    [etcd] Creating static Pod manifest for "etcd"
    [etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s
    The 'update-status' phase is deprecated and will be removed in a future release. Currently it performs no operation
    [mark-control-plane] Marking the node clstr-01-cp-03 as control-plane by adding the labels: [node-role.kubernetes.io/master(deprecated) node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
    [mark-control-plane] Marking the node clstr-01-cp-03 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
    
    This node has joined the cluster and a new control plane instance was created:
    
    * Certificate signing request was sent to apiserver and approval was received.
    * The Kubelet was informed of the new secure connection details.
    * Control plane (master) label and taint were applied to the new node.
    * The Kubernetes control plane instances scaled up.
    * A new etcd member was added to the local/stacked etcd cluster.
    
    To start administering your cluster from this node, you need to run the following as a regular user:
    
            mkdir -p $HOME/.kube
            sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
            sudo chown $(id -u):$(id -g) $HOME/.kube/config
    
    Run 'kubectl get nodes' to see this node join the cluster.
    

14. (OTHER MASTER ONLY) Then, perform step 11 on the other master nodes. This is because kubeadm doesn't like a non-empty /etc/kubernetes/manifests folder.

15. (WORKER ONLY) Then, we join the worker nodes into the cluster using kubeadm join. We need to ensure that the installed kubernetes version is the same as kubeadm. So, first do

    KUBE_VERSION=$(sudo kubeadm version -o short)
    

    Then, join the cluster

    sudo kubeadm join 192.168.0.150:6443 --token REDACTED --discovery-token-ca-cert-hash sha256:REDACTED
    

    The output should look something like this

    [preflight] Running pre-flight checks
        [WARNING SystemVerification]: missing optional cgroups: hugetlb
    [preflight] Reading configuration from the cluster...
    [preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
    [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
    [kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
    [kubelet-start] Starting the kubelet
    [kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
    
    This node has joined the cluster:
    * Certificate signing request was sent to apiserver and a response was received.
    * The Kubelet was informed of the new secure connection details.
    
    Run 'kubectl get nodes' on the control-plane to see this node join the cluster.
    

16. (MASTER ONLY) Next follow the instructions in the above output to create the kubectl config file in the home directory.

    mkdir -p $HOME/.kube
    sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    sudo chown $(id -u):$(id -g) $HOME/.kube/config
    

17. (FIRST MASTER ONLY) Next we will deploy the pod network. We are going to use Flannel for this. We are using Flannel 0.15.0 for this. It's always better to anchor the version.

    kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.15.0/Documentation/kube-flannel.yml
    

18. (WORKER ONLY) Next copy the kubectl config file to the worker nodes. We can't use sudo to copy from the remote system and ubuntu disables the root user. So, we need to copy over the config present in the $HOME/.kube/config file.

    mkdir -p $HOME/.kube
    scp ubuntu@clstr-01-cp-01:~/.kube/config $HOME/.kube/config
    

Accessing the Cluster

Now that the cluster is all set up, we can start connecting to it from outside the cluster. We do this by copying the config file from any one of the nodes. Run the following in Powershell.

# Backup any existing config file since the scp will overwrite such file. This will fail if no config file is present
Copy-Item $HOME\.kube\lol $HOME\.kube\config-bk

# We are using the IP directly as the hostname is not configured in the Windows system
scp ubuntu@192.168.0.50:~/.kube/config $HOME\.kube\config

Now open a terminal and run kubectl get nodes. This should fetch all 6 nodes as follows.

NAME             STATUS   ROLES                  AGE    VERSION
clstr-01-cp-01   Ready    control-plane,master   224d   v1.22.2
clstr-01-cp-02   Ready    control-plane,master   222d   v1.22.2
clstr-01-cp-03   Ready    control-plane,master   222d   v1.22.2
clstr-01-nd-01   Ready    <none>                 224d   v1.22.2
clstr-01-nd-02   Ready    <none>                 224d   v1.22.2
clstr-01-nd-03   Ready    <none>                 224d   v1.22.2

That's all folks!

And with that, you have a fully functional Kubernetes cluster ready to roll. There are some other challenges like persistent volumes but that's a blog post for another day.

If you have any questions or have spotted a mistake, feel free to tweet me.

I recently saw a tweet about a dead horse getting beaten up one more time.

Only just read this, and it's a couple of months old now, but it expresses the concerns and fears of many about the future of #EliteDangerous and #elitedangerousodyssey worth a read. https://t.co/eikrb2KF31

— Drew Wagar (@drewwagar) October 12, 2021

I am on a holiday right now so I have plenty of time to rage about people on the internet sharing their negative opinion on something I am positive about and writing a 2200 word blog post on why I think they are wrong. So here goes. I will first dissect the above blog post and then provide my own opinion on Elite Dangerous.

Before that, let me introduce myself. I am a long time Elite Dangerous player and go by CMDR Garud in game. I decided to put this out in my personal blog as these thoughts are not a great fit for my RP blog. Moreover, it involves discussion of other games which I wouldn't do role playing as CMDR Garud. Consider these thoughts to be from Sayak and not from Garud.

The Appeal of Elite Dangerous

Here the writer is pretty much spot on. The fact that you can do pretty much whatever you want, go wherever you want with your ship in Elite Dangerous is a core appeal of the game. But the writer makes some assumptions about Elite Dangerous that is just not true.

In Elite Dangerous you are not truly alone. Sure, if you want to be alone, there is a whole galaxy out there to be away from everybody. But you need not be. Elite Dangerous is a multiplayer game too. You can easily group up with people and can do the same stuff that you would do alone, with a group. Elite Dangerous not only shines by hitting home the loneliness and the vastness of the galaxy but also the joys of social interactions.

And although Elite Dangerous falls in the same genre as No Man's Sky and Star Citizen, its very difficult to compare them. The comparison is not like all the generic AAA First Person Shooters available. The above 3 games have their focus and is not trying to be like the other and this is something gamers need to understand.

Where's the flaw?

It has been said time and again that Elite Dangerous is repetitive and grindy. Has those people seen the gaming market? Do they think that playing the same game with different guns and maps is not repetitive? COD is not repetitive? Rocket League is not repetitive? I know I will get hundreds of people saying they are not but what is the difference?

Let me tell you an experience I had with another MMO. Elder Scrolls Online. Initially I was having a great experience, doing quests and playing the story. Some people asked me if I actually read through NPC dialogues and I said "Yes, of course!". Then once the story finished, I decided to complete the maps. This started a grind of me all side quests and dungeon running, and this made me realize what those people were talking about. So, I will change my style. I will stop trying to complete the map and take on the story more.

Honestly, if someone says that a game was repetitive after playing it for over 1500 hours, I would suggest to take that opinion with a pinch of salt.

Nothing, except self motivation

I almost have no problem in this segment although it is written in a negative tone. So, let me reiterate it in a positive one.

Elite Dangerous is a Galaxy sized sandbox where the game doesn't railroad you in playing the way it wants. You play the game you want with the tools available to you. It focuses on realism and like any realistic scenario, you are not the Hero. You are nothing in the beginning. Your purpose in Elite Dangerous is to create your own path, blaze your own trail and have a journey from nothing to influencing your own region of space and even the future of the galaxy!

What keeps Elite Dangerous running

I agree that the community plays a big part in shaping Elite Dangerous. The tools developed by the community has become an indispensable part of the playing experience (I am one of them so I know). So, has the many community groups focused on a particular activity like the Fuel Rats. For that matter, I would like to see a game which doesn't require a community to survive.

The community is a huge part of the Elite Dangerous experience. You might be a solo player but being a part of the community can greatly increase the satisfaction that you can draw from the game.

At this stage I would like to stress the fact that it would be unfair to compare Elite Dangerous to any random game which doesn't need a player to be a part of the community to enjoy it. If you don't want to be a part of the community, you will probably not enjoy Elite Dangerous for long. And that is fine! Just like if you don't like horror, you won't enjoy a horror game for long no matter how well it is made!

Elite Dangerous' demise

Demise? Seriously? The author makes some pretty wild and incorrect claims in this part. Let me go through them. EVA repairs in spacesuits, ship interiors, landable atmospheric planets and capturing other ships were ideas. They were never promised as such. They were discussed as part of their vision and visions are never promises, because visions change over the course of time.

Moreover ship interiors were never cancelled. They weren't promised in the first place!

Half-baked deliveries everywhere

This is a frequent complain. And this I kind of agree with. Elite Dangerous has the tendency to release a core gameplay loop first and then improve upon it later. Would it have been better to release things a gameplay loop fully finished? Maybe? But there is a risk that the community won't like the loop and it will be a lot of wasted effort so the developers will double down and so on. I don't see a great outcome from this.

Live service gaming is here to stay and I personally don't hate this system. It keeps things fresh or keeps our hopes for fresh things in the future.

My feelings end at "something is missing" and I can't make a cohesive argument as to exactly what it is. I have heard people say that Elite Dangerous lacks "inter-connectivity" between different parts of the gameplay. But if someone asks me to explain I won't be able to. As such, I keep my opinions my own. Cause its possible that this "feeling" is just a result of the community repeating a sentiment and me subconsciously echoing it. Maybe majority of the community just echoes this sentiment without understanding where it comes from.

You wouldn't talk, you wouldn't listen

Ahh! The age old "no communication" argument. This is a rhetoric not only from the Elite Dangerous community but in all major gaming communities. It seems like every individual wants to be heard. They argue that since they have bought a game, they have the right to be heard. But guess what? Over the years I have seen people on both sides of an argument. Almost every time a new feature is released, people get divided on either side. This means that the side whose arguments are not implemented, they will feel that they have not been heard.

The author talks about the developer's not playing the game. Well, they certainly don't play it for 10 hours a week cause they are working on making it. But do they not play it at all? Do people really want me to believe that a developer doesn't use the software they have developed?

Since we are talking from a developer's perspective, let me put in another revelation. A developer need not be using the software they built regularly. That includes games. I might be developing a CRM suite but at the end of the day, I have no need to use one for my day to day life.

Also, gamers need to understand that games are just software. Gamers are just another consumer of a software.

Sigh, I got sidetracked. As you might know this part is a personal pet peeve of mine. Having the perfect amount of communication is next to impossible. The more you communicate, the more communication will be demanded. And any discussion of future ideas will immediately be converted as a promise. Case in point, the blog in question, as pointed earlier.

I am not the kind of person who complains without knowing a way to fix the thing I am complaining about. If I don't know how to fix, I get someone who knows how to fix. The community managers of Elite Dangerous are doing more than ever to keep the community updated with the latest happenings and honestly I don't see what better could be done.

Can Elite Dangerous be saved?

It doesn't need saving in the first place. Elite Dangerous was always a niche game. NMS and Star Citizen always got more hype and as much I would like to see Elite Dangerous become more popular, I can understand that the huge learning curve it has can be a struggle to some. Hence, Elite Dangerous has perpetually been a low traffic (comparatively) game.

The Odyssey was disastrous. Nobody disagrees on that. But is that enough to kill the game? Not really. Player numbers have certainly dwindled but that should not be a death blow. More games have gone through rough patches and up until Odyssey, the game was improving in many ways, networking being one of the major ones. I am pretty sure that Odyssey has left its worst days behind and the latest updates have been promising. But I am not holding this to the author as the blog post in question was posted a couple of months ago.

As to the things the developers needs to do. I cannot recollect anything that they have promised and not delivered. Its a very different thing if the author and the community assumes some ideas to be promises and if they do so, its none of the developers fault. And if I understand this right, if the developers don't deliver these made up promises, they won't gain any trust. Well, that's a strange situation to be in.

Now, regarding the technicalities. I don't know how the author assumes anything about the COBRA engine and its capabilities but its correct that bad tools can cause severe headache for the developers. But can developers just ignore a requirement because it would be a pain to develop? I don't understand how the author makes this assumption. Since the author calls themselves a computer scientist, I presume that wherever they work they get this kind of flexibility. I have not seen something like that happen in my immediate work network.

Regarding the concept of generating a minimum viable product (MVP). Honestly, it seems like people have not seen what a MVP looks like. This is much more complete that any MVP will ever be. I just wish people would stop echoing the same rhetoric without having any understanding of MVP.

Also, a note to the author. Elite Dangerous is not your game. In this "purely capitalist" world, it is the game of Frontier Development. And no manager would want to lose out on a profit margin because no one likes to lose their job.

My personal thoughts on Elite Dangerous

I started playing Elite Dangerous in summer 2016. Till date, I have around 1850 hours in it. Its a small number considering I have played over 5 years. The major reason being that I took things slow. I didn't rush to my Anaconda. I got my Imperial Clipper and Federal Corvette a few months back. I didn't play Elite Dangerous like my life depended on it. Sometimes I would play it a lot and get close to a burn out and every time I would take breaks. The author mentions about the love-hate relationship with Elite Dangerous. For me, my relationship with Elite Dangerous has been more of a healthy one. I gave the game space and in return the game stayed enjoyable.

Elite Dangerous is not your average FPS and it is best to not treat it as such. Get engaged with the community, take breaks regularly and try to do the various things that the game has to offer.

I don't consider myself as a gamer. And if I can enjoy Elite Dangerous, so can you.

Fly safe. o7

Honestly, I have had it with Banking applications and their God awful "security" measures. Its almost as if they want malicious actors to get access to their customer's accounts. And its not just any one bank in particular, I have seen the same thing over and over again with multiple ones, at least those in India. I can't comment on other international banks but I have a hunch they would be pretty much the same.

Now, where should I start. How about something that not only banks but even big name tech companies are guilty of.

Expiring passwords

Microsoft released a lengthy explainer on why password expiration is a bad practice (scroll down a bit in the link). In short:

1. When humans are forced to change their passwords, too often they’ll make a small and predictable alteration to their existing passwords, and/or forget their new passwords.
2. Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem.
3. What should the recommended expiration period be? If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven’t implemented modern mitigations, how much protection will they really gain from password expiration?

The above points are directly copies from the linked article. I suggest everyone to have a read through that. Password expiry is an archaic practice that I have no idea why anyone came up with. It gives a false sense of security to the organizations and causes unnecessary friction to the end users. Just STOP.

Disabling right click/context menu

Me: Okayyyyy, so I have an extremely complex password that has been generated by Hardware Random Number Generator which is stored in an encrypted vault that I need biometric access to and I will copy the password since there is no way to remember it and paste it onto the password fie...

Banking Portal: NOOO! You can't go around pasting text into the password field. What if, what if a hacker ummm does something. Yeah, like uh, copy your password from this field, yeahh, that's it!

Me: But I have already copied it onto my clipboard. If someone is sniffing my clipboard, then its already gone and its my fault for not protecting my system. Moreover, why disable pastes? What will a "hacker" do by pasting on behalf of me?

Banking Portal: Rrreeeeee...

Thankfully, the above is not a conversation I had to have in my real life. Why on earth would anyone disable context menus in the login forms is beyond me. What kind of attack surface are they trying to protect? Is it worth it to prevent a user from using a complex password and use "Name@123". Is the attack surface caused by bad passwords better smaller than the one being protected by the above. I am lost on this. I dare not even google it up. If anyone has any insights, please tweet me...

Sending OTP over SMS

When this one is looked in conjunction with the others, it makes the whole thing a criminal negligence. Sending OTPs over SMS is an extremely insecure practice. Full Stop. You might have all the security in the world, but if the OTP is jacked (and there are ways it can be), you will instantly lose access to your account. I am yet to see a single bank implementing any reliable 2FA of any sorts. Organisations need to realise how insecure this method is and stop implementing on new projects. Especially for such security critical tasks.

Frequent session expiration

Ok, so this one is not the fault of the banks. And it might be a bit controlversial one too. This is because the above is because of a certain requirement of PCI DSS (Payment Card Industry Data Security Standard). Reqquirement 8.1.8 states that:

If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Now, I get, I get. The intention of this requirement is to ensure that someone else isn't able to access the account from the same system when the user walks away. It even mentioned in the above doc:

When users walk away from an open machine with access to critical system components or cardholder data, that machine may be used by others in the user’s absence, resulting in unauthorized account access and/or misuse.

Isn't there a discrepancy between the intention and the implementation. The intention is surely when the user "walks away" or isn't in front of the system. So, why does the session still time out when I am looking at my bank balance and dwelling in my pain. Should switching to a different tab be considered "walking away"? Should banks start monitoring users via a webcam to see if the user is "walking away"? In my opinion, this is a poorly worded and an even poorly implemented requirement. Cause the only way to keep the session running would be click something (which I guess sends a request to the backend which refreshes the stay alive lifetime) or click on the annoying popup which asks me if I am there 1 minute before the session expires. Here is a better (allegedly in my head) idea that I cooked up in a couple of seconds. How about sending a stay alive pulse on mouse movement. That won't solve my staring into my transactions while I reconsider my life choices but should provide a much better experience to most other users. All in all, this needs better implementation and I wish OS developers and web developers came together to find a better way to implement this.

All in all, these are some of the great UX problems in banking applications that they just pander around as "security features". They are not! I am pretty sure that this is just the tip of the iceberg as there is a vast ocean of banking applications that I certainly haven't used. Let me know via a tweet if you have faced something similar or anything new.

I am an early adopter of technology, as long I don't have to pay and what better way to do that than using the latest and the greatest of the frameworks or tools while developing. This is my experience of trying to use ES Modules in my TypeScript project and my thoughts on it.

I am working on a library to scaffold discord bots, (I maintain a couple of them and a scaffold would decrease a lot of the redundant work) and I use TypeScript for that. Now, I started my project using tsdx but I soon found out that it was not maintained nowadays. So, instead of using a fork, I decided to roll out my own Typescript starter to use it myself and for the community. Enter ts-boot which is still a WIP (contributions welcome).

Since I had a clean slate in front of me, I was thinking of using the latest standards and what could be more latest than using ES Modules instead of CommonJS. TypeScript with ES2020 targeting Node 14+ and ES Modules would be bleeding edge and a dream to develop right?

Wrong!

Now before the internet people starts judging me I should state that this is not my first rodeo in TypeScript. I have a love-hate relationship with TypeScript. I keep coming back to Typescript only to get frustrated again. I love typed languages yet the disjoint way that most libraries have their code and typings separated (via DefinitelyTyped) makes things more cumbersome that it needs to be. Quite a few times I have faced the issue wherein the @types package has not been updated for a package that has been. This causes friction that I could have avoided if I just stuck with JavaScript. But those sweet sweet types brought me back again and again.

Now don't get me wrong. I hardly face any issues nowadays. Many large packages provide their own types which makes things much smoother and for those that still have broken types, I can use any casting to force things to work. Now you might ask, why I don't contribute by fixing the types. I do. But working with the DefinitelyTyped monorepo with its bazillion files is not exactly a great experience. I can do a bare clone in git but still, its not exactly a great experience.

So, knowing all these pains, I still decided to not only use TypeScript but also use ES Modules in my latest project. This is what my package.json and tsconfig.json looks like:

{
  "name": "ts-boot",
  "version": "0.0.1",
  "description": "Typescript project bootstrapper",
  "keywords": [
    "typescript",
    "boot"
  ],
  "type": "module",
  "homepage": "https://github.com/SayakMukhopadhyay/ts-boot#readme",
  "bugs": {
    "url": "https://github.com/SayakMukhopadhyay/ts-boot/issues"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/SayakMukhopadhyay/ts-boot.git"
  },
  "license": "Apache-2.0",
  "author": "Sayak Mukhopadhyay <mukhopadhyaysayak@gmail.com>",
  "main": "index.js",
  "bin": {
    "tsboot": "./dist/index.js"
  },
  "files": [
    "dist",
    "templates"
  ],
  "scripts": {
    "start:create": "ts-node src/index.ts create myproject",
    "start:create:basic": "ts-node src/index.ts create myproject -t basic",
    "start:build": "ts-node src/index.ts build lmao",
    "build": "tsc",
    "build:watch": "tsc --watch",
    "prepare": "husky install",
    "lint": "eslint \"{src,templates,test}/**/*.ts\"",
    "lint:fix": "eslint \"{src,templates,test}/**/*.ts\" --fix",
    "test": "jest",
    "test:watch": "jest --watch",
    "test:cov": "jest --coverage",
    "test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand",
    "test:e2e": "jest --config ./test/jest-e2e.json"
  },
  "dependencies": {
    "commander": "^8.2.0",
    "fs-extra": "^10.0.0",
    "inquirer": "^8.1.5",
    "mustache": "^4.2.0",
    "typescript": "^4.4.3"
  },
  "engines": {
    "node": ">=14"
  },
  "devDependencies": {
    "@types/fs-extra": "^9.0.13",
    "@types/inquirer": "^8.1.3",
    "@types/jest": "^27.0.2",
    "@types/mustache": "^4.1.2",
    "@typescript-eslint/eslint-plugin": "^4.32.0",
    "@typescript-eslint/parser": "^4.32.0",
    "eslint": "^7.32.0",
    "eslint-config-prettier": "^8.3.0",
    "eslint-plugin-prettier": "^4.0.0",
    "husky": "^7.0.2",
    "jest": "^27.2.4",
    "prettier": "^2.4.1",
    "ts-jest": "^27.0.5",
    "ts-node": "^10.2.1"
  }
}

{
  "include": ["src/**/*"],
  "compilerOptions": {
    // type checking
    "exactOptionalPropertyTypes": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitOverride": true,
    "noImplicitReturns": true,
    "noPropertyAccessFromIndexSignature": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "strict": true,
    // module
    "module": "ES2020",
    "moduleResolution": "node",
    "rootDir": "src",
    "resolveJsonModule": true,
    // emit
    "outDir": "dist",
    // imterop constraints
    "allowSyntheticDefaultImports": true,
    "forceConsistentCasingInFileNames": true,
    // language and environment
    "lib": ["ES2020"],
    "target": "ES2020",
    // completeness
    "skipLibCheck": true
  }
}

My problems started immediately. I was importing from fs-extra as such:

import { copySync, readdirSync, readFile, readFileSync, writeFile } from 'fs-extra';
import { render } from 'mustache';
...

This immediately started failing. The reason is that I need to write my imports exactly the way I want it to be in the compiled JavaScript files. So, the correct way to do it would be:

import mustache from 'mustache';
import fs from 'fs-extra';

const { copySync, readdirSync, readFile, readFileSync, writeFile } = fs;
const { render } = mustache;

Moreover, during importing another module, one needs to use the .js extension. For eg.

import { Commands } from './commands.js';

This makes my skin crawl. JavaScript is already a meme and this doesn't help the JS/TS ecosystem in any way. Moreover, .eslintrc.js files no longer work cause ESLint still uses CommonJS to load and since we are using "type": "module" in our package.json, the whole project is now ES Module'd. And although ES Module projects can call CommonJS modules, the other way round is not possible. So, you either gotta rename the ESLint config to .eslintrc.cjs or change the format to JSON. Similar actions may need to be taken for other libraries that uses a JS config file.

It was OK, till now but the final nail hit in the coffin when I found out that Jest would not work. No matter I used a JSON or a CJS file, my tests wouldn't run at all and would give a module error. I was planning to use ts-jest and my configuration looked like:

module.exports = {
  preset: 'ts-jest',
  testEnvironment: 'node'
};

Now I don't know if I missed something or was messing something up on my part but I had already spent around 2 days working on scaffolding the library which would scaffold TypesScript project so that I could scaffold my project which scaffolds a Discord project. I threw my arms in the air, changed the config to use CommonJS and started writing this blog. Maybe I will have an easier time in a year or so.

Look forward to more posts from me regarding my experiences in working with my projects.

This blog post is not meant to be a tutorial on how to (or how not to) use ES Modules with TypeScript. Its meant to document my experiences and take it as such. But my situation might resonate with someone who have gone through a similar situation.

Well, so here I am. After working professionally over 5 years and 4 more as an engineer, I have finally decided to finally put in some effort into maintain a blog. I have been mulling over this for quite a while and finally bit the bullet.

I have tried starting a blog multiple times. Most of the times I have focused on a writing a type of blog like and software development blog but I soon realised that I wanted to write more of my thoughts than just programming tips. So, I purchased a non-bloggy domain and setup another blog. Yeah, I have another blog at https://cmdrgarud.blog/. Its a bit of a role playing blog so it might not be for everyone.

Also, I had to choose a CMS for writing my blog. Initially I had pretty much decided to go with wordpress but my years of great experience with ghost with my other blog made me make the switch. Things are much simpler and it makes it easier for me to focus on the content and not keep on making endless tweaks as I did with wordpress. Give ghost a try if you are looking for a no-frills CMS.

I think I have rambled along for long enough. Its time for me to get back to work. Do look forward for more blog posts. Until then, o7.