* [sup-talk] mime-view hook
@ 2009-04-23 1:11 Jon Dugan
2009-04-23 12:47 ` William Morgan
2009-04-23 17:53 ` Andrew Pimlott
0 siblings, 2 replies; 5+ messages in thread
From: Jon Dugan @ 2009-04-23 1:11 UTC (permalink / raw)
I'm running the mainline sup from git.
I have a mime-view.rb hook like this:
case content_type
when "text/html"
Redwood::log("w3m: " + '/opt/local/bin/w3m -dump -T ' + content_type + ' ' + filename)
IO.popen('-') {|f| f ? f.read : exec('/opt/local/bin/w3m', '-dump', '-T', content_type, filename)}
else
Redwood::log("dumbplumb: " + filename)
system '/Users/jdugan/projects/dumbplumb/dumbplumb', filename
end
It's supposed to render HTML in the SUP window and hand everything else off to
dumbplumb. It does hand everything else off to dumbplub, however it doesn't
do what I expect for the HTML attachments.
Whatever gets returned from the hook should be displayed, right?
I am a Ruby noob so maybe it's my Ruby that's bad. (Although I've got a lot
of experience with Python, Perl, etc...)
If I send the output of the IO.popen to Redwood::log I see what I'd expect in
the log buffer, so I have confidence in the part that is using w3m to render
the HTML.
Why didn't I use backticks (`) instead of the calls to system and exec?
To sidestep shell quoting issues. I started with backticks but attachments
with spaces and other shell meta characters were problematic.
Thanks for any suggestions,
Jon
PS: dumbplumb may be of interest. Here's the README:
dumbplumb is a simple mechanism for displaying files from remote systems
locally. it is a brain dead hack that implements something which is something
like the Plan 9 plumber but not really.
Eventually it may be reworked to actually use the plan9 port plumber, but for
now it's just dumb.
dumbplumbd listens on port 9937 on your local system for requests. dumbplumb
sends requests to dumbplumbd. ssh port forwarding is used to proxy the two
together, eg:
ssh -R 9937:localhost:9937 remotehost
You can find dumbplumb at http://bitbucket.org/jdugan/dumbplumb/
--
Jon M. Dugan <jdugan at es.net> | GTalk: jdugan.esnet
ESnet Network Engineering Group | http://www.es.net/
Lawrence Berkeley National Laboratory | http://www.lbl.gov/
^ permalink raw reply [flat|nested] 5+ messages in thread* [sup-talk] mime-view hook
2009-04-23 1:11 [sup-talk] mime-view hook Jon Dugan
@ 2009-04-23 12:47 ` William Morgan
2009-04-23 17:53 ` Andrew Pimlott
1 sibling, 0 replies; 5+ messages in thread
From: William Morgan @ 2009-04-23 12:47 UTC (permalink / raw)
Reformatted excerpts from Jon Dugan's message of 2009-04-22:
> It's supposed to render HTML in the SUP window and hand everything
> else off to dumbplumb. It does hand everything else off to dumbplub,
> however it doesn't do what I expect for the HTML attachments.
>
> Whatever gets returned from the hook should be displayed, right?
Not exactly. There are two MIME hooks, and you'll need them both for
what you're trying to do: mime-decode, for turning an attachment into
text (displayed directly in Sup), and mime-view, for launching
third-party applications to view an attachment. I've updated the docs on
these two in git to make their relationship a little more clear, but in
summary: mime-decode should return a string, or nil if uncovertable, and
mime-view should return true if the application was successful, and
false otherwise.
Note that by default Sup calls run-mailcap to view attachments it can't
convert to text, so you can make the dumbplumb behavior global by
changing your mailcap instead. (If you desire that.)
> dumbplumb is a simple mechanism for displaying files from remote
> systems locally. it is a brain dead hack that implements something
> which is something like the Plan 9 plumber but not really.
That's awesome. Very useful for Sup.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [sup-talk] mime-view hook
2009-04-23 1:11 [sup-talk] mime-view hook Jon Dugan
2009-04-23 12:47 ` William Morgan
@ 2009-04-23 17:53 ` Andrew Pimlott
2009-04-23 18:14 ` Jon Dugan
1 sibling, 1 reply; 5+ messages in thread
From: Andrew Pimlott @ 2009-04-23 17:53 UTC (permalink / raw)
On Wed, Apr 22, 2009 at 06:11:40PM -0700, Jon Dugan wrote:
> dumbplumbd listens on port 9937 on your local system for requests. dumbplumb
> sends requests to dumbplumbd. ssh port forwarding is used to proxy the two
> together, eg:
>
> ssh -R 9937:localhost:9937 remotehost
You probably realize this, but... A well-known port doesn't work for
this, because you need one plumber per display session. So the SSH
forwarding needs to use the right plumber on this end and establish a
corresponding session on the other end.
The obvious model for this is SSH agent forwarding. You'd have a
PLUMBER_SOCK variable containing the path to a unix socket, and ssh
would create a unix socket on the other end, forward it there, and set a
new PLUMBER_SOCK variable. The obstacle is, the SSH developers haven't
shown any interest in making the SSH agent forward mechanism availble to
others. See for example
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148
If you don't do this, you'll have plumbers stepping on each other, or
you'll have to manage ports manually.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* [sup-talk] mime-view hook
2009-04-23 17:53 ` Andrew Pimlott
@ 2009-04-23 18:14 ` Jon Dugan
2009-04-23 22:59 ` Andrew Pimlott
0 siblings, 1 reply; 5+ messages in thread
From: Jon Dugan @ 2009-04-23 18:14 UTC (permalink / raw)
Excerpts from Andrew Pimlott's message of Thu Apr 23 10:53:36 -0700 2009:
> On Wed, Apr 22, 2009 at 06:11:40PM -0700, Jon Dugan wrote:
> > dumbplumbd listens on port 9937 on your local system for requests. dumbplumb
> > sends requests to dumbplumbd. ssh port forwarding is used to proxy the two
> > together, eg:
> >
> > ssh -R 9937:localhost:9937 remotehost
>
> You probably realize this, but... A well-known port doesn't work for
> this, because you need one plumber per display session. So the SSH
> forwarding needs to use the right plumber on this end and establish a
> corresponding session on the other end.
That is definitely and issue and I should probably add that to the README.
However in practice it doesn't seem to be a problem for me, I only forward the
port for the first connection to my sup box. When I leave a display I log out
of the sup box thus freeing the well known port for the next display I sit at.
(Or if I forget I can log in and kill that ssh process by hand.) However, this
whole fiasco is part of the reason I call it dumb.
There is also a significant security issue which is anyone on the sup box can
send a dumbplumb request if they know what port to talk to. In my case this
is a fairly minor risk as I am the only person who uses my sup box. This too
is part of the reason I call it dumb.
> The obvious model for this is SSH agent forwarding. You'd have a
> PLUMBER_SOCK variable containing the path to a unix socket, and ssh
> would create a unix socket on the other end, forward it there, and set a
> new PLUMBER_SOCK variable. The obstacle is, the SSH developers haven't
> shown any interest in making the SSH agent forward mechanism availble to
> others. See for example
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148
>
> If you don't do this, you'll have plumbers stepping on each other, or
> you'll have to manage ports manually.
I've wanted this kind of forwarding for a long, long time. I was unaware of
the patch listed there. I'll have to take a look. This would be especially
cool if it was forwardable like the agent socket, since sometimes I have to
ssh through intermediate boxes. (But see my ssh-gw script for a cute trick
for getting around this: http://bitbucket.org/jdugan/ssh-gw/).
The unix socket forwarding would make the whole thing much, much cleaner.
One hack to work around the port collision problem is to enable environment
variable forwarding (see SendEnv in ssh_config(5)) and use that to dynamically
choose a port per session. This could be used to forward unix domain sockets
by combining this with something like socat. This, however, starts to become
a huge tangle of duct tape and bailing wire... Also SendEnv has some security
implications.
In short I'd love something less dumb, but for now this scratches an itch.
Jon
--
Jon M. Dugan <jdugan at es.net> | GTalk: jdugan.esnet
ESnet Network Engineering Group | http://www.es.net/
Lawrence Berkeley National Laboratory | http://www.lbl.gov/
^ permalink raw reply [flat|nested] 5+ messages in thread
* [sup-talk] mime-view hook
2009-04-23 18:14 ` Jon Dugan
@ 2009-04-23 22:59 ` Andrew Pimlott
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Pimlott @ 2009-04-23 22:59 UTC (permalink / raw)
On Thu, Apr 23, 2009 at 11:14:48AM -0700, Jon Dugan wrote:
> I've wanted this kind of forwarding for a long, long time. I was unaware of
> the patch listed there. I'll have to take a look. This would be especially
> cool if it was forwardable like the agent socket, since sometimes I have to
> ssh through intermediate boxes. (But see my ssh-gw script for a cute trick
> for getting around this: http://bitbucket.org/jdugan/ssh-gw/).
>
> The unix socket forwarding would make the whole thing much, much cleaner.
It's sad that this hasn't been picked up. I looked into it a while
back, and I can't remember exactly what the impediment is. It would be
an extension to the SecSH protocol, and nobody on the ssh side seems to
get the need for it (baffling to me, given ssh-agent). Even the code
that exists (AFAICT) only connects explicitly-named ports on either end.
> One hack to work around the port collision problem is to enable environment
> variable forwarding (see SendEnv in ssh_config(5)) and use that to dynamically
> choose a port per session.
Even then, you're manually managing the ports: You have to assign a
port number to every session you use; if others use the same machines
(which is unthinkable in the first place for lack of access control),
everyone's numbers have to be unique. That's just dumb--but you know
that. :-)
> In short I'd love something less dumb, but for now this scratches an itch.
Credit to you for writing it. As soon as I saw it, I knew the plumber
was the right thing, but when I ran into the forwarding problem, I gave
up. I'm glad you didn't!
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-04-23 22:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-23 1:11 [sup-talk] mime-view hook Jon Dugan
2009-04-23 12:47 ` William Morgan
2009-04-23 17:53 ` Andrew Pimlott
2009-04-23 18:14 ` Jon Dugan
2009-04-23 22:59 ` Andrew Pimlott
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox