Re: [Fab-user] status of "occasional droped lines of output" bug 32

[Steve Steiner (listsin)]

On Aug 9, 2009, at 5:50 PM, Jeff Forcier wrote:
> > Cool idea, though.  Finding "the fabric installation dir where I'm  
> > to run my
> > dir/ls command" is probably not going to be that much fun ;-0.
>
> How so? I was just thinking of using e.g. os.path.dirname(__file__).
> Since we're SSHing to localhost and running the test from localhost,
> that ought to get us what we need, unless I'm missing something.

I was more thinking of the various ssh types of ssh servers you might  
run into and where they might leave you file-system-wise.

Like, can you even locally ssh into yourself on Windows?  Are most  
people running linux boxes running ssh servers?  I do on my servers,  
but not on my dev laptop, for example.

> > IOW, a test against a known host on the Internet lets us test the  
> > whole
> > stack, against a known quantity, and gives the fewest variables in  
> > all
> > tests.
>
> Valid points. After thinking about it, I'm not sure I'm happy with the
> idea of opening up even a limited user to the public, however =/ call
> me paranoid but it's just asking for me to get rooted because of some
> silly vulnerability in "ls" or whatever the user is given access to.
>
> I know that in the past there used to be free "get an SSH shell for
> doing IRC or whatever" hosts out there; if those still exist they
> might potentially come in handy for this. Not sure I have the $$$ for
> another full-fledged "sandbox" VPS for this purpose, which would of
> course be another solution. (I'd rather not ask people for handouts on
> this either, but that's not to say I would turn down a
> guaranteed-to-be-valid-for-the-long-term offer :))

I understand completely.  In my other life, I run a hosting/web  
development company so I'm way more familiar with that "paranoid"  
feeling.  You're not paranoid...they *actually are* out to get you!

> > Writing mock objects for easily created real-life objects has  
> > never, in my
> > experience, been worth the effort.  This is especially true now when
> > real-life resources are so cheap and easy to set up.
>
> I agree in principle; for *now* I was (surprisingly) able to easily
> test this particular issue by mocking the SSH channel object, but I'm
> definitely still open to the "live test" setup once it becomes
> necessary. Once the "easy to mock" turns into "kind of a pain to mock"
> or "oh god I hate mocking" :)

Understood.  I'm working on a project now where mocking the servers  
would be almost more work than the product itself.  The server side  
will accept requests and return responses in XML or JSON, things have  
rate limits, timeouts, changing status (think building a cloud  
server), etc.  I just told them they'd have to give me an account to  
test it against...

I wish I had a test to run for you on this but I've not seen this  
problem.

Regards,

S