The Problem

I attempted to mount an XFS partition using the following command:

sudo mount -t xfs /dev/sdm1 /mariadb/prddisk

However, I received the following error message:

mount: /mariadb/prddisk: wrong fs type, bad option, bad superblock on /dev/sdm1, missing codepage or helper program, or other error.

At first glance, this error could be due to several factors:

• Filesystem corruption

• Incorrect filesystem type

• Damaged superblock

• Missing system utilities for XFS

To investigate further, I used dmesg to check the kernel logs:

dmesg | grep sdm1

The output provided more specific information:

[9373848.668073] XFS (sdm1): Unmounting Filesystem cbcecfa4-54ad-48c3-9dbf-f7cc49151913
[9603307.038109] XFS (sdm1): Filesystem has duplicate UUID dce22b56-4bc9-48da-927a-72ce29c5dcff - can't mount

It turned out that the issue was a duplicate UUID in the XFS filesystem, which was preventing the system from mounting the partition.

Understanding the Error: Duplicate UUID in XFS

UUIDs (Universally Unique Identifiers) are intended to uniquely identify filesystems, allowing the operating system to reference partitions even when their underlying device names (e.g. /dev/sdm1) change. If two filesystems have the same UUID, this creates a conflict, and Linux refuses to mount the filesystem.

In this case, the dmesg logs clearly indicated that the partition's UUID (dce22b56-4bc9-48da-927a-72ce29c5dcff) was duplicated.

Solution Steps

1. Check the Filesystem UUID

To confirm the UUID, I used the blkid command:

sudo blkid /dev/sdm1

This confirmed that the UUID of the filesystem was indeed duplicated with another existing filesystem, which can happen if a disk was cloned or a snapshot was created without updating the UUID.

2. Change the Filesystem UUID

The easiest way to resolve this issue is by generating a new UUID for the filesystem using the xfs_admin tool:

sudo xfs_admin -U generate /dev/sdm1

This command generates a new UUID for the XFS partition, resolving the duplication issue.

3. Check for Filesystem Corruption

Before mounting the filesystem again, I decided to check for any corruption that might have occurred during previous mounting attempts. I used the xfs_repair utility:

sudo xfs_repair /dev/sdm1

If any corruption is found, xfs_repair will attempt to fix the issue. In my case, the filesystem was in good health. (You might need to use the -L flag to clear the log for the command to be successful)

4. Mount the Filesystem

After changing the UUID and ensuring the filesystem's integrity, I retried mounting the partition:

sudo mount -t xfs /dev/sdm1 /mariadb/prddisk

This time, the filesystem mounted successfully without any errors.

5. Updating /etc/fstab

If you have an entry for this partition in /etc/fstab, don't forget to update it with the new UUID. You can use blkid again to retrieve the new UUID and update /etc/fstab accordingly:

UUID=<new_uuid> /mariadb/prddisk xfs defaults 0 0

Handling "Bad Superblock" Errors

In some cases, the error message about a "bad superblock" might indicate that the filesystem's superblock is corrupted. If you suspect this, you can use the xfs_db tool to inspect the superblock:

sudo xfs_db -c "sb 0" -r /dev/sdm1

If the superblock is damaged, you can attempt to repair it using xfs_repair. Always ensure that the filesystem is unmounted before performing these operations.

Additional Workarounds

If you continue to encounter mounting issues due to the duplicate UUID error, you can try mounting the filesystem with the -o nouuid option. This option tells the system to ignore the UUID check temporarily, which might be useful for troubleshooting:

sudo mount -t xfs -o nouuid /dev/sdm1 /mariadb/prddisk

However, this is not a permanent solution and should only be used as a temporary workaround. After mounting, it's still important to address the UUID conflict.

Conclusion

XFS is a robust filesystem, but like any system, it can run into issues such as duplicate UUIDs or corruption. Fortunately, tools like xfs_repair and xfs_admin make it relatively easy to resolve these problems. By systematically checking for issues, repairing the filesystem, and generating a new UUID, I was able to resolve the duplicate UUID problem and successfully mount the partition.

