Use Case Scenario

Problem: In most Kubernetes applications, secrets are hardcoded or statically injected, requiring pod restarts when secrets like database passwords are rotated. This creates downtime and maintenance overhead.

Solution: Integrate AKS with Azure Key Vault using the CSI driver and enable automatic secret rotation. Secrets will be mounted into pods and updated dynamically without restarting the pod, ensuring zero-downtime secret updates.

Architecture Overview

The architecture includes:

• AKS Cluster
• Azure Key Vault
• Workload Identity (OIDC) for secure identity management
• CSI Secrets Store Driver for mounting secrets
• Auto-Rotation of secrets via polling

Step-by-Step Implementation

To create a AKS cluster using CLI please follow this blog: AKS Cluster Setup Using Azure CLI with OIDC & Azure Key Vault Integration

1. Enable OIDC and Workload Identity on exiting AKS cluster

az aks update \
  --name <cluster-name> \
  --resource-group <rg> \
  --enable-oidc-issuer \
  --enable-workload-identity

az aks update \
  --name <cluster-name> \
  --resource-group <rg> \
  --enable-oidc-issuer \
  --enable-workload-identity

To enable Azure Key Vault CSI driver after the cluster is created:

az aks enable-addons \
  --addons azure-keyvault-secrets-provider \
  --name <cluster-name> \
  --resource-group <rg>
  

az aks enable-addons \
  --addons azure-keyvault-secrets-provider \
  --name <cluster-name> \
  --resource-group <rg>
  

You can verify through azure portal under your kuberenets cluster dashboard “Security Configuration” tab

Verify that each node in your cluster’s node pool has a Secrets Store CSI Driver pod and a Secrets Store Provider Azure pod running

kubectl get pods -n kube-system -l 'app in (secrets-store-csi-driver,secrets-store-provider-azure)' -o wide

kubectl get pods -n kube-system -l 'app in (secrets-store-csi-driver,secrets-store-provider-azure)' -o wide

1.2 Keyvault creation and configuration

Create a key vault with Azure role-based access control (Azure RBAC).

az keyvault create -n my-demo-k8s-key-vault -g keyvault-demo -l eastus --enable-rbac-authorization

az keyvault create -n my-demo-k8s-key-vault -g keyvault-demo -l eastus --enable-rbac-authorization

2. Create a Managed Identity

Please export following values on your terminal, make sure you have added your subscription id..etc

export SUBSCRIPTION_ID=fe4a1fdb-6a1c-4a6d-a6b0-dbb12f6a00f8
export RESOURCE_GROUP=keyvault-demo
export UAMI=azurekeyvaultsecretsprovider-keyvault-demo-cluster
export KEYVAULT_NAME=my-demo-k8s-key-vault
export CLUSTER_NAME=keyvault-demo-cluster

az account set --subscription $SUBSCRIPTION_ID

export SUBSCRIPTION_ID=fe4a1fdb-6a1c-4a6d-a6b0-dbb12f6a00f8
export RESOURCE_GROUP=keyvault-demo
export UAMI=azurekeyvaultsecretsprovider-keyvault-demo-cluster
export KEYVAULT_NAME=my-demo-k8s-key-vault
export CLUSTER_NAME=keyvault-demo-cluster

az account set --subscription $SUBSCRIPTION_ID

To Create a managed identity, following azure cli command

az identity create --name $UAMI --resource-group $RESOURCE_GROUP

export USER_ASSIGNED_CLIENT_ID="$(az identity show -g $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"

export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)

az identity create --name $UAMI --resource-group $RESOURCE_GROUP

export USER_ASSIGNED_CLIENT_ID="$(az identity show -g $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"

export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)

Create a role assignment that grants the workload ID access the key vault

export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)

az role assignment create --role "Key Vault Administrator" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE

export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)

az role assignment create --role "Key Vault Administrator" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE

Get the AKS cluster OIDC Issuer URL

export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"

echo $AKS_OIDC_ISSUER

export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"

echo $AKS_OIDC_ISSUER

3. Annotate Kubernetes ServiceAccount

export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export SERVICE_ACCOUNT_NAMESPACE="default" 

export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export SERVICE_ACCOUNT_NAMESPACE="default" 

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
  annotations:
    azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}"
EOF

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
  annotations:
    azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}"
EOF

Or If above syntax confusing, SA direct yaml syntax given below fill details accordingly

apiVersion: v1
kind: ServiceAccount
metadata:
  name: workload-identity-sa
  annotations:
    azure.workload.identity/client-id: <your-client-id>
    namespace: default

apiVersion: v1
kind: ServiceAccount
metadata:
  name: workload-identity-sa
  annotations:
    azure.workload.identity/client-id: <your-client-id>
    namespace: default

Setup Federation

export FEDERATED_IDENTITY_NAME="aksfederatedidentity" 

az identity federated-credential create --name $FEDERATED_IDENTITY_NAME --identity-name $UAMI --resource-group $RESOURCE_GROUP --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

export FEDERATED_IDENTITY_NAME="aksfederatedidentity" 

az identity federated-credential create --name $FEDERATED_IDENTITY_NAME --identity-name $UAMI --resource-group $RESOURCE_GROUP --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

4. Create SecretProviderClass

cat <<EOF | kubectl apply -f -
# This is a SecretProviderClass example using workload identity to access your key vault
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname-wi # needs to be unique per namespace
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    clientID: "${USER_ASSIGNED_CLIENT_ID}" # Setting this to use workload identity
    keyvaultName: ${KEYVAULT_NAME}       # Set to the name of your key vault
    cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
    objects:  |
      array:
        - |
          objectName: DB-Password         # Set to the name of your secret
          objectType: secret              # object types: secret, key, or cert
          objectVersion: ""              
    tenantId: "${IDENTITY_TENANT}"        # The tenant ID of the key vault
EOF

cat <<EOF | kubectl apply -f -
# This is a SecretProviderClass example using workload identity to access your key vault
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname-wi # needs to be unique per namespace
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    clientID: "${USER_ASSIGNED_CLIENT_ID}" # Setting this to use workload identity
    keyvaultName: ${KEYVAULT_NAME}       # Set to the name of your key vault
    cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
    objects:  |
      array:
        - |
          objectName: DB-Password         # Set to the name of your secret
          objectType: secret              # object types: secret, key, or cert
          objectVersion: ""              
    tenantId: "${IDENTITY_TENANT}"        # The tenant ID of the key vault
EOF

