Category Archives: Linux

List supported Chiper Suits in Kong Gateway using kubectl

Working with data transportation (integration) you sometimes need to check the support for some obscure chiper suit that only works with machines from the 60’s 🙂 Here is one way to do that

# Get the name of a kong gateway pod. Here in the namespace "kong"
> kubectl get pods -n kong

...
kong-gateway-abcdef
...

# List chiper suits supported by the pod
> kubectl -n kong exec -it kong-gateway-abcdef -- openssl ciphers -v

Defaulted container "proxy" out of: proxy, clear-stale-pid (init)
TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any  Au=any   Enc=AESGCM(256)            Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any  Au=any   Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any  Au=any   Enc=AESGCM(128)            Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256)            Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(256)            Mac=AEAD
DHE-RSA-AES256-GCM-SHA384      TLSv1.2 Kx=DH   Au=RSA   Enc=AESGCM(256)            Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
...

Tested on Kubernetes v1.29.15, Kubectl v1.27, OpenSSL v3.0.30 and OSX v15.6.1

Apt Cheat Sheet

Update the local package library

apt-get update

Upgrade all packages

apt-get upgrade

Upgrade ONE package

apt-get install --only-upgrade git

Install a package

apt-get install <package name>

Install a specific version

apt install <package name>=<version> # ex. apt install git=1.25.1

Remove a package

apt-get remove <package name>

Remove unused dependencies

apt-get autoremove

Search for a package

apt-cache search <package name>

Show package info

apt show <package name>

Lista all versions for a package

apt list --all-versions <package name>

When you hit GRUB console on boot in an ASUS VivoMini UN45 with Ubuntu 18.04

I have an ASUS VivoMini that I run Ubuntu 18.04 on as a place for databases, Docker containers, and other stuff. Every now and then it boots me into GRUB console on reboots.

I’m here going to show how I use to solve is:

grub> set root=(hd0,2)
grub> linux /boot/vmlinuz-4.15.0-112-generic root=/dev/nvme0n1p2
grub> initrd /boot/initrd.img-4.15.0-112-generic
grub> boot

Explanation:
set root=(hd0,2) sets the disk an partition where the Linux installation is. Here is the first drive (hd0) and the second partition (2)
linux /boot/vmlinuz-4.15.0-112-generic root=/dev/nvme0n1p2 here I set the Linux kernel and the root path. It’s where I usually mess up. Most guides tell you to use /dev/sdaX (or sdbX or similar). The problem is that I use an internal Intel SSD witch identifies as nvme0 and not sda2, so when I try to use sda2 I get: “Gave up waiting for root file system /dev/sda2 does not exist. Dropping to shell”, but when I use nvme0n1p2 it works (nvme0n1p2 means first disk (n1) and second partition (p2))
initrd /boot/initrd.img-4.15.0-112-generic sets the initrd file. This has to be the same version as the vmlinux version
boot simply boots the system with the settings above. If all goes well we should reach the Ubuntu login screen (or console)

To make the changes permanent (until the next power outage or other misfortune) 

sudo update-grub

This will collect all data from the settings above and create a grub.cfg file. I needed sudo on my system, maybe you don’t. After we have created a new grub.cfg file we need to install it on the disk boot sector (not on a partition so no number for disk or partition here). For me, this was done by:

sudo grub-install /dev/nvme0

The system should now behave again 🙂

Tested on Ubuntu 18.04, GRUB 3.0, and Linux kernel 4.15.0-112