If you're facing similar issues, I hope this guide helps you troubleshoot and resolve the problem. Always remember to back up important data before making changes to your filesystem!

GitHub Actions provides a powerful way to automate workflows in your repositories. By creating custom actions, you can encapsulate reusable workflows, scripts, and automation steps into a single unit.

In this article, we will walk through the steps of creating a custom GitHub Action (based on Docker), using a practical example of an action that checks the number of public repositories in the Microsoft Azure organization.

Step-by-Step Guide to Creating a Custom Action

Step 1: Create a New Repository

To get started, either create a new GitHub repository or navigate to an existing one where you want to create your custom action. The repository will contain all the necessary files for your action.

Step 2: Set Up the Directory Structure

Clone the repository for local development and begin to add files. Your repository should contain the following structure for the custom action:

my-github-action/
│
├── action.yml       # Metadata file
├── Dockerfile       # Docker configuration file
└── entrypoint.sh    # Script to execute inside the container

Step 3: Define Action Metadata in action.yml

The action.yml file defines the inputs, outputs, and execution environment of your custom action. Here’s an example:

name: 'Azure Repo Counter Action'
description: 'Fetches the public repository count for the Microsoft Azure GitHub organization'
inputs:
  my-input:
    description: 'A placeholder input value'
    required: true
    default: 'default value'
outputs:
  my-output:
    description: 'The number of public repositories'
runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - ${{ inputs.my-input }}

This file defines the name of the action, input parameters, and outputs. The runs section specifies that the action will be executed in a Docker container.

Step 4: Create the Dockerfile

The Dockerfile describes how to build the Docker image that will run the action. Here’s a simple example:

FROM ubuntu:20.04

RUN apt-get update && apt-get install -y \
  curl \
  jq

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]

In this file:

• We’re using an Ubuntu base image.

• Installing curl to make HTTP requests and jq to process JSON data.

• Copying and setting permissions for the entrypoint.sh script.

Step 5: Write the Action Logic in entrypoint.sh

The entrypoint.sh script will be executed when the action runs. In this case, it fetches the number of public repositories for the Microsoft Azure GitHub organization and sets the value as an output.

#!/bin/bash

# Get the input value
MY_INPUT=$1

