Need to install the following packages:

__dbm __tkinter

To fix the issue, I had to install the following packages:

sudo apt get update && sudo apt get install libgdbm-compat-dev tk-dev

To install python 3.13.2, the full set of commands become:

sudo apt get update

sudo apt install build-essential zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev libsqlite3-dev libbz2-dev libgdbm-compat-dev tk-dev wget

wget https://www.python.org/ftp/python/3.13.0/Python-3.13.2.tgz

tar -xvf Python-3.13.2.tgz

cd Python-3.13.2

./configure --enable-optimizations

make -j 4

sudo make altinstall

python3.13 --version

Creating a virtual env from the new python install:

python3.13 -m venv myvenv

source myvenv/bin/activate

The new SQL statements for tables creation becomes:

CREATE TABLE IF NOT EXISTS chats (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255),
    token_count INT DEFAULT 0,
    created_at TIMESTAMPTZ,
    updated_at TIMESTAMPTZ
);

CREATE TABLE IF NOT EXISTS chathistory (
    id SERIAL PRIMARY KEY,
    role VARCHAR(255),
    message TEXT,
    model_name VARCHAR(255),
    files TEXT[],
    created_at TIMESTAMPTZ,
    chat_id INT,
    FOREIGN KEY(chat_id) REFERENCES chats(id) ON DELETE CASCADE
);

The above ensures that whenever a chat entry is deleted, the associated child entries in the chathistory table are also removed due to the delete cascade statement.

However, this throws an error of operation not permitted when trying to run the vault client. This is due to vault trying to lock memory to prevent sensitive values being swapped to disk. This is a Reported Issue and also mentioned on Vault docker hub.

We can overcome this by running the container with --cap-add flag:

docker run --cap-add=IPC_LOCK -d --name=dev-vault mycustomimage vault

However, this is not required if using Raft integrated storage.

To resolve the issue, we can instead use a multistage build to copy the vault binary into the image rather than installing via package manager.

An example Dockerfile:

FROM hashicorp/vault:1.18 as vaultsource

FROM ubuntu:22.04 as base

COPY --from=vaultsource /bin/vault /usr/local/bin/vault

Using the above, we can create a custom image with a vault CLI that doesn’t throw an operation not permitted error.

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://cli.github.com/packages stable InRelease: The following signatures were invalid: EXPKEYSIG 23F3D4EA75716059 GitHub CLI <opensource+cli@github.com>
W: Failed to fetch https://cli.github.com/packages/dists/stable/InRelease  The following signatures were invalid: EXPKEYSIG 23F3D4EA75716059 GitHub CLI <opensource+cli@github.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.

This is due to the GPG key used to verify the .deb and .rpm repository expiring on the 6th September 2024. This is reported as a GH client install issue.

To resolve it, one can run the provided script which downloads and reinstalls the new GPG key, fixing the error above:

# Check for wget, if not installed, install it
(type -p wget >/dev/null || (sudo apt update && sudo apt-get install wget -y)) \
    && sudo mkdir -p -m 755 /etc/apt/keyrings

# Set keyring path based on existence of /usr/share/keyrings/githubcli-archive-keyring.gpg
# If it is in the old location, use that, otherwise always use the new location.
if [ -f /usr/share/keyrings/githubcli-archive-keyring.gpg ]; then
    keyring_path="/usr/share/keyrings/githubcli-archive-keyring.gpg"
else
    keyring_path="/etc/apt/keyrings/githubcli-archive-keyring.gpg"
fi

echo "replacing keyring at ${keyring_path}"

# Download and set up the keyring
wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo tee "$keyring_path" > /dev/null \
    && sudo chmod go+r "$keyring_path"

# Idempotently add the GitHub CLI repository as an apt source
echo "deb [arch=$(dpkg --print-architecture) signed-by=$keyring_path] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null

# Update the package lists, which should now pass
sudo apt update

By running the above, I was able to run apt update and apt upgrade again.

Hope it helps!

To fix this issue we need to:

• Install the Ubuntu version of RVM
• Install an older openssl version as a package in rvm
• Reference the above openssl package during the rvm install

Firstly, I had to install RVM Ubuntu. I followed the original instructions in the README. Ensure that any existing RVM installations are removed first.

After RVM is installed properly, to install ruby 3.0.0, these were the steps I took:

rvm pkg install openssl

rvm install ruby-3.0.0 --with-openssl-dir=/usr/share/rvm/usr

Only the above steps allowed me to get RVM to work.

Hope it helps someone!

AttributeError: module 'pkgutil' has no attribute 'ImpImporter'. Did you mean: 'zipimporter'?

This occured after installing setuptools which was a dependency of another package. As a result, I was unable to use pip itself to remove setuptools.

Rather than re-create a new venv, the only way to to resolve this issue is to reinstall pip by downloading the pip install file from https://bootstrap.pypa.io/get-pip.py and running it again:

curl https://bootstrap.pypa.io/get-pip.py -O get-pip.py

python get-pip.py

By doing so, I was able to get pip working again without rebuilding the entire venv.

This is highlighted in the python github repo: https://github.com/python/cpython/issues/95299

According to HTTP request headers and CloudFront behavior:

CloudFront sets the value to the domain name of the origin that is associated with the requested object.

For X-Forwarded-Proto:

CloudFront removes the header.

