Saturday, January 21, 2023

CloudFlare Page Rules 101: Understanding and Implementing Redirects

Redirecting your website to a secure HTTPS connection is a crucial step in ensuring the security and privacy of your website visitors. However, this can become tricky when dealing with different subdomains, such as the "www" subdomain. One way to do this is by using CloudFlare Page Rules to redirect all HTTP traffic to HTTPS Or all non-www to www with HTTPS

In this blog post, I will show you how to set up redirects using CloudFlare Page Rules for couple of different scenarios:

  1. Redirecting all traffic from http://sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1
  2. Redirecting all traffic from https://sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1
  3. Redirecting all traffic from http://www.sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1
  4. Redirecting all traffic of a sub-domain from http://blog.sunilcloudops.blogspot.com/* to https://sunilcloudops.blogspot.com/$1
  5. Redirecting all traffic of a sub-domain from http://blog.sunilcloudops.blogspot.com/* to https://sunilnewdomain.com/$1 - (external domain)

Before we begin, make sure that your website is set up with a valid SSL certificate and that it is active on CloudFlare.

  • Redirecting all traffic from http://sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1

    To redirect all traffic from non-www http to https://www, follow these steps:
    • Log in to your CloudFlare account
    • Select the website you want to redirect
    • Click on the "Page Rules" tab
    • Click on the "Create Page Rule" button
    • In the "If the URL matches" field, enter "http://sunilcloudops.blogspot.com/*"
    • In the "Then the settings are" field, select "Forwarding URL"
    • In the "Status code" field, select "301 - Permanent Redirect"
    • In the "Redirect URL/Destination URL" field, enter "https://www.sunilcloudops.blogspot.com/$1"
    • Click on the "Save and Deploy" button






  • Redirecting all traffic from https://sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1































  • Redirecting all traffic from http://www.sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1


  • Redirecting all traffic of a sub-domain from http://blog.sunilcloudops.blogspot.com/* to https://sunilcloudops.blogspot.com/$




  • Redirecting all traffic of a sub-domain from http://blog.sunilcloudops.blogspot.com/* to https://sunilnewdomain.com/$1 - (external domain)



Thanks for reading, CloudOps Signing Off! 😊

        


Installing a Specific version of Node.js and npm in Azure DevOps pipeline

Node.js is a popular JavaScript runtime that allows developers to build server-side applications using JavaScript. npm is the default package manager for Node.js, and it is used to install and manage packages for Node.js projects.

When building Node.js projects, it is often necessary to specify a specific version of Node.js and npm to be used for the build and release process. This ensures that the same version of the tools is used across all environments and prevents compatibility issues. 

This can be done using the Node Version Manager (nvm) or the Node.js installer.

Using Node.js installer:

You can install a specific version of Node.js and npm by using the Node.js tool installer task in Azure DevOps. You can add the task to your pipeline yaml file and configure it to install the desired version of Node.js and npm:











This will install version 14.18.1 of Node.js and version 6.14.15 of npm on the build agent. you can use the following command to check the version:
  • node -v
  • npm -v

If you want to install a specific version of npm instead of using the version installed by NodeTool you can use below PowerShell command into your pipeline after above task.













This will install version 7.14.0 of npm on the build agent.


Using nvm:

nvm is a command-line tool that allows you to easily install and manage multiple versions of Node.js. To install nvm, you can use the following command in your pipeline yaml file:










Once nvm is installed, you can use it to install a specific version of Node.js in your pipeline yaml file using below:















This will install version 14.18.1 of Node.js and set it as the default version for the pipeline.

You can also install a specific version of npm in your pipeline yaml file using below:













This will install version 7.14.0 of npm.

In conclusion, you can install a specific version of Node.js and npm in Azure DevOps by using the Node Version Manager (nvm) or using the Node.js tool installer task in a pipeline. 


Thanks for reading, CloudOps Signing Off! 😊














Saturday, January 14, 2023

Creating a Self-Signed Certificates for Secure Connections

Self-signed certificates can be used to secure web connections, encrypt data sent over the internet, and can be used to authenticate the identity of the server to the client. In this blog post, we will cover the basics of self-signed certificates, how to create them, and how to use them to secure your web connections.

Creating a Self-Signed Certificate

There are several ways to create a self-signed certificate, but in this blog post, we will cover two popular methods: using mkcert and using PowerShell in-built (New-SelfSignedCertificate) cmdlet.

Method 1: Using mkcert

mkcert is a simple command-line tool that can be used to create a self-signed certificate. To create a self-signed certificate using mkcert, you can use script at and can run on PowerShell.













