All,
Another critical issue that should be a priority for the R14 release is to finally have a working sftp. I just check and it is still broken:
http://www.3111skyline.com/dl/dt/trinity/ss/sftp-kio-err.jpg
However, I did capture a log from the command line that might help. It looks like there is a blank field '' that might be the culprit.
http://www.3111skyline.com/dl/dt/tde/err/sftp-kio/sftp-output.txt
Can someone give me a functional flow as to how the sftp-kio gets called? I doubt I'll be able to do anything, but at least I can look....
On 04/20/2012 08:02 PM, David C. Rankin wrote:
All,
Another critical issue that should be a priority for the R14 release is to finally have a working sftp. I just check and it is still broken:
http://www.3111skyline.com/dl/dt/trinity/ss/sftp-kio-err.jpg
However, I did capture a log from the command line that might help. It looks like there is a blank field '' that might be the culprit.
http://www.3111skyline.com/dl/dt/tde/err/sftp-kio/sftp-output.txt
Can someone give me a functional flow as to how the sftp-kio gets called? I doubt I'll be able to do anything, but at least I can look....
Is there a flag I can turn on during tdelibs/tdebase build that will make konqueror command line output much more verbose when loading the sftp-kio?? Something equivalent to setting a --debug flag?? That would help capture more information for the sftp-kio debug.. Does something like that exist?
Is there a flag I can turn on during tdelibs/tdebase build that will make konqueror command line output much more verbose when loading the sftp-kio?? Something equivalent to setting a --debug flag?? That would help capture more information for the sftp-kio debug.. Does something like that exist?
Use kdebugdialog. Enable every check box and you'll have an xsession log that will fill quickly.
To restore your xsession log thereafter, delete $TDEHOME/share/config/kdebugrc.
Darrell
On 04/20/2012 09:51 PM, Darrell Anderson wrote:
Use kdebugdialog. Enable every check box and you'll have an xsession log that will fill quickly.
To restore your xsession log thereafter, delete $TDEHOME/share/config/kdebugrc.
Darrell
Thanks Darrell,
I've just started looking at the sftp kio code. It's Greek.... The tough part is all the errors are spit out by some other part of tdebase and not the kio files, so I can't grep errors and find anything....
On 04/20/2012 11:03 PM, David C. Rankin wrote:
On 04/20/2012 09:51 PM, Darrell Anderson wrote:
Use kdebugdialog. Enable every check box and you'll have an xsession log that will fill quickly.
To restore your xsession log thereafter, delete $TDEHOME/share/config/kdebugrc.
Darrell
Thanks Darrell,
I've just started looking at the sftp kio code. It's Greek.... The tough part is all the errors are spit out by some other part of tdebase and not the kio files, so I can't grep errors and find anything....
That is really strange,
Even though I can capture errors from the command line, kdebugdialog will not cause any of the sftp or fish messages to be written to .xsession-errors. There may be more wrong with kio than meets the eye. When I log command line errors, I get:
konqtree: KonqSidebarDirTree::slotListingStopped file:/// konqtree: m_selectAfterOpening konqueror: url sftp://nirvana.3111skyline.com filtered into sftp://nirvana.3111skyline.com konqueror: KonqMainWindow::openURL : url = 'sftp://nirvana.3111skyline.com' serviceType='' req=[typedURL=sftp://nirvana.3111skyline.com newTabInFront] view=(nil) konqueror: trying openView for sftp://nirvana.3111skyline.com (serviceType ) konqueror: Creating new konqrun for sftp://nirvana.3111skyline.com req.typedURL=sftp://nirvana.3111skyline.com kio (KIOJob): stat sftp://nirvana.3111skyline.com kio (KIOJob): needs a msg box kio (KIOJob): messageBox 5 Error encountered while talking to ssh. - Unexpected SFTP error: 2 kio (KIOJob): kio_uiserver registered kio (KIOJob): SlaveInterface::messageBox m_progressId=89 konqueror: Observer::messageBox 5 Error encountered while talking to ssh. - Unexpected SFTP error: 2
but, there is nothing that is logged to .xsession-errors? Huh?
On 04/20/2012 11:23 PM, Darrell Anderson wrote:
That is really strange,
but, there is nothing that is logged to .xsession-errors? Huh?
There might not be any kdebug strings to parse....
Darrell
Makes sense,
Also, I've notices I get the same Unexpected error talking to ssh messages when I use 'fish://', but fish connects just fine. The plot thickens...
libkonq: ## addToHistory: fish://archangel.3111skyline.com/ Typed URL: fish://archangel.3111skyline.com/, Title: konqueror: KonqMainWindow::openView ok=true bOthersFollowed=false returning true libkonq: Previews disabled for protocol fish konqueror: KonqKfmIconView::slotRenderingFinished() konqueror: KonqKfmIconView completed() after rendering libkonq: ## addToHistory: fish://archangel.3111skyline.com/ Typed URL: fish://archangel.3111skyline.com/, Title: fish://archangel.3111skyline.com/ konqueror: KonqMainWindow::slotRunFinished() kio (KIOJob): needs a msg box kio (KIOJob): messageBox 5 Error encountered while talking to ssh. - Unexpected SFTP error: 2 kio (KIOJob): kio_uiserver registered kio (KIOJob): SlaveInterface::messageBox m_progressId=98 konqueror: Observer::messageBox 5 Error encountered while talking to ssh. - Unexpected SFTP error: 2 kio (KIOJob): 0x2b67bf0 SlaveInterface result=1 kio (KIOJob): error 51 Error encountered while talking to ssh. konqueror: emit m_extension->openURLRequest( fish://archangel.3111skyline.com/tmp,inode/directory) konqueror: KonqMainWindow::slotOpenURLRequest frameName= konqueror: KonqMainWindow::openURL (from slotOpenURLRequest) url=fish://archangel.3111skyline.com/tmp konqueror: KonqMainWindow::openURL : url = 'fish://archangel.3111skyline.com/tmp' serviceType='inode/directory' req=[] view=0x29894e0 konqueror: trying openView for fish://archangel.3111skyline.com/tmp (serviceType inode/directory) konqueror: KonqMainWindow::openView inode/directory fish://archangel.3111skyline.com/tmp 0x29894e0 req:[] konqueror: KonqMainWindow::openView inode/directory fish://archangel.3111skyline.com/tmp 0x2924600 req:[followMode] konqueror: KonqView::openURL url=fish://archangel.3111skyline.com/tmp locationBarURL=fish://archangel.3111skyline.com/tmp konqtree: KonqDirTree::followURL: fish://archangel.3111skyline.com/tmp
CALVIN, ROBERT -- HELP!!
Also, I've notices I get the same Unexpected error talking to ssh messages when I use 'fish://', but fish connects just fine. The plot thickens...
Do you have a KDE3 system to compare outputs?
I have both desktops but I never used sftp. Only fish.
I could run dual tests, but I need a punch list of what to check and watch.
Darrell
On 04/20/2012 11:56 PM, Darrell Anderson wrote:
Do you have a KDE3 system to compare outputs?
I have both desktops but I never used sftp. Only fish.
I could run dual tests, but I need a punch list of what to check and watch.
Darrell
The opensuse boxes all broke during Oct. 2010 and that has never been fixed. I'm fairly certain the problem is openssh >= 5.6. Since kde3 was a bastard child desktop at that time, all bugs I filed with kde.org, simple got pooh-poohed on the list and in the bug tracker. Robert & Serghei had talked about completely re-writing the sftp kio when cmake transition was completed. I don't know whatever became of that effort. But, I can confirm -- It's still needed :)
sftp-kio bug report: http://bugs.pearsoncomputing.net/show_bug.cgi?id=897
Now that might be a stupid question, but do sftp:// and fish:// provide the same functionality?
nik
Am Samstag, 21. April 2012 schrieb David C. Rankin:
On 04/20/2012 11:23 PM, Darrell Anderson wrote:
That is really strange,
but, there is nothing that is logged to .xsession-errors? Huh?
There might not be any kdebug strings to parse....
Darrell
Makes sense,
Also, I've notices I get the same Unexpected error talking to ssh messages when I use 'fish://', but fish connects just fine. The plot thickens...
libkonq: ## addToHistory: fish://archangel.3111skyline.com/ Typed URL: fish://archangel.3111skyline.com/, Title: konqueror: KonqMainWindow::openView ok=true bOthersFollowed=false returning true libkonq: Previews disabled for protocol fish konqueror: KonqKfmIconView::slotRenderingFinished() konqueror: KonqKfmIconView completed() after rendering libkonq: ## addToHistory: fish://archangel.3111skyline.com/ Typed URL: fish://archangel.3111skyline.com/, Title: fish://archangel.3111skyline.com/ konqueror: KonqMainWindow::slotRunFinished() kio (KIOJob): needs a msg box kio (KIOJob): messageBox 5 Error encountered while talking to ssh. - Unexpected SFTP error: 2 kio (KIOJob): kio_uiserver registered kio (KIOJob): SlaveInterface::messageBox m_progressId=98 konqueror: Observer::messageBox 5 Error encountered while talking to ssh. - Unexpected SFTP error: 2 kio (KIOJob): 0x2b67bf0 SlaveInterface result=1 kio (KIOJob): error 51 Error encountered while talking to ssh. konqueror: emit m_extension->openURLRequest( fish://archangel.3111skyline.com/tmp,inode/directory) konqueror: KonqMainWindow::slotOpenURLRequest frameName= konqueror: KonqMainWindow::openURL (from slotOpenURLRequest) url=fish://archangel.3111skyline.com/tmp konqueror: KonqMainWindow::openURL : url = 'fish://archangel.3111skyline.com/tmp' serviceType='inode/directory' req=[] view=0x29894e0 konqueror: trying openView for fish://archangel.3111skyline.com/tmp (serviceType inode/directory) konqueror: KonqMainWindow::openView inode/directory fish://archangel.3111skyline.com/tmp 0x29894e0 req:[] konqueror: KonqMainWindow::openView inode/directory fish://archangel.3111skyline.com/tmp 0x2924600 req:[followMode] konqueror: KonqView::openURL url=fish://archangel.3111skyline.com/tmp locationBarURL=fish://archangel.3111skyline.com/tmp konqtree: KonqDirTree::followURL: fish://archangel.3111skyline.com/tmp
CALVIN, ROBERT -- HELP!!
On Saturday 21 April 2012 23:24:23 Mag. Dr. Nikolaus Klepp wrote:
Now that might be a stupid question, but do sftp:// and fish:// provide the same functionality?
More or less. If you have a restricted shell like scponly, I think fish will not working.
nik
On 04/21/2012 04:30 PM, Serghei Amelian wrote:
On Saturday 21 April 2012 23:24:23 Mag. Dr. Nikolaus Klepp wrote:
Now that might be a stupid question, but do sftp:// and fish:// provide the same functionality?
More or less. If you have a restricted shell like scponly, I think fish will not working.
nik
I corresponded with Andreas Schneider, the person who rewrote kde4 sftp-kio, kde4 was a complete rewrite:
<quote>
kio_sftp in KDE4 has been rewritten using libssh. I don't know the process calling code, so you're on your own. Sorry ...
</quote>
So it looks like that is the recommended direction. A complete re-write is way beyond me, so we will need the skill of the c/c++ gurus to help with this bug.
As for the original question above, sftp:// has always been more reliable than the fish:// protocol. You can google 'fish:// kde3 error' (or sftp for that matter) and see what I mean. Since one of the most valuable capabilities provided by kde3/TDE was seemless remote operation, this is a big issue. konqueror, kwite, and kate all make use of this capability (quanta+ provides its own workaround, but it is also broken due to the same sftp-kio issue).
On 04/22/2012 06:59 PM, David C. Rankin wrote:
So it looks like that is the recommended direction. A complete re-write is way beyond me, so we will need the skill of the c/c++ gurus to help with this bug.
Can someone who knows the openssh responses (as well as c++), help take a look at the top of ksshprocess.cpp -- we might avoid a complete rewrite if we can update the response tables for the newer versions of openssh. ksshprocess does response lookups depending on the openssh version. If this has been the problem all along -- we may be able to put off the complete rewrite and fix sftp:// for 3.5.14.
On 04/22/2012 06:59 PM, David C. Rankin wrote:
So it looks like that is the recommended direction. A complete re-write is way beyond me, so we will need the skill of the c/c++ gurus to help with this bug.
Can someone who knows the openssh responses (as well as c++), help take a look at the top of ksshprocess.cpp -- we might avoid a complete rewrite if we can update the response tables for the newer versions of openssh. ksshprocess does response lookups depending on the openssh version. If this has been the problem all along -- we may be able to put off the complete rewrite and fix sftp:// for 3.5.14.
This is very useful information that should be posted to the bug report. My initial guess would be that the mechanism TDE uses to determine SSH version is failing with the latest SSH binaries. Can you also post the output of 'ssh -v' on your system, specifically the version line?
Thanks!
Tim
Can someone who knows the openssh responses (as well as
c++), help take a
look at the top of ksshprocess.cpp -- we might avoid a
complete rewrite if we
can update the response tables for the newer versions of
openssh. ksshprocess
does response lookups depending on the openssh version. If
this has been the
problem all along -- we may be able to put off the complete
rewrite and fix
sftp:// for 3.5.14.
This is very useful information that should be posted to the bug report. My initial guess would be that the mechanism TDE uses to determine SSH version is failing with the latest SSH binaries. Can you also post the output of 'ssh -v' on your system, specifically the version line?
I don't know whether this information will help, but Slackware 12.2 was the last Slackware release supporting KDE3. I mention this because the OpenSSH version with that release was 5.1p1. I know fish works with that release but I can't vouch for sftp. I presume so.
Slackware Current, which is a rolling release of sorts for each final snapshot official release, is now using OpenSSH 5.9p1 and OpenSSL 0.9.8t.
Perhaps that information helps narrow the range of versions to support, or a minimum version to support.
I'm using Slackware 13.1, which is using OpenSSH 5.5p1 (ssh -v: OpenSSH_5.5p1, OpenSSL 0.9.8t 18 Jan 2012).
I performed a cursory check of the message strings referenced in ksshprocess.cpp. They look the same between 5.1p1 and 5.9p1. Only a cursory check. :)
I have a complete 12.2 installation available to me that I can use to compare KDE3 fish and sftp tests to TDE. All I need are instructions of what you folks need me to do and I can proceed.
Darrell
On 04/22/2012 08:19 PM, Darrell Anderson wrote:
I have a complete 12.2 installation available to me that I can use to compare KDE3 fish and sftp tests to TDE. All I need are instructions of what you folks need me to do and I can proceed.
Darrell
Darrell,
The tests that are needed are simply to open konqueror file manager (or kwrite, or kate) and then just enter a sftp address (and compare with fish). fish should work, sftp should fail. The address form you should use is:
sftp://username@www.myhostname.com:port/dir1/dir2/ and so on
It can be as simple as
sftp://hostname (for local network)
** kde will use your default username and default port (22)
As long as ssh is configured, you should connect fine -- but it fails due to the bug. The do the same thing with fish://
fish://username@www.myhostname.com:port/dir1/dir2/
It also can be as simple as:
fish://hostname
I can use fish:// and connect in TDE (I use it a lot). But sftp is what we need to fix. I still have some older opensuse 11.0 boxes at the office I can test and compare ssh connect strings with. The sftp:// still works on openSuSE 11.0 with the old openssh version. Any testing you can do will just help. If you don't have a test host for remote ssh connections, let me know, I can set one up for you.
The tests that are needed are simply to open konqueror file manager (or kwrite, or kate) and then just enter a sftp address (and compare with fish). fish should work, sftp should fail. The address form you should use is:
sftp://username@www.myhostname.com:port/dir1/dir2/ and so on
It can be as simple as
sftp://hostname (for local network)
** kde will use your default username and default port (22)
As long as ssh is configured, you should connect fine -- but it fails due to the bug. The do the same thing with fish://
fish://username@www.myhostname.com:port/dir1/dir2/
It also can be as simple as:
fish://hostname
I can use fish:// and connect in TDE (I use it a lot). But sftp is what we need to fix. I still have some older opensuse 11.0 boxes at the office I can test and compare ssh connect strings with. The sftp:// still works on openSuSE 11.0 with the old openssh version. Any testing you can do will just help. If you don't have a test host for remote ssh connections, let me know, I can set one up for you.
I can test fish on my own network. I use SSH many times every day.
I don't have an FTP server set up here. Do I need that?
Darrell
On 04/22/2012 09:31 PM, Darrell Anderson wrote:
The tests that are needed are simply to open
<snip>
I can test fish on my own network. I use SSH many times every day.
I don't have an FTP server set up here. Do I need that?
Darrell
No sftp relies on ssh or ssl, so no ftp is required :)
On 04/22/2012 07:58 PM, Timothy Pearson wrote:
On 04/22/2012 06:59 PM, David C. Rankin wrote:
So it looks like that is the recommended direction. A complete re-write is way beyond me, so we will need the skill of the c/c++ gurus to help with this bug.
Can someone who knows the openssh responses (as well as c++), help take a look at the top of ksshprocess.cpp -- we might avoid a complete rewrite if we can update the response tables for the newer versions of openssh. ksshprocess does response lookups depending on the openssh version. If this has been the problem all along -- we may be able to put off the complete rewrite and fix sftp:// for 3.5.14.
This is very useful information that should be posted to the bug report. My initial guess would be that the mechanism TDE uses to determine SSH version is failing with the latest SSH binaries. Can you also post the output of 'ssh -v' on your system, specifically the version line?
Thanks!
Tim
Tim,
I hope it can be this straight forward. I'll add all this information to the bug report. Here is my normal connection (I have pre-shared keys) I'll also get the information for a usual login as well (will be later tonigh):
21:06 archangel:/dat_e/pkg> ssh -v nirvana OpenSSH_5.9p1, OpenSSL 1.0.1 14 Mar 2012 debug1: Reading configuration data /home/david/.ssh/config debug1: /home/david/.ssh/config line 26: Applying options for nirvana debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to nirvana [192.168.6.17] port 6660. debug1: Connection established. debug1: identity file /home/david/.ssh/id_rsa type -1 debug1: identity file /home/david/.ssh/id_rsa-cert type -1 debug1: identity file /home/david/.ssh/id_dsa type 2 debug1: identity file /home/david/.ssh/id_dsa-cert type -1 debug1: identity file /home/david/.ssh/id_ecdsa type -1 debug1: identity file /home/david/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9 debug1: match: OpenSSH_5.9 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA fd:59:75<snipped>0d:6b debug1: Host '[nirvana]:6660' is known and matches the ECDSA host key. debug1: Found key in /home/david/.ssh/known_hosts:25 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/david/.ssh/id_rsa debug1: Offering DSA public key: /home/david/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 434 debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). Authenticated to nirvana ([192.168.6.17]:6660). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. Last login: Sun Apr 22 01:29:55 2012 from ochiltree-d2.3111skyline.com
====== slightly OT openssl patch =============
I have also found a 'openssl' 1.0.0 patch for openssl in kdelibs. I don't know if this has been applied to TDE yet, but I've included that as well in case it hasn't.
On 04/22/2012 07:58 PM, Timothy Pearson wrote:
On 04/22/2012 06:59 PM, David C. Rankin wrote:
So it looks like that is the recommended direction. A complete re-write is way beyond me, so we will need the skill of the c/c++ gurus to help with this bug.
Can someone who knows the openssh responses (as well as c++), help take a look at the top of ksshprocess.cpp -- we might avoid a complete rewrite if we can update the response tables for the newer versions of openssh. ksshprocess does response lookups depending on the openssh version. If this has been the problem all along -- we may be able to put off the complete rewrite and fix sftp:// for 3.5.14.
This is very useful information that should be posted to the bug report. My initial guess would be that the mechanism TDE uses to determine SSH version is failing with the latest SSH binaries. Can you also post the output of 'ssh -v' on your system, specifically the version line?
Thanks!
Tim
Tim,
I hope it can be this straight forward. I'll add all this information to the bug report. Here is my normal connection (I have pre-shared keys) I'll also get the information for a usual login as well (will be later tonigh):
21:06 archangel:/dat_e/pkg> ssh -v nirvana OpenSSH_5.9p1, OpenSSL 1.0.1 14 Mar 2012 debug1: Reading configuration data /home/david/.ssh/config debug1: /home/david/.ssh/config line 26: Applying options for nirvana debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to nirvana [192.168.6.17] port 6660. debug1: Connection established. debug1: identity file /home/david/.ssh/id_rsa type -1 debug1: identity file /home/david/.ssh/id_rsa-cert type -1 debug1: identity file /home/david/.ssh/id_dsa type 2 debug1: identity file /home/david/.ssh/id_dsa-cert type -1 debug1: identity file /home/david/.ssh/id_ecdsa type -1 debug1: identity file /home/david/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9 debug1: match: OpenSSH_5.9 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA fd:59:75<snipped>0d:6b debug1: Host '[nirvana]:6660' is known and matches the ECDSA host key. debug1: Found key in /home/david/.ssh/known_hosts:25 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/david/.ssh/id_rsa debug1: Offering DSA public key: /home/david/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 434 debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). Authenticated to nirvana ([192.168.6.17]:6660). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. Last login: Sun Apr 22 01:29:55 2012 from ochiltree-d2.3111skyline.com
====== slightly OT openssl patch =============
I have also found a 'openssl' 1.0.0 patch for openssl in kdelibs. I don't know if this has been applied to TDE yet, but I've included that as well in case it hasn't.
I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and OpenSSL 0.9.8o, and sftp from GIT worked perfectly. I am going to try a newer system to see if I can get it to fail.
Tim
On 04/22/2012 10:36 PM, Timothy Pearson wrote:
I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and OpenSSL 0.9.8o, and sftp from GIT worked perfectly. I am going to try a newer system to see if I can get it to fail.
Tim
Note, sftp from konsole will work PERFECTLY. It is sftp:// from the konqueror address field, or kwrite/kate that fails. Here is the debug output for a box that does not use key-pairs for authentication:
23:15 nirvana:~> ssh -v supersff OpenSSH_5.9p1, OpenSSL 1.0.0h 12 Mar 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to supersff [192.168.6.121] port 22. debug1: Connection established. debug1: identity file /home/david/.ssh/id_rsa type -1 debug1: identity file /home/david/.ssh/id_rsa-cert type -1 debug1: identity file /home/david/.ssh/id_dsa type -1 debug1: identity file /home/david/.ssh/id_dsa-cert type -1 debug1: identity file /home/david/.ssh/id_ecdsa type -1 debug1: identity file /home/david/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9 debug1: match: OpenSSH_5.9 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA <snip> The authenticity of host 'supersff (192.168.6.121)' can't be established. ECDSA key fingerprint is <snip> Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'supersff,192.168.6.121' (ECDSA) to the list of known hosts. debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/david/.ssh/id_rsa debug1: Trying private key: /home/david/.ssh/id_dsa debug1: Trying private key: /home/david/.ssh/id_ecdsa debug1: Next authentication method: keyboard-interactive Password: debug1: Authentication succeeded (keyboard-interactive). Authenticated to supersff ([192.168.6.121]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. Last login: Wed Apr 11 17:07:18 2012 from alchemy.3111skyline.com
On 04/22/2012 10:36 PM, Timothy Pearson wrote:
I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and OpenSSL 0.9.8o, and sftp from GIT worked perfectly. I am going to try a newer system to see if I can get it to fail.
Tim
Note, sftp from konsole will work PERFECTLY. It is sftp:// from the konqueror address field, or kwrite/kate that fails. Here is the debug output for a box that does not use key-pairs for authentication:
I know. :-) I am tracing the issue now, but it appears that ssh > 5.5 somehow masks its stderr output so that TDE literally does not know what ssh is doing.
Tim
On 04/22/2012 10:36 PM, Timothy Pearson wrote:
I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and OpenSSL 0.9.8o, and sftp from GIT worked perfectly. I am going to try a newer system to see if I can get it to fail.
Tim
Note, sftp from konsole will work PERFECTLY. It is sftp:// from the konqueror address field, or kwrite/kate that fails. Here is the debug output for a box that does not use key-pairs for authentication:
I know. :-) I am tracing the issue now, but it appears that ssh > 5.5 somehow masks its stderr output so that TDE literally does not know what ssh is doing.
Tim
To be more precise, it looks like select() is not blocking on the ssh output file descriptors. This could also be a kernel or core system issue, so stay tuned! :-)
Tim
On 04/22/2012 10:36 PM, Timothy Pearson wrote:
I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and OpenSSL 0.9.8o, and sftp from GIT worked perfectly. I am going to try a newer system to see if I can get it to fail.
Tim
Note, sftp from konsole will work PERFECTLY. It is sftp:// from the konqueror address field, or kwrite/kate that fails. Here is the debug output for a box that does not use key-pairs for authentication:
I know. :-) I am tracing the issue now, but it appears that ssh > 5.5 somehow masks its stderr output so that TDE literally does not know what ssh is doing.
Tim
To be more precise, it looks like select() is not blocking on the ssh output file descriptors. This could also be a kernel or core system issue, so stay tuned! :-)
Tim
I have narrowed this down to a problem in how ssh and select() are interacting. To be specific, running select() on the open ssh output file descriptor always returns data available, but when an attempt is made to actually read said data with read() there is no data (an error occurs). I do not know if this is an ssh problem or a problem with some other aspect of the system regarding pipes.
Tim
On 04/22/2012 10:36 PM, Timothy Pearson wrote:
I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and OpenSSL 0.9.8o, and sftp from GIT worked perfectly. I am going to try a newer system to see if I can get it to fail.
Tim
Note, sftp from konsole will work PERFECTLY. It is sftp:// from the konqueror address field, or kwrite/kate that fails. Here is the debug output for a box that does not use key-pairs for authentication:
I know. :-) I am tracing the issue now, but it appears that ssh > 5.5 somehow masks its stderr output so that TDE literally does not know what ssh is doing.
Tim
To be more precise, it looks like select() is not blocking on the ssh output file descriptors. This could also be a kernel or core system issue, so stay tuned! :-)
Tim
I have narrowed this down to a problem in how ssh and select() are interacting. To be specific, running select() on the open ssh output file descriptor always returns data available, but when an attempt is made to actually read said data with read() there is no data (an error occurs). I do not know if this is an ssh problem or a problem with some other aspect of the system regarding pipes.
Tim
Fixed (hacked around) in GIT hash e72f492. Basically select() no longer works on newer systems (could be due to a malfunction of some kind, but it doesn't really matter), so instead of busywaiting on select(), newer systems will busywait on read().
Tim
Fixed (hacked around) in GIT hash e72f492. Basically select() no longer works on newer systems (could be due to a malfunction of some kind, but it doesn't really matter), so instead of busywaiting on select(), newer systems will busywait on read().
I don't know how much this information helps, but I tested both fish and sftp between two Trinity systems, one real and one virtual. Both systems using OpenSSH 5.5p1 and OpenSSL 0.9.8t.
Using sftp worked both ways all the time without any event. Connecting with fish from the virtual system to the real system was the same.
When trying to connect with fish from the real system to the virtual I always received the infamous "protocol died unexpectedly error." When I deleted the ksycoca cache and set KDE_FORK_SLAVES=true, then fish always connected.
In hindsight that makes no sense because the environment variable was changed some time ago to TDE_FORK_SLAVES. I'm guessing the real issue is something in the ksycoca cache causes problems for fish.
I'll test again and add more information as possible.
Darrell
On 04/23/2012 02:30 PM, Darrell Anderson wrote:
I don't know how much this information helps, but I tested both fish and sftp between two Trinity systems, one real and one virtual. Both systems using OpenSSH 5.5p1 and OpenSSL 0.9.8t.
We will have to really test. I don't know if openssl plays into the problem (I don't think so), but openssl 1.0.X has been out for a while and there were specific patches to accommodate in kde-sunset. Currently we have:
openssl 1.0.1-2 openssh 5.9p1-8
As in my last post. I'll try and test and confirm tonight.
Le 23/04/2012 09:44, Timothy Pearson a écrit :
On 04/22/2012 10:36 PM, Timothy Pearson wrote:
I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and OpenSSL 0.9.8o, and sftp from GIT worked perfectly. I am going to try a newer system to see if I can get it to fail.
Tim
Note, sftp from konsole will work PERFECTLY. It is sftp:// from the konqueror address field, or kwrite/kate that fails. Here is the debug output for a box that does not use key-pairs for authentication:
I know. :-) I am tracing the issue now, but it appears that ssh> 5.5 somehow masks its stderr output so that TDE literally does not know what ssh is doing.
Tim
To be more precise, it looks like select() is not blocking on the ssh output file descriptors. This could also be a kernel or core system issue, so stay tuned! :-)
Tim
I have narrowed this down to a problem in how ssh and select() are interacting. To be specific, running select() on the open ssh output file descriptor always returns data available, but when an attempt is made to actually read said data with read() there is no data (an error occurs). I do not know if this is an ssh problem or a problem with some other aspect of the system regarding pipes.
Tim
Fixed (hacked around) in GIT hash e72f492. Basically select() no longer works on newer systems (could be due to a malfunction of some kind, but it doesn't really matter), so instead of busywaiting on select(), newer systems will busywait on read().
Tim
Thanks, it looks to work well on Fedora 16 (patch applied to TDE 3.5.13).
Dne po 23. dubna 2012 Francois Andriot napsal(a):
Thanks, it looks to work well on Fedora 16 (patch applied to TDE 3.5.13).
Francois, you are creating packages for Fedora?
Slávek --
Le 23/04/2012 21:47, Slávek Banko a écrit :
Dne po 23. dubna 2012 Francois Andriot napsal(a):
Thanks, it looks to work well on Fedora 16 (patch applied to TDE 3.5.13).
Francois, you are creating packages for Fedora?
Slávek
Yes I do.
On Monday 23 of April 2012 21:54:27 Francois Andriot wrote:
Le 23/04/2012 21:47, Slávek Banko a écrit :
Dne po 23. dubna 2012 Francois Andriot napsal(a):
Thanks, it looks to work well on Fedora 16 (patch applied to TDE 3.5.13).
Francois, you are creating packages for Fedora?
Slávek
Yes I do.
Perhaps you have noticed here that I had some time to deal with backporting patches to 3.5.13 for Debian and Ubuntu. I therefore ask if you backport patches to Fedora? Or, if you want to use the patches, which I have already prepared? Update to 3.5.13 could thus be not only for Debian, but also for Fedora. What do you think?
Slavek --
On Tue, 24 Apr 2012 01:40:11 +0200, Slávek Banko wrote:
On
Monday 23 of April 2012 21:54:27 Francois Andriot wrote:
Le
23/04/2012 21:47, Slávek Banko a écrit :
Dne po 23. dubna 2012
Francois Andriot napsal(a):
Thanks, it looks to work well on
Fedora 16 (patch applied to TDE 3.5.13).
Francois, you are creating
packages for Fedora? Slávek
Yes I do.
Perhaps you have noticed
here that I had some time to deal with backporting
patches to 3.5.13
for Debian and Ubuntu. I therefore ask if you backport
patches to
Fedora? Or, if you want to use the patches, which I have already
prepared? Update to 3.5.13 could thus be not only for Debian, but also for
Fedora. What do you think?
Hello, I'm already backporting lots patches myself, including some which are the same as you:
You can find the packaging-related files (Redhat SPEC file + patches) in the GIT tree:
http://git.trinitydesktop.org/cgit/tde-packaging/tree/redhat/
The current RHEL/Fedora TDE build is already heavily patched compared to the stock 3.5.13.
But I did not find a place to download your patches. (I haven't searched a lot ...)
If you share them, I will happily use them too.
Francois
Dne út 24. dubna 2012 François Andriot napsal(a):
Hello, I'm already backporting lots patches myself, including some which are the same as you:
You can find the packaging-related files (Redhat SPEC file + patches) in the GIT tree:
http://git.trinitydesktop.org/cgit/tde-packaging/tree/redhat/
The current RHEL/Fedora TDE build is already heavily patched compared to the stock 3.5.13.
But I did not find a place to download your patches. (I haven't searched a lot ...)
If you share them, I will happily use them too.
Francois
wow, you already have collected well enough. My patches have not yet published. I hoped that it could establish a branch in git and patches for 3.5.13 merge there. At present, I'd be able to send by mail.
Manage patches in packaging tree I would not really want - I maintain five distributions and patches are common to all.
Slávek --
Dne út 24. dubna 2012 François Andriot napsal(a):
But I did not find a place to download your patches. (I haven't searched a lot ...) If you share them, I will happily use them too. Francois
Please could you compare if you have included patches that I am not incorporated? If will be managed to set up a GIT branch for 3.5.13 updates, there would be good to incorporate also patches from you.
My patches are now available for download here: http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz
Slavek --
On 05/02/2012 10:35 AM, Slávek Banko wrote:
Dne út 24. dubna 2012 François Andriot napsal(a):
But I did not find a place to download your patches. (I haven't searched a lot ...) If you share them, I will happily use them too.
Francois
Please could you compare if you have included patches that I am not incorporated? If will be managed to set up a GIT branch for 3.5.13 updates, there would be good to incorporate also patches from you.
My patches are now available for download here: http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz
Slavek
Slavek,
The kio_sftp.cpp patch is part of:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=897
(the bug was closed)
Dne st 2. května 2012 David C. Rankin napsal(a):
On 05/02/2012 10:35 AM, Slávek Banko wrote:
Dne út 24. dubna 2012 François Andriot napsal(a):
But I did not find a place to download your patches. (I haven't searched a lot ...) If you share them, I will happily use them too.
Francois
Please could you compare if you have included patches that I am not incorporated? If will be managed to set up a GIT branch for 3.5.13 updates, there would be good to incorporate also patches from you.
My patches are now available for download here: http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz
Slavek
Slavek,
The kio_sftp.cpp patch is part of:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=897
(the bug was closed)
David,
From my kdebase changelog:
* commit e72f4926, closes #897 Fix sftp failure on newer systems * commit 073dc86a Fix sftp when nonstandard port is specified in ssh config
I think I have a patches already incorporated into the updates.
Slávek --
On 05/02/2012 11:24 AM, Slávek Banko wrote:
David,
From my kdebase changelog:
- commit e72f4926, closes #897 Fix sftp failure on newer systems
- commit 073dc86a Fix sftp when nonstandard port is specified in ssh config
I think I have a patches already incorporated into the updates.
Slávek
Oh sorry,
You are right - they are already in your files if you have the current commits.
On 05/02/2012 10:35 AM, Slávek Banko wrote:
Dne út 24. dubna 2012 François Andriot napsal(a):
But I did not find a place to download your patches. (I haven't searched a lot ...) If you share them, I will happily use them too.
Francois
Please could you compare if you have included patches that I am not incorporated? If will be managed to set up a GIT branch for 3.5.13 updates, there would be good to incorporate also patches from you.
My patches are now available for download here: http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz
Slavek
Here is the patch itself (with comment included):
--- tdebase/kioslave/sftp/kio_sftp.cpp +++ tdebase/kioslave/sftp/kio_sftp.cpp 2012-05-02 11:05:54.872250800 -0500 @@ -478,15 +478,12 @@
mHost = h;
+ // if port is NOT provided by user in URL, do NOT pass port to ssh + // 04-25-2012, fixed sftp:// failure (TDE bug 897) if( port > 0 ) mPort = port; - else { - struct servent *pse; - if( (pse = getservbyname("ssh", "tcp") ) == NULL ) - mPort = 22; else - mPort = ntohs(pse->s_port); - } + mPort = -1;
mUsername = user; mPassword = pass;
Francois, you are creating packages for Fedora?
Slávek
Yes I do.
Francois,
Are you building 64-bit packages too?
On 64-bit I am unable to build tqca, tqca-tls, python-tqt, and python-trinity. The sources do not find the $PREFIX/lib64 directories, only looking for $PREFIX/lib.
If you succeed with those packages I would be grateful if you post your solution.
Thanks.
Darrell
Le 24/04/2012 22:43, Darrell Anderson a écrit :
Francois,
Are you building 64-bit packages too?
On 64-bit I am unable to build tqca, tqca-tls, python-tqt, and python-trinity. The sources do not find the $PREFIX/lib64 directories, only looking for $PREFIX/lib.
If you succeed with those packages I would be grateful if you post your solution.
Thanks.
Darrell
I will look into them, but I think these packages are for R14 and I'm focusing on 3.5.13 for now. I've already built tqca-tls R14 with TQT3 bt writing the attached patch (see first part). Problems occur when the "configure" script is not autogenerated but is a static shell script, it often lacks the "lib64" directories in path ...
I will look into them, but I think these packages are for R14 and I'm focusing on 3.5.13 for now. I've already built tqca-tls R14 with TQT3 bt writing the attached patch (see first part).
Where do I look for the patches?
I'm okay with your patches being for 3.5.13. I can massage/adapt them to GIT. I have been doing that regularly around here. :)
Problems occur when the "configure" script is not autogenerated but is a static shell script, it often lacks the "lib64" directories in path ...
Yes, that is the case. I need to learn how to fix only one of each (tqca or tqca-tls and python-tqt or python-trinity). After I learn to fix one of each I should be able to do likewise for the other. The challenge with the two python packages is the configuration scripts are written in python, which I don't know.
By the way, are your Fedora packages compatible with other Redhat spinoff releases, such as Scientific Linux? Just curious.
Darrell
On Tue, 24 Apr 2012 14:27:06 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I will look into them, but I think these packages are for R14 and I'm focusing on 3.5.13 for now. I've already built tqca-tls R14 with TQT3 bt writing the attached patch (see first part).
Where do I look for the patches?
I'm okay with your patches being for 3.5.13. I can massage/adapt them to GIT. I have been doing that regularly around here. :)
Problems occur when the "configure" script is not autogenerated but is a static shell script, it often lacks the "lib64" directories in path ...
Yes, that is the case. I need to learn how to fix only one of each (tqca or tqca-tls and python-tqt or python-trinity). After I learn to fix one of each I should be able to do likewise for the other. The challenge with the two python packages is the configuration scripts are written in python, which I don't know.
By the way, are your Fedora packages compatible with other Redhat spinoff releases, such as Scientific Linux? Just curious.
The RHEL packages are way more likely to be compatible with Scientific Linux than the Fedora ones, since SL is supposed to be binary compatible with the corresponding RHEL version. Didn't test at all, though.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
By the way, are your Fedora packages compatible with other Redhat spinoff releases, such as Scientific Linux? Just curious.
The RHEL packages are way more likely to be compatible with Scientific Linux than the Fedora ones, since SL is supposed to be binary compatible with the corresponding RHEL version. Didn't test at all, though.
Ok. I see.
I notice at the Trinity web page that RHEL 5 and 6 packages are available for 3.5.13. Who supports those packages?
Are there RHEL GIT packages available for testing?
Darrell
On Tue, 24 Apr 2012 14:34:57 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
By the way, are your Fedora packages compatible with other Redhat spinoff releases, such as Scientific Linux? Just curious.
The RHEL packages are way more likely to be compatible with Scientific Linux than the Fedora ones, since SL is supposed to be binary compatible with the corresponding RHEL version. Didn't test at all, though.
Ok. I see.
I notice at the Trinity web page that RHEL 5 and 6 packages are available for 3.5.13. Who supports those packages?
IIRC the RHEL packages are also from François Andriot.
Are there RHEL GIT packages available for testing?
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Le 24/04/2012 23:27, Darrell Anderson a écrit :
I will look into them, but I think these packages are for R14 and I'm focusing on 3.5.13 for now. I've already built tqca-tls R14 with TQT3 bt writing the attached patch (see first part).
Where do I look for the patches?
I'm okay with your patches being for 3.5.13. I can massage/adapt them to GIT. I have been doing that regularly around here. :)
Sorry, I forgot to attach the patch to my previous mail. Here is the patch for tqca-tls, working on fedora 16 x86_64 (tde r14 + tqt3) .
Problems occur when the "configure" script is not autogenerated but is a static shell script, it often lacks the "lib64" directories in path ...
Yes, that is the case. I need to learn how to fix only one of each (tqca or tqca-tls and python-tqt or python-trinity). After I learn to fix one of each I should be able to do likewise for the other. The challenge with the two python packages is the configuration scripts are written in python, which I don't know.
By the way, are your Fedora packages compatible with other Redhat spinoff releases, such as Scientific Linux? Just curious.
I am the packager for both RHEL and Fedora. RHEL is like an "old stable Fedora", the packaging method and tools are exactly the same, thanks to the Redhat RPM tools That's why If you look in the git tree "tde-packaging", only the "redhat" folder is populated. But I have to compile my sources for each distro (currently I compile each package 10 times: RHEL5, RHEL6, Fedora15, Fedora16, Fedora17, each distro for both x86 and x86_64).
As a bonus, I've just done the patch for tqca (tested on fedora 16 x86_64, tde r14, tqt3). It is attached to this mail too.
I did not look yet but I guess that the trinity-python package has more or less the same problem.
Francois
On 04/24/2012 04:54 PM, François ANDRIOT wrote:
Le 24/04/2012 23:27, Darrell Anderson a écrit :
I will look into them, but I think these packages are for R14 and I'm focusing on 3.5.13 for now. I've already built tqca-tls R14 with TQT3 bt writing the attached patch (see first part).
Where do I look for the patches?
I'm okay with your patches being for 3.5.13. I can massage/adapt them to GIT. I have been doing that regularly around here. :)
Sorry, I forgot to attach the patch to my previous mail. Here is the patch for tqca-tls, working on fedora 16 x86_64 (tde r14 + tqt3) .
Problems occur when the "configure" script is not autogenerated but is a static shell script, it often lacks the "lib64" directories in path ...
Yes, that is the case. I need to learn how to fix only one of each (tqca or tqca-tls and python-tqt or python-trinity). After I learn to fix one of each I should be able to do likewise for the other. The challenge with the two python packages is the configuration scripts are written in python, which I don't know.
By the way, are your Fedora packages compatible with other Redhat spinoff releases, such as Scientific Linux? Just curious.
I am the packager for both RHEL and Fedora. RHEL is like an "old stable Fedora", the packaging method and tools are exactly the same, thanks to the Redhat RPM tools That's why If you look in the git tree "tde-packaging", only the "redhat" folder is populated. But I have to compile my sources for each distro (currently I compile each package 10 times: RHEL5, RHEL6, Fedora15, Fedora16, Fedora17, each distro for both x86 and x86_64).
As a bonus, I've just done the patch for tqca (tested on fedora 16 x86_64, tde r14, tqt3). It is attached to this mail too.
I did not look yet but I guess that the trinity-python package has more or less the same problem.
Francois
Francios,
Is this configurable for those distros that do NOT utilize lib64 for 64-bit library packages? While openSuSE does put 64-bit libs in lib64, Archlinux puts all libs lin 'libs' on 64-bit boxes. This needs to be configurable for just this case. Otherwise always putting 64-bit libs in lib64 on boxes that do NOT use lib64 will really screw up the library search and build system. Can it be something like a --target option or a --with-64bit-lib-dirs= configure option?
We don't want a one-size doesn't fit all solution. That would cause about an equal number of problems as it purportedly resolves for those distros that put 64bit libs in libs.
On Wed, 25 Apr 2012 00:01:47 -0500, David C. Rankin wrote:
On
04/24/2012 04:54 PM, François ANDRIOT wrote:
Le 24/04/2012 23:27,
Darrell Anderson a écrit :
I will look into them, but I think
these packages are for R14 and I'm focusing on 3.5.13 for now. I've already built tqca-tls R14 with TQT3 bt writing the attached patch (see first part).
Where do I look for the patches? I'm okay with your
patches being for 3.5.13. I can massage/adapt them to GIT. I have been doing that regularly around here. :)
Sorry, I forgot to attach the
patch to my previous mail. Here is the patch for tqca-tls, working on fedora 16 x86_64 (tde r14 + tqt3) .
Problems occur when the
"configure" script is not autogenerated but is a static shell script, it often lacks the "lib64" directories in path ...
Yes, that is the
case. I need to learn how to fix only one of each (tqca or tqca-tls and python-tqt or python-trinity). After I learn to fix one of each I should be able to do likewise for the other. The challenge with the two python packages is the configuration scripts are written in python, which I don't know. By the way, are your Fedora packages compatible with other Redhat spinoff releases, such as Scientific Linux? Just curious.
I am
the packager for both RHEL and Fedora. RHEL is like an "old stable Fedora", the packaging method and tools are exactly the same, thanks to the Redhat RPM tools That's why If you look in the git tree "tde-packaging", only the "redhat" folder is populated. But I have to compile my sources for each distro (currently I compile each package 10 times: RHEL5, RHEL6, Fedora15, Fedora16, Fedora17, each distro for both x86 and x86_64). As a bonus, I've just done the patch for tqca (tested on fedora 16 x86_64, tde r14, tqt3). It is attached to this mail too. I did not look yet but I guess that the trinity-python package has more or less the same problem. Francois
Francios,
Is this configurable
for those distros that do NOT utilize lib64 for 64-bit
library
packages? While openSuSE does put 64-bit libs in lib64, Archlinux puts
all libs lin 'libs' on 64-bit boxes. This needs to be configurable for just this
case. Otherwise always putting 64-bit libs in lib64 on boxes
that do NOT use
lib64 will really screw up the library search and
build system. Can it be
something like a --target option or a
--with-64bit-lib-dirs= configure option?
We don't want a one-size
doesn't fit all solution. That would cause about an
equal number of
problems as it purportedly resolves for those distros that put
64bit
libs in libs.
The patch should work for both "lib64" and "lib" directory, or any other location that your system use for libraries.
Just try it and see if you get the expected result.
Sorry, I forgot to attach the patch to my previous mail. Here is the patch for tqca-tls, working on fedora 16 x86_64 (tde r14 + tqt3) .
Problems occur when the "configure" script is not autogenerated but is a static shell script, it
often lacks the "lib64" directories
in path ...
Yes, that is the case. I need to learn how to fix only
one of each (tqca or tqca-tls and python-tqt or python-trinity). After I learn to fix one of each I should be able to do likewise for the other. The challenge with the two python packages is the configuration scripts are written in python, which I don't know.
I appreciate the patches but they did not help. :(
The problem is not detecting $QTDIR but $LIBDIR when $LIBDR=$PREFIX/lib64 rather than $LIBDR=$PREFIX/lib.
The configuration process always fails because libtqt-mt.so.3 is located in $LIBDR=$PREFIX/lib64 rather than $LIBDR=$PREFIX/lib.
The whole problem is telling the configure process where to find libtqt-mt.so.3.
Darrell
Le 25/04/2012 20:45, Darrell Anderson a écrit :
I appreciate the patches but they did not help. :(
The problem is not detecting $QTDIR but $LIBDIR when $LIBDR=$PREFIX/lib64 rather than $LIBDR=$PREFIX/lib.
The configuration process always fails because libtqt-mt.so.3 is located in $LIBDR=$PREFIX/lib64 rather than $LIBDR=$PREFIX/lib.
The whole problem is telling the configure process where to find libtqt-mt.so.3.
Darrell
And where is your "libtqt-mt.so.3" located ? Isn't TQT3 supposed to be installed in /usr ? So that libraries are under /usr/lib64 directly ... that's what I do and it works very well ...
If TQT3 is in non-standard prefix (ex: /opt/trinity), you can modify the "configure" script a bit more than I did. Look at the line "for p in /usr/lib64/tqt /usr/lib/tqt ..." . These are all the path where we look for TQT3 libraries. Just add the path you want, like ${PREFIX}/lib64 and ${PREFIX}/lib at the beginning the path list, and it should do the trick.
If you have too much trouble with this "configure" script, you can stop using it and build tqca directly with only 3 commands ! (just check that the "qmake" command is in your PATH ...)
export QTDIR=/opt/trinity qmake qca.pro make
Francois
And where is your "libtqt-mt.so.3" located ? Isn't TQT3 supposed to be installed in /usr ? So that libraries are under /usr/lib64 directly ... that's what I do and it works very well ...
I install TQt3 to a $PREFIX of /opt/trinity. qmake, moc, uic, etc. all are installed in /opt/trinity/bin.
After TQt3 is installed, $QTDIR then is set to /opt/trinity as well.
Using this method I don't have to install TQt3 to any weird subdirectories as was the past practice with Qt3.
In 32-bit I have no trouble building any Trinity package.
In 64-bit I have no trouble building any Trinity package except tqca, tqca-tls, python-tqt and python-trinity.
For 32-bit builds libtqt-mt.so.3 is installed in /opt/trinity/lib.
For 64-bit builds libtqt-mt.so.3 is installed in /opt/trinity/lib64.
The configure process does not have a problem finding $PREFIX, $QTDIR because I explicitly declare those variables.
The only problem with building tqca and tqca-tls is when $LIBDIR changes from $PREFIX/lib to $PREFIX/lib64.
If TQT3 is in non-standard prefix (ex: /opt/trinity), you can modify the "configure" script a bit more than I did. Look at the line "for p in /usr/lib64/tqt /usr/lib/tqt ...". These are all the path where we look for TQT3 libraries. Just add the path you want, like ${PREFIX}/lib64 and ${PREFIX}/lib at the beginning the path list, and it should do the trick.
Adding ${PREFIX}/lib64 does not help because the configuration process finds $PREFIX and $QTDIR. I explicitly define those variables in my build script. The problem is not finding $PREFIX/lib64 ($QTDIR/lib64).
If you have too much trouble with this "configure" script, you can stop using it and build tqca directly with only 3 commands ! (just check that the "qmake" command is in your PATH ...)
export QTDIR=/opt/trinity qmake qca.pro make
OK. I tried that. I can't get that to work either. Here is the build output:
=========================================================== g++ -c -pipe -g -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -O2 -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/opt/trinity/mkspecs/default -I. -Isrc -I/usr/include/tqt -I/opt/trinity/include -I.ui/ -I.moc/ -o .obj/qca.o src/qca.cpp rm -f libqca.so.1.0.0 libqca.so libqca.so.1 libqca.so.1.0 g++ -Wl,-rpath,/opt/trinity/lib -shared -Wl,-soname,libqca.so.1 -o libqca.so.1.0.0 .obj/qca.o -L/opt/trinity/lib -ltqt-mt -lpthread /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../x86_64-slackware-linux/bin/ld: cannot find -ltqt-mt ===========================================================
The output shows that /opt/trinity/lib is being used rather than /opt/trinity/lib64.
I can run this process manually and manually edit Makefile to /opt/trinity/lib64. Then make runs without error.
The trick is to force tqca to look in /opt/trinity/lib64 and not in /opt/trinity/lib.
Darrell
Le 25/04/2012 21:44, Darrell Anderson a écrit :
The output shows that /opt/trinity/lib is being used rather than /opt/trinity/lib64.
I can run this process manually and manually edit Makefile to /opt/trinity/lib64. Then make runs without error.
The trick is to force tqca to look in /opt/trinity/lib64 and not in /opt/trinity/lib.
Darrell
Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
did you try to set variable QTLIB before running qmake ? export QTLIB=$PREFIX/lib64
did you try to set variable QTLIB before running qmake ? export QTLIB=$PREFIX/lib64
QTLIB probably the same as what I define as QT_LIB_DIR.
Nonetheless, I tried using QTLIB anyway. No difference.
Here is my build information:
=========================================================== PREFIX: /opt/trinity SYSCONFDIR: /etc/trinity LIBDIR: /opt/trinity/lib64 MANDIR: /opt/trinity/man
PKG_CONFIG_PATH: /opt/trinity/lib64/pkgconfig:/usr/local/lib64/pkgconfig:/usr/lib64/pkgconfig:/opt/trinity/lib/pkgconfig QTDIR: /opt/trinity QT_INCLUDE_DIR: /opt/trinity/include QT_LIB_DIR: /opt/trinity/lib64 LD_LIBRARY_PATH: /opt/trinity/lib64:/opt/trinity/lib64/trinity PATH: /usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/opt/trinity/bin:/usr/bin:/bin:/usr/games:/usr/lib64/java/bin:/usr/lib64/java/jre/bin:/usr/lib64/java/bin:/usr/share/texmf/bin ===========================================================
My configure options:
=========================================================== export QC_DEBUG=Y CFLAGS=$CPUOPT \ CXXFLAGS=$CPUOPT \ ./configure \ --prefix=${PREFIX} \ --qtdir=${QTDIR} ===========================================================
The build output:
=========================================================== Verifying TQt 3.x Multithreaded (MT) build environment ... fail
There was an error compiling 'conf'. Be sure you have a proper TQt 3.x Multithreaded (MT) build environment set up.
One possible reason is that you don't have libtqt-mt.so.3 installed in /opt/trinity/lib/.
make: *** No targets specified and no makefile found. Stop. There was an error trying to build tqca. EXIT_CODE: 1 ===========================================================
Here is the config.log:
=========================================================== g++ -c -pipe -g -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -O2 -D_REENTRANT -DX11_INC='"/usr/X11R6/include"' -DX11_LIBDIR ='"/usr/X11R6/lib"' -DX11_LIB='"-lXext -lX11 -lm"' -DCC='"gcc"' -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/opt/trinity/mkspecs/default -I. -I' /usr/include/tqt' -I/opt/trinity/include -I/usr/include -o conf.o conf.cpp g++ -Wl,-rpath,/opt/trinity/lib -o conf conf.o -L/opt/trinity/lib -L/usr/X11R6/lib -ltqt-mt -lXext -lX11 -lm -lpthread /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../x86_64-slackware-linux/bin/ld: cannot find -ltqt-mt collect2: ld returned 1 exit status make: *** [conf] Error 1 ===========================================================
The config.log shows the process halts because -L is set to /opt/trinity/lib rather than /opt/trinity/lib64.
I tried patching both qca.pro and qcextra (lib -> lib64) but that does not help.
Here is the contents of tqt-mt.pc:
=========================================================== prefix=/opt/trinity exec_prefix=${prefix} libdir=${prefix}/lib64 includedir=${prefix}/include qt_config=qt warn_on release incremental link_prl thread nocrosscompiler dlopen_opengl minimal-config small-config medium-config large-config full-config styles tools kernel widgets dialogs iconview workspace inputmethod network canvas table xml opengl sql opengl release dll thread largefile stl ipv6 system-mng system-jpeg jpeg system-png png gif system-zlib nis cups bigcodecs x11sm xshape xinerama xcursor xrandr xrender xftfreetype tablet xkb inputmethod dylib create_prl link_prl qt warn_on depend_includepath qmake_cache x11 x11inc create_libtool create_pc moc x11lib
Name: TQt Description: Libtqt-mt.so.3.3.8 Library Version: 3.3.8 Libs: -L${libdir} -ltqt-mt -L/usr/lib64 -L/usr/X11R6/lib -lfontconfig -ljpeg -lpng -lz -lXi -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -lXext -lX11 -lm -lSM -lICE -ldl -lpthread Cflags: -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -D_REENTRANT -I${includedir} ===========================================================
The configuration process does not seem to be using tqt-mt.pc because the information is correct.
Darrell
On 04/23/2012 02:44 AM, Timothy Pearson wrote:
Fixed (hacked around) in GIT hash e72f492. Basically select() no longer works on newer systems (could be due to a malfunction of some kind, but it doesn't really matter), so instead of busywaiting on select(), newer systems will busywait on read().
Tim
WOHOO!!! Will test and report back. Sorry, I've been swamped the past couple of days. I'll definitely try and build/test tonight!
On 04/23/2012 03:26 PM, David C. Rankin wrote:
On 04/23/2012 02:44 AM, Timothy Pearson wrote:
Fixed (hacked around) in GIT hash e72f492. Basically select() no longer works on newer systems (could be due to a malfunction of some kind, but it doesn't really matter), so instead of busywaiting on select(), newer systems will busywait on read().
Tim
WOHOO!!! Will test and report back. Sorry, I've been swamped the past couple of days. I'll definitely try and build/test tonight!
Tim,
I built tdelibs and tdebase and tested sftp. There is GOOD news and BAD news. The good new - I can connect with sftp!! The bad news - the kio is not reading host/port information from ~/.ssh/config. This requires that you manually specify a port (if not 22) where sftp:// used to read this information from the HOST/PORT information contained in ~/.ssh/config. Eg:
Host arete.3111skyline.com arete Port 6629 Host fax.rlfpllc.com fax Port 6631
I don't know what reads this file, but it is read currently when fish:// is invoked and it was previously read by sftp:// before this bug appeared. Any idea where this occurs?
On 04/23/2012 03:26 PM, David C. Rankin wrote:
On 04/23/2012 02:44 AM, Timothy Pearson wrote:
Fixed (hacked around) in GIT hash e72f492. Basically select() no longer works on newer systems (could be due to a malfunction of some kind, but it doesn't really matter), so instead of busywaiting on select(), newer systems will busywait on read().
Tim
WOHOO!!! Will test and report back. Sorry, I've been swamped the past couple of days. I'll definitely try and build/test tonight!
Tim,
I built tdelibs and tdebase and tested sftp. There is GOOD news and BAD news. The good new - I can connect with sftp!! The bad news - the kio is not reading host/port information from ~/.ssh/config. This requires that you manually specify a port (if not 22) where sftp:// used to read this information from the HOST/PORT information contained in ~/.ssh/config. Eg:
Host arete.3111skyline.com arete Port 6629 Host fax.rlfpllc.com fax Port 6631
I don't know what reads this file, but it is read currently when fish:// is invoked and it was previously read by sftp:// before this bug appeared. Any idea where this occurs?
I would have expected ssh to read this on its own, but now that you mention it I do remember a port 22 parameter being passed to ssh when invoked by the sftp kioslave. I would look in ksshprocess.cpp and see if the sftp kioslave was hardcoded to port 22 for some reason.
Tim
On 04/23/2012 06:50 PM, David C. Rankin wrote:
On 04/23/2012 03:26 PM, David C. Rankin wrote:
On 04/23/2012 02:44 AM, Timothy Pearson wrote:
Fixed (hacked around) in GIT hash e72f492. Basically select() no longer works on newer systems (could be due to a malfunction of some kind, but it doesn't really matter), so instead of busywaiting on select(), newer systems will busywait on read().
Tim
WOHOO!!! Will test and report back. Sorry, I've been swamped the past couple of days. I'll definitely try and build/test tonight!
Tim,
I built tdelibs and tdebase and tested sftp. There is GOOD news and BAD news. The good new - I can connect with sftp!! The bad news - the kio is not reading host/port information from ~/.ssh/config. This requires that you manually specify a port (if not 22) where sftp:// used to read this information from the HOST/PORT information contained in ~/.ssh/config. Eg:
Host arete.3111skyline.com arete Port 6629 Host fax.rlfpllc.com fax Port 6631
I don't know what reads this file, but it is read currently when fish:// is invoked and it was previously read by sftp:// before this bug appeared. Any idea where this occurs?
Tim,
It looks like the port is set in kio_sftp.cpp:
if( port > 0 ) mPort = port; else { struct servent *pse; if( (pse = getservbyname("ssh", "tcp") ) == NULL ) mPort = 22; else mPort = ntohs(pse->s_port); }
I have looked at the man pages for both getservbyname and ntohs. For the port to fail, it looks like the pse->s_port byte order port number returned by getservbyname must be mucked up also. I'm not sure about the remainder of what the man page is telling me. Are you familiar with what should be returned? Is there something I can test for you so we can check if the port is being set?
A patch to make it spit the port number to kdialog? How to do this?
On 04/23/2012 06:50 PM, David C. Rankin wrote:
On 04/23/2012 03:26 PM, David C. Rankin wrote:
On 04/23/2012 02:44 AM, Timothy Pearson wrote:
Fixed (hacked around) in GIT hash e72f492. Basically select() no longer works on newer systems (could be due to a malfunction of some kind, but it doesn't really matter), so instead of busywaiting on select(), newer systems will busywait on read().
Tim
WOHOO!!! Will test and report back. Sorry, I've been swamped the past couple of days. I'll definitely try and build/test tonight!
Tim,
I built tdelibs and tdebase and tested sftp. There is GOOD news and BAD news. The good new - I can connect with sftp!! The bad news - the kio is not reading host/port information from ~/.ssh/config. This requires that you manually specify a port (if not 22) where sftp:// used to read this information from the HOST/PORT information contained in ~/.ssh/config. Eg:
Host arete.3111skyline.com arete Port 6629 Host fax.rlfpllc.com fax Port 6631
I don't know what reads this file, but it is read currently when fish:// is invoked and it was previously read by sftp:// before this bug appeared. Any idea where this occurs?
Tim,
It looks like the port is set in kio_sftp.cpp:
if( port > 0 ) mPort = port; else { struct servent *pse; if( (pse = getservbyname("ssh", "tcp") ) == NULL ) mPort = 22; else mPort = ntohs(pse->s_port); }I have looked at the man pages for both getservbyname and ntohs. For the port to fail, it looks like the pse->s_port byte order port number returned by getservbyname must be mucked up also. I'm not sure about the remainder of what the man page is telling me. Are you familiar with what should be returned? Is there something I can test for you so we can check if the port is being set?
A patch to make it spit the port number to kdialog? How to do this?
-- David C. Rankin, J.D.,P.E.
The part I don't get is that this worked at all in KDE 3.5.10. Specifically this portion of the code:
else { struct servent *pse; if( (pse = getservbyname("ssh", "tcp") ) == NULL ) mPort = 22; else mPort = ntohs(pse->s_port); }
looks like it should be completely removed! This duplicates the default port logic in ssh (bad), and also overrides any ports set via the ssh option file (even worse).
I'd try removing that section of code to see if it resolves the problem.
Tim
On 04/23/2012 09:12 PM, Timothy Pearson wrote:
The part I don't get is that this worked at all in KDE 3.5.10. Specifically this portion of the code:
else { struct servent *pse; if( (pse = getservbyname("ssh", "tcp") ) == NULL ) mPort = 22; else mPort = ntohs(pse->s_port); }looks like it should be completely removed! This duplicates the default port logic in ssh (bad), and also overrides any ports set via the ssh option file (even worse).
I'd try removing that section of code to see if it resolves the problem.
Tim
I think you are correct. I didn't know what the hell it did, so I wrote a code snippet to look at it and the pse structure created. What I don't get is how the heck this would ever get the correct port since you are never providing getservbyname with any remote host information. I run this and I get port numbers -- but 1+1!=2 yet...:
#include <limits.h> #include <errno.h> #include <stdlib.h> #include <stdio.h> #include <string.h>
#include <netdb.h> #include <arpa/inet.h>
int getval (char *str, int base);
int main(int argc, char *argv[]) { int mPort; long port;
if (argc < 2) { fprintf(stderr, "Usage: %s port_str [base]\n", argv[0]); exit(EXIT_FAILURE); }
port = getval(argv[1], (argc > 2) ? atoi(argv[2]) : 10);
printf("port: %d\n", port);
struct servent *pse; pse = getservbyname("ssh", "tcp");
if( port > 0 ) mPort = port; else { if( (pse) == NULL ) mPort = 22; else mPort = ntohs(pse->s_port); }
printf("mPort: %d\n", mPort); printf("(servant *pse)\n\ pse->s_name: %s\n\ pse->s_aliases: %s\n\ pse->s_port %d\n\ pse->s_proto %s\n", pse->s_name, pse->s_aliases, pse->s_port, pse->s_proto);
printf ("The host byte order -> Network byte order: %d\n\n", ntohs(pse->s_port));
return 0; }
int getval (char *str, int base) {
char *endptr; long val;
errno = 0; /* To distinguish success/failure after call */ val = strtol(str, &endptr, base);
/* Check for various possible errors */
if ((errno == ERANGE && (val == LONG_MAX || val == LONG_MIN)) || (errno != 0 && val == 0)) { perror("strtol"); return(EXIT_FAILURE); }
if (endptr == str) { fprintf(stderr, "No digits were found\n"); return(EXIT_FAILURE); }
/* If we got here, strtol() successfully parsed a number */
printf("strtol() returned %ld\n", val);
if (*endptr != '\0') /* Not necessarily an error... */ printf("Further characters after number: %s\n", endptr);
return (val); }
The part I don't get is that this worked at all in KDE 3.5.10. Specifically this portion of the code:
else { struct servent *pse; if( (pse =getservbyname("ssh", "tcp") ) == NULL ) mPort = 22; else mPort = ntohs(pse->s_port); }
looks like it should be completely removed! This duplicates the default port logic in ssh (bad), and also overrides any ports set via the ssh option file (even worse).
I'd try removing that section of code to see if it resolves the problem.
Yes, but 3.5.10 was working during the OpenSSH <=5.5p1 days. Perhaps something changed >5.5p1 that causes that snippet to now fail?
Darrell
The part I don't get is that this worked at all in KDE 3.5.10. Specifically this portion of the code:
else { struct servent *pse; if( (pse =getservbyname("ssh", "tcp") ) == NULL ) mPort = 22; else mPort = ntohs(pse->s_port); }
looks like it should be completely removed! This duplicates the default port logic in ssh (bad), and also overrides any ports set via the ssh option file (even worse).
I'd try removing that section of code to see if it resolves the problem.
Yes, but 3.5.10 was working during the OpenSSH <=5.5p1 days. Perhaps something changed >5.5p1 that causes that snippet to now fail?
Darrell
The thing is, that snippet should never work in the first place. Miracle engineering, even if it worked in 3.5.10, usually fails once assumed conditions change.
Tim
On 04/24/2012 12:15 AM, Timothy Pearson wrote:
Yes, but 3.5.10 was working during the OpenSSH <=5.5p1 days. Perhaps
something changed >5.5p1 that causes that snippet to now fail?
Darrell
The thing is, that snippet should never work in the first place. Miracle engineering, even if it worked in 3.5.10, usually fails once assumed conditions change.
Tim
Tim,
I did a test between the 'ssh -v' output of 'OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007' and 'OpenSSH_5.9p1, OpenSSL 1.0.1 14 Mar 2012'. Here are the key differences:
===== OpenSSH_5.0p1 =====
08:10 nemesis:~> ssh -v -p 6662 archangel.3111skyline.com OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /home/david/.ssh/config debug1: Applying options for archangel.3111skyline.com debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to archangel.3111skyline.com [192.168.6.14] port 6662. debug1: Connection established.
===== OpenSSH_5.9p1 =====
21:02 archangel:/dat_e> ssh -v nirvana OpenSSH_5.9p1, OpenSSL 1.0.1 14 Mar 2012 debug1: Reading configuration data /home/david/.ssh/config debug1: /home/david/.ssh/config line 26: Applying options for nirvana debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to nirvana [192.168.6.17] port 6660. debug1: Connection established.
Looking, it seems the differences are lines '3' (5.9 provides path info to local ssh config - 5.0 simply says 'Applying options...'). I don't think this is it. Line '5' is totally MISSING in 5.9! If the current kio_sftp is relying on line '6' for the IP and port information -- it will totally fail because that information is now LINE '5'.
This would explain why sftp got 'stuck' waiting on select() as Tim found! Somewhere in the sftp code, it must be checking on the ssh output beginning with line '6' looking for IP and port information:
debug1: Connecting to nirvana [192.168.6.17] port 6660.
however, with 5.9 it is getting:
debug1: Connection established.
Causing the code to endlessly wait on select() to get the IP and port!! Now - how to find where this takes place in the code to confirm?? It is probably a hardcoded as some array index like 'sshOutputLine[5]' which will now need to be changed to 'sshOutputLine[4]' to account for the deleted line in the output, or just rewritten with a regex to look for "[www.xxx.yyy.zzz] port 01234" in the output.
How do we look for code like this to rule in or rule out this problem?
On 04/24/2012 08:36 AM, David C. Rankin wrote:
This would explain why sftp got 'stuck' waiting on select() as Tim found! Somewhere in the sftp code, it must be checking on the ssh output beginning with line '6' looking for IP and port information:
debug1: Connecting to nirvana [192.168.6.17] port 6660.
however, with 5.9 it is getting:
debug1: Connection established.
Causing the code to endlessly wait on select() to get the IP and port!! Now - how to find where this takes place in the code to confirm?? It is probably a hardcoded as some array index like 'sshOutputLine[5]' which will now need to be changed to 'sshOutputLine[4]' to account for the deleted line in the output, or just rewritten with a regex to look for "[www.xxx.yyy.zzz] port 01234" in the output.
How do we look for code like this to rule in or rule out this problem?
I think the CHANGELOG narrows down the search and it is what was identified earlier:
2-19-2002 - get() now emits mimetype, fixes problem with konqi not downloading file for viewing in kpart. - get port number using getservbyname instead of hard coding it.
So it is the 'getservbyname' call that is relied upon to get the port information -- and I'll bet the fix is just what we talked about above. Now how to figure out how to make the pieces of 'getservbyname' return the port correctly again from the ssh output?
On 04/23/2012 11:03 PM, Darrell Anderson wrote:
Yes, but 3.5.10 was working during the OpenSSH <=5.5p1 days. Perhaps something changed >5.5p1 that causes that snippet to now fail?
Darrell
Exactly! There is no question you are 100% correct! The question is how to isolate what it was and how to fix it. That's where I'm running out of ammo. I have so little background in where all the little pieces of this puzzle come from that it makes finding the pieces and then understanding if they fit or not a very puzzling process.
It does look like "kdDebug(KIO_SFTP_DB)" is one of the critical pieces. In kio_sftp.cpp it apparently does the initial gathering of the ssh connection information:
kdDebug(KIO_SFTP_DB) << "setHost(): " << user << "@" << h << ":" << port << endl;
This looks to takes setHost(), the user the host and port to form the url "user@host:port". Now I don't know if this is just to form the error displayed or if this is where the actual information is gathered. It looks like it is the error, because the port should be 'mPort'.
That where we need an experienced eye on this issue :)
On 04/23/2012 11:03 PM, Darrell Anderson wrote:
Yes, but 3.5.10 was working during the OpenSSH <=5.5p1 days. Perhaps something changed >5.5p1 that causes that snippet to now fail?
Darrell
Moreover, it still works correctly in the kioslave/fish code. I looked at that, but I wasn't able to discern the port gathering part of it. I'll try and take another look later today, but we could also use a 2nd pair of eyes figuring this one out.
Fixed (hacked around) in GIT hash e72f492. Basically select() no longer works on newer systems (could be due to a malfunction of some kind, but it doesn't really matter), so instead of busywaiting on select(), newer systems will busywait on read().
I tested both sftp and fish using OpenSSH 5.5p1 at the client end and 5.7p1 at the other end.
I can SSH both ways using the terminal. I had no problems connecting to the 5.7p1 box with both sftp and fish.
I tested both sftp and fish using OpenSSH 5.5p1 at the client end and 5.9p1 at the other end.
I can SSH both ways using the terminal. I had no problems connecting to the 5.9p1 box with both sftp and fish.
I realize the suspicion is using OpenSSH > 5.5p1 at the client side and not the server side.
I tested both sftp and fish using OpenSSH 5.7p1 at the client end and 5.7p1 at the other end.
I can SSH both ways using the terminal. I had no problems connecting to the 5.9p1 box with fish but could not connect with sftp. I received an immediate error dialog:
Unexpected sftp error:2 error encountered while talking to ssh
I conducted these tests without the latest patch.
I rebuilt tdebase with the latest sftp patch.
I now no longer have a problem using sftp OpenSSH >5.5p1
The previous problem I described with fish failing occurs only when I run konqueror as root through tdesu. When I log into a Trinity session directly as root and then run fish I cannot repeat the failure. I can repeat the failure regularly when using fish through tdesu. Whenever I delete root's ksycoca cache then fish always succeeds when used through tdesu.
I can't replicate this fish failure with my KDE3 system. Running konqueror through kdesu works as expected.
These tests all were with the same OpenSSH 5.5p1 at both ends.
This failure describes a corner case but a nuisance bug nonetheless.
Good job with the patch. :)
Darrell
-
/dev/ammo42 -
Darrell Anderson -
David C. Rankin -
Francois Andriot -
François Andriot
-
François ANDRIOT
-
Mag. Dr. Nikolaus Klepp -
Serghei Amelian -
Slávek Banko -
Timothy Pearson