Debug School: Suyash Sambhare

Windows 11 context menu

Suyash Sambhare — Fri, 08 May 2026 05:15:07 +0000

Ye Olde Right Click menu

Design engineer in Microsoft probably thinking, "Hmm, the context menu when you right-click on a file is quite cluttered, lets fix that by moving everything to an overflow option called Show more options"

Le New Right Click Menu

Much better!

Win Updates via PS1

Suyash Sambhare — Wed, 22 Apr 2026 03:07:02 +0000

PowerShell file

cd C:\
sfc /scannow
chkdsk C: /scan /perf
winget upgrade --all
install-Module PSWindowsUpdate -Force
import-Module PSWindowsUpdate
get-WindowsUpdate -Install -AcceptAll
tree
shutdown /r
exit

Requires reboot

AWS Secrets Manager in GitLab CI/CD

Suyash Sambhare — Wed, 15 Apr 2026 05:45:02 +0000

Using AWS Secrets Manager in GitLab CI/CD

GitLab lets you fetch secrets directly from AWS Secrets Manager at job runtime, instead of hard‑coding or manually syncing secrets into GitLab CI variables.

This gives you:

Centralized secret management (AWS)
Short‑lived credentials (OIDC)
No secrets stored permanently in GitLab

How the Integration Works (Architecture)

GitLab Runner authenticates to AWS
- Via IAM Role attached to the runner host
- Or via OpenID Connect (OIDC) using GitLab ID tokens
During the “Resolving secrets” phase:
- Runner calls AWS Secrets Manager
- Fetches the secret value
GitLab:
- Writes the secret to a temporary file
- Exposes the file path as an environment variable
Your job uses the secret
Temp files are removed when the job finishes

Secrets never appear in the job logs unless you echo them.

Authentication Methods

1. IAM Role

variables:
  AWS_REGION: us-east-1

No tokens or role assumptions needed.

With Kubernetes runners, the IAM role must be on the runner manager, not just the pod.

2. OpenID Connect

GitLab issues a short‑lived OIDC token
AWS STS exchanges it for temporary credentials
AWS_ROLE_ARN defines what role is assumed

id_tokens:
  AWS_ID_TOKEN:
    aud: sts.amazonaws.com

variables:
  AWS_ROLE_ARN: arn:aws:iam::123456789012:role/gitlab-secrets-role
  AWS_REGION: us-east-1

Defining Secrets in Jobs

Standard Form

secrets:
  DATABASE_PASSWORD:
    aws_secrets_manager:
      secret_id: app-secrets/database
      field: password
    file: false

password field is extracted from JSON
Value is exposed as $DATABASE_PASSWORD
file: false → variable, not file path

secrets:
  API_KEY:
    aws_secrets_manager: app-secrets/api#api_key
    file: false