Or use below direct yaml secretproviderclass and fill details accordingly

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname-wi
spec:
  provider: azure
  parameters:
    keyvaultName: <your-kv-name>
    tenantId: <your-tenant-id>
    clientID: <your-client-id>
    objects: |
      array:
        - objectName: DB-Password
          objectType: secret
          objectVersion: ""

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname-wi
spec:
  provider: azure
  parameters:
    keyvaultName: <your-kv-name>
    tenantId: <your-tenant-id>
    clientID: <your-client-id>
    objects: |
      array:
        - objectName: DB-Password
          objectType: secret
          objectVersion: ""

5. Deploy a Workload (e.g., BusyBox Test Pod)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-secrets
spec:
  replicas: 1
  selector:
    matchLabels:
      app: busybox-secrets
  template:
    metadata:
      labels:
        app: busybox-secrets
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: workload-identity-sa
      containers:
        - name: busybox
          image: registry.k8s.io/e2e-test-images/busybox:1.29-4
          command: ["/bin/sleep", "10000"]
          volumeMounts:
            - name: secrets-store-vol
              mountPath: "/mnt/secrets-store"
              readOnly: true
      volumes:
        - name: secrets-store-vol
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: azure-kvname-wi
              rotationPollInterval: "30s"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-secrets
spec:
  replicas: 1
  selector:
    matchLabels:
      app: busybox-secrets
  template:
    metadata:
      labels:
        app: busybox-secrets
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: workload-identity-sa
      containers:
        - name: busybox
          image: registry.k8s.io/e2e-test-images/busybox:1.29-4
          command: ["/bin/sleep", "10000"]
          volumeMounts:
            - name: secrets-store-vol
              mountPath: "/mnt/secrets-store"
              readOnly: true
      volumes:
        - name: secrets-store-vol
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: azure-kvname-wi
              rotationPollInterval: "30s"

Now you can exec into the pod and verify the secret are mounted into the container. You can run following command to verify the same

kubectl exec <pod> -- ls /mnt/secrets-store/
kubectl exec <pod> -- cat /mnt/secrets-store/DB-Password

kubectl exec <pod> -- ls /mnt/secrets-store/
kubectl exec <pod> -- cat /mnt/secrets-store/DB-Password

⟳ Enable Auto-Rotation of Secrets

Run the following command to enable the rotation feature:

az aks addon update \
  --resource-group <rg> \
  --name <cluster-name> \
  --addon azure-keyvault-secrets-provider \
  --enable-secret-rotation \
  --rotation-poll-interval 30s

az aks addon update \
  --resource-group <rg> \
  --name <cluster-name> \
  --addon azure-keyvault-secrets-provider \
  --enable-secret-rotation \
  --rotation-poll-interval 30s

Verify it with:

kubectl -n kube-system describe ds aks-secrets-store-csi-driver

kubectl -n kube-system describe ds aks-secrets-store-csi-driver

Ensure the arguments include:

• --enable-secret-rotation=true
• --rotation-poll-interval=30s

To work Azure Key Vault auto rotation in deployment, Make sure following settings are there in first

1) Under SecretProviderClass Leave objectVersion blank

2) Add to volume attributes on deployment file: rotationPollInterval

volumeAttributes:
  secretProviderClass: azure-kvname-wi
  rotationPollInterval: "30s"

volumeAttributes:
  secretProviderClass: azure-kvname-wi
  rotationPollInterval: "30s"

Testing the Rotation

1. Manually update the secret version in Azure Key Vault.
2. Wait for rotationPollInterval.
3. Check the mounted file inside the pod:

kubectl exec <pod> -- ls /mnt/secrets-store/
kubectl exec <pod> -- cat /mnt/secrets-store/DB-Password

kubectl exec <pod> -- ls /mnt/secrets-store/
kubectl exec <pod> -- cat /mnt/secrets-store/DB-Password

4. Observe that the new value is reflected without restarting the pod.

Best Practices

• Avoid subPath in volume mounts (breaks rotation).
• Ensure your application reads secrets from file, not env vars.
• Consider implementing file watchers for dynamic config reloads.
• Monitor CSI driver logs: kubectl logs ds/aks-secrets-store-csi-driver -n kube-system

Conclusion

With Azure Key Vault, CSI driver, and workload identity, you can achieve secure, automated, and zero-downtime secret management for your AKS workloads. Auto-rotation ensures credentials like DB passwords can be updated without disrupting live applications.

Feel free to follow me on LinkedIn and share your thoughts. For a complete YAML reference or demo repo, connect with me or leave a comment!

The post Secure Secret Management in AKS with Azure Key Vault CSI Driver and Auto-Rotation Enabled appeared first on abdulrahmanuk.com.

Step 1: Create an Azure Resource Group

az group create --name keyvault-demo --location eastus

This creates a logical container for your AKS resources.

Step 2: Create the AKS Cluster with Workload Identity and Azure Key Vault Integration

az aks create \
  --name keyvault-demo-cluster \
  --resource-group keyvault-demo \
  --node-count 1 \
  --enable-addons azure-keyvault-secrets-provider \
  --enable-oidc-issuer \
  --enable-workload-identity

Explanation of Flags:

• --enable-addons azure-keyvault-secrets-provider: Installs the CSI driver and Azure Key Vault provider addon.
• --enable-oidc-issuer: Enables the OIDC issuer URL for secure authentication with federated identity.
• --enable-workload-identity: Activates Azure Workload Identity (replacement for AAD Pod Identity).

Step 3: Get AKS Credentials for kubectl

az aks get-credentials \
  --resource-group keyvault-demo \
  --name keyvault-demo-cluster

This updates your local kubeconfig so you can interact with the new cluster.

Step 4: Verify CSI Driver and Azure Provider Pods

Make sure everything is running correctly:

kubectl get pods -n kube-system -l 'app in (secrets-store-csi-driver,secrets-store-provider-azure)' -o wide

You should see pods like:

• secrets-store-csi-driver-*
• secrets-store-provider-azure-*

Bonus: Why Use Azure Key Vault with AKS?

• Centralized Secrets Management
• Automatic Secret Rotation
• No Secret Mounting in Code
• Secure Identity Binding with Workload Identity

This setup is cloud-native, secure, and production-ready.

The post AKS Cluster Setup Using Azure CLI with OIDC & Azure Key Vault Integration appeared first on abdulrahmanuk.com.

In this guide, we’ll walk you through how to create an AKS cluster using PowerShell directly from the Azure Cloud Shell or your local PowerShell session. Whether you’re getting started or automating cluster provisioning, this tutorial will provide a clear, step-by-step approach.

