Friday, October 20, 2023

Git commands - for setup and daily work

 This article is just to collect some of the Git commands that are being used on a regular basis.

Git commands for daily work

git clone <https link to repo> (clone a remote repo. Make sure you’re in the correct directory when running)

git pull (sync the latest changes from remote repo)

git checkout -b feature/new_branch_name (create new feature branch)

git checkout main (switch to main branch)

git add -A (pre-commit command to add all new files to local staging, run this before local commit)

git commit -a -m "adding a test file" (commit all files to local branch and add a message)

git push --set-upstream origin feature/testingbranch (publish local branch to remote repo, use the same name as the current feature branch)

git branch -d localBranchName (delete local branch)

git push origin --delete remoteBranchName (delete branch remotely)

git branch -l (list branches)

Git commands configuring Git

git config --global user.name "First Last" (user name and email should be set up as a one time config)

git config --global user.email <user@email.com>

git config --global core.longpaths true (fixes an error with long path names)

git config --list (show git config)

git config --list --show-origin (show git config including where variables are defined)

git config --global http.https://dev.azure.com/.proxy https://someaddress (this is a proxy related setting)

git config --global http.https://dev.azure.com/.proxyauthmethod negotiate (this is a proxy related setting)

git config --global http.https://dev.azure.com/.emptyAuth true (this is a proxy related setting)

git config --global --edit (edit the global config file in VI editor)

git config --global --replace-all user.name "username" (replaces current user name)

git config --global --replace-all user.email <user@email.com>

git config --unset-all credential.helper (unset named settings)

git config --global --set credential.helper (set the credentials helper type)

   


Tuesday, October 10, 2023

Add custom rule to new NSGs via Azure Policy

 For governance, or operational, reasons there may be a need to ensure that certain rules are applied to all NSGs that are created within a certain scope.

This can be achieved using Azure Policy with a deployIfNotExist function.

Such a policy has already been created and is ready to use from AzAdvertizer.net, see link here:

I ran a quick test to verify the functionality and it works as expected. At the time of creation of the NSG, the policy kicks in an applies the rule right away.

The policy will let you specify one rule. So for multiple rules additional assignments can be created.

The policy looks for a suffix (the last part of the name) in the NSG name and only applies the rule if there's a match. You can re-arrange the check and have it look for a prefix instead, I have uploaded an example here on Github (can be copied in as a new definition via Azure Portal -> Policy -> Definitions).

If you want to apply the rule to all NSGs, then simply remove this check, see marked part below:


The policy is parameterized, so when you create an assignment it will request you to add all relevant parameters. See example below:

Note that some of the parameters such as destinationPortRange are arrays. They should be added in the format ["3389"] (for port 3389..).


Below is a screenshot of the inbound rule added post NSG deployment:


Since this is a deployIfNotExist policy, this means the Assignment requires a system assigned managed identity (or a user assigned managed identity) with Network Contributor permissions which will be automatically created when you create the assignment if you have enough permissions.