Delete a branch both locally and remotely

Here's how to delete a branch both locally and remotely:

Step-by-Step Deletion

Step 1: Switch to a Different Branch First

You can't delete a branch you're currently on:

# Switch to dev or main
git switch dev

Step 2: Delete Local Branch

# Delete local branch (safe delete - prevents deletion if unmerged)
git branch -d feat/-deployment

# OR force delete (if you get warnings about unmerged changes)
git branch -D feat/-deployment

Step 3: Delete Remote Branch

# Delete remote branch
git push origin --delete feat/-deployment

AWS CLI SSO

 

To log in to AWS CLI using SSO (IAM Identity Center), follow these steps:

• Configure your AWS CLI profile for SSO:

This step sets up the necessary configuration in your AWS CLI profile to use IAM Identity Center for authentication. You will need your SSO Start URL and SSO Region.

Código

    aws configure sso

The command will interactively prompt you for:

• SSO Start URL: The URL for your organization's AWS access portal.
• SSO Region: The AWS Region where your IAM Identity Center instance is located.
• AWS Account ID: The AWS account you want to access.
• Role Name: The IAM role (permission set) you want to assume within that account.
• Default output format: (e.g., json, text, table)
• Default region: The AWS Region where your commands will be sent by default.
• Profile name: A name for this SSO profile (e.g., my-sso-profile).

To use the profile:
aws sts get-caller-identity --profile aeropay 

 

Log in to IAM Identity Center.

After configuring the profile, you need to initiate the login process to obtain temporary credentials.

Código

aws sso login --profile <your-profile-name>
export AWS_PROFILE=company-profile

Replace <your-profile-name> with the name you provided in the aws configure sso step. This command typically opens your default web browser to the IAM Identity Center login page, where you authenticate using your organization's credentials. Once authenticated, the AWS CLI retrieves and caches temporary credentials.

Note: If you prefer not to open a browser, you can use the --no-browser or --use-device-code options with aws sso login. Use the configured profile.

After a successful login, you can use the configured profile to execute AWS CLI commands.

Código

    aws s3 ls --profile <your-profile-name>

This command would list your S3 buckets using the credentials obtained through your SSO session.

Important Considerations:

• AWS CLI Version:

  Ensure you are using AWS CLI version 2, as SSO integration is primarily supported in this version.
• Session Management:

  SSO sessions have a limited duration. When your session expires, you will need to run aws sso login again to refresh your credentials.
• Logout:

  To explicitly log out and remove cached credentials, use aws sso logout --profile <your-profile-name>



Solaar rules for ubuntu Logitech MX Master 3S

Great rules for our Logitech

%YAML 1.3

---

- MouseGesture: Mouse Right

- KeyPress:

- [Super_L, Right]

- click

...

---

- MouseGesture: Mouse Left

- KeyPress:

- [Super_L, Left]

- click

...

---

- MouseGesture: Mouse Up

- KeyPress:

- [Super_L, a]

- click

...

---

- MouseGesture: Mouse Down

- KeyPress:

- Super_L

- click

...

---

- Test: [thumb_wheel_up, 15]

- KeyPress:

- [Control_L, Alt_L, Left]

- click

...

---

- Test: [thumb_wheel_down, 15]

- KeyPress:

- [Control_L, Alt_L, Right]

- click

...

 

Terraform with lambda

 

 

terraform {

required_version = ">= 1.13.5"

required_providers {

aws = {

source = "hashicorp/aws"

version = ">= 4.16.1"

}

}

}

# Configure the AWS provider

provider "aws" {

region = "us-east-1" # Replace with your desired region

}

# IAM role for Lambda execution

resource "aws_iam_role" "lambda_exec" {

name = "hello_world_lambda_role"

assume_role_policy = jsonencode({

Version = "2012-10-17"

Statement = [{

Action = "sts:AssumeRole"

Effect = "Allow"

Principal = {

Service = "lambda.amazonaws.com"

}

}]

})

}

# Attach basic Lambda execution policy

resource "aws_iam_role_policy_attachment" "lambda_policy" {

role = aws_iam_role.lambda_exec.name

policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"

}

# Create a ZIP archive of the Lambda function

data "archive_file" "lambda_zip" {

type = "zip"

source_file = "${path.module}/lambda_function.py"

output_path = "${path.module}/lambda_function.zip"

}

# Create the Lambda function

resource "aws_lambda_function" "hello_world" {

function_name = "hello_world"

filename = data.archive_file.lambda_zip.output_path

source_code_hash = data.archive_file.lambda_zip.output_base64sha256

role = aws_iam_role.lambda_exec.arn

handler = "lambda_function.lambda_handler"

runtime = "python3.9"

environment {

variables = {

ENVIRONMENT = "production"

}

}

}

