screen/remote apps

[bruce]

Hi.

I can locally run screen, and then run an app.

If I wanted to have a process where I remotely start/run an app on a
remote box (ssh) via screen, How is this accomplished? Can it be done?

Ie, I want the app on the remote instance/box to be running in a
screen process within a term. This would allow someone to login, fire
up the screen process for the screen id, and see the process in
action...

Thanks for any pointers..

[Markus Schönhaber]

22.01.2016, 01:50 CET, bruce:
> I can locally run screen, and then run an app.
>
> If I wanted to have a process where I remotely start/run an app on a
> remote box (ssh) via screen, How is this accomplished? Can it be done?

ssh into the remote box and start screen there (screen has to be
installed on the remote box, obviously). Use the remote screen to start
the app.
> Ie, I want the app on the remote instance/box to be running in a
> screen process within a term. This would allow someone to login, fire
> up the screen process for the screen id, and see the process in
> action...

Yep, that's what the screen on the remote box accomplishes.

[bruce]

Hey Markus,

So you're saying it's basically a 2 step process:

1) -ssh remote box start Screen (with starting attributes)
2) --ssh remote box "ScreenCmd --name appToRun"

something like this??

On Fri, Jan 22, 2016 at 3:26 AM, Markus Schönhaber
 wrote:
> 22.01.2016, 01:50 CET, bruce:
> > I can locally run screen, and then run an app.
> >
> > If I wanted to have a process where I remotely start/run an app on a
> > remote box (ssh) via screen, How is this accomplished? Can it be done?
>
> ssh into the remote box and start screen there (screen has to be
> installed on the remote box, obviously). Use the remote screen to start
> the app.
> > Ie, I want the app on the remote instance/box to be running in a
> > screen process within a term. This would allow someone to login, fire
> > up the screen process for the screen id, and see the process in
> > action...
>
> Yep, that's what the screen on the remote box accomplishes.
>
> --
> Regards
>   mks
>
> --
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

[Markus Schönhaber]

Bruce, Fri, 22 Jan 2016 03:35:12 -0500:

Don't top-post!
> > ssh into the remote box and start screen there (screen has to be
> > installed on the remote box, obviously). Use the remote screen to start
> > the app.
> So you're saying it's basically a 2 step process:
> -ssh remote box start Screen (with starting attributes)
> --ssh remote box "ScreenCmd --name appToRun"
>
> something like this??

I'm not sure I understand what the above is supposed to mean.

