SSH-sesje stjert mei de VPN: tmux of in taakútfierder?

Jo VPN-yndikator wurdt grien, de rûte is werom, en it SSH-finster dat jo iepen lieten jout nea wer in opdrachteken. It werstellen fan in rûte werstelt net it TCP-petear dat deryn brûkt waard, dus alles wat yn dat finster typt is, is fuort. As de echte soarch in bewurkerbuffer of in lange migraasje is, is de oplossing om dat wurk net mear oan ien ferbining te binen. tmux en in taakútfierder losse ferskillende helten fan dat probleem op.

In werferbûne VPN ferfettet de socket net

TCP hat gjin begryp fan ferfetsjen nei in adresferoaring. De SSH-ferbining wurdt troch beide einen identifisearre, en as de tunnel wer opboud wurdt, kin it pleatslike adres feroarje en de âlde socket is dea. De tsjinner merkt it úteinlik, mar jo terminal merkt it daliks.

In keepalive fan de klant ûntdekt in deade wjerskant earder. It bringt de sesje net werom, en it kin in opdracht dy't al rûn net weromhelje. De keepalive is in ûntdekker, gjin ferhelptark. It seit neat oer oft de opdracht fan fierôf oerlibbe hat.

Set it wurk op de fiere host

Meitsje de sesje oan op de fiere host, net op 'e laptop. Ferbyn jo sa gewoan, start tmux dêr, en rin de bewurker of migraasje deryn. Loskeppelje mei it standertfoarheaksel en de sesje bliuwt rinnen wylst de SSH-ferbining ferdwynt. tmux pleatslik starte beskermet jo shell tsjin in sletten finster, net in opdracht fan fierôf tsjin in deade tunnel.

ssh [email protected]
tmux new-session -s office-work

As de VPN werom is, iepenje in nije SSH-ferbining nei deselde host en fêstigje jo wer by namme. De sesje is it duorsume objekt, net de ferbining. Jou it in namme dy't jo in wike letter noch werkenne.

tmux tsjin in taakútfierder

tmux hâldt in ynteraktyf proses libben salang't de host oan stiet. In taakútfierder of tsjinstbehearder hâldt in net-ynteraktive taak libben, leit de útgongsstatus fêst, en oerlibbet it hielendal einigjen fan 'e SSH-sesje. It earste is foar wurk dat jo besjogge; it twadde foar wurk dat jo planne en letter ynspektearje.

Gjint fan beide oerlibbet in werstart, útsein as de host ynsteld is om it wer te bringen. In tmux-sesje stjert mei de masine, en in tydlike taak stjert mei it opstarten, útsein as it as ienheid registrearre waard. Kies neffens wat it wurk oerlibje moat.

Beide oanpakken hawwe ek in loch nedich dat jo nei it werferbinen lêze kinne. Sûnder ien witte jo dat it proses bestiet, mar net wat it dien hat. Skriuw it lochpaad njonken de sesjenamme.

Beslis neffens wat oerlibje moat

Beslis neffens it slimste dat barre kin as it wurk healwei stopet. In bewurkersesje ferliest net-bewarre buffers, wat ferfelend is mar werstelber. In migraasje dy't de helte fan syn wizigings fêstleit is dat net, en dat pleitet foar in útfierder mei in fêstleine útkomst. As de taak ynteraktyf en lang is, is tmux plus in skreaune loch meastentiids genôch.

systemd-run --user --unit=migrate-customers --collect ./migrate.sh

Wat jo ek kieze, ynspektearje de fêstleine útkomst foardat jo wat dan ek wer starte. In ûntbrekkende lêste rigel fertelt jo wat de laptop seach, net wat de tsjinner fêstlei. Dat ferskil is de reden om it wurk fan it begjin ôf bûten de ferbining te hâlden, en model fan loskeppeljen en wer fêstigjen is de lytste ferzje dêrfan.