How to Change a Git Commit Message
git commit --amend -m "New commit message."

Installing Ansible

The ansible package can always be installed from PyPI using pip on most systems but it is also packaged and maintained by the community for a variety of Linux distributions.

On CentOS:
$ sudo yum install epel-release
$ sudo yum install ansible
RPMs for currently supported versions of CentOS are also available from EPEL.

On Ubuntu (configure the PPA and install Ansible):
$ sudo apt update
$ sudo apt install software-properties-common
$ sudo add-apt-repository --yes --update ppa:ansible/ansible
$ sudo apt install ansible
Ubuntu builds are available in a PPA here.

Validate Ansible inventory file

Verify the hosts in your inventory:
ansible -i hosts all --list-hosts
ansible -i hosts all --list

Validate and obtain all information about your Ansible inventory:
ansible-inventory -i hosts --list

docker system df

Show docker disk usage.
It seems to me, that especially it is useful for Docker desktop on Mac or Windows. Because Docker volumes on these OS work under Linux virtual machine, and not always convenient to get actual size of volumes.

https://docs.docker.com/engine/reference/commandline/system_df/

AWS - Данные о Сервере EC2 - http://169.254.169.254/latest/meta-data/

How do I integrate a GIT submodule back into my project as an usual folder?

Or, in other words, how do I un-submodule a git submodule? If all you want is to put your submodule code into the main repository, you just need to remove the submodule and re-add the files into the main repo:

1. Delete the reference to the submodule from the index, but keep the files:

git rm --cached submodule_path

(no trailing slash)

2.Delete the .gitmodules file or if you have more than one submodules edit this file removing the submodule from the list:

git rm .gitmodules

3.Remove the .git metadata folder (make sure you have backup of this):

rm -rf submodule_path/.git

4.Add the submodule to the main repository index:

git add submodule_path git commit -m "remove submodule"

NOTE: The procedure outlined above is destructive for the history of the submodule, in cases where you want to retain a congruent history of your submodules you have to work through a fancy "merge". For more details I defer you to this very complete Stack Overflow reference.

https://www.atlassian.com/git/articles/core-concept-workflows-and-tips

Your AWS account has default quotas. Unless otherwise noted, each quota is Region-specific. You can request increases for some quotas, and other quotas cannot be increased.

To view the quotas for Amazon EC2 Auto Scaling, open the Service Quotas console . In the navigation pane, choose AWS services and select desired AWS Service.

Cronjob for the First Monday of Every Month

The crontab man page (“man 5 crontab” ) contains this bit:

Note: The day of a command’s execution can be specified by two fields — day of month, and day of week. If both fields are restricted (i.e., don’t start with *), the command will be run when either field matches the current time. For example, 30 4 1,15 * 5 would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday.

What does it mean precisely? If you specify both the day of month and the day of week field, then cron will run the command when either of the fields match. In other words, there’s a logical OR relationship between the two fields. Let’s look at an example:

0 0 1 * MON

This expression translates to “Run at the midnight if it’s the first day of the month OR Monday”. An expression like this could be handy for a job that sends weekly and monthly reports as it probably needs to run at the start of every week, and the start of every month. However, if either field is unrestricted, the logical relationship between the fields changes to “AND”. For example:

0 0 * * MON

Here, the day of month field is unrestricted. Cron will run this command when both the day of month field AND the day of week fields match. Since * matches any day of month, this expression effectively translates to “Run at midnight every Monday”.

So far so good! The sometimes-OR relationship between the two fields is a relatively well-known cron gotcha. But let’s look closer at what values cron considers “unrestricted”. Star (*) is of course unrestricted, but, according to the man page, any value that starts with the star character is also unrestricted. For example, */2 is unrestricted too. Can we think of any useful schedules that exploit this fact? Yes, we can:

0 0 1-7 * */7

Here, the day of month is restricted to dates 1 to 7. Cron will interpret */7 in the day of week field as “every 7 days starting from 0 (Sunday)”, so, effectively, “Every Sunday”. Since the day of week field starts with *, cron will run the command on dates 1 to 7 which are also Sunday. In other words, this will match midnight of the first Sunday of every month.

In the above example, */7 is a trick to say “every Sunday” in a way that starts with the star. Unfortunately, this trick only works for Sunday. Can we make an expression that runs on, say, the first Monday of every month? Yes, we can!

0 0 */100,1-7 * MON

The day of month field here is */100,1-7, meaning “every 100 days starting from date 1, and also on dates 1-7”. Since there are no months with 100+ days, this again is a trick to say “on dates 1 to 7” but with a leading star. Because of the star, cron will run the command on dates 1 to 7 that are also Monday (AND relationship).

https://blog.healthchecks.io/2022/09/schedule-cron-job-the-funky-way/

Whoami for awscli

aws sts get-caller-identity

Returns details about the IAM user or role whose credentials are used to call the operation.

Terraform update only one resource

terraform state list
terraform apply --target=helm_release.app_name

AWS EC2 On-Demand pricing calculator
https://aws.amazon.com/ec2/pricing/on-demand/

Daylight Saving Time (DST) Handling in Linux (Summer Time)

To list the valid values for TZ, execute
cd /usr/share/zoneinfo ; find

These zoneinfo files, part of the timezone package, are not human-readable. To check the data in them, use the zdump command.
For example, to list the timezone information for Brazil/East, run
zdump -v Brazil/East | grep 2023
zdump -v /usr/share/zoneinfo/Brazil/East | grep 2023

The output of zdump lists all clock jumps for this timezone, including the offset from Greenwich Mean Time and whether DST applies (it does when isdst=1).
In the Brazil/East example, the lines
Brazil/East Sun Feb 18 01:59:59 2007 UTC = Sat Feb 17 23:59:59 2007 BRST isdst=1 gmtoff=-7200
Brazil/East Sun Feb 18 02:00:00 2007 UTC = Sat Feb 17 23:00:00 2007 BRT isdst=0 gmtoff=-10800
indicate that in 2007, DST ("ST") will end at the end of Saturday, February 17th at which point the clock will be put back one hour.

Whether DST is honoured in a particular region and if so, what its start and end dates are, can change over time. The timezone packages for Linux products is updated regularly to reflect regulatory DST changes.

To see Ansible facts (data related to your remote systems).

Run this command at the command line:
ansible <hostname> -m ansible.builtin.setup
ansible localhost -m ansible.builtin.setup

Azure: Create a Linux virtual machine and install Nginx

Use the following Azure CLI commands to create a Linux VM and install Nginx. After your VM is created, you'll use the Custom Script Extension to install Nginx. The Custom Script Extension is an easy way to download and run scripts on your Azure VMs. It's just one of the many ways you can configure the system after your VM is up and running.

1. From Shell, run the following az vm create command to create a Linux VM:

az vm create \
--resource-group [sandbox resource group name] \
--name my-vm \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys


Your VM will take a few moments to come up. You name the VM my-vm. You use this name to refer to the VM in later steps.

2. Run the following az vm extension set command to configure Nginx on your VM:

az vm extension set \
--resource-group [sandbox resource group name] \
--vm-name my-vm \
--name customScript \
--publisher Microsoft.Azure.Extensions \
--version 2.1 \
--settings '{"fileUris":["https://raw.githubusercontent.com/MicrosoftDocs/mslearn-welcome-to-azure/master/configure-nginx.sh"]}' \
--protected-settings '{"commandToExecute": "./configure-nginx.sh"}'

This command uses the Custom Script Extension to run a Bash script on your VM. The script is stored on GitHub. While the command runs, you can choose to examine the Bash script from a separate browser tab. To summarize, the script:

1. Runs apt-get update to download the latest package information from the internet. This step helps ensure that the next command can locate the latest version of the Nginx package.
2. Installs Nginx.
3. Sets the home page, /var/www/html/index.html, to print a welcome message that includes your VM's host name.

Azure: Configure network access

Let's configure the access to the virtual machine (VM) you created earlier.
Right now, the VM you created and installed Nginx on isn't accessible from the internet. You'll create a network security group that changes that by allowing inbound HTTP access on port 80.

1) Access your web server
In this procedure, you get the IP address for your VM and attempt to access your web server's home page.

Run the following az vm list-ip-addresses command to get your VM's IP address and store the result as a Bash variable:

IPADDRESS="$(az vm list-ip-addresses \
   --resource-group [sandbox resource group name] \
   --name my-vm \
   --query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
   --output tsv)"

Run the following curl command to download the home page:
curl --connect-timeout 5 http://$IPADDRESS

The --connect-timeout argument specifies to allow up to five seconds for the connection to occur. After five seconds, you see an error message that states that the connection timed out:
curl: (28) Connection timed out after 5001 milliseconds

This message means that the VM was not accessible within the timeout period.
As an optional step, try to access the web server from a browser:
Run the following to print your VM's IP address to the console:
echo $IPADDRESS

You see an IP address.
Copy the IP address that you see to the clipboard.
Open a new browser tab and go to your web server. After a few moments, you see that the connection isn't happening.
Keep this browser tab open for later.


2) List the current network security group rules
Your web server wasn't accessible. To find out why, let's examine your current NSG rules.
Run the following az network nsg list command to list the network security groups that are associated with your VM:

az network nsg list \
   --resource-group [sandbox resource group name] \
   --query '[].name' \
   --output tsv

You see this:
my-vmNSG

Every VM on Azure is associated with at least one network security group. In this case, Azure created an NSG for you called my-vmNSG.

Run the following az network nsg rule list command to list the rules associated with the NSG named my-vmNSG:
az network nsg rule list \
--resource-group [sandbox resource group name] \
--nsg-name my-vmNSG

You see a large block of text in JSON format in the output. In the next step, you'll run a similar command that makes this output easier to read.

Run the az network nsg rule list command a second time. This time, use the --query argument to retrieve only the name, priority, affected ports, and access (Allow or Deny) for each rule. The --output argument formats the output as a table so that it's easy to read:

az network nsg rule list \
   --resource-group [sandbox resource group name] \
   --nsg-name my-vmNSG \
   --query '[].{Name:name, Priority:priority, Port:destinationPortRange, Access:access}' \
   --output table

You see this:

Name               Priority    Port    Access
-----------------  ----------  ------  --------
default-allow-ssh  1000        22      Allow

You see the default rule, default-allow-ssh. This rule allows inbound connections over port 22 (SSH). SSH (Secure Shell) is a protocol that's used on Linux to allow administrators to access the system remotely. The priority of this rule is 1000. Rules are processed in priority order, with lower numbers processed before higher numbers.
By default, a Linux VM's NSG allows network access only on port 22. This enables administrators to access the system. You need to also allow inbound connections on port 80, which allows access over HTTP.

3) Create the network security rule
Here, you create a network security rule that allows inbound access on port 80 (HTTP).
Run the following az network nsg rule create command to create a rule called allow-http that allows inbound access on port 80:

az network nsg rule create \
   --resource-group [sandbox resource group name] \
   --nsg-name my-vmNSG \
   --name allow-http \
   --protocol tcp \
   --priority 100 \
   --destination-port-range 80 \
   --access Allow

For learning purposes, here you set the priority to 100. In this case, the priority doesn't matter. You would need to consider the priority if you had overlapping port ranges.
To verify the configuration, run az network nsg rule list to see the updated list of rules:

az network nsg rule list \
   --resource-group [sandbox resource group name] \
   --nsg-name my-vmNSG \
   --query '[].{Name:name, Priority:priority, Port:destinationPortRange, Access:access}' \
   --output table 

You see this both the default-allow-ssh rule and your new rule, allow-http:

Name               Priority    Port    Access
-----------------  ----------  ------  --------
default-allow-ssh  1000        22      Allow
allow-http         100         80      Allow

4) Access your web server again
Now that you've configured network access to port 80, let's try to access the web server a second time.
Note: After you update the NSG, it may take a few moments before the updated rules propagate. Retry the next step, with pauses between attempts, until you get the desired results.
Run the same curl command that you ran earlier:

curl --connect-timeout 5 http://$IPADDRESS

You see this:
<html><body><h2>Welcome to Azure! My name is my-vm.</h2></body></html>

As an optional step, refresh your browser tab that points to your web server.

Nice work. In practice, you can create a standalone network security group that includes the inbound and outbound network access rules you need. If you have multiple VMs that serve the same purpose, you can assign that NSG to each VM at the time you create it. This technique enables you to control network access to multiple VMs under a single, central set of rules.