What I meant is the following:
localbox$ ssh user@remotebox
(you're on the remotebox now)
remotebox$ screen yourapp

Or, if you don't want screen to terminate with your app, start screen
and the the app from inside screen.

[Rick Stevens]

On 01/22/2016 12:50 AM, Markus Schönhaber wrote:
> Bruce, Fri, 22 Jan 2016 03:35:12 -0500:
>
> Don't top-post!
> > > ssh into the remote box and start screen there (screen has to be
> > > installed on the remote box, obviously). Use the remote screen to start
> > > the app.
> > So you're saying it's basically a 2 step process:
> > -ssh remote box start Screen (with starting attributes)
> > --ssh remote box "ScreenCmd --name appToRun"
> >
> > something like this??
>
> I'm not sure I understand what the above is supposed to mean.
>
> What I meant is the following:
> localbox$ ssh user@remotebox
> (you're on the remotebox now)
> remotebox$ screen yourapp
>
> Or, if you don't want screen to terminate with your app, start screen
> and the the app from inside screen.

Or you could:

ssh user@remotebox "/usr/bin/screen -S name-of-your-screen-session -d 
-m command-you-want-to-run-inside-the-screen-session"

That would launch a detached screen session on the remote box that
runs "command-you-want-to-run-inside-the-screen-session" in a screen
session named "name-of-your-screen-session".

For example, I do that on a box to do a backup of some data. The "-S"
parameter I used was "adcorp-backup", and this is the result:

[root@brc3-r1 ~]# screen -ls
    There is a screen on:
    	24708.adcorp-backup	(Detached)
    1 Socket in /var/run/screen/S-root.

Should I want to check on it, I can ssh to that box and

screen -r 24708.adcorp-backup

to re-attach to the session. Once I'm done prowling around, "ctrl-a d"
detaches me again and leaves the session running.

Hope that helps.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-     I.R.S.: We've got what it takes to take what you've got!       -
----------------------------------------------------------------------

[bruce]

Thanks Rick,

Thats exactly what I was trying to get to.

The goal, I want to have a local process that iterates through a list
of long running apps.

I want to then spin up a remote instance/screen session on something
like DigitalOcean/DO where I fire up the app, running it on the remote
instance.

The Screen, should then provide a long running process, with the
ability to ssh in, or have a separate app check on the
realtime/ongoing status of the running apps..

As the process grows, I envision having a few hundred of these apps
running/testing...

So, thanks!

On Fri, Jan 22, 2016 at 1:25 PM, Rick Stevens  wrote:
> On 01/22/2016 12:50 AM, Markus Schönhaber wrote:
> > Bruce, Fri, 22 Jan 2016 03:35:12 -0500:
> >
> > Don't top-post!
> > > > ssh into the remote box and start screen there (screen has to be
> > > > installed on the remote box, obviously). Use the remote screen to start
> > > > the app.
> > > So you're saying it's basically a 2 step process:
> > > -ssh remote box start Screen (with starting attributes)
> > > --ssh remote box "ScreenCmd --name appToRun"
> > >
> > > something like this??
> >
> > I'm not sure I understand what the above is supposed to mean.
> >
> > What I meant is the following:
> > localbox$ ssh user@remotebox
> > (you're on the remotebox now)
> > remotebox$ screen yourapp
> >
> > Or, if you don't want screen to terminate with your app, start screen
> > and the the app from inside screen.
>
> Or you could:
>     ssh user@remotebox "/usr/bin/screen -S name-of-your-screen-session
>
> -d -m command-you-want-to-run-inside-the-screen-session"
>
> That would launch a detached screen session on the remote box that
> runs "command-you-want-to-run-inside-the-screen-session" in a screen
> session named "name-of-your-screen-session".
>
> For example, I do that on a box to do a backup of some data. The "-S"
> parameter I used was "adcorp-backup", and this is the result:
>     [root@brc3-r1 ~]# screen -ls
>     There is a screen on:
>             24708.adcorp-backup     (Detached)
>     1 Socket in /var/run/screen/S-root.
>
> Should I want to check on it, I can ssh to that box and
>     screen -r 24708.adcorp-backup
>
> to re-attach to the session. Once I'm done prowling around, "ctrl-a d"
> detaches me again and leaves the session running.
> Hope that helps.
> Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
>                                                                -
> I.R.S.: We've got what it takes to take what you've got!       -
>
> --
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

[Rick Stevens]

On 01/22/2016 12:00 PM, bruce wrote:
> Thanks Rick,
>
> Thats exactly what I was trying to get to.
>
> The goal, I want to have a local process that iterates through a list
> of long running apps.
>
> I want to then spin up a remote instance/screen session on something
> like DigitalOcean/DO where I fire up the app, running it on the remote
> instance.
>
> The Screen, should then provide a long running process, with the
> ability to ssh in, or have a separate app check on the
> realtime/ongoing status of the running apps..
>
> As the process grows, I envision having a few hundred of these apps
> running/testing...
>
> So, thanks!

Glad to help. I use that sort of thing in rc.local scripts as well to
launch boot-type tasks in screen sessions. Very handy.

By the way, Bruce, we prefer bottom-posting on this list if you can do
so (I think Markus already admonished you about that). It makes
following the thoughts in the thread a lot easier.
> On Fri, Jan 22, 2016 at 1:25 PM, Rick Stevens  wrote:
> > On 01/22/2016 12:50 AM, Markus Schönhaber wrote:
> > > Bruce, Fri, 22 Jan 2016 03:35:12 -0500:
> > >
> > > Don't top-post!
> > > > > ssh into the remote box and start screen there (screen has to be
> > > > > installed on the remote box, obviously). Use the remote screen to start
> > > > > the app.
> > > > So you're saying it's basically a 2 step process:
> > > > -ssh remote box start Screen (with starting attributes)
> > > > --ssh remote box "ScreenCmd --name appToRun"
> > > >
> > > > something like this??
> > >
> > > I'm not sure I understand what the above is supposed to mean.
> > >
> > > What I meant is the following:
> > > localbox$ ssh user@remotebox
> > > (you're on the remotebox now)
> > > remotebox$ screen yourapp
> > >
> > > Or, if you don't want screen to terminate with your app, start screen
> > > and the the app from inside screen.
> >
> > Or you could:
> >      ssh user@remotebox "/usr/bin/screen -S name-of-your-screen-session
> >
> > -d -m command-you-want-to-run-inside-the-screen-session"
> >
> > That would launch a detached screen session on the remote box that
> > runs "command-you-want-to-run-inside-the-screen-session" in a screen
> > session named "name-of-your-screen-session".
> >
> > For example, I do that on a box to do a backup of some data. The "-S"
> > parameter I used was "adcorp-backup", and this is the result:
> >      [root@brc3-r1 ~]# screen -ls
> >      There is a screen on:
> >              24708.adcorp-backup     (Detached)
> >      1 Socket in /var/run/screen/S-root.
> >
> > Should I want to check on it, I can ssh to that box and
> >      screen -r 24708.adcorp-backup
> >
> > to re-attach to the session. Once I'm done prowling around, "ctrl-a d"
> > detaches me again and leaves the session running.
> >
> > Hope that helps.

----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-              Careful!  Ugly strikes 9 out of 10 people!            -
----------------------------------------------------------------------

[bruce]

On Fri, Jan 22, 2016 at 3:48 PM, Rick Stevens  wrote:
> On 01/22/2016 12:00 PM, bruce wrote:
> > Thanks Rick,
> >
> > Thats exactly what I was trying to get to.
> >
> > The goal, I want to have a local process that iterates through a list
> > of long running apps.
> >
> > I want to then spin up a remote instance/screen session on something
> > like DigitalOcean/DO where I fire up the app, running it on the remote
> > instance.
> >
> > The Screen, should then provide a long running process, with the
> > ability to ssh in, or have a separate app check on the
> > realtime/ongoing status of the running apps..
> >
> > As the process grows, I envision having a few hundred of these apps
> > running/testing...
> >
> > So, thanks!
>
> Glad to help. I use that sort of thing in rc.local scripts as well to
> launch boot-type tasks in screen sessions. Very handy.
>
> By the way, Bruce, we prefer bottom-posting on this list if you can do
> so (I think Markus already admonished you about that). It makes
> following the thoughts in the thread a lot easier.
> > On Fri, Jan 22, 2016 at 1:25 PM, Rick Stevens 
> > wrote:
> > > On 01/22/2016 12:50 AM, Markus Schönhaber wrote:
> > > > Bruce, Fri, 22 Jan 2016 03:35:12 -0500:
> > > >
> > > > Don't top-post!
> > > > > > ssh into the remote box and start screen there (screen has to be
> > > > > > installed on the remote box, obviously). Use the remote screen to
> > > > > > start
> > > > > > the app.
> > > > > So you're saying it's basically a 2 step process:
> > > > > -ssh remote box start Screen (with starting attributes)
> > > > > --ssh remote box "ScreenCmd --name appToRun"
> > > > >
> > > > > something like this??
> > > >
> > > > I'm not sure I understand what the above is supposed to mean.
> > > >
> > > > What I meant is the following:
> > > > localbox$ ssh user@remotebox
> > > > (you're on the remotebox now)
> > > > remotebox$ screen yourapp
> > > >
> > > > Or, if you don't want screen to terminate with your app, start screen
> > > > and the the app from inside screen.
> > >
> > > Or you could:
> > >      ssh user@remotebox "/usr/bin/screen -S
> > >
> > > name-of-your-screen-session
> > > -d -m command-you-want-to-run-inside-the-screen-session"
> > >
> > > That would launch a detached screen session on the remote box that
> > > runs "command-you-want-to-run-inside-the-screen-session" in a screen
> > > session named "name-of-your-screen-session".
> > >
> > > For example, I do that on a box to do a backup of some data. The "-S"
> > > parameter I used was "adcorp-backup", and this is the result:
> > >      [root@brc3-r1 ~]# screen -ls
> > >      There is a screen on:
> > >              24708.adcorp-backup     (Detached)
> > >      1 Socket in /var/run/screen/S-root.
> > >
> > > Should I want to check on it, I can ssh to that box and
> > >      screen -r 24708.adcorp-backup
> > >
> > > to re-attach to the session. Once I'm done prowling around, "ctrl-a d"
> > > detaches me again and leaves the session running.
> > >
> > > Hope that helps.
> Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
>                                                                -
>          Careful!  Ugly strikes 9 out of 10 people!            -
>
> --
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

thanks!

[Patrick O'Callaghan]

On Fri, 2016-01-22 at 16:06 -0500, bruce wrote:
> thanks!

Thanks for not top-posting, but next time try to trim the quoted
material to what you're responding to. We don't need to see the entire
message all over again. That's what the list archives are for.

poc

[Cameron Simpson]

On 22Jan2016 09:50, Markus Schönhaber  wrote:
> Bruce, Fri, 22 Jan 2016 03:35:12 -0500:
> Don't top-post!
> > > ssh into the remote box and start screen there (screen has to be
> > > installed on the remote box, obviously). Use the remote screen to start
> > > the app.
> > So you're saying it's basically a 2 step process:
> > -ssh remote box start Screen (with starting attributes)
> > --ssh remote box "ScreenCmd --name appToRun"
> >
> > something like this??
>
> I'm not sure I understand what the above is supposed to mean.
>
> What I meant is the following:
> localbox$ ssh user@remotebox
> (you're on the remotebox now)
> remotebox$ screen yourapp
>
> Or, if you don't want screen to terminate with your app, start screen
> and the the app from inside screen.

Yeah, ssh to remote host, start (or resume) a named screen session with the app 
started inside it.

I use tmux instead of screen when possible, and I have a helper script named 
"tm":

https://bitbucket.org/cameron_simpson/css/src/tip/bin/tm

largely for local sessions, but it also aids using remote sessions. It has a 
"use-session-remote" operation which connects to a remote host and join (or 
create) a named session. For convenience, it will also recite a shell function 
namd "tm_remote" for accessing remote sessions, which I alias to "@":

eval "$(tm recite-function-remote)"
  alias @=tm_remote

which lets me go:

@ remote-host:SESSION_NAME

In case of disconnect, it remembers the last command, so to reconnect one just 
says:

@

Cheers,
Cameron Simpson