Format:
secret-name[#json-field]

Working with Full JSON Secrets

If you don’t specify field, GitLab retrieves the entire value.

secrets:
  FULL_SECRET:
    aws_secrets_manager: app-secrets/api

Then:

cat "$FULL_SECRET" | jq -r '.api_key'

Secret Versioning

You can pin secrets to:

A version stage (recommended)
A specific version ID

version_stage: AWSCURRENT

version_id: 01234567-89ab-cdef-0123-456789abcdef

You cannot specify both.

Cross‑Account Access

To read secrets from another AWS account:

Use OIDC
Use the full secret ARN

secret_id: arn:aws:secretsmanager:us-east-1:987654321098:secret:shared-api-keys-AbCdEf

IAM role must trust:

GitLab’s OIDC provider
The specific GitLab project/group

Per‑Secret Overrides (Advanced)

You can override AWS settings per secret:

aws_secrets_manager:
  secret_id: eu-app-secrets/database
  region: eu-west-1
  role_arn: arn:aws:iam::123456789012:role/eu-role

File vs Variable (`file: true | false`)

Default behavior:

GitLab writes secret to a temp file
Environment variable contains file path

cat "$DATABASE_PASSWORD"

If you want the raw value:

file: false

Then:

echo "$DATABASE_PASSWORD"

File mode is safer for binaries & large secrets.

Use AWS Secrets Manager secrets in GitLab CI/CD

You can use secrets stored in AWS Secrets Manager
in your GitLab CI/CD pipelines.

Prerequisites:

Have access to AWS Secrets Manager in your AWS account.
Configure authentication using one of the following methods:
- IAM Role: Use the IAM role assigned to your GitLab Runner instance.
- OpenID Connect: Configure OpenID Connect in AWS to retrieve temporary credentials.
Add CI/CD variables to your project to provide details about your AWS configuration:
- AWS_REGION: The AWS region where your secrets are stored.
- AWS_ROLE_ARN: The ARN of the AWS IAM role to assume (required when using OpenID Connect).
- AWS_ROLE_SESSION_NAME: Optional. Custom session name for the assumed role.

Use AWS Secrets Manager secrets in a CI/CD job

With IAM Role authentication

You can use a secret stored in AWS Secrets Manager in a job by defining it with the
aws_secrets_manager keyword.

This method uses the IAM role assigned to your GitLab Runner instance. When using the
Kubernetes executor or autoscaling,
make sure the IAM role is applied to your runner manager.

Prerequisites:

GitLab Runner 18.3 or later.

For example:

variables:
  AWS_REGION: us-east-1

database-migration:
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: app-secrets/database
        field: 'password'
      file: false
  stage: deploy
  script:
    - echo "Running database migration..."
    - mysql -h $DB_HOST -u $DB_USER -p$DATABASE_PASSWORD < migration.sql
    - echo "Migration completed successfully."

With OpenID Connect authentication

For enhanced security, you can use OpenID Connect to authenticate with AWS and assume a specific IAM role.
By default, the runner looks for an ID token named AWS_ID_TOKEN. For example:

variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::123456789012:role/gitlab-secrets-role'

database-migration:
  id_tokens:
    AWS_ID_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: app-secrets/database
        field: 'password'
      file: false
  stage: deploy
  script:
    - echo "Connecting to production database..."
    - psql postgresql://$DB_USER:$DATABASE_PASSWORD@$DB_HOST:5432/$DB_NAME -c "SELECT version();"
    - echo "Database connection successful."

You can also specify a custom token using the token option. For example:

variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::123456789012:role/gitlab-secrets-role'

database-migration:
  id_tokens:
    CUSTOM_AWS_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: app-secrets/database
        field: 'password'
      token: $CUSTOM_AWS_TOKEN
      file: false
  stage: deploy
  script:
    - echo "Connecting to production database with custom token..."
    - psql postgresql://$DB_USER:$DATABASE_PASSWORD@$DB_HOST:5432/$DB_NAME -c "SELECT version();"
    - echo "Database connection successful."

Short form syntax

You can use a simplified syntax by specifying the secret ID as a string.
You can optionally specify a field by separating it with a # character.
For example:

variables:
  AWS_REGION: us-east-1

api-deployment:
  secrets:
    API_KEY:
      aws_secrets_manager: 'app-secrets/api#api_key'
      file: false
    FULL_SECRET:
      aws_secrets_manager: 'app-secrets/api'
      file: false
  stage: deploy
  script:
    - echo "Deploying API with specific field..."
    - curl --header "Authorization: Bearer $API_KEY" https://api.example.com/deploy
    - echo "Using full secret..."
    - curl --header "Authorization: Bearer $(cat $FULL_SECRET | jq --raw-output '.api_key')" https://api.example.com/status

Secret versioning

AWS Secrets Manager supports multiple versions of secrets. You can specify a particular version
using either version_id or version_stage. For example:

variables:
  AWS_REGION: us-east-1

production-deployment:
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: prod-app-secrets/database
        field: 'password'
        version_stage: 'AWSCURRENT'
      file: false
    STAGING_DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: prod-app-secrets/database
        field: 'password'
        version_id: '01234567-89ab-cdef-0123-456789abcdef'
      file: false
  stage: deploy
  script:
    - echo "Deploying to production with current secret version..."
    - deploy-prod.sh --db-password $DATABASE_PASSWORD
    - echo "Testing with specific secret version..."
    - test-with-version.sh --db-password $STAGING_DATABASE_PASSWORD

Cross-account secret access

To retrieve secrets from another AWS account, you must use the full ARN.
For example:

variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::123456789012:role/cross-account-secrets-role'

cross-account-deployment:
  id_tokens:
    AWS_ID_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    SHARED_API_KEY:
      aws_secrets_manager:
        secret_id: 'arn:aws:secretsmanager:us-east-1:987654321098:secret:shared-api-keys-AbCdEf'
        field: 'production_key'
      file: false
  stage: deploy
  script:
    - echo "Accessing shared secret from another account..."
    - curl --header "Authorization: Bearer $SHARED_API_KEY" https://shared-api.example.com/deploy

Per-secret configuration overrides

You can override global AWS settings on a per-secret basis. For example:

variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::123456789012:role/default-role'

multi-region-deployment:
  id_tokens:
    AWS_ID_TOKEN:
      aud: 'sts.amazonaws.com'
    EU_AWS_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    EU_DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: eu-app-secrets/database
        field: 'password'
        region: 'eu-west-1'
        role_arn: 'arn:aws:iam::123456789012:role/eu-deployment-role'
        role_session_name: 'gitlab-eu-deployment'
      token: $EU_AWS_TOKEN
      file: false
    US_DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: us-app-secrets/database
        field: 'password'
      file: false
  stage: deploy
  script:
    - echo "Deploying to EU region..."
    - deploy-to-eu.sh --db-password $EU_DATABASE_PASSWORD
    - echo "Deploying to US region..."
    - deploy-to-us.sh --db-password $US_DATABASE_PASSWORD

In these examples:

aud: The audience, which must match the audience used when creating the federated identity credentials.
secret_id: The name or ARN of the secret in AWS Secrets Manager. To retrieve a secret from another account, you must use an ARN.
field: Is the specific key in the JSON secret to retrieve. If not specified, the entire secret is retrieved. Field access is only supported for flat JSON secrets (top-level keys only) and supports string, number, and boolean values. For example:
- password: Accesses the password field.
- api_key: Accesses the api_key field.
- token: Specifies which ID token to use for authentication. If not specified, the runner looks for a token named AWS_ID_TOKEN.
version_id: Is the unique identifier of a specific version of the secret. If you don't specify either version_id or version_stage, AWS Secrets Manager returns the AWSCURRENT version.
version_stage: The staging label of the version of the secret to retrieve (such as AWSCURRENT or AWSPENDING). You cannot specify both version_id and version_stage for the same secret.
region: Overrides the global AWS_REGION for this specific secret.
role_arn: Overrides the global AWS_ROLE_ARN for this specific secret.
role_session_name: Overrides the global AWS_ROLE_SESSION_NAME for this specific secret.
GitLab fetches the secret from AWS Secrets Manager and stores the value in a temporary file. The path to this file is stored in a CI/CD variable, similar to file type CI/CD variables.

Troubleshooting

Refer to OIDC for AWS troubleshooting for general
problems when setting up OIDC with AWS.

Error: `no EC2 IMDS role found`

The following error might happen if both of these conditions are true:

The CI/CD job is configured to use IAM role authentication.
The job is executed by a runner with the Kubernetes executor hosted on AWS EKS.

Resolving secrets
Resolving secret "MY_AWS_SECRET"...
Using "aws_secrets_manager" secret resolver...
ERROR: Job failed (system failure): resolving secrets: operation error Secrets Manager: GetSecretValue, get identity: get credentials: failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, canceled, context deadline exceeded

The Resolving secrets step is handled by the runner manager. This step accesses IAM credentials
cached in EC2 IMDS.
If the IAM role has not been applied to the runner manager, the Resolving secrets step fails.

To address this error, apply the correct IAM role to the runner manager.

Applying the IAM role to the runner pods that are spawned and managed by the runner manager does not resolve this issue.

Ref: https://docs.gitlab.com/ci/secrets/aws_secrets_manager/

Fix invalid checkpoint record in Postgres

Suyash Sambhare — Tue, 31 Mar 2026 22:10:21 +0000

When PostgreSQL is unable to detect a valid checkpoint from which to begin the recovery procedure, it displays the error "PANIC: could not locate a valid checkpoint record." This may occur if the PostgreSQL container is not restarted safely.

Prevent data corruption

For stateful applications like databases, the first method is to use Stateful Sets rather than Deployments; this is a Kubernetes best practice. To preserve the stability and integrity of your database, Stateful Sets offer assurances regarding the ordering and uniqueness of pods. Additionally, stateful sets will manage restarts more effectively.

The second method is to safely shut down your PostgreSQL instance by using a preStop hook in Kubernetes.
Before a pod is terminated in Kubernetes, the preStop hook is invoked. Once the preStop hook is finished, the pod's termination process starts.

Apply the preStop hook in a Kubernetes configuration for PostgreSQL:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  replicas: 1
  serviceName: "postgres"
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:latest
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: postgres-data
          mountPath: /var/lib/postgresql/data
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "pg_ctl -D /var/lib/postgres/data -w -t 60 -m fast stop"]
  volumeClaimTemplates:
  - metadata:
      name: postgres-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

This preStop hook runs the pg_ctl stop command to shut down the PostgreSQL server.

-D /var/lib/postgres/data option specifies the directory where the data base files live,
-w waits until the server shuts down,
-t 60 specifies the wait timeout in seconds, and
-m fast means to do a "fast" shutdown, which rolls back all active transactions, disconnects clients immediately and shuts down.

For AWS ECS deployments you can set the Min and max running tasks respectively: 0% min and 100% max

Recover from an error state

This can be fixed by running pg_resetwal command by connecting to the container.
However, since the pod is in crashLoopBackOff state, we will not be able to connect to the container.
We must first make the pod to be in stable state to execute the command.

Please follow the steps below for manual execution of the command pg_resetwal in a container.
This process requires the pod to be in a stable state, and not in a crash loop.
You can achieve this by introducing a delay in the postgres-deployment.yaml file.

Scale down the deployment by reducing the replica count of the deployment to zero using the following command: kubectl scale deployment postgres - replicas=0
Introduce a delay: Modify the postgres-deployment.yaml file to include a sleep command that delays the initialization process by 600 seconds, keeping the pod in the initializing state.

Here is an example of how to add it:

spec:
      containers:
      - name: postgres
        image: postgres:latest
        command: [ "/bin/bash", "-c", " - " ] 
        args: [ "sleep 600;" ]

Scale up the deployment: Bring the deployment back up by increasing the replica count to one using the following command: kubectl scale deployment postgres - replicas=1
Execute pg_resetwal in the pod: Once the pod reaches the initializing state, run the pg_resetwal command by executing into the pod. Here is how you can do this:

kubectl exec -it postgres - /bin/bash
su postgres
pg_resetwal /var/lib/postgres/data

Proceed despite the warning: If you do receive the warning, continue the process by forcing the pg_resetwal command as follows: pg_resetwal /var/lib/posgtgres/data -f

