linux/devops resource - $$

[bruce]

Hi guys...

Still trying to resolve my ssh/screen/remote cmd issue.

If anyone knows of anyone with centos/devops skills that wants to make
a few $$$ for what should be 5-10 mins of work.

Let me know.

The basic prob scope:

User on a local machine, needs/wants to ssh into a remote box, and set
up a screen session.

Using the same remote screen session, the user wants to run a 2nd ssh
into the box, and run a long running process using the same screen
session.

Creating the initial ssh/screen session 'testname' is trivial.

Crafting the next ssh/screen shell script to implement the long
running cmd so it's running inside the screen, and then returning cmd
to the calling term is a bit an issue.

The process needs to essentially:
ssh into the remote box
reattach to the existing screen
run the long running process within the screen env
detach from the screen session (while the long running cmd is running)
return control to the calling term/cmd..

This then allows other users/process to then reattach as needed to the
remote screen session, and to view/track the generated output from
the long running cmd/process...

If you know anyone with skills in the area of
linux/devops/sysAdmin/etc.. who wants to make a few $$$ for a few
mins of help, let me know!

Thanks...

-bruce

[Christopher Cprek]

I prefer tmux over screen, so I don't know the full scope of screen's features and limitations. But I know you can share named sessions in tmux. Maybe tmux is a better solution for you. 

https://www.howtoforge.com/sharing-terminal-sessions-with-tmux-and-screen

/$0.02

-bruce

--
You received this message because you are subscribed to the Google Groups "LVL1 - Louisville's Hackerspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lvl1+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bruce]

Thanks...

But for now.. want a screen based solution!

It really shouldn't be this much of an issue.. so I suspect there's
something subtle I'm missing..

>> email to lvl1+uns...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "LVL1 - Louisville's Hackerspace" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to lvl1+uns...@googlegroups.com.

[d.s.]

So you are trying to solve a problem that is not really solvable using screen. Screen doesn't produce stdin/stdout friendly output, and applications that are started within screen can not push their stdio to screen' stdio since screen does all of the magic to magic screen output and emulation.

So with that in might you have to understand that you can not script the interactive tid-bits of screen. You have to use something like expect AND you have to be able to handle the screen-escape codes.

The simplest thing I can think of, is start screen, then launch a shell script with the command that you want as a param. 

The shell script will redirect the stdio of the running program to a file.

When the program is done running the script will output the status code as the last character in the file.

If the file already exists the shell script simply exits.

You can start screen with '-r <session name>' to re-attach.

So here is a basic shell script that does that.

#!/bin/sh

if [ $# -lt 1 ]; then

    echo '$0: <exec> [params for exec]'

    exit 1

fi

if [ -f /tmp/output.file ]; then

    echo "outputfile already exists, another instance still running? or just remove '/tmp/output.file' if you are sure"

    exit 1

fi

if [ ! -e `which $1` ]; then

    echo "$1 does not exist or is not an executable"

    exit 1

fi

( $* ) 0>>/tmp/output.file 1>>/tmp/output.file; echo $? >> /tmp/output.file

Now outside of screen, you can check the contents of the /tmp/output.file to see if it's done or what ever not and don't forget to remove it.

(I would just write a simple python daemon that would look for a file. If it exist assume that it's contents is a command line to execute, once done it replaces contents of file with output status.)

If you are willing to donate $100 to your local favorite 501(c)(3), I can put in the time to actually implement this solution for you using python or I can even write a c based daemon.

It's about 3 hours of work.

-bruce

--
You received this message because you are subscribed to the Google Groups "LVL1 - Louisville's Hackerspace" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lvl1+unsubscribe@googlegroups.com.

[bruce]

Hey ds.

Thanks for the reply.

I think this works....

//--fire up the named screen session..
ssh crawl...@192.81.214.49 "screen -d -m -S 'testname' "

//fire up the "long running cmd....
ssh -t crawl...@192.81.214.49 "screen -r -S testname -X stuff
'sleep 60'$(echo -ne '\015') "

i've tested this with sleeping of different times, as well as diff sys
commands.. it seems to work ok...

I'll do more testing of course!

I've been able to do the proc tbl (ps) to see that the cmds are being
run.. and in checking the screen/session.. it is definitely detached.

As a check to ensure that this really works... I did a sleep test,
without the echo -ne '\015' -- which generates the newline..

This checked out that the screen session was attached...

So, I think this is ok...

Thoughts/Comments

>> email to lvl1+uns...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "LVL1 - Louisville's Hackerspace" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to lvl1+uns...@googlegroups.com.