website/bugs/monkeysphere-ssh-proxycommand-quiet-option.mdwn

   1 I don't mind the monkeysphere-ssh-proxycommand output on regular connections.
   2
   3 For me it looks something like this with a server not participating in the
   4 monkey sphere:
   5
   6                 ms: processing host: chavez.mayfirst.org
   7                 ms:   - key not found.
   8
   9 And like this for a server participating:
  10
  11                 ms: processing host: george.riseup.net
  12                 ms:  primary key found: 7353A74E3B757F8C
  13                 ms:   * acceptable key found.
  14                 ms: known_hosts file updated.
  15
  16 However, I have some batch scripts that run ssh that also provide
  17 output, so the monkeysphere output clutters things up.
  18
  19 I would really like to either have a -q/--quiet option, or, preferable for me
  20 at least, would be for silent output to be the default and have a -v/--verbose
  21 option to get the output. Or - maybe these should be environmental variables?
  22 In any event - someway to suppress informational output would be a useful
  23 improvement.
  24
  25 ------
  26
  27 I'd be fine with silent mode as a default, with a more verbose mode
  28 accessible to the user who desires it.
  29
  30 I'd prefer an environment variable (e.g. `MONKEYSPHERE_VERBOSE` or
  31 `MONKEYSPHERE_DEBUG`) over a command-line (e.g. `--verbose`) option,
  32 personally.  It's more in keeping with the model we've used in general
  33 so far.
  34
  35 --dkg
  36
  37 ------
  38
  39 I just completed this feature. I published it to a separate branch
  40 (called quiet-mode). I haven't committed it to my master branch for a
  41 couple reasons:
  42
  43  * I made some significant changes and wanted to ask Big Jimmy to take
  44  a look since it's mostly his stuff I mucked about with.
  45
  46  * Sometime between starting my hacking and mid-way through, my
  47  ~.ssh/known_hosts file got truncted to nothing. I recovered from a
  48  backup. I couldn't figure out what caused that to happen and couldn't
  49  replicate it. I was debugging my bash and what I was debugging
  50  involved bash redirection, so it's reasonable to think that something
  51  I did caused the problem. However, before committing we incorporate
  52  this, I would appreciate another set of eyes on my code to make sure
  53  I'm not doing something dangerous or just dumb :).
  54
  55 Here's an overview of what I did:
  56
  57 There were two function defined in common that handle sending messages
  58 to the user: log and loge. They both echo the argument passed to
  59 standard error. The first one also echo's "ms: " (as a preface to the
  60 message).  loge was only called in two places and I think is left over
  61 cruft (let me know if I'm wrong please!).
  62
  63 I've added drop in replacement functions: notice, info, and
  64 debug. I've replaced all instances of log and loge with info.
  65
  66 If you use notice, your message will always be sent to standard error.
  67 If you use info, it will be sent to standard error if the env variable
  68 `MONKEYSPHERE_OUTPUT_QUIET` is set to off (it is off by default).  If
  69 you use debug, it will be sent to standard error only if
  70 `MONKEYSPHERE_OUTPUT_DEBUG` is set to on (it's off by default).
  71
  72 Lastly, in monkeysphere-ssh-proxycommand, I've set
  73 `MONKEYSPHERE_QUIET_MODE` to on by default.
  74
  75 So the result is: when using monkeysphere-ssh-proxycommand, you will
  76 not get any output unless you set `MONEKYSPHERE_OUTPUT_QUIET` to off
  77 or `MONKEYSPHERE_OUTPUT_DEBUG` to on. All other commands should work
  78 exactly like they did in the past.
  79
  80 And... we can go through the code and change calls to the info
  81 function to either notice (if we want them to be sent regardless of
  82 the `QUIET` variable) or debug (if we want it only sent if `DEBUG` is
  83 set).
  84
  85 I'm open to suggestions, problems, etc :).
  86
  87 -- SJJ
  88
  89 ------
  90
  91 Hey, your Royal Highness.  I do think it's good that I look over these
  92 changes, because there are definitely some stuff (ie. key processing)
  93 that requires that things go to stderr and definitely not to stdout.
  94 I can see that if that were changed, it's possible that things could
  95 go wrong (ie. cause a `known_hosts` file to get truncated maybe).
  96
  97 I have to say that I'm still not sure I totally see why it's necessary
  98 to implement such nuanced output switches.  All of the stuff you were
  99 worried about when you reported this bug, and all the stuff that
 100 starts with "ms:", goes to stderr.  If you didn't want to see it, can
 101 you not just redirect stderr to /dev/null?
 102
 103 For what it's worth, I'm not sure *I* can ever imagine *not* wanting
 104 to see that stuff, since it effectively reports on whether the host
 105 you're connecting to is acceptable or not.  I feel like I would always
 106 want to see that.  I guess that's neither here nor there, though,
 107 cause if a user thinks it would be a good switch to have, and it's not
 108 too difficult to implement (as this is), then it's worth implementing.
 109
 110 I think before we really start trying to tackle this, though, we
 111 should outline what is the behavior we ultimately want.  What output
 112 do we want to go to stdout, and do we want to be able to turn that off
 113 or on?  What output do we want to go to stderr, and do we want to be
 114 able to turn that off or on?  At the moment, most output is really
 115 just info for the user, which is why I was sending it all to stderr.
 116 Should all output then just go to stderr, with a switch to either turn
 117 it off or on?
 118
 119 I should point out that we're sort of hitting a bit of a bash
 120 limitation here.  Some monkeysphere internal functions pass info on to
 121 other stuff via stdout, but also need to report stuff to the user as
 122 well, which means this stuff can only be passed to the user via
 123 stderr.
 124
 125 In any event, I just want to outline a straightforward policy about
 126 output so we can know how to best handle it.
 127
 128 -- Big Jimmy.