# Execute it on Powershell ./Generate-SelfSignedCertificate-mkcert.ps1
$hostName = "kb.sunilcloudops.com"
$ErrorActionPreference = "Stop";
##################################
# Configure TLS/HTTPS certificates
##################################
Write-Host "Generating Certificates ..." -ForegroundColor Green
try {
$mkcert = ".\mkcert.exe"
if ($null -ne (Get-Command mkcert.exe -ErrorAction SilentlyContinue)) {
# mkcert installed in PATH
$mkcert = "mkcert"
} elseif (-not (Test-Path $mkcert)) {
Write-Host "Downloading and installing mkcert certificate tool..." -ForegroundColor Green
Invoke-WebRequest "https://github.com/FiloSottile/mkcert/releases/download/v1.4.1/mkcert-v1.4.1-windows-amd64.exe" -UseBasicParsing -OutFile mkcert.exe
if ((Get-FileHash mkcert.exe).Hash -ne "1BE92F598145F61CA67DD9F5C687DFEC17953548D013715FF54067B34D7C3246") {
Remove-Item mkcert.exe -Force
throw "Invalid mkcert.exe file"
}
}
#Write-Host "Remove old TLS certificate..." -ForegroundColor Green
#Get-ChildItem -Path . -Include tls.crt -File -Recurse | foreach { $_.Delete()}
#Get-ChildItem -Path . -Include tls.key -File -Recurse | foreach { $_.Delete()}
Write-Host "Generating TLS certificate..." -ForegroundColor Green
& $mkcert -install
& $mkcert -cert-file D:\Install\tls.crt -key-file D:\Install\tls.key "*.$($hostName)"
#& $mkcert -key-file key.pem -cert-file cert.pem "*.$($HostName).localhost"
}
catch {
Write-Host "An error occurred while attempting to generate TLS certificate: $_" -ForegroundColor Red
}
finally {
Pop-Location
}
Write-Host "Done!" -ForegroundColor Green

Once you run the script it will first download the mkcert.exe if not exist, and using that will create the Self-Signed Certificate. 









Your directory will looks like below:















Method 2: Using PowerShell

Another way to create a self-signed certificate is by using PowerShell in-built 'New-SelfSignedCertificate' cmdlet. Here is an example of how to use this cmdlet to create a self-signed certificate:

Option 1: Creating a DNS based self-signed certificate









$workingFolder = "D:\Install"
$dnsNames = @("sunilcloudopsvm01","localhost","sunilcloudops.com")
$certFriendlyName = "Sitecore - Solr SelfSigned SSL Certificate"
$certPassword = "secret"
Write-Host "Looking for certificate $certFriendlyName"
$cert = Get-ChildItem -Path Cert:\LocalMachine\Root | where { $_.FriendlyName -eq $certFriendlyName }
if( $cert -eq $null )
{
$cert = New-SelfSignedCertificate -Subject $certFriendlyName -FriendlyName $certFriendlyName -DnsName $dnsNames -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(10)
Write-Host "Created certificate $($cert.Thumbprint)"
Move-Item "cert:\LocalMachine\my\$($cert.Thumbprint)" "cert:\LocalMachine\Root"
Write-Host "Moved cert to trusted store"
$cert = Get-Item "cert:\LocalMachine\Root\$($cert.Thumbprint)"
}
else
{
Write-Host "Found certificate $($cert.Thumbprint)"
}
$certStore = "$workingFolder\solr-ssl.keystore.pfx"
$certPwd = ConvertTo-SecureString -String $certPassword -Force -AsPlainText
$cert | Export-PfxCertificate -FilePath $certStore -Password $certpwd | Out-Null
Write-Host "Exported Cert to $certStore"

This command will create a self-signed certificate for the different hostnames and store it in the local certificate store.

Option 2: Creating a DNS + IP Address based self-signed certificate