# Fetch public repositories from the Microsoft Azure organization using GitHub API
DATA=$(curl -s https://api.github.com/orgs/Azure)

# Use jq to parse the data and get the public repository count
REPO_COUNT=$(echo "$DATA" | jq '.public_repos')

# Output the number of public repositories
echo "Microsoft Azure organization has $REPO_COUNT public repositories"

# Set an output variable using the environment file method (Optional)
echo "my-output=$REPO_COUNT" >> "$GITHUB_ENV"

This script fetches data from the GitHub API, processes it using jq, and then uses the GITHUB_ENV file to pass the result to the workflow.

Step 6: Push Your Action to GitHub

Once everything is set up, push your changes to the repository:

git add .
git commit -m "Add custom Docker GitHub Action"
git push origin main

Step 7: Use the Action in a Workflow

To use your custom action, create a new workflow file in the .github/workflows/ directory. Here’s an example workflow:

name: Example Workflow

on: [push]

jobs:
  my-job:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Run Azure Repo Counter Action
        uses: ./  # Uses the custom action in the same repository
        with:
          my-input: "Fetching Azure repositories"

      - name: Print output
        run: echo "Public repositories in Microsoft Azure: ${{ env.my-output }}"

This workflow will:

1. Checkout the repository code.

2. Execute your custom action.

3. Output the number of public repositories in the Microsoft Azure organization.

Step 8: Trigger the Workflow

Push changes to your repository, and GitHub Actions will automatically trigger the workflow. You can view the workflow’s execution in the "Actions" tab and see how your custom action performs.

Conclusion

By following this guide, you’ve created a reusable GitHub Action that runs in a Docker container, fetches data from the GitHub API, and returns a result to your workflow. You can expand this approach to create more sophisticated actions, integrate with other APIs, or automate any part of your DevOps pipelines. Container actions provide great flexibility, as they allow you to run any tool or script in a controlled environment.

Starting with High Resource Allocations and Adjusting Downwards

Starting with higher resource allocations and gradually reducing them can be an effective strategy, particularly for performance-critical applications where you need to guarantee optimal performance from the outset. Here’s why:

Pros:

1. Immediate Performance Validation:

   • By allocating ample resources from the start, you ensure that your application operates at its peak performance, minimizing the risk of initial performance bottlenecks. This approach allows you to quickly validate whether your application meets its performance goals under ideal conditions.

2. Identifying Over-Provisioning:

   • With high resources allocated, you can identify areas where resources are being over-provisioned. This helps you pinpoint the optimal resource levels that maintain performance while avoiding unnecessary overhead.

3. Avoiding Initial Performance Issues:

   • Under-provisioning can lead to performance degradation or application crashes during testing, which may obscure other issues or skew your testing results. Starting with high resources prevents these problems and provides a clearer picture of your application’s behavior under load.

Cons:

1. Potential Resource Waste:

   • High initial allocations may lead to resource wastage, as you might be allocating more than what’s necessary for your application to perform effectively. This can be misleading when evaluating cost efficiency.

2. Longer Optimization Process:

   • Gradually reducing resources requires careful monitoring and multiple testing iterations to ensure performance remains stable. This can make the optimization process more time-consuming.

Starting with Low Resource Allocations and Adjusting Upwards

Alternatively, beginning with lower resource allocations and increasing them as needed can be a more cost-efficient approach, particularly for applications where budget considerations are paramount.

Pros:

1. Cost-Efficiency from the Start:

   • Starting with minimal resources allows you to see the lowest possible cost for running your application. You only scale up resources when necessary, helping you understand the minimum viable configuration for your application.

2. Stress Testing Early:

   • This approach helps you identify the minimum resource requirements needed to maintain acceptable performance. By starting with less, you can stress test your application and determine its lower bounds, providing valuable insights into its resilience and efficiency.

3. Clear Resource Boundaries:

   • As you incrementally increase resources, you can pinpoint the exact threshold where your application begins to perform optimally. This clarity is crucial for fine-tuning and ensuring you’re not over-allocating resources.

Cons:

1. Risk of Performance Bottlenecks:

   • Starting with low resources might cause the application to underperform or even crash, which could complicate the initial stages of testing. These issues might be misinterpreted as application faults rather than resource limitations.

2. Slower Performance Validation:

   • It may take longer to reach a configuration that meets your performance needs, as you’ll need to incrementally test and adjust resources, potentially prolonging the testing phase.

Which Approach is Better?

The choice between starting high and adjusting downwards or starting low and adjusting upwards depends on your application’s specific needs:

• For Performance-Critical Applications: If ensuring optimal performance is your top priority and you want to avoid any potential disruptions, starting with high resources and adjusting downwards is generally the better approach. This strategy ensures that you start with the best possible performance and only scale down to find the most cost-effective allocation that still meets your performance requirements.

• For Cost-Sensitive Applications: If cost efficiency is more critical, and you’re comfortable with the possibility of encountering some initial performance issues, starting with low resources and adjusting upwards can be more effective. This approach allows you to identify the minimum resource allocation required to achieve satisfactory performance, thereby optimizing your costs.

A Hybrid Approach: Finding Balance

In practice, a hybrid approach often provides the best balance between performance and cost efficiency:

• Start with a Reasonable Baseline: Begin with a resource allocation that you estimate is close to what your application might need. This baseline could be informed by previous experience, application profiling, or educated guesses.

• Test and Adjust: Monitor performance carefully and adjust resources in the appropriate direction—upwards if performance is lacking, or downwards if resources seem over-allocated.

This hybrid method allows you to fine-tune your resource allocations efficiently, ensuring your application performs well while maintaining cost-effectiveness.

Conclusion

When it comes to resource allocation for performance testing, there’s no one-size-fits-all approach. Whether you start with high resources and adjust downwards or begin with low allocations and scale up, the key is to align your strategy with your application’s performance requirements and cost constraints. By considering the pros and cons of each method—and potentially adopting a hybrid approach—you can optimize both performance and resource utilization, ensuring your application runs smoothly and efficiently.

Previously, RBAC only granted access to a Key Vault's management plane and access policies were needed if a user needed to access the data plane. While this helped prevent the arbitrary access that RBAC's heirarchical nature could have granted to sensitive data, it has been found that this approach does not scale well as the number of Key Vaults increase. The reality is that most organisations will have a few tens to hundreds of key vaults and having to manage access policies across these key vaults per user any time there is a change in circumstances can be a nightmare. Thankfully, Microsoft subsequently introduced the RBAC model which has greatly improved how key vault access is managed

In this blog post, we will explore the need to convert from the traditional "Access Policy" model to the more recent "Role-Based Access Control" (RBAC) authorization model. We will also outline the essential steps involved in this conversion process.

The Need for Conversion

While the Access Policy model has served as a solid foundation for managing access to Azure Key Vault, the RBAC authorization model brings a host of benefits that align with modern cloud security requirements. Here are a few reasons why you should consider migrating from the Access Policy model to RBAC:

1. Centralized Access Management: RBAC enables centralized management of permissions across multiple Azure resources, making it easier to maintain consistency and control access more efficiently.

2. Granular Control: RBAC allows for fine-grained control by assigning roles at the subscription, resource group, or individual resource level. This granular control enables precise access management tailored to the specific needs of different teams or individuals.

3. Segregation of Duties: With RBAC, you can separate responsibilities by assigning different roles to different individuals or teams. This segregation of duties enhances security by preventing conflicts of interest and reducing the risk of unauthorized access.

4. Auditing and Compliance: RBAC provides detailed audit logs, allowing you to track and monitor access requests, changes in permissions, and other security-related activities. This feature aids in meeting regulatory requirements and enhancing overall compliance.

Steps for Conversion

Step 1: Evaluate Access Policies: Review the existing access policies defined within the Azure Key Vault. Identify the roles and permissions assigned to various users or applications. This assessment will help in mapping the current access policies to RBAC roles accurately.

To get the access policies across several key vaults, you could run this powershell script to grab all the access policies and dump them in a CSV file that you can use for analysis and role mappings.

$outputFile = @()

get-Azsubscription | Where-Object {$_.State -eq "Enabled"} | ForEach-Object {
    Set-AzContext $_ 

    $vaultNames = (Get-AzKeyVault).VaultName

    foreach ($vaultName in $vaultNames) {
        $accessPolicies = (Get-AzKeyVault -VaultName $vaultName).AccessPolicies

        foreach ($policy in $accessPolicies) {
            $properties = "" | Select-Object Subscription, vaultName, oID, DisplayName
            $properties.oID = $policy.ObjectId
            $properties.DisplayName = $policy.DisplayName
            $properties.Subscription = $_.Name
            $properties.VaultName = $vaultName

            $outputFile += @($properties)
        }
    }
}

$outputFile | Select-Object Subscription, vaultName, oID, DisplayName | Export-Csv -NoTypeInformation "kvIDs.csv"

Step 2: Define RBAC Roles: Determine the RBAC roles that align with the access requirements of your organization. Azure provides several built-in roles for Key Vaults like Key Vault Administrator, Key Vault Reader, Key Vault Secrets User, and many more. Additionally, custom roles can be created to suit specific needs. Assigning roles based on job responsibilities and required access levels ensures a more secure and manageable access control system. The Microsoft docs contain some recommended access policy to RBAC role mappings.

Step 3: Assign RBAC Roles: Once the RBAC roles have been defined, assign them to the appropriate users or groups. This can be done at the subscription, resource group, or individual Key Vault level, depending on the desired level of control. Again, for organisations with lots of Key Vault, a step like this will have to be automated. The following is a sample powershell script that can be used to create RBAC role assignments across multiple Key Vaults

$subs = Get-AzSubscription | Where-Object { $_.State -eq "Enabled" } | Sort-Object Name # You can add other filters as you wish

foreach ($sub in $subs) {
    $subID = $sub.Id
    $subName = $sub.Name
    set-azcontext -SubscriptionId $subID

    write-host "Subscription: $subName"

    $vaultNames = (Get-AzKeyVault).VaultName

    foreach ($vaultName in $vaultNames) {
        write-host "Getting Access Policies for Sub"
        $accessPolicies = (Get-AzKeyVault -VaultName $vaultName).AccessPolicies
        $kvRG = (Get-AzKeyVault -VaultName $vaultName).ResourceGroupName

        foreach ($policy in $accessPolicies) {
            #Check if the role assignment already exists
            $getRBAC = Get-AzRoleAssignment `
                -ObjectId $policy.ObjectId `
                -RoleDefinitionName "Key Vault Secrets User" `
                -Scope "/subscriptions/$subID/resourceGroups/$kvRG/providers/Microsoft.KeyVault/vaults/$vaultName"
            If ($null -eq $getRBAC) {
                Write-Host "KV Role does not Exist. Creating Role Assignment"

                New-AzRoleAssignment `
                    -ObjectId $policy.ObjectId `
                    -RoleDefinitionName "Key Vault Secrets User" `
                    -Scope "/subscriptions/$subID/resourceGroups/$kvRG/providers/Microsoft.KeyVault/vaults/$vaultName"
            }
            else {
                write-host "KV Role Assignment Already Exists"
            }

        }

    }
}

