[jira] Commented: (SSHD-109) Pass server session to FileSystemFactory.createFileSystemView
[ https://issues.apache.org/jira/browse/SSHD-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002229#comment-13002229 ] Frank van der Kleij commented on SSHD-109: -- This is already part of 0.5.1-SNAPSHOT; please checkout the trunk. > Pass server session to FileSystemFactory.createFileSystemView > - > > Key: SSHD-109 > URL: https://issues.apache.org/jira/browse/SSHD-109 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 >Reporter: Richard Evans >Priority: Minor > > In the integration of sshd with our application we have a > PasswordAuthenticator implementation which authenticates against our internal > user database. From this we derive an internal user object which is needed > for further permissions checking, etc in the file system view. However the > createFileSystemView call takes a user name only. If the ServerSession was > passed to createFileSystemView also, the user object could be stored in the > session and retrieved when the file system view is created. In the current > system I have to store the user object in a ThreadLocal and get it from there > in createFileSystemView. > This would require a custom session factory and session object - if the > session had some internal storage for private attributes, etc (rather like an > HttpSession) this would not be necessary. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SSHD-107) Extend SshFile etc views to scp command
[ https://issues.apache.org/jira/browse/SSHD-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002224#comment-13002224 ] Frank van der Kleij commented on SSHD-107: -- This is already part of 0.5.1-SNAPSHOT; you could give it a try if you checkout the trunk. > Extend SshFile etc views to scp command > --- > > Key: SSHD-107 > URL: https://issues.apache.org/jira/browse/SSHD-107 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 >Reporter: Richard Evans >Priority: Minor > > Following the changes for SSHD-82, we have successfully integrated sshd into > our server application and sftp works well. It would be nice to allow the > use of scp also since that is sometimes simpler from the client side. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Question on SSHD
The ScpCommand has already been refactored to use the filesystem abstraction;
it is in the trunk...
Frank
> From: s...@google.com
> Date: Wed, 12 Jan 2011 08:07:01 -0800
> Subject: Re: Question on SSHD
> To: dev@mina.apache.org
>
> On Tue, Jan 11, 2011 at 07:06, Joerg Schmidbauer wrote:
> >
> > I'm currently investigating the possibilities of implementing
> > SSH/SCP/SFTP for VSE. My favorite scenario would be some kind of
> > a "proxy SSHD" running on Unix/Linux/Windows, forwarding commands
> > via IP to VSE, where an already existing server executes cmds
> > and sends the output back.
> ...
> > My question is basically: what's the simplest way of using the MINA SSHD
> > as a proxy with the VSE operating system? The most elegant way of course
> > would be just adding my code optionally without changing your code.
>
> Create your own SshServer instance. A good place to start is to use
> the setUpDefaultServer() method:
>
> SshServer sshd = SshServer.setUpDefaultServer();
>
> Now replace the CommandFactory with your own. This will handle any
> commands that come in from the command line and would forward them:
>
> sshd.setCommandFactory(new CommandFactory() {
> public Command createCommand(String commandLine) {
> return new VseCommand(commandLine);
> }
> });
>
> class VseCommand implements Command {
> public void start(Environment env) {
> ... create a new thread
> ... within the thread, forward command to VSE
> ... also do copying of InputStream, OutputStream, ErrorStream as
> necessary
> ... note you may need 3 threads (one for each stream)
> }
> }
>
> Likewise you can also replace the ShellFactory to support interactive
> shells, and FileSystemFactory to support the SFTP server's access to
> files.
>
> scp is a bit more difficult. Your CommandFactory would need to create
> and return the ScpCommand, but its file system interface hasn't been
> abstracted to use the FileSystemFactory. So right now ScpCommand
> modifies the SshServer's host filesystem as the SshServer's JVM user.
> Not exactly what you want. If you really need it, you should refactor
> ScpCommand to use the FileSystemFactory and try to submit the patch
> back to the project for inclusion in a future release.
RE: How add another way to authenticate ?
Basically you create your own implementation of org.apache.ftpserver.ftplet.UserManager and register it, e.g. http://mina.apache.org/ftpserver/spring/v1"; xmlns:beans="http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://mina.apache.org/ftpserver/spring/v1 http://mina.apache.org/ftpserver/ftpserver-1.0.xsd " id="myServer"> Good luck, Frank > From: sylver@gmail.com > Date: Mon, 29 Nov 2010 12:12:32 +0100 > Subject: How add another way to authenticate ? > To: dev@mina.apache.org > > Hi guys ! > > I need to add another way to authenticate on the FTP server, and i would > like your help to understand where & what add :) > It's very simple. The user enter his mail & password, the server send theses > informations somewhere on the web (like http://www.isitokay.com/signin). The > server analyse the response to the message and if it's a yes, the user is > able to connect to the ftp and to browse his directory. > > So, how i can do that ? I'm just a little lost between all the class, all > the bean so if you can guide me a little, it will help me a lot :) > > Thanks guys, > > Best Regards, > > Simon.
[jira] Updated: (SSHD-96) Virtual File System improvement for SCP and session injection
[ https://issues.apache.org/jira/browse/SSHD-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank van der Kleij updated SSHD-96: Attachment: sshd-96.patch This patch adds support for the Virtual Filesystem for SCP and allowd information exchange between the authenticator and the filesystem > Virtual File System improvement for SCP and session injection > - > > Key: SSHD-96 > URL: https://issues.apache.org/jira/browse/SSHD-96 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 > Reporter: Frank van der Kleij > Attachments: sshd-96.patch > > > The SCP Command does not yet use the Virtual File System implemented in > SSHD-82. > Another improvement is passing the ServerSession to FileSystemFactory instead > of just the user name. > This allows the injection of information known in the Authenticator into the > file system. > The particular use case is the implementation of a Virtual File System based > on Apache Commons VFS. > There the authenticator already contains the root file object (resulting from > the authentication) which needs to be passed to the FileSystemView. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SSHD-96) Virtual File System improvement for SCP and session injection
[ https://issues.apache.org/jira/browse/SSHD-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank van der Kleij updated SSHD-96: Attachment: (was: sshd-96.patch) > Virtual File System improvement for SCP and session injection > - > > Key: SSHD-96 > URL: https://issues.apache.org/jira/browse/SSHD-96 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 > Reporter: Frank van der Kleij > Attachments: sshd-96.patch > > > The SCP Command does not yet use the Virtual File System implemented in > SSHD-82. > Another improvement is passing the ServerSession to FileSystemFactory instead > of just the user name. > This allows the injection of information known in the Authenticator into the > file system. > The particular use case is the implementation of a Virtual File System based > on Apache Commons VFS. > There the authenticator already contains the root file object (resulting from > the authentication) which needs to be passed to the FileSystemView. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SSHD-96) Virtual File System improvement for SCP and session injection
[ https://issues.apache.org/jira/browse/SSHD-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931673#action_12931673 ] Frank van der Kleij commented on SSHD-96: - Sorry, I forgot the tests...I will submit a new patch > Virtual File System improvement for SCP and session injection > - > > Key: SSHD-96 > URL: https://issues.apache.org/jira/browse/SSHD-96 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 > Reporter: Frank van der Kleij > Attachments: sshd-96.patch > > > The SCP Command does not yet use the Virtual File System implemented in > SSHD-82. > Another improvement is passing the ServerSession to FileSystemFactory instead > of just the user name. > This allows the injection of information known in the Authenticator into the > file system. > The particular use case is the implementation of a Virtual File System based > on Apache Commons VFS. > There the authenticator already contains the root file object (resulting from > the authentication) which needs to be passed to the FileSystemView. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SSHD-96) Virtual File System improvement for SCP and session injection
[ https://issues.apache.org/jira/browse/SSHD-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank van der Kleij updated SSHD-96: Attachment: sshd-96.patch This patch adds the requested changes. > Virtual File System improvement for SCP and session injection > - > > Key: SSHD-96 > URL: https://issues.apache.org/jira/browse/SSHD-96 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 0.5.0 > Reporter: Frank van der Kleij > Attachments: sshd-96.patch > > > The SCP Command does not yet use the Virtual File System implemented in > SSHD-82. > Another improvement is passing the ServerSession to FileSystemFactory instead > of just the user name. > This allows the injection of information known in the Authenticator into the > file system. > The particular use case is the implementation of a Virtual File System based > on Apache Commons VFS. > There the authenticator already contains the root file object (resulting from > the authentication) which needs to be passed to the FileSystemView. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SSHD-96) Virtual File System improvement for SCP and session injection
Virtual File System improvement for SCP and session injection - Key: SSHD-96 URL: https://issues.apache.org/jira/browse/SSHD-96 Project: MINA SSHD Issue Type: Improvement Affects Versions: 0.5.0 Reporter: Frank van der Kleij The SCP Command does not yet use the Virtual File System implemented in SSHD-82. Another improvement is passing the ServerSession to FileSystemFactory instead of just the user name. This allows the injection of information known in the Authenticator into the file system. The particular use case is the implementation of a Virtual File System based on Apache Commons VFS. There the authenticator already contains the root file object (resulting from the authentication) which needs to be passed to the FileSystemView. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: (SSHD-82) Virtual File System
I am finally working on a VFS implementation now. For me it be more practical if the FileSystemFactory would receive the Session instead of just the username. The VFS Authenticator resolves the user name and password and string representing the root of the virtual filesystem and creates a FileObject. This FileObject should be injected in the FileSystemView, which can be done via the session. (In the past this information was picked up by the commands (shell, scp, sftp) through the setSession method) I also noticed that the SCP command is not yet using the FileSystemView. Should I propose a patch? Thanks, Frank > Date: Tue, 12 Oct 2010 14:33:17 -0400 > From: matthew.schu...@onlinebankingsolutions.com > To: dev@mina.apache.org > Subject: (SSHD-82) Virtual File System > > A patch has been attached to the SSHD-82 issue related to integrating a > Virtual File System similar to that in the Apache FTP Server into the > SSHD SFTP subsystem. The patch adds the VFS functionality, a native > filesystem implementation of the functionality, and a few other minor > improvements. > > Matthew Schulze
RE: [jira] Commented: (FTPSERVER-40) Support for SFTP
If you want to have a single API for FTP, FTPS and SFTP for your client you could have a look at Apache Commons VFS. Of course it also hides some stuff so you should see if suits you. Frank > Date: Wed, 6 Oct 2010 20:24:37 -0400 > From: j...@apache.org > To: dev@mina.apache.org > Subject: [jira] Commented: (FTPSERVER-40) Support for SFTP > > > [ > https://issues.apache.org/jira/browse/FTPSERVER-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918742#action_12918742 > ] > > Mike Baliel commented on FTPSERVER-40: > -- > > It would be great to see this project implement SFTP support... What would > be really nice is an SFTP client that mirrors the commands of the FTP and > FTPS client. I think a lot of developers come looking for SFTP support via > the commons net and are disappointed that it does not have support... > > > Support for SFTP > > > > > > Key: FTPSERVER-40 > > URL: https://issues.apache.org/jira/browse/FTPSERVER-40 > > Project: FtpServer > > Issue Type: Wish > > Environment: Apache FtpServer > >Reporter: Timothy Barlotta > > > > I looked through the JIRA for any information on plans for supporting SFTP > > (http://en.wikipedia.org/wiki/SSH_file_transfer_protocol) and did not see > > any information. Are there any plans for supporting SFTP? > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. >
[jira] Commented: (FTPSERVER-40) Support for SFTP
[ https://issues.apache.org/jira/browse/FTPSERVER-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918830#action_12918830 ] Frank van der Kleij commented on FTPSERVER-40: -- The Apache SSHD server has SFTP support now, though the framework is not as elaborated and customizable (yet) as in Apache FTP server. Note that it focusses on the server side, not the client. > Support for SFTP > > > Key: FTPSERVER-40 > URL: https://issues.apache.org/jira/browse/FTPSERVER-40 > Project: FtpServer > Issue Type: Wish > Environment: Apache FtpServer >Reporter: Timothy Barlotta > > I looked through the JIRA for any information on plans for supporting SFTP > (http://en.wikipedia.org/wiki/SSH_file_transfer_protocol) and did not see any > information. Are there any plans for supporting SFTP? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: SFTP problems
Great! and thanks > Date: Mon, 10 May 2010 07:33:45 +0200 > Subject: Re: SFTP problems > From: gno...@gmail.com > To: dev@mina.apache.org > > I think I've actually fixed the issue. The problem is that in version 3, > the reply to SSH_FXP_REALPATH should always send back dummy attributes. > > On Sun, May 9, 2010 at 16:15, Frank van der Kleij wrote: > > > > > I was doing some tests and found a problem on uploading. > > > > When doing the upload REALPATH is called on the file that is about to be > > created, but in writeAttrs there is a check whether the file actually exists > > and an exception is thrown. > > > > When I remove the exception throwing in writeAttrs then all seems to work > > correctly, so that is the easy solution. > > > > I believe that in the specs it says that on REALPATH dummy attributes > > should be sent so that's an option too. > > > > Any preference? > > > > Frank > > > > PS: this is unrelated, but if getUnixDate would be public I could use it in > > my subclass... > > > > > > _ > > Express yourself instantly with MSN Messenger! Download today it's FREE! > > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com _ New Windows 7: Simplify what you do everyday. Find the right PC for you. http://windows.microsoft.com/shop
RE: SFTP problems
I was doing some tests and found a problem on uploading. When doing the upload REALPATH is called on the file that is about to be created, but in writeAttrs there is a check whether the file actually exists and an exception is thrown. When I remove the exception throwing in writeAttrs then all seems to work correctly, so that is the easy solution. I believe that in the specs it says that on REALPATH dummy attributes should be sent so that's an option too. Any preference? Frank PS: this is unrelated, but if getUnixDate would be public I could use it in my subclass... _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
RE: SFTP problems
Hi Guillaume, I still have the FileNotFoundException when I start in e.g. d:\temp with f = new File(normalizedPath); For me it works only with f = resolveFile(normalizedPath); What are your settings? Do you start in '/' on Mac? Regards _ New Windows 7: Find the right PC for you. Learn more. http://windows.microsoft.com/shop
RE: SFTP problems
I'm testing on Windows in a non-root directory and the folder navigation works
but I have errors in the log because of this:
line 790:
f = new File(normalizedPath);
if (f.getName().length() == 0) {
f = new File(f, ".");
}
It causes errors in writeAttrs because the file doesn't really exist in the
normalized path (it is relative to the root).
I am not sure if it is necessary to reassign f, but if you need it you should
do resolveFile(f) to resolve it relative to the root.
Probably even "." should be resolved relative to the root.
Frank
_
New Windows 7: Find the right PC for you. Learn more.
http://windows.microsoft.com/shop
[SSHD] SFTP relies on Java 6?
Hi, Thanks for the SFTP support! There might be a small issue though. The SftpSubsystem.java uses java.io.File.canExecute() which was introduced in Java6. I think the pom still says SSHD compiles with Java5. Will you switch to Java6? Thanks, Frank _ New Windows 7: Find the right PC for you. Learn more. http://windows.microsoft.com/shop
RE: Extending Spring Configuration Definition
You could also replace the user manager by your own (which might subclass the existing). I did it like that, see http://vfs-utils.sourceforge.net/ftpserver/configuration.html Frank _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
[jira] Updated: (FTPSERVER-325) ftpd-full.xml does not show options on server element
[ https://issues.apache.org/jira/browse/FTPSERVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank van der Kleij updated FTPSERVER-325: -- Attachment: FTPSERVER-325.patch The patch is made relative to the full-ftpd.xml file. > ftpd-full.xml does not show options on server element > - > > Key: FTPSERVER-325 > URL: https://issues.apache.org/jira/browse/FTPSERVER-325 > Project: FtpServer > Issue Type: Improvement > Components: Server >Affects Versions: 1.0.2 > Reporter: Frank van der Kleij >Priority: Minor > Attachments: FTPSERVER-325.patch > > > The configuration options on the server element listed in > http://mina.apache.org/ftpserver/server.html > are not available in > distribution/res/conf/ftpd-full.xml > (except for the id attribute) > I'll submit a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-325) ftpd-full.xml does not show options on server element
ftpd-full.xml does not show options on server element - Key: FTPSERVER-325 URL: https://issues.apache.org/jira/browse/FTPSERVER-325 Project: FtpServer Issue Type: Improvement Components: Server Affects Versions: 1.0.2 Reporter: Frank van der Kleij Priority: Minor The configuration options on the server element listed in http://mina.apache.org/ftpserver/server.html are not available in distribution/res/conf/ftpd-full.xml (except for the id attribute) I'll submit a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [sshd] clients and echo
Thanks for the feedback. It's not that I wouldn't want to work on it, but unfortunately I don't have the time to dig in the SSH specifics. I am trying to abstract from it as much as possible and see it as a transport layer. I am working on it after hours only and got my hands full with the rest. In ChannelSession only ONCLR is used (in handleShell), do you think the echoing should be managed there or is it a shell responsibility? > Date: Mon, 17 Aug 2009 02:09:04 +0200 > Subject: Re: [sshd] clients and echo > From: gno...@gmail.com > To: dev@mina.apache.org > > The echo stuff amongst other things is sent using the pty-req command from > the ssh client to the server. > The problem is that those parameters can't be modified atm, so we need to > enhance the client api to allow overriding those parameters. > You can make a try by changing the client code and sending 0 for ECHO, > ECHOE, ECHO_K, ECHO_NL, NOFLSH and see if it behaves better. > > The other problem is that the server side supports this command and store > the value of the different configuration bits (see ChannelSession#ptyModes), > but has no way to inform the shell that those values have changed. > > I think we should raise jira about these issues and fix them if possible. > Wanna raise the jiras and eventually work on a patch ? > > On Sun, Aug 16, 2009 at 21:07, Frank van der Kleij wrote: > > > > > I am trying to roll my own sshd based server but I am having some issues > > with the different clients and echoing what comes in. > > > > It seems like most clients send each character to the server and expect the > > server to echo it. The term attribute is set to 'xterm ' for > > PuTTY and *nix based ssh clients; cygwin sets 'cygwin'. > > > > The java sshd client sets 'dummy' for term. It does not send each > > character, but waits until the user presses Enter and thus does not need the > > server to echo. Echoing would just repeat what the user entered before the > > result is shown. > > > > I am currently activating echo on the server when the term attribute starts > > with xterm or cygwin, but this does not seem a very good approach. God knows > > which other clients could connect. > > > > Is there any way to determine in a clean way whether the sshd server should > > echo what comes in? Should it always echo and is the sshd client wrong here? > > > > > > > > _ > > Express yourself instantly with MSN Messenger! Download today it's FREE! > > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
[sshd] clients and echo
I am trying to roll my own sshd based server but I am having some issues with the different clients and echoing what comes in. It seems like most clients send each character to the server and expect the server to echo it. The term attribute is set to 'xterm ' for PuTTY and *nix based ssh clients; cygwin sets 'cygwin'. The java sshd client sets 'dummy' for term. It does not send each character, but waits until the user presses Enter and thus does not need the server to echo. Echoing would just repeat what the user entered before the result is shown. I am currently activating echo on the server when the term attribute starts with xterm or cygwin, but this does not seem a very good approach. God knows which other clients could connect. Is there any way to determine in a clean way whether the sshd server should echo what comes in? Should it always echo and is the sshd client wrong here? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
RE: [sshd] does scp works?
Yes, I tried with the trunk. Using PuTTY (on Windows) I also have the problem in normal shell mode when sending large results of shell commands (e.g. cat). When I use the SSHD Client it does not block and when I use ssh from Linux neither. I copied the stack below. Thread [VfsShell] (Suspended) Object.wait(long) line: not available [native method] Window(Object).wait() line: not available Window.waitAndConsume(int) line: 124 ChannelOutputStream.flush() line: 89 ChannelOutputStream.write(byte[], int, int) line: 65 LoggingFilterOutputStream.write(byte[], int, int) line: 55 PrintStream.write(byte[], int, int) line: not available FileUtil.writeContent(FileObject, OutputStream) line: 91 Cat.cat(FileObject, Engine) line: 36 Cat.execute(Arguments, Engine) line: 30 BoxedEngine(Engine).handleCommand(Arguments) line: 259 BoxedEngine(Engine).go() line: 100 VfsShell.run() line: 178 Thread.run() line: not available > Date: Sun, 9 Aug 2009 10:40:42 +0200 > Subject: Re: [sshd] does scp works? > From: gno...@gmail.com > To: dev@mina.apache.org > > On Sat, Aug 8, 2009 at 18:55, Frank van der Kleij wrote: > > > > The SshClient is not scp enabled then? > > No, we don't have the client side yet. > > > > > I am now trying with putty's pscp and it works better. I found a small > > glitch for which I will submit a patch on JIRA. I still have a problem with > > recursive copy on a folder; > > > > The Window class says: 'Waiting for 16384 bytes on server remote window' > > and blocks... > > This does not look like an error specific to scp, but rather to the > ssh protocol. Have you tried with the latest trunk, I've committed a > few patches that might help. > > > > >> Date: Sat, 8 Aug 2009 18:27:21 +0200 > >> Subject: Re: [sshd] does scp works? > >> From: gno...@gmail.com > >> To: dev@mina.apache.org > >> > >> I only tried with the basic scp command from my mac. There may be > >> compatibilities problems and it has not been extensively tested. > >> > >> On Sat, Aug 8, 2009 at 16:18, Frank van der Kleij wrote: > >> > > >> > I am trying to write my own implementation of the ScpCommand using > >> > Apache VFS FileObject io File, but I have several issues. Is anyone > >> > using the ScpCommand? > >> > > >> > I copied the original and just patched it where needed so the problems I > >> > have are likely to exist in the normal ScpCommand too. > >> > > >> > I am probably doing something wrong but I noticed the following: > >> > 1. The last element of the command array is a newline character, but the > >> > ScpCommand treats it as being the filepath. The sshd SshClient > >> > explicitly puts a newline, the ScpCommandFactory splits at normal > >> > whitespace only. I fixed it by looking at the element just before the > >> > last. Is it part of the protocol? > >> > 2. The server hangs on readAck(). I know nothing of the protocol; is > >> > this a server problem or should the client send an ack? > >> > > >> > Which scp clients are compatible? I am using the SshClient of the sshd > >> > project. I tried WinScp but it wants to open a bash shell and does not > >> > seem to use pure scp... > >> > > >> > Thanks > >> > > >> > > >> > _ > >> > See all the ways you can stay connected to friends and family > >> > http://www.microsoft.com/windows/windowslive/default.aspx > >> > >> > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> > >> Blog: http://gnodet.blogspot.com/ > >> > >> Open Source SOA > >> http://fusesource.com > > > > _ > > See all the ways you can stay connected to friends and family > > http://www.microsoft.com/windows/windowslive/default.aspx > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com _ What can you do with the new Windows Live? Find out http://www.microsoft.com/windows/windowslive/default.aspx
RE: [sshd] does scp works?
The SshClient is not scp enabled then? I am now trying with putty's pscp and it works better. I found a small glitch for which I will submit a patch on JIRA. I still have a problem with recursive copy on a folder; The Window class says: 'Waiting for 16384 bytes on server remote window' and blocks... > Date: Sat, 8 Aug 2009 18:27:21 +0200 > Subject: Re: [sshd] does scp works? > From: gno...@gmail.com > To: dev@mina.apache.org > > I only tried with the basic scp command from my mac. There may be > compatibilities problems and it has not been extensively tested. > > On Sat, Aug 8, 2009 at 16:18, Frank van der Kleij wrote: > > > > I am trying to write my own implementation of the ScpCommand using Apache > > VFS FileObject io File, but I have several issues. Is anyone using the > > ScpCommand? > > > > I copied the original and just patched it where needed so the problems I > > have are likely to exist in the normal ScpCommand too. > > > > I am probably doing something wrong but I noticed the following: > > 1. The last element of the command array is a newline character, but the > > ScpCommand treats it as being the filepath. The sshd SshClient explicitly > > puts a newline, the ScpCommandFactory splits at normal whitespace only. I > > fixed it by looking at the element just before the last. Is it part of the > > protocol? > > 2. The server hangs on readAck(). I know nothing of the protocol; is this a > > server problem or should the client send an ack? > > > > Which scp clients are compatible? I am using the SshClient of the sshd > > project. I tried WinScp but it wants to open a bash shell and does not seem > > to use pure scp... > > > > Thanks > > > > > > _ > > See all the ways you can stay connected to friends and family > > http://www.microsoft.com/windows/windowslive/default.aspx > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com _ See all the ways you can stay connected to friends and family http://www.microsoft.com/windows/windowslive/default.aspx
[sshd] does scp works?
I am trying to write my own implementation of the ScpCommand using Apache VFS FileObject io File, but I have several issues. Is anyone using the ScpCommand? I copied the original and just patched it where needed so the problems I have are likely to exist in the normal ScpCommand too. I am probably doing something wrong but I noticed the following: 1. The last element of the command array is a newline character, but the ScpCommand treats it as being the filepath. The sshd SshClient explicitly puts a newline, the ScpCommandFactory splits at normal whitespace only. I fixed it by looking at the element just before the last. Is it part of the protocol? 2. The server hangs on readAck(). I know nothing of the protocol; is this a server problem or should the client send an ack? Which scp clients are compatible? I am using the SshClient of the sshd project. I tried WinScp but it wants to open a bash shell and does not seem to use pure scp... Thanks _ See all the ways you can stay connected to friends and family http://www.microsoft.com/windows/windowslive/default.aspx
RE: [sshd] use of session attributes and AttributeKey
> >
> > Has anyone used the ServerSession attributes? I'm puzzled by the
> > AttributeKey class that is used to define the key. It's an empty class
> > without any state. The only way I can see to use it is to make a subclass of
> > it, but that seems like a lot of trouble just to store something in the
> > session.
> > To be useful it should have some state together with the methods hashCode
> > and equals. The subclass I made is based on a String...
> > Am I missing something or should everyone define his own key? It would be
> > nice if something workable would be in the core...
>
>
> Yes, its easier than that. All you have to do is this:
>
> class MyState {
> public static final AttributeKey MY_STATE = new
> AttributeKey();
>
> public static MyState get(ServerSession s) {
> return s.getAttribute(MY_STATE);
> }
>
> public void put(ServerSession s) {
> s.setAttribute(MY_STATE, this);
> }
> }
>
> No need to subclass it. The reason AttributeKey exists as it does is to
> make the get/set methods have type safe signatures. You just need to create
> a new instance of the AttributeKey to get a unique entry in the attribute
> map. Since AttributeKey is then relying on reference equality, two keys are
> only equal if they are the same key instance. You can scope your attribute
> data by scoping your AttributeKey instance; if nobody can get your key,
> nobody can get (or set) your attribute.
Thanks, I did not think of that. I got my integration working now.
I submitted a patch to have communication between the PasswordAuthenticator and
the Shell; hopefully it will be integrated (or something similar) so I can
publish my project. In the patchI also added some documentation to the
AttributeKey class that describes your pattern.
_
What can you do with the new Windows Live? Find out
http://www.microsoft.com/windows/windowslive/default.aspx
[sshd] use of session attributes and AttributeKey
Has anyone used the ServerSession attributes? I'm puzzled by the AttributeKey class that is used to define the key. It's an empty class without any state. The only way I can see to use it is to make a subclass of it, but that seems like a lot of trouble just to store something in the session. To be useful it should have some state together with the methods hashCode and equals. The subclass I made is based on a String... Am I missing something or should everyone define his own key? It would be nice if something workable would be in the core... Thanks, Frank _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
RE: [sshd] access to identity in custom shell?
So the most symmetrical solution would be to pass the ServerSession to the PasswordAuthenticator and to have a SessionAware on the ShellFactory. Passing around the Identity would be done using session attributes. Not touching the PasswordAuthenticator interface but letting the UserAuthPassword store the Identity in the ServerSession would be less invasive, but would force the Identity concept onto everybody. For me the Identity concept could be a little stronger in the model, but it seems no one else needs it. I'll work on the symmetrical solution and propose it as a patch when finished. Thanks _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
[sshd] access to identity in custom shell?
Hi, I am trying to integrate my custom shell (that is based on Apache Commons VFS) in the sshd server. It starts to take form but I have some trouble. I have created a custom PasswordAuthenticator that I give a path that points to a Virtual File System. When it authenticates the user it returns a handle to a FileObject that represents the root directory as Identity. I also created a custom ShellFactory and custom Shell. In my shell I should initialize the current directory by giving it a FileObject that contains the authentication information. So I would need to have access to the Identity created during the authentication for this. Through the Environment given at the start of the shell I can have access to the username but that is not enough. Would it be possible to add the Identity object to the Environment? Are there better solutions? Thanks, Frank _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
RE: (FTPSERVER-119) STOR command should not eat exceptions when closing stream
close() at the end of the command. The command STOR is an
> example of one of these commands. At the end of STOR, the close() is in
> a final block, to insure that the close() will always happen.
>
>public class STOR {
> ...
> } finally {
> IoUtils.close(outStream);
> }
>}
>
> The IoUtils.close() traps and ignores any exception that occurred with
> the close().
>
> In most cases the above scenario is okay, however in some cases,
> ignoring exceptions on a close() is not okay. How to handle these?
>
> One proposal is to add a FileObject close() method. Why? Because the
> command -level operations like STOR have no idea about what to do for
> any particular implementation of a FileObject. Who knows best about the
> FileObject? the FileObject itself. So by adding a close() to the
> FileObject, allows the FileObject the opportunity to do some additional
> processing. One such opportunity is to close it's streams and handle any
> exceptions.
>
> Understand that a FileObject does not have to use the close() method, it
> can just be empty. In any case the command-level operation, such as STOR
> will call it anyway. Just to be sure that the stream really is closed,
> the command-level operation will always call close() on the stream. If
> the FileObject closed the stream, it's okay, the stream close() ignores
> all exceptions.
>
> The close() proposal would add the addition close() in the final block
> of commands that use a FileObject stream. In addition, the order would
> be to call the FileObject close() first and then the Stream close. This
> will give the FileObject an opportunity to "personally" deal with any
> tasks that it needs, such as closing a stream and catching the exceptions.
>
>public class STOR {
> ...
> } finally {
> // let the FileObject do some post-process tasks
> IoUtils.close(file);
>
> // as-a-safety-check, try to close the stream
> IoUtils.close(outStream);
> }
>}
>
> Hopefully all of this makes sense? Again, keep in mind that the close()
> is always done at the end of a command. In the current code only a
> stream close is done, but it's always done at the end of the command. At
> that point the command [STOR as an example] is done with the FileObject.
>
> Also keep in mind that the close() in a FileObject does not have to do
> anything. More importantly, calling the close() does not mean the FTP
> Server is finished with the FileObject. The close() is just giving the
> FileObject an opportunity to do some house-cleaning if it wants to.
>
> Andy Thomson
>
>
> Frank van der Kleij wrote:
> > Hi Andy,
> >
> > I don't think it's conceptually clean to close the file object before
> > the stream is closed, it's very counterintuitive. I think the stream
> > must be closed first and than the file object. The close on the stream
> > means the transfer is finished, the close on the file object means you're
> > done with it altogether (in theory releasing it to an object pool or
> > something similar).
> >
> >
> > In the handling you propose the exceptions are ignored anyway
> > (IOUtils.close(FileObject)) so it does not resolve the need to inform the
> > FTP client that the file transfer was not successful.
> >
> > I do think that a close on FileObject is necessary but I don't think it is
> > a solution to my problem...
> >
> > I don't quite follow your explanation of the assembly-line since I'm new
> > here. In my view the outputstream is written and closed in the context of
> > the STOR operation using a particular FileObject. If the close on the
> > stream fails, the exception should be caught and an error code should be
> > returned to the client. Likewise, if the close on the FileObject fails an
> > error should be returned to the client too.
> >
> > If you don't want to be bothered by exceptions on close I think it should
> > be the responsibility of the FileObject to muffle them; e.g. by wrapping
> > the OutputStream and ignore the exceptions on close there. In the current
> > situation the STOR command is explicitly killing all options to signal
> > something went wrong.
> >
> > Frank
> >
> >
> >
> >
> >> Date: Wed, 7 May 2008 21:18:14 -0600
> >> From: [EMAIL PROTECTED]
> >> To: dev@mina.apache.org
> >> Subject: Re: (FTPSERVER-119) STOR command should not eat exceptions when
> >> closing stream
> >>
> &
RE: (FTPSERVER-119) STOR command should not eat exceptions when closing stream
Hi Andy,
I don't think it's conceptually clean to close the file object before
the stream is closed, it's very counterintuitive. I think the stream
must be closed first and than the file object. The close on the stream means
the transfer is finished, the close on the file object means you're done with
it altogether (in theory releasing it to an object pool or something similar).
In the handling you propose the exceptions are ignored anyway
(IOUtils.close(FileObject)) so it does not resolve the need to inform the FTP
client that the file transfer was not successful.
I do think that a close on FileObject is necessary but I don't think it is a
solution to my problem...
I don't quite follow your explanation of the assembly-line since I'm new here.
In my view the outputstream is written and closed in the context of the STOR
operation using a particular FileObject. If the close on the stream fails, the
exception should be caught and an error code should be returned to the client.
Likewise, if the close on the FileObject fails an error should be returned to
the client too.
If you don't want to be bothered by exceptions on close I think it should be
the responsibility of the FileObject to muffle them; e.g. by wrapping the
OutputStream and ignore the exceptions on close there. In the current situation
the STOR command is explicitly killing all options to signal something went
wrong.
Frank
> Date: Wed, 7 May 2008 21:18:14 -0600
> From: [EMAIL PROTECTED]
> To: dev@mina.apache.org
> Subject: Re: (FTPSERVER-119) STOR command should not eat exceptions when
> closing stream
>
> Frank,
>
> What should probably happen is that the FileObject.close() should be
> called first, this then gives you the opportunity to close the stream
> and handle the errors. The outStream close() would be called anyway,
> because not everyone may want to handle their own close() so it insures
> the stream is closed.
>
> In the STOR command
>
> ...
> finally {
>
> // provide an opportunity for the FileObject to handle close
> IoUtils.close(file);
>
> // close the stream, it may have been previously closed, make sure
> IoUtils.close(outStream);
> }
>
> In the FileObject
>
> public void close() {
> // close the stream(s) or raf
>
> // do some other clean-up
> }
>
> This implies some changes in the FileObject issuance of the
> createOutputStream() and createInputStream() if you wish to handle the
> close on the stream(s). Or at least a change for the write-stream in any
> case.
>
> Once an operation [close() for example] leaves the FileObject, ie, it's
> at the Command-level, the command-level does not know one file object
> from another, nor if one FileObject is suppose to be handled
> differently, it's just doing an assembly-line operation.
>
> Does the above make sense on why a FileObject.close() was proposed?
> Trying to handle individual FileObject tasks at the command level just
> causes the "assembly-line" to slow down, and possibly break. Far better
> to call the FileObject and let it deal with it's needs.
>
> From your comments [excellent feedback], what should be done at the
> command-level is call the FileObject.close() first, then the stream close.
>
> Andy Thomson
>
> Frank van der Kleij wrote:
> > Thanks for commenting on the issue.
> >
> > The close on the file object seems a good idea in general but for me it
> > won't do the trick. The Apache VFS API does provide for close operations
> > but they serve a slightly different purpose.
> >
> > VFS uses a stream based API to write; three objects are involved, a
> > FileObject, a FileContent and an OutputStream ( to write you'd have to do
> > fileObject.getFileContent().getOutputStream() ). Close on FileObject means
> > you're done treating the file, which is different from meaning that you're
> > done writing to it. The same goes for close on FileContent, which is
> > supposed to release all resources and closes InputStreams as well. Only
> > close on the OutputStream only means that all data is transferred.
> >
> > For information, internally in VFS operations, e.g. on a copy operation,
> > the close is only called on the outputstream too.
> >
> > My point is that a close on the FileObject is not what I'm looking for; it
> > is rather the handling of exceptions on close of the stream that concern
> > me.
> >
> > I doubt it is really necessary to ignore exceptions on the close of the
> > stream. I can imagine it was done because the close is called in a finally
> > block and handling except
Re: (FTPSERVER-119) STOR command should not eat exceptions when closing stream
Thanks for commenting on the issue. The close on the file object seems a good idea in general but for me it won't do the trick. The Apache VFS API does provide for close operations but they serve a slightly different purpose. VFS uses a stream based API to write; three objects are involved, a FileObject, a FileContent and an OutputStream ( to write you'd have to do fileObject.getFileContent().getOutputStream() ). Close on FileObject means you're done treating the file, which is different from meaning that you're done writing to it. The same goes for close on FileContent, which is supposed to release all resources and closes InputStreams as well. Only close on the OutputStream only means that all data is transferred. For information, internally in VFS operations, e.g. on a copy operation, the close is only called on the outputstream too. My point is that a close on the FileObject is not what I'm looking for; it is rather the handling of exceptions on close of the stream that concern me. I doubt it is really necessary to ignore exceptions on the close of the stream. I can imagine it was done because the close is called in a finally block and handling exceptions there is rather ugly. By doing the close before the finally the exceptions can be handled normally. It would do a double close on the same stream, but streams are supposed to support that kind of thing. Best regards, Frank _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
(FTPSERVER-119) STOR command should not eat exceptions when closing stream
I am using the Mina FTPServer together with Apache Commons VFS to provide FTP access to the Documentum CMS. I created an alternative file system manager implementation for the FTPServer to bridge to the VFS (more details can be found at http://dctmvfs.sourceforge.net/ftpserver-vfs). Documentum access is realized using a plugin for VFS To import in Documentum I need to work with files, while the FTP (and VFS) interfaces work with streams. I solved this by using a handler on the close event of the stream that does the actual import. Since all kinds of errors can occur, these errors arrive in the FTP server on the close method on the stream, which are ignored for the moment. FTP clients therefore think the transfer was successful. Since I think the close is a major event in interfaces like this, I suggest to stop ignoring the possible exceptions. For for example by adding a close on the stream right after the method that uses the stream and to only ignore exceptions on a close in the finally block. The exact error message that should be sent can be a 551 as is the current IOException handling; but perhaps there are better options, I'm not too familiar with FTP error codes. Does anyone have any comments? Best regards, Frank Below, I've put my original JIRA request and Niklas Gustavssons comment. > Date: Sun, 6 Apr 2008 13:20:25 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: [jira] Commented: (FTPSERVER-119) STOR command should not eat > exceptions when closing stream > > > [ > https://issues.apache.org/jira/browse/FTPSERVER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586175#action_12586175 > ] > > Niklas Gustavsson commented on FTPSERVER-119: > - > > So, if I understand your request, you would like us to send a "551 Error on > output file" error message in an exception is thrown during close? If so, > please start a discussion on the dev list (dev@mina.apache.org) as it might > affect other people, just to make sure we do the right thing. > > > STOR command should not eat exceptions when closing stream > > -- > > > > Key: FTPSERVER-119 > > URL: https://issues.apache.org/jira/browse/FTPSERVER-119 > > Project: FtpServer > > Issue Type: Improvement > > Components: Core > >Affects Versions: 1.0 > > Environment: na > >Reporter: Frank > >Priority: Minor > > > > When the STOR commands closes the outputstream, it uses > > IOUtils.close(OutputStream) in a finally block which eats all exceptions. > > Wouldn't it be possible to first do a normal close on the stream after > > dataConnection.transferFromClient(outStream) and only eat exceptions on > > close in the finally block? > > Is there a reason for always eating close exceptions? > > If you consider changing it, would you also do it on branch1.4? > > I'll describe my motivation below: > > I have created a custom FileSystemManager based on Commons VFS. One of the > > VFS plugins I use stores the output stream temporarily as a file and then > > further handles the file when close is called on the output stream. > > When something goes wrong passing the file to lower levels an exception is > > thrown, but the exception gets eaten by IOUtils.close and a success message > > is sent to the FTP client. FileZilla for example already shows the file > > being transferred since it doesn't do a new directory listing, so for users > > it's quite difficult to find failed transfers. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
