Hoe kan ik ervoor zorgen dat ik SSH sessies kan overnemen?

[SampleUser]

Hoe kan ik ervoor zorgen dat ik SSH sessies kan overnemen?

Dit mag ook met externe tools. Er was vroegâh een fork van OpenSSH, dan kon je gewoon ssh-takeover [TTY-id], maar was onstabiel en is nooit publiek gemaakt.

Ik heb gehoord van een tool genaamd scream, maar helaas kan ik daar niet veel over vinden.

Edit: ik draai Debian 8.

[ Voor 4% gewijzigd door SampleUser op 14-02-2016 12:59 ]

[swbr]

Je bedoelt screen, niet scream. Google en man pages doen de rest.

[Thralas]

reptyr?

[lordgandalf]

Waarom wil je uberhaupt ssh sessies overnemen ? Beetje blackhatish ?

[aawe mwan]

Wat bedoel je precies met "overnemen"?

Met tmux kan je in de ene SSH sessie een programma starten, vervolgens de SSH sessie verbreken, vanaf een andere computer inloggen en dan met "tmux attach" verder gaan met je draaiende programma.

Je kunt ook vanuit 2 SSH sessies die tegelijkertijd op hetzelfde account ingelogd zijn een "tmux attach" doen en dan zien deze twee sessies allebei precies hetzelfde scherm.

[pennywiser]

Tmux, volgens mij -S of -s

[SampleUser]

aawe mwan schreef op zondag 14 februari 2016 @ 19:22:
Wat bedoel je precies met "overnemen"?

Met tmux kan je in de ene SSH sessie een programma starten, vervolgens de SSH sessie verbreken, vanaf een andere computer inloggen en dan met "tmux attach" verder gaan met je draaiende programma.

Je kunt ook vanuit 2 SSH sessies die tegelijkertijd op hetzelfde account ingelogd zijn een "tmux attach" doen en dan zien deze twee sessies allebei precies hetzelfde scherm.

Danku, daar was ik naar op zoek.

[thunder7]

lordgandalf schreef op zondag 14 februari 2016 @ 19:14:
Waarom wil je uberhaupt ssh sessies overnemen ? Beetje blackhatish ?

Praktijkvoorbeeld: een screen-sessie met de monitoring van je zonnepanelen, stroommeter, email, world-community-grid progress etc. kun je thuis op de bank, thuis op je kamer, onderweg op de telefoon, op je werk, op bezoek elders etc. overal 'meenemen'.

En een email waar je aan bezig bent kun je dus gewoon verder bewerken op een andere locatie. Daar is niets blackhatish aan, lijkt me.

Of je screen of tmux moet gebruiken is volgens mij net zo'n discussie als tussen vim en emacs.

[lordgandalf]

ja maar je vraagt hoe neem ik een ssh sessie over als in hoe kan ik in een ssh sessie kijken en er dingen in doen. Als in meneer a heeft een open ssh sessie staan naar zijn server hoe neem ik die sessie over en kan ik op die server.
Het is de bewoording die mij hier aan deed denken.

[u_nix_we_all]

thunder7 schreef op maandag 15 februari 2016 @ 09:11:
[...]

Of je screen of tmux moet gebruiken is volgens mij net zo'n discussie als tussen vim en emacs.

Ik zie dat anders. Services die horen headless te draaien, tmux en/of screen is voor mensen die niet weten hoe ze een process in de achtergrond moeten laten draaien en geen kaas gegeten hebben van redirection en logfiles. Een service moet headless draaien en niet in een interactieve sessie.
Ik heb serieus productiesystemen plat zien gaan omdat de processen in screen draaiden, en dat door user error of zelfs door bugs in screen zelf plat ging. En probeer dan maar een iets van logs terug te zien als screen geklapt, of gestopt is.

[SampleUser]

u_nix_we_all schreef op maandag 15 februari 2016 @ 18:00:
[...]


Ik zie dat anders. Services die horen headless te draaien, tmux en/of screen is voor mensen die niet weten hoe ze een process in de achtergrond moeten laten draaien en geen kaas gegeten hebben van redirection en logfiles. Een service moet headless draaien en niet in een interactieve sessie.
Ik heb serieus productiesystemen plat zien gaan omdat de processen in screen draaiden, en dat door user error of zelfs door bugs in screen zelf plat ging. En probeer dan maar een iets van logs terug te zien als screen geklapt, of gestopt is.

Ik zie niet hoe je htop als een demoon kan draaien..

[u_nix_we_all]

SampleUser schreef op maandag 15 februari 2016 @ 18:16:
[...]


Ik zie niet hoe je htop als een demoon kan draaien..

Ik zie het nut niet van htop als daemon draaien. Die start je toch gewoon wanneer je het wilt zien ? Waarom moet dat in een screen draaien ?

[Cyphax]

u_nix_we_all schreef op maandag 15 februari 2016 @ 18:00:
[...]