After running this command, you should receive a confirmation message stating “Write-ahead log reset.”
After you have successfully executed the pg_resetwal command, you should be able to restart the PostgreSQL server.
Remember that the pg_resetwal command is a measure of last resort and carries the risk of data loss or inconsistency.
Always make sure to maintain regular backups of your PostgreSQL databases and consider setting up high availability and replication solutions for your production databases.

Ref: https://medium.com/@adnanitdev/fix-for-error-panic-could-not-locate-a-valid-checkpoint-record-in-postgres-or-citus-running-in-b03d8341a258

VMWare vExpert Program

Suyash Sambhare — Thu, 29 Jan 2026 04:35:52 +0000

Announcement: vExpert 2025 Recognition

I am pleased to share that I have been recognised as a vExpert.

Directory Listing: https://vexpert.vmware.com/directory/9629

vExpert Badge

The vExpert program highlights individuals who demonstrate a strong passion for VMware technologies and who dedicate their time to sharing knowledge through blogs, forums, community groups, and various online or in‑person events. I am honoured to be part of such a dynamic and collaborative community, where ideas continually evolve and opportunities to engage with experts from around the world are abundant.

Importance of the vExpert Program

The VMware by Broadcom vExpert Program is a global community recognition initiative that acknowledges individuals who have made meaningful contributions to the VMware ecosystem. The program welcomes anyone with a deep interest in VMware products and services and seeks to recognise those who actively share their expertise, insights, and experiences with the broader community.

I am particularly grateful for the wealth of technical blogs, articles, and resources produced by fellow vExperts. Their contributions not only support other vExperts but also provide invaluable guidance to VMware professionals worldwide. These resources span a wide range of topics, including best practices, troubleshooting, automation, networking, and advanced virtualisation concepts.

Ways to Qualify for vExpert

The vExpert award recognises contributions across multiple categories, including:

Enterprise/Internal Influencer – Leading internal knowledge‑sharing sessions such as workshops or webinars on VMware technologies.
Blogging – Publishing educational content on VMware products or events like VMware Explore.
Code Sharing – Providing tools, scripts, or code samples through websites, apps, VMware {code}, or internal platforms.
Event Speaking – Presenting at VMUG meetings, VMware Explore, or other industry conferences.
Podcasting – Hosting or co‑hosting podcasts focused on VMware topics.
Video Content – Creating tutorials, demonstrations, or technical walkthroughs on platforms such as YouTube.
Online Forums – Supporting the community by answering questions on VMTN or VMware‑related Reddit communities.
VMUG Leadership Support – Assisting local VMUG chapters in leadership or organisational roles.

Value of the vExpert Program

Becoming a vExpert provides numerous benefits that extend well beyond recognition:

Content Promotion – vExpert content is amplified through VMware’s official social channels, LinkedIn, Broadcom Advocacy, and the VMware Blog RSS feed, increasing visibility and engagement.
Personal Brand Development – The vExpert title enhances professional credibility and strengthens your reputation within the technology community.
Professional Recognition – Inclusion in the vExpert Directory and on LinkedIn validates your community contributions and helps distinguish you in your career.
Complimentary VMUG Advantage Membership – Includes access to valuable resources and discounts.
Free VMware Licenses – vExperts receive VCF Home Lab licenses through VMUG Advantage (subject to passing the VCP‑VCF exam), enabling hands‑on learning and skill development.
Exclusive Networking Opportunities – Access to private vExpert communication channels and industry experts.
Early Access & NDA Briefings – Participation in NDA sessions and early access to VMware roadmap materials.
VMware Explore Blogger Passes – Complimentary blogger access to VMware Explore events (limited availability).

Pathways to Becoming a vExpert

There are several recognised avenues for contributing to the VMware community:

Enterprise / Internal Influencers
Bloggers
Code Contributors
VMUG Leaders
Event Speakers
Podcasters
Online Forum Supporters
Authors
VCDX Certification Holders

Beyond being a symbol of achievement, the vExpert program empowers individuals to expand their professional network, strengthen their personal brand, and gain access to exclusive resources and events.

Closing Thoughts

Being part of the vExpert community is not solely about holding a title—it is about the collective impact we make on the VMware ecosystem. One of the most valuable aspects of this community is the wealth of knowledge shared by its members, which continues to inspire and support professionals across the globe.

If you found this article helpful, a share on LinkedIn or X would be greatly appreciated.

vExpert Suyash Sambhare

Directory Listing: https://vexpert.vmware.com/directory/9629

For more information, visit the official vExpert website: https://vexpert.vmware.com

DevOps Training

Suyash Sambhare — Tue, 13 Jan 2026 03:28:07 +0000

Application Development Concepts

• History of Application Development
• Evolution of Application Development Methodologies
• Introduction to Application Architectures
• Introduction to the Application Development Lifecycle
• Application Testing and Quality Assurance
• Application Monitoring, Maintenance, and Support

Application Security Fundamentals

• What is Secure Application Development
• Need for Application Security
• Common Application Security Risks and Threats
• OWASP Top 10 Application Security Techniques
• Secure Design Principles
• Threat Modeling
• Secure Coding
• Secure Code Review
• SAST and DAST Testing
• Secure Configurations
• Educating Developers
• Role of Risk Management in Secure Development
• Project Management Role in Secure Application Development

Introduction to DevOps

• Introduction to DevOps
• DevOps Principles
• DevOps Pipelines
• DevOps and Project Management

Introduction to DevSecOps

• Understanding DevSecOps
• DevOps vs. DevSecOps
• DevSecOps Principles
• DevSecOps Culture
• Shift-Left Security
• DevSecOps Pipelines
• Pillars of DevSecOps
• DevSecOps Benefits and Challenges

Introduction to DevSecOps Management Tools

• Project Management Tools
• Integrated Development Environment (IDE) Tools
• Source-code Management Tools
• Build Tools
• Continuous Testing Tools

Introduction to DevSecOps Code and CI/CD Tools

• Continuous Integration Tools
• Infrastructure as Code Tools
• Configuration Management Tools
• Continuous Monitoring Tools

Introduction to DevSecOps Pipelines

• Role of DevSecOps in the CI/CD Pipeline
• DevSecOps Tools
• Embracing the DevSecOps Lifecycle
• DevSecOps Ecosystem
• Key Elements of the DevSecOps Pipeline
• Integrating Security into the DevOps Pipeline

Introduction to DevSecOps CI/CD Testing and Assessments

• Implementing Security into the CI/CD Pipeline and Security Controls
• Continuous Security in DevSecOps with Security as Code
• Continuous Application Testing for CI/CD Pipeline Security
• Application Assessments and Penetration Testing

Implementing DevSecOps Testing and Threat Modeling

• Integrating Security Threat Modeling in Plan Stage
• Integrating Secure Coding in Code Stage
• Integrating SAST, DAST, and IAST in Build and Test Stage
• Integrating RASP and VAPT in Release and Deploy Stage

Implementing DevSecOps Monitoring Feedback

• Implementing Infrastructure as Code (IaC)
• Integrating Configuration Orchestration
• Integrating Security in Operate and Monitor Stage
• Integrating Compliance as Code (CaC)
• Integrating Logging, Monitoring, and Alerting
• Integrating Continuous Feedback Loop

EFS Utils

Suyash Sambhare — Wed, 07 Jan 2026 23:34:57 +0000

Utilities for Amazon Elastic File System

AWS EFS (Elastic File System) Utils is a mount helper for using Amazon EFS file systems used for various tasks related to managing and using Amazon EFS services. Here’s a breakdown of their primary functionalities:

Purpose of AWS EFS Utils

1. Mounting EFS File Systems

