Add scripts to support Tenks network persistence

[MaxBed4d]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @MaxBed4d, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a mechanism to ensure that Tenks network configurations are automatically applied and maintained across system reboots. It achieves this by integrating a systemd service that triggers a specialized bash script during the boot sequence, which in turn prepares the environment and executes the necessary Kayobe-based network configuration commands.

Highlights

• Systemd Service for Network Persistence: A new systemd service, tenks-network-on-boot.service, has been introduced to automatically execute a network setup script during system boot, ensuring Tenks network configurations are applied persistently.
• Dedicated Network Setup Script: A new bash script, tenks-network-setup, has been added. This script is responsible for activating the Kayobe virtual environment, setting up critical environment variables, and invoking the tenks-network-reboot-patch.sh script to configure the network.
• Automated Tenks Network Configuration: The changes automate the process of setting up Tenks host networking on system startup, leveraging existing Kayobe tooling to manage the configuration.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a systemd service and an accompanying script to ensure Tenks network settings persist across reboots. The overall approach is logical. However, I've identified a couple of significant issues. The systemd service configuration grants potentially excessive permissions, which is a security concern. Additionally, the setup script relies on hardcoded paths, which severely impacts its maintainability and portability. My review includes suggestions to address these points by adhering to the principle of least privilege and by refactoring the script to be more robust and configurable.

[gemini-code-assist]

This script has a couple of areas for improvement:

1. Hardcoded Paths: It contains multiple hardcoded paths based on /home/lab/deployment. This makes the script brittle and hard to maintain or reuse in different environments. It's recommended to centralize the base path definition.
2. Unsetting Variables: The method for unsetting OS_* variables can be made more robust and efficient using modern bash features.

The suggestion below addresses both points by introducing a base path and using parameter expansion to unset variables.

Suggested change

	source /home/lab/deployment/venvs/kayobe/bin/activate
	source /home/lab/deployment/src/kayobe-config/kayobe-env
	cd /home/lab/deployment/src
	for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done
	export KAYOBE_CONFIG_SOURCE_PATH=/home/lab/deployment/src/kayobe-config
	export KAYOBE_VENV_PATH=/home/lab/deployment/venvs/kayobe
	export TENKS_CONFIG_PATH=/home/lab/deployment/src/kayobe-config/tenks.yml
	# A base path could be set here, or sourced from an environment file.
	# e.g. DEPLOYMENT_BASE=${DEPLOYMENT_BASE:-/home/lab/deployment}
	DEPLOYMENT_BASE="/home/lab/deployment"
	SRC_DIR="$DEPLOYMENT_BASE/src"
	VENV_DIR="$DEPLOYMENT_BASE/venvs/kayobe"
	KAYOBE_CONFIG_DIR="$SRC_DIR/kayobe-config"
	source "$VENV_DIR/bin/activate"
	source "$KAYOBE_CONFIG_DIR/kayobe-env"
	cd "$SRC_DIR"
	# Unset all shell variables and functions starting with OS_
	for var in "${!OS_@}"; do
	unset "$var"
	done
	export KAYOBE_CONFIG_SOURCE_PATH="$KAYOBE_CONFIG_DIR"
	export KAYOBE_VENV_PATH="$VENV_DIR"
	export TENKS_CONFIG_PATH="$KAYOBE_CONFIG_DIR/tenks.yml"