Recherche effectué dans :

Filtre actif, cliquez pour en enlever un tag :

Cliquez sur un tag pour affiner votre recherche :

Résultat de la recherche (3 notes) :

J'ai découvert upterm qui permet de partager facilement une session terminal à distance #terminal, #cli, #tooling, #ssh, #JaiDécouvert

J'ai cherché une solution pour partager facilement une session shell de ma workstation à un collègue.

Je connais les solutions suivantes :

$ ngrok tcp 22
Donne : tcp://0.tcp.ngrok.io:12345
# Connexion : ssh user@0.tcp.ngrok.io -p 12345

#JaiDécouvert aujourd'hui les solutions upterm et bore.

Le projet upterm a commencé en 2019 et est codé en Golang. Le projet bore est plus jeune, il a commencé 2022 et est codé en rust.

J'ai testé bore puis upterm. J'ai retenu upterm pour les raisons suivantes :

  • upterm propose directement un package rpm, contrairement à bore
  • Le serveur relais public de upterm était significativement plus réactif que celui de bore lors de mes tests
  • upterm propose nativement une session partagée entre deux utilisateurs, alors que bore est spécialisé dans la création de tunnels TCP. Il est possible de configurer bore pour lancer automatiquement des sessions partagées via un script tmux lancé par ssh, mais c'est moins pratique que upterm

Voici une démonstration de upterm :

$ sudo dnf install -y https://github.com/owenthereal/upterm/releases/download/v0.20.0/upterm_linux_amd64.rpm

Je peux ensuite autoriser la clé publique ssh de l'utilisateur invité :

$ upterm host --authorized-keys PATH_TO_PUBLIC_KEY

ou directement via son username GitHub :

$ upterm host --github-user username

Pour donner accès à une session terminal :

$ upterm host
The authenticity of host 'uptermd.upterm.dev (2a09:8280:1::3:4b89)' can't be established.
ED25519 key fingerprint is SHA256:9ajV8JqMe6jJE/s3TYjb/9xw7T0pfJ2+gADiBIJWDPE.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
╭─ Session: LiZaF6eKfCTxNeFSEt7B ─╮
┌──────────────────┬─────────────────────────────────────────────┐
│ Command:         │ /usr/bin/zsh                                │
│ Force Command:   │ n/a                                         │
│ Host:            │ ssh://uptermd.upterm.dev:22                 │
│ Authorized Keys: │ n/a                                         │
│                  │                                             │
│ ➤ SSH Command:   │ ssh LiZaF6eKfCTxNeFSEt7B@uptermd.upterm.dev │
└──────────────────┴─────────────────────────────────────────────┘

╰─ Run 'upterm session current' to display this again ─╯

🤝 Accept connections? [y/n] (or <ctrl-c> to force exit)
✅ Starting to accept connections...

L'utilisateur invité accède à ce terminal simplement avec :

$ ssh LiZaF6eKfCTxNeFSEt7B@uptermd.upterm.dev

upterm maintient une liste de sessions ouvertes, consultable avec :

$ upterm session list
📡 Active Sessions (1)
═══════════════════════
┌───┬──────────────────────┬──────────────┬─────────────────────────────┐
│   │      SESSION ID      │   COMMAND    │            HOST             │
├───┼──────────────────────┼──────────────┼─────────────────────────────┤
│ * │ DumRFGF6AuinQjzwBf0E │ /usr/bin/zsh │ ssh://uptermd.upterm.dev:22 │
└───┴──────────────────────┴──────────────┴─────────────────────────────┘

💡 Tips:
  • Use 'upterm session current' to see details
  • Use 'upterm session info <SESSION_ID>' for specific session

Journal du mardi 18 juin 2024 à 09:24 #coding, #database, #migration, #tooling, #JaiDécouvert

#JaiDécouvert dbmate (from).

A lightweight, framework-agnostic database migration tool.

Ce projet a commencé en 2015.

Je viens de voir dans mes notes que j'avais déjà regardé ce projet le 15 octobre 2023, donc ce n'est pas vraiment une découverte 🤣.

Il est codé en Golang, chose que j'apprécie pour ce genre d'outil.


Depuis septembre 2022, j'utilise l'outil de migration graphile-migrate. Avant cela j'utilisais Migrate.


Dans ce thread j'ai été surpris de voir ce commentaire :

I’ve always wondered why tools like this cannot become stateless. Most have an up and down action, but I haven’t seen one yet that can run a query to determine if a migration has been applied or not. Then no state tables/artifacts are needed.

Instead of one file with an up and down, there could be two files where each has a predicate and then an action, where the predicate would run to determine if the migration has been applied or not.

En quelques secondes, je pense être capable d'imaginer plusieurs scénarios — que je ne souhaite pas lister ici — pour lesquels son idée ne pourrait pas fonctionner 🤔.

Dernière page.