You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Bengt Rodehav <be...@rodehav.com> on 2010/06/15 08:35:12 UTC
camel-ftp and ftps secure data channel
Claus,
I decided to create a new thred of conversation instead of reusing
"camel-ftp problems with ftps implicit mode". The modifications you did in
camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave me a lot
of problems due to the changs in Camel's OSGi support. Willem has helped me
to sort them out and I've now gone back to the original ftps secure data
channel subject.
NOTE, if you've read my last post in the thread "camel-ftp problems with
ftps implicit mode" I had missed the first line of the exception stacktrace
which I have corrected in this mail.
I've now tested your ftps enhancement against Filezilla and Serv-U and it
works. However, I noticed the following:
If option "execPbsz" is not set then the PBSZ command is not sent at all.
The documentation says that default value is "0" which indicates that PBSZ
is always sent. I think the behaviour is correct but the documentation
should change and specify that "null" is the default value for "execPbsz".
About the configuration, I still think that the configuration is a bit
illogical. First of all, PBSZ and PROT commands are valid even though a
secure data channel is not used. It might even be valid for purt ftp (not
ftps) as well - I'm not sure. Therefore, the execProt and execPbsz options
should take effect regardless of the value of the useSecureDataChannel
option.
Furthermore, I think the normal case should be default and require very
little configuration. I therefore suggest the following:
a) useSecureDataChannel should be true by default. This is due to two
reasons:
1. If ftp severs have requirements in this area, they tend to be
restrictive. Serv-U, for example require PROT P (secure data channel). Clear
text is allowed if one explicitly sends PROT C but not if no PROT command is
sent at all.
2. I think that if the default is clear text then many developers will
send unencrypted content by mistake. I think that if you choose to use ftps,
most developers assume that the data is encrypted. That's what I did anyway.
b) If useSecureDataChannel is true, then this implies execPbsz=0 and
execProt=P without having to configure it explicitly.
c) execPbsz and execProt options shall always take effect and shall override
the values implied by setting useSecureDataChannel to true. Normally one
would not have to configure these options at all.
One can argue that if we make PBSZ 0 and PROT P the default, then we could
skip the useSecureDataChannel and only have the execProt and execPbsz
options. This would actually be OK since overriding the PBSZ 0 / PROT P
options is an active decision by a developer who presumably knows what s/he
is doing. This is OK with me but then it should also be possible to disable
sending of the PBSZ and PROT commands by explicitly setting those options to
the empty string.
Maybe I'm writing too much in this thread now but I also found another
problem: If something goes wrong, e g file already exists (Filezilla doesn't
permit overwrite) then I get the following exception on subsequent attempts.
I have to manually restart the route to get it to work.
org.apache.camel.component.file.GenericFileOperationFailedException: File
operation failed: null Unconnected sockets not implemented. Code: 221
at
org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
...
I get the above exception regardless of the value of the "disconnect" optin
in camel-ftp.
Best regards,
/Bengt
Re: camel-ftp and ftps secure data channel
Posted by Bengt Rodehav <be...@rodehav.com>.
OK.
2010/6/16 Claus Ibsen <cl...@gmail.com>
> On Wed, Jun 16, 2010 at 11:20 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> > Claus,
> >
> > I've tested your latest changes and it works very well. Thanks for your
> > effort.
> >
> > BTW. Have you considered changing the default ports for ftps? I'm pretty
> > sure that the standard practice is port 21 for explicit ftps since you
> > always start with normal ftp and then switch to ftps. Also the standard
> port
> > for implicit ftps is 990. See the following link:
> >
> > http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
> >
>
> Hi
>
> I have changed the default port back to 21 for ftps.
> I could not easily change the logic to cater for isImplicit=true to
> change port to 990 automatic. So end user have to set the port number
> themself.
> Camel will use port 21 as default.
>
>
>
> > /Bengt
> >
> >
> > 2010/6/15 Bengt Rodehav <be...@rodehav.com>
> >
> >> Thanks Claus!
> >>
> >> Will test shortly (probably tomorrow),
> >>
> >> /Bengt
> >>
> >> 2010/6/15 Claus Ibsen <cl...@gmail.com>
> >>
> >>> On Tue, Jun 15, 2010 at 12:57 PM, Bengt Rodehav <be...@rodehav.com>
> >>> wrote:
> >>> > Claus,
> >>> >
> >>> > Just realised that I can stop both PSBZ and PROT to be sent by
> >>> > specifying useSecureDataChannel=false. This means that it is possible
> to
> >>> > tweak this every possible way. The only issue then would be the name
> of
> >>> this
> >>> > option. E g it's a bit illogical to specify:
> >>> >
> >>> > useSecureDataChannel=false
> >>> > execProt=P
> >>> >
> >>> > as well as:
> >>> >
> >>> > useSecureDataChannel=true
> >>> > execProt=C
> >>> >
> >>> > What the option "useSecureDataChannel" really does is setting default
> >>> values
> >>> > for execProt and execPbsz - maybe this should be reflected in the
> name.
> >>> What
> >>> > about renaming this option to "disableSecureDataChannelDefaults"
> (maybe
> >>> a
> >>> > bit long...). The meaning of its value would be the inverse of
> >>> > "useSecureDataChannel" and its default value would be false.
> >>> >
> >>>
> >>> Hi
> >>>
> >>> I have renamed that option. Yeah finding a good name for options is
> >>> often harder than you would think.
> >>> Fell free to test the latest source code on your systems.
> >>>
> >>>
> >>> >
> >>> > /Bengt
> >>> >
> >>> > 2010/6/15 Bengt Rodehav <be...@rodehav.com>
> >>> >
> >>> >> Claus,
> >>> >>
> >>> >> I've tested your new version and it works very good. However, I did
> not
> >>> >> find a way to specify that the PSBZ command should not be sent at
> all.
> >>> I
> >>> >> have a feeling that one does not want to send it when explicitly
> >>> specifying
> >>> >> PROT C. I'm not sure but maybe we need a way of specifying the the
> PSBZ
> >>> /
> >>> >> PROT command should not be sent. Perhaps some reserved value like
> "-1"
> >>> for
> >>> >> execPbsz and "none" for execProt.
> >>> >>
> >>> >> One other question/suggestion. The default port for ftps in
> camel-ftp
> >>> is
> >>> >> 2222. I don't quite understand why. Both Filizilla and Serv-U use
> port
> >>> 21
> >>> >> (the normal ftp port) for explicit ftps and port 990 for implicit
> ftps.
> >>> I
> >>> >> have a feeling that this is standard practice. Would be nice if
> >>> camel-ftp
> >>> >> defaulted to that.
> >>> >>
> >>> >> Did you know anything about the exception I mentioned? (Unconnected
> >>> >> sockets not implemented...)
> >>> >>
> >>> >>
> >>> >> Best regards,
> >>> >>
> >>> >> /Bengt
> >>> >>
> >>> >>
> >>> >> 2010/6/15 Claus Ibsen <cl...@gmail.com>
> >>> >>
> >>> >> Hi Bengt
> >>> >>>
> >>> >>> I have just committed a change on trunk. Can you test it on your
> >>> system?
> >>> >>> It now defaults have useSecureDataChannel as true. And that P and 0
> is
> >>> >>> used if not explicit configured.
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <be...@rodehav.com>
> >>> wrote:
> >>> >>> > Claus,
> >>> >>> >
> >>> >>> > I decided to create a new thred of conversation instead of
> reusing
> >>> >>> > "camel-ftp problems with ftps implicit mode". The modifications
> you
> >>> did
> >>> >>> in
> >>> >>> > camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which
> gave
> >>> me a
> >>> >>> lot
> >>> >>> > of problems due to the changs in Camel's OSGi support. Willem has
> >>> helped
> >>> >>> me
> >>> >>> > to sort them out and I've now gone back to the original ftps
> secure
> >>> data
> >>> >>> > channel subject.
> >>> >>> >
> >>> >>> > NOTE, if you've read my last post in the thread "camel-ftp
> problems
> >>> with
> >>> >>> > ftps implicit mode" I had missed the first line of the exception
> >>> >>> stacktrace
> >>> >>> > which I have corrected in this mail.
> >>> >>> >
> >>> >>> > I've now tested your ftps enhancement against Filezilla and
> Serv-U
> >>> and
> >>> >>> it
> >>> >>> > works. However, I noticed the following:
> >>> >>> >
> >>> >>> > If option "execPbsz" is not set then the PBSZ command is not sent
> at
> >>> >>> all.
> >>> >>> > The documentation says that default value is "0" which indicates
> >>> that
> >>> >>> PBSZ
> >>> >>> > is always sent. I think the behaviour is correct but the
> >>> documentation
> >>> >>> > should change and specify that "null" is the default value for
> >>> >>> "execPbsz".
> >>> >>> >
> >>> >>> > About the configuration, I still think that the configuration is
> a
> >>> bit
> >>> >>> > illogical. First of all, PBSZ and PROT commands are valid even
> >>> though a
> >>> >>> > secure data channel is not used. It might even be valid for purt
> ftp
> >>> >>> (not
> >>> >>> > ftps) as well - I'm not sure. Therefore, the execProt and
> execPbsz
> >>> >>> options
> >>> >>> > should take effect regardless of the value of the
> >>> useSecureDataChannel
> >>> >>> > option.
> >>> >>> >
> >>> >>> > Furthermore, I think the normal case should be default and
> require
> >>> very
> >>> >>> > little configuration. I therefore suggest the following:
> >>> >>> >
> >>> >>> > a) useSecureDataChannel should be true by default. This is due to
> >>> two
> >>> >>> > reasons:
> >>> >>> > 1. If ftp severs have requirements in this area, they tend to be
> >>> >>> > restrictive. Serv-U, for example require PROT P (secure data
> >>> channel).
> >>> >>> Clear
> >>> >>> > text is allowed if one explicitly sends PROT C but not if no PROT
> >>> >>> command is
> >>> >>> > sent at all.
> >>> >>> > 2. I think that if the default is clear text then many
> developers
> >>> will
> >>> >>> > send unencrypted content by mistake. I think that if you choose
> to
> >>> use
> >>> >>> ftps,
> >>> >>> > most developers assume that the data is encrypted. That's what I
> did
> >>> >>> anyway.
> >>> >>> >
> >>> >>> > b) If useSecureDataChannel is true, then this implies execPbsz=0
> and
> >>> >>> > execProt=P without having to configure it explicitly.
> >>> >>> >
> >>> >>> > c) execPbsz and execProt options shall always take effect and
> shall
> >>> >>> override
> >>> >>> > the values implied by setting useSecureDataChannel to true.
> Normally
> >>> one
> >>> >>> > would not have to configure these options at all.
> >>> >>> >
> >>> >>> > One can argue that if we make PBSZ 0 and PROT P the default, then
> we
> >>> >>> could
> >>> >>> > skip the useSecureDataChannel and only have the execProt and
> >>> execPbsz
> >>> >>> > options. This would actually be OK since overriding the PBSZ 0 /
> >>> PROT P
> >>> >>> > options is an active decision by a developer who presumably knows
> >>> what
> >>> >>> s/he
> >>> >>> > is doing. This is OK with me but then it should also be possible
> to
> >>> >>> disable
> >>> >>> > sending of the PBSZ and PROT commands by explicitly setting those
> >>> >>> options to
> >>> >>> > the empty string.
> >>> >>> >
> >>> >>> > Maybe I'm writing too much in this thread now but I also found
> >>> another
> >>> >>> > problem: If something goes wrong, e g file already exists
> (Filezilla
> >>> >>> doesn't
> >>> >>> > permit overwrite) then I get the following exception on
> subsequent
> >>> >>> attempts.
> >>> >>> > I have to manually restart the route to get it to work.
> >>> >>> >
> >>> >>> >
> org.apache.camel.component.file.GenericFileOperationFailedException:
> >>> >>> File
> >>> >>> > operation failed: null Unconnected sockets not implemented. Code:
> >>> 221
> >>> >>> > at
> >>> >>> >
> >>> >>>
> >>>
> org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> >>> > at
> >>> >>> >
> >>> >>>
> >>>
> org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> >>> > at
> >>> >>> >
> >>> >>>
> >>>
> org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> >>> > at
> >>> >>> >
> >>> >>>
> >>>
> org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> >>> > at
> >>> >>> >
> >>> >>>
> >>>
> org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
> >>> >>> > at
> >>> >>> >
> >>> >>>
> >>>
> org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> >>> > ...
> >>> >>> >
> >>> >>> > I get the above exception regardless of the value of the
> >>> "disconnect"
> >>> >>> optin
> >>> >>> > in camel-ftp.
> >>> >>> >
> >>> >>> >
> >>> >>> > Best regards,
> >>> >>> >
> >>> >>> > /Bengt
> >>> >>> >
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> Claus Ibsen
> >>> >>> Apache Camel Committer
> >>> >>>
> >>> >>> Author of Camel in Action: http://www.manning.com/ibsen/
> >>> >>> Open Source Integration: http://fusesource.com
> >>> >>> Blog: http://davsclaus.blogspot.com/
> >>> >>> Twitter: http://twitter.com/davsclaus
> >>> >>>
> >>> >>
> >>> >>
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Claus Ibsen
> >>> Apache Camel Committer
> >>>
> >>> Author of Camel in Action: http://www.manning.com/ibsen/
> >>> Open Source Integration: http://fusesource.com
> >>> Blog: http://davsclaus.blogspot.com/
> >>> Twitter: http://twitter.com/davsclaus
> >>>
> >>
> >>
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
Re: camel-ftp and ftps secure data channel
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jun 16, 2010 at 11:20 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> Claus,
>
> I've tested your latest changes and it works very well. Thanks for your
> effort.
>
> BTW. Have you considered changing the default ports for ftps? I'm pretty
> sure that the standard practice is port 21 for explicit ftps since you
> always start with normal ftp and then switch to ftps. Also the standard port
> for implicit ftps is 990. See the following link:
>
> http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
>
Hi
I have changed the default port back to 21 for ftps.
I could not easily change the logic to cater for isImplicit=true to
change port to 990 automatic. So end user have to set the port number
themself.
Camel will use port 21 as default.
> /Bengt
>
>
> 2010/6/15 Bengt Rodehav <be...@rodehav.com>
>
>> Thanks Claus!
>>
>> Will test shortly (probably tomorrow),
>>
>> /Bengt
>>
>> 2010/6/15 Claus Ibsen <cl...@gmail.com>
>>
>>> On Tue, Jun 15, 2010 at 12:57 PM, Bengt Rodehav <be...@rodehav.com>
>>> wrote:
>>> > Claus,
>>> >
>>> > Just realised that I can stop both PSBZ and PROT to be sent by
>>> > specifying useSecureDataChannel=false. This means that it is possible to
>>> > tweak this every possible way. The only issue then would be the name of
>>> this
>>> > option. E g it's a bit illogical to specify:
>>> >
>>> > useSecureDataChannel=false
>>> > execProt=P
>>> >
>>> > as well as:
>>> >
>>> > useSecureDataChannel=true
>>> > execProt=C
>>> >
>>> > What the option "useSecureDataChannel" really does is setting default
>>> values
>>> > for execProt and execPbsz - maybe this should be reflected in the name.
>>> What
>>> > about renaming this option to "disableSecureDataChannelDefaults" (maybe
>>> a
>>> > bit long...). The meaning of its value would be the inverse of
>>> > "useSecureDataChannel" and its default value would be false.
>>> >
>>>
>>> Hi
>>>
>>> I have renamed that option. Yeah finding a good name for options is
>>> often harder than you would think.
>>> Fell free to test the latest source code on your systems.
>>>
>>>
>>> >
>>> > /Bengt
>>> >
>>> > 2010/6/15 Bengt Rodehav <be...@rodehav.com>
>>> >
>>> >> Claus,
>>> >>
>>> >> I've tested your new version and it works very good. However, I did not
>>> >> find a way to specify that the PSBZ command should not be sent at all.
>>> I
>>> >> have a feeling that one does not want to send it when explicitly
>>> specifying
>>> >> PROT C. I'm not sure but maybe we need a way of specifying the the PSBZ
>>> /
>>> >> PROT command should not be sent. Perhaps some reserved value like "-1"
>>> for
>>> >> execPbsz and "none" for execProt.
>>> >>
>>> >> One other question/suggestion. The default port for ftps in camel-ftp
>>> is
>>> >> 2222. I don't quite understand why. Both Filizilla and Serv-U use port
>>> 21
>>> >> (the normal ftp port) for explicit ftps and port 990 for implicit ftps.
>>> I
>>> >> have a feeling that this is standard practice. Would be nice if
>>> camel-ftp
>>> >> defaulted to that.
>>> >>
>>> >> Did you know anything about the exception I mentioned? (Unconnected
>>> >> sockets not implemented...)
>>> >>
>>> >>
>>> >> Best regards,
>>> >>
>>> >> /Bengt
>>> >>
>>> >>
>>> >> 2010/6/15 Claus Ibsen <cl...@gmail.com>
>>> >>
>>> >> Hi Bengt
>>> >>>
>>> >>> I have just committed a change on trunk. Can you test it on your
>>> system?
>>> >>> It now defaults have useSecureDataChannel as true. And that P and 0 is
>>> >>> used if not explicit configured.
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <be...@rodehav.com>
>>> wrote:
>>> >>> > Claus,
>>> >>> >
>>> >>> > I decided to create a new thred of conversation instead of reusing
>>> >>> > "camel-ftp problems with ftps implicit mode". The modifications you
>>> did
>>> >>> in
>>> >>> > camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave
>>> me a
>>> >>> lot
>>> >>> > of problems due to the changs in Camel's OSGi support. Willem has
>>> helped
>>> >>> me
>>> >>> > to sort them out and I've now gone back to the original ftps secure
>>> data
>>> >>> > channel subject.
>>> >>> >
>>> >>> > NOTE, if you've read my last post in the thread "camel-ftp problems
>>> with
>>> >>> > ftps implicit mode" I had missed the first line of the exception
>>> >>> stacktrace
>>> >>> > which I have corrected in this mail.
>>> >>> >
>>> >>> > I've now tested your ftps enhancement against Filezilla and Serv-U
>>> and
>>> >>> it
>>> >>> > works. However, I noticed the following:
>>> >>> >
>>> >>> > If option "execPbsz" is not set then the PBSZ command is not sent at
>>> >>> all.
>>> >>> > The documentation says that default value is "0" which indicates
>>> that
>>> >>> PBSZ
>>> >>> > is always sent. I think the behaviour is correct but the
>>> documentation
>>> >>> > should change and specify that "null" is the default value for
>>> >>> "execPbsz".
>>> >>> >
>>> >>> > About the configuration, I still think that the configuration is a
>>> bit
>>> >>> > illogical. First of all, PBSZ and PROT commands are valid even
>>> though a
>>> >>> > secure data channel is not used. It might even be valid for purt ftp
>>> >>> (not
>>> >>> > ftps) as well - I'm not sure. Therefore, the execProt and execPbsz
>>> >>> options
>>> >>> > should take effect regardless of the value of the
>>> useSecureDataChannel
>>> >>> > option.
>>> >>> >
>>> >>> > Furthermore, I think the normal case should be default and require
>>> very
>>> >>> > little configuration. I therefore suggest the following:
>>> >>> >
>>> >>> > a) useSecureDataChannel should be true by default. This is due to
>>> two
>>> >>> > reasons:
>>> >>> > 1. If ftp severs have requirements in this area, they tend to be
>>> >>> > restrictive. Serv-U, for example require PROT P (secure data
>>> channel).
>>> >>> Clear
>>> >>> > text is allowed if one explicitly sends PROT C but not if no PROT
>>> >>> command is
>>> >>> > sent at all.
>>> >>> > 2. I think that if the default is clear text then many developers
>>> will
>>> >>> > send unencrypted content by mistake. I think that if you choose to
>>> use
>>> >>> ftps,
>>> >>> > most developers assume that the data is encrypted. That's what I did
>>> >>> anyway.
>>> >>> >
>>> >>> > b) If useSecureDataChannel is true, then this implies execPbsz=0 and
>>> >>> > execProt=P without having to configure it explicitly.
>>> >>> >
>>> >>> > c) execPbsz and execProt options shall always take effect and shall
>>> >>> override
>>> >>> > the values implied by setting useSecureDataChannel to true. Normally
>>> one
>>> >>> > would not have to configure these options at all.
>>> >>> >
>>> >>> > One can argue that if we make PBSZ 0 and PROT P the default, then we
>>> >>> could
>>> >>> > skip the useSecureDataChannel and only have the execProt and
>>> execPbsz
>>> >>> > options. This would actually be OK since overriding the PBSZ 0 /
>>> PROT P
>>> >>> > options is an active decision by a developer who presumably knows
>>> what
>>> >>> s/he
>>> >>> > is doing. This is OK with me but then it should also be possible to
>>> >>> disable
>>> >>> > sending of the PBSZ and PROT commands by explicitly setting those
>>> >>> options to
>>> >>> > the empty string.
>>> >>> >
>>> >>> > Maybe I'm writing too much in this thread now but I also found
>>> another
>>> >>> > problem: If something goes wrong, e g file already exists (Filezilla
>>> >>> doesn't
>>> >>> > permit overwrite) then I get the following exception on subsequent
>>> >>> attempts.
>>> >>> > I have to manually restart the route to get it to work.
>>> >>> >
>>> >>> > org.apache.camel.component.file.GenericFileOperationFailedException:
>>> >>> File
>>> >>> > operation failed: null Unconnected sockets not implemented. Code:
>>> 221
>>> >>> > at
>>> >>> >
>>> >>>
>>> org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> >>> > at
>>> >>> >
>>> >>>
>>> org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> >>> > at
>>> >>> >
>>> >>>
>>> org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> >>> > at
>>> >>> >
>>> >>>
>>> org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> >>> > at
>>> >>> >
>>> >>>
>>> org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
>>> >>> > at
>>> >>> >
>>> >>>
>>> org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> >>> > ...
>>> >>> >
>>> >>> > I get the above exception regardless of the value of the
>>> "disconnect"
>>> >>> optin
>>> >>> > in camel-ftp.
>>> >>> >
>>> >>> >
>>> >>> > Best regards,
>>> >>> >
>>> >>> > /Bengt
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Claus Ibsen
>>> >>> Apache Camel Committer
>>> >>>
>>> >>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> >>> Open Source Integration: http://fusesource.com
>>> >>> Blog: http://davsclaus.blogspot.com/
>>> >>> Twitter: http://twitter.com/davsclaus
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>
>>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: camel-ftp and ftps secure data channel
Posted by Bengt Rodehav <be...@rodehav.com>.
Claus,
I've tested your latest changes and it works very well. Thanks for your
effort.
BTW. Have you considered changing the default ports for ftps? I'm pretty
sure that the standard practice is port 21 for explicit ftps since you
always start with normal ftp and then switch to ftps. Also the standard port
for implicit ftps is 990. See the following link:
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
/Bengt
2010/6/15 Bengt Rodehav <be...@rodehav.com>
> Thanks Claus!
>
> Will test shortly (probably tomorrow),
>
> /Bengt
>
> 2010/6/15 Claus Ibsen <cl...@gmail.com>
>
>> On Tue, Jun 15, 2010 at 12:57 PM, Bengt Rodehav <be...@rodehav.com>
>> wrote:
>> > Claus,
>> >
>> > Just realised that I can stop both PSBZ and PROT to be sent by
>> > specifying useSecureDataChannel=false. This means that it is possible to
>> > tweak this every possible way. The only issue then would be the name of
>> this
>> > option. E g it's a bit illogical to specify:
>> >
>> > useSecureDataChannel=false
>> > execProt=P
>> >
>> > as well as:
>> >
>> > useSecureDataChannel=true
>> > execProt=C
>> >
>> > What the option "useSecureDataChannel" really does is setting default
>> values
>> > for execProt and execPbsz - maybe this should be reflected in the name.
>> What
>> > about renaming this option to "disableSecureDataChannelDefaults" (maybe
>> a
>> > bit long...). The meaning of its value would be the inverse of
>> > "useSecureDataChannel" and its default value would be false.
>> >
>>
>> Hi
>>
>> I have renamed that option. Yeah finding a good name for options is
>> often harder than you would think.
>> Fell free to test the latest source code on your systems.
>>
>>
>> >
>> > /Bengt
>> >
>> > 2010/6/15 Bengt Rodehav <be...@rodehav.com>
>> >
>> >> Claus,
>> >>
>> >> I've tested your new version and it works very good. However, I did not
>> >> find a way to specify that the PSBZ command should not be sent at all.
>> I
>> >> have a feeling that one does not want to send it when explicitly
>> specifying
>> >> PROT C. I'm not sure but maybe we need a way of specifying the the PSBZ
>> /
>> >> PROT command should not be sent. Perhaps some reserved value like "-1"
>> for
>> >> execPbsz and "none" for execProt.
>> >>
>> >> One other question/suggestion. The default port for ftps in camel-ftp
>> is
>> >> 2222. I don't quite understand why. Both Filizilla and Serv-U use port
>> 21
>> >> (the normal ftp port) for explicit ftps and port 990 for implicit ftps.
>> I
>> >> have a feeling that this is standard practice. Would be nice if
>> camel-ftp
>> >> defaulted to that.
>> >>
>> >> Did you know anything about the exception I mentioned? (Unconnected
>> >> sockets not implemented...)
>> >>
>> >>
>> >> Best regards,
>> >>
>> >> /Bengt
>> >>
>> >>
>> >> 2010/6/15 Claus Ibsen <cl...@gmail.com>
>> >>
>> >> Hi Bengt
>> >>>
>> >>> I have just committed a change on trunk. Can you test it on your
>> system?
>> >>> It now defaults have useSecureDataChannel as true. And that P and 0 is
>> >>> used if not explicit configured.
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <be...@rodehav.com>
>> wrote:
>> >>> > Claus,
>> >>> >
>> >>> > I decided to create a new thred of conversation instead of reusing
>> >>> > "camel-ftp problems with ftps implicit mode". The modifications you
>> did
>> >>> in
>> >>> > camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave
>> me a
>> >>> lot
>> >>> > of problems due to the changs in Camel's OSGi support. Willem has
>> helped
>> >>> me
>> >>> > to sort them out and I've now gone back to the original ftps secure
>> data
>> >>> > channel subject.
>> >>> >
>> >>> > NOTE, if you've read my last post in the thread "camel-ftp problems
>> with
>> >>> > ftps implicit mode" I had missed the first line of the exception
>> >>> stacktrace
>> >>> > which I have corrected in this mail.
>> >>> >
>> >>> > I've now tested your ftps enhancement against Filezilla and Serv-U
>> and
>> >>> it
>> >>> > works. However, I noticed the following:
>> >>> >
>> >>> > If option "execPbsz" is not set then the PBSZ command is not sent at
>> >>> all.
>> >>> > The documentation says that default value is "0" which indicates
>> that
>> >>> PBSZ
>> >>> > is always sent. I think the behaviour is correct but the
>> documentation
>> >>> > should change and specify that "null" is the default value for
>> >>> "execPbsz".
>> >>> >
>> >>> > About the configuration, I still think that the configuration is a
>> bit
>> >>> > illogical. First of all, PBSZ and PROT commands are valid even
>> though a
>> >>> > secure data channel is not used. It might even be valid for purt ftp
>> >>> (not
>> >>> > ftps) as well - I'm not sure. Therefore, the execProt and execPbsz
>> >>> options
>> >>> > should take effect regardless of the value of the
>> useSecureDataChannel
>> >>> > option.
>> >>> >
>> >>> > Furthermore, I think the normal case should be default and require
>> very
>> >>> > little configuration. I therefore suggest the following:
>> >>> >
>> >>> > a) useSecureDataChannel should be true by default. This is due to
>> two
>> >>> > reasons:
>> >>> > 1. If ftp severs have requirements in this area, they tend to be
>> >>> > restrictive. Serv-U, for example require PROT P (secure data
>> channel).
>> >>> Clear
>> >>> > text is allowed if one explicitly sends PROT C but not if no PROT
>> >>> command is
>> >>> > sent at all.
>> >>> > 2. I think that if the default is clear text then many developers
>> will
>> >>> > send unencrypted content by mistake. I think that if you choose to
>> use
>> >>> ftps,
>> >>> > most developers assume that the data is encrypted. That's what I did
>> >>> anyway.
>> >>> >
>> >>> > b) If useSecureDataChannel is true, then this implies execPbsz=0 and
>> >>> > execProt=P without having to configure it explicitly.
>> >>> >
>> >>> > c) execPbsz and execProt options shall always take effect and shall
>> >>> override
>> >>> > the values implied by setting useSecureDataChannel to true. Normally
>> one
>> >>> > would not have to configure these options at all.
>> >>> >
>> >>> > One can argue that if we make PBSZ 0 and PROT P the default, then we
>> >>> could
>> >>> > skip the useSecureDataChannel and only have the execProt and
>> execPbsz
>> >>> > options. This would actually be OK since overriding the PBSZ 0 /
>> PROT P
>> >>> > options is an active decision by a developer who presumably knows
>> what
>> >>> s/he
>> >>> > is doing. This is OK with me but then it should also be possible to
>> >>> disable
>> >>> > sending of the PBSZ and PROT commands by explicitly setting those
>> >>> options to
>> >>> > the empty string.
>> >>> >
>> >>> > Maybe I'm writing too much in this thread now but I also found
>> another
>> >>> > problem: If something goes wrong, e g file already exists (Filezilla
>> >>> doesn't
>> >>> > permit overwrite) then I get the following exception on subsequent
>> >>> attempts.
>> >>> > I have to manually restart the route to get it to work.
>> >>> >
>> >>> > org.apache.camel.component.file.GenericFileOperationFailedException:
>> >>> File
>> >>> > operation failed: null Unconnected sockets not implemented. Code:
>> 221
>> >>> > at
>> >>> >
>> >>>
>> org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> >>> > at
>> >>> >
>> >>>
>> org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> >>> > at
>> >>> >
>> >>>
>> org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> >>> > at
>> >>> >
>> >>>
>> org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> >>> > at
>> >>> >
>> >>>
>> org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
>> >>> > at
>> >>> >
>> >>>
>> org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> >>> > ...
>> >>> >
>> >>> > I get the above exception regardless of the value of the
>> "disconnect"
>> >>> optin
>> >>> > in camel-ftp.
>> >>> >
>> >>> >
>> >>> > Best regards,
>> >>> >
>> >>> > /Bengt
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Claus Ibsen
>> >>> Apache Camel Committer
>> >>>
>> >>> Author of Camel in Action: http://www.manning.com/ibsen/
>> >>> Open Source Integration: http://fusesource.com
>> >>> Blog: http://davsclaus.blogspot.com/
>> >>> Twitter: http://twitter.com/davsclaus
>> >>>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>
>
Re: camel-ftp and ftps secure data channel
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks Claus!
Will test shortly (probably tomorrow),
/Bengt
2010/6/15 Claus Ibsen <cl...@gmail.com>
> On Tue, Jun 15, 2010 at 12:57 PM, Bengt Rodehav <be...@rodehav.com> wrote:
> > Claus,
> >
> > Just realised that I can stop both PSBZ and PROT to be sent by
> > specifying useSecureDataChannel=false. This means that it is possible to
> > tweak this every possible way. The only issue then would be the name of
> this
> > option. E g it's a bit illogical to specify:
> >
> > useSecureDataChannel=false
> > execProt=P
> >
> > as well as:
> >
> > useSecureDataChannel=true
> > execProt=C
> >
> > What the option "useSecureDataChannel" really does is setting default
> values
> > for execProt and execPbsz - maybe this should be reflected in the name.
> What
> > about renaming this option to "disableSecureDataChannelDefaults" (maybe a
> > bit long...). The meaning of its value would be the inverse of
> > "useSecureDataChannel" and its default value would be false.
> >
>
> Hi
>
> I have renamed that option. Yeah finding a good name for options is
> often harder than you would think.
> Fell free to test the latest source code on your systems.
>
>
> >
> > /Bengt
> >
> > 2010/6/15 Bengt Rodehav <be...@rodehav.com>
> >
> >> Claus,
> >>
> >> I've tested your new version and it works very good. However, I did not
> >> find a way to specify that the PSBZ command should not be sent at all. I
> >> have a feeling that one does not want to send it when explicitly
> specifying
> >> PROT C. I'm not sure but maybe we need a way of specifying the the PSBZ
> /
> >> PROT command should not be sent. Perhaps some reserved value like "-1"
> for
> >> execPbsz and "none" for execProt.
> >>
> >> One other question/suggestion. The default port for ftps in camel-ftp is
> >> 2222. I don't quite understand why. Both Filizilla and Serv-U use port
> 21
> >> (the normal ftp port) for explicit ftps and port 990 for implicit ftps.
> I
> >> have a feeling that this is standard practice. Would be nice if
> camel-ftp
> >> defaulted to that.
> >>
> >> Did you know anything about the exception I mentioned? (Unconnected
> >> sockets not implemented...)
> >>
> >>
> >> Best regards,
> >>
> >> /Bengt
> >>
> >>
> >> 2010/6/15 Claus Ibsen <cl...@gmail.com>
> >>
> >> Hi Bengt
> >>>
> >>> I have just committed a change on trunk. Can you test it on your
> system?
> >>> It now defaults have useSecureDataChannel as true. And that P and 0 is
> >>> used if not explicit configured.
> >>>
> >>>
> >>>
> >>> On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <be...@rodehav.com>
> wrote:
> >>> > Claus,
> >>> >
> >>> > I decided to create a new thred of conversation instead of reusing
> >>> > "camel-ftp problems with ftps implicit mode". The modifications you
> did
> >>> in
> >>> > camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave
> me a
> >>> lot
> >>> > of problems due to the changs in Camel's OSGi support. Willem has
> helped
> >>> me
> >>> > to sort them out and I've now gone back to the original ftps secure
> data
> >>> > channel subject.
> >>> >
> >>> > NOTE, if you've read my last post in the thread "camel-ftp problems
> with
> >>> > ftps implicit mode" I had missed the first line of the exception
> >>> stacktrace
> >>> > which I have corrected in this mail.
> >>> >
> >>> > I've now tested your ftps enhancement against Filezilla and Serv-U
> and
> >>> it
> >>> > works. However, I noticed the following:
> >>> >
> >>> > If option "execPbsz" is not set then the PBSZ command is not sent at
> >>> all.
> >>> > The documentation says that default value is "0" which indicates that
> >>> PBSZ
> >>> > is always sent. I think the behaviour is correct but the
> documentation
> >>> > should change and specify that "null" is the default value for
> >>> "execPbsz".
> >>> >
> >>> > About the configuration, I still think that the configuration is a
> bit
> >>> > illogical. First of all, PBSZ and PROT commands are valid even though
> a
> >>> > secure data channel is not used. It might even be valid for purt ftp
> >>> (not
> >>> > ftps) as well - I'm not sure. Therefore, the execProt and execPbsz
> >>> options
> >>> > should take effect regardless of the value of the
> useSecureDataChannel
> >>> > option.
> >>> >
> >>> > Furthermore, I think the normal case should be default and require
> very
> >>> > little configuration. I therefore suggest the following:
> >>> >
> >>> > a) useSecureDataChannel should be true by default. This is due to two
> >>> > reasons:
> >>> > 1. If ftp severs have requirements in this area, they tend to be
> >>> > restrictive. Serv-U, for example require PROT P (secure data
> channel).
> >>> Clear
> >>> > text is allowed if one explicitly sends PROT C but not if no PROT
> >>> command is
> >>> > sent at all.
> >>> > 2. I think that if the default is clear text then many developers
> will
> >>> > send unencrypted content by mistake. I think that if you choose to
> use
> >>> ftps,
> >>> > most developers assume that the data is encrypted. That's what I did
> >>> anyway.
> >>> >
> >>> > b) If useSecureDataChannel is true, then this implies execPbsz=0 and
> >>> > execProt=P without having to configure it explicitly.
> >>> >
> >>> > c) execPbsz and execProt options shall always take effect and shall
> >>> override
> >>> > the values implied by setting useSecureDataChannel to true. Normally
> one
> >>> > would not have to configure these options at all.
> >>> >
> >>> > One can argue that if we make PBSZ 0 and PROT P the default, then we
> >>> could
> >>> > skip the useSecureDataChannel and only have the execProt and execPbsz
> >>> > options. This would actually be OK since overriding the PBSZ 0 / PROT
> P
> >>> > options is an active decision by a developer who presumably knows
> what
> >>> s/he
> >>> > is doing. This is OK with me but then it should also be possible to
> >>> disable
> >>> > sending of the PBSZ and PROT commands by explicitly setting those
> >>> options to
> >>> > the empty string.
> >>> >
> >>> > Maybe I'm writing too much in this thread now but I also found
> another
> >>> > problem: If something goes wrong, e g file already exists (Filezilla
> >>> doesn't
> >>> > permit overwrite) then I get the following exception on subsequent
> >>> attempts.
> >>> > I have to manually restart the route to get it to work.
> >>> >
> >>> > org.apache.camel.component.file.GenericFileOperationFailedException:
> >>> File
> >>> > operation failed: null Unconnected sockets not implemented. Code: 221
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > ...
> >>> >
> >>> > I get the above exception regardless of the value of the "disconnect"
> >>> optin
> >>> > in camel-ftp.
> >>> >
> >>> >
> >>> > Best regards,
> >>> >
> >>> > /Bengt
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Claus Ibsen
> >>> Apache Camel Committer
> >>>
> >>> Author of Camel in Action: http://www.manning.com/ibsen/
> >>> Open Source Integration: http://fusesource.com
> >>> Blog: http://davsclaus.blogspot.com/
> >>> Twitter: http://twitter.com/davsclaus
> >>>
> >>
> >>
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
Re: camel-ftp and ftps secure data channel
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jun 15, 2010 at 12:57 PM, Bengt Rodehav <be...@rodehav.com> wrote:
> Claus,
>
> Just realised that I can stop both PSBZ and PROT to be sent by
> specifying useSecureDataChannel=false. This means that it is possible to
> tweak this every possible way. The only issue then would be the name of this
> option. E g it's a bit illogical to specify:
>
> useSecureDataChannel=false
> execProt=P
>
> as well as:
>
> useSecureDataChannel=true
> execProt=C
>
> What the option "useSecureDataChannel" really does is setting default values
> for execProt and execPbsz - maybe this should be reflected in the name. What
> about renaming this option to "disableSecureDataChannelDefaults" (maybe a
> bit long...). The meaning of its value would be the inverse of
> "useSecureDataChannel" and its default value would be false.
>
Hi
I have renamed that option. Yeah finding a good name for options is
often harder than you would think.
Fell free to test the latest source code on your systems.
>
> /Bengt
>
> 2010/6/15 Bengt Rodehav <be...@rodehav.com>
>
>> Claus,
>>
>> I've tested your new version and it works very good. However, I did not
>> find a way to specify that the PSBZ command should not be sent at all. I
>> have a feeling that one does not want to send it when explicitly specifying
>> PROT C. I'm not sure but maybe we need a way of specifying the the PSBZ /
>> PROT command should not be sent. Perhaps some reserved value like "-1" for
>> execPbsz and "none" for execProt.
>>
>> One other question/suggestion. The default port for ftps in camel-ftp is
>> 2222. I don't quite understand why. Both Filizilla and Serv-U use port 21
>> (the normal ftp port) for explicit ftps and port 990 for implicit ftps. I
>> have a feeling that this is standard practice. Would be nice if camel-ftp
>> defaulted to that.
>>
>> Did you know anything about the exception I mentioned? (Unconnected
>> sockets not implemented...)
>>
>>
>> Best regards,
>>
>> /Bengt
>>
>>
>> 2010/6/15 Claus Ibsen <cl...@gmail.com>
>>
>> Hi Bengt
>>>
>>> I have just committed a change on trunk. Can you test it on your system?
>>> It now defaults have useSecureDataChannel as true. And that P and 0 is
>>> used if not explicit configured.
>>>
>>>
>>>
>>> On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <be...@rodehav.com> wrote:
>>> > Claus,
>>> >
>>> > I decided to create a new thred of conversation instead of reusing
>>> > "camel-ftp problems with ftps implicit mode". The modifications you did
>>> in
>>> > camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave me a
>>> lot
>>> > of problems due to the changs in Camel's OSGi support. Willem has helped
>>> me
>>> > to sort them out and I've now gone back to the original ftps secure data
>>> > channel subject.
>>> >
>>> > NOTE, if you've read my last post in the thread "camel-ftp problems with
>>> > ftps implicit mode" I had missed the first line of the exception
>>> stacktrace
>>> > which I have corrected in this mail.
>>> >
>>> > I've now tested your ftps enhancement against Filezilla and Serv-U and
>>> it
>>> > works. However, I noticed the following:
>>> >
>>> > If option "execPbsz" is not set then the PBSZ command is not sent at
>>> all.
>>> > The documentation says that default value is "0" which indicates that
>>> PBSZ
>>> > is always sent. I think the behaviour is correct but the documentation
>>> > should change and specify that "null" is the default value for
>>> "execPbsz".
>>> >
>>> > About the configuration, I still think that the configuration is a bit
>>> > illogical. First of all, PBSZ and PROT commands are valid even though a
>>> > secure data channel is not used. It might even be valid for purt ftp
>>> (not
>>> > ftps) as well - I'm not sure. Therefore, the execProt and execPbsz
>>> options
>>> > should take effect regardless of the value of the useSecureDataChannel
>>> > option.
>>> >
>>> > Furthermore, I think the normal case should be default and require very
>>> > little configuration. I therefore suggest the following:
>>> >
>>> > a) useSecureDataChannel should be true by default. This is due to two
>>> > reasons:
>>> > 1. If ftp severs have requirements in this area, they tend to be
>>> > restrictive. Serv-U, for example require PROT P (secure data channel).
>>> Clear
>>> > text is allowed if one explicitly sends PROT C but not if no PROT
>>> command is
>>> > sent at all.
>>> > 2. I think that if the default is clear text then many developers will
>>> > send unencrypted content by mistake. I think that if you choose to use
>>> ftps,
>>> > most developers assume that the data is encrypted. That's what I did
>>> anyway.
>>> >
>>> > b) If useSecureDataChannel is true, then this implies execPbsz=0 and
>>> > execProt=P without having to configure it explicitly.
>>> >
>>> > c) execPbsz and execProt options shall always take effect and shall
>>> override
>>> > the values implied by setting useSecureDataChannel to true. Normally one
>>> > would not have to configure these options at all.
>>> >
>>> > One can argue that if we make PBSZ 0 and PROT P the default, then we
>>> could
>>> > skip the useSecureDataChannel and only have the execProt and execPbsz
>>> > options. This would actually be OK since overriding the PBSZ 0 / PROT P
>>> > options is an active decision by a developer who presumably knows what
>>> s/he
>>> > is doing. This is OK with me but then it should also be possible to
>>> disable
>>> > sending of the PBSZ and PROT commands by explicitly setting those
>>> options to
>>> > the empty string.
>>> >
>>> > Maybe I'm writing too much in this thread now but I also found another
>>> > problem: If something goes wrong, e g file already exists (Filezilla
>>> doesn't
>>> > permit overwrite) then I get the following exception on subsequent
>>> attempts.
>>> > I have to manually restart the route to get it to work.
>>> >
>>> > org.apache.camel.component.file.GenericFileOperationFailedException:
>>> File
>>> > operation failed: null Unconnected sockets not implemented. Code: 221
>>> > at
>>> >
>>> org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> > at
>>> >
>>> org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> > at
>>> >
>>> org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> > at
>>> >
>>> org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> > at
>>> >
>>> org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
>>> > at
>>> >
>>> org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>>> > ...
>>> >
>>> > I get the above exception regardless of the value of the "disconnect"
>>> optin
>>> > in camel-ftp.
>>> >
>>> >
>>> > Best regards,
>>> >
>>> > /Bengt
>>> >
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>
>>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: camel-ftp and ftps secure data channel
Posted by Bengt Rodehav <be...@rodehav.com>.
Claus,
Just realised that I can stop both PSBZ and PROT to be sent by
specifying useSecureDataChannel=false. This means that it is possible to
tweak this every possible way. The only issue then would be the name of this
option. E g it's a bit illogical to specify:
useSecureDataChannel=false
execProt=P
as well as:
useSecureDataChannel=true
execProt=C
What the option "useSecureDataChannel" really does is setting default values
for execProt and execPbsz - maybe this should be reflected in the name. What
about renaming this option to "disableSecureDataChannelDefaults" (maybe a
bit long...). The meaning of its value would be the inverse of
"useSecureDataChannel" and its default value would be false.
/Bengt
2010/6/15 Bengt Rodehav <be...@rodehav.com>
> Claus,
>
> I've tested your new version and it works very good. However, I did not
> find a way to specify that the PSBZ command should not be sent at all. I
> have a feeling that one does not want to send it when explicitly specifying
> PROT C. I'm not sure but maybe we need a way of specifying the the PSBZ /
> PROT command should not be sent. Perhaps some reserved value like "-1" for
> execPbsz and "none" for execProt.
>
> One other question/suggestion. The default port for ftps in camel-ftp is
> 2222. I don't quite understand why. Both Filizilla and Serv-U use port 21
> (the normal ftp port) for explicit ftps and port 990 for implicit ftps. I
> have a feeling that this is standard practice. Would be nice if camel-ftp
> defaulted to that.
>
> Did you know anything about the exception I mentioned? (Unconnected
> sockets not implemented...)
>
>
> Best regards,
>
> /Bengt
>
>
> 2010/6/15 Claus Ibsen <cl...@gmail.com>
>
> Hi Bengt
>>
>> I have just committed a change on trunk. Can you test it on your system?
>> It now defaults have useSecureDataChannel as true. And that P and 0 is
>> used if not explicit configured.
>>
>>
>>
>> On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <be...@rodehav.com> wrote:
>> > Claus,
>> >
>> > I decided to create a new thred of conversation instead of reusing
>> > "camel-ftp problems with ftps implicit mode". The modifications you did
>> in
>> > camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave me a
>> lot
>> > of problems due to the changs in Camel's OSGi support. Willem has helped
>> me
>> > to sort them out and I've now gone back to the original ftps secure data
>> > channel subject.
>> >
>> > NOTE, if you've read my last post in the thread "camel-ftp problems with
>> > ftps implicit mode" I had missed the first line of the exception
>> stacktrace
>> > which I have corrected in this mail.
>> >
>> > I've now tested your ftps enhancement against Filezilla and Serv-U and
>> it
>> > works. However, I noticed the following:
>> >
>> > If option "execPbsz" is not set then the PBSZ command is not sent at
>> all.
>> > The documentation says that default value is "0" which indicates that
>> PBSZ
>> > is always sent. I think the behaviour is correct but the documentation
>> > should change and specify that "null" is the default value for
>> "execPbsz".
>> >
>> > About the configuration, I still think that the configuration is a bit
>> > illogical. First of all, PBSZ and PROT commands are valid even though a
>> > secure data channel is not used. It might even be valid for purt ftp
>> (not
>> > ftps) as well - I'm not sure. Therefore, the execProt and execPbsz
>> options
>> > should take effect regardless of the value of the useSecureDataChannel
>> > option.
>> >
>> > Furthermore, I think the normal case should be default and require very
>> > little configuration. I therefore suggest the following:
>> >
>> > a) useSecureDataChannel should be true by default. This is due to two
>> > reasons:
>> > 1. If ftp severs have requirements in this area, they tend to be
>> > restrictive. Serv-U, for example require PROT P (secure data channel).
>> Clear
>> > text is allowed if one explicitly sends PROT C but not if no PROT
>> command is
>> > sent at all.
>> > 2. I think that if the default is clear text then many developers will
>> > send unencrypted content by mistake. I think that if you choose to use
>> ftps,
>> > most developers assume that the data is encrypted. That's what I did
>> anyway.
>> >
>> > b) If useSecureDataChannel is true, then this implies execPbsz=0 and
>> > execProt=P without having to configure it explicitly.
>> >
>> > c) execPbsz and execProt options shall always take effect and shall
>> override
>> > the values implied by setting useSecureDataChannel to true. Normally one
>> > would not have to configure these options at all.
>> >
>> > One can argue that if we make PBSZ 0 and PROT P the default, then we
>> could
>> > skip the useSecureDataChannel and only have the execProt and execPbsz
>> > options. This would actually be OK since overriding the PBSZ 0 / PROT P
>> > options is an active decision by a developer who presumably knows what
>> s/he
>> > is doing. This is OK with me but then it should also be possible to
>> disable
>> > sending of the PBSZ and PROT commands by explicitly setting those
>> options to
>> > the empty string.
>> >
>> > Maybe I'm writing too much in this thread now but I also found another
>> > problem: If something goes wrong, e g file already exists (Filezilla
>> doesn't
>> > permit overwrite) then I get the following exception on subsequent
>> attempts.
>> > I have to manually restart the route to get it to work.
>> >
>> > org.apache.camel.component.file.GenericFileOperationFailedException:
>> File
>> > operation failed: null Unconnected sockets not implemented. Code: 221
>> > at
>> >
>> org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> > at
>> >
>> org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> > at
>> >
>> org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> > at
>> >
>> org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> > at
>> >
>> org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
>> > at
>> >
>> org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
>> > ...
>> >
>> > I get the above exception regardless of the value of the "disconnect"
>> optin
>> > in camel-ftp.
>> >
>> >
>> > Best regards,
>> >
>> > /Bengt
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>
>
Re: camel-ftp and ftps secure data channel
Posted by Bengt Rodehav <be...@rodehav.com>.
Claus,
I've tested your new version and it works very good. However, I did not find
a way to specify that the PSBZ command should not be sent at all. I have a
feeling that one does not want to send it when explicitly specifying PROT C.
I'm not sure but maybe we need a way of specifying the the PSBZ / PROT
command should not be sent. Perhaps some reserved value like "-1" for
execPbsz and "none" for execProt.
One other question/suggestion. The default port for ftps in camel-ftp is
2222. I don't quite understand why. Both Filizilla and Serv-U use port 21
(the normal ftp port) for explicit ftps and port 990 for implicit ftps. I
have a feeling that this is standard practice. Would be nice if camel-ftp
defaulted to that.
Did you know anything about the exception I mentioned? (Unconnected sockets
not implemented...)
Best regards,
/Bengt
2010/6/15 Claus Ibsen <cl...@gmail.com>
> Hi Bengt
>
> I have just committed a change on trunk. Can you test it on your system?
> It now defaults have useSecureDataChannel as true. And that P and 0 is
> used if not explicit configured.
>
>
>
> On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> > Claus,
> >
> > I decided to create a new thred of conversation instead of reusing
> > "camel-ftp problems with ftps implicit mode". The modifications you did
> in
> > camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave me a
> lot
> > of problems due to the changs in Camel's OSGi support. Willem has helped
> me
> > to sort them out and I've now gone back to the original ftps secure data
> > channel subject.
> >
> > NOTE, if you've read my last post in the thread "camel-ftp problems with
> > ftps implicit mode" I had missed the first line of the exception
> stacktrace
> > which I have corrected in this mail.
> >
> > I've now tested your ftps enhancement against Filezilla and Serv-U and it
> > works. However, I noticed the following:
> >
> > If option "execPbsz" is not set then the PBSZ command is not sent at all.
> > The documentation says that default value is "0" which indicates that
> PBSZ
> > is always sent. I think the behaviour is correct but the documentation
> > should change and specify that "null" is the default value for
> "execPbsz".
> >
> > About the configuration, I still think that the configuration is a bit
> > illogical. First of all, PBSZ and PROT commands are valid even though a
> > secure data channel is not used. It might even be valid for purt ftp (not
> > ftps) as well - I'm not sure. Therefore, the execProt and execPbsz
> options
> > should take effect regardless of the value of the useSecureDataChannel
> > option.
> >
> > Furthermore, I think the normal case should be default and require very
> > little configuration. I therefore suggest the following:
> >
> > a) useSecureDataChannel should be true by default. This is due to two
> > reasons:
> > 1. If ftp severs have requirements in this area, they tend to be
> > restrictive. Serv-U, for example require PROT P (secure data channel).
> Clear
> > text is allowed if one explicitly sends PROT C but not if no PROT command
> is
> > sent at all.
> > 2. I think that if the default is clear text then many developers will
> > send unencrypted content by mistake. I think that if you choose to use
> ftps,
> > most developers assume that the data is encrypted. That's what I did
> anyway.
> >
> > b) If useSecureDataChannel is true, then this implies execPbsz=0 and
> > execProt=P without having to configure it explicitly.
> >
> > c) execPbsz and execProt options shall always take effect and shall
> override
> > the values implied by setting useSecureDataChannel to true. Normally one
> > would not have to configure these options at all.
> >
> > One can argue that if we make PBSZ 0 and PROT P the default, then we
> could
> > skip the useSecureDataChannel and only have the execProt and execPbsz
> > options. This would actually be OK since overriding the PBSZ 0 / PROT P
> > options is an active decision by a developer who presumably knows what
> s/he
> > is doing. This is OK with me but then it should also be possible to
> disable
> > sending of the PBSZ and PROT commands by explicitly setting those options
> to
> > the empty string.
> >
> > Maybe I'm writing too much in this thread now but I also found another
> > problem: If something goes wrong, e g file already exists (Filezilla
> doesn't
> > permit overwrite) then I get the following exception on subsequent
> attempts.
> > I have to manually restart the route to get it to work.
> >
> > org.apache.camel.component.file.GenericFileOperationFailedException: File
> > operation failed: null Unconnected sockets not implemented. Code: 221
> > at
> >
> org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> > at
> >
> org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> > at
> >
> org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> > at
> >
> org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> > at
> >
> org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
> > at
> >
> org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> > ...
> >
> > I get the above exception regardless of the value of the "disconnect"
> optin
> > in camel-ftp.
> >
> >
> > Best regards,
> >
> > /Bengt
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
Re: camel-ftp and ftps secure data channel
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Bengt
I have just committed a change on trunk. Can you test it on your system?
It now defaults have useSecureDataChannel as true. And that P and 0 is
used if not explicit configured.
On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> Claus,
>
> I decided to create a new thred of conversation instead of reusing
> "camel-ftp problems with ftps implicit mode". The modifications you did in
> camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave me a lot
> of problems due to the changs in Camel's OSGi support. Willem has helped me
> to sort them out and I've now gone back to the original ftps secure data
> channel subject.
>
> NOTE, if you've read my last post in the thread "camel-ftp problems with
> ftps implicit mode" I had missed the first line of the exception stacktrace
> which I have corrected in this mail.
>
> I've now tested your ftps enhancement against Filezilla and Serv-U and it
> works. However, I noticed the following:
>
> If option "execPbsz" is not set then the PBSZ command is not sent at all.
> The documentation says that default value is "0" which indicates that PBSZ
> is always sent. I think the behaviour is correct but the documentation
> should change and specify that "null" is the default value for "execPbsz".
>
> About the configuration, I still think that the configuration is a bit
> illogical. First of all, PBSZ and PROT commands are valid even though a
> secure data channel is not used. It might even be valid for purt ftp (not
> ftps) as well - I'm not sure. Therefore, the execProt and execPbsz options
> should take effect regardless of the value of the useSecureDataChannel
> option.
>
> Furthermore, I think the normal case should be default and require very
> little configuration. I therefore suggest the following:
>
> a) useSecureDataChannel should be true by default. This is due to two
> reasons:
> 1. If ftp severs have requirements in this area, they tend to be
> restrictive. Serv-U, for example require PROT P (secure data channel). Clear
> text is allowed if one explicitly sends PROT C but not if no PROT command is
> sent at all.
> 2. I think that if the default is clear text then many developers will
> send unencrypted content by mistake. I think that if you choose to use ftps,
> most developers assume that the data is encrypted. That's what I did anyway.
>
> b) If useSecureDataChannel is true, then this implies execPbsz=0 and
> execProt=P without having to configure it explicitly.
>
> c) execPbsz and execProt options shall always take effect and shall override
> the values implied by setting useSecureDataChannel to true. Normally one
> would not have to configure these options at all.
>
> One can argue that if we make PBSZ 0 and PROT P the default, then we could
> skip the useSecureDataChannel and only have the execProt and execPbsz
> options. This would actually be OK since overriding the PBSZ 0 / PROT P
> options is an active decision by a developer who presumably knows what s/he
> is doing. This is OK with me but then it should also be possible to disable
> sending of the PBSZ and PROT commands by explicitly setting those options to
> the empty string.
>
> Maybe I'm writing too much in this thread now but I also found another
> problem: If something goes wrong, e g file already exists (Filezilla doesn't
> permit overwrite) then I get the following exception on subsequent attempts.
> I have to manually restart the route to get it to work.
>
> org.apache.camel.component.file.GenericFileOperationFailedException: File
> operation failed: null Unconnected sockets not implemented. Code: 221
> at
> org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> at
> org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> at
> org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> at
> org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> at
> org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
> at
> org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> ...
>
> I get the above exception regardless of the value of the "disconnect" optin
> in camel-ftp.
>
>
> Best regards,
>
> /Bengt
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus