cross-posted from: https://lemmy.run/post/10868

Beginner's Guide to grep

grep is a powerful command-line tool used for searching and filtering text in files. It allows you to find specific patterns or strings within files, making it an invaluable tool for developers, sysadmins, and anyone working with text data. In this guide, we will cover the basics of using grep and provide you with some useful examples to get started.

Installation

grep is a standard utility on most Unix-like systems, including Linux and macOS. If you're using a Windows operating system, you can install it by using the Windows Subsystem for Linux (WSL) or through tools like Git Bash, Cygwin, or MinGW.

Basic Usage

The basic syntax of grep is as follows:

grep [options] pattern [file(s)]

• options: Optional flags that modify the behavior of grep.
• pattern: The pattern or regular expression to search for.
• file(s): Optional file(s) to search within. If not provided, grep will read from standard input.

Examples

Searching in a Single File

To search for a specific pattern in a single file, use the following command:

grep "pattern" file.txt

Replace "pattern" with the text you want to search for and file.txt with the name of the file you want to search in.

Searching in Multiple Files

If you want to search for a pattern across multiple files, use the following command:

grep "pattern" file1.txt file2.txt file3.txt

You can specify as many files as you want, separating them with spaces.

Ignoring Case

By default, grep is case-sensitive. To perform a case-insensitive search, use the -i option:

grep -i "pattern" file.txt

Displaying Line Numbers

To display line numbers along with the matching lines, use the -n option:

grep -n "pattern" file.txt

This can be helpful when you want to know the line numbers where matches occur.

Searching Recursively

To search for a pattern in all files within a directory and its subdirectories, use the -r option (recursive search):

grep -r "pattern" directory/

Replace directory/ with the path to the directory you want to search in.

Using Regular Expressions

grep supports regular expressions for more advanced pattern matching. Here's an example using a regular expression to search for email addresses:

grep -E "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b" file.txt

In this case, the -E option enables extended regular expressions.

Conclusion

grep is a versatile tool that can greatly enhance your text searching and filtering capabilities. With the knowledge you've gained in this beginner's guide, you can start using grep to quickly find and extract the information you need from text files. Experiment with different options and explore more advanced regular expressions to further expand your skills with grep. Happy grepping!

cross-posted from: https://lemmy.run/post/10868

Beginner's Guide to grep

grep is a powerful command-line tool used for searching and filtering text in files. It allows you to find specific patterns or strings within files, making it an invaluable tool for developers, sysadmins, and anyone working with text data. In this guide, we will cover the basics of using grep and provide you with some useful examples to get started.

Installation

grep is a standard utility on most Unix-like systems, including Linux and macOS. If you're using a Windows operating system, you can install it by using the Windows Subsystem for Linux (WSL) or through tools like Git Bash, Cygwin, or MinGW.

Basic Usage

The basic syntax of grep is as follows:

grep [options] pattern [file(s)]

• options: Optional flags that modify the behavior of grep.
• pattern: The pattern or regular expression to search for.
• file(s): Optional file(s) to search within. If not provided, grep will read from standard input.

Examples

Searching in a Single File

To search for a specific pattern in a single file, use the following command:

grep "pattern" file.txt

Replace "pattern" with the text you want to search for and file.txt with the name of the file you want to search in.

Searching in Multiple Files

If you want to search for a pattern across multiple files, use the following command:

grep "pattern" file1.txt file2.txt file3.txt

You can specify as many files as you want, separating them with spaces.

Ignoring Case

By default, grep is case-sensitive. To perform a case-insensitive search, use the -i option:

grep -i "pattern" file.txt

Displaying Line Numbers

To display line numbers along with the matching lines, use the -n option:

grep -n "pattern" file.txt

This can be helpful when you want to know the line numbers where matches occur.

Searching Recursively

To search for a pattern in all files within a directory and its subdirectories, use the -r option (recursive search):

grep -r "pattern" directory/

Replace directory/ with the path to the directory you want to search in.

Using Regular Expressions

grep supports regular expressions for more advanced pattern matching. Here's an example using a regular expression to search for email addresses:

grep -E "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b" file.txt

In this case, the -E option enables extended regular expressions.

Conclusion

