Sometimes you create a virtual machine in Libvirt/KVM with a qcow2 disk and later realise you need more space.
The good news is you can expand the disk without rebuilding the VM. This post walks through the process step by step.

1. Shut down the VM

It’s safest to resize while the VM is powered off.

# Shutdown the vm
virsh shutdown <vm-name>
# Confirm the vm is shutdown
virsh list --all

2. Resize the qcow2 image

On the host, increase the size of the disk file. You can either grow by a delta or set an absolute size.

# Add 500 GB
qemu-img resize /var/lib/libvirt/images/<vm-name>.qcow2 +500G

# Or set to a fixed size (2 TB total)
qemu-img resize /var/lib/libvirt/images/<vm-name>.qcow2 2T

3. Start the VM

Bring the VM back up:

virsh start <vm-name>

4. Grow the partition inside the VM

Inside the VM, check what the disk looks like:

lsblk

If your root/data partition is /dev/vda1, you can expand it:

# Expand the partition
sudo growpart /dev/vda 1

# Resize the filesystem
# For ext4:
sudo resize2fs /dev/vda1

# For XFS:
sudo xfs_growfs /

Now the OS can use the additional space.

5. Verify the new size

You should see the extra capacity available

dh -h

Notes & Tips

• You can run qemu-img resize while the VM is running, but the guest won’t see the change until a rescan or reboot.
• If you use LVM inside the VM, you’ll also need pvresize and lvextend before running resize2fs or xfs_growfs.
• For storage nodes (e.g. Longhorn or Ceph), make sure you resize the data disk partition, not just the root disk, so the cluster sees the capacity.

Cockpit is great for managing a box, but it ships with a self-signed cert. Here’s a clean, repeatable way to put a real Let’s Encrypt cert on Cockpit and keep it renewing automatically.

We’ll use the DNS-01 challenge with Cloudflare (works behind firewalls and supports wildcards).

What you’ll end up with

• https://cockpit.your-domain.tld:9090 on a valid Let’s Encrypt certificate
• Auto-renewals via the Certbot snap systemd timer
• A deploy hook that restarts Cockpit only when this cert renews

Requirements

• Ubuntu 22.04+ (works on 24.04 too)
• Cockpit installed and running on port 9090
• A Cloudflare API token scoped to just the zone you need (DNS:Edit is sufficient; add Zone:Read if required)

1) Install Certbot

sudo snap install --classic certbot

The snap sets up a systemd timer for renewals out of the box.

2) Get a certificate

# allow plugins to run with root and install the cloudflare dns plugin
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

# token file (restrict perms!)
sudo mkdir -p /root/.secrets/certbot
sudo tee /root/.secrets/certbot/cloudflare.ini > /dev/null <<'EOT'
dns_cloudflare_api_token = AN_API_TOKEN_HERE
EOT
sudo chmod 600 /root/.secrets/certbot/cloudflare.ini

# issue the cert (add a wildcard if you want)
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  --domain cockpit.example.com \
  --deploy-hook 'systemctl restart cockpit.socket'

Using the --deploy-hook 'systemctl restart cockpit.socket arg we can make sure Cockpit restarts when the certificate is renewed.

3) Point Cockpit at the Let’s Encrypt cert

Cockpit reads certs from /etc/cockpit/ws-certs.d/. It picks the alphabetically last .cert file and expects a matching .key (same basename). The key must be unencrypted.

sudo mkdir -p /etc/cockpit/ws-certs.d

# pick a basename that sorts late (e.g., 99-*)
sudo ln -sf /etc/letsencrypt/live/cockpit.example.com/fullchain.pem /etc/cockpit/ws-certs.d/99-letsencrypt.cert
sudo ln -sf /etc/letsencrypt/live/cockpit.example.com/privkey.pem   /etc/cockpit/ws-certs.d/99-letsencrypt.key

# reload Cockpit
sudo systemctl restart cockpit.socket

# sanity check
sudo /usr/lib/cockpit/cockpit-certificate-ensure --check

4) Renewals (already handled)