To actually convert your Key Vaults to the RBAC permission model, you can run the following powershell script:

$subs = Get-AzSubscription | Where-Object { $_.State -eq "Enabled" } | Sort-Object Name # You can add other filters as you wish

foreach ($sub in $subs) {
    set-azcontext -SubscriptionId ($sub).Id

    $kvNames = (Get-AzKeyVault).VaultName

    foreach ($kvName in $kvNames) {
        Write-Host "Converting $kvName to RBAC Permission Model" -ForegroundColor Green
        $kvRG = (Get-AzKeyVault -VaultName $kvName).ResourceGroupName

        Update-AzKeyVault -VaultName $kvName -ResourceGroupName $kvRG -EnableRbacAuthorization $true        
    }
}

Step 4: Remove Access Policies: As RBAC roles are assigned, gradually remove the existing access policies from Azure Key Vault.

Warning: Ensure that all necessary permissions have been properly mapped and assigned to the appropriate RBAC roles before removing the access policies to prevent any unintended access gaps!

Step 5: Test and Validate: Thoroughly test the new RBAC-based access control configuration to ensure that all required operations can be performed by the assigned roles. Validate that the access control changes do not disrupt any existing applications or workflows.

Step 6: Monitor and Maintain: Regularly review and update RBAC assignments to accommodate any changes in personnel or access requirements. Monitor access logs and regularly audit permissions to ensure ongoing compliance and security.