grep is a versatile tool that can greatly enhance your text searching and filtering capabilities. With the knowledge you've gained in this beginner's guide, you can start using grep to quickly find and extract the information you need from text files. Experiment with different options and explore more advanced regular expressions to further expand your skills with grep. Happy grepping!

Beginner's Guide to grep

grep is a powerful command-line tool used for searching and filtering text in files. It allows you to find specific patterns or strings within files, making it an invaluable tool for developers, sysadmins, and anyone working with text data. In this guide, we will cover the basics of using grep and provide you with some useful examples to get started.

Installation

grep is a standard utility on most Unix-like systems, including Linux and macOS. If you're using a Windows operating system, you can install it by using the Windows Subsystem for Linux (WSL) or through tools like Git Bash, Cygwin, or MinGW.

Basic Usage

The basic syntax of grep is as follows:

grep [options] pattern [file(s)]

• options: Optional flags that modify the behavior of grep.
• pattern: The pattern or regular expression to search for.
• file(s): Optional file(s) to search within. If not provided, grep will read from standard input.

Examples

Searching in a Single File

To search for a specific pattern in a single file, use the following command:

grep "pattern" file.txt

Replace "pattern" with the text you want to search for and file.txt with the name of the file you want to search in.

Searching in Multiple Files

If you want to search for a pattern across multiple files, use the following command:

grep "pattern" file1.txt file2.txt file3.txt

You can specify as many files as you want, separating them with spaces.

Ignoring Case

By default, grep is case-sensitive. To perform a case-insensitive search, use the -i option:

grep -i "pattern" file.txt

Displaying Line Numbers

To display line numbers along with the matching lines, use the -n option:

grep -n "pattern" file.txt

This can be helpful when you want to know the line numbers where matches occur.

Searching Recursively

To search for a pattern in all files within a directory and its subdirectories, use the -r option (recursive search):

grep -r "pattern" directory/

Replace directory/ with the path to the directory you want to search in.

Using Regular Expressions

grep supports regular expressions for more advanced pattern matching. Here's an example using a regular expression to search for email addresses:

grep -E "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b" file.txt

In this case, the -E option enables extended regular expressions.

Conclusion

grep is a versatile tool that can greatly enhance your text searching and filtering capabilities. With the knowledge you've gained in this beginner's guide, you can start using grep to quickly find and extract the information you need from text files. Experiment with different options and explore more advanced regular expressions to further expand your skills with grep. Happy grepping!

cross-posted from: https://lemmy.run/post/10475

Testing Service Accounts in Kubernetes

Service accounts in Kubernetes are used to provide a secure way for applications and services to authenticate and interact with the Kubernetes API. Testing service accounts ensures their functionality and security. In this guide, we will explore different methods to test service accounts in Kubernetes.

1. Verifying Service Account Existence

To start testing service accounts, you first need to ensure they exist in your Kubernetes cluster. You can use the following command to list all the available service accounts:

kubectl get serviceaccounts

Verify that the service account you want to test is present in the output. If it's missing, you may need to create it using a YAML manifest or the kubectl create serviceaccount command.

2. Checking Service Account Permissions

After confirming the existence of the service account, the next step is to verify its permissions. Service accounts in Kubernetes are associated with roles or cluster roles, which define what resources and actions they can access.

To check the permissions of a service account, you can use the kubectl auth can-i command. For example, to check if a service account can create pods, run:

kubectl auth can-i create pods --as=system:serviceaccount:<namespace>:<service-account>

Replace <namespace> with the desired namespace and <service-account> with the name of the service account.

3. Testing Service Account Authentication

Service accounts authenticate with the Kubernetes API using bearer tokens. To test service account authentication, you can manually retrieve the token associated with the service account and use it to authenticate requests.

To get the token for a service account, run:

kubectl get secret <service-account-token-secret> -o jsonpath="{.data.token}" | base64 --decode

Replace <service-account-token-secret> with the actual name of the secret associated with the service account. This command decodes and outputs the service account token.

You can then use the obtained token to authenticate requests to the Kubernetes API, for example, by including it in the Authorization header using tools like curl or writing a simple program.

4. Testing Service Account RBAC Policies

Role-Based Access Control (RBAC) policies govern the access permissions for service accounts. It's crucial to test these policies to ensure service accounts have the appropriate level of access.