Prerequisites

Before we begin, make sure you have the following:

• An active Azure subscription
• Azure PowerShell installed locally or use Azure Cloud Shell
• Azure CLI is optional but recommended for verification

Step 1: Log in to the Azure Account

Open PowerShell and log in to your Azure account.

Connect-AzAccount

This command opens a sign-in window or browser-based prompt to authenticate your account.

Step 2: Set Your Subscription (If You Have Multiple)

Get-AzSubscription
Set-AzContext -SubscriptionId "your-subscription-id"

Step 3: Create a Resource Group

A resource group is a container that holds related resources for an Azure solution.

$resourceGroup = "AKS-ResourceGroup"
$location = "EastUS"

New-AzResourceGroup -Name $resourceGroup -Location $location

Step 4: Create an Azure AD Service Principal (Optional but recommended)

This account will be used by AKS to interact with Azure resources.

$sp = New-AzADServicePrincipal -DisplayName "AKSServicePrincipal"
$spPassword = (New-AzADSpCredential -ServicePrincipalObjectId $sp.Id).SecretText

Store the AppId and Password for later use.

Step 5: Create the AKS Cluster

$aksName = "MyAKSCluster"

New-AzAksCluster `
  -ResourceGroupName $resourceGroup `
  -Name $aksName `
  -KubernetesVersion "1.29.2" `
  -NodeCount 3 `
  -NodeVmSize "Standard_DS2_v2" `
  -GenerateSshKey `
  -Location $location `
  -EnableRBAC

You can specify additional parameters such as -ServicePrincipalId, -ClientSecret, or -NetworkPlugin azure For more custom setups.

Step 6: Verify the Cluster

After creation, verify the AKS cluster status:

Get-AzAksCluster -ResourceGroupName $resourceGroup -Name $aksName

Step 7: Connect to the AKS Cluster Using kubectl

First, install kubectl if you haven’t already:

az aks install-cli

Then, get credentials:

az aks get-credentials --resource-group $resourceGroup --name $aksName

Verify connection:

kubectl get nodes

Wrapping Up

You’ve successfully created an AKS Cluster using PowerShell on Microsoft Azure! This process is ideal for automating infrastructure deployment.

Bonus Tips

• Use Azure Bicep or Terraform for infrastructure-as-code.
• Integrate Azure Key Vault and Managed Identity for secure secrets management.
• Enable monitoring with Azure Monitor and Log Analytics for production workloads.

The post How to Create an AKS Cluster Using PowerShell in Azure Portal appeared first on abdulrahmanuk.com.

Thankfully, Kubernetes provides powerful tools to enforce resource limits at the namespace level, allowing teams to share the cluster fairly. In this blog post, we’ll explore two important tools for namespace-level resource management:

• Resource Quotas
• Limit Ranges

Let’s dive in and see how they work, with practical examples to help you get started.

What Are Resource Quotas in Kubernetes?

Resource Quotas let administrators cap the total amount of resources that a specific namespace can use. Think of it as setting a budget for pods, CPU, memory, and other compute resources.

Why Use Resource Quotas?

• Define clear usage boundaries per namespace.
• Monitor and track resource usage in real-time.
• Automatically block workloads that try to exceed their limits.

How to Set a Resource Quota

To apply a Resource Quota, create a YAML file and apply it to the relevant namespace.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota-example
  namespace: example-namespace
spec:
  hard:
    pods: "1"
    requests.cpu: "2"
    requests.memory: "5Gi"
    limits.cpu: "4"
    limits.memory: "10Gi"

Then apply it using:

kubectl apply -f resource-quota.yaml

This will limit the example-namespace to 1 pod, 2 CPU requests, 5Gi of memory requests, and caps CPU and memory usage at 4 CPUs and 10Gi, respectively.

Verifying the Resource Quota

Check if the quota has been successfully applied:

kubectl get resourcequota resource-quota-example -n example-namespace

Or to get detailed info:

kubectl describe ns example-namespace

Sample output:

Resource         Used  Hard
limits.cpu       0     4
limits.memory    0     10Gi
pods             0     1
requests.cpu     0     2
requests.memory  0     5Gi

Testing Quota Enforcement

Let’s try deploying more pods than allowed to see the quota in action.

Deployment with 2 replicas (but the quota allows only 1):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: quota-test
  namespace: example-namespace
  labels:
    app: deployment-label
spec:
  replicas: 2
  selector:
    matchLabels:
      app: deployment-label
  template:
    metadata:
      labels:
        app: deployment-label
    spec:
      containers:
      - name: nginx-deploy
        image: nginx:latest
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 100m
            memory: 100Mi

Apply the deployment:

kubectl apply -f deploy.yaml

Check the pod status:

kubectl get all -n example-namespace

ou’ll see something like:

Warning  FailedCreate  pods "quota-test-xxxx" is forbidden: exceeded quota: resource-quota-example...

The second pod fails to start—exactly what we want. The quota is working as intended!

What Are Limit Ranges in Kubernetes?

While Resource Quotas set overall namespace limits, Limit Ranges control the default and maximum/minimum resource limits for each pod, container, or PVC. This ensures no single pod or container hogs cluster resources.

Why Use Limit Ranges?

• Enforce consistent resource consumption across deployments.
• Prevent resource abuse by setting sensible defaults.
• Ensure all pods have a minimum allocation for healthy operation.

How to Set a Limit Range

Create a limit-range.yaml file:

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-range-example
  namespace: example-namespace
spec:
  limits:
  - type: Pod
    max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "200m"
      memory: "256Mi"
    maxLimitRequestRatio:
      cpu: "4"
      memory: "8"
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "250m"
      memory: "256Mi"
    max:
      cpu: "1"
      memory: "1Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    maxLimitRequestRatio:
      cpu: "2"
      memory: "4"
  - type: PersistentVolumeClaim
    max:
      storage: "10Gi"
    min:
      storage: "1Gi"
    default:
      storage: "5Gi"
    defaultRequest:
      storage: "2Gi"
    maxLimitRequestRatio:
      storage: "2"

Apply it:

kubectl apply -f limit-range.yaml

Limit Ranges apply defaults automatically to pods if you forget to specify them!

Verifying the Limit Range

Use the following commands:

kubectl describe limitrange limit-range-example -n example-namespace
kubectl describe ns example-namespace

You’ll see something like:

Type                   Resource  Min    Max   Default Request  Default Limit  Max Limit/Request Ratio
Pod                    cpu       200m   2     -                -              4
Pod                    memory    256Mi  4Gi   -                -              8
Container              cpu       100m   1     250m             500m           2
Container              memory    128Mi  1Gi   256Mi            512Mi          4
PersistentVolumeClaim  storage   1Gi    10Gi  2Gi              5Gi            2

Testing the Limit Range in Action

Create a deployment without resource specs and watch the defaults kick in:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: limit-test
  namespace: example-namespace
  labels:
    app: deployment-label
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deployment-label
  template:
    metadata:
      labels:
        app: deployment-label
    spec:
      containers:
      - name: nginx-deploy
        image: nginx:latest

Apply it:

kubectl apply -f deploy.yaml

Now describe the pod and you’ll notice the resource requests and limits are automatically applied based on the LimitRange!

Final Thoughts

Namespace-level resource control in Kubernetes is not just a best practice—it’s a necessity for scalable and stable clusters.

Use Resource Quotas to enforce overall limits per namespace.
Use Limit Ranges to set smart defaults and enforce per-container or per-pod limits.

By combining both, you ensure fair resource distribution, avoid noisy neighbor problems, and maintain consistent workload performance across your Kubernetes environment.

Got questions about resource management in Kubernetes?
Drop a comment below or connect with me for more DevOps tips and Kubernetes best practices.

Happy Clustering!

The post Kubernetes Resource Limits Simplified – From Beginner to Production Ready appeared first on abdulrahmanuk.com.

Introduction

As a DevOps engineer, mastering Linux is non-negotiable. Whether you’re deploying microservices, debugging performance issues, managing cloud infrastructure, or building CI/CD pipelines, Linux commands are at the core of your workflow. This guide walks you through 35 essential Linux commands, each with real-world use cases tailored for DevOps.

File & Directory Operations

1. ls – List files and directories.
   • ls -lah shows file sizes and permissions.
2. cd – Change directories.
   • Navigate efficiently in scripts: cd /var/www/html.
3. pwd – Print working directory.
   • Useful for debugging scripts.
4. mkdir – Create directories.
   • Example: mkdir -p /opt/myapp/logs creates nested folders.
5. touch – Create empty files.
   • Used to create .env or placeholder files in pipelines.
6. rm – Remove files and directories.
   • Caution: rm -rf /some/path can be destructive. Automate cleanup jobs.
7. cp – Copy files and directories.
   • Example: cp config.yaml config.yaml.bak before updates.
8. mv – Move or rename files.
   • Use in deployment steps: mv new.html index.html
9. find – Search for files.
   • find /var/log -name "*.log" to identify large log files.
10. du – Estimate file space usage.
    • du -sh * shows space used by directories.

File Viewing & Manipulation

11. cat – View file contents.
    • Combine with grep for quick searches.
12. less / more – Page through text.
    • less /var/log/syslog to view logs comfortably.
13. head / tail – View the start or end of files.
    • tail -f /var/log/nginx/access.log for live logs.
14. grep – Search text with patterns.
    • Example: grep "ERROR" /var/log/app.log
15. awk – Pattern scanning and data extraction.
    • Real use: awk -F":" '{ print $1 }' /etc/passwd to list usernames.
16. sed – Stream editor for modifying files.
    • Replace text in files: sed -i 's/foo/bar/g' config.txt
17. cut – Extract fields from text.
    • cut -d':' -f1 /etc/passwd
18. sort – Sort lines in text files.
    • Useful in processing pipeline logs or output.
19. uniq – Filter out repeated lines.
    • sort data.txt | uniq -c shows duplicates.

Permissions & Ownership

20. chmod – Change file permissions.
    • chmod 755 script.sh makes it executable.
21. chown – Change file owner and group.
    • chown www-data:www-data /var/www/html -R
22. umask – Set default permissions.
    • Often set in init scripts.
23. stat – Display detailed file info.
    • Helps in debugging file access issues.

Process & Resource Management

24. ps – Display current processes.
    • ps aux | grep nginx to locate specific services.
25. top / htop – Monitor system resource usage.
    • htop is interactive and user-friendly.
26. kill / killall – Terminate processes.
    • kill -9 <PID> to forcefully stop rogue processes.
27. nice / renice – Set process priority.
    • Adjust priority for resource-hungry tasks.
28. lsof – List open files.
    • Debug file locks: lsof | grep deleted
29. strace – Trace system calls.
    • Debug startup issues: strace ./myapp

Networking & Troubleshooting

30. curl – Transfer data to/from a server.
    • Test APIs: curl -X POST -d '{}' https://api.example.com
31. wget – Non-interactive file download.
    • wget https://downloads.example.com/tool.sh
32. netstat / ss – Network statistics.
    • ss -tulnp shows listening ports.
33. tcpdump – Capture network traffic.
    • Debug latency: tcpdump -i eth0 port 80
34. ping / traceroute – Network connectivity.
    • Identify broken routes or DNS issues.

Automation & Scripting

35. xargs – Build and execute commands from input.
    • Bulk operations: cat urls.txt | xargs wget

Real DevOps Use Case Highlights:

• Using awk in CI/CD: Extract version info from files and pass it to Docker.
• lsof to troubleshoot: Find services holding deleted files and causing disk bloat.
• sed in automation: Replace environment variables during deployment.
• tail -f in monitoring: View live logs in Kubernetes pods.
• xargs for batch tasks: Automate bulk log rotation or file downloads.

Conclusion

Mastering these 35 Linux commands will not only boost your productivity but also help you troubleshoot and automate your infrastructure with confidence. Bookmark this list and start integrating these commands into your daily workflow. Want more DevOps content? Follow me on LinkedIn and stay tuned for upcoming posts on Ansible, Docker, Kubernetes, and Terraform!

The post 35 Must-Know Linux Commands Every DevOps Engineer Should Master (with Real DevOps Use Cases) appeared first on abdulrahmanuk.com.

MySQL InnoDB Cluster Architecture

1. 3 MySQL Nodes: 1 primary (writer) + 2 secondaries (readers)
2. Group Replication for HA
3. MySQL Router (deployed on a separate VM for better failover control)
4. Backups (dump + binary logs) for PITR

Pre-requisites
Ubuntu VMs (each with at least 2 vCPUs and 4GB RAM recommended)
All VMs must be reachable via an internal network.
MySQL port (3306) and Group Replication ports (33061, 33062) must be open.

I had created 3 VMs on Azure Cloud to create the MySQL Cluster architecture

Step 1: Install MySQL on All Nodes

