Re: [jira] Commented: (FTPSERVER-184) IODataConnection ASCII mode does not work as expected.
I've a couple of classes to handle the ASCII transfer mode. Since
these classes are inherited from InputStream and OutputStream, you
should be able to plug these in very easily by just wrapping the
original stream into the new stream. I used these classes in my FTP
Client implementation. We should be able to use these in the Server as
well with no (or little) modifications.
I've attached the classes for you to take a look at.
Regards,
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Mon, Nov 17, 2008 at 3:26 PM, Niklas Gustavsson (JIRA)
<[EMAIL PROTECTED]> wrote:
>
>[
> https://issues.apache.org/jira/browse/FTPSERVER-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648348#action_12648348
> ]
>
> Niklas Gustavsson commented on FTPSERVER-184:
> -
>
> David, would you like to work on this for M4 or should we reschedule it for
> now? I do think we should fix this, but it could be done for 1.0
>
>> IODataConnection ASCII mode does not work as expected.
>> --
>>
>> Key: FTPSERVER-184
>> URL: https://issues.apache.org/jira/browse/FTPSERVER-184
>> Project: FtpServer
>> Issue Type: Improvement
>> Components: Core
>>Affects Versions: 1.0-M2, 1.0-M3
>>Reporter: David Latorre
>>Assignee: Niklas Gustavsson
>> Fix For: 1.0-M4
>>
>>
>> New lines in files sent in ASCII mode are transformed into /r/n no matter
>> what platform the ftp server is running on. But if I'm not wrong, the new
>> EOL should be equal to "line.separator" . If ASCII mode is going to be
>> supported, this ought to be changed.
>>
>> The code in IODataConnection.transfer()
>> {
>> if (isAscii) {
>> for (int i = 0; i < count; ++i) {
>> byte b = buff[i];
>> if (b == '\n' && !lastWasCR) {
>> bos.write('\r');
>> }
>> if (b == '\r') {
>> lastWasCR = true;
>> } else {
>> lastWasCR = false;
>> }
>> bos.write(b);
>> }
>> }
>> }
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
[X] +1 Yes, accept the SSH server as a sub-project Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Wed, Nov 19, 2008 at 5:21 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Hi guys, > > Guillaume Nodet has written a SSH server based on MINA, and as we discussed > it last week, it would be interesting to have it as a subproject. It's time > for a formal vote then : > > [] +1 Yes, accept the SSH server as a sub-project > [] +/-0 I don't really care > [] -1 Nope, it does not belong to MINA > > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
Re: Ftplet configuration FAQ
I think you need to define the namespace and schema for the "beans" as
shown the ftpd-full.xml.
Here are the lines you need to have at the beginning of the config file.
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://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://mina.apache.org/ftpserver/spring/v1
http://mina.apache.org/ftpserver/ftpserver-1.0.xsd
"
id="myServer">
Hope this helps.
Regards,
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Wed, Nov 26, 2008 at 7:10 AM, Vinod Kumar Singh, Noida <[EMAIL PROTECTED]>
wrote:
> Hi,
>
>
>
> I am just been started development of customized ftplet and trying to
> configure as mentioned in this site. Though I have done as instructed, I
> still not able to include my customized ftplet functions.
>
> I just include my customized ftplet and configuration adding into the xml
> file as attachment for your reference.
>
>
>
> 1) ftpd-typical.xml – As instructed configuration for ftplets added
>
> 2) FtpConnect.java – extending the DefaultFtplet class to implement the
> required methods by overriding them, but its just an default implementation
> with logging statement so that it can be tested for actually these methods
> are called then I can probably implement them as per requirement.
>
> 3) ftpleterror.txt – this has the error and execution command for ftplet
>
>
>
> I need your help to fix this up as soon as possible. Thanks for your effort.
>
>
>
> Thanks and Regards,
>
> Vinod
>
>
Re: [VOTE] Releasing FtpServer 1.0.0-M4
Let's do it! > [ +]: +1, Release FtpServer 1.0.0-M4 > [ ]: 0, Abstain > [ ]: -1, Don't release MINA 1.0.0-M4 Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Tue, Dec 2, 2008 at 2:59 PM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote: > Hi > > Time to get the beast out, this is the vote for 1.0.0-M4 of FtpServer, > a subproject of MINA. M4 is aimed at being feature complete and with a > stable API. Hopefully, we can fix bugs and documentation and then > release RC1. > > You can find the binaries, RAT reports and Maven artifacts here: > http://people.apache.org/~ngn/ftpserver/1.0.0-M4/ > > These files was built from the following code: > http://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.0-M4/ > > Revision 722616. > > Let's get trashing! > [ ]: +1, Release FtpServer 1.0.0-M4 > [ ]: 0, Abstain > [ ]: -1, Don't release MINA 1.0.0-M4 > > /niklas >
Re: [jira] Assigned: (FTPSERVER-227) RMD command should not delete the current working directory or the any parent of current working directory
Not sure what this e-mail from Jira means, but have any of you had a chance to look at the patch I submitted for this? Thanks. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Wed, Dec 10, 2008 at 5:46 AM, David Latorre (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > David Latorre reassigned FTPSERVER-227: > --- > >Assignee: David Latorre > >> RMD command should not delete the current working directory or the any >> parent of current working directory >> -- >> >> Key: FTPSERVER-227 >> URL: https://issues.apache.org/jira/browse/FTPSERVER-227 >> Project: FtpServer >> Issue Type: Bug >> Components: Core >>Affects Versions: 1.0.0-M4 >>Reporter: Sai Pullabhotla >>Assignee: David Latorre >> Fix For: 1.0.0-RC1 >> >> Attachments: FTPSERVER-227_patch.text >> >> >> RMD command should not delete the current working directory or the any >> parent of current working directory. >> case 1: Let us say, the current working directory is "/wd" then "RMD ." or >> RMD "/wd" should result in a 5XX reply. >> case 2: Let us say the working directory is "/wd/subdir", then RMD /wd or >> "RMD .." should also be restricted and a 5xx reply should be sent. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: [FTPSERVER] Ftplets never destroyed
I agree with Jiří that if some one chooses to use a custom Ftplet container, it is their responsibility to implement the appropriate methods (such as init and destroy). All we can do is call the destroy method when we think the server is going down. I don't see any reason why we need to keep track of what Ftplet container is in use and make decisions based on that. Regards, Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Mon, Dec 22, 2008 at 1:20 AM, Jiří Kuhn wrote: > In my opinion, if we call init(), we should call destroy(). It's clear and > logic behaviour. Client may provide an instance of the ftplet container and > the server calls methods defined by an interface, why to make a difference > if the instance is default one or not. The decision is on a client if the > destroy() method should be implemented or empty and the destruction of the > provided ftplet container is done somewhere else. > > The interface defines a contract, if the client breaks it, it will face the > consequences itself. > > At present, if you use everything default, your ftplets are never > destroyed(). This is wrong, I think. > > Jiří Kuhn. > > 2008/12/19 Niklas Gustavsson > >> On Fri, Dec 19, 2008 at 8:14 AM, Jiří Kuhn wrote: >> > destroy() method on ftplet container is never called. I gues that >> something >> > like >> > >> >serverContext.getFtpletContainer().destroy(); >> > >> > should be placed somewhere inside DefaultFtpServer.stop() method. >> Probably >> > right just before serverContext disposition to be, let's say, consistent >> > with init() method. I really wonder that none has noticed it yet. Or am I >> > missing something? >> >> I'm aware of this, but unsure how we best handle it. If the user has >> provided their own FtpletContainer (pretty unlikely but possible), I >> think the API client should destroy the container itself. However, in >> most cases, clients will simple add Ftplets to the server, in this >> case we should destroy on shutdown. So, should we keep track of the >> fact that we're using our default provided FtpletContainer and only >> destroy if that's true? >> >> /niklas >> >
Re: Re : MINA trunk - Failed test - NTLMTest.testType1Message
Vista returns the following for the "ver" command:
Microsoft Windows [Version 6.0.6001]
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Tue, Jan 27, 2009 at 6:00 PM, Edouard De Oliveira wrote:
> Your problem should be fixed in trunk ashish
> Thx for the report:)
>
> Can anyone running vista tell me what is exactly the response of
> the "ver" command on a vista command shell ? i wonder if it can
> be an issue too.
> Cordialement, Regards,
> -Edouard De Oliveira-
> http://tedorg.free.fr/en/main.php
>
>
>
> - Message d'origine
> De : Ashish
> À : dev@mina.apache.org
> Envoyé le : Mardi, 27 Janvier 2009, 10h06mn 14s
> Objet : Re: MINA trunk - Failed test - NTLMTest.testType1Message
>
> Environment Details
>
> java version "1.6.0_01"
> Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
> Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)
>
> OS - Win XP - SP3
>
>
> Got the problem. Problem is at Line 98 of
> org.apache.mina.proxy.handlers.http.ntlm.NTLMUtilities
>
> Since the out of command "ver" (Line 91) on my machine is "Microsoft
> Windows XP [Version 5.1.2600]"
>
> The code (Line 98) checks int pos = line.indexOf("version"); which
> fails and an exception is thrown and
> we get the default properties in exception block.
>
> Not sure of its a bug?
>
>
>
>
>
Re: [FtpServer] Suspend problem on OSX (was Re: [VOTE] Releasing FtpServer 1.0.0)
Does this help at all? http://lists.apple.com/archives/java-dev/2004/Feb/msg00331.html Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Mon, Mar 2, 2009 at 9:54 AM, Niklas Gustavsson wrote: > On Mon, Mar 2, 2009 at 1:17 PM, Emmanuel Lecharny > wrote: > > It may be just a matter of checking that the file can be deleted, then > check > > that the working directory still exists after having done the deletion. > If > > so, we are golden, otherwise, we have to recreate it, and send an error. > > Recreating it will cause several side effects (might change ownership, > permissions, inode). > > > In case the working directory is not empty, the deletion will fail > anyway. > > > > if we don't want to delete the working directory for some reason, we can > > rename it. > > Not convinced this is a very good anyways. As mentioned previously, > FTP server file systems are commonly monitored for file changes, > concurrent users might access the same directory and so on. I would > prefer that we either do or do not do an action, rather than doing it > in several steps. > > Let me whip up a prototype and we can test it on the available platforms. > > /niklas >
Re: [FtpServer] Suspend problem on OSX (was Re: [VOTE] Releasing FtpServer 1.0.0)
I would like to take this one step back as I think that the
getCanonicalFile() or getCanonicalPath() on an existing file should return
the exact file name with the correct case as it is stored on the file
system. At least that is what the JavaDoc says.
Can some one run this test program on OS X/HFS and post the results back?
Before running this, make sure there is no directory named "Foo" in your
working directory.
import java.io.File;
import java.io.IOException;
public class FileCaseTest {
public static void main(String[] args) throws IOException {
File dir = new File("Foo");
boolean created = dir.mkdir();
System.out.println("Created directory " + dir + ": " + created);
dir = new File("FOO");
System.out.println("Absolute Path: " + dir.getAbsoluteFile());
System.out.println("Canonical Path: " + dir.getCanonicalFile());
}
}
This is what I get on Windows:
Created directory Foo: true
Absolute Path: D:\linomasoftware\projects\test\FOO
Canonical Path: D:\linomasoftware\projects\test\Foo
On Linux:
Created directory Foo: true
Absolute Path: /home/inspiron/dev/eclipseworkspace/develop/FOO
Canonical Path: /home/inspiron/dev/eclipseworkspace/develop/FOO
The canonical path is still in all CAPS because there is no file with the
name FOO exists. I would be curious to see what results we get back with the
HFS file system in question.
Regards,
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Wed, Mar 4, 2009 at 4:13 PM, Niklas Gustavsson wrote:
> On Mon, Mar 2, 2009 at 4:54 PM, Niklas Gustavsson
> wrote:
> > Let me whip up a prototype and we can test it on the available platforms.
>
> Alright, here's a prototype that I would much appreciate if all of you
> would take the time to test. First of all, you need to set the
> FILE_SYSTEM_TYPE to the correct value (this is only used for
> verification in the tests). On case sensitive file systems (most of
> the *nix file systems), this should be set to
> FileSystemType.CaseSensitive. On NTFS it should be set to
> CaseInsensitiveMissingAsTrue, and on case-insensitive HFS to
> CaseInsensitiveMissingAsFalse. It would be very interesting to have
> this code tested on other file systems. If you do, please report the
> file system and the test results.
>
> /niklas
>
> package org.apache.ftpserver.filesystem.nativefs.impl;
>
> import java.io.File;
> import java.io.FilenameFilter;
> import java.io.IOException;
>
> import junit.framework.TestCase;
>
> public class FileEqualsTest extends TestCase {
>
>private enum FileSystemType {
>CaseSensitive,
>// non-existing files with different casing are equal
>// e.g. NTFS
>CaseInsensitiveMissingAsTrue,
>// non-existing files with different casing are non-equal
>// e.g. HFS
>CaseInsensitiveMissingAsFalse
>};
>
>private static final FileSystemType FILE_SYSTEM_TYPE =
> FileSystemType.CaseSensitive;
>
>private boolean isCaseSensitive() {
>return FILE_SYSTEM_TYPE == FileSystemType.CaseSensitive;
>}
>
>private boolean isCaseInsensitive() {
>return FILE_SYSTEM_TYPE != FileSystemType.CaseSensitive;
>}
>
>@Override
>protected void setUp() throws Exception {
>System.out.println("File system type: " + FILE_SYSTEM_TYPE);
>super.setUp();
>}
>
>public void testSimple() throws IOException {
>File f1 = new File("foo");
>assertTrue(f1.createNewFile());
>File f2 = new File("foo");
>
>assertTrue(equals(f1, f2));
>}
>
>public void testNonExistingButSimple() {
>File f1 = new File("foo");
>File f2 = new File("foo");
>
>assertTrue(equals(f1, f2));
>}
>
>public void testDifferentCase() throws IOException {
>File f1 = new File("foo");
>assertTrue(f1.createNewFile());
>File f2 = new File("FOO");
>
>// if this succeeds, we have two different files
>assertEquals(isCaseSensitive(), f2.createNewFile());
>
>assertEquals(isCaseInsensitive(), equals(f1, f2));
>}
>
>public void testDifferentCaseNonExisting() throws IOException {
>File f1 = new File("foo");
>File f2 = new File("FOO");
>
>assertEquals(FILE_SYSTEM_TYPE ==
> FileSystemType.CaseInsensitiveMissingAsTrue, equals(f1, f2));
>}
>
>public void testSameNameDifferentParent() throws IOException {
>File f1 = new File("foo");
>assertTrue(f1.createNewFile());
>File dir
Re: [FtpServer] Suspend problem on OSX (was Re: [VOTE] Releasing FtpServer 1.0.0)
That's what I was expecting. So, if the issue is about RMDIR on the current
working directory, we should be able to match up the canonical paths and if
they are same (the directory that was requested for deletion and the current
working directory), send an error back. Does that sound correct?
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Thu, Mar 5, 2009 at 3:38 PM, Emmanuel Lecharny wrote:
> Niklas Gustavsson wrote:
>
>> On Thu, Mar 5, 2009 at 8:55 PM, Emmanuel Lecharny
>> wrote:
>>
>>
>>> i'm pretty sure I tested it, and the getCanonicalPath() keeps the name
>>> which
>>> as been used on HSF+.
>>>
>>>
>>
>> Could you please clarify that? If a file exists with the name "foo",
>> and we call new File("FOO").getCanonicalPath(), what casing will it
>> return?
>>
>>
>
> new File("FOO").getCanonicalPath() --> foo if the foo file exists.
> new File("FOO").getCanonicalPath() --> FOO if the foo file does not exist.
>
> In other words, it returns the existing name, or the new name.
>
>
>>
>
> /niklas
>>
>>
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: Enhance the Ftplet.afterCommand to provide more information about the result of command execution
I debated about adding a new method called getPhysicalFileAsString() which returns a String along with the getPhysicalFile which returns an Object. But then, I thought, the PhysicalFile could do this in the toString method. Like the NativeFtpFile returns java.io.File which has the string representation of the file implemented in the toString(). It might still be a good idea to add the AsString method to the interface so generic Ftplets (Ftplets that are not dependent on a specific file system used by the server such as the one in the example below) can be guranteed to get some good value. The main reason why I added the getPhysicalFile is - An Ftplet implemented for audit logging purposes needs to know which file was downloaded, uploaded or renamed etc. Most often server administrators would like to see the real path instead of the virtual path (e.g. C:\ftpserver\user\psai\test.txt vs /test.txt) in the audit logs. If the FileSystem is not file based (e.g. database based), the FileSystem implementation could still return something like a document ID which uniquely identifies the file. The Ftplet can then log the physical file whether it is the path to the file or the document ID by calling FtpFile.getPhysicalFile().toString() or FtpFile.getPhysicalFileAsString(). Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Mon, Apr 6, 2009 at 12:32 PM, Niklas Gustavsson wrote: > 2009/4/6 David Latorre (JIRA) : > > Are you subscribed to the developers mailing list? So we can move the > discussion there. > > I'm pretty sure Sai is, so let's move. > > > I hadn't thought much about these changes myself but your work looks > pretty good. The only thing I don't quite get is why we would use > FTPFile.getPhysicalFile ... Since it returns an Object, the coder developing > the FTPLet should know which 'PhysicalFile' object (s)he is using. This > would mean in most situations that they know which FTPFile implementation > they're using and hence, they could use casting to their appropriate type. > And I guess it's possible to have an implementation of FTPFile that doesn't > use a "PhysicalFile" object ... So what's your use case for this addition? > I'm so tired i can't clearly think... > > I agree with David that the patch looks very good (I will review it a > bit more in detail later). I have previously argued against something > like getPhysicalFile, but I'm more and more leaning over to it being a > good idea. The reason for this is that we would encourage developers > to provide a standard way of getting the underlying object. But, the > javadocs should very clearly state that the method might return null, > for example if there is no reasonable object to return. > > > Another problem we have is that it is becoming quite difficult to develop > pluggable components (be it an UserManager ,a Command or a ftplet) with only > the API documentation. How would a user know which types of FTPReply he > should use if overwriting a command? - I don't have a solution for this at > all. It's just something we could think about. > > That is a very interesting comment. How about we attempt to provide a > reasonable simple factory? It would also fit well with the OSGi > support. > > > Agree we should add a bug report for getUniqueFile(), using > createTempFile would be simpler but it is probably better to generate an > unique filename and check for permission before creating the actual file > (so all these should be under a static lock) ; although of course checking > only parent directory permissions we are good to go right now. > > Please open a JIRA and let's fix this in both trunk and the 1.0.x branch. > > /niklas >
Re: [jira] Created: (DIRMINA-685) Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/mina/common/IoHandler
Perhaps you have an older version of Mina libraries that are picked up by the JVM which are no longer compatible with your code? Potential places too look into would include the "ext" folder under the JRE as well as the classpath environment variable. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Thu, Apr 9, 2009 at 9:03 AM, Synapsis Brasil (JIRA) wrote: > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/mina/common/IoHandler > > --- > > Key: DIRMINA-685 > URL: https://issues.apache.org/jira/browse/DIRMINA-685 > Project: MINA > Issue Type: Bug > Environment: Red Hat Enterprise Linux Server release 5 (Tikanga) > Linux x 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 > x86_64 GNU/Linux > >Reporter: Synapsis Brasil >Priority: Blocker > > > > We have to applications. They work well on a server with the following > kernel version: Linux CC 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:19 EDT > 2007 x86_64 x86_64 x86_64 GNU/Linux. > > But on a server with this kernel version: Linux x 2.6.18-8.el5 #1 SMP > Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux, occurs the > erros bellow: > > 1) Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/mina/common/IoHandler > > 2) Exception in thread "main" java.lang.NoClassDefFoundError: > br/com/v2telecom/axon/util/Config >at br.com.v2telecom.axon.switch3.main.Main.main(Main.java:32) >at br.com.v2telecom.axon.switch3.main.Main.main(Main.java:50) > > Can you help us? > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: Enhance the Ftplet.afterCommand to provide more information about the result of command execution
I worked over the weekend to add another type of reply for commands like MKD, RMD, DELE etc and updated these commands. I think I should be able to check these in for review/any tweaking. Can one of you tell me if I should commit all changes together or file by file with commit comments specific to each file? Regards, Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Tue, Apr 7, 2009 at 4:11 AM, Niklas Gustavsson wrote: > I think the patch looks good as a starting point, please feel free to > commit it to trunk now that you should have the powers :-) > > /niklas > > On Mon, Apr 6, 2009 at 8:00 PM, Sai Pullabhotla > wrote: > > I debated about adding a new method called getPhysicalFileAsString() > which > > returns a String along with the getPhysicalFile which returns an Object. > But > > then, I thought, the PhysicalFile could do this in the toString method. > Like > > the NativeFtpFile returns java.io.File which has the string > representation > > of the file implemented in the toString(). It might still be a good idea > to > > add the AsString method to the interface so generic Ftplets (Ftplets that > > are not dependent on a specific file system used by the server such as > the > > one in the example below) can be guranteed to get some good value. > > > > The main reason why I added the getPhysicalFile is - > > > > An Ftplet implemented for audit logging purposes needs to know which file > > was downloaded, uploaded or renamed etc. Most often server administrators > > would like to see the real path instead of the virtual path (e.g. > > C:\ftpserver\user\psai\test.txt vs /test.txt) in the audit logs. If the > > FileSystem is not file based (e.g. database based), the FileSystem > > implementation could still return something like a document ID which > > uniquely identifies the file. The Ftplet can then log the physical file > > whether it is the path to the file or the document ID by calling > > FtpFile.getPhysicalFile().toString() or > FtpFile.getPhysicalFileAsString(). > > > > Sai Pullabhotla > > Phone: (402) 408-5753 > > Fax: (402) 408-6861 > > www.jMethods.com > > > > > > > > On Mon, Apr 6, 2009 at 12:32 PM, Niklas Gustavsson >wrote: > > > >> 2009/4/6 David Latorre (JIRA) : > >> > Are you subscribed to the developers mailing list? So we can move the > >> discussion there. > >> > >> I'm pretty sure Sai is, so let's move. > >> > >> > I hadn't thought much about these changes myself but your work looks > >> pretty good. The only thing I don't quite get is why we would use > >> FTPFile.getPhysicalFile ... Since it returns an Object, the coder > developing > >> the FTPLet should know which 'PhysicalFile' object (s)he is using. This > >> would mean in most situations that they know which FTPFile > implementation > >> they're using and hence, they could use casting to their appropriate > type. > >> And I guess it's possible to have an implementation of FTPFile that > doesn't > >> use a "PhysicalFile" object ... So what's your use case for this > addition? > >> I'm so tired i can't clearly think... > >> > >> I agree with David that the patch looks very good (I will review it a > >> bit more in detail later). I have previously argued against something > >> like getPhysicalFile, but I'm more and more leaning over to it being a > >> good idea. The reason for this is that we would encourage developers > >> to provide a standard way of getting the underlying object. But, the > >> javadocs should very clearly state that the method might return null, > >> for example if there is no reasonable object to return. > >> > >> > Another problem we have is that it is becoming quite difficult to > develop > >> pluggable components (be it an UserManager ,a Command or a ftplet) with > only > >> the API documentation. How would a user know which types of FTPReply he > >> should use if overwriting a command? - I don't have a solution for this > at > >> all. It's just something we could think about. > >> > >> That is a very interesting comment. How about we attempt to provide a > >> reasonable simple factory? It would also fit well with the OSGi > >> support. > >> > >> > Agree we should add a bug report for getUniqueFile(), using > >> createTempFile would be simpler but it is probably better to generate > an > >> unique filename and check for permission before creating the actual file > >> (so all these should be under a static lock) ; although of course > checking > >> only parent directory permissions we are good to go right now. > >> > >> Please open a JIRA and let's fix this in both trunk and the 1.0.x > branch. > >> > >> /niklas > >> > > >
Re: Enhance the Ftplet.afterCommand to provide more information about the result of command execution
Okay, I just checked in all my changes to the trunk for review/test/further enhancements. Below are a few questions: 1. Do we want to always send a specific type of reply from a specific command? In other words, do we want a command (e.g. RETR) to send a generic FtpReply in some cases and DataTransferFtpReply in some cases? There is currently once place in the data transfer commands (STOR, RETR etc) where I'm sending a DefaultFtpReply. Perhaps we should change it to send DataTransferFtpReply? 2. What additional information can possibly be added to the new FtpReply interfaces? 3. Do we want to add a new method to the FtpFile interface that returns the physical path of the file as a String? I recommend that we do this, but would like to know what you guys think. Regards, Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Mon, Apr 13, 2009 at 1:33 PM, Niklas Gustavsson wrote: > On Mon, Apr 13, 2009 at 2:19 PM, Sai Pullabhotla > wrote: > > I worked over the weekend to add another type of reply for commands like > > MKD, RMD, DELE etc and updated these commands. I think I should be able > to > > check these in for review/any tweaking. Can one of you tell me if I > should > > commit all changes together or file by file with commit comments specific > to > > each file? > > Do all at a time. > > /niklas >
Re: Enhance the Ftplet.afterCommand to provide more information about the result of command execution
Sorry, I do not have JUnit setup yet to run the test cases. But I hope the errors you have seen are related to the ListFormatter test cases where the new method added to the FtpFile was not implemented. I added that method to the test classes and checked those in. I simply returned a string "/short" from the getPhysicalFile method in these classes. I was not sure what else to return. Hope that takes care of it. Regarding the addition of getPhysicalFileAsString method to the FtpFile, I think we should enforce the implementation classes to do it so generic Ftplets such as a logging Ftplet can be sure of getting a valid value instead of getting a pointer back in case an Ftplet returns a physical file with no toString() implemented. Regards, Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Mon, Apr 13, 2009 at 1:48 PM, Niklas Gustavsson wrote: > On Mon, Apr 13, 2009 at 8:38 PM, Sai Pullabhotla > wrote: > > Okay, I just checked in all my changes to the trunk for > review/test/further > > enhancements. > > Seems like the test broke, can you have a look at it? > > > Below are a few questions: > > > 1. Do we want to always send a specific type of reply from a specific > > command? In other words, do we want a command (e.g. RETR) to send a > generic > > FtpReply in some cases and DataTransferFtpReply in some cases? There is > > currently once place in the data transfer commands (STOR, RETR etc) where > > I'm sending a DefaultFtpReply. Perhaps we should change it to send > > DataTransferFtpReply? > > I don't care particulary if a command return different types of > replies. The user of the replies should always check the type before > using. > > > 3. Do we want to add a new method to the FtpFile interface that returns > the > > physical path of the file as a String? I recommend that we do this, but > > would like to know what you guys think. > > The use case for this would be for auditing purposes as you described > earlier? I would say that getPhysicalFile().toString() should suffice. > > /niklas >
Re: [jira] Created: (FTPSERVER-289) Implement locking mechanism for files.
I believe all operating systems handle the file locking on files to prevent concurrent writing. So, if more than one users/sessions try to write to the same file, who ever opens the file first for writing would win and the rest would fail. So not sure if we need to implement what you have mentioned. Thanks. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Mon, Apr 13, 2009 at 3:52 AM, David Latorre (JIRA) wrote: > Implement locking mechanism for files. > -- > > Key: FTPSERVER-289 > URL: https://issues.apache.org/jira/browse/FTPSERVER-289 > Project: FtpServer > Issue Type: New Feature > Components: Core >Affects Versions: 1.0.0 >Reporter: David Latorre > Fix For: WISHLIST > > > > In order to solve FTPSERVER-288 , this is, to prevent the possibility of > race conditions in STOU command ( it is possible that non-unique filenames > be generated with the current implementation) we would eventually need that > there was some file locking mechanism which might be a mechanism to keep > track of in-use files. > > > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: svn commit: r766111 - /mina/trunk/core/src/main/java/org/apache/mina/filter/logging/LoggingFilter.java
Can we deprecate the old method and add the new one to keep up the promise?
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Fri, Apr 17, 2009 at 2:04 PM, Niklas Gustavsson wrote:
> On Fri, Apr 17, 2009 at 8:24 PM, wrote:
> > -public LogLevel getExceptionCaughtLoglevel() {
> > +public LogLevel getExceptionCaughtLogLevel() {
>
> This breaks the API, something we promised not to do after M4. Are we
> still okay with this change?
>
> /niklas
>
Re: [VOTE] Releasing FtpServer 1.0.1
+1 Sai Pullabhotla www.jMethods.com On Wed, May 13, 2009 at 3:56 PM, Niklas Gustavsson wrote: > Hey, > > since 1.0.0 some issues has been reported in FtpServer. Now is > therefore a good time to get 1.0.1 out. > > You can find the binaries and Maven artifacts here: > http://people.apache.org/~ngn/ftpserver/1.0.1/<http://people.apache.org/%7Engn/ftpserver/1.0.1/> > > These files was built from the following code: > https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.1 > > The bugs fixed are: > https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12313619 > > Get those bugs squashed? > [ ]: +1, Release FtpServer 1.0.1 > [ ]: 0, Abstain > [ ]: -1, Don't release FtpServer 1.0.1 > > /niklas >
Re: [jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
>> when FtpServer receives a file in ASCII mode our current code replaces \r
for \r\n and ignores \n, but since it seems FileZilla
>> doesn't transform new lines to \r\n we will never find a \r and the new
line characters will be silently ignored.
Hmm... shouldn't it be just doing the following:
1. Replace \r\n with System.getProperty("line.separator");
2. Write everything else as is.
Sai Pullabhotla
www.jMethods.com
On Tue, May 26, 2009 at 2:34 AM, David Latorre (JIRA) wrote:
>
>[
> https://issues.apache.org/jira/browse/FTPSERVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712889#action_12712889]
>
> David Latorre commented on FTPSERVER-306:
> -
>
> Sending a file with \n separated lines in ASCII mode with FileZilla for
> windows will result in a file with no new lines:
>
> when FtpServer receives a file in ASCII mode our current code replaces \r
> for \r\n and ignores \n, but since it seems FileZilla doesn't transform new
> lines to \r\n we will never find a \r and the new line characters will be
> silently ignored.
>
> This is a bug in Filezilla (Might be because im sending "Unix" files from
> windows) but I doubt every other client is performing this transformation.
> So, when we find a \n we should check if last character was \r and otherwise
> insert the new line sequence.
>
>
>
>
>
>
> > some clients won't transform NEW LINE characters to \r\n when sending in
> ASCII mode so after sending a file the new lines will be gone.
> >
> -
> >
> > Key: FTPSERVER-306
> > URL: https://issues.apache.org/jira/browse/FTPSERVER-306
> > Project: FtpServer
> > Issue Type: Improvement
> >Reporter: David Latorre
> >
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Re: [jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect
Not sure why you think it will break the API, as I could not find anywhere the "idleTimeout" being documented as maximum idle time. Below is the Javadoc from the ListenerFactory: * Set the number of seconds during which no network activity * is allowed before a session is closed due to inactivity. * * @param idleTimeout The idle timeout in seconds So, to keep things simple, we should just mark it as a bug and make it the default timeout. Also, pre 1.0 releases worked fine with listener timeout set to a finite value and user timeout left at zero. so, I guess the issue is with 1.0/1.0.1. Sai Pullabhotla www.jMethods.com On Tue, May 26, 2009 at 1:00 PM, Niklas Gustavsson wrote: > On Tue, May 26, 2009 at 7:01 PM, Johannes Katelaan > wrote: > > I absolutely agree with you. The listener timeout should be a default > > timeout. > > Since this would break our API, it's not something we can do for the > 1.X series. So, if we want to introduce a default idle time, in > addition to the existing maximum idle time, it needs to be a new > configuration. > > /niklas >
Re: [jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
I agree with Dave Roberts - On STOR, tranform CRLFs to local EOL. On RETR, transform local EOL to CRLF. Absolutely no other changes. Sai Pullabhotla www.jMethods.com On Thu, May 28, 2009 at 4:50 AM, Dave Roberts < dave.robe...@saaconsultants.com> wrote: > David Latorre wrote: > > So unless someone has a strong reason to need uniform EOLs > > > > corresponding to the target system, then we might assume that the > > > > issue with different clients resulting in different files can be > > > > ignored, and transform only the canonical line ending. > > My understanding of the spec has always been that in ASCII mode, > both sides must convert between the local OS specific line endings > and the canonical CR/LF pairing. If the file isn't in the correct > format for the local OS, then the right results cannot be guaranteed. > > So I would agree that we should only transform to/from the canonical > line ending. >
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only supports listing files in working directory [patch provided]
I would like to say that the results you have indicated only come from FTP servers that actually run the UNIX's ls command when a NLST command is received. Other servers probably adhere to the RFC by just returning names. Here are a few tests I did with various FTP servers: Results from Netscape's anonymous FTP site did match up with what Dennis described. (ftp.netscape.com) Results from GlobalScape's anonymous FTP site always returned just names. ( ftp.globalscape.com) Results from an AS/400 FTP server (IBM's System i) always returned just names. (Private) Results from IPSwitch's WS_FTP server always returned just names. ( ftp.ipswitch.com) Results from Microsoft's anonymous web site running MS FTP service also retruns just names (ftp.microsoft.com) Hopefully this might help making a decision. Sai Pullabhotla www.jMethods.com On Mon, Jun 1, 2009 at 7:39 PM, Dennis Keller (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715317#action_12715317] > > Dennis Keller commented on FTPSERVER-287: > - > > Hi Niklas - I suppose my comment would be that regardless of the text of > the RFC, if you compare the Apache FTPServer response against that of other > FTP servers, you will see the difference (they return paths when the request > includes a path). > > I included an example in my initial posting. I suppose you could interpret > the spec literally, however I urge to you test the cases I've provided using > other ftp servers. I believe the intent of the RFC is to behave similarly to > a list command on a UNIX machine. If you include the path in a list command, > the response will include the target path. The RFC says "... return a stream > of names of files...", which does not exclude the path, if the file was > requested with a path. For example: > > If I execute "nlst file.txt", I expect a response of "file.txt" > If I execute "nlst directory/file.txt", I expect a response of > "directory/file.txt" > If I execute "nlst /directory/file.txt", I expect a response of > "/directory/file.txt" > If I execute "nlst ../parentdir/subdir/file.txt", I expect a response of > "../parentdir/subdir/file.txt" > > This is how other FTP servers work and this is how unix works. The RFC is > vague and open to interpretation, therefore we need to look to other > implementations to find the consensus implementation. As it stands now, we > are unable to use the apache ftp server (before the patch) because of the > significant implementation difference. > > Note that my patch may not be the best solution, however there is an > implementation issue now. So at the very least the test cases should be > included and the implementation constructed around them. I will provide more > examples if you require. > > > NLST: Implementation only supports listing files in working directory > [patch provided] > > > -- > > > > Key: FTPSERVER-287 > > URL: https://issues.apache.org/jira/browse/FTPSERVER-287 > > Project: FtpServer > > Issue Type: Bug > > Components: Core > >Affects Versions: 1.1 > > Environment: Fedora 10-64bit and RH 5.2-64bit, Java 1.6.0_12-64 > >Reporter: Dennis Keller > > Fix For: 1.0.2, 1.1 > > > > Attachments: nlst.patch > > > > > > The NLST formatter, as implemented on trunk is insufficient to handle any > request other than a file within in the current working directory. Some > examples: > > ftp> passive > > Passive mode on. > > ftp> nlist /directory/file.txt > > 227 Entering Passive Mode (127,0,0,1,179,241) > > 150 File status okay; about to open data connection. > > file.txt > > 226 Closing data connection. > > Other FTP servers return the following: > > ftp> passive > > Passive mode on. > > ftp> nlist /directory/file.txt > > 227 Entering Passive Mode (127,0,0,1,179,241) > > 150 File status okay; about to open data connection. > > /directory/file.txt > > 226 Closing data connection. > > Upon investigating, I found that the formatter will not handle absolute > file requests, parent directory request or non-absolute child directory > requests. It does not error, it just doesn't give useful output. > > I've modified the code to handle the cases that I could come up with, but > there may be other situations that need to be covered. I'm not an expert on > the FTP specification (but what I could find was not impressive), so there > many be additional cases that need to be covered. > > Please consider the attached patch, with accompanying test cases > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only supports listing files in working directory [patch provided]
In any case, what if we give an option for running a native command when NLST or LIST command is received. So, the user could configure the FTP server to execute the ls command and we redirect the output of the ls command back to the client. One of the advantages of allowing this for the LIST command is we can actually return more information about files and directories such as if an object is symbolic link, the owner etc. (of course applicable mainly to *NIX systems) which cannnot be retrived using Java. Something to think about. Sai Pullabhotla www.jMethods.com On Tue, Jun 2, 2009 at 1:51 AM, Niklas Gustavsson wrote: > On Tue, Jun 2, 2009 at 3:31 AM, Sai Pullabhotla > wrote: > > I would like to say that the results you have indicated only come from > FTP > > servers that actually run the UNIX's ls command when a NLST command is > > received. Other servers probably adhere to the RFC by just returning > names. > > One addition to this list, FileZilla works as described by Dennis. > > /niklas >
Possible enhancement to the UserManager in FTP server
Currently the UserManager interface has the authenticate method defined as follows: User authenticate(Authentication authentication) throws AuthenticationFailedException; I'm wondering if it would be of any benefit to change it to: User authenticate(Authentication authentication, FtpSession session) throws AuthenticationFailedException; The reason(s) behind this - I want to log a message when the login fails. The login could fail to due to a number of reasons - such as Account is disabled, password has expired and so on. Since I do not have the session information available from this interface, I'm not able to log all the information that I normally do - such as the session ID, remote address and so on. I know I can log this information from onLogin() method of an Ftplet, but then I would not have any information on why the login has actually failed. All I've is - 530 Authentication Failed reply. Another benefit would be if I want to implement my user manager based on user name and IP address. For example let User1 login if and only if he is connecting from IP address xxx.xxx.xxx.xxx. Not sure if any one does this kind of authentication, but in case if some one want to, this change should help. Let me know what you guys think. Regards, Sai Pullabhotla www.jMethods.com
Re: [jira] Commented: (FTPSERVER-315) Pass FtpSession information to the UserManager.authenticate method
Thanks, Niklas. I thought there was something like that, but overlooked. Sai Pullabhotla www.jMethods.com On Mon, Jun 29, 2009 at 7:25 AM, Niklas Gustavsson (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/FTPSERVER-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725150#action_12725150] > > Niklas Gustavsson commented on FTPSERVER-315: > - > > The client certificate chain is already available to the UserManager in the > UserMetadata class (calling > authentication.getUserMetadata().getCertificateChain()). > > > Pass FtpSession information to the UserManager.authenticate method > > -- > > > > Key: FTPSERVER-315 > > URL: https://issues.apache.org/jira/browse/FTPSERVER-315 > > Project: FtpServer > > Issue Type: Improvement > > Components: Core, Ftplets > >Reporter: Sai Pullabhotla > >Priority: Minor > > Fix For: 2.0.0 > > > > > > Currently the UserManager interface has the authenticate method defined > as follows: > > User authenticate(Authentication authentication) > > throws AuthenticationFailedException; > > I'm wondering if it would be of any benefit to change it to: > > User authenticate(Authentication authentication, FtpSession session) > > throws AuthenticationFailedException; > > The reason(s) behind this - > > I want to log a message when the login fails. The login could fail to due > to a number of reasons - such as Account is disabled, password has expired > and so on. Since I do not have the session information available from this > interface, I'm not able to log all the information that I normally do - such > as the session ID, remote address and so on. I know I can log this > information from onLogin() method of an Ftplet, but then I would not have > any information on why the login has actually failed. All I've is - 530 > Authentication Failed reply. > > Another benefit would be if I want to implement my user manager based on > user name and IP address. For example let User1 login if and only if he is > connecting from IP address xxx.xxx.xxx.xxx. Not sure if any one does this > kind of authentication, but in case if some one want to, this change should > help. > > More info about this feature request can be found in the thread - > http://www.mail-archive.com/dev@mina.apache.org/msg12942.html. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Unable to reply to a posted question
My reply to one of the questions on the forum is being rejected by the Apache mail server. Any one has any idea why? Below is the returned message: This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: dev@mina.apache.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 552 552 spam score (5.8) exceeded threshold (state 18). - Original message - MIME-Version: 1.0 Received: by 10.216.88.7 with SMTP id z7mr574449wee.19.1249053706797; Fri, 31 Jul 2009 08:21:46 -0700 (PDT) In-Reply-To: <4700784fc6e6214a8818f3524684f095084ca...@usilms11.ca.com> References: <4700784fc6e6214a8818f3524684f095084ca...@usilms11.ca.com> Date: Fri, 31 Jul 2009 10:21:46 -0500 Message-ID: <44ed9df20907310821j597eccbci3d5ff87d91a0a...@mail.gmail.com> Subject: Re: Ftplet Properties From: Sai Pullabhotla To: dev@mina.apache.org Content-Type: multipart/alternative; boundary=0016e6dab0597fc6a0047001fad1 --0016e6dab0597fc6a0047001fad1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I believe your ftplet, MyFtplet, needs to have a setFoo method which takes the appropriate argument. The setFoo is called when initilizing the Ftplet and you can do what ever you want to with that property. Sai Pullabhotla www.jMethods.com <http://www.jmethods.com/> - Message truncated - Sai Pullabhotla www.jMethods.com
Re: Unable to reply to a posted question
Thanks, let us see if this gets there without bouncing back! Sai Pullabhotla www.jMethods.com On Fri, Jul 31, 2009 at 2:18 PM, Niklas Gustavsson wrote: > On Fri, Jul 31, 2009 at 5:25 PM, Sai > Pullabhotla wrote: >> My reply to one of the questions on the forum is being rejected by the >> Apache mail server. Any one has any idea why? Below is the returned message: > > Try resending as a plain text mail, Apache mailing lists frown on HTML > emails :-) > > /niklas >
FTPS with passive mode is slow
I've been noticing that the passive data connections are taking quite some time when using SSL. I finally got some time to look into this and noticed the following while debugging through the code. This issue might have been introduced with the fix we put in for FTPSERVER-241. The code that wraps the plain socket into an SSL socket uses the following line: SSLSocket sslSocket = (SSLSocket) ssocketFactory .createSocket(serverSocket, serverSocket.getInetAddress().getHostName(), serverSocket.getPort(), true); Based on the JavaDocs, the InetAddress.getHostName() performs a reverse name look up, which was taking about 1.5 seconds on every system on our network. I'm not sure if this is an issue with the way our network is setup. Some one please let me know if this in fact an issue with our network. We are not seeing this lag when client and server are running on the same system. Things work too fast in this case, probably because the system knows very well about itself. Just to try it out, I changed the code to simply use the IP address rather than the host name, and I was able to get rid of the lag and things seem to be working much faster. Below is the change to the above line: SSLSocket sslSocket = (SSLSocket) ssocketFactory .createSocket(serverSocket, serverSocket.getInetAddress().getHostAddress(), serverSocket.getPort(), true); Could some one test the current code base with client and server running on different systems and tell me if they notice the lag when creating the passive data connection. If this can be reproduced on one of your environments, we should probably put the above fix. I don't think this suggested fix should cause any other issues, do you? Regards, Sai Pullabhotla www.jMethods.com
Re: FTPS with passive mode is slow
Okay, done! I also have another question around the same code...Should we be checking the remote address and make sure it matches with the IP address of the remote host on the control connection. If we do not do this check, it is possible for a hacker to connect to this port before the original client and may gain access to the data? I know it is not very easy to do this, but just in case. What do you think? Sai Pullabhotla www.jMethods.com On Tue, Aug 4, 2009 at 3:48 PM, Niklas Gustavsson wrote: > I believe this problem has been reported multiple times. Please open a > JIRA and apply the patch, it makes perfect sense. > > /niklas > > On Tue, Aug 4, 2009 at 10:02 PM, Sai > Pullabhotla wrote: >> I've been noticing that the passive data connections are taking quite >> some time when using SSL. I finally got some time to look into this >> and noticed the following while debugging through the code. This issue >> might have been introduced with the fix we put in for FTPSERVER-241. >> >> The code that wraps the plain socket into an SSL socket uses the >> following line: >> >> SSLSocket sslSocket = (SSLSocket) ssocketFactory >> .createSocket(serverSocket, >> serverSocket.getInetAddress().getHostName(), >> serverSocket.getPort(), true); >> >> Based on the JavaDocs, the InetAddress.getHostName() performs a >> reverse name look up, which was taking about 1.5 seconds on every >> system on our network. I'm not sure if this is an issue with the way >> our network is setup. Some one please let me know if this in fact an >> issue with our network. >> >> We are not seeing this lag when client and server are running on the >> same system. Things work too fast in this case, probably because the >> system knows very well about itself. >> >> Just to try it out, I changed the code to simply use the IP address >> rather than the host name, and I was able to get rid of the lag and >> things seem to be working much faster. Below is the change to the >> above line: >> >> SSLSocket sslSocket = (SSLSocket) ssocketFactory >> .createSocket(serverSocket, >> serverSocket.getInetAddress().getHostAddress(), >> serverSocket.getPort(), true); >> >> Could some one test the current code base with client and server >> running on different systems and tell me if they notice the lag when >> creating the passive data connection. If this can be reproduced on one >> of your environments, we should probably put the above fix. I don't >> think this suggested fix should cause any other issues, do you? >> >> Regards, >> >> Sai Pullabhotla >> www.jMethods.com >> >
Re: FTPS with passive mode is slow
I'm not sure, I think it should go to the main trunk as well. Sai Pullabhotla www.jMethods.com On Wed, Aug 5, 2009 at 9:31 AM, Niklas Gustavsson wrote: > On Wed, Aug 5, 2009 at 2:41 PM, Sai > Pullabhotla wrote: >> I also have another question around the same code...Should we be >> checking the remote address and make sure it matches with the IP >> address of the remote host on the control connection. If we do not do >> this check, it is possible for a hacker to connect to this port before >> the original client and may gain access to the data? I know it is not >> very easy to do this, but just in case. What do you think? > > I think this makes sense. We already do the logically same for active > connections. Probably only should apply this to the 1.1.X (trunk) > code, right? > > /niklas >
Re: FTPS with passive mode is slow
I'm also wondering if we could perform better with SSL, if we cache the SSLContext and SSLSocketFactory. Currently, every data connection creates the SSLContext (even though the context parameters are the same) and gets the SocketFacotry from the context. Instead, we should create the SSLContext and SSLSocketFactory once per each SslConfiguration and reuse it. Obviously, this reduces the unnecessary object creation and eliminates the unnecessary method calls and context initialization. I've made some changes locally and things seem to be working fine. If you think we should apply this suggested change, I can post the patch for review. Basically, the changes we would need are: Add the following new method to the SslConfiguration interface - SSLSocketFactory getSocketFactory() throws GeneralSecurityException; Implement the above method method in the DefaultSslConfiguration. When constructing the DefaultSslConfiguration, create the SSLContext and an SSLSocketFactory and save them as members. Then when we need a SSLSocket, we simply call SSLConfiguration.getSocketFactory() which returns the pre-created socket factory. I know we may not notice much time difference with this change, but every little things add up, especially under high loads. Let me know what you think. Regards, Sai Pullabhotla www.jMethods.com On Wed, Aug 5, 2009 at 10:05 AM, Sai Pullabhotla wrote: > I'm not sure, I think it should go to the main trunk as well. > > Sai Pullabhotla > www.jMethods.com > > > > > On Wed, Aug 5, 2009 at 9:31 AM, Niklas Gustavsson wrote: >> On Wed, Aug 5, 2009 at 2:41 PM, Sai >> Pullabhotla wrote: >>> I also have another question around the same code...Should we be >>> checking the remote address and make sure it matches with the IP >>> address of the remote host on the control connection. If we do not do >>> this check, it is possible for a hacker to connect to this port before >>> the original client and may gain access to the data? I know it is not >>> very easy to do this, but just in case. What do you think? >> >> I think this makes sense. We already do the logically same for active >> connections. Probably only should apply this to the 1.1.X (trunk) >> code, right? >> >> /niklas >> >
Re: FTPS with passive mode is slow
I did notice anywhere from 20 to 50 milliseconds improvement for each data connection creation. The fix is checked in now to the trunk. Regards, Sai Pullabhotla www.jMethods.com On Wed, Aug 5, 2009 at 3:15 PM, Niklas Gustavsson wrote: > On Wed, Aug 5, 2009 at 10:01 PM, Sai > Pullabhotla wrote: > [snip] > >> I know we may not notice much time difference with this change, but >> every little things add up, especially under high loads. > > Did you see any performance improvements in your local copy? Anyways, > I think this makes sense, again for 1.1.X. > > /niklas >
Re: [jira] Created: (FTPSERVER-324) FTPServer should bind on the entire 127.0.0.0/8 range when loopback address is given
Can you explain the intended use of it? Also, have you tried setting up your listener with localAddress set to "loopback"? Sai Pullabhotla www.jMethods.com On Fri, Aug 14, 2009 at 6:02 AM, Gusti Benawi (JIRA) wrote: > FTPServer should bind on the entire 127.0.0.0/8 range when loopback address > is given > > > Key: FTPSERVER-324 > URL: https://issues.apache.org/jira/browse/FTPSERVER-324 > Project: FtpServer > Issue Type: Bug > Components: Server > Affects Versions: 1.0.2, 1.0.1, 1.0.0, 1.0.0-RC2, 1.0.0-RC1, 1.0.0-M4, > 1.0.0-M3, 1.0.0-M2, 1.0.0-M1, 1.0.3, 1.1.0, 2.0.0 > Reporter: Gusti Benawi > Priority: Minor > > > When a loopback address is given to the serverAddress, the server should bind > on all range of the loopback address. Instead of a single address. Or better > the server should bind on network interface instead of ip address. > > For example: given localhost or 127.0.0.1 to the serverAddress block, it > should be possible to connect to the server using any of the loopback > address, for example 127.0.1.1 > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: [jira] Commented: (FTPSERVER-323) Passive Data connections should check the remote IP address before starting the data transfer
Do you think this should be a configurable option? I tested with some other servers and they DO ALLOW steal the data connection from a different client. I believe it is to facilitate site to site transfers. Let me know. On Wed, Aug 12, 2009 at 2:56 PM, Niklas Gustavsson (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/FTPSERVER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742544#action_12742544 > ] > > Niklas Gustavsson commented on FTPSERVER-323: > - > > If this happens, and it should be a very uncommon event, I think we should > close the data connection. It is after all known by the hacker, so better > safe than sorry. > >> Passive Data connections should check the remote IP address before starting >> the data transfer >> - >> >> Key: FTPSERVER-323 >> URL: https://issues.apache.org/jira/browse/FTPSERVER-323 >> Project: FtpServer >> Issue Type: Bug >> Affects Versions: 1.0.2 >> Reporter: Sai Pullabhotla >> Fix For: 1.1.0 >> >> >> In the current version it is possible for a hacker to connect to any passive >> port that is currently waiting for a connection and read/write data off that >> connection. We should implement a check in place to make sure the IP address >> of the remote host is same as the one we are expecting, if not, close the >> data connection right way. After closing the data connection we can do one >> of the following: >> 1. Wait for incoming connection again so the original client can connect >> 2. just quit and send a reply back to the client that the data connection is >> closed. We need to figure out what reply we want to send in this case. >> What do you guys think we should do? > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: [jira] Created: (FTPSERVER-327) breaking RFC by replying 150 after establishing data connection
Even though you are connecting to the passive IP and Port before a
data transfer command is issued (STOR, RETR etc), the server in fact
does not accept the connection until a data transfer command is
issued. In other words, on the server side there is no Socket open
until you send the STOR command. This means that sending 150 reply is
correct. Do you agree?
Sai Pullabhotla
www.jMethods.com
On Tue, Aug 25, 2009 at 2:47 AM, Parijat Bansal (JIRA) wrote:
> breaking RFC by replying 150 after establishing data connection
> ---
>
> Key: FTPSERVER-327
> URL: https://issues.apache.org/jira/browse/FTPSERVER-327
> Project: FtpServer
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.0.2
> Environment: RHEL3
> Reporter: Parijat Bansal
> Priority: Minor
>
>
> Hi,
>
> RFC 959 explains 125 and 150 (valid intermediate responses for STOR/RETR) as
> follows:
> 125 Data connection already open; transfer starting.
> 150 File status okay; about to open data connection.
> If the data connection is already estabilished and after it the server
> receives STOR/RETR then it should respond with 125. I connected in passive
> mode using my custom client to verify this. I first estabilished a data
> channel and after it only I sent STOR but still got 150 which is wrong.
>
> Following is part of my code :
> data = new Socket(pasv_ip, pasv_port);
> data_os = data.getOutputStream();
> data_is = data.getInputStream();
> control_os.print("STOR " + "file.txt" + "\r\n");
> System.out.print("---> STOR " + "file.txt" + "\n");
> control_os.flush();
> System.out.println(control_is.readLine());
>
> However if I tried sending STOR before establishing data channel then also I
> received 150 which seems ok as per RFC.
>
> Regards,
> Parijat Bansal
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Reply to FEAT command in FTPServer
Current version of the FTP Server sends the following reply to FEAT command: 211-Extensions supported SIZE MDTM REST STREAM LANG en;zh-tw;ja;is MLST Size;Modify;Type;Perm AUTH SSL AUTH TLS MODE Z UTF8 TVFS MD5 MMD5 MFMT 211 End When I issue the TVFS command, I get the following reply: 502 Command TVFS not implemented. Same happens with UTF8 command. Should n't the reply to FEAT command be adjusted to remove the unimplemented commands? Thanks. Sai Pullabhotla www.jMethods.com
Re: Reply to FEAT command in FTPServer
Thanks Niklas. I will take a closer look at these documents. Sai Pullabhotla www.jMethods.com On Sat, Sep 26, 2009 at 3:39 PM, Niklas Gustavsson wrote: > On Fri, Sep 25, 2009 at 3:51 PM, Sai Pullabhotla > wrote: >> When I issue the TVFS command, I get the following reply: > > TVFS is an indication that we support the Trivial Virtual File System, > it is not a command. More info here: > http://tools.ietf.org/html/draft-ietf-ftpext-mlst-16#page-17 > >> Same happens with UTF8 command. > > UTF8 is sent as OPTS UTF8 (which is default for us so we do nothing > besides return a success). > > /niklas >
Re: [Vote] Releasing FtpServer 1.0.3
For FTPSERVER-330, I noticed that you also changed the times returned by the traditional LIST command. The LIST command now returns the dates in UTC. I was wondering if we should really do this as most/all FTP servers return the local date and time for the LIST command. Most FTP clients are now showing times differently than what they used to show, which may break things when people upgrade to 1.0.3. Sai Pullabhotla www.jMethods.com On Sun, Sep 27, 2009 at 1:48 PM, Niklas Gustavsson wrote: > Hey, > > Another set of bugs wants to be crushed, let's get FtpServer 1.0.3 released. > > You can find the binaries and Maven artifacts here: > http://people.apache.org/~ngn/ftpserver/1.0.3/ > > These files was built from the following code: > https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.3 > > The bugs fixed are: > https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12314039 > > [ ]: +1, Release FtpServer 1.0.3 > [ ]: 0, Abstain > [ ]: -1, Don't release FtpServer 1.0.3 > > /niklas >
Re: [Vote] Releasing FtpServer 1.0.3
The LIST command in RFC959 is a big mess with no standards defined. It is unfortunate, but I think it is important that the new versions of the server should not break existing applications if they are relying on the dates to get files. Since this change is definitely going to break it, I would prefer to switch it back to the way it was. FYI, Some FTP clients offer a setting to specify the server's timezone to workaround this issue. Sai Pullabhotla www.jMethods.com On Mon, Sep 28, 2009 at 7:37 AM, Niklas Gustavsson wrote: > On Mon, Sep 28, 2009 at 2:20 PM, Sai Pullabhotla > wrote: >> For FTPSERVER-330, I noticed that you also changed the times returned >> by the traditional LIST command. The LIST command now returns the >> dates in UTC. I was wondering if we should really do this as most/all >> FTP servers return the local date and time for the LIST command. > > Right, I checked the RFC and noted that it does not seem to say > anything about what time zone to use. So, I thought we should be > consistent in what we return. However, I do not have a strong opinion > on this matter. Could we confirm what other FTP servers do, do they > return different time zones for LIST and MLST? I just checked a few > servers and the only one that supported MLST returned different > results (since I know its local time zone I also confirmed that LIST > returned in the local time zone and MLST in UTC). > >> Most >> FTP clients are now showing times differently than what they used to >> show, which may break things when people upgrade to 1.0.3. > > Right, however it does not seem like we nor the RFC has made any > commitments as to what time zone to return. So, to me I would rather > see us conform to how the majority of other FTP server behave. Of > course, these might not be contradictory :-) > > /niklas >
Re: [Vote] Releasing FtpServer 1.0.3 - take 2
+1, Release FtpServer 1.0.3, let's go for it! Sai Pullabhotla www.jMethods.com On Tue, Sep 29, 2009 at 3:36 PM, Niklas Gustavsson wrote: > Hey, > > After rolling back the change that would have made the LIST and STAT > commands break backwards compatibility, here's a new build. > > You can find the binaries and Maven artifacts here: > http://people.apache.org/~ngn/ftpserver/1.0.3/ > > These files was built from the following code (recreated from the 1.0.x > branch): > https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.3 > > The bugs fixed are: > https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12314039 > > [ ]: +1, Release FtpServer 1.0.3 > [ ]: 0, Abstain > [ ]: -1, Don't release FtpServer 1.0.3 > > /niklas >
Re: [jira] Commented: (FTPSERVER-334) Read Timed Out Prior to Idle Timeout
I tried to reproduce the issue, but could not. I will keep looking into it some more. It might help if you setup your logging (in DEBUG mode) to include dates and times in a readable format and send the log when it timesout again so we can look at the sequence of commands, replies and the timestamps. That may give us some clues. Sai Pullabhotla www.jMethods.com On Thu, Oct 1, 2009 at 4:45 PM, Nick Padgett (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/FTPSERVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761355#action_12761355 > ] > > Nick Padgett commented on FTPSERVER-334: > > > Say I have a file that takes 300 seconds to upload on a passive connection. > If I set the ListenerFactory's idleTimeout higher than 300 seconds, say 400 > seconds, then I do NOT receive this error. If I set the ListenerFacotry's > idleTimeout lower than 300 seconds, say 200 seconds, then I do receive this > error. If the client wasn't correctly terminating the socket, then shouldn't > I receive this error is both situations? > >> Read Timed Out Prior to Idle Timeout >> >> >> Key: FTPSERVER-334 >> URL: https://issues.apache.org/jira/browse/FTPSERVER-334 >> Project: FtpServer >> Issue Type: Bug >> Affects Versions: 1.0.2 >> Reporter: Nick Padgett >> >> I receive a read timeout when I attempt to passively ftp a file that is >> longer than the idle timeout. The file makes it to the server in its >> entirety and then throws a read timeout. The input and output sockets need >> to be kept in sync. I.e. the input socket shouldn't timeout if the output >> socket was used within the idle timeout. Similarly, the output socket >> shouldn't timeout if the input socket was used withing the idle timeout. >> >> 1304157934 [pool-2-thread-455] INFO >> org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: USER glattig >> 1304158004 [pool-2-thread-455] INFO >> org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: PASS * >> 1304158005 [pool-2-thread-455] INFO org.apache.ftpserver.command.impl.PASS >> - Login success - glattig >> 1304158044 [pool-2-thread-455] INFO >> org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: OPTS utf8 on >> 1304158083 [pool-2-thread-455] INFO >> org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: PWD >> 1304158122 [pool-2-thread-455] INFO >> org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: CWD >> /1037/2009/09/14/ >> 1304158163 [pool-2-thread-455] INFO >> org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: TYPE I >> 1304158202 [pool-2-thread-455] INFO >> org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: PASV >> 1304158281 [pool-2-thread-455] INFO >> org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: STOR >> 6928_uUKgWHvc_event.wmv >> 1306180855 [pool-2-thread-455] WARN >> org.apache.ftpserver.impl.IODataConnection - Exception during data >> transfer, closing data connection socket >> java.net.SocketTimeoutException: Read timed out >> at java.net.SocketInputStream.socketRead0(Native Method) >> at java.net.SocketInputStream.read(SocketInputStream.java:129) >> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) >> at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) >> at java.io.BufferedInputStream.read(BufferedInputStream.java:317) >> at java.io.FilterInputStream.read(FilterInputStream.java:90) >> at >> org.apache.ftpserver.impl.IODataConnection.transfer(IODataConnection.java:243) >> at >> org.apache.ftpserver.impl.IODataConnection.transferFromClient(IODataConnection.java:136) >> at org.apache.ftpserver.command.impl.STOR.execute(STOR.java:146) >> at >> org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(DefaultFtpHandler.java:210) >> at >> org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(FtpHandlerAdapter.java:61) >> at >> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:721) >> at >> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:433) >> at >> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47) &
Re: Two questions on Apache Mina FTPServer
I think #1 is kind of available. The data connection handling is defined by the interface ServerDataConnectionFactory. The current version ships the default implementation in IODataConnectionFactory. It appears that you can substitute your own implemenation of ServerDataConnectionFactory by setting the ATTRIBUTE_DATA_CONNECTION in the FtpSession. So, as soon as a client logs in, you can use an Ftplet to update the FtpSession and tell it to use your own version of data connection factory. I think #2 is in works or at least in the wish list for 2.0. Some one, please correct me if I'm wrong. Hope this helps. Sai Pullabhotla www.jMethods.com On Mon, Oct 12, 2009 at 7:08 AM, Jon Folland, Nativ Ltd wrote: > Hi, > > 1. Is there any reason why the FTPServer project does not support Socket and > ServerSocket Factories in the DataConnection classes? The reason I ask is we > would like to specify a different concrete implementation of the Java Socket > and ServerSocket classes without changing the code base. I notice this is > supported in the FTPClient class in the Apache commons net package and it's > very useful from the FTP client perspective. Is there any chance of an update > on the code? > > 2. Is there any reason why the DataConnection classes don't use nio server > socket channels for better scaling on the sever-side to support large volumes > of concurrent file transfers? > > Many thanks, > > Jon. >
Looking for ideas on building a DMZ Gateway
Dear Fellow Developers, I thought this developers group can provide me with some ideas on building a DMZ Gateway. Basically, our company has developed a MFT (Managed File Transfer) product, which has an FTP/S, SFTP and HTTPS services for letting trading partners get/put files. Lately we have been getting requests from our customers and prospects that they do not want to store any data or credentials in the DMZ. In other words, they want all these services running in the internal network. However, when a trading partner wants to exchange file(s), they will be given an external address which will be routed to a system in the DMZ. The system in the DMZ need not know how to validate the credentials or need to store any data (files). No connections should be made from the system in DMZ to the system(s) in the internal network. However, systems in the internal network can initiate a connection to a system in the DMZ. The system in the DMZ should basically act as a Proxy for various protocols where as the systems in the internal network do the actual work. At this point I'm looking for various techniques to implement this kind of a system. I appreciate any help you guys could offer. Regards, Sai Pullabhotla
Re: Looking for ideas on building a DMZ Gateway
Ashish, Thanks for the reply. In fact most of the requests come from external network over the Internet. The idea is if a hacker makes it into the DMZ, he should not be able to open any connections to the internal network. Therefore, the firewall sitting between the DMZ and internal network is configured to block all incoming connections to the internal network, but allows connections to the DMZ from the internal network. As said before, systems in the DMZ will not contain any data of any sort, so there is not much for the hacker out there. Here is what I'm thinking... The Services (FTP/S, SFTP, HTTP/S) in the internal network need to know their DMZ gateways/proxies. During startup of these services, they initiate a connection or a few connections to the DMZ Gateway. These connections can later be used for bi-directional communication between the server in the DMZ and the actual Service sitting in the internal network. When a connection from external client comes in, it is routed to the system in the DMZ. At this point, the DMZ already has pre-established connection(s) so it can send some messages to the internal network such as a new client just connected. Based on the message the DMZ sends, the internal network may open one or more connections. As far as Proxying goes, it is probably going to be a lot easier for HTTP/SFTP, but for FTP/FTPS, the data connection handling could become tricker. In order to handle the data connection in FTP, this Gateway must also filter the packets sent/received. Is that correct? Hope this all makes sense. I've read somewhere on the Internet that this kind of thing can be accomplished with reverse-proxying. Do you guys have any idea on what it means and how it can be implemented. I appreciate any other ideas that you may come up with. Regards, Sai Pullabhotla On Wed, Dec 16, 2009 at 10:03 PM, Ashish wrote: > On Wed, Dec 16, 2009 at 7:48 PM, Sai Pullabhotla > wrote: >> Dear Fellow Developers, >> >> I thought this developers group can provide me with some ideas on >> building a DMZ Gateway. Basically, our company has developed a MFT >> (Managed File Transfer) product, which has an FTP/S, SFTP and HTTPS >> services for letting trading partners get/put files. Lately we have >> been getting requests from our customers and prospects that they do >> not want to store any data or credentials in the DMZ. In other words, >> they want all these services running in the internal network. However, >> when a trading partner wants to exchange file(s), they will be given >> an external address which will be routed to a system in the DMZ. The >> system in the DMZ need not know how to validate the credentials or >> need to store any data (files). No connections should be made from the >> system in DMZ to the system(s) in the internal network. However, > > If this can't happen, how would you handle the request coming from > external network? > or it would always be initiated from internal network? > >> systems in the internal network can initiate a connection to a system >> in the DMZ. The system in the DMZ should basically act as a Proxy for >> various protocols where as the systems in the internal network do the >> actual work. At this point I'm looking for various techniques to >> implement this kind of a system. I appreciate any help you guys could >> offer. > > Won't our proxy example be a good place to start ? > >> Regards, >> Sai Pullabhotla >> > > > > -- > thanks > ashish > > Blog: http://www.ashishpaliwal.com/blog > My Photo Galleries: http://www.pbase.com/ashishpaliwal >
Re: Looking for ideas on building a DMZ Gateway
David, Thanks for your comments. Even I'm not an expert in this area by any means, and am still trying to figure things out. Some of the MFT vendors have already implemented this feature. Not sure how they exactly do it. The basic idea remains same, where the actual service in the internal network initiates one or a few connections to the system in the DMZ (let us call it Proxy for now). These connections stay alive as long as the services in the internal network are alive. These connections possibly could use a proprietary protocol to transmit proprietary commands such as a new connection came from IP x.x.x.x. When this message is sent from the Proxy to the internal system, it could possibly create a new connection to the proxy and mark it as the connection for client x.x.x.x. Any subsequent commands such as LOGIN, DOWNLOAD etc. received by client x.x.x.x would be proxied to the internal server on the pre-established connection for the very same client. Responses from the internal server are proxied back to the original client with or without any modifications. An example where a response modification is necessary is when a data connection need to be established for the FTP service (PASV or PORT commands). Unfortunately, having a dedicated connection for each client as explained above may not scale well. I'm thinking out loud here :). Any other comments/ideas are welcome. Regards, Sai Pullabhotla On Sun, Dec 20, 2009 at 3:52 PM, David Latorre wrote: > Hello Sai, > > I'm no expert here so i cannot give you advice on your solution but > ... are you sure you need all of this? I'm thinking it should be > possible to meet your security needs in an simpler way. Let's say, > application-based firewalls on the dmz machines? (so only the allowed > applications can't connect to the network) A more secure way to do > this, I guess, could be running the services in VMware, VirtuaBox or > any other virtualization software. > > Another option could be some kind of VLAN with security ... > > Anyway , your solution might be completely right depending on your > circumstances. It's my understanding that you want a proxy server > routing e,g. all the incoming FTPS requests to the actual service > inside your private network - this is very easy to implement with MINA > if you don't have this 'no new connections from the DMZ' > restriction(actually I did), but even if you used any kind of > notification system to alert the other end that a new connection > should be created I think this might be troublesome ; how do we change > FTPServer to indicate that we should create the connection to the > 'client' (or proxy) and not the other way? And is it worthy? > > If you didn't need such a general solution, I guess a JMS server or > similar solutions ( I wonder if it's possible to do something like > this with XMPP) could work. You would send messages to a local queue > (or local endpoint of any kind) that would be read by the machines in > the internal network. > > > > > > > > > > 2009/12/18 Ashish : >>> >>> In fact most of the requests come from external network over the Internet. >>> >>> The idea is if a hacker makes it into the DMZ, he should not be able >>> to open any connections to the internal network. Therefore, the >>> firewall sitting between the DMZ and internal network is configured to >>> block all incoming connections to the internal network, but allows >>> connections to the DMZ from the internal network. As said before, >>> systems in the DMZ will not contain any data of any sort, so there is >>> not much for the hacker out there. >> >> Security is very important, but it seems like a situation I want to >> host a Web Server, but nobody from >> outside can open a connection :-( >> There are ways to address security concerns. >> >>> Here is what I'm thinking... >>> >>> The Services (FTP/S, SFTP, HTTP/S) in the internal network need to >>> know their DMZ gateways/proxies. >>> During startup of these services, they initiate a connection or a few >>> connections to the DMZ Gateway. These connections can later be used >>> for bi-directional communication between the server in the DMZ and the >>> actual Service sitting in the internal network. >>> When a connection from external client comes in, it is routed to the >>> system in the DMZ. At this point, the DMZ already has pre-established >>> connection(s) so it can send some messages to the internal network >>> such as a new client just connected. Based on the message the DMZ >>> sends, the internal network may open one or more connecti
Re: [OT] Joined Terracotta
Congratulations and all the best! Regards, Sai Pullabhotla On Wed, Jan 6, 2010 at 6:30 AM, Ashish wrote: > Folks, > > Have joined Terracotta on 4th Jan, as Solution Architect. > Hopefully my move shall help me in increasing my contribution towards MINA :-) > > Wanted to extend thanks to Chris, whose solution around TC and MINA, > was the driving force around my exploring this framework and finally > getting hired :-) > > Will be slightly less active till the time I settle in my new role. > > -- > thanks > ashish >
FTP Server - MD5 and MMD5 command replies when a file name or path contains spaces
It appears that we may have an issue with the replies we send for MD5 and MMD5 commands when the file name or path has one or more white spaces. According to the RFC posted on the FtpServer web site (http://mina.apache.org/ftpserver/draft-twine-ftpmd5-00.html), I think the reply should enclose the file name/path in double quotes if there are any white spaces. The current code does the following: MD5 How Email Templates work.docx 251 How Email Templates work.docx 95B88906981FD7E2145AF50CE97A3291 I wonder if the file name in the 251 reply should be enclosed in double quotes. This is based on the examples in the RFC. The RFC does not explicitly say anything about double quotes. What do you guys think? Regards, Sai Pullabhotla
Re: FTP Server - MD5 and MMD5 command replies when a file name or path contains spaces
Sure, not a problem. Is it okay if I check it into trunk? Would you be able to merge it into appropriate branches? Or would you rather prefer patch attached to the JIRA issue? Regards, Sai Pullabhotla On Thu, Jan 21, 2010 at 2:53 AM, Niklas Gustavsson wrote: > On Wed, Jan 20, 2010 at 4:16 PM, Sai Pullabhotla > wrote: >> I wonder if the file name in the 251 reply should be enclosed in >> double quotes. This is based on the examples in the RFC. The RFC does >> not explicitly say anything about double quotes. > > I agree. Could you open a JIRA for this? And feel free to fix it for > 1.0.x and 1.1.x if you got the time :-) > > /niklas >
Re: FTP Server - MD5 and MMD5 command replies when a file name or path contains spaces
I will give it a shot. I always used the Merge option in Eclipse. But, I'm a little hesitant to do it on someone else's repository. I will give it a shot anyway. I'm sure you can fix it in case if I screw something up :). Regards, Sai Pullabhotla On Thu, Jan 21, 2010 at 8:15 AM, Niklas Gustavsson wrote: > On Thu, Jan 21, 2010 at 3:02 PM, Sai Pullabhotla > wrote: >> Sure, not a problem. Is it okay if I check it into trunk? Would you be >> able to merge it into appropriate branches? Or would you rather prefer >> patch attached to the JIRA issue? > > Give it a try to get it into both branches. Here's how I do it: > * Develop the solution in trunk > * Extract a patch (Team -> Create patch if you use Eclipse) > * Review this so I only get what I really want > * Apply patch in 1.0.x branch > * Test and verify > * Commit to both branches > > /niklas >
Re: [jira] Commented: (FTPSERVER-346) loadStore method in SslConfigurationFactory should be protected to allow overriding
Looking at the code, and the loadStore method, it appears that this method should actually have been a static method, instead of an instance method. It is just a utility method to load either of the key stores - trustStore and keyStore. So, I'm not sure if we want to make it protected. We could make it a public static method in the same class or move the method to another utility class if we have one. If you create a temporary key/certificate every time the server is started, your clients would see a new certificate and may not work with the server unless they explicitly trust the certificate every time (or the client blindly trusts any certificate). Not sure if this is going to be an issue in your case. The other option could be to create a temporary file that contains the keys, then feed the file to the FTP server, and start the FTP server. Regards, Sai Pullabhotla On Wed, Jan 27, 2010 at 11:26 AM, Cath Gibbons (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/FTPSERVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805580#action_12805580 > ] > > Cath Gibbons commented on FTPSERVER-346: > > > Hello Niklas, > > And thank you for the prompt response :) > > The embedded FTP server I have implemented is only used temporarily, during a > short session within our application, and because of our packaging, we cannot > create a keystore file that would have to be moved during installation, and > thus rendered useless. > > For our usage, I set the implicit Ssl to false, so the client needs to > explicitly request to use Ssl. > When creating the Ssl configuration, there is no keystore already created. > I went around the fact that loadStore is declared private by having to copy > the createSslConfiguration method in SslConfigurationFactory class. > Is there a particular reason why loadStore cannot be declared protected? > > Thanks again for your awesome work, Niklas! > > Cath > > > > > > > >> loadStore method in SslConfigurationFactory should be protected to allow >> overriding >> --- >> >> Key: FTPSERVER-346 >> URL: https://issues.apache.org/jira/browse/FTPSERVER-346 >> Project: FtpServer >> Issue Type: Improvement >> Components: Server >> Affects Versions: 1.0.3 >> Environment: Windows XP >> Reporter: Cath Gibbons >> Priority: Minor >> Original Estimate: 0.03h >> Remaining Estimate: 0.03h >> >> The loadStore method in the SslConfigurationFactory class only deals with >> the case when the Keystore file actually exists at runtime. >> I am using the Apache FTP Server 1.0.3 on Windows XP to run an embedded >> server that does not have an existing Keystore file at runtime. Rather, it >> generates a temporary Keystore file using the Keystore load method with a >> null argument as InputStream. >> Since I could not override just the loadStore method that is declared >> "private", I had to copy the entire createSslConfiguration method in order >> to call my own loadStore. >> Why not make the loadStore protected to allow for it to be overriden? >> Thanks! > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: FTP Server - MD5 and MMD5 command replies when a file name or path contains spaces
Well, I guess I kind of screwed it up by not updating the test case. I did see some emails from Hudson that the builds have failed. I checked in the fix for the test cases. Hope it is all good now. Regards, Sai Pullabhotla On Thu, Jan 21, 2010 at 8:45 AM, Niklas Gustavsson wrote: > On Thu, Jan 21, 2010 at 3:36 PM, Sai Pullabhotla > wrote: >> I'm sure you can fix it in case if I screw >> something up :). > > I don't think you will, but sure :-) > > /niklas >
Re: [VOTE] Releasing FtpServer 1.0.4
I'm reviewing the changes in this release, and have a couple of concerns on the fix for FTPSERVER-347. 1. I think the RFC says to indent only if intermediate lines begin with 3 digits. Below is the excerpt from the RFC: "If an intermediary line begins with a 3-digit number, the Server must pad the front to avoid confusion." The fix pads all lines that starts with a digit. Not sure if it is a big deal. 2. The fix uses Character.isDigit() to check if the first character in any line is a digit. The isDigit method returns true for several other characters other than the Latin 0 through 9. We should probably just compare the decimal value of the character like ch >= 48 and ch <= 57? 3. The fix applies padding to the first line as well as the last line if they begin with a digit. Instead, it should pad intermediate lines only. Again, this is not a big deal. Regards, Sai Pullabhotla On Sun, Mar 7, 2010 at 7:48 AM, Niklas Gustavsson wrote: > Hey, > > Our alert users has reported yet some more bugs and we have fixed > them. Time for another release. > > You can find the distributions and Maven artifacts here: > http://people.apache.org/~ngn/ftpserver/1.0.4/ > > These files was built from the following code: > https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.4 > > Changelog: > https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12314283 > > [ ]: +1, Release FtpServer 1.0.4 > [ ]: 0, Abstain > [ ]: -1, Don't release FtpServer 1.0.4 > > /niklas >
Re: [jira] Commented: (FTPSERVER-349) WhiteList
Why not have asterisk(s) represent allow all? Regards, Sai Pullabhotla On Mon, Mar 8, 2010 at 4:40 AM, David Latorre (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/FTPSERVER-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842621#action_12842621 > ] > > David Latorre commented on FTPSERVER-349: > - > > Hello Devnull, > > When i first revised your patch I noticed this problem. I considered some > possibilities you haven't mentioned: > -1. In the method that adds the subnets/ips to the WhiteListFilter ( > updateWhitelistFilter(), right?) we can remove the filter from the chain if > we have an empty subnet list. > > This would work but I'm concerned that ftpserver users may want to use > WhiteListFilter when it is not in the chain. > > -2. Explictly check for the address 0.0.0.0/0 and consider it to mean "all > addresses allowed". > > > If we move the WhiteListFilter to MINA-core, it might be worth discussing > there how to signal that "all addresses are allowed". > > > What do you think, Niklas? > > > > > > >> WhiteList >> - >> >> Key: FTPSERVER-349 >> URL: https://issues.apache.org/jira/browse/FTPSERVER-349 >> Project: FtpServer >> Issue Type: Improvement >> Components: Server >> Affects Versions: 1.0.3 >> Reporter: DevNull43 >> Priority: Trivial >> Fix For: 1.1.0 >> >> Attachments: WhiteList.txt >> >> >> WhiteList filer >> Restricting access to FTP based on a WhiteList >> BlackList -> Allow all, Deny some. >> WhiteList -> Deny all, Allow some. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: [VOTE] Release FtpServer 1.0.4 - take 2
+1 Let's go for it! Regards, Sai Pullabhotla On Sun, Mar 7, 2010 at 2:23 PM, Niklas Gustavsson wrote: > Hey, > > Alright, I've fixed the issues found by Sai, here's take 2 on this release > vote. > > You can find the distributions and Maven artifacts here: > http://people.apache.org/~ngn/ftpserver/1.0.4/ > > These files was built from the following code: > https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.4 > > Changelog: > https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12314283 > > [ ]: +1, Release FtpServer 1.0.4 > [ ]: 0, Abstain > [ ]: -1, Don't release FtpServer 1.0.4 > > /niklas >
Black/White List in FTP Server
I've been trying to implement white/black lists in FTP server and thought of running my findings/ideas with you guys. Currently, each listener can have a black list. There is NO white listing capability. I've been thinking, instead of having the black list IPs/Subnets, simply have an interface called IPFilter. Each listener can have at most one IPFilter. The IPFilter requires an implementation for a method named accept(), which tells if the client's connection should be accepted or rejected based on the IP address. This gives us the flexibility of having a black or white list which ever is preferred by the server administrator. By default, we can ship default implementation for IPFilter which can be a black or white filter. For example, in the spring configuration, instead of having a blacklist element, we would have a element as shown below: 192.168.1.200/32, 192.168.1.201/32 The type attribute in the ipFilter element tells us if it should be a white or black list. The value for this attribute could be "whitelist" or "blacklist" or something similar such as BLOCK/PASS. I could not think of any good usage scenarios where one might want to have both white and black lists for a given listener. So, one IP Filter per listener should be good enough, unless you guys think otherwise. The above should work for users who want to run the FTP server out-of-the-box. For people who want to override the default IP filter implementaton, could create a new class that implements the IPFilter interface and specify the class name(?) in the spring config or programmatically call ListenerFactory.setIPFilter(IPFilter) method. Let me know what do you guys think and we can decide on how best it should be implemented. I do have sometime this week to work on this if we finalize on something. Thanks & Regards, Sai Pullabhotla
Re: Black/White List in FTP Server
Does this mean you want to wait until Mina 3.0, or should we start working on the FTP Server right away and share relevant code with MINA? Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 1:13 AM, Niklas Gustavsson wrote: > On Mon, Mar 15, 2010 at 7:27 PM, Sai Pullabhotla > wrote: >> I've been trying to implement white/black lists in FTP server and >> thought of running my findings/ideas with you guys. > > +1 to all you say. I think we should aim to land this work in MINA 3.0. > > /niklas >
Re: Black/White List in FTP Server
Cool, I will see what I can do. I was also looking at other ways to implement this feature and looks like one should be able to make use of an Ftplet and capture the onConnect event to determine if the connection should be allowed or not. I did some quick tests and found the following: Plain FTP/Explicit SSL does not seem to have any visible issues. Check the client's IP in the Ftplet's onConnect and return DISCONNECT if the client connection should not be accepted. However, with FTPS (Implicit), the SSL negotiation is initiated prior to sending the onConnect event to the Ftplets. To be precise, the client does get the server's certificate before onConnect is called. I was wondering if this should be done differently so no data is exchanged (read/written) unless onConnect of all Ftplets are executed. What do you think? Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 7:18 AM, Niklas Gustavsson wrote: > On Tue, Mar 16, 2010 at 1:05 PM, Sai Pullabhotla > wrote: >> Does this mean you want to wait until Mina 3.0, or should we start >> working on the FTP Server right away and share relevant code with >> MINA? > > I think we can start right away and copy the code upstream until we > move FtpServer to MINA 3.0. > > /niklas >
Re: Black/White List in FTP Server
I would not disagree that the IP restrictions should be handled by the filters, but at the same time. I was just looking for other ways that can be used when the filters do not provide the functionality the user wants. I do See that MINA propagates two different events - 1. session opened 2. session created Currently, we call the Ftplet.onConnect from the sessionOpened method. May be we should add yet another method to the Ftplets to indicate a sessionCreated event, in case if some one wants to use it? Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 7:38 AM, Niklas Gustavsson wrote: > On Tue, Mar 16, 2010 at 1:29 PM, Sai Pullabhotla > wrote: >> However, with FTPS (Implicit), the SSL negotiation is initiated prior >> to sending the onConnect event to the Ftplets. To be precise, the >> client does get the server's certificate before onConnect is called. I >> was wondering if this should be done differently so no data is >> exchanged (read/written) unless onConnect of all Ftplets are executed. > > With "data" in this case, we're only talking about the SSL handshake, > right? I think onConnect should indicate that the socket (session) is > established. With SSL, the socket might be ended (e.g due to > certificate validation failing) during the handshake. So, I think the > current behavior is correct. Besides, I think IP restriction is better > handled in the filter chain, rather than in Ftplets which I think > should contain things more like "business logic" (if you excuse the > very broad use of that term :-). > > /niklas >
Re: Black/White List in FTP Server
Yes, you are correct, and I did read that note in the MINA documentation. Essentially, an IP filter should make use of Session Created to filter out unwanted clients. Filtering may take a while depending on how big the list is or how efficient the filtering algorithm is. If a filter can make use of this event, why not an Ftplet? I agree that Ftplet authors should know what they are doing when using this method, but do not see any harm in making this event available. Just throwing in my ideas for discussion/evaluation, not that I really want it to be included. :) Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 8:31 AM, Niklas Gustavsson wrote: > On Tue, Mar 16, 2010 at 2:24 PM, Sai Pullabhotla > wrote: >> Currently, we call the Ftplet.onConnect from the sessionOpened method. >> May be we should add yet another method to the Ftplets to indicate a >> sessionCreated event, in case if some one wants to use it? > > If I recall correctly, sessionCreated is called from the IO processor > thread and we would therefore shortcut our threading model if we > expose it to Ftplets (letting an Ftplet block the entire listener). My > understanding is that sessionCreated is useful if you really know what > you're doing and I'm not sure that should be required by Ftplet users > :-) > > /niklas >
Re: Black/White List in FTP Server
Attached is the alpha release ;) for the black/white lists for your review. This patch is created from the trunk. I briefly tested this as a stand-alone server using spring config as well as programmatically configuring the server with a custom IP Filter. I updated the spring config/parser to support old style blacklist element or the new ip-filter element. If both elements are used, it raises an error. Both elements use the new IP Filter. Keep in mind that I still may have to do some tweaking and cleanup, but thought I should get this out to you guys for review so we can tweak it as needed. I appreciate any feedback. Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 7:18 AM, Niklas Gustavsson wrote: > On Tue, Mar 16, 2010 at 1:05 PM, Sai Pullabhotla > wrote: >> Does this mean you want to wait until Mina 3.0, or should we start >> working on the FTP Server right away and share relevant code with >> MINA? > > I think we can start right away and copy the code upstream until we > move FtpServer to MINA 3.0. > > /niklas >
Re: Black/White List in FTP Server
Done. Regards, Sai Pullabhotla On Thu, Mar 18, 2010 at 1:32 PM, Niklas Gustavsson wrote: > On Thu, Mar 18, 2010 at 7:20 PM, Sai Pullabhotla > wrote: >> Attached is the alpha release ;) for the black/white lists for your >> review. > > Create a JIRA issue and attach it there. Mailing lists strip attachments :-) > > /niklas >
Converting an IP range to CIDR notation
Does any one have Java code for converting a given range of IP addresses to CIDR notation, like the one here http://ip2cidr.com/. Thanks. Regards, Sai Pullabhotla
Re: Converting an IP range to CIDR notation
Does not look like it. What I'm looking for is - given a from and to IP addresses, it needs to generate corresponding Subnets using the CIDR notation. So, for example, if the from address is 192.168.1.1 and the to address is 192.168.1.12, the subnets should be - 192.168.1.1/32 192.168.1.2/31 192.168.1.4/30 192.168.1.8/30 192.168.1.12/32 I downloaded the source code of Apache James too, and did not find anything that would do this. Regards, Sai Pullabhotla On Mon, Mar 22, 2010 at 12:10 PM, Rick Bullotta wrote: > Would this work for you? > > http://labs.karmasphere.org/dp/javadoc/com/karmasphere/dp/type/CIDR.html > > > -Original Message- > From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com] > Sent: Monday, March 22, 2010 10:16 AM > To: dev > Subject: Converting an IP range to CIDR notation > > Does any one have Java code for converting a given range of IP > addresses to CIDR notation, like the one here http://ip2cidr.com/. > > Thanks. > > Regards, > Sai Pullabhotla > >
Checking out Maven Projects with MyEclipse
Dear Fellow Developers, I'm having hard time checking out the Maven projects with MyEclipse and wondering how you guys are doing. When I try to "check out as Maven project" on the FTP Server, MyEclipse leaves me with a balnk project unattached to the SVN. This has been reported in MyEclipse forums and there is no good answer/fix. I've also tried checking out the project as a regular Java project and then tried to add Maven builder, but things just don't work right. Does any one of you use MyEclipse? If not, I'm sure several/all of you use the Free Eclipse edition, but what plugin do you use that works nicely with existing SVN/MVN projects? Thanks in advance for your help. Regards, Sai Pullabhotla
Re: [jira] Created: (FTPSERVER-361) Provide more information on command execution to Ftplets - especially file created in STOU
I think this should have been taken care of with the https://issues.apache.org/jira/browse/FTPSERVER-222. You might want to try building from the trunk and see if this works out better. Regards, Sai Pullabhotla On Mon, Mar 29, 2010 at 4:56 AM, Richard Evans (JIRA) wrote: > Provide more information on command execution to Ftplets - especially file > created in STOU > -- > > Key: FTPSERVER-361 > URL: https://issues.apache.org/jira/browse/FTPSERVER-361 > Project: FtpServer > Issue Type: Improvement > Components: Ftplets > Affects Versions: 1.0.4 > Reporter: Richard Evans > > > To monitor file uploads, I can configure an Ftplet and override onUploadEnd > and onUploadUniqueEnd in DefaultFtplet. However I cannot find a way to > determine the real file that was written in the upload. > > For a non-unique upload I can get the argument and resolve it against the > working directory in the file system view; but this seems unnecessarily > complex and does not for for unique uploads (STOU) because the random file > name is not available. > > Browsing the code I can see the file observer stuff, but these are non-public > APIs and there can be only one observer at a time whilst I can have many > independent Ftplets implementing the onUpload APIs. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java
I apologize for the mess up. However, I do want you to know that I tried all the possible things I could, but still was not able to figure out how Eclipse manages to screw it up. I did not format any existing sources. I even tried creating a brand new workspace, set the new lines to UNIX style, instead of Windows. Not sure what's wrong, but I gave up after struggling for a few hours (yes, was fighting with it at 3am :(. May be if any one of you know a procedure on how not to mess these things up, that would help. All I can offer at this time is a tip in case if we can't figure this out - Turn ON "ignore white space differences" in Eclipse preferences. This would help when reviewing the changes as it does not show the white space changes as spaces. This preference is available under General -> Compare/Patch -> General tab. You may already know about this, but in case. Of course, a Source Code Formatter posted to the MINA web site would definitely be a plus as I do want to format and still keep the unchanged stuff as is. Regards, Sai Pullabhotla On Mon, Mar 29, 2010 at 2:34 PM, Niklas Gustavsson wrote: > On Mon, Mar 29, 2010 at 2:31 PM, wrote: >> Author: sai >> Date: Mon Mar 29 13:31:55 2010 >> New Revision: 928769 >> >> URL: http://svn.apache.org/viewvc?rev=928769&view=rev >> Log: >> Implemented FTPSERVER-357 > > Seems like there was a ton of whitespace changes included in this > commit. Keeping the commits clean makes them much easier to review. > > /niklas >
Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java
BTW, do you know why Hudson is complaining about the test failure on trunk? I did not get that error locally. Regards, Sai Pullabhotla On Mon, Mar 29, 2010 at 4:06 PM, Niklas Gustavsson wrote: > On Mon, Mar 29, 2010 at 9:39 PM, Emmanuel Lecharny > wrote: >> Otherwise, if you think that the coding conventions don't fit, then we can >> discuss openly here. > > I don't mind what coding conventions we use, as long as they are consistent > :-) > > /niklas >
Re: svn commit: r928769
Cool, thanks. Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 3:21 AM, Dave Roberts wrote: > On 29/03/2010 22:35, Sai Pullabhotla wrote: >> >> Of course, a Source Code Formatter posted to the MINA web site would >> definitely be a plus as I do want to format and still keep the >> unchanged stuff as is. > > http://mina.apache.org/developer-guide.data/ImprovedJavaConventions.xml > > Or, go to the MINA home page, click on Developers Guide on the left, > then find the Coding Convention section > > "We follow Sun's standard Java coding convention except that we > always use spaces instead of tabs. Please download the Eclipse Java > formatter settings file before you make any changes to the code." >
Re: FTPServer handling of multiple concurrent connections.
I don't think that was intended. If this is in fact an issue, we should probably consider adding a configuration option such as maxThreads as the default max we choose may not be the best in all cases. Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 3:29 AM, David Latorre wrote: > Hello, > > When inspecting http://issues.apache.org/jira/browse/FTPSERVER-359 I > noticed that we might have an issue with threading in Ftpserver. > > I think we are using a 'fixed size thread pool' with max-threads=16 > for the Executor threadpool in which commands are executed. This would > mean that if we had 16 data transfers currently running , FTPServer > would be blocked until some of these data transfers ended- Is my > understanding correct? > > Is this behaviour desirable for us? I don't think that 16 data > transfers are that many, and some users might need to send huge files. >
Re: FTPServer handling of multiple concurrent connections.
What would be the benefit of using MINA compared to the traditional sockets, especially for passive connections? Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 7:33 AM, Niklas Gustavsson wrote: > On Tue, Mar 30, 2010 at 10:33 AM, Sai Pullabhotla > wrote: >> I don't think that was intended. If this is in fact an issue, we >> should probably consider adding a configuration option such as >> maxThreads as the default max we choose may not be the best in all >> cases. > > I think David is correct, and I agree with your proposed solution > (defaulting the value higher than 16 thou). We should also look into > moving the data connection over to using MINA, if someone got the > time. > > /niklas >
Re: FTPServer handling of multiple concurrent connections.
Since changing everything over to MINA could be quite a bit of work, and the issue we have is somewhat serious, we should come up with a short term solution first and release a patch. Perhaps this patch would do the following: Option 1: Have Max Threads as a configurable option at the server level. Each listener would share the same thread pool. Option 2: Have Max Threads as a configurable option at the listener (acceptor) level. I prefer option 1 as most people would look at the server level rather than listener level. In other words, my server should be able to handle 200 concurrent users. If Max Threads is not specified, may be we should default it to maxUsers/connections that we have. Not sure what the current keep-alive time for the threads is, but perhaps having a shorter keep-alive time may help in some cases, or make it as a configurable option. What do you think? Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 8:33 AM, Niklas Gustavsson wrote: > On Tue, Mar 30, 2010 at 2:22 PM, David Latorre wrote: >> I would rather go for a solution that make it impossible to block >> FTPServer rather than making it 'more difficult'. >> For this, we might limit the total number of data connections which >> wouldn't be perfect but might help... or maybe we can enforce a rule >> that MaxUsers < MaxThreads. > > Depending on your user profiles, I think there might be different > configurations that suites you best. So, I think we should supply both > the max concurrent users option (that we do today) and a max threads > option. Then, we need to provide reasonable defaults and documentation > on how to best use them. > >> - We could have a filter that limited bandwidth usage, although I >> don't think there is anything like that in FTPServer. > > We already do bandwidth limitation in our blocking data connections. > > /niklas >
Re: FTPServer handling of multiple concurrent connections.
Since I did not hear back anything on this, I will ask again :). Are you guys okay with the proposed short term solution? Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 10:10 AM, Sai Pullabhotla wrote: > Since changing everything over to MINA could be quite a bit of work, > and the issue we have is somewhat serious, we should come up with a > short term solution first and release a patch. Perhaps this patch > would do the following: > > Option 1: Have Max Threads as a configurable option at the server > level. Each listener would share the same thread pool. > > Option 2: Have Max Threads as a configurable option at the listener > (acceptor) level. > > I prefer option 1 as most people would look at the server level rather > than listener level. In other words, my server should be able to > handle 200 concurrent users. If Max Threads is not specified, may be > we should default it to maxUsers/connections that we have. Not sure > what the current keep-alive time for the threads is, but perhaps > having a shorter keep-alive time may help in some cases, or make it as > a configurable option. > > What do you think? > > Regards, > Sai Pullabhotla > > > > > > On Tue, Mar 30, 2010 at 8:33 AM, Niklas Gustavsson > wrote: >> On Tue, Mar 30, 2010 at 2:22 PM, David Latorre wrote: >>> I would rather go for a solution that make it impossible to block >>> FTPServer rather than making it 'more difficult'. >>> For this, we might limit the total number of data connections which >>> wouldn't be perfect but might help... or maybe we can enforce a rule >>> that MaxUsers < MaxThreads. >> >> Depending on your user profiles, I think there might be different >> configurations that suites you best. So, I think we should supply both >> the max concurrent users option (that we do today) and a max threads >> option. Then, we need to provide reasonable defaults and documentation >> on how to best use them. >> >>> - We could have a filter that limited bandwidth usage, although I >>> don't think there is anything like that in FTPServer. >> >> We already do bandwidth limitation in our blocking data connections. >> >> /niklas >> >
Re: svn commit: r928769
I've imported this formatter, but this does not auto-format the Java Docs. So, if I type a long line for a method comment, and format just the method or the entire class, the comments/java docs are not affected. Is it okay to enable the formatting on Javadocs and wrap the lines at 80 just like the code? Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 3:21 AM, Dave Roberts wrote: > On 29/03/2010 22:35, Sai Pullabhotla wrote: >> >> Of course, a Source Code Formatter posted to the MINA web site would >> definitely be a plus as I do want to format and still keep the >> unchanged stuff as is. > > http://mina.apache.org/developer-guide.data/ImprovedJavaConventions.xml > > Or, go to the MINA home page, click on Developers Guide on the left, > then find the Coding Convention section > > "We follow Sun's standard Java coding convention except that we > always use spaces instead of tabs. Please download the Eclipse Java > formatter settings file before you make any changes to the code." >
Re: svn commit: r928769
Wouldn't you use HTML tags/pre-formatted text for those types of docs? Regards, Sai Pullabhotla On Thu, Apr 1, 2010 at 1:47 PM, Emmanuel Lecharny wrote: > On 4/1/10 2:37 PM, Sai Pullabhotla wrote: >> >> I've imported this formatter, but this does not auto-format the Java >> Docs. So, if I type a long line for a method comment, and format just >> the method or the entire class, the comments/java docs are not >> affected. Is it okay to enable the formatting on Javadocs and wrap the >> lines at 80 just like the code? >> > > That's not a good idea. We did that one at ADS, and all the painfully > formatted comments where we exposed > data structure were all broken as a consequence ... > > Just my 2 cts. > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > >
Assigning JIRA issues
Is there a way I can assign some of the open issues in JIRA to myself. I'm planning on working on some of the items that I opened recently and want to make sure nobody else is/would work on them. Regards, Sai Pullabhotla
Re: Assigning JIRA issues
Thanks, Niklas! Regards, Sai Pullabhotla On Mon, Apr 5, 2010 at 3:36 PM, Niklas Gustavsson wrote: > On Mon, Apr 5, 2010 at 10:16 PM, Sai Pullabhotla > wrote: >> Is there a way I can assign some of the open issues in JIRA to myself. >> I'm planning on working on some of the items that I opened recently >> and want to make sure nobody else is/would work on them. > > Fixed. > > /niklas >
Re: [jira] Created: (FTPSERVER-367) RFC: FTP HASH command (similar to MD5, which is already supported)
This looks good. We should have these defined years ago, but better late than never! Regards, Sai Pullabhotla On Wed, Apr 14, 2010 at 2:38 AM, Ant Bryan (JIRA) wrote: > RFC: FTP HASH command (similar to MD5, which is already supported) > -- > > Key: FTPSERVER-367 > URL: https://issues.apache.org/jira/browse/FTPSERVER-367 > Project: FtpServer > Issue Type: New Feature >Reporter: Ant Bryan >Priority: Trivial > Fix For: WISHLIST > > > According to http://mina.apache.org/ftpserver/documentation.html , the > MD5/MMD5 FTP commands from draft-twine-ftpmd5-00 are supported. > > Unfortunately, MD5 and other FTP hashing commands (XMD5, XSHA, XSHA1, > XSHA256, XSHA512, SITE SHOHASH, SITE CHECKSUM, etc) have not been formally > specified, leading to non-interoperability and confusion. > > A new draft which intends to reach RFC status is underway: > http://tools.ietf.org/html/draft-bryan-ftp-hash > > It would be very helpful, if this draft could be reviewed and your comments > provided to improve it. > > > Here is a quick overview. > > Requesting hash: > > HASH filename.ext > > HASH server response with Positive Completion code and the requested > hash using the currently selected algorithm: > > 213 80bc95fd391772fa61c91ed68567f0980bb45fd9 > > Changing HASH algorithms: > >C> OPTS HASH SHA-512 >S> 200 SHA-512 > > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > https://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > >
Re: FTPServer handling of multiple concurrent connections.
I'm pretty sure it is checked into the trunk. Regards, Sai Pullabhotla On Fri, Apr 23, 2010 at 7:35 AM, Peter van der Velde < peter.vanderve...@anachron.com> wrote: > L.S. > > Is there an ETA for this change? > > Greetings, > > Peter van der Velde > > -Original Message- > From: David Latorre [mailto:dvl...@gmail.com] > Sent: donderdag 1 april 2010 12:57 > To: dev@mina.apache.org > Subject: Re: FTPServer handling of multiple concurrent connections. > > 2010/3/31 Niklas Gustavsson : > > On Wed, Mar 31, 2010 at 6:32 PM, Sai Pullabhotla > > wrote: > >> Since I did not hear back anything on this, I will ask again :). > >> > >> Are you guys okay with the proposed short term solution? > > > > +1 to option 1 and to defaulting to max users. > > Sounds good :-) > > > /niklas > > >
Re: [VOTE] Release SSHD 0.4.0
I've not played with this project much, but thought I should check
this out after I saw the SFTP support in the release notes. I could
not get a working SFTP session using FileZilla. SSHD is running on
Windows using the code from trunk. I've modified the main method in
SshServer to add the SFTP subsystem. I was able to connect, login and
then when FileZilla does a PWD, it errors out as it receives an
invalid response from the server. Below is the debug log from
FileZilla:
Status: Connecting to localhost:...
Trace: Going to execute "C:\Program Files (x86)\FileZilla FTP
Client\fzsftp.exe"
Response: fzSftp started
Trace: CSftpControlSocket::ConnectParseResponse(fzSftp started)
Trace: CSftpControlSocket::SendNextCommand()
Trace: CSftpControlSocket::ConnectSend()
Command:keyfile "C:\Users\sai\temp\filezilla.ppk"
Trace: CSftpControlSocket::ConnectParseResponse()
Trace: CSftpControlSocket::SendNextCommand()
Trace: CSftpControlSocket::ConnectSend()
Command:open "p...@localhost"
Trace: Looking up host "localhost"
Trace: Connecting to 127.0.0.1 port
Trace: Server version: SSH-2.0-${POM.ARTIFACTID}-${POM.VERSION}
Trace: Using SSH protocol version 2
Trace: We claim version: SSH-2.0-PuTTY_Local:_Oct_10_2009_18:54:23
Trace: Using Diffie-Hellman with standard group "group14"
Trace: Doing Diffie-Hellman key exchange with hash SHA-1
Command:Trust new Hostkey: Once
Trace: Host key fingerprint is:
Trace: ssh-dss 1024 90:c8:10:01:dd:81:97:00:65:ec:c3:f9:d9:16:2d:b1
Trace: Initialised AES-256 CBC client->server encryption
Trace: Initialised HMAC-SHA1 client->server MAC algorithm
Trace: Initialised AES-256 CBC server->client encryption
Trace: Initialised HMAC-SHA1 server->client MAC algorithm
Trace: Successfully loaded 1 key pair from file
Trace: Offered public key from "C:\Users\sai\temp\filezilla.ppk"
Trace: Offer of public key accepted, trying to authenticate using it.
Trace: Access granted
Trace: Opened channel for session
Trace: Started a shell/command
Status: Connected to SAI
Trace: CSftpControlSocket::ConnectParseResponse()
Trace: CSftpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Retrieving directory listing...
Trace: CSftpControlSocket::SendNextCommand()
Trace: CSftpControlSocket::ChangeDirSend()
Command:pwd
Response: Current directory is: "."
Trace: ControlSocket.cpp(361): Failed to parse returned path.
caller=0p2835f80
Trace: CSftpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Trace: CSftpControlSocket::ParseSubcommandResult(2)
Trace: CSftpControlSocket::ListSubcommandResult()
Trace: CSftpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Error: Failed to retrieve directory listing
Notice that the reply to pwd (real path) is just ".". I think it
should start with "/", and that is why FileZilla is blowing up.
In short, the question is - should SSH_FXP_REALPATH return the path
(virtual or absolute) instead of just the name?
Regards,
Sai Pullabhotla
On Tue, May 4, 2010 at 8:19 AM, Guillaume Nodet wrote:
> I've uploaded a RC for SSHD 0.4.0 at
> https://repository.apache.org/content/repositories/orgapachemina-003/
>
> The release notes are available at
> https://cwiki.apache.org/SSHD/sshd-040.html
>
> Please review and vote
>
> --
> Cheers,
> Guillaume Nodet
>
> Blog: http://gnodet.blogspot.com/
>
> Open Source SOA
> http://fusesource.com
>
Re: [VOTE] Release SSHD 0.4.0 (2nd try)
Is this SFTP fix checked into trunk or 0.4 tag? I do not see any changes to the SVN. Regards, Sai Pullabhotla On Wed, May 5, 2010 at 4:52 AM, Guillaume Nodet wrote: > I've uploaded a RC for SSHD 0.4.0 at > https://repository.apache.org/content/repositories/orgapachemina-008/ > > The release notes are available at > https://cwiki.apache.org/SSHD/sshd-040.html > > Please review and vote. > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com >
Re: [VOTE] Release SSHD 0.4.0 (2nd try)
tCommand()
Trace: CSftpControlSocket::ConnectSend()
Command:keyfile "C:\Users\sai\temp\filezilla.ppk"
Trace: CSftpControlSocket::ConnectParseResponse()
Trace: CSftpControlSocket::SendNextCommand()
Trace: CSftpControlSocket::ConnectSend()
Command:open "p...@localhost"
Trace: Looking up host "localhost"
Trace: Connecting to 127.0.0.1 port
Trace: Server version: SSH-2.0-${POM.ARTIFACTID}-${POM.VERSION}
Trace: Using SSH protocol version 2
Trace: We claim version: SSH-2.0-PuTTY_Local:_Oct_10_2009_18:54:23
Trace: Using Diffie-Hellman with standard group "group14"
Trace: Doing Diffie-Hellman key exchange with hash SHA-1
Command:Trust new Hostkey: Once
Trace: Host key fingerprint is:
Trace: ssh-dss 1024 90:c8:10:01:dd:81:97:00:65:ec:c3:f9:d9:16:2d:b1
Trace: Initialised AES-256 CBC client->server encryption
Trace: Initialised HMAC-SHA1 client->server MAC algorithm
Trace: Initialised AES-256 CBC server->client encryption
Trace: Initialised HMAC-SHA1 server->client MAC algorithm
Trace: Successfully loaded 1 key pair from file
Trace: Offered public key from "C:\Users\sai\temp\filezilla.ppk"
Trace: Offer of public key accepted, trying to authenticate using it.
Trace: Access granted
Trace: Opened channel for session
Trace: Started a shell/command
Status: Connected to SAI
Trace: CSftpControlSocket::ConnectParseResponse()
Trace: CSftpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CSftpControlSocket::FileTransfer(...)
Status: Starting download of C:\Users\sai\opensource\sshd\LICENSE.txt
Trace: CSftpControlSocket::SendNextCommand()
Trace: CSftpControlSocket::ChangeDirSend()
Command:cd "C:\Users\sai\opensource\sshd"
Error: Directory
C:\Users\sai\opensource\sshd/C:\Users\sai\opensource\sshd: no such
file or directory
Trace: CSftpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Trace: CSftpControlSocket::ParseSubcommandResult(2)
Trace: CSftpControlSocket::FileTransferSubcommandResult()
Trace: CSftpControlSocket::SendNextCommand()
Trace: FileTransferSend()
Command:mtime "C:\Users\sai\opensource\sshd\LICENSE.txt"
Error: get attrs for
C:\Users\sai\opensource\sshd/C:\Users\sai\opensource\sshd\LICENSE.txt:
no such file or directory
Trace: FileTransferParseResponse()
Trace: CSftpControlSocket::SendNextCommand()
Trace: FileTransferSend()
Command:get "C:\Users\sai\opensource\sshd\LICENSE.txt"
"C:\users\sai\temp\LICENSE.txt"
Error: C:\Users\sai\opensource\sshd/C:\Users\sai\opensource\sshd\LICENSE.txt:
open for read: failure
Trace: FileTransferParseResponse()
Trace: CSftpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Regards,
Sai Pullabhotla
On Wed, May 5, 2010 at 8:03 AM, Guillaume Nodet wrote:
> Committed at rev 941273. Could you give it a try asap please ? I'll wait
> for your input before recutting the release.
>
> On Wed, May 5, 2010 at 15:02, Guillaume Nodet wrote:
>
>> Argh, I committed to my git repo and forgot to push the change.
>>
>>
>> On Wed, May 5, 2010 at 14:53, Sai Pullabhotla <
>> sai.pullabho...@jmethods.com> wrote:
>>
>>> Is this SFTP fix checked into trunk or 0.4 tag? I do not see any
>>> changes to the SVN.
>>>
>>> Regards,
>>> Sai Pullabhotla
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 5, 2010 at 4:52 AM, Guillaume Nodet wrote:
>>> > I've uploaded a RC for SSHD 0.4.0 at
>>> > https://repository.apache.org/content/repositories/orgapachemina-008/
>>> >
>>> > The release notes are available at
>>> > https://cwiki.apache.org/SSHD/sshd-040.html
>>> >
>>> > Please review and vote.
>>> >
>>> > --
>>> > 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
>>
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
> Blog: http://gnodet.blogspot.com/
>
> Open Source SOA
> http://fusesource.com
>
Re: [VOTE] Release SSHD 0.4.0 (2nd try)
I think I got it to work a little better by changing the code in
SftpSubsystem.sendAbsoluteName to as follows:
line 743:
buffer.putString("/" + file.getPath().replace('\\', '/'));
In order to make it work correctly on *NIX systems, we might need a
check to determine whether or not we should prepend another "/" to the
path. Also, the currently checked in code puts the path into the
buffer twice. I'm not sure if that is needed.
Regards,
Sai Pullabhotla
On Wed, May 5, 2010 at 8:18 AM, Sai Pullabhotla
wrote:
> Okay, I got the fix and was able to see the directory listing using
> FileZilla. However, a couple of issues:
>
> 1. Date/time on the files returned by the list are incorrect. Looks
> like SSHD is always sending "Jan 01 00:00" for the date times.
> 2. I could not download or upload a file. Below is the trace info from
> FileZilla. Basically, when I try to download a file, FileZilla is
> requesting the incorrect path for what so ever reason. The path it
> requests is
> C:\Users\sai\opensource\sshd/C:\Users\sai\opensource\sshd\LICENSE.txt.
> As you can see, it is prepending the working directory to the selected
> file. I'm thinking it is due to the fact that we are sending "\" as
> the path separator instead of "/".
>
> Status: Connecting to localhost:...
> Trace: Going to execute "C:\Program Files (x86)\FileZilla FTP
> Client\fzsftp.exe"
> Response: fzSftp started
> Trace: CSftpControlSocket::ConnectParseResponse(fzSftp started)
> Trace: CSftpControlSocket::SendNextCommand()
> Trace: CSftpControlSocket::ConnectSend()
> Command: keyfile "C:\Users\sai\temp\filezilla.ppk"
> Trace: CSftpControlSocket::ConnectParseResponse()
> Trace: CSftpControlSocket::SendNextCommand()
> Trace: CSftpControlSocket::ConnectSend()
> Command: open "p...@localhost"
> Trace: Looking up host "localhost"
> Trace: Connecting to 127.0.0.1 port
> Trace: Server version: SSH-2.0-${POM.ARTIFACTID}-${POM.VERSION}
> Trace: Using SSH protocol version 2
> Trace: We claim version: SSH-2.0-PuTTY_Local:_Oct_10_2009_18:54:23
> Trace: Using Diffie-Hellman with standard group "group14"
> Trace: Doing Diffie-Hellman key exchange with hash SHA-1
> Command: Trust new Hostkey: Once
> Trace: Host key fingerprint is:
> Trace: ssh-dss 1024 90:c8:10:01:dd:81:97:00:65:ec:c3:f9:d9:16:2d:b1
> Trace: Initialised AES-256 CBC client->server encryption
> Trace: Initialised HMAC-SHA1 client->server MAC algorithm
> Trace: Initialised AES-256 CBC server->client encryption
> Trace: Initialised HMAC-SHA1 server->client MAC algorithm
> Trace: Successfully loaded 1 key pair from file
> Trace: Offered public key from "C:\Users\sai\temp\filezilla.ppk"
> Trace: Offer of public key accepted, trying to authenticate using it.
> Trace: Access granted
> Trace: Opened channel for session
> Trace: Started a shell/command
> Status: Connected to SAI
> Trace: CSftpControlSocket::ConnectParseResponse()
> Trace: CSftpControlSocket::ResetOperation(0)
> Trace: CControlSocket::ResetOperation(0)
> Status: Retrieving directory listing...
> Trace: CSftpControlSocket::SendNextCommand()
> Trace: CSftpControlSocket::ChangeDirSend()
> Command: pwd
> Response: Current directory is: "C:\Users\sai\opensource\sshd"
> Trace: CSftpControlSocket::ResetOperation(0)
> Trace: CControlSocket::ResetOperation(0)
> Trace: CSftpControlSocket::ParseSubcommandResult(0)
> Trace: CSftpControlSocket::ListSubcommandResult()
> Trace: CSftpControlSocket::SendNextCommand()
> Trace: CSftpControlSocket::ListSend()
> Command: ls
> Status: Listing directory C:\Users\sai\opensource\sshd
> Listing: -rw-rw-rw- 1 psai psai 734 Jan 01 00:00
> .classpath
> Listing: -rw-rw-rw- 1 psai psai 55 Jan 01 00:00
> .gitignore
> Listing: -rw-rw-rw- 1 psai psai 558 Jan 01 00:00
> .project
> Listing: drw-rw-rw- 1 psai psai 0 Jan 01 00:00
> .settings
> Listing: drw-rw-rw- 1 psai psai 4096 Jan 01 00:00 .svn
> Listing: drw-rw-rw- 1 psai psai 0 Jan 01 00:00
> assembly
> Listing: drw-rw-rw- 1 psai psai 4096 Jan 01 00:00 classes
> Listing: -rw-rw-rw- 1 psai psai 680 Jan 01 00:00 key.pem
> Listing: -rw-rw-rw- 1 psai psai 11359 Jan 01 00:00
> LICENSE.txt
> Listing: -rw-rw-rw- 1 psai psai 3090 Jan 01 00:00
> NOTICE.txt
> Listing: -rw-rw-rw- 1 psai psai 8786 Jan 01 00:00 pom.xml
> Listing
Re: [VOTE] Release SSHD 0.4.0 (2nd try)
I removed the second call to place the path in the buffer and seems to be working fine. Regards, Sai Pullabhotla
Re: [VOTE] Release SSHD 0.4.0 (2nd try)
How about something like this:
protected void sendAbsoluteName(int id, File file) throws IOException {
Buffer buffer = new Buffer();
buffer.putByte((byte) SSH_FXP_NAME);
buffer.putInt(id);
buffer.putInt(1);
String path = file.getPath();
if(File.separatorChar != '/') {
path = path.replace(File.separatorChar, '/');
}
if(path.charAt(0) != '/') {
path = '/' + path;
}
buffer.putString(path);
//buffer.putString(file.getPath());
writeAttrs(buffer, file);
send(buffer);
}
Regards,
Sai Pullabhotla
On Wed, May 5, 2010 at 8:45 AM, Sai Pullabhotla
wrote:
> I removed the second call to place the path in the buffer and seems to
> be working fine.
>
> Regards,
> Sai Pullabhotla
>
Re: [VOTE] Release SSHD 0.4.0 (2nd try)
I just noticed that the code checked in just replaces "\" with "/". I
think for best compliance on all operating systems and file systems,
it should replace File.separatorChar with "/". Not sure if there are
any file systems that use a separator other than "/" and "\".
Regards,
Sai Pullabhotla
On Wed, May 5, 2010 at 9:22 AM, Guillaume Nodet wrote:
> I've committed the changes. Could you give a try ?
>
> On Wed, May 5, 2010 at 16:20, Guillaume Nodet wrote:
>
>> Removing the second string works with FileZilla but fails with the sftp
>> command line utility.
>>
>>
>> On Wed, May 5, 2010 at 16:13, Guillaume Nodet wrote:
>>
>>> Yeah, that's what I'm trying.
>>> Let me try with removing the double name though.
>>>
>>>
>>> On Wed, May 5, 2010 at 15:50, Sai Pullabhotla <
>>> sai.pullabho...@jmethods.com> wrote:
>>>
>>>> How about something like this:
>>>>
>>>> protected void sendAbsoluteName(int id, File file) throws IOException
>>>> {
>>>> Buffer buffer = new Buffer();
>>>> buffer.putByte((byte) SSH_FXP_NAME);
>>>> buffer.putInt(id);
>>>> buffer.putInt(1);
>>>> String path = file.getPath();
>>>> if(File.separatorChar != '/') {
>>>> path = path.replace(File.separatorChar, '/');
>>>> }
>>>> if(path.charAt(0) != '/') {
>>>> path = '/' + path;
>>>> }
>>>> buffer.putString(path);
>>>> //buffer.putString(file.getPath());
>>>> writeAttrs(buffer, file);
>>>> send(buffer);
>>>> }
>>>>
>>>> Regards,
>>>> Sai Pullabhotla
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 5, 2010 at 8:45 AM, Sai Pullabhotla
>>>> wrote:
>>>> > I removed the second call to place the path in the buffer and seems to
>>>> > be working fine.
>>>> >
>>>> > Regards,
>>>> > Sai Pullabhotla
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
> Blog: http://gnodet.blogspot.com/
>
> Open Source SOA
> http://fusesource.com
>
Re: [VOTE] Release SSHD 0.4.0 (2nd try)
How about the dates on the files?
Regards,
Sai Pullabhotla
On Wed, May 5, 2010 at 10:13 AM, Guillaume Nodet wrote:
> Fixed, let me know if you find any other easily fixed issues.
>
> On Wed, May 5, 2010 at 16:41, Sai Pullabhotla
> wrote:
>
>> I just noticed that the code checked in just replaces "\" with "/". I
>> think for best compliance on all operating systems and file systems,
>> it should replace File.separatorChar with "/". Not sure if there are
>> any file systems that use a separator other than "/" and "\".
>>
>> Regards,
>> Sai Pullabhotla
>>
>>
>>
>>
>>
>> On Wed, May 5, 2010 at 9:22 AM, Guillaume Nodet wrote:
>> > I've committed the changes. Could you give a try ?
>> >
>> > On Wed, May 5, 2010 at 16:20, Guillaume Nodet wrote:
>> >
>> >> Removing the second string works with FileZilla but fails with the sftp
>> >> command line utility.
>> >>
>> >>
>> >> On Wed, May 5, 2010 at 16:13, Guillaume Nodet wrote:
>> >>
>> >>> Yeah, that's what I'm trying.
>> >>> Let me try with removing the double name though.
>> >>>
>> >>>
>> >>> On Wed, May 5, 2010 at 15:50, Sai Pullabhotla <
>> >>> sai.pullabho...@jmethods.com> wrote:
>> >>>
>> >>>> How about something like this:
>> >>>>
>> >>>> protected void sendAbsoluteName(int id, File file) throws
>> IOException
>> >>>> {
>> >>>> Buffer buffer = new Buffer();
>> >>>> buffer.putByte((byte) SSH_FXP_NAME);
>> >>>> buffer.putInt(id);
>> >>>> buffer.putInt(1);
>> >>>> String path = file.getPath();
>> >>>> if(File.separatorChar != '/') {
>> >>>> path = path.replace(File.separatorChar, '/');
>> >>>> }
>> >>>> if(path.charAt(0) != '/') {
>> >>>> path = '/' + path;
>> >>>> }
>> >>>> buffer.putString(path);
>> >>>> //buffer.putString(file.getPath());
>> >>>> writeAttrs(buffer, file);
>> >>>> send(buffer);
>> >>>> }
>> >>>>
>> >>>> Regards,
>> >>>> Sai Pullabhotla
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Wed, May 5, 2010 at 8:45 AM, Sai Pullabhotla
>> >>>> wrote:
>> >>>> > I removed the second call to place the path in the buffer and seems
>> to
>> >>>> > be working fine.
>> >>>> >
>> >>>> > Regards,
>> >>>> > Sai Pullabhotla
>> >>>> >
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> 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
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > 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
>
Re: [VOTE] Release SSHD 0.4.0 (2nd try)
Oh, by the way, it works fine for me with just putting (sending) the
path just once in the buffer. Tried with native sftp client on Ubuntu
Linux as well as Putty's SFTP command line client, which is what
FileZilla uses internally. I wonder why that does not work for you.
Regards,
Sai Pullabhotla
On Wed, May 5, 2010 at 10:49 AM, Sai Pullabhotla
wrote:
> How about the dates on the files?
>
> Regards,
> Sai Pullabhotla
>
>
>
>
>
> On Wed, May 5, 2010 at 10:13 AM, Guillaume Nodet wrote:
>> Fixed, let me know if you find any other easily fixed issues.
>>
>> On Wed, May 5, 2010 at 16:41, Sai Pullabhotla
>> wrote:
>>
>>> I just noticed that the code checked in just replaces "\" with "/". I
>>> think for best compliance on all operating systems and file systems,
>>> it should replace File.separatorChar with "/". Not sure if there are
>>> any file systems that use a separator other than "/" and "\".
>>>
>>> Regards,
>>> Sai Pullabhotla
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 5, 2010 at 9:22 AM, Guillaume Nodet wrote:
>>> > I've committed the changes. Could you give a try ?
>>> >
>>> > On Wed, May 5, 2010 at 16:20, Guillaume Nodet wrote:
>>> >
>>> >> Removing the second string works with FileZilla but fails with the sftp
>>> >> command line utility.
>>> >>
>>> >>
>>> >> On Wed, May 5, 2010 at 16:13, Guillaume Nodet wrote:
>>> >>
>>> >>> Yeah, that's what I'm trying.
>>> >>> Let me try with removing the double name though.
>>> >>>
>>> >>>
>>> >>> On Wed, May 5, 2010 at 15:50, Sai Pullabhotla <
>>> >>> sai.pullabho...@jmethods.com> wrote:
>>> >>>
>>> >>>> How about something like this:
>>> >>>>
>>> >>>> protected void sendAbsoluteName(int id, File file) throws
>>> IOException
>>> >>>> {
>>> >>>> Buffer buffer = new Buffer();
>>> >>>> buffer.putByte((byte) SSH_FXP_NAME);
>>> >>>> buffer.putInt(id);
>>> >>>> buffer.putInt(1);
>>> >>>> String path = file.getPath();
>>> >>>> if(File.separatorChar != '/') {
>>> >>>> path = path.replace(File.separatorChar, '/');
>>> >>>> }
>>> >>>> if(path.charAt(0) != '/') {
>>> >>>> path = '/' + path;
>>> >>>> }
>>> >>>> buffer.putString(path);
>>> >>>> //buffer.putString(file.getPath());
>>> >>>> writeAttrs(buffer, file);
>>> >>>> send(buffer);
>>> >>>> }
>>> >>>>
>>> >>>> Regards,
>>> >>>> Sai Pullabhotla
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Wed, May 5, 2010 at 8:45 AM, Sai Pullabhotla
>>> >>>> wrote:
>>> >>>> > I removed the second call to place the path in the buffer and seems
>>> to
>>> >>>> > be working fine.
>>> >>>> >
>>> >>>> > Regards,
>>> >>>> > Sai Pullabhotla
>>> >>>> >
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> 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
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > 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
>>
>
Re: [VOTE] Release SSHD 0.4.0 (2nd try)
Okay, I see the fix for the dates, but they are still incorrect when
the client interprets its. Couple of things -
I believe time should be on a 24 hour clock basis - so the format need
to be changed to HH instead of hh.
The listing is not compatible with UNIX style listing. So files older
than 6 months should show the year, but not the time. Files in the
last 6 months should show time, but not year. Unless SFTP has a
standard for the directory list format.
In essence, FileZilla shows a file that is modified in year 2006 as 2010.
There is some code in the FtpServer project that we may want to steal.
It is org.apache.ftpserver.util.DateUtils.getUnixDate(long).
Regards,
Sai Pullabhotla
On Wed, May 5, 2010 at 11:15 AM, Guillaume Nodet wrote:
> Which dates ? I've fixed the "Jan 01 ..." thing if that's why you're
> referring to.
> But using filezilla, there are still things that we don't support, but i've
> been able to download directories recursively without problems.
>
> On Wed, May 5, 2010 at 17:49, Sai Pullabhotla
> wrote:
>
>> How about the dates on the files?
>>
>> Regards,
>> Sai Pullabhotla
>>
>>
>>
>>
>>
>> On Wed, May 5, 2010 at 10:13 AM, Guillaume Nodet wrote:
>> > Fixed, let me know if you find any other easily fixed issues.
>> >
>> > On Wed, May 5, 2010 at 16:41, Sai Pullabhotla
>> > wrote:
>> >
>> >> I just noticed that the code checked in just replaces "\" with "/". I
>> >> think for best compliance on all operating systems and file systems,
>> >> it should replace File.separatorChar with "/". Not sure if there are
>> >> any file systems that use a separator other than "/" and "\".
>> >>
>> >> Regards,
>> >> Sai Pullabhotla
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, May 5, 2010 at 9:22 AM, Guillaume Nodet
>> wrote:
>> >> > I've committed the changes. Could you give a try ?
>> >> >
>> >> > On Wed, May 5, 2010 at 16:20, Guillaume Nodet
>> wrote:
>> >> >
>> >> >> Removing the second string works with FileZilla but fails with the
>> sftp
>> >> >> command line utility.
>> >> >>
>> >> >>
>> >> >> On Wed, May 5, 2010 at 16:13, Guillaume Nodet
>> wrote:
>> >> >>
>> >> >>> Yeah, that's what I'm trying.
>> >> >>> Let me try with removing the double name though.
>> >> >>>
>> >> >>>
>> >> >>> On Wed, May 5, 2010 at 15:50, Sai Pullabhotla <
>> >> >>> sai.pullabho...@jmethods.com> wrote:
>> >> >>>
>> >> >>>> How about something like this:
>> >> >>>>
>> >> >>>> protected void sendAbsoluteName(int id, File file) throws
>> >> IOException
>> >> >>>> {
>> >> >>>> Buffer buffer = new Buffer();
>> >> >>>> buffer.putByte((byte) SSH_FXP_NAME);
>> >> >>>> buffer.putInt(id);
>> >> >>>> buffer.putInt(1);
>> >> >>>> String path = file.getPath();
>> >> >>>> if(File.separatorChar != '/') {
>> >> >>>> path = path.replace(File.separatorChar, '/');
>> >> >>>> }
>> >> >>>> if(path.charAt(0) != '/') {
>> >> >>>> path = '/' + path;
>> >> >>>> }
>> >> >>>> buffer.putString(path);
>> >> >>>> //buffer.putString(file.getPath());
>> >> >>>> writeAttrs(buffer, file);
>> >> >>>> send(buffer);
>> >> >>>> }
>> >> >>>>
>> >> >>>> Regards,
>> >> >>>> Sai Pullabhotla
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> On Wed, May 5, 2010 at 8:45 AM, Sai Pullabhotla
>> >> >>>> wrote:
>> >> >>>> > I removed the second call to place the path in the buffer and
>> seems
>> >> to
>> >> >>>> > be working fine.
>> >> >>>> >
>> >> >>>> > Regards,
>> >> >>>> > Sai Pullabhotla
>> >> >>>> >
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> 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
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > 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
>> >
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
>
> Blog: http://gnodet.blogspot.com/
>
> Open Source SOA
> http://fusesource.com
>
Re: SFTP problems
I've setup the root directory for the SFTP subsystem to be "C:\". The login, and cd'ing, listing to subdirectories is working fine. But, I cannot "cd" to C:\ again using "cd ..". So if my working directory is "/dev", doing a "cd .." should put me back in "/" (whose real path is "C:\"). But the directory is unchanged. The "cd .." works well for directories that are deeper than one level. In other words, if my current dir is "/dev/apis" and doing a "cd .." puts me back in "/dev". Also, should the Default SSH server setup the SFTP subsystem as well? Regards, Sai Pullabhotla On Thu, May 6, 2010 at 4:54 AM, Guillaume Nodet wrote: > I've made a few other fixes (including SSHD-86) which helps a lot. > Please have a look and i'll cut a release tonight or tomorrow. > > On Wed, May 5, 2010 at 21:18, Guillaume Nodet wrote: > >> Thanks for the pointer. The SFTP subsystem is now using that code. >> Any more issues ? >> >> On Wed, May 5, 2010 at 18:43, Sai Pullabhotla < >> sai.pullabho...@jmethods.com> wrote: >> >>> Okay, I see the fix for the dates, but they are still incorrect when >>> the client interprets its. Couple of things - >>> >>> I believe time should be on a 24 hour clock basis - so the format need >>> to be changed to HH instead of hh. >>> >>> The listing is not compatible with UNIX style listing. So files older >>> than 6 months should show the year, but not the time. Files in the >>> last 6 months should show time, but not year. Unless SFTP has a >>> standard for the directory list format. >>> >>> In essence, FileZilla shows a file that is modified in year 2006 as 2010. >>> >>> There is some code in the FtpServer project that we may want to steal. >>> It is org.apache.ftpserver.util.DateUtils.getUnixDate(long). >>> >>> >>> Regards, >>> Sai Pullabhotla >>> >>> >>> >>> >>> >>> On Wed, May 5, 2010 at 11:15 AM, Guillaume Nodet >>> wrote: >>> > Which dates ? I've fixed the "Jan 01 ..." thing if that's why you're >>> > referring to. >>> > But using filezilla, there are still things that we don't support, but >>> i've >>> > been able to download directories recursively without problems. >>> > >>> > On Wed, May 5, 2010 at 17:49, Sai Pullabhotla >>> > wrote: >>> > >>> >> How about the dates on the files? >>> >> >>> >> Regards, >>> >> Sai Pullabhotla >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> On Wed, May 5, 2010 at 10:13 AM, Guillaume Nodet >>> wrote: >>> >> > Fixed, let me know if you find any other easily fixed issues. >>> >> > >>> >> > On Wed, May 5, 2010 at 16:41, Sai Pullabhotla >>> >> > wrote: >>> >> > >>> >> >> I just noticed that the code checked in just replaces "\" with "/". >>> I >>> >> >> think for best compliance on all operating systems and file systems, >>> >> >> it should replace File.separatorChar with "/". Not sure if there are >>> >> >> any file systems that use a separator other than "/" and "\". >>> >> >> >>> >> >> Regards, >>> >> >> Sai Pullabhotla >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Wed, May 5, 2010 at 9:22 AM, Guillaume Nodet >>> >> wrote: >>> >> >> > I've committed the changes. Could you give a try ? >>> >> >> > >>> >> >> > On Wed, May 5, 2010 at 16:20, Guillaume Nodet >>> >> wrote: >>> >> >> > >>> >> >> >> Removing the second string works with FileZilla but fails with >>> the >>> >> sftp >>> >> >> >> command line utility. >>> >> >> >> >>> >> >> >> >>> >> >> >> On Wed, May 5, 2010 at 16:13, Guillaume Nodet >>> >> wrote: >>> >> >> >> >>> >> >> >>> Yeah, tha
Re: svn commit: r942690 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/impl/FtpIoSession.java test/java/org/apache/ftpserver/clienttests/LoginTest.java
+1 for this. Most of the code that is currently checked is not formatted using the published formatter. It should be easy to reformat all the sources and check them in. Regards, Sai Pullabhotla On Mon, May 10, 2010 at 4:45 AM, Emmanuel Lecharny wrote: > On 5/10/10 11:41 AM, David Latorre wrote: >> >> Oh sorry, >> >> I believed I was using "MINA formatter" so I thought it would be ok to >> format the whole thing. >> > > It would be a good idea to "reformat" all the files following the current > formater in one big commit, so that developpers are not annoyed when > checking a diff... > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > >
Re: [VOTE] Release SSHD 0.4.0 (third try)
+1 Regards, Sai Pullabhotla On Mon, May 10, 2010 at 9:44 PM, Guillaume Nodet wrote: > I've uploaded a RC for SSHD 0.4.0 at > https://repository.apache.org/content/repositories/orgapachemina-026/ > > The release notes are available at > https://cwiki.apache.org/SSHD/sshd-040.html > > Please review and vote. > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com >
Custom NioScoketSession
I've been trying to use the MINA API in one of my projects, and have the following question: Is it possible to create a custom NioSocketSession when NioSocketAcceptor accepts a connection from a client? My idea is to have a sub class of NioSocketSession and some how attach it to the Acceptor. This subclass would hold the additional information that I need during the life of the session. I know we can store any custom attributes in the session, but that could get pretty messy when I need to store a bunch of information. I looked through the API docs and code, but did not find a way to do what I want. I apologize if I did not look hard enough. NioSocketAcceptor creates a NioSocketSession in its accept method. I thought of subclassing NioSocketAcceptor and override the accept method (which is protected), but can't do it because the class is final. Is there a reason why this class is final and still have protected methods? I really could use this piece of functionality if there is a way to do it with the current release. Any help is greatly appreciated. Thanks in advance, Sai
Help needed with OutOfMemory error and/or GC Issues/Dead Locks
Guys, I've been fighting with various issues using Mina over the past couple of weeks, and a couple of them are - 1) OutOfMemory on Heap 2) Possible dead lock (it could just be a GC issue). Application does not make any progress nor any error is reported. 3) When running under Java 6, I often am getting java.lang.OutOfMemoryError: GC overhead limit exceeded, which tells me that GC is not able to clean up the stuff. The version of MINA I'm using is 2.0-RC1. Just to give you a background - I'm trying to create what I would like to call "Broker". A Broker basically connects to two different servers, and forwards the data received from one server to the other. Sounds simple, but I'm not having much luck using the Nio implementation of MINA. Things seem to work fine when there is not much data flows through the broker, but, when large amounts of data is flowing through, I'm running out of memory. I did see the MINA documentation on the OOM, and am using IoEventQueueThrottle, but did not get any better results. I hope I'm using it the right way, as I did not see much documentation on that class. I decided to stop working on the main project, and decided to put a simple test case as follows: 1. Create a MINA server using NioSocketAcceptor. I called this the MinaSenderServer. All this does is as soon as a client connects to it, it starts sending a bunch of random data, upto the specified size, and closes the session. Basically, the IoHandler.sessionOpened, goes into a loop and calls IoSession.write until the desired amount of bytes are written, and the calls the IoSession.close(false). 2. I Created another MINA server using the very same NioSocketAcceptor. I called this the MinaReceiverServer. All this does is - accepts connections from clients, and dumps any data received from the client into a temp file. 3. I also created my Broker, which uses NioSocketConnector. It connects to to MinaReceiverServer first, and then to MinaSenderServer. Creates a tunnel using both the sessions. It then forwards the random data received from MinaSenderServer to the MinaReceiverServer. This appears to be working for small amounts of data (< 1MB), but get either a OOM on heap, or GC error in Java 6 or app appears to have locked up making no progress. Just so you know, I'm running these 3 classes in 3 different JVMs using default memory settings for Java. My understanding is that not much of data should be kept in memory, but some how it is retained in memory, or GC is not able to reclaim it. My requirement is that I would have server concurrent Broker sessions at any given time, which could be carrying any amount of data ranging from a few KB to a few GB. I've tried various configuration settings on the Acceptors and Connectors such as - 1. Using thread pool executor/Not using 2. Using IoEventQueue Throttle/Not using 3. When using a Thread pool, waiting for WriteFutures to complete 4. Setting various session configuration options such as Send and Receive buffers of sockets None of these gave me any positive result. Obviously I'm missing something. I can send the test classes that I wrote if some one wants to take a look at it and what I'm doing wrong. Hopefully, it is something simple that I'm unknown of, or overlooking. Let me know the preferred way for posting this test code.
Re: Help needed with OutOfMemory error and/or GC Issues/Dead Locks
I've attached a couple of simple classes, one server, and one client to reproduce this lockup/OOM, at https://issues.apache.org/jira/browse/DIRMINA-789. I appreciate your time and help looking into this. On Thu, Jun 10, 2010 at 6:32 PM, Emmanuel Lecharny wrote: > On 6/11/10 1:10 AM, Sai Pullabhotla wrote: >> >> Guys, >> >> I've been fighting with various issues using Mina over the past couple >> of weeks, and a couple of them are - >> >> 1) OutOfMemory on Heap >> 2) Possible dead lock (it could just be a GC issue). Application does >> not make any progress nor any error is reported. >> 3) When running under Java 6, I often am getting >> java.lang.OutOfMemoryError: GC overhead limit exceeded, which tells me >> that GC is not able to clean up the stuff. >> >> The version of MINA I'm using is 2.0-RC1. >> >> Just to give you a background - I'm trying to create what I would like >> to call "Broker". A Broker basically connects to two different >> servers, and forwards the data received from one server to the other. >> Sounds simple, but I'm not having much luck using the Nio >> implementation of MINA. Things seem to work fine when there is not >> much data flows through the broker, but, when large amounts of data is >> flowing through, I'm running out of memory. >> >> I did see the MINA documentation on the OOM, and am using >> IoEventQueueThrottle, but did not get any better results. I hope I'm >> using it the right way, as I did not see much documentation on that >> class. >> >> I decided to stop working on the main project, and decided to put a >> simple test case as follows: >> >> 1. Create a MINA server using NioSocketAcceptor. I called this the >> MinaSenderServer. All this does is as soon as a client connects to it, >> it starts sending a bunch of random data, upto the specified size, and >> closes the session. Basically, the IoHandler.sessionOpened, goes into >> a loop and calls IoSession.write until the desired amount of bytes are >> written, and the calls the IoSession.close(false). >> >> 2. I Created another MINA server using the very same >> NioSocketAcceptor. I called this the MinaReceiverServer. All this does >> is - accepts connections from clients, and dumps any data received >> from the client into a temp file. >> >> 3. I also created my Broker, which uses NioSocketConnector. It >> connects to to MinaReceiverServer first, and then to MinaSenderServer. >> Creates a tunnel using both the sessions. It then forwards the random >> data received from MinaSenderServer to the MinaReceiverServer. >> >> This appears to be working for small amounts of data (< 1MB), but get >> either a OOM on heap, or GC error in Java 6 or app appears to have >> locked up making no progress. Just so you know, I'm running these 3 >> classes in 3 different JVMs using default memory settings for Java. My >> understanding is that not much of data should be kept in memory, but >> some how it is retained in memory, or GC is not able to reclaim it. My >> requirement is that I would have server concurrent Broker sessions at >> any given time, which could be carrying any amount of data ranging >> from a few KB to a few GB. >> >> I've tried various configuration settings on the Acceptors and >> Connectors such as - >> >> 1. Using thread pool executor/Not using >> 2. Using IoEventQueue Throttle/Not using >> 3. When using a Thread pool, waiting for WriteFutures to complete >> 4. Setting various session configuration options such as Send and >> Receive buffers of sockets >> >> None of these gave me any positive result. Obviously I'm missing >> something. >> >> I can send the test classes that I wrote if some one wants to take a >> look at it and what I'm doing wrong. Hopefully, it is something simple >> that I'm unknown of, or overlooking. Let me know the preferred way for >> posting this test code. >> > > Can you create a JIRA and attach those files into it ? > > Thanks ! > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > >
Re: Allowing only AUTH SSL in ftpserver
You should be able to this with an Ftplet that captures the beforeCommand (USER command) event, and make sure the session is secured. If the session was not secured already, send a 5xx/4xx reply from the Ftplet, and optionally close the session. FtpSession.isSecure() is the method you need to use for determining this. Hope this helps. Sai. On Tue, Sep 14, 2010 at 10:09 AM, John Hartnup wrote: > Hi, > > Reading the config docs, and briefly examining the source, it seems as if > explicit SSL is supported (AUTH TLS) but that there's no way to disallow > login if the session hasn't been secured. > > 1. Have I got that wrong? > 2. Does anyone have any opinion on the best place to add that feature? My > (naive?) instinct is to add a test in org.apache.ftpserver.command.imp.USER > or possibly PASS. > > Thanks, > John > > -- > "There is no way to peace; peace is the way" >
Re: Allowing only AUTH SSL in ftpserver
A future release could have a setting on the listener to force a secure session. You might want to open a case in JIRA for this. I think this would be a good addition. On Tue, Sep 14, 2010 at 10:37 AM, John Hartnup wrote: > Thanks, yes that makes sense. > > The implication, then, is that this is a niche behaviour that would be best > implemented in an ftplet, and not something that be available all the time, > to be configured in the element? > > On 14 September 2010 16:18, Sai Pullabhotla > wrote: > >> You should be able to this with an Ftplet that captures the >> beforeCommand (USER command) event, and make sure the session is >> secured. If the session was not secured already, send a 5xx/4xx reply >> from the Ftplet, and optionally close the session. >> FtpSession.isSecure() is the method you need to use for determining >> this. >> >> Hope this helps. >> Sai. >> >> On Tue, Sep 14, 2010 at 10:09 AM, John Hartnup >> wrote: >> > Hi, >> > >> > Reading the config docs, and briefly examining the source, it seems as if >> > explicit SSL is supported (AUTH TLS) but that there's no way to disallow >> > login if the session hasn't been secured. >> > >> > 1. Have I got that wrong? >> > 2. Does anyone have any opinion on the best place to add that feature? My >> > (naive?) instinct is to add a test in >> org.apache.ftpserver.command.imp.USER >> > or possibly PASS. >> > >> > Thanks, >> > John >> > >> > -- >> > "There is no way to peace; peace is the way" >> > >> > > > > -- > "There is no way to peace; peace is the way" >
Re: Allowing only AUTH SSL in ftpserver
While this should work with most clients, there is still a need to just secure authentication process (especially the user name and password). Once the authentication is finished, a client might want to switch back to plain old FTP if there is no confidential data. So having an option or two on the listeners might not be a bad idea. On Tue, Sep 14, 2010 at 10:47 AM, Dave Roberts wrote: > On 14/09/2010 16:37, John Hartnup wrote: >> The implication, then, is that this is a niche behaviour that would be best >> implemented in an ftplet, and not something that be available all the time, >> to be configured in the element? > > Given that you want to impose the use of SSL, can you not make use > of the implicit SSL option on a single listener instance? As far as > I know, most clients that support SSL, support both implicit and > explicit modes. >
Re: FtpServer 1.0.5 release planning
I think it is a major issue, and I recommend including it in the patch, if possible. FYI, I've been using this patch in production for quite some months now. On Mon, Sep 20, 2010 at 12:47 AM, Niklas Gustavsson wrote: > On Mon, Sep 20, 2010 at 7:18 AM, Chandraprakash Bhagtani > wrote: >> is FTPSERVER-362 included in this cut? > > No, not currently. As noted in the issue, I would prefer to keep that > to 1.1.0 since it's a pretty significant change and also requires an > update to the XML schema. If anyone feel strongly about getting this > into 1.0.5, please speak up and let's review the patch further. > > /niklas >
Re: [VOTE] Release Apache FtpServer 1.0.5
Not sure if I'm doing something wrong, but I downloaded https://repository.apache.org/content/repositories/orgapachemina-015/org/apache/ftpserver/ftpserver/1.0.5/ftpserver-1.0.5.zip, and extracted it, and ran the ftpd.bat. I get the following error: C:\dev\servers\apache-ftpserver-1.0.5\bin>ftpd.bat Using default configuration Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/ftpserver/ ipfilter/IpFilter at org.apache.ftpserver.listener.ListenerFactory.createListener(Listener Factory.java:109) at org.apache.ftpserver.impl.DefaultFtpServerContext.(DefaultFtpSe rverContext.java:100) at org.apache.ftpserver.FtpServerFactory.(FtpServerFactory.java:51 ) at org.apache.ftpserver.main.CommandLine.getConfiguration(CommandLine.ja va:115) at org.apache.ftpserver.main.CommandLine.main(CommandLine.java:56) Please advise. Regards, Sai Pullabhotla On Sun, Sep 26, 2010 at 2:56 PM, Niklas Gustavsson wrote: > Hi > > We've fixed quite a few bugs in FtpServer and I think we're ready for > a new release. I've uploaded binaries at: > https://repository.apache.org/content/repositories/orgapachemina-015/ > > These are based on the source here: > https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.5/ > > The change log is here: > https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12314821 > > Let's vote: > [ ] +1, release FtpServer 1.0.5 > [ ] 0 > [ ] -1, don't release because... > > /niklas >
Re: [VOTE] Release Apache FtpServer 1.0.5, take 2
[ ] +1, release FtpServer 1.0.5
