[RFC] per-branch umask

[John A Meinel]

Robey Pointer wrote:
> 
> On 15 Dec 2005, at 21:57, John Arbash Meinel wrote:
> 
>> Robey Pointer wrote:
>>>
>>> On 15 Dec 2005, at 15:36, John Arbash Meinel wrote:
>>>
>>>> There is another issue, though. Pipelining doesn't work right away if
>>>> you are using SFTProcess (openssh instead of paramiko's connection).
>>>> Paramiko needs the function "recv_ready". Which for now I've just 
>>>> forced
>>>> with a "def recv_ready(self): return True)".
>>>> I assume that means it would block rather than being properly 
>>>> pipelined.
>>>>
>>>> On win32, I don't think I have poll() or select(), so I'll just 
>>>> have to
>>>> do True. But I think for Linux I can do poll().
>>>
>>>
>>> Oooh, good catch!  I wonder if this has been slowing down sftp  pushes.
>>> Almost certainly, but how much...
>>>
>>> Windows currently has no way to use SFTPProcess, because only unix-
>>> based ssh clients are supported, so Windows is always using  paramiko.
>>> Thus (for now) just doing a select() should work fine.
>>
>> Eventually, I would like to see putty() or maybe even cygwin ssh
>> supported.
>>
>> I don't know if you followed my posting, but I did write up a python
>> script which by using win32all and ctypes is able to talk to pageant. I
>> wasn't sure about how to integrate it into paramiko, but I was thinking
>> to look into it. I was able to request the list of agent keys, so I'm
>> pretty sure it is working.
>>
>> Pageant seems to uses Windows event messages to pass the name of a named
>> memory page to read and write from. And then the communication messages
>> are just standard ssh-agent statements (at least as much as I can tell).
>> I would like to see a little bit more privacy in the memory page names
>> (they are unique by using GetThreadId, but I don't think that makes them
>> hidden enough as also having a random number).
> 
> Yeah, I saw that, looks interesting.  I have no way to test it, but I
> did save it.  Did you get the key list using the same protocol as in
> agent.py?  If so, I can probably hook them together pretty easily. 
> (agent.py is surprisngly small.)

I did it manually, but looking at agent.py it looks almost exactly like
that is what I did.

I think I could easily write a Pageant version of Agent, which uses the
memory buffer tricks.

So what about doing it this way, have a SocketAgent and a PageantAgent,
and use something like:
if sys.platform == 'win32':
	Agent = PageantAgent
else:
	Agent = SocketAgent

That way the interface of "instantiate an Agent, and ask it for the
keys), stays the same.
Otherwise, we could refactor the internals of Agent, so it either has a
child class which is the communication method, or knows how to do both
itself. I don't really want side by side '_send_message' and
'_send_message_pageant' functions, though.

> 
> Putty SFTPProcess support would be orthogonal to pageant support,
> though.  In fact if you had putty process support, the pageant support
> would be moot.

Well, it is still probably useful since people can customize paramiko
easier than they can customize Putty. But otherwise I agree.

> 
> 
>>> [[[ idle thoughts follow:
>>> Paramiko is assuming it has a socket-like object, not a file.  You
>>> might try having recv_ready() always return False, which would force
>>> all async responses to buffer up until the file is closed.  However,  I
>>> think I've seen some sftp servers disconnect in this case -- they  keep
>>> getting requests but they can't write responses because the  responses
>>> have filled up the OS buffers and TCP windows.  Paramiko  could also be
>>> a bit smarter and track unack'd async requests, forcing  a read after
>>> some threshold is reached, but that turns into a  magickal tuning value.
>>> ]]]
>>
>> I would say that you could use some sort of buffer. So you would give
>> yourself X un-acked requests. I think even a low number like 2 or 3
>> would help a little bit with pipelining as you can have 1 being copied
>> while the next one is being requested, and another one is being
>> acknowledged, etc.
> 
> Yeah, maybe a magic tuning variable is unavoidable.  If you want to play
> with a version of paramiko with this feature, I've posted a test branch
> here:
> 
>     http://www.lag.net/paramiko/bzr/paramiko-zapf
> 
> I set the limit at 10, hoping that was a good compromise value.
> 
> robey
> 
> 

If I get the chance, I'll look at it.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051218/8b64b7fd/attachment.pgp