By default, Cloudfront will forward the IP of the distribution to the origin and not the real user’s IP. In addition it will also remove the X-Forwarded-Proto header.

To resolve the issue we need to add those two headers to the distribution via a custom policy.

But which policy group do we add it to? Cache policy ? Origin request policy?

To provide some context, recent changes to Cloudfront encourages the use of policies to edit the behaviour of the cache key, requests and response headers.

As per their Cloudfront Policy blog post, Cache policies are generally used for caching assets. Origin request policies should be used instead to modify the request headers since it is invoked during a cache miss or revalidation. In my use case, I don’t want the user’s IP to be cached but instead forwarded it to the origin so a origin request policy is more appropriate.

Since the cloudfront distribution was built using terraform, I was able to create a custom origin request policy and attach it to the distribution.

resource "aws_cloudfront_origin_request_policy" "example" {
  name    = "example-policy"
  comment = "example comment"
  cookies_config {
    cookie_behavior = "none"
  }

  headers_config {
    header_behavior = "whitelist"
    headers {
      items = ["Host", "Cloudfront-Forwarded-Proto"]
    }
  }

  query_strings_config {
    query_string_behavior = "none"
  }
}

# Attach the above policy to the distribution
resource "aws_cloudfront_distribution" "s3_distribution" {
  ....


  enabled             = true
  is_ipv6_enabled     = true
  comment             = "Some comment"

  ...

  # Attach the above policy to the distribution
  default_cache_behavior {
    ...


    origin_request_policy_id  = aws_cloudfront_origin_request_policy.example.id
    path_pattern     = "/*"
  }
  ...

}

We added the Host and Cloudfront-Forwarded-Proto headers to the custom policy.

In my use case it appends the client IP in the format of x_forwarded_for: <my ip> in the origin’s logs.

Using a resource of aws_wafv2_web_acl_logging_configuration we are able to declare a redacted_fields block to identity which part of the request to remove. Within the block we can only declare an argument of method, query_string, single_header and uri_path.

Only the single_header argument takes a name attribute which is what I need in my use case.

By entering each of the header name in individual block, I was able to filter it out from the cloudfront logs:

resource "aws_wafv2_web_acl_logging_configuration" "example" {
  log_destination_configs = [aws_kinesis_firehose_delivery_stream.example.arn]
  resource_arn            = aws_wafv2_web_acl.example.arn
  redacted_fields {
    single_header {
      name = "header-1"
    }

    single_header {
      name = "header-2"
    }
  }
}

To test that it works, I was able to trigger fake requests to be sent via Kinesis firehose which populated the logs. Then I accessed the logs via S3 and checked that the headers were marked with REDACTED if it has removed it.

More information can be found on the WAF Logging management

I used the aws-cli to get the list of azs from the given region in question:

aws ec2 describe-availability-zones --region eu-west-1

It returns a list as follows:

{
    "AvailabilityZones": [
        {
            "State": "available",
            "OptInStatus": "opt-in-not-required",
            "Messages": [],
            "RegionName": "eu-west-1",
            "ZoneName": "eu-west-1a",
            "ZoneId": "euw1-az2",
            "GroupName": "eu-west-1",
            "NetworkBorderGroup": "eu-west-1",
            "ZoneType": "availability-zone"
        },
        {
            "State": "available",
            "OptInStatus": "opt-in-not-required",
            "Messages": [],
            "RegionName": "eu-west-1",
            "ZoneName": "eu-west-1b",
            "ZoneId": "euw1-az3",
            "GroupName": "eu-west-1",
            "NetworkBorderGroup": "eu-west-1",
            "ZoneType": "availability-zone"
        },
        {
            "State": "available",
            "OptInStatus": "opt-in-not-required",
            "Messages": [],
            "RegionName": "eu-west-1",
            "ZoneName": "eu-west-1c",
            "ZoneId": "euw1-az1",
            "GroupName": "eu-west-1",
            "NetworkBorderGroup": "eu-west-1",
            "ZoneType": "availability-zone"
        }
    ]
}

That allows me to troubleshoot the missing az and switch to another region with the right number of azs.

Could not connect to archive.ubuntu.com:80 (185.125.190.36), connection timed out Could not connect to archive.ubuntu.com:80 (91.189.91.39), connection timed out Could not connect to archive.ubuntu.com:80 (185.125.190.39), connection timed out
...

It turns out that the docker daemon is unable to use the host networking to do a apt-get update within the ubuntu container during the build process and as such is unable to call out to the remote host.

To fix the issue system wide we can create a /etc/docker/daemons.json file with the right naemserver entries and restart the docker daemon:

Firstly, run the following to get the host DNS server ip

nmcli dev show | grep 'IP4.DNS'

Create a file at /etc/docker/daemons.json with the following entries:

{
	"dns": ["my-nameserver-ip-from-above", "8.8.8.8"]
}

Restart the docker daemon

sudo systemctl restart docker.service

sudo systemctl status docker.service

As a test we can run the following image to see if it can do a nslookup of google.com from within a container:

docker run busybox nslookup google.com

The response should include the DNS server address from above:

Server:		X.X.X.X
Address:	X.X.X.X:53

Non-authoritative answer:
Name:	google.com
Address: 172.217.16.238

Non-authoritative answer:
Name:	google.com
Address: 2a00:1450:4009:819::200e

Hope it helps someone!