On Wed, Feb 28, 2018 at 9:43 AM, bruce <badouglas(a)gmail.com> wrote:
On Tue, Feb 27, 2018 at 7:54 PM, bruce <badouglas(a)gmail.com>
wrote:
> On Tue, Feb 27, 2018 at 4:40 PM, bruce <badouglas(a)gmail.com> wrote:
>> Hi.. again...
>>
>> ok..
>>
>> If I create /etc/clusters
>>
>> cat /etc/clusters
>> #clusters = testcluster
>>
>> testcluster1 -a "-t screen -r cSession" cuser(a)1.2.3.4
>>
>> cssh testcluster1 doesn't work... throws up a number of windows/terms
>> that immediately crash..
>>
>> However, running
>> testcluster1 -a "-t screen -r cSession" cuser(a)1.2.3.4
>> from the cmdline does work...
>>
>> and it displays the term/window in the running screen session..
>>
>> So, got 2 questions/issues...
>>
>> 1- is there a way to get this to work in the config file??
>> 2- running from the cmdline works.. but when I do a " ctrlA-d to get
>> out of the screen session.. I also kill the term!
>> Is there a way to be able to "launch the screen" but also be able
>> to kill the screen session, returning to the
>> shell if the cssh/window...
>> I could prob run some quick/dirty shell script to fire up the
>> screen session.. within the window when it gets launched..
>> but that seems kludgy..
>>
>> thoughts/comments..
>>
>> thanks
>>
>>
>>
>>
>>
>> On Tue, Feb 27, 2018 at 2:44 PM, bruce <badouglas(a)gmail.com> wrote:
>>> Hi.
>>>
>>> Testing the cssh process.
>>>
>>> I configured the /etc/clusters file to have
>>> -testcluser foo(a)1.2.3.4
>>>
>>> As user 'foo' I run -- cssh testuser
>>>
>>> Process returns:
>>> Connection to server failed -- (version 11.0)
>>> No protocol specified
>>> at /usr/bin/cssh line 2152
>>>
>>> As a test, logged in as root ran the same thing.. a term displayed.
>>>
>>> So, I've got something misconfigured on the local to run the gui
process.
>>>
>>> In the /etc/ssh/ssh_config I tested with both
>>> ForwardX11 yes/no <<<<
>>>
>>> with no difference
>>>
>>> Looking through the 'net I se a number of possible issues, but as I
>>> currently work through them, no change.
>>>
>>> Thoughts/comments??
>>>
>>> Thanks
>
>
> Followup...
>
> Tried to see if it's possible to use cssh to "run" an initial cmd upon
> launch. Unable to get it to work.
>
> The following was used.
>
> cssh -debug 1 --title '11' -a '/home/crawl_user/cssh1.php'
crawl_user@1,2,3,4
>
> This is run on the local, to invoke a term/window for the remote.
>
> The test cssh1.php is a simple php using an input screenSession name
> to run/generate the screenSession on the remote.
>
> #!/usr/bin/php
> <?php
>
> /*
> cssh1.php
> */
>
> $t=$argv[1];
> //print $t."\n";
> $t="screen -r ".$t;
> `$t &`;
>
> ?>
>
> In running the cssh, I get ::
> Loading keymaps and keycodes
> Warning: Tried to connect to session manager, None of the
> authentication protocols specified are supported
> 159.203.188.67 session closed
>
> where the term/window is displayed for a sec and then dies.
>
> by the way, running
>
> cssh --title '252' -a "-t screen -r crawl2Session"
crawl_user(a)1.2.3.4 &
>
> works as expected with the term fired up and the screen session running.
>
> Any thoughts on what's missing with the attempt as passing arg to the
> php to get it to run remotely?
>
> Thanks
ok.....
Here's where the testing is now... using cssh, the process can fire up
a term, and display a different screen session, so the user can
essentially see/view a number of terms, each showing a different
screenSession.
(still cant figure out how to invoke a term, and kill the
screenSession - (ctrlA-d and get to the cmd prompt) - the ctrlA-d
kills the term!!)
I'm also unable to figure out how to get the displayed cssh
terms/windows to "tile" correctly. They essentially get displayed over
each other..
the test cssh cmds:
cssh -G --title '111' -a "-t screen -r crawl1Session" cuser(a)1.2.3.4
&
cssh -G --title '252' -a "-t screen -r crawl3Session" cuser(a)1.2.3.4
&
As far as I can see, this should work.. it appears to be similar to
what others online have presented.
thoughts/comments??
the ~/.csshrc contains:
#always_tiling=yes
auto_quit=yes
command=
comms=ssh
console_position=
extra_cluster_file=
history_height=10
history_width=40
key_addhost=Control-Shift-plus
key_clientname=Alt-n
key_history=Alt-h
key_paste=Control-v
key_quit=Control-q
key_retilehosts=Alt-r
max_addhost_menu_cluster_items=6
max_host_menu_items=30
menu_host_autotearoff=0
menu_send_autotearoff=0
method=ssh
mouse_paste=Button-2
rsh_args=
screen_reserve_bottom=60
screen_reserve_left=0
screen_reserve_right=0
screen_reserve_top=0
send_menu_xml_file=/home/crawl_user/.csshrc_send_menu
show_history=0
ssh=/usr/bin/ssh
ssh_args= -x -o ConnectTimeout=10
telnet_args=
terminal=/usr/bin/xterm
terminal_allow_send_events=-xrm '*.VT100.allowSendEvents:true'
terminal_args=
terminal_bg_style=dark
terminal_colorize=1
terminal_decoration_height=10
terminal_decoration_width=8
terminal_font=6x13
terminal_reserve_bottom=0
terminal_reserve_left=0 #5
terminal_reserve_right=0
terminal_reserve_top= #5
terminal_size=80x24
terminal_title_opt=-T
title=CSSH
unmap_on_redraw=no
use_hotkeys=yes
window_tiling=yes
window_tiling_direction=right
aha...getting closer.....
in the /etc/clusters ifle...
--------------------------------------------------------------------------
#clusters = testcluster
testcluster1 crawl_user@159.203.188.67:--title '11' -a "-t screen -r
crawl1Session" crawl_user@159.203.188.67:--title '22' -a "-t screen
-r crawl1Session"
testcluster2 crawl_user(a)159.203.188.67 crawl_user(a)159.203.188.67
--------------------------------------------------------
so running cssh testclusert2 from the cmdline.. generates 2
term/windows as expected..
however, running the cssh testclusert1 throws up a bunch of terms that
display/die/etc..
It's now apparent that the "attributes" used -->--title '11' -a
"-t
screen -r crawl1Session"
aren't being applied to the host.
So the question is.. how does one set up the /etc/clusters file to map
the attributes to the user@host
i'm sure this is simple to resolve.. but havent seen the syntax yet..