Happy New Year to all.
I just noticed I can no longer sftp in konqueror to sites I normally "visit". It's been a week or 2 since I last used the feature, but I think a Trinity update may have caused this snafu.
I'm running Ubuntu 16.04 with Trinity 14.0.6 using the Preliminary Stable Builds repository.
konqueror "claims" it's connecting, but it just hangs after that. I see _nothing_ concerning the attempt in either the local or remote logs.
Every failure in konqueror works Just Fine when replicated on the command line. E.G.,
sftp://UserID:PASSword@example.com fails in konqueror
sftp UserID:PASSword@example.com connects just fine on the command line
... as well, it fails on sites where I use SSH Key-Based Authentication. And, again, it works Just Fine at the command line.
Anyone else confirm?
Thank you, Jonesy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2018/12/31 02:17 AM, Marvin Jones via trinity-users wrote:
Happy New Year to all.
I just noticed I can no longer sftp in konqueror to sites I normally "visit". It's been a week or 2 since I last used the feature, but I think a Trinity update may have caused this snafu.
I'm running Ubuntu 16.04 with Trinity 14.0.6 using the Preliminary Stable Builds repository.
konqueror "claims" it's connecting, but it just hangs after that. I see _nothing_ concerning the attempt in either the local or remote logs.
Every failure in konqueror works Just Fine when replicated on the command line. E.G.,
sftp://UserID:PASSword@example.com fails in konqueror
sftp UserID:PASSword@example.com connects just fine on the command line
.. as well, it fails on sites where I use SSH Key-Based Authentication. And, again, it works Just Fine at the command line.
Anyone else confirm?
Thank you, Jonesy
I am on R14.1.0-dev and sftp works fine in Konqueror. Does your password contain special non-ASCII characters? And if so, what is your locale? Cheers Michele
On Mon, 31 Dec 2018, Michele Calgaro via trinity-users wrote:
On 2018/12/31 02:17 AM, Marvin Jones via trinity-users wrote:
Happy New Year to all.
I just noticed I can no longer sftp in konqueror to sites I normally "visit". It's been a week or 2 since I last used the feature, but I think a Trinity update may have caused this snafu.
I'm running Ubuntu 16.04 with Trinity 14.0.6 using the Preliminary Stable Builds repository.
konqueror "claims" it's connecting, but it just hangs after that. I see _nothing_ concerning the attempt in either the local or remote logs.
Every failure in konqueror works Just Fine when replicated on the command line. E.G.,
sftp://UserID:PASSword@example.com fails in konqueror
sftp UserID:PASSword@example.com connects just fine on the command line
.. as well, it fails on sites where I use SSH Key-Based Authentication. And, again, it works Just Fine at the command line.
I am on R14.1.0-dev and sftp works fine in Konqueror. Does your password contain special non-ASCII characters? And if so, what is your locale?
Thank you for your reply.
No, I have no "special non-ASCII characters" in the passwords. Anyway, as I stated in the OP, it also fails on sites where I use SSH Key-Based Authentication.
$ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=
Still fails after a reboot on the client end. The other end involves various servers.
ssh, sftp, and sshfs all play nice from the command line.
I'll do a test that just occurred to me: I'll try sftp'ing into my own workstation.
I'll be back in a while. Jonesy
Am Montag, 31. Dezember 2018 schrieb Marvin Jones via trinity-users:
On Mon, 31 Dec 2018, Michele Calgaro via trinity-users wrote:
On 2018/12/31 02:17 AM, Marvin Jones via trinity-users wrote:
Happy New Year to all.
I just noticed I can no longer sftp in konqueror to sites I normally "visit". It's been a week or 2 since I last used the feature, but I think a Trinity update may have caused this snafu.
I'm running Ubuntu 16.04 with Trinity 14.0.6 using the Preliminary Stable Builds repository.
konqueror "claims" it's connecting, but it just hangs after that. I see _nothing_ concerning the attempt in either the local or remote logs.
Every failure in konqueror works Just Fine when replicated on the command line. E.G.,
sftp://UserID:PASSword@example.com fails in konqueror
sftp UserID:PASSword@example.com connects just fine on the command line
.. as well, it fails on sites where I use SSH Key-Based Authentication. And, again, it works Just Fine at the command line.
I am on R14.1.0-dev and sftp works fine in Konqueror. Does your password contain special non-ASCII characters? And if so, what is your locale?
Thank you for your reply.
No, I have no "special non-ASCII characters" in the passwords. Anyway, as I stated in the OP, it also fails on sites where I use SSH Key-Based Authentication.
$ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=
Still fails after a reboot on the client end. The other end involves various servers.
ssh, sftp, and sshfs all play nice from the command line.
I'll do a test that just occurred to me: I'll try sftp'ing into my own workstation.
I'll be back in a while. Jonesy
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Does fish://.... work?
On Mon, 31 Dec 2018, Marvin Jones via trinity-users wrote:
I just noticed I can no longer sftp in konqueror to sites I normally "visit". It's been a week or 2 since I last used the feature, but I think a Trinity update may have caused this snafu.
I'm running Ubuntu 16.04 with Trinity 14.0.6 using the Preliminary Stable Builds repository. Still fails after a reboot on the client end. The other end involves various servers.
ssh, sftp, and sshfs all play nice from the command line.
I'll do a test that just occurred to me: I'll try sftp'ing into my ownw orkstation.
OH BOY! It just gets stranger and stranger.
One of my brain cells fired off and I remembered "fish". (And I just now see a reply from Nikolaus also about "fish".)
So, locally I tried all 'flavors' of sftp and fish. All the following done in the konqueror address "box":
|fish://jonesy@localhost (WORKS!)
|fish://jonesy@127.0.0.1 (instantly:) |An error occurred while loading fish://jonesy@127.0.0.1: |Could not connect to host 127.0.0.1.
|fish://jonesy@192.168.1.17 (instantly:) |An error occurred while loading fish://jonesy@192.168.1.17: |Could not connect to host 192.168.1.17.
|sftp://jonesy@localhost (after about 1 minute:) |An error occurred while loading sftp://jonesy@localhost: |The process for the sftp://localhost protocol died unexpectedly.
|sftp://jonesy@127.0.0.1 (after about 1 minute:) |An error occurred while loading sftp://jonesy@127.0.0.1: |The process for the sftp://127.0.0.1 protocol died unexpectedly.
|sftp://jonesy@192.168.1.17 (after about 1 minute:) |An error occurred while loading sftp://jonesy@192.168.1.17: |The process for the sftp://192.168.1.17 protocol died unexpectedly.
What's especially strange is that fish to localhost WORKS (which IS mapped to 127.0.0.1 in /etc/hosts), but fish to 127.0.0.1 FAILS!
So, the test(s) shows that problem occurs within my local workstation, and should rule out any issue with the remote hosts.
I have to believe the problem is in konqueror or some sub-component it uses for this feature/function.
How to debug?? It's not like I can use -v -v -v as I can on the ssh/sftp command line.
Jonesy
On 12/31/2018 09:12 AM, Marvin Jones via trinity-users wrote:
What's especially strange is that fish to localhost WORKS (which IS mapped to 127.0.0.1 in /etc/hosts), but fish to 127.0.0.1 FAILS!
So, the test(s) shows that problem occurs within my local workstation, and should rule out any issue with the remote hosts.
I have to believe the problem is in konqueror or some sub-component it uses for this feature/function.
Back in the 2012 days there was a bug with sftp:// that Tim patched, but in that case fish continued to work. If both sftp and fish fail in konqueror, but work in konsole from the command line, then that would point to a tdelibe/kio_slaves (or maybe tdebase) I haven't looked in ages. There is global component that coordinate the kioslaves themselves as well as source file for each individual slave (e.g. sftp, fish, etc..)
The fact that it works on the command line would tend to rule out a name-resolution issue.
On Mon, 31 Dec 2018, David C. Rankin wrote:
On 12/31/2018 09:12 AM, Marvin Jones via trinity-users wrote:
What's especially strange is that fish to localhost WORKS (which IS mapped to 127.0.0.1 in /etc/hosts), but fish to 127.0.0.1 FAILS!
So, the test(s) shows that problem occurs within my local workstation, and should rule out any issue with the remote hosts.
I have to believe the problem is in konqueror or some sub-component it uses for this feature/function.
Back in the 2012 days there was a bug with sftp:// that Tim patched, but in that case fish continued to work. If both sftp and fish fail in konqueror, but work in konsole from the command line, then that would point to a tdelibe/kio_slaves (or maybe tdebase) I haven't looked in ages. There is global component that coordinate the kioslaves themselves as well as source file for each individual slave (e.g. sftp, fish, etc..)
Ahhh... I thought fish and sftp were realized "internally".
|jonesy@nix5:~$ locate sftp | egrep '(bin|lib)' |/opt/trinity/lib/trinity/tdeio_sftp.la |/opt/trinity/lib/trinity/tdeio_sftp.so |/usr/bin/sftp |/usr/lib/gvfs/gvfsd-sftp |/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/sftp.so
|jonesy@nix5:~$ locate fish | egrep '(bin|lib)' |/opt/trinity/lib/trinity/tdeio_fish.la |/opt/trinity/lib/trinity/tdeio_fish.so |/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/fish.so
(The output from `locate fish | egrep '(bin|lib)'` needed editing to eliminate non-applicable system/application components.)
The fact that it works on the command line would tend to rule out a name-resolution issue.
That, and the fact that it fails using ip destination addressing.
And, why would it work -- out of all the possible sftp & fish combinations I tried -- ONLY with fish://jonesy@localhost/
I believe it was working up to the most recent system update I did. That update brought in a bunch of system (Ubuntu) and Trinity changes.
I still believe the problem lies with konqueror -- or with a new incompatibility between konqueror (Trinity) and Ubuntu.
I can readily do almost everything I need with command line ssh, sftp, and sshfs. But, there are some maintenance activities that would be SO MUCH easier and straightforward with konqueror.
Jonesy
On 12/31/2018 08:31 PM, Marvin Jones via trinity-users wrote:
I believe it was working up to the most recent system update I did. That update brought in a bunch of system (Ubuntu) and Trinity changes.
I still believe the problem lies with konqueror -- or with a new incompatibility between konqueror (Trinity) and Ubuntu.
I can readily do almost everything I need with command line ssh, sftp, and sshfs. But, there are some maintenance activities that would be SO MUCH easier and straightforward with konqueror.
It sounds like how the url is being passed by konqueror to the kioslaves. (I'm still on KDE3 (Leap 15) and both fish and sftp are working fine (just tried a remote sftp:// to my office using RSA keys and it works flawlessly)
I do recall a large "renaming" effort that was going to take place a month or two ago -- you could be experiencing "side-effects" of the latest round (a 't' and 'k' mismatch?) Hopefully you are not the proverbial Canary-in-the-Coal-Mine...
The only problem I have encountered in the past year or so was with openssh reducing the number of sequential logins allowed (so with kate when I had 100 build scripts open, the first 20 were fine and the last 80 would fail initially), but that isn't your issue.
There was a way to set kdebug logging individually with kdebugdialog. You may want to make sure the following are enabled (should be by default)
127 kio (kProtocolInfo) 170 kdecore (KNetwork sockets) 174 kdecore (KProcIO) 1219 media kioslave 1220 remote kioslave 5100 libkdenetwork 7000 kio 7002 kio (Slave) 7005 kio (Filter) 7007 kio (KIOJob) 7017 kio (KIOConnection) 7019 kio (kioslave) 7023 kuirfilter (plugins) 7024 kio (UIServer) 7027 kio (TCPSlaveBase) 7032 kio (KURLCompletion) 7120 kio_sftp 7127 kio_fish
(they should be on/checked by default)
That's about the best I can think of.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I do recall a large "renaming" effort that was going to take place a month or two ago -- you could be experiencing "side-effects" of the latest round (a 't' and 'k' mismatch?) Hopefully you are not the proverbial Canary-in-the-Coal-Mine...
It is definitely not that, since the renaming was only applied to the master branch (e.g. R14.1.0 DEV).
There was a way to set kdebug logging individually with kdebugdialog. You may want to make sure the following are enabled (should be by default)
127 kio (kProtocolInfo) 170 kdecore (KNetwork sockets) 174 kdecore (KProcIO) 1219 media kioslave 1220 remote kioslave 5100 libkdenetwork 7000 kio 7002 kio (Slave) 7005 kio (Filter) 7007 kio (KIOJob) 7017 kio (KIOConnection) 7019 kio (kioslave) 7023 kuirfilter (plugins) 7024 kio (UIServer) 7027 kio (TCPSlaveBase) 7032 kio (KURLCompletion) 7120 kio_sftp 7127 kio_fish
Just for info, most of these are now tde* and not k* in TDE and the application is called tdedebugdialog.
Cheers Michele
On 01/02/2019 07:35 PM, Michele Calgaro via trinity-users wrote:
Just for info, most of these are now tde* and not k* in TDE and the application is called tdedebugdialog.
Cheers Michele
As long as you don't rename
Kate -> Take or Konsole -> Tonsole or Konqueror -> Tonqueror,
I guess the renaming makes sense.
(though personally I've always wondered if those hundreds of man-hours may not have been better spent elsewhere)
Glad the ssh/fish issue wasn't a side-effect.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2018/12/31 10:37 PM, Marvin Jones via trinity-users wrote:
No, I have no "special non-ASCII characters" in the passwords.
Ok thanks. The reason why I asked is that there were some changes a few weeks ago related to password handling code and if you had special non-ascii characters in your password, this could have perhaps been a problem. With normal ASCII chars we can rule out any influence from this.
Yeah, your problem seems a bit funny to say the least, since I would expect either everything works or everything fails, but not a mix of that. I can't reproduce it here, but please open a bug report on bugzilla or even better a issue report on TGW, so that it does not get lost. https://mirror.git.trinitydesktop.org/gitea https://wiki.trinitydesktop.org/TDE_Gitea_Workspace (guide)
Is anyone else able to reproduce the same issue? Or does sftp/fish works fine?
Cheers Michele
On Monday 31 December 2018 09:09:38 pm Michele Calgaro via trinity-users wrote:
On 2018/12/31 10:37 PM, Marvin Jones via trinity-users wrote:
No, I have no "special non-ASCII characters" in the passwords.
Ok thanks. The reason why I asked is that there were some changes a few weeks ago related to password handling code and if you had special non-ascii characters in your password, this could have perhaps been a problem. With normal ASCII chars we can rule out any influence from this.
Yeah, your problem seems a bit funny to say the least, since I would expect either everything works or everything fails, but not a mix of that. I can't reproduce it here, but please open a bug report on bugzilla or even better a issue report on TGW, so that it does not get lost. https://mirror.git.trinitydesktop.org/gitea https://wiki.trinitydesktop.org/TDE_Gitea_Workspace (guide)
Is anyone else able to reproduce the same issue? Or does sftp/fish works fine?
Konqueror R14.04 (Using Trinity R14.04)
sftp://username@IP
works fine. (SSH Key-Based Authentication)
Hope that helps to reduce a data point...
Best, Michael
Am Dienstag, 1. Januar 2019 schrieb Michael:
On Monday 31 December 2018 09:09:38 pm Michele Calgaro via trinity-users
wrote:
On 2018/12/31 10:37 PM, Marvin Jones via trinity-users wrote:
[…]
Is anyone else able to reproduce the same issue? Or does sftp/fish works fine?
Konqueror R14.04 (Using Trinity R14.04)
sftp://username@IP
works fine. (SSH Key-Based Authentication)
fish://username@server sftp://username@server
both seem to work with SSH Key-Based Authentication.
$ konqueror --version Qt: 3.5.0 TDE: R14.0.6 [DEVELOPMENT] Konqueror: R14.0.5
$ acp konqueror-trinity konqueror-trinity: Installiert: 4:14.0.6~pre29-0debian9.0.0+9 Installationskandidat: 4:14.0.6~pre29-0debian9.0.0+9 Versionstabelle: *** 4:14.0.6~pre29-0debian9.0.0+9 500 500 http://mirror.xcer.cz/trinity-sb stretch/main-r14 amd64 Packages 100 /var/lib/dpkg/status
Kind regards, Stefan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2019/01/09 04:36 AM, Stefan Krusche wrote:
Am Dienstag, 1. Januar 2019 schrieb Michael:
On Monday 31 December 2018 09:09:38 pm Michele Calgaro via trinity-users
wrote:
On 2018/12/31 10:37 PM, Marvin Jones via trinity-users wrote:
[…]
Is anyone else able to reproduce the same issue? Or does sftp/fish works fine?
Konqueror R14.04 (Using Trinity R14.04)
sftp://username@IP
works fine. (SSH Key-Based Authentication)
fish://username@server sftp://username@server
both seem to work with SSH Key-Based Authentication.
$ konqueror --version Qt: 3.5.0 TDE: R14.0.6 [DEVELOPMENT] Konqueror: R14.0.5
$ acp konqueror-trinity konqueror-trinity: Installiert: 4:14.0.6~pre29-0debian9.0.0+9 Installationskandidat: 4:14.0.6~pre29-0debian9.0.0+9 Versionstabelle: *** 4:14.0.6~pre29-0debian9.0.0+9 500 500 http://mirror.xcer.cz/trinity-sb stretch/main-r14 amd64 Packages 100 /var/lib/dpkg/status
Kind regards, Stefan
For those interested in follow ups, the discussion is going on TGW tdebase #24. https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/issues/24
Cheers Michele
On Tue, 1 Jan 2019, Michele Calgaro via trinity-users wrote: On 2018/12/31 10:37 PM, Marvin Jones via trinity-users wrote:
No, I have no "special non-ASCII characters" in the passwords.
Ok thanks. The reason why I asked is that there were some changes a few weeks ago related to password handling code and if you had special non-ascii characters in your password, this could have perhaps been a problem. With normal ASCII chars we can rule out any influence from this.
As well, it fails with ssh-key authentication.
Yeah, your problem seems a bit funny to say the least, since I would expect either everything works or everything fails, but not a mix of that. I can't reproduce it here, but please open a bug report on bugzilla or even better a issue report on TGW, so that it does not get lost. https://mirror.git.trinitydesktop.org/gitea https://wiki.trinitydesktop.org/TDE_Gitea_Workspace (guide)
Thanks for the pointers (above). The last time I worked with the Trinity bug system was years ago -- back in my Ubuntu 9.1 days!
I'll report my problem (the bug) next year. :-) (3+ hours from now.)
Jonesy
-
David C. Rankin -
Dr. Nikolaus Klepp -
Marvin Jones via trinity-users -
Michael -
Michele Calgaro via trinity-users
-
Stefan Krusche