Thinking a bit more about this, I think the following would make sense: * copy FtpFile and NativeFtpFile from FtpServer into the sshd subsystem package * copy the SftpSubsystem to AbstractSftpSubsystem and rework it to use a FtpFile root * rework SftpSubsystem to inherit AbstractSftpSubsystem and just provide a NativeFtpFile file system root
For the long term solution, I think it would make more sense to do the work in FtpServer and use SSH as an addition transport layer, thus reusing user management, file system users configuration and all ... It should be then really simple to implement an org.apache.sshd.server.sftp.FtpFile on top of the existing ftpserver FtpFile and provide a user authentication mechanism delegating to the ftpserver auth mechanism. On Mon, Jun 14, 2010 at 11:27, Guillaume Nodet <[email protected]> wrote: > > > On Thu, Jun 10, 2010 at 20:19, Chuck Johnstone < > [email protected]> wrote: > >> Hi, >> >> As per the previous email I'm going to experimentally rework SftpSubsystem >> to use a db backend. >> >> My current approach is to copy SftpSubsystem and abstract out the file >> access. The new class is called AbstractSftpSubsystem. >> >> Right now I've created an interface that mimics all the pertinent bits of >> java.io.File as used in SftpSubsystem. >> >> The interface currently looks like this: >> >> public static interface SftpFile { // from java.io.File >> boolean exists(); >> boolean createNewFile(); >> SftpFile getParentFile(); // based on File.getParentFile() >> String getPath(); >> long length(); >> boolean canRead(); >> boolean canWrite(); >> boolean isFile(); >> boolean isDirectory(); >> long lastModified(); >> SftpFile[] listFiles(); >> String getName(); >> boolean delete(); >> boolean mkdir(); >> boolean renameTo(SftpFile dest); >> SftpFile getAbsoluteFile(); >> } >> > > Yeah, looks good. Though, we'd need to be able to read / write to those > files, which isn't possible in this interface. > I really wonder if a simplier approach would be to just copy the FtpFile > interface [1] into the subsystem package. At least, we'd know that we'll be > able to bridge with FtpServer quite easily. > > [1] > http://svn.apache.org/viewvc/mina/ftpserver/trunk/ftplet-api/src/main/java/org/apache/ftpserver/ftplet/FtpFile.java?view=markup > >> >> I believe this is in line with the discussion so far. If there is a >> better way let me know. I'll submit patches if you think this approach is >> useful. >> >> Cool ! Patches is the way to go ... > > >> The good news is that my company is funding the development time. The >> above approach is our short term solution to this problem but we're also >> interested in a longer term solution. Mention was made of moving this into >> apache ftpServer. We intend to help with that too. I've used ftpServer to >> implement a backend FTPS solution so I'm a bit familiar with the system but >> I'm not familiar with the details of SFTP. I'm assuming that SFTP code from >> SftpSubsystem could be ported into Mina ftpServer structures. >> > > Well, I'm not very familiar with the FtpServer project. I wonder if it > would be easier / cleaner to integrate SSHD into FtpServer project as an > additional transport, or integrate FtpServer into SSHD as a new backend for > SFTP subsystem. Maybe other FtpServer people can jump in and throw some > ideas here. > > >> >> I'll be focused on the short term solution over the next few weeks but >> after that I can move onto the longer term solution. Discussion/guidance in >> this task will be greatly appreciated. >> >> Chuck Johnstone >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
