On Wed, Feb 28, 2018 at 9:43 AM, bruce <badouglas@xxxxxxxxx> wrote: > On Tue, Feb 27, 2018 at 7:54 PM, bruce <badouglas@xxxxxxxxx> wrote: >> On Tue, Feb 27, 2018 at 4:40 PM, bruce <badouglas@xxxxxxxxx> wrote: >>> Hi.. again... >>> >>> ok.. >>> >>> If I create /etc/clusters >>> >>> cat /etc/clusters >>> #clusters = testcluster >>> >>> testcluster1 -a "-t screen -r cSession" cuser@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@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@xxxxxxxxx> wrote: >>>> Hi. >>>> >>>> Testing the cssh process. >>>> >>>> I configured the /etc/clusters file to have >>>> -testcluser foo@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@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@1.2.3.4 & > cssh -G --title '252' -a "-t screen -r crawl3Session" cuser@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@159.203.188.67 crawl_user@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.. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
