Hello everyone,
I'm trying to freeze paramiko using freeze.py (to freeze a program I
wrote that uses paramiko).
This requires freezing PyCrypto. Hence the problem, since many PyCrypto
components (mostly ciphers from what I could see) are compiled C
extensions, and all compiled extension mod
Hello,
Is there any way to get standard output and standard error arranged
chronologically together in one text stream as they come from ssh
server, while doing connection_object.exec_command() of course?
Sometimes you do want to separate standard output from standard error.
But sometimes yo
Hello,
There I was, happy user of SSHClient(). However, in order to use
"set_combine_stderr" method on the Channel object (thanks, Todd!), I
have to get a transport and then open channel and exec command in
channel myself.
This means I have to channel.recv() standard output from the command
james bardin wrote:
Looks like you've got the gist of it. You could also use the
chn.makefile() method to make it work like SSHClient.exec_command()
(from client.py)
Looks like not everything was done correctly: the code I posted before
did not read scp replies working in sink mode (see:
http
Sigh... It seems that scp on some platforms does indeed return smth
different than binary 0, 1 or 2 as reply. In my case ssh in question was
openssh-server-3.9p1-8.RHEL4.9 on x64 hardware, where scp returned empty
string after 'scp -t -v' command even though scp continued operation
normally (
Hello everyone,
I wrote "concurrent ssh" client using Paramiko, available here:
http://python.domeny.com/cssh.py
This program has a function for concurrent remote file/dir copying
(class SSHThread, method 'sendfile'). One thread per host specified is
started for copying (with a working queue
Hello,
I'm using paramiko to concurrently distribute large files/dirs to many
hosts.
This is heavy on CPU. Is there any way to say to SSHClient or channel or
transport what cipher to use? Which one would be recommended anyway? I
was thinking of Blowfish as it is typically recommended for scp
james bardin wrote:
On Thu, Dec 31, 2009 at 11:19 AM, Marcin Krol wrote:
Hello,
I'm using paramiko to concurrently distribute large files/dirs to many
hosts.
This is heavy on CPU. Is there any way to say to SSHClient or channel or
transport what cipher to use? Which one would be recomm
Hello James,
I'm sorry to say that it doesn't work:
james bardin wrote:
I don't there's any way to set the security options with SSHClient, so
you will have to use the Transport directly.
###
import paramiko
import socket
s = socket.socket()
s.connect(('localhost', 22))
t = param
Hello everyone,
I'm getting 'unknown cipher':
Traceback (most recent call last):
File "/usr/local/lib/python2.6/threading.py", line 522, in
__bootstrap_inner
self.run()
File "/var/www/html/cssh4.py", line 946, in run
self.ssh_connect_for_scp()
File "/var/www/html/cssh4.py", line
james bardin wrote:
On Wed, Feb 3, 2010 at 5:30 AM, Marcin Krol wrote:
Hello everyone,
I'm getting 'unknown cipher':
Are you using the latest version of paramiko (1.7.6)?
No. Silly me. I have upgraded to 1.7.6 and it works. Thanks, James!
Performance-wise:
time cssh.py
Hello everyone,
I have one host that is extremely slow to respond (30 seconds or more).
When I connect with paramiko.SSHClient() using username and password,
the connection fails immediately for some reason.
However, then I undertake 2nd connection attempt using a key. During
that time param
Hello James,
james bardin wrote:
I would use threading.Timer, and have the callback try to close the
transport. I think you need to put this around
transport.start_client().
Here's the simplest possible example:
##
s = socket.socket()
s.connect(('localhost', 22))
t = param
I'm just shooting in the dark since I can't replicate this, but you
could try to break the connection by closing the socket from
underneath the transport (stored in transport.sock).
Unfortunately, no:
def printandclose(self):
print "\ntrying to close transport.sock"
self.trans.sock.clos
james bardin wrote:
trying to close transport.sock
No handlers could be found for logger "paramiko.transport"
ERROR (9, 'Bad file descriptor')
Are you getting a stack trace here, or is paramiko eating the
exception and just printing out the ERROR line?
That's the case, that is, just the abov
Hello James,
Problem solved. It's not paramiko, I've had this loop:
# Terminating threads
while len(queue) > 0:
if opts.copy:
copyprogressindicator(lock, total, hostnum, queue,
thfinished, finalizing=True)
time.sleep(1)
queue = joinfinish
Hello James,
I swear it's real this time. :-)
So I have this code:
try:
channel = transport.open_session()
except Exception, e:
return str(e)
..and I traced execution of the program in winpdb:
1. before "channel = transport.open_session()" I have tran
Hello James,
P.S.
I ran sshd -d on that Solaris box:
This is with normal scp:
bash-2.05# /usr/lib/ssh/sshd -d
debug1: sshd version Sun_SSH_1.0
debug1: Bad RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read SSH2 private key done: name rsa w/o comment success 1
debug1: load_private_key_autode
Nikolaus Rath wrote:
Hello,
I would like to use an SFTPClient instance concurrently with several
threads, but I couldn't find any information about thread safety in the
API documentation.
- Can I just share the SFTPClient instance between several threads?
Why use SFTPClient? Its performance
Nikolaus Rath wrote:
All I need is a Python API for uploading, downloading and renaming files
over SSH. I chose SFTPClient since it seemed to be the simplest
solution, and I don't remember seeing any warnings about performance or
compatibility.
I don't know about paramiko implementation of SFT
james bardin wrote:
The main loop is a busy loop! It's hogging the GIL itself, and pegging
a cpu core at %100.
Because the threads only do work with a lock, there is no time for the
GIL to switch threads., The sleep() simply allows a few cycles for the
GIL to be released.
Oops! I didn't analyze
Eric S. Johansson wrote:
personally, I find threading to be more trouble than it is worth. I
would use the python multiprocessing module and distribute the load
across multiple processes rather than threads. Well it's never as
simple as a single thread implementation, it's far less complex and
Andrew Bennetts wrote:
If you meant “can handle many concurrent connections” instead, I'd
suggest Twisted, it tends to excel at that sort of task (and without
threads, usually). Personally, even if threads are required I'd probably
lean towards using it anyway :)
Threads are not a hard requir
23 matches
Mail list logo