One way to test RBAC policies is by creating a Pod that uses the service account you want to test and attempting to perform actions that the service account should or shouldn't be allowed to do. Observe the behavior and verify if the access is granted or denied as expected.

5. Automated Testing

To streamline the testing process, you can create automated tests using testing frameworks and tools specific to Kubernetes. For example, the Kubernetes Test Framework (KTF) provides a set of libraries and utilities for writing tests for Kubernetes components, including service accounts.

Using such frameworks allows you to write comprehensive test cases to validate service account behavior, permissions, and RBAC policies automatically.

Conclusion

Testing service accounts in Kubernetes ensures their proper functioning and adherence to security policies. By verifying service account existence, checking permissions, testing authentication, and validating RBAC policies, you can confidently use and rely on service accounts in your Kubernetes deployments.

Remember, service accounts are a critical security component, so it's important to regularly test and review their configuration to prevent unauthorized access and potential security breaches.

cross-posted from: https://lemmy.run/post/10206

Creating a Helm Chart for Kubernetes

In this tutorial, we will learn how to create a Helm chart for deploying applications on Kubernetes. Helm is a package manager for Kubernetes that simplifies the deployment and management of applications. By using Helm charts, you can define and version your application deployments as reusable templates.

Prerequisites

Before we begin, make sure you have the following prerequisites installed:

• Helm: Follow the official Helm documentation for installation instructions.

Step 1: Initialize a Helm Chart

To start creating a Helm chart, open a terminal and navigate to the directory where you want to create your chart. Then, run the following command:

helm create my-chart

This will create a new directory named my-chart with the basic structure of a Helm chart.

Step 2: Customize the Chart

Inside the my-chart directory, you will find several files and directories. The most important ones are:

• Chart.yaml: This file contains metadata about the chart, such as its name, version, and dependencies.
• values.yaml: This file defines the default values for the configuration options used in the chart.
• templates/: This directory contains the template files for deploying Kubernetes resources.

You can customize the chart by modifying these files and adding new ones as needed. For example, you can update the Chart.yaml file with your desired metadata and edit the values.yaml file to set default configuration values.

Step 3: Define Kubernetes Resources

To deploy your application on Kubernetes, you need to define the necessary Kubernetes resources in the templates/ directory. Helm uses the Go template language to generate Kubernetes manifests from these templates.

For example, you can create a deployment.yaml template to define a Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Release.Name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          ports:
            - containerPort: {{ .Values.containerPort }}

This template uses the values defined in values.yaml to customize the Deployment's name, replica count, image, and container port.

Step 4: Package and Install the Chart

Once you have defined your Helm chart and customized the templates, you can package and install it on a Kubernetes cluster. To package the chart, run the following command:

helm package my-chart

This will create a .tgz file containing the packaged chart.

To install the chart on a Kubernetes cluster, use the following command:

helm install my-release my-chart-0.1.0.tgz

Replace my-release with the desired release name and my-chart-0.1.0.tgz with the name of your packaged chart.

Conclusion

Congratulations! You have learned how to create a Helm chart for deploying applications on Kubernetes. By leveraging Helm's package management capabilities, you can simplify the deployment and management of your Kubernetes-based applications.

Feel free to explore the Helm documentation for more advanced features and best practices.

Happy charting!

cross-posted from: https://lemmy.run/post/10475

Testing Service Accounts in Kubernetes

Service accounts in Kubernetes are used to provide a secure way for applications and services to authenticate and interact with the Kubernetes API. Testing service accounts ensures their functionality and security. In this guide, we will explore different methods to test service accounts in Kubernetes.

1. Verifying Service Account Existence

To start testing service accounts, you first need to ensure they exist in your Kubernetes cluster. You can use the following command to list all the available service accounts:

kubectl get serviceaccounts

Verify that the service account you want to test is present in the output. If it's missing, you may need to create it using a YAML manifest or the kubectl create serviceaccount command.

2. Checking Service Account Permissions

After confirming the existence of the service account, the next step is to verify its permissions. Service accounts in Kubernetes are associated with roles or cluster roles, which define what resources and actions they can access.

To check the permissions of a service account, you can use the kubectl auth can-i command. For example, to check if a service account can create pods, run:

kubectl auth can-i create pods --as=system:serviceaccount:<namespace>:<service-account>

Replace <namespace> with the desired namespace and <service-account> with the name of the service account.

3. Testing Service Account Authentication

Service accounts authenticate with the Kubernetes API using bearer tokens. To test service account authentication, you can manually retrieve the token associated with the service account and use it to authenticate requests.

To get the token for a service account, run:

kubectl get secret <service-account-token-secret> -o jsonpath="{.data.token}" | base64 --decode

Replace <service-account-token-secret> with the actual name of the secret associated with the service account. This command decodes and outputs the service account token.

You can then use the obtained token to authenticate requests to the Kubernetes API, for example, by including it in the Authorization header using tools like curl or writing a simple program.

4. Testing Service Account RBAC Policies

Role-Based Access Control (RBAC) policies govern the access permissions for service accounts. It's crucial to test these policies to ensure service accounts have the appropriate level of access.

One way to test RBAC policies is by creating a Pod that uses the service account you want to test and attempting to perform actions that the service account should or shouldn't be allowed to do. Observe the behavior and verify if the access is granted or denied as expected.

5. Automated Testing

To streamline the testing process, you can create automated tests using testing frameworks and tools specific to Kubernetes. For example, the Kubernetes Test Framework (KTF) provides a set of libraries and utilities for writing tests for Kubernetes components, including service accounts.

Using such frameworks allows you to write comprehensive test cases to validate service account behavior, permissions, and RBAC policies automatically.

Conclusion

Testing service accounts in Kubernetes ensures their proper functioning and adherence to security policies. By verifying service account existence, checking permissions, testing authentication, and validating RBAC policies, you can confidently use and rely on service accounts in your Kubernetes deployments.

Remember, service accounts are a critical security component, so it's important to regularly test and review their configuration to prevent unauthorized access and potential security breaches.

cross-posted from: https://lemmy.run/post/10475

Testing Service Accounts in Kubernetes

Service accounts in Kubernetes are used to provide a secure way for applications and services to authenticate and interact with the Kubernetes API. Testing service accounts ensures their functionality and security. In this guide, we will explore different methods to test service accounts in Kubernetes.

1. Verifying Service Account Existence

To start testing service accounts, you first need to ensure they exist in your Kubernetes cluster. You can use the following command to list all the available service accounts:

kubectl get serviceaccounts

Verify that the service account you want to test is present in the output. If it's missing, you may need to create it using a YAML manifest or the kubectl create serviceaccount command.

2. Checking Service Account Permissions

After confirming the existence of the service account, the next step is to verify its permissions. Service accounts in Kubernetes are associated with roles or cluster roles, which define what resources and actions they can access.

To check the permissions of a service account, you can use the kubectl auth can-i command. For example, to check if a service account can create pods, run:

kubectl auth can-i create pods --as=system:serviceaccount:<namespace>:<service-account>

Replace <namespace> with the desired namespace and <service-account> with the name of the service account.

3. Testing Service Account Authentication

Service accounts authenticate with the Kubernetes API using bearer tokens. To test service account authentication, you can manually retrieve the token associated with the service account and use it to authenticate requests.

To get the token for a service account, run:

kubectl get secret <service-account-token-secret> -o jsonpath="{.data.token}" | base64 --decode

Replace <service-account-token-secret> with the actual name of the secret associated with the service account. This command decodes and outputs the service account token.

You can then use the obtained token to authenticate requests to the Kubernetes API, for example, by including it in the Authorization header using tools like curl or writing a simple program.

4. Testing Service Account RBAC Policies

Role-Based Access Control (RBAC) policies govern the access permissions for service accounts. It's crucial to test these policies to ensure service accounts have the appropriate level of access.

One way to test RBAC policies is by creating a Pod that uses the service account you want to test and attempting to perform actions that the service account should or shouldn't be allowed to do. Observe the behavior and verify if the access is granted or denied as expected.

5. Automated Testing

To streamline the testing process, you can create automated tests using testing frameworks and tools specific to Kubernetes. For example, the Kubernetes Test Framework (KTF) provides a set of libraries and utilities for writing tests for Kubernetes components, including service accounts.

