[Geoserver-devel] Proposing new community module: embedded ftp server

Hi,
I need an easy to set up FTP server for GeoServer
so that remote admins can upload data.

Alessio some time ago pointed me at Apache Mina FtpServer,
and this tutorial shows how to create an embedded FTP
server the easy way:
http://mina.apache.org/ftpserver/embedding-ftpserver-in-5-minutes.html

GeoSolutions actually added that into GeoBatch already.
Alessio, Simone, is it working fine for you?

I guess this would be a contribution of general interest.
Yes, setting up a stand alone FTP server for the same purpose
is not hard, but requires deciding which one you want to use
platform per platform, configuring it, creating the necessary
users (a separate set from GeoServer own users), and making
sure the files created by the server can be read
(and eventually written) by GeoServer.

The idea of the embedded module is that you drop it in and
it just start serving the data directory contents to all
the GS users that have administration powers (since you need
to be able to configure the data afterwards anyways).
Basically a no options easy install that gets you going
in 5 minutes.

Given it's a full fledged FTP server we also get much better
service than just file upload in forms, for example, no
limit on file sizes, restartable services, easy multiple uploads,
and a ton of existing clients on various platforms that
can access it directly.

So, opinions?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

+1

That is very cool Andrea. Indeed if FTP is starting to be a staging area for WFS results then it makes a lot of sense as well.

jody

On 01/06/2010, at 2:04 AM, Andrea Aime wrote:

Hi,
I need an easy to set up FTP server for GeoServer
so that remote admins can upload data.

Alessio some time ago pointed me at Apache Mina FtpServer,
and this tutorial shows how to create an embedded FTP
server the easy way:
http://mina.apache.org/ftpserver/embedding-ftpserver-in-5-minutes.html

GeoSolutions actually added that into GeoBatch already.
Alessio, Simone, is it working fine for you?

I guess this would be a contribution of general interest.
Yes, setting up a stand alone FTP server for the same purpose
is not hard, but requires deciding which one you want to use
platform per platform, configuring it, creating the necessary
users (a separate set from GeoServer own users), and making
sure the files created by the server can be read
(and eventually written) by GeoServer.

The idea of the embedded module is that you drop it in and
it just start serving the data directory contents to all
the GS users that have administration powers (since you need
to be able to configure the data afterwards anyways).
Basically a no options easy install that gets you going
in 5 minutes.

Given it's a full fledged FTP server we also get much better
service than just file upload in forms, for example, no
limit on file sizes, restartable services, easy multiple uploads,
and a ton of existing clients on various platforms that
can access it directly.

So, opinions?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

+1

also, my vote does not count

2010/6/1 Jody Garnett <jody.garnett@anonymised.com>

+1

That is very cool Andrea. Indeed if FTP is starting to be a staging area for WFS results then it makes a lot of sense as well.

jody

On 01/06/2010, at 2:04 AM, Andrea Aime wrote:

Hi,
I need an easy to set up FTP server for GeoServer
so that remote admins can upload data.

Alessio some time ago pointed me at Apache Mina FtpServer,
and this tutorial shows how to create an embedded FTP
server the easy way:
http://mina.apache.org/ftpserver/embedding-ftpserver-in-5-minutes.html

GeoSolutions actually added that into GeoBatch already.
Alessio, Simone, is it working fine for you?

I guess this would be a contribution of general interest.
Yes, setting up a stand alone FTP server for the same purpose
is not hard, but requires deciding which one you want to use
platform per platform, configuring it, creating the necessary
users (a separate set from GeoServer own users), and making
sure the files created by the server can be read
(and eventually written) by GeoServer.

The idea of the embedded module is that you drop it in and
it just start serving the data directory contents to all
the GS users that have administration powers (since you need
to be able to configure the data afterwards anyways).
Basically a no options easy install that gets you going
in 5 minutes.

Given it’s a full fledged FTP server we also get much better
service than just file upload in forms, for example, no
limit on file sizes, restartable services, easy multiple uploads,
and a ton of existing clients on various platforms that
can access it directly.

So, opinions?

Cheers
Andrea


Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Francesco Izzi
CNR - IMAA
geoSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3203126609
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

I like the idea, and I think FTP is probably the way to go given Microsofts propensity to break WebDAV.