Ik zie dat anders. Services die horen headless te draaien, tmux en/of screen is voor mensen die niet weten hoe ze een process in de achtergrond moeten laten draaien en geen kaas gegeten hebben van redirection en logfiles. Een service moet headless draaien en niet in een interactieve sessie.
Ik heb serieus productiesystemen plat zien gaan omdat de processen in screen draaiden, en dat door user error of zelfs door bugs in screen zelf plat ging. En probeer dan maar een iets van logs terug te zien als screen geklapt, of gestopt is.

Sure, het gaat meer om het gebruik door een eindgebruiker die bijvoorbeeld e-mail, IM, IRC, torrentclient of dat soort dingen open laten staan voor het gemak, niet om ze op die manier als daemon te draaien. Daar komt bij dat iig screen meer is dan een ik-onthou-wel-waar-je-mee-bezig-was-apparaatje maar meer een windowmanager is voor je terminal.

Maargoed, ik denk dat jij het meer hebt over misbruik van screen om een soort van iets als daemon te laten draaien, dat is idd vies.

u_nix_we_all schreef op maandag 15 februari 2016 @ 18:21:
[...]

Ik zie het nut niet van htop als daemon draaien. Die start je toch gewoon wanneer je het wilt zien ? Waarom moet dat in een screen draaien ?

Hopelijk alleen voor dit soort (leuke) experimentjes.

[ Voor 16% gewijzigd door Cyphax op 15-02-2016 18:27 ]

[deadinspace]

SampleUser schreef op maandag 15 februari 2016 @ 18:16:
Ik zie niet hoe je htop als een demoon kan draaien..

Door atop te gebruiken

[Rainmaker]

SampleUser schreef op maandag 15 februari 2016 @ 18:16:
[...]


Ik zie niet hoe je htop als een demoon kan draaien..

htop houdt toch helemaal geen history bij?

Als je terug wil kijken naar wat je cpu e.d. in het verleden gedaan heeft, is er gewoon sysstat. Die verzameld met een cronjob iedere X minuten performance data.

[pennywiser]

u_nix_we_all schreef op maandag 15 februari 2016 @ 18:00:
[...]


Ik zie dat anders. Services die horen headless te draaien, tmux en/of screen is voor mensen die niet weten hoe ze een process in de achtergrond moeten laten draaien en geen kaas gegeten hebben van redirection en logfiles. Een service moet headless draaien en niet in een interactieve sessie.
Ik heb serieus productiesystemen plat zien gaan omdat de processen in screen draaiden, en dat door user error of zelfs door bugs in screen zelf plat ging. En probeer dan maar een iets van logs terug te zien als screen geklapt, of gestopt is.

Mooi dat jij dat zo ziet, maar het natuurlijk bullshit. Tmux kan veel meer dan alleen multiplexen. Ja als je een productie mysql of apache met de hand start mee laat draaien in een screen is dat nogal vreemd en vragen om moeilijkheden. Helaas zijn je voorbeelden ("bugs in screen") nogal algemeen en vaag.

[CyBeR]

u_nix_we_all schreef op maandag 15 februari 2016 @ 18:00:
[...]


Ik zie dat anders. Services die horen headless te draaien, tmux en/of screen is voor mensen die niet weten hoe ze een process in de achtergrond moeten laten draaien en geen kaas gegeten hebben van redirection en logfiles. Een service moet headless draaien en niet in een interactieve sessie.
Ik heb serieus productiesystemen plat zien gaan omdat de processen in screen draaiden, en dat door user error of zelfs door bugs in screen zelf plat ging. En probeer dan maar een iets van logs terug te zien als screen geklapt, of gestopt is.

Screen is niet voor services maar voor commando's die je in de achtergrond wilt draaien maar waarvan je de output nog wilt kunnen hebben en eventueel direct mee wilt kunnen interacteren.

Je gaat mij niet wijs maken dat ik m'n irssi als systemd service moet opstarten want daar heb ik niks aan.

[u_nix_we_all]

CyBeR schreef op woensdag 17 februari 2016 @ 10:38:
[...]


Screen is niet voor services maar voor commando's die je in de achtergrond wilt draaien maar waarvan je de output nog wilt kunnen hebben en eventueel direct mee wilt kunnen interacteren.

Je gaat mij niet wijs maken dat ik m'n irssi als systemd service moet opstarten want daar heb ik niks aan.

Tuurlijk, screen is een prima tool voor dat soort dingen. Maar een irc client is natuurlijk iets heel anders dan service die je host. Mijn punt is dat voor dat laatste je geen screen wilt gebruiken. Misschien dat het in dit topic niet helemaal op zijn plaats is (het is me nog steeds niet duidelijk wat het doel van de TS is) maar ik heb gewoon hele slechte ervaringen met systemen waar services op gehost worden die in screen draaien.

[CyBeR]

Fair enough want daar is screen inderdaad niet voor, maar dat is in dit topic imo verder weinig relevant.

[pennywiser]

Het doel maakt toch niet uit, hij vraagt gewoon of het kan: ja het kan. Soms wil je dat er meerdere mensen meekijken als een bepaalt tooltje output geeft, compile errors en whatnot. Omdat het kan.