AWS EFS Utils provide easy-to-use commands for mounting EFS file systems to EC2 instances, allowing you to access files stored in EFS from your applications.

2. Performance Management

The tools include options to configure mount settings that can optimize performance based on your specific workload needs, such as choosing throughput modes.

3. Automatic DNS Resolution

EFS Utils help automatically resolve the correct DNS name for the EFS file system, simplifying the mounting process.

4. Health Monitoring

These utils include commands that can be used to check the health and status of your EFS file systems, ensuring they are functioning correctly.

5. Security Configuration

AWS EFS Utils help with configuring security options like AWS Identity and Access Management (IAM) policies and mounted instances' security groups, enhancing security during access.

6. Command-Line Interface

The utilities provide a command-line interface for performing various administrative tasks related to EFS, making it easier to integrate EFS with your scripts or applications.

7. Troubleshooting

They also include features for debugging and monitoring, allowing users to diagnose and troubleshoot issues that may arise during usage.

Summary

AWS EFS Utils streamline the process of using Amazon EFS by providing tools for mounting, managing, and optimizing EFS interactions, making it a vital component for applications that require scalable file storage. If you have specific scenarios in mind for using EFS, let me know!

The efs-utils package has been verified against the following Linux distributions:

Distribution	Package Type	`init` System
Amazon Linux 2	`rpm`	`systemd`
Amazon Linux 2023	`rpm`	`systemd`
RHEL 8	`rpm`	`systemd`
RHEL 9	`rpm`	`systemd`
Ubuntu 20.04	`deb`	`systemd`
Ubuntu 22.04	`deb`	`systemd`
Ubuntu 24.04	`deb`	`systemd`
OpenSUSE Leap	`rpm`	`systemd`
SLES 15	`rpm`	`systemd`

To install AWS EFS (Elastic File System) Utils on Ubuntu, follow these steps:

Note: Building from source requires Rust 1.70+, Cargo, Go 1.17.13+, CMake 3.0+, GCC/G++, and Perl.

Installing AWS EFS Utils on Ubuntu

Step 1: Update the Package Index

Open your terminal and update the package index:

sudo apt update

Step 2: Install Required Packages

Install the necessary packages for building the EFS Utils:

sudo apt install -y git make gcc

Step 3: Clone the EFS Utils Repository

Clone the AWS EFS Utils GitHub repository:

git clone https://github.com/aws/efs-utils

Step 4: Change Directory

Navigate into the cloned directory:

cd efs-utils

Step 5: Install EFS Utils

Run the make command to compile and install:

sudo make install

Step 6: Verify Installation

To ensure that the EFS Utils are installed correctly, you can check the version:

sudo efs-utils --version

If you see the version number, the installation was successful.

Detailed Installation Information

Building efs-utils from Source

This guide provides detailed instructions for building efs-utils from source on various Linux distributions.

Build Prerequisites

Building efs-utils v2.0+ requires the following dependencies:

rust 1.70+
cargo
go 1.17.13+
perl
cmake 3.0+
gcc and g++ (or gcc-c++)
make
git

Recommended Resource Size: minimum 2 vCPUs, 4GB RAM to ensure sufficient resources for compilation. In AWS EC2, use t3.medium or larger.

Installing Rust and Cargo

If your distribution doesn't provide a rust or cargo package, or it provides versions
that are older than 1.70, then you can install rust and cargo through rustup:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
. "$HOME/.cargo/env"

Installing Go

Ensure you have Go 1.17.13 or later is installed and configured on your system.
Some distributions provide Go packages through package manager, but they may have outdated versions.

# DEB-based
sudo apt-get update  
sudo apt-get -y install golang

# Verify Go 1.17.13 or later is installed
go version

GCC Version Requirements

# Install GCC 13 (if not already installed)
# For Debian 13
sudo apt-get install -y gcc-13 g++-13

# Set GCC 13 as the compiler for the build
export CC=gcc-13
export CXX=g++-13
# Then proceed with the normal build steps

Ubuntu 20.04, upgrade to use gcc-10 and g++-10

# Install GCC 10
sudo apt-get -y install gcc-10 g++-10

# Set GCC 10 as the compiler for the build
export CC=gcc-10
export CXX=g++-10

Note: Alternatively, you can set the system default compiler using update-alternatives (requires sudo and affects all applications)

CMake version requirement

Building AWS-LC requires CMake 3.0 or later. CMake is typically available through the standard packager manager.

DEB-based Distributions

Debian/Ubuntu

sudo apt-get update
sudo apt-get -y install git binutils rustc cargo libssl-dev pkg-config gettext make gcc g++ cmake wget perl # remove gcc g++ here if you already installed a compatible version following GCC Version Requirements instruction
git clone https://github.com/aws/efs-utils
cd efs-utils
./build-deb.sh
sudo apt-get -y install ./build/amazon-efs-utils*deb

Running Tests

After building from source, you can run the test suite:

Set up a virtualenv:

virtualenv ~/.envs/efs-utils
source ~/.envs/efs-utils/bin/activate
pip install -r requirements.txt

Run tests:

make test

Verifying Installation

After installation, verify efs-utils is working:

mount.efs --version
/usr/sbin/mount.efs Version: 2.2.0

mount.efs --help
Usage: mount.efs [--version] [-h|--help] <fsname> <mountpoint> [-o <options>]

Additional Notes

Make sure you have nfs-common installed, as it is required for mounting EFS file systems. You can install it with:

sudo apt install nfs-common

Usage

mount.efs

efs-utils includes a mount helper utility, mount.efs, that simplifies and improves the performance of EFS file system mounts.

mount.efs launches a proxy process that forwards NFS traffic from the kernel's NFS client to EFS.
This proxy is responsible for TLS encryption, and for providing improved throughput performance.

To mount with the recommended default options, simply run:

sudo mount -t efs file-system-id efs-mount-point/

To mount file system to a specific mount target of the file system, run:

sudo mount -t efs -o mounttargetip=mount-target-ip-address file-system-id efs-mount-point/

To mount file system within a given network namespace, run:

sudo mount -t efs -o netns=netns-path file-system-id efs-mount-point/

To mount file system to the mount target in a specific availability zone (e.g. us-east-1a), run:

sudo mount -t efs -o az=az-name file-system-id efs-mount-point/

To mount file system to the mount target in a specific region (e.g. us-east-1), run:

sudo mount -t efs -o region=region-name file-system-id efs-mount-point/

To mount the filesystem mount target in the same physical availability zone ID (e.g. use1-az1) as the client instance over cross-AWS-account mounts, run:

sudo mount -t efs -o crossaccount file-system-id efs-mount-point/

To mount over TLS, simply add the tls option:

sudo mount -t efs -o tls file-system-id efs-mount-point/

To authenticate with EFS using the system’s IAM identity, add the iam option. This option requires the tls option.

sudo mount -t efs -o tls,iam file-system-id efs-mount-point/

To mount using an access point, use the accesspoint= option. This option requires the tls option.
The access point must be in the "available" state before it can be used to mount EFS.

sudo mount -t efs -o tls,accesspoint=access-point-id file-system-id efs-mount-point/

To mount your file system automatically with any of the options above, you can add entries to /efs/fstab like:

file-system-id efs-mount-point efs _netdev,tls,iam,accesspoint=access-point-id 0 0

For more information on mounting with the mount helper, see the manual page:

man mount.efs

mount.efs launches a proxy process that forwards NFS traffic from the kernel's NFS client to EFS. This proxy
is responsible for TLS encryption, and for providing improved throughput performance.

fs-id-or-dns-name has to be of one of the following two forms:

An EFS filesystem ID in the form of "fs-abcd1234", generated when the file system is created.
A domain name that has a resolvable DNS-CNAME record, which in turn points to a fully-qualified EFS DNS name in the form of "fs-abcd1234.efs.us-east-1.amazonaws.com" or "us-east-1a.fs-abcd1234.efs.us-east-1.amazonaws.com".
mount-point is the local directory on which the file system will be mounted.
mount.efs automatically applies the following NFS options:
nfsvers=4.1
rsize=1048576
wsize=1048576
hard
timeo=600
retrans=2
noresvport
tls (for Mac distributions)

By default, when using the Amazon EFS mount helper with Transport Layer Security (TLS), the mount helper enforces the certificate hostname checking and disables the use of Online Certificate Status Protocol (OCSP). These options can be configured in the config file located at /etc/amazon/efs/efs-utils.conf.

Additionally, the Amazon EFS mount helper has built-in logging for troubleshooting purposes. These logs are located at /var/log/amazon/efs.

It is possible to configure your Amazon EC2 instance to automatically remount your Amazon EFS file system when it reboots.

Options

-o, Options are specified with a -o flag followed by a comma separated string of options. All of the options specified in nfs are available, in addition to the following EFS-specific options:

tls: Mounts the EFS file system over TLS. For EC2 instances using Mac distributions, this option is by default passed and the EFS file system is mounted over TLS.
notls: Mounts the EFS file system without TLS, applies for Mac distributions only.
region: Mounts the EFS file system from the specified region, overriding any config file value.
tlsport=n: Configures the proxy process to listen for connections from the NFS client on the specified port. This is applicable to both non-tls and tls mounts. By default, the tlsport is chosen randomly from port range defined in the config file located at /etc/amazon/efs/efs-utils.conf.
verify=n: Verify TLS certificates using the specified stunnel verify level.
ocsp / noocsp: Selects whether to perform OCSP validation on TLS certificates, overriding /etc/amazon/efs/efs-utils.conf. By default OCSP is disabled. The ocsp mount option is incompatible with the efs-proxy process, and will revert efs-utils to the legacy stunnel mode, which does not support improved per-client throughput performance.
iam: Use the system's IAM identity to authenticate with EFS. The mount helper will try to retrieve the required IAM credentials from the following locations: the aws credentials URI passed by mount option, the AWS CLI credentials file (~/.aws/credentials), and the AWS CLI config file (~/.aws/config), the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable, the AssumeRoleWithWebIdentity, the EC2 instance profile. The first location that has credentials will be used. This option requires the tls option.
rolearn: Role ARN for IAM authentication with AssumeRoleWithWebIdentity API.
jwtpath: Identity token for IAM authentication with AssumeRoleWithWebIdentity API.
accesspoint: Mount the EFS file system using the specified access point. This option requires the tls option. The access point must be in the "available" state before it can be used to mount EFS.
awsprofile: Use the named profile used to lookup IAM credentials in the AWS CLI credentials file (~/.aws/credentials) or AWS CLI config file (~/.aws/config). If botocore is installed, assume the named profile and use the credentials of the assumed profile. If "awsprofile" is not specified, the "default" profile is used.
awscredsuri: Use the relative uri to lookup IAM credentials from ecs task metadata endpoint.
cafile: Use the cafile as the stunnel certificate authority file.
netns: Mount the EFS file system to the specified network namespace.
az: Mount the EFS file system to the specified availability zone mount target.
mountport: Use the port 2049 to bypass portmapper daemon on EC2 Mac instances running macOS Big Sur.
mounttargetip: Mount the EFS file system to the specified mount target ip address.
stunnel: Forward NFS traffic from the local NFS client to EFS using stunnel instead of efs-proxy. This will enable compatibility with the ocsp mount option, but will not deliver the increased throughput performance provided by efs-proxy. This option is enabled by default for Mac clients.

Ref: https://github.com/aws/efs-utils

Happy New Year!

Suyash Sambhare — Thu, 01 Jan 2026 08:20:33 +0000

Happy New Year!

Happy New Year!
🫥🧑🏼‍💻🪺🫕🌁🪉

Configure SQL Container

Suyash Sambhare — Wed, 17 Dec 2025 04:52:53 +0000

✅ How to Configure and Customize SQL Server Linux Containers

SQL Server on Linux containers offers powerful flexibility for development, testing, and even some production setups. You can customize your container using:

Environment variables
Custom Dockerfiles
Persistent storage
Startup scripts
Docker Compose or env‑files

This guide walks you through each of these approaches.

1. Create and Customize SQL Server Linux Containers

1.1 Build a Customized Container

You can create your own Dockerfile and add scripts, packages, or configuration steps.

Example from Microsoft documentation: the SQL Server process must remain the primary (right‑most) foreground process; otherwise, the container shuts down when other steps finish.

/usr/src/app/do-my-sql-commands.sh & 
/opt/mssql/bin/sqlservr

If sqlservr is not last, the container exits immediately after your custom script finishes.

2. Configure Using Environment Variables

SQL Server on Linux exposes a comprehensive set of environment variables covering setup, memory, language, storage paths, HADR, SQL Agent, ports, and more.

Here are some of the most important:

Variable	Purpose
`ACCEPT_EULA`	Required to accept license terms
`MSSQL_SA_PASSWORD`	Sets `sa` password (replaces deprecated `SA_PASSWORD`)
`MSSQL_PID`	Sets edition or product key
`MSSQL_COLLATION`	Default collation
`MSSQL_LCID`	Language locale
`MSSQL_MEMORY_LIMIT_MB`	Max memory
`MSSQL_TCP_PORT`	Listen port (default 1433)
`MSSQL_DATA_DIR` / `MSSQL_LOG_DIR`	Custom data & log paths
`MSSQL_BACKUP_DIR`	Backup directory
`MSSQL_AGENT_ENABLED`	Enable SQL Agent (true/false)
`MSSQL_ENABLE_HADR`	Enable Availability Groups

Example Container Run

docker run -e "ACCEPT_EULA=Y" \
  -e "MSSQL_SA_PASSWORD=MyP@ssw0rd!" \
  -e "MSSQL_AGENT_ENABLED=true" \
  -e "MSSQL_TCP_PORT=1533" \
  -p 1533:1533 \
  --name sqlserver \
  -d mcr.microsoft.com/mssql/server:2022-latest

3. Persisting Data (Critical!)

Container files are ephemeral. To retain your databases, use volumes.

SQL Server recommends mounting /var/opt/mssql, the location for data, logs, dumps, and configs.

Example:

docker run -e "ACCEPT_EULA=Y" \
  -e "MSSQL_SA_PASSWORD=MyP@ssw0rd!" \
  -v ~/sqlvolumes:/var/opt/mssql \
  -p 1433:1433 \
  --name sql1 \
  -d mcr.microsoft.com/mssql/server:2022-latest

4. Using Docker Compose for Multi‑Container or Complex Configs

Docker Compose simplifies multi‑step setups (e.g., AOAG clusters). It passes environment variables, mounts volumes, and orchestrates replicated SQL Server containers.

Example docker-compose.yml:

services:
  sql1:
    image: mcr.microsoft.com/mssql/server:2022-latest
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: "MyP@ssw0rd!"
      MSSQL_AGENT_ENABLED: "true"
    ports:
      - "1433:1433"
    volumes:
      - sql1data:/var/opt/mssql

volumes:
  sql1data:

5. Using .env Files for Cleaner Configuration

Instead of piling up variables in Docker commands, store them in a file (example from Axial SQL).

