Red Hat Bugzilla – Bug 738635
scp upload ends with 'Error in the SSH layer'
Last modified: 2015-02-01 17:54:45 EST
Created attachment 523372 [details] abrt bug Description of problem: I used report uploader to report anaconda traceback. I wanted to save the traceback to remote system over scp. I received a message 'Error in the SSH layer' every time. When using scp manually the transfer worked ok. Version-Release number of selected component (if applicable): Fedora 16 Beta TC2 anaconda 16.17 Additional info: https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system
Proposing as F16 NTH, it can't be fixed afterwards.
(In reply to comment #0) > Created attachment 523372 [details] > abrt bug The URL is wrong, see the following FAQ: http://curl.haxx.se/docs/faq.html#How_to_SFTP_from_my_user_s_home
There is no documentation about supported syntax in the UI. So what is the correct syntax I can use _inside ABRT_ for scp and ftp?
The url from ui is passed directly to curl, so it's the same syntax as curl uses. URL is the directory where abrt should upload the file.
OK, I found the scp syntax: scp://login:password@host/path This one works. I'll leave this bug open until we figure out the ftp syntax (including path segment), because I need to document it in our test case [1]. If you know it (<poke>you should, you are the developers</poke>), please state it here. Removing blocker, functionality works, it's just utterly unfriendly. [1] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system
(In reply to comment #5) > OK, I found the scp syntax: > > scp://login:password@host/path > > This one works. > > I'll leave this bug open until we figure out the ftp syntax (including path > segment), because I need to document it in our test case [1]. If you know it > (<poke>you should, you are the developers</poke>), please state it here. Sounds weird to me. Did you try to replace 'scp' by 'ftp' in the scheme above? If you need a more detailed howto, you can have a look at RFC 1738...
I haven't tested FTP yet. I hope that you, as the program authors, are able to tell me the supported syntax, so that I can instruct testers to regularly test it, instead of finding the syntax using the trial-and-error approach.
The syntax is RFC 1738. Whoever can use a web browser knows how a URL looks like. The only extension in libcurl is the use of '~' for specifying user's home directory as I already mentioned in comment #2 (RFC 1738 says nothing about SCP and SFTP, but it does describe the URL syntax for FTP).
ok guys, we have 2 proposals how to fix this: 1. add a example text into the dialog: SCP: scp://name:password@hostname/directory FTP ftp://name:password@hostname/directory 2. use different UI: http://jmoskovc.fedorapeople.org/report_uploader_ui.png Ideas?
(In reply to comment #9) > 1. add a example text into the dialog: > > SCP: scp://name:password@hostname/directory > FTP ftp://name:password@hostname/directory In the SCP example, I would either use the '~': scp://name:password@hostname/~/directory ... or an apparent absolute path: scp://name:password@hostname/home/bob/directory Otherwise, most users would end up in non-existing directories since sending files somewhere to the home directory is a common use-case. > 2. use different UI: > http://jmoskovc.fedorapeople.org/report_uploader_ui.png That would introduce an unnecessary limitation. libcurl supports ~20 protocols (although not all of them are suitable for sending ABRT reports).
UI is more user friendly. Just please add some example inside (at least a tooltip) how the address should look like (I guess "host" or "host/path"). > That would introduce an unnecessary limitation. libcurl supports ~20 protocols > (although not all of them are suitable for sending ABRT reports). Well with current UI I would be very surprised if anyway except ABRT developers knew how to use it. With good UI docs even the one-line text field could be usable.
> Well with current UI I would be very surprised if anyway except ABRT ^^anyone
Created attachment 603465 [details] current unfriendly UI The uploader config dialog looks awfull with gtk3, I still propose using the other UI - even tho it's limitating, but c'mon who will use something else than ftp, scp, file ?? I really don't like this over generic approach which only leads to unusable UIs.
I think after this commit it looks significantly better: commit c3aaa2ae358657501a23dd1fe29535c0ffcc2521 Author: Denys Vlasenko <vda.linux@googlemail.com> Date: Fri Aug 17 17:29:13 2012 +0200 event_config_dialog: make it resizable; tweak Uploader hint Uploader config had its hint text horribly wrapped. Now the window looks like this: URL: [..........................................] Examples: ftp://[user[:pass]@]host/dir/[file.tar.gz] scp://[user[:pass]@]host/dir/[file.tar.gz] file:///dir/[file.tar.gz]
abrt-2.0.20-1.fc18,btparser-0.24-1.fc18,libreport-2.0.20-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/abrt-2.0.20-1.fc18,btparser-0.24-1.fc18,libreport-2.0.20-1.fc18
abrt-2.0.20-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/abrt-2.0.20-1.fc17
Package abrt-2.0.20-1.fc18, btparser-0.24-1.fc18, libreport-2.0.20-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abrt-2.0.20-1.fc18 btparser-0.24-1.fc18 libreport-2.0.20-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20725/abrt-2.0.20-1.fc18,btparser-0.24-1.fc18,libreport-2.0.20-1.fc18 then log in and leave karma (feedback).
abrt-2.0.20-1.fc18, btparser-0.24-1.fc18, libreport-2.0.20-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
abrt-2.0.20-1.fc17, btparser-0.24-1.fc17, libreport-2.0.20-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.