Conclusion

In the ever-changing landscape of cloud security, it is essential to adapt and implement advanced access control mechanisms. By transitioning from the traditional Access Policy model to the RBAC authorization model in Azure Key Vault, you can achieve greater control, segregation of duties, and auditing capabilities. With careful planning and execution of the outlined steps, you can ensure a smoother migration and strengthen the security of your sensitive data. The RBAC authorization model provides a robust framework for managing permissions across Azure resources, enabling you to streamline access control and mitigate potential security risks.

Remember, before starting the conversion process, it is crucial to thoroughly assess your organization's access requirements and consult with your security and compliance teams to ensure a seamless transition. With proper planning and execution, converting your Azure Key Vault from the Access Policy model to the RBAC authorization model can enhance your overall security posture and protect your valuable assets effectively.

Apart from this you will also want the ability to run scripts against them quickly and without having to log in and log out of accounts each time or moving between separate devices.

The context management cmdlets in Azure are a fantastic way to solve this problem and make your life easier.

To connect to one or more Azure Accounts, run the following command each time and provide your credentials for each of the accounts.

Connect-AzAccount -TenantId

Usually when the account contains multiple subscriptions, one subscription is chosen as the context at the beginning. You can use get-AzContext to get the current context. You can also use (get-AzContext).Name which will show you the context's name only. This useful when the name is long and the display gets truncated in powershell.