Using such frameworks allows you to write comprehensive test cases to validate service account behavior, permissions, and RBAC policies automatically.

Conclusion

Testing service accounts in Kubernetes ensures their proper functioning and adherence to security policies. By verifying service account existence, checking permissions, testing authentication, and validating RBAC policies, you can confidently use and rely on service accounts in your Kubernetes deployments.

Remember, service accounts are a critical security component, so it's important to regularly test and review their configuration to prevent unauthorized access and potential security breaches.

cross-posted from: https://lemmy.run/post/10475

Testing Service Accounts in Kubernetes

Service accounts in Kubernetes are used to provide a secure way for applications and services to authenticate and interact with the Kubernetes API. Testing service accounts ensures their functionality and security. In this guide, we will explore different methods to test service accounts in Kubernetes.

1. Verifying Service Account Existence

To start testing service accounts, you first need to ensure they exist in your Kubernetes cluster. You can use the following command to list all the available service accounts:

kubectl get serviceaccounts

Verify that the service account you want to test is present in the output. If it's missing, you may need to create it using a YAML manifest or the kubectl create serviceaccount command.

2. Checking Service Account Permissions

After confirming the existence of the service account, the next step is to verify its permissions. Service accounts in Kubernetes are associated with roles or cluster roles, which define what resources and actions they can access.

To check the permissions of a service account, you can use the kubectl auth can-i command. For example, to check if a service account can create pods, run:

kubectl auth can-i create pods --as=system:serviceaccount:<namespace>:<service-account>

Replace <namespace> with the desired namespace and <service-account> with the name of the service account.

3. Testing Service Account Authentication

Service accounts authenticate with the Kubernetes API using bearer tokens. To test service account authentication, you can manually retrieve the token associated with the service account and use it to authenticate requests.

To get the token for a service account, run:

kubectl get secret <service-account-token-secret> -o jsonpath="{.data.token}" | base64 --decode

Replace <service-account-token-secret> with the actual name of the secret associated with the service account. This command decodes and outputs the service account token.

You can then use the obtained token to authenticate requests to the Kubernetes API, for example, by including it in the Authorization header using tools like curl or writing a simple program.

4. Testing Service Account RBAC Policies

Role-Based Access Control (RBAC) policies govern the access permissions for service accounts. It's crucial to test these policies to ensure service accounts have the appropriate level of access.

One way to test RBAC policies is by creating a Pod that uses the service account you want to test and attempting to perform actions that the service account should or shouldn't be allowed to do. Observe the behavior and verify if the access is granted or denied as expected.

5. Automated Testing

To streamline the testing process, you can create automated tests using testing frameworks and tools specific to Kubernetes. For example, the Kubernetes Test Framework (KTF) provides a set of libraries and utilities for writing tests for Kubernetes components, including service accounts.

Using such frameworks allows you to write comprehensive test cases to validate service account behavior, permissions, and RBAC policies automatically.

Conclusion

Testing service accounts in Kubernetes ensures their proper functioning and adherence to security policies. By verifying service account existence, checking permissions, testing authentication, and validating RBAC policies, you can confidently use and rely on service accounts in your Kubernetes deployments.

Remember, service accounts are a critical security component, so it's important to regularly test and review their configuration to prevent unauthorized access and potential security breaches.

cross-posted from: https://lemmy.run/post/10475

Testing Service Accounts in Kubernetes

Service accounts in Kubernetes are used to provide a secure way for applications and services to authenticate and interact with the Kubernetes API. Testing service accounts ensures their functionality and security. In this guide, we will explore different methods to test service accounts in Kubernetes.

1. Verifying Service Account Existence

To start testing service accounts, you first need to ensure they exist in your Kubernetes cluster. You can use the following command to list all the available service accounts:

kubectl get serviceaccounts

Verify that the service account you want to test is present in the output. If it's missing, you may need to create it using a YAML manifest or the kubectl create serviceaccount command.

2. Checking Service Account Permissions

After confirming the existence of the service account, the next step is to verify its permissions. Service accounts in Kubernetes are associated with roles or cluster roles, which define what resources and actions they can access.

To check the permissions of a service account, you can use the kubectl auth can-i command. For example, to check if a service account can create pods, run:

kubectl auth can-i create pods --as=system:serviceaccount:<namespace>:<service-account>

Replace <namespace> with the desired namespace and <service-account> with the name of the service account.

3. Testing Service Account Authentication

Service accounts authenticate with the Kubernetes API using bearer tokens. To test service account authentication, you can manually retrieve the token associated with the service account and use it to authenticate requests.

To get the token for a service account, run:

kubectl get secret <service-account-token-secret> -o jsonpath="{.data.token}" | base64 --decode

Replace <service-account-token-secret> with the actual name of the secret associated with the service account. This command decodes and outputs the service account token.

You can then use the obtained token to authenticate requests to the Kubernetes API, for example, by including it in the Authorization header using tools like curl or writing a simple program.

4. Testing Service Account RBAC Policies

Role-Based Access Control (RBAC) policies govern the access permissions for service accounts. It's crucial to test these policies to ensure service accounts have the appropriate level of access.

One way to test RBAC policies is by creating a Pod that uses the service account you want to test and attempting to perform actions that the service account should or shouldn't be allowed to do. Observe the behavior and verify if the access is granted or denied as expected.

5. Automated Testing

To streamline the testing process, you can create automated tests using testing frameworks and tools specific to Kubernetes. For example, the Kubernetes Test Framework (KTF) provides a set of libraries and utilities for writing tests for Kubernetes components, including service accounts.

Using such frameworks allows you to write comprehensive test cases to validate service account behavior, permissions, and RBAC policies automatically.

Conclusion

Testing service accounts in Kubernetes ensures their proper functioning and adherence to security policies. By verifying service account existence, checking permissions, testing authentication, and validating RBAC policies, you can confidently use and rely on service accounts in your Kubernetes deployments.

Remember, service accounts are a critical security component, so it's important to regularly test and review their configuration to prevent unauthorized access and potential security breaches.

Author: Sanghamitra

East and west: Gujarat and Odisha celebrate the Rathayatra of Lord Jagannath with pomp and splendour

Today is Ashadha Shukla Dwitiya, the auspicious day for Lord Jagannath's Rathayatra every year. Two Indian states, located on the two opposite coasts of the grand nation, are celebrating the festival with much fervor and grandeur.

Today is Ashadha Shukla Dwitiya, the auspicious day for Lord Jagannath’s Rathayatra every year. Two Indian states, located on the two opposite coasts of the grand nation, are celebrating the festival with much fervor and grandeur.

Odisha Rathayatra

Odisha, the home abode of Lord Jagannath, has been celebrating the Rathayatra festival for centuries now. The grand Jagannath Temple at Puri, constructed in the 12th century organizes the world’s largest and oldest Rathayatra festival every year in the ‘Bada Danda’ in Puri.

The three grand chariots await outside the Singhadwara of the Temple on the day of the Rathayatra. The construction of the chariots starts on the day of Akshaya Tritiya, and designated carpenters, known as ‘Maharanas’ make the chariots. The colour schemes, and design of the chariots are fixed for each of the three Gods.

Lord Jagannatha’s chariot is called ‘Nandighosha’, Lord Balabhadra’s chariot is called ‘Taladhwaja’ and Devi Subhadra’s chariot is called ‘Debadalana’. Lord Sudarshana rides in the Debadalana too.

The process of bringing the holy Trinity out from their pedestal in the temple to their respective chariots is called ‘Pahandi’.

After the Gods are seated in their respective chariots, the Gajapati Maharaj, the traditional ruler of Kalinga, performs the ritual of ‘Chhera Panhara’. It is the ritual of sweeping the chariots with a golden broom. It signifies the belief that the Gajapati Maharaj is the servant of Lord Jagannath and rules in his name.

The Chhera Panhara ritual has another significance in Odia folklore and literary tradition. Odia epic ‘Kanchi Kaveri Upakhyana’ describes Purushottama Deva’s campaign to win kingdoms in the south of Kalinga. Purushottama Deva was insulted by Kanchi ruler Saluva Narasingha Deva because the former wanted to marry the latter’s daughter Padmavati. Saluva Narasingha Deva had declared that he would rather get his daughter married to a poor sweeper than allow her to marry the Kalinga Gajapati.