sudo certbot renew --dry-run
systemctl list-timers | grep certbot

That’s it, Cockpit will have be using a real certificate from Let’s Encrypt.

What is terraform-variable-sort?

terraform-variable-sort is a handy script designed to bring order to your Terraform variable files. By sorting your variables alphabetically, you can improve readability and ensure that your variable definitions follow a consistent pattern. Whether you’re working on a small project or a large-scale infrastructure, maintaining well-organized variable files is essential.

For more information on the terraform-variable-sort script look here

Requirements

This script relies on GNU awk, which is readily available on most Linux distributions. If you’re using macOS, you can install gawk using Homebrew:

brew install gawk

With gawk or awk installed, you’re ready to proceed.

Installation

Getting terraform-variable-sort up and running is a breeze. You can install it using Homebrew, making it even more convenient to manage your Terraform projects.

brew tap sculley/homebrew-formula
brew install terraform-variable-sort

Alternatively, you can use the script manually by running the following command:

curl -s https://raw.githubusercontent.com/sculley/terraform-variable-sort/main/terraform-variable-sort.sh -o terraform-variable-sort.sh
chmod +x terraform-variable-sort
mv terraform-variable-sort /usr/local/bin

With the terraform-variable-sort command installed, you’re all set to start sorting your Terraform variables.

Usage

The simplest way to sort your Terraform variables is by running terraform-variable-sort without any arguments. By default, it looks for a file named variables.tf in your current directory:

variable "foo" {
    description = "foo"
    type = string
    default = "foo"
}

variable "bar" {
    description = "bar"
    type = string
    default = "bar"
}

terraform-variable-sort

If your variable file has a different name or is located elsewhere, you can specify it as the first argument:

terraform-variable-sort my_variables.tf

After running your variables file should now look like

variable "bar" {
    description = "bar"
    type = string
    default = "bar"
}

variable "foo" {
    description = "foo"
    type = string
    default = "foo"
}

Your Terraform variable file will be automatically updated in place, ensuring that it remains well-organized.

Conclusion

With terraform-variable-sort, you can maintain consistency and readability in your Terraform projects effortlessly. Say goodbye to manually sorting variables, and start enjoying a more organized infrastructure codebase. Give it a try today and experience the benefits of a neatly sorted Terraform variable file.

Download terraform-variable-sort now and simplify your Terraform workflow!

First, I created a policy called terraform with the following permissions.

$ vault policy write terraform - <<EOF
path "*" {
  capabilities = ["list", "read"]
}

path "secrets/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "auth/token/create" {
capabilities = ["create", "read", "update", "list"]
}
EOF

Then I enabled the approle auth method.

$ vault auth enable approle

Next, I created an approle called terraform.

$ vault write auth/approle/role/terraform \
  secret_id_ttl=0 \
  token_num_uses=0 \
  token_ttl=0 \
  token_max_ttl=0 \
  secret_id_num_uses=0

Let’s assign the policy we created earlier to the approle.

$ vault write auth/approle/role/terraform/policy terraform

Now we can get the role id and secret id for the approle, this is what we will use in Terraform to authenticate with Vault.

$ vault read auth/approle/role/terraform/role-id
$ vault write -f auth/approle/role/terraform/secret-id

Copy the role id and secret id and add them to your Terraform configuration I pass them in as variables and store in my CI/CD pipeline.

provider "vault" {
  address          = var.vault_address
  skip_child_token = true # https://stackoverflow.com/questions/73034161/permission-denied-on-vault-terraform-provider-token-creation

  auth_login {
    path = "auth/approle/login"

    parameters = {
      role_id   = var.vault_role_id
      secret_id = var.vault_role_secret_id
    }
  }
}

That’s it you should now be able to authenticate with Vault using an approle instead of a token.

Requirements

To run this script, you will need the following:

• A Kubernetes cluster
• A Kubernetes API server URL
• A client key
• A client cert
• A CA cert
• jq (https://stedolan.github.io/jq/)

To get the client key, client cert, and CA cert, you can use the following commands (assuming you are using the default context and have a kubeconfig file):

kubectl config view --raw -o json | jq -r '.users[0].user."client-certificate-data"' | base64 -d > client.crt
kubectl config view --raw -o json | jq -r '.users[0].user."client-key-data"' | base64 -d > client.key
kubectl config view --raw -o json | jq -r '.clusters[0].cluster."certificate-authority-data"' | base64 -d > ca.crt

Usage

Copy the following script to a file and run it with the required arguments

#!/usr/bin/env bash
# list_rbac_resources.sh - list all the kubernetes rbac resources/sub-resources
# Requires jq (https://stedolan.github.io/jq/)
# Usage: ./list_rbac_resources.sh <kubernetes api server url> <client key> <client cert> <ca cert>

# Generate a UUID for the tmp output file
UUID=$(uuidgen)

# Get the list of APIs
APIS=$(curl --key $2 --cert $3 --cacert $4 -s $1/apis | jq -r '[.groups | .[].name] | join(" ")')

# Add header to tmp output file
echo "API Resource Verb Namespaced Kind" >> /tmp/list_rbac_resources_${UUID}

# Get the list of resources/sub-resources from the core API
curl --key $2 --cert $3 --cacert $4 -s $1/api/v1 | jq -r --arg api "$api" '.resources | .[] | "\($api) \(.name) \(.verbs | join(",")) \(.namespaced) \(.kind)"' >> /tmp/list_rbac_resources_${UUID}

# Get the list of resources/sub-resources from the other APIs
for api in $APIS; do
    version=$(curl --key $2 --cert $3 --cacert $4 -s $1/apis/$api | jq -r '.preferredVersion.version')
    curl --key $2 --cert $3 --cacert $4 -s $1/apis/$api/$version | jq -r --arg api "$api" '.resources | .[]? | "\($api) \(.name) \(.verbs | join(",")) \(.namespaced) \(.kind)"' >> /tmp/list_rbac_resources_${UUID}
done

# Print the list of resources/sub-resources using the column command
column -t /tmp/list_rbac_resources_${UUID}

# Remove the tmp output file
rm -rf /tmp/list_rbac_resources_${UUID}

Example

$ ./list_rbac_resources.sh https://172.31.123.141:6443 client.key client.crt ca.crt

Using the Ansible lookup plugin, you can retrieve the value of a 1Password item and use it in Ansible playbooks. The lookup plugin is a built-in plugin that allows you to retrieve the value of a variable from a file, database, or another external source. In this case, we will be retrieving the value of a 1Password item.

- name: "retrieve password for ITEM"
  debug:
    msg: "{{ lookup('onepassword', 'ITEM') }}"

For more information on the lookup plugin, see the ansible-lookup-plugin.

This allows you to retrieve your sudo password from 1Password without having to manually enter it into your terminal when running ansible-playbook main.yml -K or reading locally from a plan text file or encrypted vault.

Usage

Requirements

• A 1Password account - If you don’t have a 1Password account, you can sign up for a free account here.

• The 1Password CLI tool - If you don’t have the 1Password CLI tool, you can download it here.

Create your password item in 1Password and give it a name. In this example, I will be using the name ansible_become_pass. You can name it whatever you want, but you will need to use the same name in your Ansible playbook.

$ op item create --category=password --title="ansible-become-password" --vault="Personal" \
  password="my-super-secret-password"

Next, you will need to add the lookup plugin as the value for the ansible_become_pass variable in your Ansible playbook. I set mine in the inventory file, but you can also set it in the vars section of your playbook (or a vars file). The lookup plugin will retrieve the value of the 1Password item with the same name as the variable. In this case, it will retrieve the value of the 1Password item named ansible_become_pass.

[all:vars]
ansible_become_pass="{{ lookup('onepassword', 'ansible_become_pass', errors='warn') | d(omit) }}"

That’s it! when running your playbook, Ansible will automatically retrieve the value of the 1Password item and use it as the value for the ansible_become_pass variable. 1Password will prompt you to allow access to the Vault/Item when running the playbook.

$ ansible-playbook -i inventory main.yml