config.env:

    MSSQL_PID=Developer
    ACCEPT_EULA=Y
    MSSQL_AGENT_ENABLED=True
    MSSQL_DATA_DIR=/var/opt/sqlserver/sqldata
    MSSQL_LOG_DIR=/var/opt/sqlserver/sqllog
    MSSQL_BACKUP_DIR=/var/opt/sqlserver/sqlbackups

Run with:

docker run --env-file config.env \
  -e MSSQL_SA_PASSWORD=MyP@ssw0rd! \
  -p 1433:1433 \
  --name sqlcontainer1 \
  -d mcr.microsoft.com/mssql/server:2019-latest

6. Copy Files In and Out of Containers

SQL Server containers support file copying (e.g., backups, scripts).

docker cp myscript.sql sql1:/tmp/myscript.sql
docker exec -it sql1 /opt/mssql-tools18/bin/sqlcmd \
    -S localhost -U sa -P MyP@ssw0rd! -i /tmp/myscript.sql

7. Advanced Customization with Dockerfile

You can:

Install extra tools
Add startup scripts
Change OS‑level settings
Customize collation or locale via environment variables at build time

Example from SQL Server 2025 container customization: you can specify collation during container creation only.

-e "MSSQL_COLLATION=Latin1_General_BIN2"

8. Starting SQL Server 2025 Preview Containers

Microsoft’s official SQL Server 2025 preview image command:

docker run -e "ACCEPT_EULA=Y" \
  -e "MSSQL_SA_PASSWORD=<password>" \
  -e "MSSQL_PID=Evaluation" \
  -p 1433:1433 \
  --name sqlpreview \
  --hostname sqlpreview \
  -d mcr.microsoft.com/mssql/server:2025-latest

9. Additional Notes & Best Practices

Non‑root containers

SQL Server 2019+ containers run as non‑root for security.

Encryption‑first ODBC tooling

ODBC 18 enforces encryption by default when using sqlcmd inside containers.

Availability Groups in containers

You can build clusterless Always On AG setups using Docker Desktop + scripts.

✅ Summary

To configure and customize SQL Server Linux containers:

Use environment variables for edition, passwords, ports, collation, memory, and SQL Agent.
Use Dockerfiles to automate customizations.
Use volumes to persist SQL data.
Use copy commands or mount points for scripts and backups.
Use Docker Compose or env files for multi‑container setups or cleaner configs.
Consider SQL Server 2025 preview features and new image behaviors.

Ref: https://learn.microsoft.com/en-nz/sql/sql-server/?view=sql-server-ver16

Colored Bash Prompt

Suyash Sambhare — Fri, 12 Dec 2025 01:12:59 +0000

-------- Modern Colored Bash Prompt --------

Colors (ANSI escape sequences, with Bash [ ] wrapping for correct line editing)

Regular

BLACK="[\e[30m]"; RED="[\e[31m]"; GREEN="[\e[32m]"; YELLOW="[\e[33m]"
BLUE="[\e[34m]"; MAGENTA="[\e[35m]"; CYAN="[\e[36m]"; WHITE="[\e[37m]"

Styles

BOLD="[\e[1m]"; DIM="[\e[2m]"; RESET="[\e[0m]"

Show last exit code if non-zero

__last_exit_segment() {
local ec=$?
if [[ $ec -ne 0 ]]; then
echo -e "${RED}✖${ec}${RESET} "
fi
}

Git branch + dirty/clean + ahead/behind markers

__git_segment() {
command -v git >/dev/null 2>&1 || return
local branch dirty ahead behind
branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null) || return
# Detect changes
if ! git diff --quiet 2>/dev/null || ! git diff --cached --quiet 2>/dev/null; then
dirty="*"
else
dirty=""
fi
# Ahead/behind against upstream
if git rev-parse --abbrev-ref @{u} >/dev/null 2>&1; then
local counts
counts=$(git rev-list --left-right --count HEAD...@{u} 2>/dev/null)
ahead=$(echo "$counts" | awk '{print $1}')
behind=$(echo "$counts" | awk '{print $2}')
fi
local ab=""
[[ -n "$ahead" && "$ahead" -gt 0 ]] && ab+="↑$ahead"
[[ -n "$behind" && "$behind" -gt 0 ]] && ab+="↓$behind"

if [[ -n "$ab" ]]; then
echo -e "${MAGENTA} ${branch}${dirty} ${YELLOW}${ab}${RESET}"
else
echo -e "${MAGENTA} ${branch}${dirty}${RESET}"
fi
}

Jobs segment (background jobs)

__jobs_segment() {
local jcount
jcount=$(jobs -p | wc -l | tr -d ' ')
if [[ "$jcount" -gt 0 ]]; then
echo -e "${CYAN}⚙ ${jcount}${RESET} "
fi
}

Build PS1

build_ps1() {
local exit_seg git_seg jobs_seg
exit_seg=$(last_exit_segment)
git_seg=$(git_segment)
jobs_seg=$(jobs_segment)
PS1="${exit_seg}${DIM}\u@\h${RESET} ${BOLD}${BLUE}\w${RESET}"
if [[ -n "$git_seg" ]]; then
PS1+=" ${git_seg}"
fi
if [[ -n "$jobs_seg" ]]; then
PS1+=" ${jobs_seg}"
fi
PS1+="\n${GREEN}➜${RESET} "
}

Ensure the prompt rebuilds each time

PROMPT_COMMAND="__build_ps1"


# -------- Modern Colored Bash Prompt --------
# Colors (ANSI escape sequences, with Bash \[ \] wrapping for correct line editing)
# Regular
BLACK="\[\e[30m\]"; RED="\[\e[31m\]"; GREEN="\[\e[32m\]"; YELLOW="\[\e[33m\]"
BLUE="\[\e[34m\]"; MAGENTA="\[\e[35m\]"; CYAN="\[\e[36m\]"; WHITE="\[\e[37m\]"
# Styles
BOLD="\[\e[1m\]"; DIM="\[\e[2m\]"; RESET="\[\e[0m\]"

# Show last exit code if non-zero
__last_exit_segment() {
  local ec=$?
  if [[ $ec -ne 0 ]]; then
    echo -e "${RED}✖${ec}${RESET} "
  fi
}

# Git branch + dirty/clean + ahead/behind markers
__git_segment() {
  command -v git >/dev/null 2>&1 || return
  local branch dirty ahead behind
  branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null) || return
  # Detect changes
  if ! git diff --quiet 2>/dev/null || ! git diff --cached --quiet 2>/dev/null; then
    dirty="*"
  else
    dirty=""
  fi
  # Ahead/behind against upstream
  if git rev-parse --abbrev-ref @{u} >/dev/null 2>&1; then
    local counts
    counts=$(git rev-list --left-right --count HEAD...@{u} 2>/dev/null)
    ahead=$(echo "$counts" | awk '{print $1}')
    behind=$(echo "$counts" | awk '{print $2}')
  fi
  local ab=""
  [[ -n "$ahead" && "$ahead" -gt 0 ]] && ab+="↑$ahead"
  [[ -n "$behind" && "$behind" -gt 0 ]] && ab+="↓$behind"

  if [[ -n "$ab" ]]; then
    echo -e "${MAGENTA} ${branch}${dirty} ${YELLOW}${ab}${RESET}"
  else
    echo -e "${MAGENTA} ${branch}${dirty}${RESET}"
  fi
}

# Jobs segment (background jobs)
__jobs_segment() {
  local jcount
  jcount=$(jobs -p | wc -l | tr -d ' ')
  if [[ "$jcount" -gt 0 ]]; then
    echo -e "${CYAN}⚙ ${jcount}${RESET} "
  fi
}