But by default GeoServer ships with a small security problem in the sense that the admin password is universally known. I prefer Tomcat's approach in which no account enabled by default, but this has not been a big issue up to this point.

But if we include an FTP server then GeoServer suddenly becomes a valuable target for people who want to distribute illegal materials.

I therefore suggest that it should not be possible to login with the standard credentials, and if possible tell the FTP client the reason for the rejection in the Access Denied response.

Moving the service to a different port does not really help in this regard, it's easy to run SYN scans against large networks, and a custom port makes it easier to identify the software and possible credentials to try.

-Arne

On 05/31/2010 06:04 PM, Andrea Aime wrote:

Hi,
I need an easy to set up FTP server for GeoServer
so that remote admins can upload data.

Alessio some time ago pointed me at Apache Mina FtpServer,
and this tutorial shows how to create an embedded FTP
server the easy way:
http://mina.apache.org/ftpserver/embedding-ftpserver-in-5-minutes.html

GeoSolutions actually added that into GeoBatch already.
Alessio, Simone, is it working fine for you?

I guess this would be a contribution of general interest.
Yes, setting up a stand alone FTP server for the same purpose
is not hard, but requires deciding which one you want to use
platform per platform, configuring it, creating the necessary
users (a separate set from GeoServer own users), and making
sure the files created by the server can be read
(and eventually written) by GeoServer.

The idea of the embedded module is that you drop it in and
it just start serving the data directory contents to all
the GS users that have administration powers (since you need
to be able to configure the data afterwards anyways).
Basically a no options easy install that gets you going
in 5 minutes.

Given it's a full fledged FTP server we also get much better
service than just file upload in forms, for example, no
limit on file sizes, restartable services, easy multiple uploads,
and a ton of existing clients on various platforms that
can access it directly.

So, opinions?

Cheers
Andrea

+1

Perhaps possible to have something that only enables the service when
a default admin is replaced with strong password? its convenient for
developers, but no real service should allow a weak password on a well
known account name.

On Tue, Jun 1, 2010 at 3:07 AM, Arne Kepp <arne@anonymised.com> wrote:

I like the idea, and I think FTP is probably the way to go given
Microsofts propensity to break WebDAV.

But by default GeoServer ships with a small security problem in the
sense that the admin password is universally known. I prefer Tomcat's
approach in which no account enabled by default, but this has not been a
big issue up to this point.

But if we include an FTP server then GeoServer suddenly becomes a
valuable target for people who want to distribute illegal materials.

I therefore suggest that it should not be possible to login with the
standard credentials, and if possible tell the FTP client the reason for
the rejection in the Access Denied response.

Moving the service to a different port does not really help in this
regard, it's easy to run SYN scans against large networks, and a custom
port makes it easier to identify the software and possible credentials
to try.

-Arne

On 05/31/2010 06:04 PM, Andrea Aime wrote:

Hi,
I need an easy to set up FTP server for GeoServer
so that remote admins can upload data.

Alessio some time ago pointed me at Apache Mina FtpServer,
and this tutorial shows how to create an embedded FTP
server the easy way:
http://mina.apache.org/ftpserver/embedding-ftpserver-in-5-minutes.html

GeoSolutions actually added that into GeoBatch already.
Alessio, Simone, is it working fine for you?

I guess this would be a contribution of general interest.
Yes, setting up a stand alone FTP server for the same purpose
is not hard, but requires deciding which one you want to use
platform per platform, configuring it, creating the necessary
users (a separate set from GeoServer own users), and making
sure the files created by the server can be read
(and eventually written) by GeoServer.

The idea of the embedded module is that you drop it in and
it just start serving the data directory contents to all
the GS users that have administration powers (since you need
to be able to configure the data afterwards anyways).
Basically a no options easy install that gets you going
in 5 minutes.

Given it's a full fledged FTP server we also get much better
service than just file upload in forms, for example, no
limit on file sizes, restartable services, easy multiple uploads,
and a ton of existing clients on various platforms that
can access it directly.

So, opinions?

Cheers
Andrea

------------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

+1

Perhaps possible to have something that only enables the service when
a default admin is replaced with strong password? its convenient for
developers, but no real service should allow a weak password on a well
known account name.