Purushottama Deva, fumed at the insult, had attacked Kanchi and eventually won with direct help from Lord Jagannatha and his brother Lord Balabhadra. After bringing Padmavati to Kalinga, he was yet to forget the insult. So he had declared that Padmavati will be married off to a sweeper, just as her father wanted.

However, the clever ministers of Purushottama Deva knew that the Kanchi princess deserves to marry the Gajapati, and Kalinga deserves a queen of unparalleled beauty and qualities that she possessed. So on the day of Rathayatra, when Purushottama Deva was performing the sweeping ritual, they brought the Kanchi princess on board the chariot, and she put a garland on the neck of the Gajapati, just when he held a broom in his hand, literally being a ‘sweeper’.

Purushottama Deva had loved the princess and there was no way he could be angry now, after being married to her in the presence of Lord Jagannatha himself.

Thus, the ministers avoided their king’s wrath and made him see reason by forgetting his anger. The story can be read in detail here.

In Puri’s Rathayatra, the Gods visit the Gundicha Temple and stay there for 9 days. Then they return to their own Temple, that Yatra is called ‘Bahuda Yatra’.

Gujarat Rathayatra

Gujarat is home to Dwaraka, Lord Krishna’s kingdom. Like Odisha, it too has a deep Vaishnava tradition. The state has been celebrating Rathayatra for nearly a century and a half.

It is celebrated as a ‘Lokotsav’ or a public festival in Gujarat. Though many cities have their own Rathyatra, Ahmedabad hosts the grandest and biggest event. The CM performs the ‘Pahind Vidhi’ which is similar to the ‘Chhera Panhara’ ritual of Odisha.

In Ahmedabad Rathyaatra, the chariots pass through the different parts of the city. The chariots cover a distance of 14 km and the devotees offer ‘mahabhoj’ to the entire entourage.

Union Minister Amit Shah today performed the mangal aarti at the Jagannath Temple in Ahmedabad before the commencement of Rathayatra. CM Bhupendra Patel performed the ‘Pahind Vidhi’. This is the 146th year of the Ahmedabad Rathayatra.

Gujarat and Odisha are separated by over 1800 km, located on the opposite coasts of India. However, Rathayatra is something that binds the two states together. Each celebration is unique in its style and decorations, but the deep Jagannath Bhakti and the Vaishnava traditions of their people are what bring them close in mind and spirit.

Rathyatra celebrations in these two distant states are another example of how the states of India, despite diverse linguistic and cultural norms, are bound together by strings of Hindu tradition and spirituality.

Author: Jinit Jain

Ahilyabai Holkar, the Maratha Queen like no other who constructed and restored Hindu temples which stand tall even today

*Ahilyabai Holkar is fondly remembered for constructing hundreds of temples, ghats, pilgrimage centres, Dharamshalas but rebuilding of Kashi Vishwanath Temple is considered as her greatest achievement. *

PM Narendra Modi on Monday, December 13, 2021, inaugurated the Kashi Vishwanath Corridor Project in Varanasi, restoring an array of temples to their past glory. With the inauguration of the hallowed temple corridor project, PM Modi has once again burnished his credentials as the most potent preserver of the Hindu heritage in the recent times.

As PM Modi buckles down the task of fulfilling the promises he made while contesting the Lok Sabha elections from Varanasi constituency in 2014, one of them being transforming it into a “city of temples”, he did not fail to acknowledge the role of historical figures who helped in conserving the city’s holy character.

In his inaugural speech, PM Modi paid floral tributes to Ahilyabai Holkar, Maharaja Ranjit Singh among other people, who played a pivotal role in reconstruction and renovation of Kashi Vishwanath in the past.

PM said, “The role of Mata Ahilyabai Holkar in the reconstruction of the temple is noteworthy. Maharaja Ranjit Singh sent 23 man (920 KG) of gold to the temple.” He said after Mata Ahilyabai Holkar, the expansion of the Kashi Vishwanath Dham had happened now.

And not just in words but in deeds too, PM Modi and the Centre paid homage to Maratha Queen Ahilyabai Holkar for her momentous contribution in preserving the heritage of Kashi Vishwanath. A figurine of Maharani Ahilyabai Holkar has been put up at the sprawling campus of the Kashi Vishwanath Dham, which was adorned with flowers for its inauguration on Monday. In addition to this, large posters of the Maratha queen were also held up in the premises of the corridors.

