Zsa Voyager - part 2

Initial forewords

It has been a while, but I’ve now had the ZSA Voyager for a very long time, and I therefor feel qualified to give it a proper review of it.

The keyboard and I have gone through modifications, that I feel, ultimately have set it apart from the competition, and into something i truely love using, which also have help tremendously with RSI (Repetitive Strain Injury).

Backstory

As I mention, in my initial thoughts, back in the July 2024-post, this keybord would hopefully be my endgame keyboard, as well as fit the criteria of being a way to delay RSI or even combat it. I usually spend a lot of hours in front of a computer and I’m not getting any younger. If I want to continue in my profession and sit long hours in front of a computer, I would need to take care of my body, especially my hands, neck and back.

Read more

Zsa Voyager

Backstory

I’ve been searching for the endgame keyboard for a while now and for two reasons.

Number 1, requirement, because of working long hours at the computer and I do want to delay RSI for as long as possible.

Number 2, is purely because I’m a keyboard enthusiast and I love new tech.

This is not a full review, because I have not received the keyboard yet.

The purchase

I’m using a Dygma Defy and I’m moving back and forth between my workplace and home. It’s working, but I would like a more mobile setup. So after a lot of reasearch, I made a purchase a few days ago and is now waiting for the keyboard to arrive.

Read more

Control Philips Hue Lights with API

Control Philips Hue Lights with API

The Python script uses the Philips Hue API to interact with a Philips Hue bridge, which manages the smart lights. It presents a menu offering options to turn lights on, turn lights off, or exit the program.

When selecting to turn lights on, the script retrieves a list of lights that are currently off. It then prompts the user to choose one or multiple lights from this list by entering their respective numbers, separated by commas.

Read more

SELinux

SELINUX

SELinux (Security-Enhanced Linux) is a security feature in Linux that provides a flexible mandatory access control system. Here are some common commands to work with SELinux:

  1. Check SELinux Status:
sestatus
  • Enable/Disable SELinux: To temporarily change SELinux mode:
setenforce 0  # Permissive mode
setenforce 1  # Enforcing mode
  • Modify SELinux Settings:
# To change SELinux mode permanently
vim /etc/selinux/config
  • Context of Files and Directories: Viewing SELinux context of files:
ls -Z
  • Changing SELinux Context: To change the context of a file or directory:
chcon -t <target_context> <file/directory>
  • Restore Default SELinux Context: If a file’s context has been changed unintentionally, restore it to default:
restorecon -v <file/directory>
# To restore every label on the whole system to the correct type, depending on SElinux policies
# Navigate to / and touch file .autorelabel 
# Then do a reboot and SELinux will label the corret type depending on folder and files.
# The .autorelabel file will automatically selfdelete as well
cd / && sudo touch .autorelabel
  • Booleans: SELinux Booleans manage specific functionalities.
getsebool -a  # List all SELinux booleans or use 'semange boolean --list'
setsebool -P <boolean_name> <value> # Set SELinux boolean value for the runnig system (Will not persist through reboot)
semange boolean --modify --on <boolean_name> # Set SELinux boolean value for the runnig system (Will persist through reboot)
  • Audit Logs: Checking SELinux audit logs:
ausearch -m AVC,USER_AVC -i

Remember, when working with SELinux, it’s crucial to understand the security implications of your actions. Modifying contexts and booleans can impact system security, so always ensure changes align with your system’s security policies.

Read more

Ansible Directory Structur

Ansible Directory Structure:

ansible_project/
├── inventories/
│   ├── production/
│   │   └── group_vars/
│   │       └── all.yml         # Common variables for the production environment
│   │       └── vault.yml       # Encrypted file containing sensitive information (e.g., using Ansible Vault)
│   └── staging/
│       └── group_vars/
│           └── all.yml         # Common variables for the staging environment
│           └── vault.yml       # Encrypted file containing sensitive information (e.g., using Ansible Vault)
├── playbooks/
│   ├── main.yml               # Main playbook file
│   ├── webserver.yml          # Playbook for configuring web servers
│   └── database.yml           # Playbook for configuring databases
├── roles/
│   ├── common/                # Role for common tasks (used across multiple playbooks)
│   │   ├── tasks/
│   │   ├── handlers/
│   │   ├── templates/
│   │   └── defaults/
│   │
│   ├── webserver/             # Role for web server configuration
│   │   ├── tasks/
│   │   ├── handlers/
│   │   ├── templates/
│   │   └── defaults/
│   │
│   └── database/              # Role for database configuration
│       ├── tasks/
│       ├── handlers/
│       ├── templates/
│       └── defaults/
├── files/                     # Static files to be transferred to hosts
│   └── example.txt
├── vars/                      # Variable files, organized by purpose or environment
│   ├── common_vars.yml
│   ├── production_vars.yml
│   └── staging_vars.yml
└── ansible.cfg                # Ansible configuration file