get-AzContext

(get-AzContext).Name #Display context name only.

To use another subscription as the current context, use the following command(s):

set-AzContext -subscriptionId <subscriptionID for your sub>

You can give this new context a name directly by providing a value for the name parameter. e.g.

Set-AzContext -SubscriptionId <subscriptionID for your sub>  -Name 'DevSub'

# This command will also give the context a memorable name
Get-AzSubscription -SubscriptionName 'MySubscriptionName' | Set-AzContext -Name 'MyContextName'

Use the following command to rename the context to something more memorable/easy to type

Rename-AzContext -SourceName <Name of your subscription> -TargetName <memorableName>

# Change 'ISRXL' to characters contained in your subscription's name

$sourceName = (get-AzContext -ListAvailable | where-object {$_.Name -like '*ISRXL*'}).name

Rename-AzContext -SourceName $sourceName -TargetName 'PersonalSub'

After renaming the contexts, use the get-AzContext -ListAvailable command again to see the Azure contexts available to you in powershell.

To use the contexts after they have been renamed to simpler, memorable names:

select-AzContext 'PersonalSub'

You can also save these context settings to a file:

# Save-AzContext -Path <path-to-folder-you-choose>
Save-AzContext -Path "C:\Users\Isrxl\Documents\AzureContext.json

Once the context settings have been saved to a file, they can be imported into another powershell session as follows:

Import-AzContext -Path "C:\Users\Isrxl\Documents\AzureContext.json

It is important to develop the habit of checking and switching your azure context before running any commands or scripts. In fact, I think it is a good practice to ensure that the first few lines of your scripts/script blocks checks that the right context is being used.

Useful Links:

https://docs.microsoft.com/en-us/powershell/azure/context-persistence?view=azps-7.3.2
https://docs.microsoft.com/en-us/powershell/module/az.accounts/clear-azcontext?view=azps-7.3.2
https://docs.microsoft.com/en-us/powershell/module/az.accounts/disconnect-azaccount?view=azps-7.3.2

Headings

Headings in markdown are created by starting with one or more hash (#) characters. Depending on the heading type, the number of hashes (#) can range between 1 (for H1 or main headings) and 6 (for smaller headings, a.k.a subheadings). The title (markdown shenanigans) is an example of an H1 (#) heading.
To view other headings and see the difference between them, check the list below:

Markdown Syntax:

# Heading 1 (H1) 
## Heading 2 (H2) 
### Heading 3 (H3) 
#### Heading 4 (H4) 
##### Heading 5 (H5) 
###### Heading 6 (H6)

Result:

Heading 1 (H1)

Heading 2 (H2)

Heading 3 (H3)

Heading 4 (H4)

Heading 5 (H5)

Heading 6 (H6)

Making Emphasis with italics or bold…

Emphasizing a word or sentence can be done by adding at least one asterisk (*) at each end of that word or sentence.

*One asterisk at each end italicizes your words.*
**Two asterisks at each end make your words bold** 
***Three asterisks at each end make your words bold and italicized***

One asterisk at each end italicizes your words.
Two asterisks at each end make your words bold
Three asterisks at each end make your words bold and italicized

Creating (Block) Quotes

To create block quotes, you need to indent each line using a right-angle bracket (>) or what mathematicians would call a "greater than" symbol. Additional angle brackets create inner block quotes.

> ***This is a block quote in italics and bold***
>> This is an inner block quote\
I did this just because I can\
and also because I like it
>>> I can even try an inner-inner block quote\
That's how we stars do it
>>>> Now keep your complaints to yourself :p

This is a block quote in italics and bold

This is an inner block quote
I did this just because I can
and also because I like it

I can even try an inner-inner block quote
That's how we stars do it

Now keep your complaints to yourself :p

Now let us try lists:

Creating a random unordered list…

* Apples
* Oranges
* Pears
- One
- Two
- Three
+ First
+ Second
+ Third

• Apples

• Oranges

• Pears

• One

• Two

• Three

• First

• Second

• Third

and now a random ordered list…

1. Number one
2. Number two
3) Number three
4) Number four