# Build PS1
__build_ps1() {
  local exit_seg git_seg jobs_seg
  exit_seg=$(__last_exit_segment)
  git_seg=$(__git_segment)
  jobs_seg=$(__jobs_segment)
  PS1="${exit_seg}${DIM}\u@\h${RESET} ${BOLD}${BLUE}\w${RESET}"
  if [[ -n "$git_seg" ]]; then
    PS1+=" ${git_seg}"
  fi
  if [[ -n "$jobs_seg" ]]; then
    PS1+=" ${jobs_seg}"
  fi
  PS1+="\n${GREEN}➜${RESET} "
}

# Ensure the prompt rebuilds each time
PROMPT_COMMAND="__build_ps1"
#

~/.bashrc: executed by bash(1) for non-login shells.

see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)

for examples

If not running interactively, don't do anything

case $- in
i) ;;
*) return;;
esac

don't put duplicate lines or lines starting with space in the history.

See bash(1) for more options

HISTCONTROL=ignoreboth

append to the history file, don't overwrite it

shopt -s histappend

for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

HISTSIZE=1000
HISTFILESIZE=2000

check the window size after each command and, if necessary,

update the values of LINES and COLUMNS.

shopt -s checkwinsize

If set, the pattern "**" used in a pathname expansion context will

match all files and zero or more directories and subdirectories.

shopt -s globstar

make less more friendly for non-text input files, see lesspipe(1)

[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

set variable identifying the chroot you work in (used in the prompt below)

if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

set a fancy prompt (non-color, unless we know we "want" color)

case "$TERM" in
xterm-color|*-256color) color_prompt=yes;;
esac

uncomment for a colored prompt, if the terminal has the capability; turned

off by default to not distract the user: the focus in a terminal window

should be on the output of commands, not on the prompt

