maallyn/updated-radar
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove un needed files

Browse Source
This commit is contained in:
Mark Allyn
2026-05-21 20:12:32 -07:00
parent f01db5e6b4
commit b781d2af2f
7 changed files with 90 additions and 2115 deletions
Download Patch File Download Diff File Expand all files Collapse all files

136
CLAUDE.md
View File

@@ -78,7 +78,11 @@ struct target_data_structure {
TargetType type; TargetType type;
}; };
To optimize memory bandwidth on the Radeon 780M GPU, the traffic_cop packs raw telemetry down into a lightweight structure passed directly into a standard OpenGL Shader Storage Buffer Object (SSBO) with a layout(std430) alignment.C++struct target_data_to_shader_structure { To optimize memory bandwidth on the Radeon 780M GPU, the traffic_cop packs raw telemetry
down into a lightweight structure passed directly into a standard OpenGL Shader
Storage Buffer Object (SSBO) with a layout(std430) alignment.
C++struct target_data_to_shader_structure {
float target_x; // Local Cartesian offset East (meters from radar origin) float target_x; // Local Cartesian offset East (meters from radar origin)
float target_y; // Local Cartesian offset North (meters from radar origin) float target_y; // Local Cartesian offset North (meters from radar origin)
float length; // Vessel length bounding box size (meters) float length; // Vessel length bounding box size (meters)
@@ -87,7 +91,76 @@ To optimize memory bandwidth on the Radeon 780M GPU, the traffic_cop packs raw t
float altitude; // Target altitude profile (meters) float altitude; // Target altitude profile (meters)
long long timestamp;// Data alignment padding field long long timestamp;// Data alignment padding field
}; };
Ingestion ProtocolThread Isolation: The traffic_cop handles parsing, scaling, and double-buffering completely isolated on its own thread to prevent blocking the frame rendering pipeline.Precision Correction: Coordinate projections (converting Lat/Long maps to local relative meters) are performed on the CPU using double-precision calculations before passing parameters down as 32-bit floating-point numbers to protect against rounding distortions.Boundary & Ceiling Filters: Targets residing beyond the selected scope's maximum range are immediately culled. Marine installations enforce an absolute <= 40-meter altitude cap; any aircraft target exceeding this height is dropped.Synchronized Dispatch: The traffic_cop writes updates into the graphics pipeline using a std::mutex critical section precisely when the PPI radar line swings past 0.0 radians (True North).4. Operational Exhibit ScopesUsers step through the available scope list in a continuous loop using the forward (1) and backward (2) keys. Scopes reset to their baseline parameters upon entry.Exhibit Introduction: Displays static informational text on the left panel. The right view panel remains blank until navigation keys are pressed.Chain Home A-Scope (1940s): Simulated 1D electrostatic vector trace. Features an inverted top-down baseline. All video signals deflect downward. Includes crystal-controlled 20-mile reference pips and a wide $150^\circ$ floodlight footprint. Target azimuth coordinates are evaluated manually via a radiogoniometer search coil nulling control.Marine A-Scope (1940s): Represents early surface-search systems like the British Type 271. Features a bottom-up baseline trace showing signal power versus range. The antenna is rotated manually using a servo motor console knob to sweep for target peak voltages.Marine Traffic Control PPI Scope (1960s): Stationary shore installation tracking Bellingham Bay. Features a high-power $25\text{ kW}$ transmitter, a highly directional 12-foot linear waveguide array ($0.7^\circ$ horizontal beamwidth), and a slow 15 RPM rotation rate. The screen top is locked to True North.Shipborne Marine PPI Scope (1960s): Simulates a moving patrol boat or Coast Guard cutter. Features a $15\text{ kW}$ tactical transmitter, a 4-to-6-foot antenna ($1.2^\circ$ horizontal beamwidth), and a fast 25 RPM sweep. The screen top is locked to the vessel's bow, and the graticule ring dynamically adjusts using gyrocompass inputs.5. Shader Modularization StrategyThe rendering engine decomposes processing tasks across distinct, optimized shader sets to isolate raw signal generation from persistent phosphor simulations. [Target SSBO Data] & [GDAL Elevation Maps]
Ingestion ProtocolThread Isolation:
The traffic_cop handles parsing, scaling, and double-buffering completely
isolated on its own thread to prevent blocking the frame rendering pipeline.
Precision Correction: Coordinate projections (converting Lat/Long maps to
local relative meters) are performed on the CPU using double-precision
calculations before passing parameters down as 32-bit floating-point
numbers to protect against rounding distortions.
Boundary & Ceiling Filters:
Targets residing beyond the selected scope's maximum range are immediately culled.
Marine installations enforce an absolute <= 40-meter altitude cap; any
aircraft target exceeding this height is dropped.
Synchronized Dispatch:
The traffic_cop writes updates into the graphics pipeline using a
std::mutex critical section precisely when the PPI radar
line swings past 0.0 radians (True North).
4. Operational Exhibit Scopes
Users step through the available scope list in a continuous loop using the
forward (1) and backward (2) keys.
Scopes reset to their baseline parameters upon entry.
Exhibit Introduction: Displays static informational text on the left panel.
The right view panel remains blank until navigation keys are pressed.
Chain Home A-Scope (1940s):
Simulated 1D electrostatic vector trace. Features an inverted top-down baseline. All video signals
deflect downward. Includes crystal-controlled 20-mile reference pips and a
wide $150^\circ$ floodlight footprint.
Target azimuth coordinates are evaluated manually
via a radiogoniometer search coil nulling control.
Marine A-Scope (1940s):
Represents early surface-search systems like the British Type 271. Features a
bottom-up baseline trace showing signal power versus range. The antenna is
rotated manually using a servo motor console knob to sweep for target peak voltages.
Marine Traffic Control PPI Scope (1960s):
Stationary shore installation tracking Bellingham Bay. Features a high-power $25\text{ kW}$
transmitter, a highly directional 12-foot linear waveguide array ($0.7^\circ$ horizontal beamwidth),
and a slow 15 RPM rotation rate. The screen top is locked to True North.
Shipborne Marine PPI Scope (1960s):
Simulates a moving patrol boat or Coast Guard cutter. Features a $15\text{ kW}$ tactical
transmitter, a 4-to-6-foot antenna ($1.2^\circ$ horizontal beamwidth), and a
fast 25 RPM sweep. The screen top is locked to the vessel's bow,
and the graticule ring dynamically adjusts using gyrocompass inputs.
5. Shader Modularization Strategy
The rendering engine decomposes processing tasks across distinct, optimized
shader sets to isolate raw signal generation from persistent phosphor
simulations.
[Target SSBO Data] & [GDAL Elevation Maps]
│ │
▼ ▼
┌──────────────────────────────────────────────────┐ ┌──────────────────────────────────────────────────┐
@@ -106,58 +179,28 @@ Ingestion ProtocolThread Isolation: The traffic_cop handles parsing, scaling, an
│ PASS C: Orthographic 2D UI & Graticule Overlay │ │ PASS C: Orthographic 2D UI & Graticule Overlay │
│ (Applies Backlit Vector Rings and Text Overlays) │ │ (Applies Backlit Vector Rings and Text Overlays) │
└──────────────────────────────────────────────────┘ └──────────────────────────────────────────────────┘
Pass A (Signal Generation & Terrain Pipeline): Evaluates the radar equation, target cross-sections, and landscape masks on a per-pixel basis. It writes output results directly into a high-precision floating-point Framebuffer Object (FBO) texture, preventing signal clipping and rounding artifacts.Pass B (P7 Phosphor Integration & Persistence Pass): Emulates vintage cathode-ray tube long-persistence phosphors. It blends the newly generated excitation texture from Pass A into a historical ping-pong frame buffer tracking multi-stage exponential decay.Pass C (Orthographic 2D UI & Graticule Overlay): Draws edge-lit vector rings, angular graduation marks, baseline coordinates, and text glyph textures directly onto screen coordinates.6. Complete Compilation Blueprint Natively for UbuntuCMakeLists.txtCMakecmake_minimum_required(VERSION 3.22)
project(RadarSimulator SYSTEM CXX)
# Target configuration details: Mark Allyn, 2026 Pass A (Signal Generation & Terrain Pipeline):
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
# Enforce architectural optimizations for the Geekom A8 Max (Ryzen 9 8945HS) Evaluates the radar equation, target cross-sections, and landscape masks on a
if(CMAKE_COMPILER_IS_GNUCXX) per-pixel basis. It writes output results directly into a high-precision
add_compile_options(-Wall -Wextra -O3 -march=native -pthread) floating-point Framebuffer Object (FBO) texture, preventing signal clipping and
endif() rounding artifacts.
# Find systemic hardware dependencies inside Ubuntu Pass B (P7 Phosphor Integration & Persistence Pass):
find_package(PkgConfig REQUIRED)
pkg_check_modules(FREETYPE REQUIRED freetype2)
pkg_check_modules(GLFW3 REQUIRED glfw3)
find_package(PostgreSQL REQUIRED) Emulates vintage cathode-ray tube long-persistence phosphors. It blends the
newly generated excitation texture from Pass A into a historical ping-pong
frame buffer tracking multi-stage exponential decay.
find_path(GDAL_INCLUDE_DIR gdal.h PATH_SUFFIXES gdal) Pass C (Orthographic 2D UI & Graticule Overlay):
find_library(GDAL_LIBRARY NAMES gdal)
if(NOT GDAL_LIBRARY OR NOT GDAL_INCLUDE_DIR) Draws edge-lit vector rings, angular graduation marks, baseline coordinates,
message(FATAL_ERROR "GDAL structural development assets not found in ecosystem.") and text glyph textures directly onto screen coordinates.6.
endif()
# Define the primary radar simulator executable target Settings file used for troubleshooting and tuning parameters without
add_executable(radar_simulator having to re-compile.
main.cpp
settings.h
)
# Explicit target layout inclusion bounds
target_include_directories(radar_simulator PRIVATE
${CMAKE_CURRENT_SOURCE_DIR}
${FREETYPE_INCLUDE_DIRS}
${GLFW3_INCLUDE_DIRS}
${PostgreSQL_INCLUDE_DIRS}
${GDAL_INCLUDE_DIR}
)
# Core library synchronization
target_link_libraries(radar_simulator PRIVATE
${GLFW3_LIBRARIES}
${FREETYPE_LIBRARIES}
${PostgreSQL_LIBRARIES}
${GDAL_LIBRARY}
GL
dl
pthread
)
settings.hC++/* settings.hC++/*
* MIT License * MIT License
* Copyright (c) 2026 Mark Allyn * Copyright (c) 2026 Mark Allyn
@@ -260,6 +303,7 @@ namespace MarineBoatPPI {
const float ANTENNA_RPM = 25.0f; /* 25 RPM high-frequency sweep */ const float ANTENNA_RPM = 25.0f; /* 25 RPM high-frequency sweep */
const float ANTENNA_GAIN = 1258.93f; /* 31 dB linear converter multiplier */ const float ANTENNA_GAIN = 1258.93f; /* 31 dB linear converter multiplier */
} }
main.cppC++/* main.cppC++/*
* MIT License * MIT License
* Copyright (c) 2026 Mark Allyn * Copyright (c) 2026 Mark Allyn

59
CMakeLists.txt
View File

@@ -1,59 +0,0 @@
cmake_minimum_required(VERSION 3.20)
project(new-radar LANGUAGES C CXX)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
# Output binaries to build/bin
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
# ── Find system packages ──────────────────────────────────────────────────────
find_package(OpenGL REQUIRED)
find_package(glfw3 REQUIRED)
find_package(Freetype REQUIRED)
find_package(GDAL REQUIRED)
# PostgreSQL (libpq)
find_package(PostgreSQL REQUIRED)
# ── GLAD (bundled) ────────────────────────────────────────────────────────────
add_library(glad STATIC glad/src/glad.c)
target_include_directories(glad PUBLIC ${CMAKE_SOURCE_DIR}/include)
# ── Collect sources ───────────────────────────────────────────────────────────
file(GLOB_RECURSE SOURCES CONFIGURE_DEPENDS src/*.cpp)
# ── Main executable ───────────────────────────────────────────────────────────
add_executable(radar ${SOURCES})
target_include_directories(radar PRIVATE
${CMAKE_SOURCE_DIR}/include
${FREETYPE_INCLUDE_DIRS}
${GDAL_INCLUDE_DIRS}
${PostgreSQL_INCLUDE_DIRS}
)
target_link_libraries(radar PRIVATE
glad
OpenGL::GL
glfw
Freetype::Freetype
${GDAL_LIBRARIES}
${PostgreSQL_LIBRARIES}
pthread
)
# ── Compiler flags ────────────────────────────────────────────────────────────
target_compile_options(radar PRIVATE
-Wall
-Wextra
-Wpedantic
$<$<CONFIG:Debug>:-g -O0>
$<$<CONFIG:Release>:-O2>
)
# AMD Radeon 780M uses Mesa; no vendor-specific extensions
target_compile_definitions(radar PRIVATE
GL_GLEXT_PROTOTYPES
)

145
DESIGN.md
View File

@@ -1,145 +0,0 @@
# Radar Exhibit — Design Document
## Hardware target
- Geekom A8 Max: AMD Ryzen 9 8945HS, Radeon 780M (Mesa/RADV), 32 GB RAM
- Ubuntu 25.10, g++ 15.2.0, C++20, OpenGL 4.3 Core
---
## Screen layout
Three fixed regions rendered with `glViewport` + `glScissor`:
| Region | Content |
|--------|---------|
| Left panel | Text description, control list (white text; red labels; pink keystrokes) |
| Right panel — upper | Radar scope |
| Right panel — lower | Status bar: range, bearing, scope ID (yellow text) |
---
## Scope sequence (cycled with keys 1 / 2)
1. Exhibit introduction (text only)
2. Chain Home A-Scope (1940s)
3. Marine A-Scope (1940s)
4. PPI — stationary marine traffic control
5. PPI — on-board boat
Each scope's control state is **independent** and **resets on re-entry**.
---
## Radar equation
$$P_r = \frac{P_t G^2 \lambda^2 \sigma}{(4\pi)^3 R^4}$$
Signal strength falls off with $1/R^4$. Each radar type has fixed hardware loop gain baked into its shader set as a constant.
---
## Controls (keyboard until physical panel is built)
| Key | Action |
|-----|--------|
| 1 / 2 | Next / previous scope |
| 3 / 4 | Intensity down / up |
| 5 / 6 | Receiver sensitivity down / up |
| q / w | STC sensitivity down / up |
| e / r | STC range down / up |
| t / y | Radiogoniometer left / right (Chain Home only) |
| u / i | Max range down / up (all except Chain Home) |
| o / p | Range cursor down / up (PPI only) |
| a / s | Bearing cursor CCW / CW (PPI only) |
| d / f | Antenna bearing CCW / CW (Marine A-Scope only) |
Notes:
- Radiogoniometer, marine antenna bearing, and PPI bearing cursor share one physical knob on the eventual panel; kept separate in software.
- Range cursor ≠ max range: max range is the radar's selected range setting; range cursor is the measurement cursor on the PPI display.
---
## Scope specifications
### Chain Home A-Scope
- Fixed range: 200 miles
- No graticule; crystal-oscillator range pips every 20 miles (operator cannot change)
- Bearing via radiogoniometer simulation: operator finds null point; bearing shown as text below scope
- Two perpendicular antenna sets (N-S, E-W); radiogoniometer angle determines which target pip goes to null
### Marine A-Scope
- Ranges: 1.5 / 3.0 / 6.0 / 12.0 miles
- Range pips: every 0.25 / 0.5 / 1.0 / 2.0 miles respectively (fixed oscillator; not affected by range setting)
- No graticule
- Bearing by rotating simulated dish/horn antenna (d/f keys)
- Pip shape: finite rise, fixed-width pulse, finite fall — curved waveform, not a vertical line
### PPI scopes (both)
- 360° sweep with phosphor persistence via FBO (semi-transparent black quad each frame; no full clear)
- Range cursor and bearing cursor overlay
#### Stationary (marine traffic control)
- Fixed observer position; targets move relative to scope center
#### On-boat
- Observer is scope center; heading-up display — world rotates as boat heading changes
- Boat position/heading supplied from GDAL/PostgreSQL data
---
## Architecture
### Class hierarchy (State pattern)
```
BaseScope — intensity, sensitivity, STC vars, virtual render/update
├── AScope — horizontal sweep, curved pip waveform
│ ├── ChainHomeScope — radiogoniometer, fixed 200 mi range, 20 mi pips
│ └── MarineAScope — antenna bearing knob, 4 range settings
└── PPIScope — 360° sweep, FBO persistence, range/bearing cursors
├── StationaryPPI
└── OnBoatPPI — heading offset passed into shader
```
### Threading model
| Thread | Responsibility |
|--------|---------------|
| Render (main) | OpenGL loop, GLFW input, all `glDraw*` calls — never blocks |
| Simulation | Polls `target_data` (PostgreSQL) and GDAL; updates shared `std::vector<Target>` under `std::mutex` |
### FBO phosphor decay
- Render sweep into FBO each frame
- Blit FBO to screen
- Do **not** clear color buffer between frames; draw full-screen quad at very low alpha (~0.05) to decay old sweeps
### Shader notes
- GL_DEBUG_OUTPUT + `glDebugMessageCallback` enabled at startup (GPU robustness protocol)
- No NVIDIA-specific extensions; Mesa/RADV only
- $1/R^4$ attenuation computed in fragment shader; hardware loop gain is a per-scope `uniform` constant
---
## File structure
```
new-radar/
├── CMakeLists.txt
├── src/ — .cpp source files
├── include/ — .h/.hpp headers
│ ├── glad/
│ └── KHR/
├── glad/src/ — glad.c (bundled)
├── shaders/ — .vert / .frag files
├── data/ — patrol_route.json, etc.
└── map/
├── charts_enc/ — ENC .000 and GeoTIFF files
└── lidar_raw/ — LIDAR zips
```
---
## Database
- PostgreSQL, database `radar`, user `radar`, password `radar`
- Table `target_data`: polled by simulation thread for live target positions

0
build_progress.md
View File

1733
claude.save
View File

File diff suppressed because it is too large Load Diff

80
possible-claude.md-changes
View File

@@ -1,80 +0,0 @@
Implementation: Use a Frame Buffer Object (FBO). Instead of clearing the screen each frame, draw a full-screen quad with a very low alpha (e.g., 0.95) to slowly "dim" previous sweeps.
Threading for PostgreSQL and LIDAR
Reading from PostgreSQL (targets) and GDAL (LIDAR terrain) can cause "micro-stuttering" if done on the main render thread.
The Simulation Thread: Create a background thread that polls the target_data table and updates a thread-safe std::vector<Target>.
The Render Thread: The OpenGL loop should simply read the latest target positions and render them at 60 FPS (or higher) to keep the "sweep" of the PPI radar smooth.
Class Hierarchy and PPI SpecificsSince you have four distinct scopes (Chain Home A-Scope, Marine A-Scope, Stationary PPI, and On-boat PPI), a State Pattern is ideal.BaseScope Class: Handles the universal Intensity and Sensitivity variables.AScope Subclass: Implements the horizontal sweep and the "curved waveform" logic for the marine version.PPIScope Subclass: Implements the $360^\circ$ rotation logic. For the "On-boat" version, you will need to pass the boat's own GPS/Heading coordinates (from GDAL/LIDAR) into the shader to offset the target positions.
Deepseek:
Mathematical Logic vs. Contextual UnderstandingDeepSeek's Strength: DeepSeek is often more "aggressive" with mathematical optimization. It will likely give you very efficient GLSL code for the $1/R^4$ calculations.The "DeepSeek.md" file: You should rename your instructions to DEEPSEEK.md. DeepSeek models are trained to look for specific instructions in the root directory, similar to how Claude looks for CLAUDE.md.
Explicit Hardware Prompting
While Claude is currently aware of the AMD Radeon 780M and Ubuntu 25.10 nuances through our conversation, DeepSeek may require more explicit "reminders" about:
Mesa Drivers: Remind it to avoid vendor-specific (NVIDIA) extensions.
C++20 Strictness: DeepSeek sometimes defaults to older C++ standards; ensure your CMakeLists.txt is the first thing it reviews to lock it into your C++20 requirement.
Coding Style Enforcement
DeepSeek is generally good at following style guides, but it can be "talkative." You may need to add a directive:
"Provide code only. Do not explain standard C++ features unless they relate directly to the OpenGL 4.3 Core specification or the Geekom A8 Max hardware."
Suggested Additions to your .md file
To help either AI (Claude or DeepSeek) write better code for the PPI scopes, I recommend adding these details to your file:
PPI Rotation Speed: Specify the "RPM" for the marine traffic control (e.g., 12-24 RPM).
The "North-Up" vs "Head-Up" display: For the on-boat radar, will the display rotate as the boat turns (Head-Up), or will "North" always be at the top?
LIDAR Resolution: Define how many LIDAR data points should be converted into "clutter" on the radar screen.
This setup on your Geekom A8 Max should provide plenty of power to handle both the PostgreSQL queries and the complex OpenGL fragments required for a realistic "vintage" look.
Proposed Addition: > [THREADING MODEL]
Main/Render Thread: Handles the OpenGL loop, GLFW input, and glDraw calls. It must remain non-blocking to ensure a smooth 60 FPS sweep.
Simulation/Data Thread: A background thread that polls the target_data table and updates a thread-safe shared state (using std::mutex or atomics) for the Render thread to consume.
The PPI Scope Particulars
Since you are ready to define the two PPI modes (Stationary and On-Boat), adding these "Rules of Behavior" will prevent the AI from guessing.
Proposed Addition:
[PPI SCOPE SPECIFICS]
Persistence (Phosphor Decay): Implement using a Frame Buffer Object (FBO). Do not clear the color buffer every frame; instead, draw a semi-transparent black quad to simulate 1940s-60s CRT decay.
Marine Traffic Control (Stationary): Fixed location. Targets move relative to the center of the scope.
Police Boat (On-Boat): The center of the scope is the boat. Integrate boat heading (heading-up display) so the "world" rotates around the observer as the boat turns.
File Structure & CMake Prep
To make the two-step CMakeLists.txt generation easier, add a section for organization.
Proposed Addition:
[PROJECT STRUCTURE]
/src: All .cpp source files.
/include: All .hpp header files.
/shaders: External .glsl files for vertex and fragment shaders.
/data: Location for GDAL LIDAR and ENC chart files.
pdated Logic for DeepSeek/Claude SelectionOnce you add these, the transition will be seamless:Claude will be better at setting up the Class Hierarchy (the BaseScope and its derivatives) because it follows the "System Engineer" logic of your persona very well.DeepSeek will be excellent if you need to optimize the GLSL Shaders for the $1/R^4$ logic or the GDAL coordinate transformations, as it tends to be very mathematically rigorous.How to proceed:Go ahead and update your CLAUDE.md with these details. Once you're ready, paste the updated content here (or just tell me it's done), and we can generate that Foundation CMakeLists.txt to get your Geekom A8 Max environment ready for the first "Hello Radar" sweep.

52
sec-stuff
View File

@@ -1,52 +0,0 @@
LOcked key method on backup linode
from="PROD_IP_HERE",command="/usr/local/bin/run-backup.sh",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3... (rest of your key)
Create a simple script at /usr/local/bin/run-backup.sh on the backup machine:
#!/bin/bash
# 1. Sync the Gitea Database (assuming it was dumped to a file)
# 2. Re-run the Git Clone/Pull for your radar & website projects
cd /path/to/backup/folder
git pull origin main || git clone http://your-gitea-url/repo.git .
# Optional: Log the backup time
echo "Backup successful: $(date)" >> /var/log/backup_history.log
from="PROD_IP",command="/usr/share/doc/rsync/scripts/rrsync -ro /mnt/backups/ilovearthur/",restrict ssh-rsa AAAAB3...
#!/bin/bash
# Sync critical system and user data
rsync -az --delete /etc /var /home root@backup.ilovearthur.org:/
Wrapper script on backup server
#!/bin/bash
case "$SSH_ORIGINAL_COMMAND" in
rsync*)
# Allows rsync to only touch the designated backup folder
$SSH_ORIGINAL_COMMAND
;;
"git-sync")
# Custom command to refresh your Gitea mirrors
cd /home/backups/radar-repo
git pull || git clone http://your-gitea-url/repo.git .
;;
*)
echo "Access Denied: Command not permitted."
exit 1
;;
esac
Authorized keys file:
from="PROD_IP",command="/usr/local/bin/backup-handler.sh",no-agent-forwarding,no-port-forwarding,no-pty ssh-rsa AAAAB3...
from="192.0.2.1,2001:db8::1",command="/usr/local/bin/backup-handler.sh",no-pty ... [your-ssh-key]