updating release notes for 0.23
[monkeysphere.git] / website / bugs / cssh-connection-timeout.mdwn
1 [[meta title="Monkeysphere interferes with clusterssh"]]
2
3 clusterssh is a package that allows you to control multiple ssh xterm
4 sessions at the same time.
5
6 When the monkeysphere-ssh-proxycommand is enabled and I launch 5 or more
7 cssh sessions, intermittently one or two out of every five will fail
8 with: Connection timed out during banner exchange.
9
10 I tried to debug by running:
11
12     MONKEYSPHERE_LOG_LEVEL=debug cssh -D -d <server1> <server2> etc.
13
14 However, while it produced some private data, it didn't give me any
15 insight into what was going wrong. Also, it didn't output any
16 Monkeysphere debugging info.
17
18 I had no luck with google and the error message being output.
19
20 This isn't a huge priority (it's not hard to disable the
21 monkeysphere-ssh-proxycommand before running cssh), however, it would be
22 nice to figure out why it's not working.
23
24 ---
25
26 What do you mean by "produced some private data" when you set the log
27 level to DEBUG?  Monkeysphere does not output any "private" data in
28 the sense of private keys or passwords or anything like that.  Maybe
29 you mean the cssh debug mode outputs private data?  or do you just
30 mean "info that you don't want to post here"?  It might be useful to
31 see some output, so maybe you could just block out the nasty bits?
32 But I'm not sure it will help.
33
34 The problem may be due to the locking of the known\_hosts file while
35 the proxycommand is running.  At the moment, the
36 monkeysphere-ssh-proxycommand can only be run serially, since each
37 invocation will lock the known\_hosts file while it updates it.  I
38 think this is required, since we obviously can't have two invocations
39 modifying the file at the same time.  However, it's probably possible
40 to decrease the amount of time it takes to update the file.  It's not
41 done very efficiently at the moment.  The file is locked basically at
42 the very begining, and is locked while all gpg interactions are done,
43 which are slow.  I think it should be possible to take the gpg
44 interactions out of the loop.
45
46 I just tried cssh and it doesn't seem to work very well with my ssh
47 setup at all.  For instance, the simultaneous ssh connections cause
48 simultaneous calls to the agent to get my permission to use the key,
49 which don't interact very well with each other.  This of course is not
50 a monkeysphere problem but a general problem with trying to make
51 simultaneous ssh connections with an agent that want key use
52 confirmation.
53
54 -- jrollins
55
56 ---
57
58 I can get cssh to work fine with a confirmation-required agent if i
59 turn off the monkeysphere proxycommand:
60
61     cssh -l username -o '-oProxyCommand=none' $(cat hostlist.txt)
62
63 with the proxycommand, i definitely get the "Connection timed out
64 during banner exchange" message.
65
66 However, i'm also able to get the cssh connection to work if i assert
67 that a longer connection timeout is acceptable:
68
69     cssh -l username -o '-oConnectTimeout=30' $(cat hostlist.txt)
70
71 Perhaps this is an acceptable workaround?
72
73 -- dkg
74
75 ---
76
77 Sorry for not being more clear. Monkeysphere debug does not reveal personal
78 information - but cluster cssh -d -D exposes the hosts in my ssh config file.
79
80 dkg's approach seems to work. His suggestion, as written, didn't work for me.
81 But that's because I ran cssh -u > $HOME/.csshrc, which generates a default
82 cssh config file (that specifies ConnectTimeout=10). That file seems to
83 override the command linke (perhaps a cssh bug?). I changed the ConnectTimeout
84 to 30 in my ~/.csshrc file and now everything works. 
85
86 I think jrollins' assessment is probably right - the extra delay due to locking
87 causes the timeout. I think tweaking ConnectTimeout parameter via the .csshrc
88 file or via the command line is a reasonable fix for this bug, so I'm closing
89 as [[bugs/done]].
90
91 -- Sir Jam Jam
92
93 I just [posted the cssh bug in debian](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498968).