$workingFolder = "D:\Install"
$dnsNames = "DNS=sunilcloudopssolr01&DNS=localhost"
$ip = "IPAddress=10.0.0.1&IPAddress=127.0.0.1"
$certFriendlyName = "Solr SelfSigned SSL Certificate"
$certPassword = "hmmmmmm"
Write-Host "Looking for certificate $certFriendlyName"
$cert = Get-ChildItem -Path Cert:\LocalMachine\Root | where { $_.FriendlyName -eq $certFriendlyName }
if( $cert -eq $null )
{
$cert = New-SelfSignedCertificate -Subject $certFriendlyName -FriendlyName $certFriendlyName -TextExtension @("2.5.29.17={text}$ip&$dnsNames") -CertStoreLocation "cert:\LocalMachine\My" -KeyAlgorithm RSA -KeyLength 2048 -NotAfter (Get-Date).AddYears(10)
Write-Host "Created certificate $($cert.Thumbprint)"
Move-Item "cert:\LocalMachine\my\$($cert.Thumbprint)" "cert:\LocalMachine\Root"
Write-Host "Moved cert to trusted store"
$cert = Get-Item "cert:\LocalMachine\Root\$($cert.Thumbprint)"
}
else {Write-Host "Found certificate $($cert.Thumbprint)"}
$certStore = "$workingFolder\solr-ssl.keystore.pfx"
$certPwd = ConvertTo-SecureString -String $certPassword -Force -AsPlainText
$cert | Export-PfxCertificate -FilePath $certStore -Password $certpwd | Out-Null
Write-Host "Exported Cert to $certStore"
Write-Host ''
Write-Host '2. Add the following lines to your solr.in.cmd:' -ForegroundColor Green
Write-Host ''
Write-Host "set SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.pfx" -ForegroundColor Yellow
Write-Host "set SOLR_SSL_KEY_STORE_PASSWORD=$certPassword" -ForegroundColor Yellow
Write-Host "set SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.pfx" -ForegroundColor Yellow
Write-Host "set SOLR_SSL_TRUST_STORE_PASSWORD=$certPassword" -ForegroundColor Yellow
Write-Host ''
Write-Host 'Done!'

This command will create a self-signed certificate for couple of domains and IP addresses and store it in the local certificate store.

If you want to have the Signer for the Self-Signed certificate then you can first generate the root  certificate and then pass that root certificate while creating the other Self-Signed certificate.

$rootCert = New-SelfSignedCertificate -Subject 'CN=TestRootCA,O=TestRootCA,OU=TestRootCA' -KeyExportPolicy Exportable -KeyUsage CertSign,CRLSign,DigitalSignature -KeyLength 2048 -KeyUsageProperty All -KeyAlgorithm 'RSA' -HashAlgorithm 'SHA256' -Provider 'Microsoft Enhanced RSA and AES Cryptographic Provider'

New-SelfSignedCertificate -Subject $certFriendlyName -FriendlyName $certFriendlyName -Signer $rootCert -TextExtension @("2.5.29.17={text}$ip&$dnsNames") -CertStoreLocation "cert:\LocalMachine\My" -KeyAlgorithm RSA -KeyLength 2048 -NotAfter (Get-Date).AddYears(10)


Note: Self-signed certificates are not trusted by default and will not be recognized by default trusted root CA, so it is important to inform users that they are visiting a self-signed certificate website.


Thanks for reading, CloudOps 
Signing Off! 😊


Saturday, January 7, 2023

Building Visual Studio Solutions with MSBuild - Command Line

 MSBuild is a powerful build tool that is included with Visual Studio. It can be used to build Visual Studio solutions and projects from the command line or from scripts, making it easy to automate builds and deployments.

To build a Visual Studio solution using MSBuild, you can use the following command:

msbuild location: C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\msbuild.exe






msbuild "D:\a\1\s\solution.sln" /t:Build /p:Configuration=Release /p:platform="any cpu"

You can also specify a specific project within the solution to build by using the /target parameter:







msbuild "D:\a\1\s\solution.sln" /t:Build /p:Configuration=Release /p:platform="any cpu" /target:cms.proj

To generate deployment artifacts for a web project using MSBuild, you can use the 'WebPublish' target. This will build the project and create the necessary files for deployment to a web server.

Here's an example of the command to generate deployment artifacts for a web project:







msbuild "D:\a\1\s\solution.sln" /t:WebPublish /p:Configuration=Release /p:platform="any cpu" /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:DeployDefaultTarget=WebPublish /p:DeleteExistingFiles=True /p:publishUrl="D:\a\1\s\outdir"

Alternatively, you can specify the OutDir property to specify the output directory for the build artifacts. This can be used in conjunction with the 'Build' target to generate the necessary files for deployment.






msbuild "D:\a\1\s\solution.sln" /t:Build /p:Configuration=Release /p:platform="any cpu" /p:DeployOnBuild=false /p:SkipInvalidConfigurations=true /p:OutDir="D:\a\1\s\outputdirectory"

You can also specify additional parameters, such as /p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false /p:VisualStudioVersion="15.0" /v:diag to customize the build process.

Alternatively, you can generate a deployment package by using the 'WebPublish' target with the 'Package' publish method:







msbuild "D:\a\1\s\solution.sln" /t:WebPublish /p:Configuration=Release /p:Platform="any cpu" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\website\\"

This will build the project and create a deployment package using the specified settings. The 'PackageAsSingleFile' parameter specifies that the package should be created as a single file, and the 'SkipInvalidConfigurations' parameter specifies that the build should continue even if there are invalid project configurations. The 'PackageLocation' parameter specifies the directory where the package should be created.

To enabled verbose logging add below parameter to command line:

/v:diag


Thanks for reading, CloudOps Signing Off! 😊


Azure Login 101: Command Line Options

There are a few different ways that you can log in to the Azure portal using the command line:

  1. Install the Azure CLI or Azure PowerShell module on your local machine, if it is not already installed. 
  2. Use the 'az login' command (for the Azure CLI) or the 'Connect-AzAccount' cmdlet (for the Azure PowerShell module) to log in to Azure.
  3. Use the '--tenant' option (for the Azure CLI) or the '-TenantId' parameter (for the Azure PowerShell module) to specify the tenant (i.e., the Azure Active Directory) that you want to use.
  4. Use the '--subscription' option (for the Azure CLI) or the '-SubscriptionId' parameter (for the Azure PowerShell module) to specify the subscription that you want to use.
  5. Use the 'az account show' command (for the Azure CLI) or the 'Get-AzContext' cmdlet (for the Azure PowerShell module) to display the details of the currently selected tenant and subscription.

  • Azure CLI: The Azure CLI is a cross-platform command-line interface that you can use to manage Azure resources. To log in to the Azure portal using Azure CLI, follow these steps:
# Install the Azure CLI (if it is not already installed)
Invoke-WebRequest -Uri https://aka.ms/installazurecliwindows -OutFile .\AzureCLI.msi; Start-Process msiexec.exe -Wait -ArgumentList '/I AzureCLI.msi /quiet'; rm .\AzureCLI.msi  

 # Log in to Azure and set the default tenant and subscription (replace <tenant-id> and <subscription-id> with the appropriate values)

az login --tenant <tenant-id>

          az account set --subscription <subscription-id>

# Display the details of the currently selected subscription
az account show

This script first installs the Azure CLI, then logs in to Azure and sets the default tenant and subscription using the az login command. It then displays the details of the currently selected subscription using the az account show command.

If you only use 'az login' command then use the 'az account set --tenant' and  'az account set --subscription' command to switch between the tenants and subscriptions.

 

  • PowerShell: This is a command-line shell and scripting language that you can use to manage Azure resources. To log in to the Azure portal using the Azure PowerShell module on a Windows machine:, follow these steps:
# Install the Azure PowerShell module (if it is not already installed)
Install-Module -Name Azure -AllowClobber
# Log in to Azure and set the default tenant and subscription (replace <tenant-id> and <subscription-id> with the appropriate values)
Connect-AzAccount -Tenant <tenant-id> -SubscriptionId <subscription-id>

         Set-AzContext -Tenant <tenant-id> -SubscriptionId <subscription-id> 

# Display the details of the currently selected subscription
Get-AzContext


This script first installs the Azure PowerShell module, then logs in to Azure and sets the default tenant and subscription using the Connect-AzAccount cmdlet. It then displays the details of the currently selected subscription using the Get-AzContext cmdlet.

If you only use 'Connect-AzAccount' command then use the 'Connect-AzAccount -TenantId <tenant-id>' and  'Connect-AzAccount -SubscriptionId <subscription-id>' command to switch between the tenants and subscriptions.

 

  • Azure Cloud Shell: This is a browser-based shell that you can use to manage Azure resources. To log in to the Azure portal using Azure Cloud Shell, follow these steps: 
    • Go to the Azure portal in your web browser.
    • Click the Cloud Shell icon in the top right-hand corner of the portal.
    • Select Bash as the shell.
    • Follow the prompts to sign in with your Azure account.

Here are some other common Azure CLI commands that you might find useful:

  • 'az account list': List all subscriptions for the authenticated account.
  • 'az account set --subscription SUBSCRIPTION_NAME': Set the default subscription.
  • 'az resource list --resource-group RESOURCE_GROUP_NAME': List all resources in a resource group.
  • 'az resource show --name RESOURCE_NAME --resource-group RESOURCE_GROUP_NAME --resource-type RESOURCE_TYPE': Show information about a specific resource.

Here are some other common Azure PowerShell commands that you might find useful:

  • 'Get-AzSubscription': List all subscriptions for the authenticated account.
  • 'Set-AzContext -Subscription SUBSCRIPTION_NAME': Set the default subscription.
  • 'Get-AzResource -ResourceGroupName RESOURCE_GROUP_NAME': List all resources in a resource group.
  • 'Get-AzResource -Name RESOURCE_NAME -ResourceGroupName RESOURCE_GROUP_NAME -ResourceType RESOURCE_TYPE': Show information about a specific resource.

Thanks for reading, CloudOps Signing Off! 😊