Explanation:

  • Inventories: Holds inventory files defining your servers and their groups, along with group-specific variables.

Read more

How to Design a Modern CICD Pipeline

How to design a modern CI/CD pipeline

Designing a modern CI/CD pipeline involves multiple steps and tools that integrate seamlessly to automate the process. Below is a general outline of how you can set up each stage of the CI/CD pipeline:

  1. Version Control System (VCS) Setup (Git):

    • Create a central repository for your project.
    • Configure branch protection rules to enforce code quality and security standards.
    • Integrate linters and other static analysis tools to ensure that code pushed to the repository meets the defined coding standards.
  2. Build Automation:

Read more

Wake on LAN

Wake on LAN

1. Check if server supports wake-on-lan:

SSH to server. Im using Proxmox.

ssh username@server

List interfaces and find the interface the correct one.

Usually integraded interfaces, like on a motherboard, will work.

root@home-server ~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

eno1 seems to be the one we are looking for.

Read more

Set Memory Usage for a Podman Container

How to limit memory resource for a Podman container

This is a simple and quick script to set amount of memory for a Podman container.

This can be helpful if you are running alot of containers via Distrobox.

Take a look at the script below and feel free to modify it as you like:

#!/usr/bin/env bash

# Capture the output from the 'podman ps' command
podman_output="$(podman ps --all --no-trunc --format "{{.Names}} {{.ID}} {{.Labels}}" | grep "manager:distrobox" | cut -d " " -f1,2 | column -t)"

# Define an associative array to store the tokens
declare -A tokens

# Parse and store the tokens
while read -r name token; do
    tokens["$name"]="$token"
done <<< "$podman_output"

# Prompt the user for RAM amount and container name
read -p "Enter RAM amount (e.g., 4G): " ram
read -p "Enter the container name: " container_name

# Check if the user-specified container name is in the tokens array
if [ -n "${tokens[$container_name]}" ]; then
    token="${tokens[$container_name]}"
    # Use the user input to replace the token and RAM in the systemctl command
    systemctl_command="systemctl --user set-property libpod-$token.scope MemoryMax=$ram && systemctl --user status libpod-$token.scope | grep 'Memory: '"

    # Execute the systemctl command
    echo "Executing: $systemctl_command"
    eval "$systemctl_command"
else
    echo "Container name '$container_name' not found in the captured data."
fi

# Spacer
echo ""

# Store the running container names in a variable
running_containers=$(podman ps --format '{{.Names}}' --filter status=running)

# Get the container details including tokens
container_details=$(podman ps --all --no-trunc --format "{{.Names}} {{.ID}} {{.Labels}}" | grep "mana
ger:distrobox" | cut -d " " -f1,2)

# Loop through each line of the container details
while read -r line; do
    container_name=$(echo $line | awk '{print $1}')
    container_token=$(echo $line | awk '{print $2}')
    if [[ $running_containers == *"$container_name"* ]]; then
        echo "Container: $container_name"
        systemctl --user status libpod-$container_token.scope | grep 'Memory: '
        echo
    fi
done <<< "$container_details"
Read more

Two Default Gateways on One System

Problem Description

You have built two or more network cards into one Linux system and each of these cards has its own default gateway. By default, you can only have one default gateway on a system. The case described would lead to asynchronous routing, whereby the router would reject the packets as appropriate.

Solution

The iproute2 program, which is included in all current Linux distributions and already installed even, as a rule, can be used for the solution of this problem. Normally, a Linux system only has one routing table, in which only one default gateway can make entries. With iproute2, you have the ability to setup an additional routing table, for one thing, and allow this table to be used by the system based on rules, for another.

Read more

Clean Up Journalctl Logs

How to safely clean up Journalctl logs

1. Check disk usage

journalctl --disk-usage

2. Remove old logs

Use the command “journalctl –vacuum-size=500M” to clear logs that are larger than 500MB. Adjust the size parameter as needed.

journalctl --vacuum-size=500M

Alternatively, you can use “journalctl –vacuum-time=2weeks” to clear logs older than two weeks.

journalctl –vacuum-time=2weeks

or remove all logs:

journalctl --rotate
journalctl --vacuum-time=1s

3. Restart service

systemctl restart systemd-journald.service
systemctl status systemd-journald.service
Read more