sudo apt update && sudo apt install mysql-server net-tools -y
wget https://repo.mysql.com//mysql-apt-config_0.8.34-1_all.deb
sudo dpkg -i mysql-apt-config_0.8.34-1_all.deb
sudo apt update && sudo apt install mysql-shell -y

Check that MySQL is running and listening on 3306 on each node (especially node01):

sudo netstat -tulnp | grep 3306

#You should see something like:
**tcp   0  0 0.0.0.0:3306   0.0.0.0:*   LISTEN   1234/mysqld**

If it only shows 127.0.0.1:3306, then MySQL is **not listening on external IPs**.
👉 **To fix that:**
Edit your mysqld.cnf (location: /etc/mysql/mysql.conf.d/mysqld.cnf):

**bind-address = 0.0.0.0**

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
# Set bind-address to:
bind-address = 0.0.0.0

Then restart:

sudo systemctl restart mysql

Step 2: Configure Each MySQL Node

Create a config file /etc/mysql/mysql.conf.d/group_replication.cnf on each node.
Example (for node01):

[mysqld]
# Server identity (must be unique for each node)
server-id=1  # node01 = 1, node02 = 2, node03 = 3 (change accordingly)

# Enable binary logging
log_bin = mysql-bin
binlog_format = ROW
binlog_checksum = NONE
transaction_write_set_extraction = XXHASH64

# Enable GTID
gtid_mode = ON
enforce_gtid_consistency = ON

# Group Replication settings
loose-group_replication_group_name="aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
loose-group_replication_start_on_boot=off
loose-group_replication_bootstrap_group=off
loose-group_replication_local_address="node01:33061"  # Change per node
loose-group_replication_group_seeds="node01:33061,node02:33061,node03:33061"
loose-group_replication_single_primary_mode=ON
loose-group_replication_enforce_update_everywhere_checks=OFF

# Networking
report_host=node01  # change for each node
bind-address=0.0.0.0
mysqlx-bind-address=0.0.0.0

# InnoDB settings
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

Make sure each node has a unique server-id and correct report_host.

Step 3: Create a Cluster Admin User

CREATE USER 'clusteradmin'@'%' IDENTIFIED BY 'StrongPass!123';
GRANT ALL PRIVILEGES ON *.* TO 'clusteradmin'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Step 4: Configure InnoDB Cluster

On node01, use MySQL Shell:

mysqlsh --uri clusteradmin@localhost

Please enter clusteradmin password “StrongPass!123” once it pops up on your terminal

Then: Run the following command one by one on node01

dba.configureInstance('clusteradmin@node01')
dba.configureInstance('clusteradmin@node02')
dba.configureInstance('clusteradmin@node03')

After once you have completed above command, then run following command on node01

var cluster = dba.createCluster('wordpressCluster')
cluster.addInstance('clusteradmin@node02')
cluster.addInstance('clusteradmin@node03')

Finally, you can check the cluster status.

cluster.status()

At this point, the cluster is formed, and MySQL group replication is working.
Success! You now have a functional InnoDB Cluster

Step 5: Setup mysqldump Cron Job for Daily Backups

Create a script /usr/local/bin/mysql_backup.sh:
You can mount a volume to this directory /mnt/mysql_backup. This way, you can make sure your backup will be safe if the server has any issues.

#!/bin/bash
DATE=$(date +%F_%H-%M)
mysqldump -u root --all-databases > /mnt/mysql_backup/db_backup_$DATE.sql

Make it executable:

chmod +x /usr/local/bin/mysql_backup.sh

Add a cron job:

crontab -e

0 2 * * * /usr/local/bin/mysql_backup.sh

This runs daily at 2 AM.

Step 6: Backup Binary Logs Every Minute

Use mysqlbinlog to extract binlog content every minute:
Create /usr/local/bin/binlog_backup.sh:

#!/bin/bash
DATE=$(date +%F_%H-%M)
BINLOG_PATH="/mnt/mysql_binlog"
DEST_PATH="/mnt/mysql_backup/binlogs"
mkdir -p "$DEST_PATH"
cp $BINLOG_PATH/mysql-bin.* "$DEST_PATH/binlog_$DATE"

Add to crontab:

* * * * * /usr/local/bin/binlog_backup.sh

This ensures you can do point-in-time recovery using full dump + binlogs.

Important Concepts to Know

MySQL Router – On a Dedicated VM
For better failover and load balancing, deploy MySQL Router separately:

sudo apt install mysql-router -y
mysqlrouter --bootstrap clusteradmin@node01:3306 --directory /etc/mysqlrouter
sudo systemctl start mysqlrouter

It ensures connections always route to the right node. no manual switching needed

Failover Test

Try stopping MySQL on node01:

sudo systemctl stop mysql

Once you stop MySQL services, to see the failover, you have to connect to the MySQL shell. For that, follow the commands below

mysqlsh --uri clusteradmin@localhost

var cluster = dba.getCluster('wordpressCluster')

cluster.status()

Wrapping Up

Setting up a MySQL InnoDB Cluster isn’t just about replication. It’s about building a resilient, production-ready database architecture with automatic failover, dedicated routing, and reliable backups. With 3 MySQL nodes, a separate MySQL Router VM, binary logs, and regular dumps, you’re all set for high availability and peace of mind.

The post Creating a Highly Available MySQL InnoDB Cluster appeared first on abdulrahmanuk.com.

If you are working in Software Industry must hear about the two-term “Git and GitHub” but before jumping into git first, you have to understand what version control is and what issue the software industry was facing before git.

What is Version Control System?

A version control system is software that tracks changes to a file or set of files over time so that you can recall specific versions later. It also allows you to work together with other programmers.

The version control system is a collection of software tools that help a team to manage changes in a source code. It uses a special kind of database to keep track of every modification to the code.

Developers can compare earlier versions of the code with an older version to fix the mistakes.

Benefits

• Enhances the project development speed by providing efficient collaboration.
• Reduce possibilities of errors and conflicts meanwhile project development through traceability to every small change.
• Employees or contributors of the project can contribute from anywhere irrespective of the different geographical locations through this VCS
• For each different contributor to the project, a different working copy is maintained and not merged to the main file unless the working copy is validated.
• Informs us about Who, What, When, and Why changes have been made.
• Helps in recovery in case of any disaster situation

Types of VCS

1. Centralized Version Control Systems

2. Distributed Version Control Systems

Centralized Version Control Systems :

Centralized version control systems contain just one repository globally and every user needs to commit for reflecting one’s changes in the repository. Others can see your changes by updating.