1. Number one

2. Number two

3. Number three

4. Number four

We can also create nested lists like…

* Fruits  
    1. Oranges
    2. Pears
    3. Apples

* Numbers  
    - One
    - Two  
    - Three

• Fruits

  1. Oranges

  2. Pears

  3. Apples

• Numbers

  • One

  • Two

  • Three

In both cases, we need to indent at least 2 spaces on the next line to create a nested list.

Let's see how a link looks like:

[My first Blog Post](https://www.isrxl.com/i-came-i-blogged-i-conquered/)  
[Check out isrxl blog][id]

[id]: isrxl.com "title"

<https://isrxl.com>

My first Blog Post
Check out isrxl blog

https://isrxl.com

Get a picture

![Nice Picture](https://unsplash.com/?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit)

How do we write code blocks?

This is probably my favourite use of markdown. When I was still trying to create my web pages from scratch, I was having a hard time displaying code snippets in the way most tech professionals would like when reading a tech article. Once I saw how easy it was in markdown, I quickly dumped HTML/CSS/JS (for now at least).

Code blocks can be created by indenting the line (pressing the tab key) four (4) times in markdown before writing the code

                get-AzResourceGroup
                get-AzContext

            get-AzResourceGroup
            get-AzContext

Another way to create code blocks is by starting a new line with the backtick character three (3) times and optionally following it with the code language. After this, you can write your line/block of code on a new line. Once you are done you can end the code block by using the backtick character three (3) times on a new (and final) line... Like in the code example below:

```powershell
get-service
```

get-service

You can also write code in markdown as inline code. For example,

Inline code: `get-AzContext`, another example is `1 + 5 = 6`.

Inline code: get-AzContext, another example is 1 + 5 = 6.

Closing Remarks

Once you get the hang of it, the markdown language makes authoring technical documentation quite easy and enjoyable.

To create markdown files, you can simply use a plain text editor like notepad or notepad++. If you like to create markdown files and also enjoy the use of some custom plugins like live visualization, Visual Studio Code should be your go-to tool.

If you would also like to play around with markdown, you can check the following sites for good examples:

Getting started with Markdown

Markdown Tutorial

CommonMark Website

Happy "markdowning' or is it Happy "markingdown"?

Enjoy.

I had wanted to start this blog a long time ago (as far back as the beginning of 2022) but I got in my way by overthinking a lot of things. First, I spent an inordinate amount of time wondering how the blog would be received. Then I agonized for an even greater amount of time about what I would be writing about. Most laughable was how I was determined to do it in a "special way". I started out wanting to "build my site from scratch" and even started taking web development courses, but then I quickly realized that if I was going to wait till I finished the courses before launching the blog I might have to wait till 2023 at the earliest. Then I played around with "Hugo" for a while before finally coming to the realization that all I have been doing was digging myself down a rabbit hole with nothing to show for it (actually I had some help reaching this point of clarity, I got great advice from people like Ayo Oladejo, Jorge Arteiro and Robin Smorenburg). So I decided to chuck all the distractions and face my actual goal of blogging.

And here I am. Blogging.

So while this is definitely not a technical blog post, it was my way of overcoming the initial resistance and getting the ball rolling. You know how they say, "the first step is always the most important" or that "it doesn't have to be perfect, it just has to get done", "do it afraid" etc etc...

Now that I have my first post out of the way, I hope that this journey I have started will gather momentum and that this blog will be of immense benefit to me and everyone who reads my posts.

Welcome to my blog!