diff options
Diffstat (limited to 'topics/programming')
| -rw-r--r-- | topics/programming/autossh-for-keeping-ssh-tunnels.gmi | 65 | ||||
| -rw-r--r-- | topics/programming/better-logging.gmi | 17 |
2 files changed, 76 insertions, 6 deletions
diff --git a/topics/programming/autossh-for-keeping-ssh-tunnels.gmi b/topics/programming/autossh-for-keeping-ssh-tunnels.gmi new file mode 100644 index 0000000..a977232 --- /dev/null +++ b/topics/programming/autossh-for-keeping-ssh-tunnels.gmi @@ -0,0 +1,65 @@ +# Using autossh to Keep SSH Tunnels Alive + +## Tags +* keywords: ssh, autossh, tunnel, alive + + +## TL;DR + +``` +guix package -i autossh # Install autossh with Guix +autossh -M 0 -o "ServerAliveInterval 60" -o "ServerAliveCountMax 5" -L 4000:127.0.0.1:3306 alexander@remoteserver.org +``` + +## Introduction + +Autossh is a utility for automatically restarting SSH sessions and tunnels if they drop or become inactive. It's particularly useful for long-lived tunnels in unstable network environments. + +See official docs: + +=> https://www.harding.motd.ca/autossh/ + +## Installing autossh + +Install autossh using Guix: + +``` +guix package -i autossh +``` + +Basic usage: + +``` +autossh [-V] [-M monitor_port[:echo_port]] [-f] [SSH_OPTIONS] +``` + +## Examples + +### Keep a database tunnel alive with autossh + +Forward a remote MySQL port to your local machine: + +**Using plain SSH:** + +``` +ssh -L 5000:localhost:3306 alexander@remoteserver.org +``` + +**Using autossh:** + +``` +autossh -L 5000:localhost:3306 alexander@remoteserver.org +``` + +### Better option + +``` +autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -L 5000:localhost:3306 alexander@remoteserver.org +``` + +#### Option explanations: + +- `ServerAliveInterval`: Seconds between sending keepalive packets to the server (default: 0). +- `ServerAliveCountMax`: Number of unanswered keepalive packets before SSH disconnects (default: 3). + +You can also configure these options in your `~/.ssh/config` file to simplify command-line usage. diff --git a/topics/programming/better-logging.gmi b/topics/programming/better-logging.gmi index dca8c0d..d80bb0d 100644 --- a/topics/programming/better-logging.gmi +++ b/topics/programming/better-logging.gmi @@ -1,14 +1,17 @@ -# Improving Logging in GN2 +# Improving Alerting/Logging in GN2 -## What Are We Trying To Solve? +## Problem Statement -We prioritise maintaining user functionality over speed in GN [with time this speed will be improved]. As such we should be pay more attention at not breaking any currently working GN2 functionality. And when/if we do, trouble-shooting should be easy. On this front, one way is to stream-line logging in both GN2/GN3 and make it more script friendly - only report when something fails, not to instrument variables - and in so doing make the process of monitoring easier. +Current logging in the genenetwork ecosystem is noisy and difficult to parse programatically which makes it hard to: + +* Integrate logs into some observability pipeline (E.g. sheepdog). +* Troubleshoot issues as they occur. We always learn of bugs from users. ## Goals -* Have script-friendly error/info logs. -* Remove noise from GN2. -* Separate logging into different files: error logs, info logs. Add this somewhere with Flask itself instead of re-directing STDOUT to a file. +* Standardize logging format and config across GN2 flask apps and gn-guile. +* Adopt structured logging. +* Extend sheep-dog to be able to parse gn logs and send alerts on e-mail or matrix. ### Non-goals @@ -27,3 +30,5 @@ We prioritise maintaining user functionality over speed in GN [with time this sp ## Resources => https://realpython.com/python-logging/ Logging in Python +=> https://signoz.io/guides/python-logging-best-practices/ Python Logging Best Practices - Obvious and Not-So-Obvious +=> https://signoz.io/blog/what-is-opentelemetry/ What is OpenTelemetry |