Who was Ahilyabai Holkar?

Ahilyabai Holkar was one of the most well-known queens to have presided over the Maratha Empire in the 18th century. Born in May 1725 in the village of Chaundi, in present-day Ahmednagar district of Maharashtra, Maharani Ahilyabai Holkar was the Holkar Queen of the Maratha Malwa kingdom.

She was not born in the royal lineage and was the hereditary noble Queen of the Maratha Empire. When she was 8-years-old, she was spotted by the acclaimed Lord of the Malwa territory, Malhar Rao Holkar, while she feeding the poor. Struck by her compassion and empathy for the destitute, Malhar Rao betrothed her to his son.

However, she lost her husband in the battle of Kumbher when she was just 29. After her husband’s death, she tried to end her life with the practice of Sati but was stopped by her father-in-law. She later ascended the throne and became the ruler of Indore on 11 December 1767.

In opposition to the prevailing culture of the time which disallowed women from pursuing education, Ahilyabai Holkar was an educated woman. She was homeschooled by her father. Perhaps, it was her education and knowledge that helped her to pull together the kingdom of Malwa after the demise of her husband and father-in-law.

Ahilyabai ruled for nearly three decades and was conferred with the title of ‘The Philosopher Queen’ by a British historian John Keyas. In her praise, he said: “Ahilyabai Holkar, the philosopher-queen of Malwa, had evidently been an acute observer of the wider political scene.”

Ahilyabai Holkar-The pioneer of temple construction and restoration

Though Ahilyabai Holkar was an astute queen and quite adept in handling court matters, she was best known for being the pioneer, builder and preserver of the Hindu temples across the length and breadth of the country. From Somnath in the west, to the Kashi Vishwanath in the east, Holkar dedicated her life towards renovating and reconstructing temples that were victims of the ravages of the time or were subjected to assault and plunder by Muslim invaders.

She built temples at Srinagar, Haridwar, Kedarnath, Badrinath, Rishikesh, Prayaga, Varanasi, Naimisharanya, Puri, Rameshwaram, Somnath, Nasik, Omkareshvar, Mahabaleshwar, Pune, Indore, Srisailam, Udipi, Gokarna, Khatmandu etc. She built and restored temples everywhere across India except for territories controlled by Afghans, Nawabs & the British.

River Ganga holds special importance as per Hindu scriptures. Regarded as sacred by Hindus, the river is embodied as the goddess Ganga in ancient texts and art. The water of river Ganga is considered as holy, with ritual bathing being an integral part of Hindu pilgrimage. The water, reverentially called as gangajal, was also used in various pujas performed in Hindu temples. Ahilyabai Holkar arranged for supplying water from the river Ganga collected at Gangotri to be received by temples across the country, including temples as far away as in Kerala, Tamil Nadu and Karnataka.

The Maratha Queen’s contribution in rebuilding Kashi Vishwanath Temple

She is fondly remembered for constructing hundreds of temples, ghats, pilgrimage centres, Dharamshalas around her kingdom but rebuilding of Kashi Vishwanath Temple is considered as her greatest achievements of all.

Her contribution in restoring Kashi Vishwanath temple was particularly significant. The temple had stood tall for centuries before becoming an eye sour for the Mughals. The Islamic rulers, who were on the mission to destroy anything that was against Islam, saw Kashi Vishwanath Dham as one of the main targets challenging the supremacy of their faith.

On April 18, 1669, Islamic ruler Aurangzeb gave the order to demolish Kashi Vishwanath Temple. In his order, he had written that the temple was the place where “the foolish Pundits teach evil knowledge from junk books.”

On the explicit orders from Mughal emperor Aurangzeb, Kashi Vishwanath Dham, one of the holiest Hindu sites of pilgrimage, was plundered, desecrated, demolished & converted into Gyanvapi Mosque in 1669. The current structure and the form of the Kashi Vishwanath Temple could be attributed to Ahilyabai Holkar, who got the structure reconstructed in 1776. Then in 19th century, Maharaja Ranjit Singh adorned the temple with ‘golden’ shikhar.