# Output the Lambda function ARN

output "lambda_function_arn" {

description = "The ARN of the Lambda function"

value = aws_lambda_function.hello_world.arn

}

# Output the Lambda function name

output "lambda_function_name" {

description = "The name of the Lambda function"

value = aws_lambda_function.hello_world.function_name

}

 

Detect lambda drift with terraform

To detect drift in your Lambda function's code using the hash, you can compare the current hash in your Terraform state with the actual deployed Lambda's hash.

terraform state show aws_lambda_function.hello_world | grep source_code_hash

aws lambda get-function --function-name hello_world --query 'Configuration.CodeSha256' --output text

Terraform import block

 Let's imagine we want to import an SNS Topic into our template.

 We should have something like this, change region, to and id of the import.

terraform {

required_version = ">= 1.13.5"

required_providers {

aws = {

source = "hashicorp/aws"

version = ">= 4.16.1"

}

}

}

# Configure the AWS provider

provider "aws" {

region = "us-east-1" # Replace with your desired region

}

import {

to = aws_sns_topic.AleTopic

id = "arn:aws:sns:us-east-1:XXXX:AleTopic"

}

 

Run to generate the config file for that resource

terraform plan -generate-config-out=generated.tf 

A new file will be generated.

# __generated__ by Terraform

# Please review these resources and move them into your main configuration files.

# __generated__ by Terraform

resource "aws_sns_topic" "AleTopic" {

application_failure_feedback_role_arn = null

application_success_feedback_role_arn = null

application_success_feedback_sample_rate = 0

archive_policy = null

content_based_deduplication = false

delivery_policy = null

display_name = "My topic"

fifo_throughput_scope = null

Run terraform plan

 

Then run terraform apply to bring the changes to the state file. 

 

 

Update aws cdk to the latest version

sudo npm uninstall -g aws-cdk
sudo npm uninstall -g npm
sudo npm install -g npm@latest
sudo npm install -g aws-cdk@latest

Import an existing resource using AWS CDK

To fully manage the existing resource with your CDK stack (allowing you to modify its properties later), you must perform a Resource Import using the cdk import CLI command, which relies on CloudFormation's import capabilities.

Let's test this with new cdk code, importing a sns topic.

cdk init app --language=python

 

Create venv

source .venv/bin/activate && pip install -r requirements.txt

 

 We would like import this resource

 

 

On the cdk code you need to write the following, referencing the topic.

from aws_cdk import (

# Duration,

Stack,

aws_sns as sns,

aws_iam as iam

)

from constructs import Construct

class CdkImportStack(Stack):

def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:

super().__init__(scope, construct_id, **kwargs)

existing_topic = sns.Topic(self, "MyManagedTopic", topic_name="MyTopic")

 

Run cdk synth to see the cloudformation template

cdk synth

Resources:
  MyManagedTopic0CEB7327:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: MyTopic
    Metadata:
      aws:cdk:path: CdkImportStack/MyManagedTopic/Resource
  CDKMetadata:
    Type: AWS::CDK::Metadata
    Properties:
      Analytics: v2:deflate64:H4sIAAAAAAAA/zPcxxxxxxx
    Metadata:
      aws:cdk:path: CdkImportStack/CDKMetadata/Default
Parameters:
  BootstrapVersion:
    Type: AWS::SSM::Parameter::Value<String>
    Default: /cdk-bootstrap/hnb659fds/version
    Description: Version of the CDK Bootstrap resources in this environment, automatically retrieved from SSM Parameter Store. [cdk:skip]

Then run and it will ask for the topic arn

cdk import CdkImportStack

 

You will see on the cloudformation stack the resource imported

 

 

CDK migrate, a way to migrate your cloudformation template to cdk code

 The migration from the CloudFormation template to the CDK is done with a single command: cdk migrate. Simply point to the local CloudFormation template file (let’s call it demo-template.yaml), and watch as the CLI converts the template into a CDK application. The output and result from running the command will be a directory comprised of the CDK code and dependencies, but will not deploy the stack.

You can grab the template code from cloudformation. 

cdk migrate --stack-name CdkStack --language python --from-path cleaned_template.json

 

After that the template is under cdk_stack.

 

 

Run the code to see the cdk.out code generated.

source .venv/bin/activate
pip install -r CdkStack/requirements.txt 

cd CdkStack
cdk deploy 

 

 

Upgrading Node.js to the latest version Ubuntu

The module n makes version-management easy:

sudo npm install n -g

For the latest stable version:

n stable

For the latest version:

n latest