force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}[\033[01;32m]\u@\h[\033[00m]:[\033[01;34m]\w[\033[00m]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

If this is an xterm set the title to user@host:dir

case "$TERM" in
xterm*|rxvt*)
PS1="[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a]$PS1"
;;
*)
;;
esac

enable color support of ls and also add handy aliases

if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'

colored GCC warnings and errors

export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'

some more ls aliases

alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

Add an "alert" alias for long running commands. Use like so:

sleep 10; alert

alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]+\s*//;s/[;&|]\s*alert$//'\'')"'

Alias definitions.

You may want to put all your additions into a separate file like

~/.bash_aliases, instead of adding them here directly.

See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi

enable programmable completion features (you don't need to enable

this, if it's already enabled in /etc/bash.bashrc and /etc/profile

sources /etc/bash.bashrc).

if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
[ -r /home/ubuntu/.config/byobu/prompt ] && . /home/ubuntu/.config/byobu/prompt #byobu-prompt#

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
        # We have color support; assume it's compliant with Ecma-48
        # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
        # a case would tend to support setf rather than setaf.)
        color_prompt=yes
    else
        color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands.  Use like so:
#   sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi
[ -r /home/ubuntu/.config/byobu/prompt ] && . /home/ubuntu/.config/byobu/prompt   #byobu-prompt#

VMware to RedHat Virtualization Migration

Suyash Sambhare — Thu, 11 Dec 2025 00:47:14 +0000

Migration Toolkit for Virtualization

Cold and warm migration in MTV

Cold migration is when a powered off virtual machine (VM) is migrated to a separate host. The VM is powered off, and there is no need for common shared storage.
Warm migration is when a powered on VM is migrated to a separate host. A source host state is cloned to the destination host.

Stages:

Warm migration precopy stage
Warm migration cutover stage
Power off of virtual machines during cold migrations
Power on of virtual machines during warm migrations
Precopy stage
Cutover stage

Install MTV

In the Red Hat OpenShift web console, click Operators → OperatorHub.
Use the Filter by keyword field to search for mtv-operator.
Click Migration Toolkit for Virtualization Operator and then click Install.
Click Create ForkliftController when the button becomes active.
Click Create. Your ForkliftController appears in the list that is displayed.
Click Workloads → Pods to verify that the MTV pods are running.
Click Operators → Installed Operators to verify that Migration Toolkit for Virtualization Operator appears in the openshift-mtv project with the status Succeeded.

When the plugin is ready you will be prompted to reload the page. The Migration menu item is automatically added to the navigation bar, displayed on the left of the Red Hat OpenShift web console.

Using CLI:

cat << EOF | oc apply -f -
apiVersion: project.openshift.io/v1
kind: Project
metadata:
  name: openshift-mtv
EOF

cat << EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: migration
  namespace: openshift-mtv
spec:
  targetNamespaces:
    - openshift-mtv
EOF

cat << EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: mtv-operator
  namespace: openshift-mtv
spec:
  channel: release-v2.9
  installPlanApproval: Automatic
  name: mtv-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: "mtv-operator.v2.9.6"
EOF

cat << EOF | oc apply -f -
apiVersion: forklift.konveyor.io/v1beta1
kind: ForkliftController
metadata:
  name: forklift-controller
  namespace: openshift-mtv
spec:
  olm_managed: true
EOF

oc get pods -n openshift-mtv

NAME                                                    READY   STATUS    RESTARTS   AGE
forklift-api-bb45b8db4-cpzlg                            1/1     Running   0          6m34s
forklift-controller-7649db6845-zd25p                    2/2     Running   0          6m38s
forklift-must-gather-api-78fb4bcdf6-h2r4m               1/1     Running   0          6m28s
forklift-operator-59c87cfbdc-pmkfc                      1/1     Running   0          28m
forklift-ui-plugin-5c5564f6d6-zpd85                     1/1     Running   0          6m24s
forklift-validation-7d84c74c6f-fj9xg                    1/1     Running   0          6m30s
forklift-volume-populator-controller-85d5cb64b6-mrlmc   1/1     Running   0          6m36s

Configure MTV

You can configure the following settings of the MTV Operator by modifying the ForkliftController custom resource (CR), or in the Settings section of the Overview page, unless otherwise indicated.

Maximum number of virtual machines (VMs) or disks per plan that Migration Toolkit for Virtualization (MTV) can migrate simultaneously.
How long must gather reports are retained before being automatically deleted (ForkliftController CR only).
CPU limit allocated to the main controller container.
Memory limit allocated to the main controller container.
Interval at which a new snapshot is requested before initiating a warm migration.
Frequency with which the system checks the status of snapshot creation or removal during a warm migration.
Percentage of space in persistent volumes allocated as file system overhead when the storageclass is filesystem (ForkliftController CR only).
Fixed amount of additional space allocated in persistent block volumes. This setting is applicable for any storageclass that is block-based (ForkliftController CR only).
Configuration map of operating systems to preferences for vSphere source providers (ForkliftController CR only).
Configuration map of operating systems to preferences for Red Hat Virtualization (RHV) source providers (ForkliftController CR only).
Whether to retain importer pods so that the Containerized Data Importer (CDI) does not delete them during migration (ForkliftController CR only).

Migration

To Migrate from VMware to RedHat OpenShift Virtualization

Access the Create provider page for VMware by doing one of the following:

a. In the Red Hat OpenShift web console, click Migration for Virtualization > Providers.

i. Click Create Provider.
ii. Select a Project from the list. The default project shown depends on the active project of MTV. If the active project is All projects, then the default project is openshift-mtv. Otherwise, the default project is the same as the active project. If you have Administrator privileges, you can see all projects, otherwise, you can see only the projects you are authorized to work with.
iii. Click VMware.

b. If you have Administrator privileges, in the Red Hat OpenShift web console, click Migration for Virtualization > Overview.

i. In the Welcome pane, click VMware. If the Welcome pane is not visible, click Show the welcome card in the upper-right corner of the page, and click VMware when the Welcome pane opens.
ii. Select a Project from the list. The default project shown depends on the active project of MTV. If the active project is All projects, then the default project is openshift-mtv. Otherwise, the default project is the same as the active project. If you have Administrator privileges, you can see all projects, otherwise, you can see only the projects you are authorized to work with.

Specify the following fields:

a. Provider details

Provider resource name: Name of the source provider.
Endpoint type: Select the vSphere provider endpoint type. Options: vCenter or ESXi. You can migrate virtual machines from vCenter, an ESX/ESXi server that is not managed by vCenter, or from an ESX/ESXi server that is managed by vCenter but does not go through vCenter.
URL: URL of the SDK endpoint of the vCenter on which the source VM is mounted. Ensure that the URL includes the sdk path, usually /sdk. For example, https://vCenter-host-example.com/sdk. If a certificate for FQDN is specified, the value of this field needs to match the FQDN in the certificate.
VDDK init image: VDDKInitImage path. It is strongly recommended to create a VDDK init image to accelerate migrations. For more information, see Creating a VDDK image.
Select the Skip VMWare Virtual Disk Development Kit (VDDK) SDK acceleration (not recommended).
Enter the path in the VDDK init image text box. Format: /vddk:.
Upload a VDDK archive and build a VDDK init image from the archive by doing the following:
Click Browse next to the VDDK init image archive text box, select the desired file, and click Select.
Click Upload. The URL of the uploaded archive is displayed in the VDDK init image archive text box.

b. Provider credentials

Username: vCenter user or ESXi user. For example, user@vsphere.local.
Password: vCenter user password or ESXi user password.

Choose one of the following options for validating CA certificates:
Use a custom CA certificate: Migrate after validating a custom CA certificate.
Use the system CA certificate: Migrate after validating the system CA certificate.
Skip certificate validation : Migrate without validating a CA certificate.
To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
To skip certificate validation, toggle the Skip certificate validation switch to the right.
Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.
Click Fetch certificate from URL. The Verify certificate window opens.
If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.
Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.
Click Create provider to add and save the provider.
The provider appears in the list of providers.

Note: It might take a few minutes for the provider to have the status Ready.

Add access to the UI of the provider:
On the Providers page, click the provider.
The Provider details page opens.
Click the Edit icon under External UI web link.
Enter the link and click Save.

Ref: https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/

MicroCode Update

Suyash Sambhare — Thu, 04 Dec 2025 04:33:45 +0000

FIT Microcode Update

The Firmware Interface Table (FIT) is a data structure located in the platform BIOS SPI flash that may contain pointers to one or more microcode updates. Loading a microcode update from the FIT is the preferred way to load a microcode update in Intel platforms, because it helps ensure all the update components1 are loaded at the earliest point in the boot process. Before executing the first instruction of the BIOS firmware at the Intel® architecture (IA) reset vector, the CPU processes the FIT to locate a microcode update suitable for that particular CPU. If a suitable update is found, the CPU loads the update before the first instruction of the BIOS firmware is fetched. After loading an update from the FIT, the bootstrap processor (BSP) begins fetching and executing the BIOS firmware from the IA reset vector, while the application processors (APs) enter into the Wait-for-SIPI state.

On some processors, a microcode update is loaded from the FIT only on the BSP core, while on other processors, it may be loaded on all cores.

A microcode update is loaded from the FIT after either a warm or cold hardware reset. It does not occur in response to an INIT event. It is BIOS’s responsibility to ensure the validity and the integrity of the microcode update before incorporating it into the IFWI in flash memory.

Early BIOS Microcode Update

Early BIOS microcode update is when a microcode update is loaded by BIOS before memory has been initialized.

Early BIOS microcode update may be performed by early BIOS initialization on the BSP. BIOS may skip this microcode update if an update has already been loaded via the FIT. BIOS can determine whether an update was loaded from the FIT by executing the CPUID instruction and then reading IA32_BIOS_SIGN_ID (MSR 8BH). If IA32_BIOS_SIGN_ID[63:32] is non-zero, then an update was already loaded from the FIT, and the early BIOS microcode update load point may be skipped.

Intel recommends that updates are loaded very early in the BIOS initialization sequence, either via the FIT (preferred), or via early BIOS microcode update load before the BIOS Memory Reference Code is executed and before DRAM is available. This is needed to address issues that may affect the later BIOS code (like the BIOS Memory Reference Code).

When a microcode update is loaded from the FIT, it may be loaded on all processors or only on the BSP. When an update is loaded during early BIOS, it may also be loaded only on the BSP core, since application processor (AP) cores may not be awake at this point in the boot sequence. Therefore, as soon as possible after receiving the Startup Inter-Processor Interrupt (SIPI), BIOS software on the AP cores should load the update if it has not already been loaded from the FIT.

Late BIOS Microcode Update

On more recent processors, certain architectural features, such as Intel® Software Guard Extensions (Intel® SGX), require an additional late BIOS microcode update. In order to enable these architectural features, a late BIOS microcode update must be performed on all logical processors, even if the same microcode update has already been loaded from the FIT or during early BIOS. In that case, late BIOS must reload the same update that was loaded earlier. Failure to perform the late BIOS microcode update on all logical processors may prevent these architectural features from being used.

During a late BIOS microcode update, the update may perform certain checks on the memory configuration and/or other settings required to enable these features. To facilitate the system checks, late BIOS load must occur after all of the following are completed:

DRAM and memory map is configured
Invocation of the first System Management Interrupt (SMI)
System Management Mode (SMM) handler relocation
Processor Reserved Memory Range Registers (PRMRR) are configured

In a multisocket system, BIOS software must provide synchronization to perform the late BIOS microcode update on all sockets in parallel. During the update sequence, each CPU will attempt to synchronize with CPUs in other sockets. Failure to load the update in parallel across sockets may cause this synchronization to fail, which may prevent certain architectural features from being enabled. This multisocket synchronization is only necessary during the late BIOS microcode update on processors supporting features that specifically require it. It is not required when loading a microcode update from the OS.

Early OS Microcode Update

The operating system (OS) should check if it has a more recent microcode update (higher update revision) than the version applied by the BIOS. If it does, the OS should load that microcode update shortly after BIOS hands off control to the OS. This microcode update load point is called the early OS microcode update. This can be done by an early boot software layer such as a Unified Extensible Firmware Interface (UEFI) driver, a bootloader, the operating system, or any other software layer provided by the operating system (like early startup scripts). The early OS microcode update should be done on each core as early as possible in the OS boot sequence, before any CPUID feature flags or other enumeration values are cached by the OS software. It is also required to be loaded before any user-space applications or virtual machines are launched. This is necessary so that the update is loaded before the affected microcode is ever used, enabling any relevant mitigations for potential vulnerabilities as early as possible.

If the BIOS does not load the most recent microcode update, Intel recommends loading that update during the early OS microcode update.

Runtime Microcode Update

Runtime microcode update refers to loading an update while the system is fully operational and running workloads, possibly including user-space applications and virtual machines. Software should ensure that the same update is loaded on all cores. Some microcode updates may introduce new features and may change CPUID feature flags or other enumeration. Software that wishes to use features introduced via a runtime microcode update may need to reevaluate any CPUID feature flags or other enumeration after the update is loaded in order to take advantage of any new capabilities introduced by that microcode update.

Runtime microcode update should be used when a system reset would be problematic (for example, when a system reset would impact server uptime requirements). Where possible, it is preferable to load microcode updates through BIOS or early OS.

Ref: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/microcode-update-guidance.html