CVCS has some drawbacks and the problem was,

a) It is not locally available, meaning you always need to be connected to a network to perform any actions.

b) Since everything is centralized, if Central Server gets failed, you will lose the entire data.

Central Repository or Central Server means,it is a kind of storage or folder in a remote server, where you or anyone can keep your code and can see that code or can access it.

Distributed Version Control Systems

1. In a DVCS, every developer has a full copy of the repository, including the entire history of all changes. This makes it easier for developers to work together, as they don’t have to constantly communicate with a central server to commit their changes or to see the changes made by others.
2. Because developers have a local copy of the repository, they can commit their changes and perform other version control actions faster, as they don’t have to communicate with a central server.
3. With a DVCS, developers can work offline and commit their changes later when they do have an internet connection. They can also choose to share their changes with only a subset of the team, rather than pushing all of their changes to a central server.
4. In a DVCS, the repository history is stored on multiple servers and computers, which makes it more resistant to data loss.

Git is an example of DVCS.

Difference between CVCS and DVCS

1. In CVCS, a client need to get a local copy of the source from the server, do the changes and commit those changes to the central source on the server, while in DVCS each client can have a local branch or repository as well and have a complete history on it. The client needs to push the changes to the branch which will then be pushed to the server repository.

2. CVCS systems are easy to learn and set up, and DVCS systems are difficult for beginners. Multiple commands need to be remembered.

3. Working on branches is difficult in CVCS, Developer often faces Merge Conflict. Working on branches is easier in DVCS, developers face less conflict.

4. CVCS systems do not provide offline access. DVCS systems are working fine in offline mode as a client copies the entire repository on their local machine.

5. CVCS is slower as every command needs to communicate with the server. while DVCS is faster as most user deals with a local copy without hitting the server every time.

6. If the CVCS server goes down, the developer is not able to do the work. But if the DVCS server is down, developers can work using their local copies.

GitHub

Git and GitHub are not the same things, Git mainly works on local systems. Github is used to store code that is remotely centralized and most Developers use this to store their code. GitHub is the largest host of source code in the world and has been owned by Microsoft since 2018.

Git

Git is a Distributed Version Control System and was launched by Linus Torvald & this person also introduced Linux. Git is a software tool.

It is used for:

• Tracking code changes
• Tracking who made changes
• Coding collaboration

What does Git do?

• Manage projects with Repositories
• Clone a project to work on a local copy
• Control and track changes with Staging and Committing
• Branch and Merge to allow for work on different parts and versions of a project
• Pull the latest version of the project to a local copy
• Push local updates to the main project

Actual Workflow of Git

1. Initialize Git on a folder, making it a local Repository by the git init command. A hidden folder will create named .git
2. Clone a project to work on a local copy
3. Working directory and Staging area: this is where you see files physically and do modifications. At a time you can work on a particular branch. When we send our code to the staging area to finalize our code from the working space, this procedure is known as AddIn other CVCS, developers generally make modifications and commit their changes directly to the Repository (central). But Git uses a different strategy. Git does not track every modified file. Whenever you do commit an operation, Git looks for the files present in the staging area. Only those files present in the staging area are considered for commit and not all the modified files.
4. Commit: From the staging area when we send our codes to the local Repository this process will be known as Commit (save/snapshot). After saving the code, a commit id will be created & this is unique.Commit Id: So if anyone needs to check any code later time, then they can check it through that commit id. Commit-ID is 40 alpha-numeric characters. It mainly uses the SHA-1 checksum concept. Even if you change one dot, the commit-id will get changed. It helps you to track the changes. Commit is also known as SHA-Hash.
5. Snapshot: It is that when you keep the codes into a file & when you change some code, eg:you change into 4-5 lines then when you take a snapshot of that file, the snapshot will copy only that 4-5 lines of code in another file, not the entire code. So this helps to save less storage of a file.Snapshot is incremental i.e. it will copy or save only the changed data.
6. Push: Push operation copies changes from a local Repository instance to a Remote or Central Repo(GitHub). This is used to store the changes permanently in the Git Repo.
7. Pull: Pull Operation copies the changes from a Remote Repo to a local machine. The pull operation is used for synchronization between two repo.
8. Branch: There is an important concept of the branch…

The diagram above visualizes a repository with two isolated lines of development. By developing them as branches, it’s not only possible to work on both of them in parallel, but it also keeps the main Master (default branch) free from error.

• Each task has one separate branch.
• After done with the code, Merge other Branches with the Master.
• This concept is useful for parallel development means at times many persons can work on their branch and that won’t reflect on the main branch.
• you can create any number of branches.
• Changes are personal to that particular branch.
• The default branch is Master.
• Files created in Workspace will be visible in any of the branch workspaces until you commit. Once you commit, then that file belongs to that particular branch.
• When creating a new branch, data from the existing Branch is copied to the new branch (only one time when the branch is created).

Tasks

1. Install git on your system

As am using Linux OS(Ubuntu ) so by default git is already installed in it ( Aws instance). My git version is 2.34.1

2. Create a free account in GitHub.

You can create a free account in GitHub by Signing up github.com (use this link).

3. Make a directory and make it a local repository by the git init command

Created one directory as test-repository then changed the directory to it. Then made it a git repository with git init command.A .git folder will be created that is hidden

4. Create a new repository on GitHub and clone it to your local machine

Created one repository in GitHub named Task-Repo and cloned it to my machine.

5. Make some changes to a file in the repository and commit them to the repository using Git

Cloned the repository that I created in GitHub by the url in my machine.

configured git with git config –global user.name and user.email (this will help to check who is committed by name and mail id) command.

Now chnaged to the repository that I cloned. Then created a file called devops.txt.

add the file by git add <filename> command and check the git status. This file is now staged. Now commit the file by the git commit command.

6. Push the changes back to the repository on GitHub

Now add the repository by the command git remote add origin <url of GitHub repo>

Then I pushed the committed file into GitHub by the command git push origin main (as my default branch is main here, it can be master sometimes too).

While pushing the file into github have to enter the GitHub username and Personal access token ( go to Developers settings in GitHub -> personal access token->generate token)

The post Day 8 Task – Basics Of Git & GitHub appeared first on abdulrahmanuk.com.

1. Pacakage Manager

A package manager is a tool that allows users to install, remove, upgrade, configure and manage software packages on an operating system. The package manager can be a graphical application like a software center or a command lines tool like apt-get or Pacman.

What is a Package?

