Sesioni SSH vdes bashkë me VPN-në: tmux apo ekzekutues detyrash?

Treguesi i VPN-së bëhet jeshil, rruga kthehet, dhe dritarja SSH që latë hapur nuk kthen më kurrë promptin. Rivendosja e një rruge nuk rivendos bisedën TCP që e përdorte, prandaj çdo gjë e shkruar në atë dritare humbi. Nëse shqetësimi i vërtetë është një buffer editori ose një migrim i gjatë, zgjidhja është të ndaloni lidhjen e asaj pune me një lidhje të vetme. tmux dhe një ekzekutues detyrash zgjidhin gjysma të ndryshme të atij problemi.

Një VPN i rilidhur nuk e vazhdon soketin

TCP nuk ka asnjë nocion për të vazhduar pas një ndryshimi adrese. Lidhja SSH identifikohet nga të dy skajet, dhe kur tuneli rindërtohet, adresa lokale mund të ndryshojë dhe soketi i vjetër është i vdekur. Serveri e vë re në fund, por terminali juaj e vë re menjëherë.

Keepalive i klientit zbulon një palë të vdekur më herët. Nuk e kthen sesionin, dhe nuk mund të rikuperojë një komandë që ishte duke punuar. Keepalive është një zbulues, jo një mjet rikuperimi. Nuk thotë asgjë nëse komanda e largët mbijetoi.

Vendoseni punën në hostin e largët

Krijoni sesionin në hostin e largët, jo në laptop. Lidhuni si zakonisht, nisni tmux atje dhe ekzekutoni editorin ose migrimin brenda tij. Shkëputuni me prefiksin e parazgjedhur dhe sesioni vazhdon të punojë ndërsa lidhja SSH zhduket. Nisja e tmux lokalisht mbron shellin tuaj nga një dritare e mbyllur, jo një komandë të largët nga një tunel i vdekur.

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

Kur VPN të kthehet, hapni një lidhje të re SSH me të njëjtin host dhe rilidhuni me emër. Objekti i qëndrueshëm është sesioni, jo lidhja. Jepini një emër që do ta njihni edhe pas një jave.

tmux kundrejt një ekzekutuesi detyrash

tmux mban gjallë një proces interaktiv sa kohë hosti është i ndezur. Një ekzekutues detyrash ose menaxher shërbimesh mban gjallë një detyrë jointeraktive, regjistron statusin e daljes së saj dhe i mbijeton përfundimit të plotë të sesionit SSH. I pari është për punën që shikoni; i dyti për punën që planifikoni dhe inspektoni më vonë.

Asnjëri nuk i mbijeton një rindezjeje nëse hosti nuk është konfiguruar ta rivendosë. Një sesion tmux vdes me makinën, dhe një detyrë kalimtare vdes me nisjen nëse nuk është regjistruar si njësi. Zgjidhni sipas asaj që puna duhet të mbijetojë.

Të dyja qasjet kërkojnë gjithashtu një regjistër që mund ta lexoni pas rilidhjes. Pa të dini se procesi ekziston, por jo çfarë ka bërë. Shkruani shtegun e regjistrit pranë emrit të sesionit.

Vendosni sipas asaj që duhet të mbijetojë

Vendosni sipas gjësë më të keqe që mund të ndodhë nëse puna ndalon në mes. Një sesion editori humbet buffer-at e paruajtur, gjë që është e bezdisshme por e rikuperueshme. Një migrim që kryen gjysmën e ndryshimeve të tij nuk është, dhe kjo flet për një ekzekutues me rezultat të regjistruar. Nëse detyra është interaktive dhe e gjatë, tmux plus një regjistër i shkruar zakonisht mjafton.

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

Çfarëdo që të zgjidhni, inspektoni rezultatin e regjistruar përpara se të ekzekutoni përsëri çdo gjë. Një rresht i fundit që mungon ju tregon çfarë pa laptopi, jo çfarë regjistroi serveri. Pikërisht ky dallim është arsyeja për ta mbajtur punën jashtë lidhjes që në fillim, dhe modeli i shkëputjes dhe rilidhjes është versioni më i vogël i tij.