On Tue, Jun 1, 2010 at 3:07 AM, Arne Kepp <arne@anonymised.com> wrote:

I like the idea, and I think FTP is probably the way to go given
Microsofts propensity to break WebDAV.

But by default GeoServer ships with a small security problem in the
sense that the admin password is universally known. I prefer Tomcat's
approach in which no account enabled by default, but this has not been a
big issue up to this point.

But if we include an FTP server then GeoServer suddenly becomes a
valuable target for people who want to distribute illegal materials.

I therefore suggest that it should not be possible to login with the
standard credentials, and if possible tell the FTP client the reason for
the rejection in the Access Denied response.

Moving the service to a different port does not really help in this
regard, it's easy to run SYN scans against large networks, and a custom
port makes it easier to identify the software and possible credentials
to try.

-Arne

On 05/31/2010 06:04 PM, Andrea Aime wrote:

Hi,
I need an easy to set up FTP server for GeoServer
so that remote admins can upload data.

Alessio some time ago pointed me at Apache Mina FtpServer,
and this tutorial shows how to create an embedded FTP
server the easy way:
http://mina.apache.org/ftpserver/embedding-ftpserver-in-5-minutes.html

GeoSolutions actually added that into GeoBatch already.
Alessio, Simone, is it working fine for you?

I guess this would be a contribution of general interest.
Yes, setting up a stand alone FTP server for the same purpose
is not hard, but requires deciding which one you want to use
platform per platform, configuring it, creating the necessary
users (a separate set from GeoServer own users), and making
sure the files created by the server can be read
(and eventually written) by GeoServer.

The idea of the embedded module is that you drop it in and
it just start serving the data directory contents to all
the GS users that have administration powers (since you need
to be able to configure the data afterwards anyways).
Basically a no options easy install that gets you going
in 5 minutes.

Given it's a full fledged FTP server we also get much better
service than just file upload in forms, for example, no
limit on file sizes, restartable services, easy multiple uploads,
and a ton of existing clients on various platforms that
can access it directly.

So, opinions?

Cheers
Andrea

------------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Rob Atkinson ha scritto:

+1

Perhaps possible to have something that only enables the service when
a default admin is replaced with strong password? its convenient for
developers, but no real service should allow a weak password on a well
known account name.

That is going a bit overboard imho, especially considering future
enhancements where GS takes username/passwords from a database, or
does not even get to see the password to start with.

Showing a password strength can be a nice addition to the GUI
for managing users though (I mean, in general, regardless of the
FTP module)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Arne Kepp ha scritto:

I like the idea, and I think FTP is probably the way to go given Microsofts propensity to break WebDAV.

But by default GeoServer ships with a small security problem in the sense that the admin password is universally known. I prefer Tomcat's approach in which no account enabled by default, but this has not been a big issue up to this point.

But if we include an FTP server then GeoServer suddenly becomes a valuable target for people who want to distribute illegal materials.

I therefore suggest that it should not be possible to login with the standard credentials, and if possible tell the FTP client the reason for the rejection in the Access Denied response.

Sigh, unfortunately it does not seem possible to control the access
denied response.
This might be a source of some confusion as people are not notified
of why the thing is failing.

We can still address this by documentation, or just allow logins
by prominently report the issue in the logs...

Suggestions?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Ship with FTP disabled, and when an admin enables it, have some sort of account creation wizard enforcing best practices?

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

On 6/1/2010 11:05 AM, Andrea Aime wrote:

Arne Kepp ha scritto:

I like the idea, and I think FTP is probably the way to go given
Microsofts propensity to break WebDAV.

But by default GeoServer ships with a small security problem in the
sense that the admin password is universally known. I prefer Tomcat's
approach in which no account enabled by default, but this has not been a
big issue up to this point.

But if we include an FTP server then GeoServer suddenly becomes a
valuable target for people who want to distribute illegal materials.

I therefore suggest that it should not be possible to login with the
standard credentials, and if possible tell the FTP client the reason for
the rejection in the Access Denied response.

Sigh, unfortunately it does not seem possible to control the access
denied response.
This might be a source of some confusion as people are not notified
of why the thing is failing.

We can still address this by documentation, or just allow logins
by prominently report the issue in the logs...

Suggestions?

Cheers
Andrea