A package is usually referred to an application but it could be a GUI application, command line tool or a software library (required by other software programs). A package is essentially an archive file containing the binary executable, configuration file and sometimes information about the dependencies.

How does the package manager work?

The package manager is a generic concept and it’s not exclusive to Linux. You’ll often find package managers for different software or programming languages. There is a PIP package manager just for Python packages.

Almost all Linux distributions have software repositories which is a collections of software packages. Yes, there could be more than one repository. The repositories contain software packages of a different kinds.

Repositories also have metadata files that contain information about the packages such as the name of the package, version number, description of the package and the repository name etc. This is what you see if you use the apt show command in Ubuntu/Debian.

Your system’s package manager first interacts with the metadata. The package manager creates a local cache of metadata on your system. When you run the update option of the package manager (for example apt update), it updates this local cache of metadata by referring to metadata from the repository.

When you run the installation command of your package manager (for example apt install package_name), the package manager refers to this cache. If it finds the package information in the cache, it uses the internet connection to connect to the appropriate repository and downloads the package first before installing on your system.

A package may have dependencies. Meaning that it may require other packages to be installed. The package manager often takes care of the dependencies and installs it automatically along with the package you are installing.

Types of Package Managers:

• 1. DPKG – Debian Package Management System
• APT (Advanced Packaging Tool) :It is a very popular, free, powerful, and more so, useful command line package management system that is a front end for the dpkg package management system.Users of Debian or its derivatives such as Ubuntu and Linux Mint should be familiar with this package management tool.
• Aptitude Package ManagerThis is also a popular command line front-end package management tool for the Debian Linux family, it works similarly to APT . It was initially built for Debian and its derivatives but now its functionality stretches to the RHEL family.
• 2. RPM (Red Hat Package Manager)
• YUM (Yellowdog Updater, Modified)It is an open-source and popular command line package manager that works as an interface for users to RPM. You can compare it to APT under Debian Linux systems, it incorporates the common functionalities that APT has.
• 3. Pacman Package Manager – Arch Linux
• 4. Zypper Package Manager – openSUSE
• 5. Portage Package Manager – Gentoo

2. You have to install docker and Jenkins in your system from your terminal using package managers

Jenkins:

To install Jenkins you first have to install java. So this is some steps to install java:

Initially update all packages used in the below command. NOTE: I’m showing here for Ubuntu operating system.

sudo apt update

sudo apt update

Depending on which Java version you want to install, Java 8 or 11, run one of the following commands:

To install OpenJDK 8, run:

sudo apt install openjdk-8-jdk -y

sudo apt install openjdk-8-jdk -y

To install OpenJDK 11, run:

sudo apt install openjdk-11-jdk -y

sudo apt install openjdk-11-jdk -y

Add Jenkins Repository

The version of Jenkins included with the default Ubuntu packages is often behind the latest available version from the project itself. To ensure you have the latest fixes and features, use the project-maintained packages to install Jenkins.

First, add the repository key to your system:

wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key |sudo gpg --dearmor -o /usr/share/keyrings/jenkins.gpg

wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key |sudo gpg --dearmor -o /usr/share/keyrings/jenkins.gpg

The gpg --dearmor command is used to convert the key into a format that apt recognizes.

Next, let’s append the Debian package repository address to the server’s sources.list:

sudo sh -c 'echo deb [signed-by=/usr/share/keyrings/jenkins.gpg] http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'

sudo sh -c 'echo deb [signed-by=/usr/share/keyrings/jenkins.gpg] http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'

The [signed-by=/usr/share/keyrings/jenkins.gpg] portion of the line ensures that apt will verify files in the repository using the GPG key that you just downloaded.

After both commands have been entered, run apt update so that apt will use the new repository.

sudo apt update

sudo apt update

Finally, install Jenkins and its dependencies:

sudo apt install jenkins

sudo apt install jenkins

Now that Jenkins and its dependencies are in place, we’ll start the Jenkins server.

Starting Jenkins

now that Jenkins is installed, start it by using systemctl:

sudo systemctl start jenkins.service

sudo systemctl start jenkins.service

Since systemctl doesn’t display status output, we’ll use the status command to verify that Jenkins started successfully:

sudo systemctl status jenkins

sudo systemctl status jenkins

If everything went well, the beginning of the status output shows that the service is active and configured to start at boot:

you have completed the installation stage and can continue with configuring Jenkins.

Docker installation:

step 1: sudo apt update -y

step 2: sudo apt install docker.io -y

step 3: docker –version

step 4: systemctl status docker [ to check if docker is in the active state]

systemctl and systemd

systemctl is used to examine and control the state of the “systemd” system and service manager.

systemd is a system and service manager for Unix-like operating systems(most of the distributions, not all).

4. stop the service Jenkins and post before and after screenshots

Jenkins active status Screenshot:

Jenkins stop Screenshot :

Read about the commands systemctl vs service

The Service command looks up the script to run at the path /etc/init.d/SCRIPT. It then runs the script, passing the COMMAND unchanged as the arguments. The service command guarantees a predictable running environment by removing most of the variables and setting the root path as the current working directory.

eg: sudo service jenkins start

The systemctl command interacts with the SystemD service manager to manage the services. Contrary to the service command, it manages the services by interacting with the SystemD process instead of running the init script.

To start, stop, and restart a process, we can run the commands with systemctl .

eg: sudo systemctl start docker

The post Day 7 Task – Understanding package manager and systemctl appeared first on abdulrahmanuk.com.

File permissions are core to the security model used by Linux systems. They determine who can access files and directories on a system and how.

To check a file permission as :

ls -l <file-name>

Permission Descriptions:

1. Read (r): The read permission allows you to open and read the content of a file. But you can’t do any editing or modification in the file.
2. Write (w): The write permission allows you to edit, remove or rename a file. For instance, if a file is present in a directory, and write permission is set on the file but not on the directory, then you can edit the content of the file but can’t remove, or rename it.
3. Execute (x): In Unix type system, you can’t run or execute a program unless execute permission is set. But in Windows, there is no such permission available.

Owner (u): Permissions used for the Owner of the file.

Group(g): Permissions used by members of the group.

Other(o): Permissions used by all other users.

Permission Set:

Permissions in detail:

Change File Permissions:

a) chmod: Change file access permissions.

Description: This command is used to change the file permissions. These permissions read, write and execute permission for the owner, group, and others.

Syntax (symbolic mode): chmod [ugoa][[+-=][mode]] file

The first optional parameter indicates who – this can be (u)ser, (g)roup, (o)there, or (a)ll.

The second optional parameter indicates opcode – this can be for adding (+), removing (-), or assigning (=) permission.

The third optional parameter indicates the mode – this can be (r)ead, (w)rite, or e(x) acute.

Example: Add writes permission for user, group, and others for file1.

$ chmod ugo+w file1

There is another way to change file permissions by numeric symbol:

Example: Give read/write/execute permission to the user, read/execute permission to the group, and execute permission to others.

$ chmod 751 file1

b) chown: Change ownership of the file.

Description: Only the owner of the file has the right to change the file ownership.

Syntax: chown [owner] [file]

Example: Change the owner of file1 to user2 assuming it is currently owned by the current user

$ chown user2 file1

c) chgrp: Change the group ownership of the file

Description: Only the owner of the file has the right to change the file ownership

Syntax: chgrp [group] [file]

Example: Change group of file1 to group2 assuming it is currently owned by the current user

$ chgrp group2 file1

2. Create a simple file and check the details of the file:

Here I created one file by using the touch command and then check the details of the file by using the ls -l command and then change the file permissions to 766 [all owner permissions, read and write permissions to group and others].

3 . Read about ACL and try out the commands getfacl and setfacl

Access control list (ACL) provides an additional, more flexible permission mechanism for file systems. It is designed to assist with UNIX file permissions. ACL allows you to give permissions for any user or group to any disc resource.

Use Of ACL: Think of a scenario in which a particular user is not a member of a group created by you but still you want to give some read or write access, how can you do it without making the user a member of the group, here comes in picture Access Control Lists, ACL helps us to do this trick.

ACLs are used to make a flexible permission mechanism in Linux.

From Linux man pages, ACLs are used to define more fine-grained discretionary access rights for files and directories.

setfacl and getfacl command:

The command “setfacl” refers to Set File Access Control Lists and “getfacl” refers to Get File Access Control List.

Example:

getfacl <file or directory name>

1. To add permission for user

setfacl -m “u:user: permissions” /path/to/file

setfacl -m u:tanaya:rwx test/declarations.h

2. To add permissions for a group

setfacl -m “g:group: permissions” /path/to/file

3. To remove ACL permission of user:

setfacl -x “u:user: permissions” /path/to/file

4. To remove ACL permission of group:

setfacl -x “g:group: permissions” /path/to/file

The post Day 6 – Linux File Permissions and Access Control Lists appeared first on abdulrahmanuk.com.

If you noticed that there are total 90 sub directories in the directory ‘2023’ of this repository. What did you think, how did I create 90 directories. Manually one by one or using a script, or a command ?

All 90 directories within seconds using a simple command.

mkdir day{1..90}

Tasks

1. You have to do the same using Shell Script i.e using either Loops or command with start day and end day variables using arguments –

So Write a bash script createDirectories.sh that when the script is executed with three given arguments (one is directory name and second is start number of directories and third is the end number of directories ) it creates specified number of directories with a dynamic directory name.

Example 1: When the script is executed as

./createDirectories.sh day 1 90

then it creates 90 directories as day1 day2 day3 .... day90

Example 2: When the script is executed as

./createDirectories.sh Movie 20 50 then it creates 50 directories as Movie20 Movie21 Movie23 ...Movie50

As we know that if we want to pass any argument at the time of bash script execution we used to denote it as like $1(first arg),$2(2nd arg) etc…So here we will do the same thing in a bash script like :

name of the file as createDirectories.sh

start_day as $2 and end_day as $3 and day as $1

Execute as ./createDirectories.sh day 1 90

Output

#!/bin/bash

if [ $# != 3 ]
then
	echo "Can't proceed \n Please give three arguments to continue"
	exit 1

fi

echo "Creating directory as per your requirement"
start_day=$2
end_day=$3

for (( i=start_day; i<=end_day; i++ ))
do
	mkdir $1$i
done	

echo "Here are your directories:"
ls

2. Create a Script to back up all your work done till now.

Backups are an important part of DevOps Engineers’ day to Day activities. Usually, when we create any backup of a file we used to create a zip file by using the tar command: tar -czvf file.tar.gz directory_name

Here is a simple shell script to take a backup of recent work:

#!/bin/bash

src_directory=/var/www/my-blog

BACKUP_FILENAME="backup_$(date +%Y-%m-%d).tar.gz"
TARGET_DIRECTORY="/home/ubuntu/backup/"

#Create backup archive
tar -czvf $TARGET_DIRECTORY/$BACKUP_FILENAME $src_directory

if [ $? -eq 0 ]; then
	echo "Backup successful!"
else
	echo "Backup failed."
fi

3. Read About Cron and Crontab, to automate the backup Script

Cron is a system process that will automatically perform tasks as per the specific schedule. It is a set of commands that are used for running regular scheduling tasks. Crontab stands for “cron table”. It allows using a job scheduler, which is known as cron to execute tasks.

Crontab is also the name of the program, which is used to edit that schedule. It is driven by a crontab file, a config file that indicates shell commands to run periodically for the specific schedule.

Reasons for using Cron jobs:

• Helps OS to take a scheduled backup of log files or database.
• Delete old log files
• Archive and purge database tables
• Send out any notification email such as Newsletters, Password expiration email
• Regular clean-up of cached data
• Crontab is an ideal option to automate Unix jobs.
• It is used to automate system maintenance

Crontab syntax:

MIN HOUR DOM MON DOW CMD

Ranges :

4. Read about User Management

User management includes everything from creating a user to deleting a user on your system.

root

The root user is the superuser and has all the powers for creating a user, deleting a user and can even login in with the other user’s account. The root user always has userid 0.

useradd

1. With useradd command, you can add a user.

Syntax: sudo adduser username [you should have the super user power to add a user]

Then Enter the password for the new account and confirm

You can check the newly added user from the file /etc/passwd

Command: cat /etc/passwd

2. For disabling an account using Terminal, remove the password set on the account.

sudo passwd -l ‘username’

3. To delete an account, use the command –

sudo userdel -r ‘username

5. Create 2 users and just display their Usernames

Added two users by using the useradd command :

$ sudo useradd Sam

$ sudo useradd Vinod

To display their name use cat /etc/passwd and redirected the output to the tail command to see only the last two lines from the file :

To display their name use cat /etc/passwd and redirected the output to the tail command to see only the last two lines from the file :

The post Day-5 Task – Advanced Linux Shell Scripting for DevOps Engineers with User Management appeared first on abdulrahmanuk.com.