[Geoserver-devel] starting GeoServer live

Justin_Deoliveira · August 22, 2008, 2:35am

Hi all,

This is something that has been floating around in my head for quite some time and I wanted to throw some ideas out and see what people think of them.

So the use case here is be able to run GeoServer "live", that is straight off a CD or a USB stick. The problem is however that, as many know, GeoServer needs write access to be able to run. Now with a USB stick with enough space on it this is not an issue, but after a recent bad experience with USB sticks in labs, not having a CD to fall back on is suicide in my opinion :).

To find the instances I started GeoServer with an unwritable data directory and it blew up with issues related to logging, writable file checks, data like shapefiles locking and writing out index files, and more.

Past startup there is also the obvious fact that without a writable data directory there would be no ability to save any changes made via the web ui. Not ideal in a workshop situation.

So... my thought about the easiest way to get around this situation would be to somehow tell GeoServer to use the temporary O/S space, or use the users home directory for the data dir.

My first thought on how to do this is to use "special" values for the GEOSERVER_DATA_DIR parameter. Something like:

-DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]

Then the GeoServerDataDirectory.init() method would recognize these values and set the data directory path accordingly.

So continuing on with this, what about content inside the data directory? If you start geoserver with an "empty" data directory it still chokes. So my thought was to have GeoServerDataDirectory.init() not only set the path based on the special values, but also initialize the directory structure (only on the first run of course).

It seems logical to me to just use the minimal data directory in this case, which is just a skeleton catalog.xml and services.xml, and 4 sld files. However... in a workshop situation this is also not ideal, since we are going to want people to have a data directory which has been pre-configured.

So my thought to get around this would be to support an additional startup parameter, called something like "GEOSERVER_DATA_DIR_TEMPLATE". The value of the parameter is a path to a data directory... however instead of using that path directly, the behavior is instead to copy the contents of it to temporary O/S space / home directory. So startup would look something like:

-DGEOSERVER_DATA_DIR=[TMP] -DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir

End of rant. Feedback welcome :).

-JD

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

Rob_Atkinson1 · August 22, 2008, 2:48am

What about allowing the logging to be separated from the config?
Logging is a different issue than configuration for a production
system, and its very unusual not to have a separate location.

It would be nice to have a load location and a write location for the
config - this is the template idea you have, but all you do is change
the data dir to the [save] location if you want to save a modified
config. on startup it could just check - if the [save] directory
exists ignore the [load] location.

And, for the icing on the cake, it would be nice on startup, if these
parameters are not defined, to allow the config of these via the UI.
challenge i guess is saving these settings somewhere sensible.

Rob

On Fri, Aug 22, 2008 at 12:35 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Hi all,

This is something that has been floating around in my head for quite
some time and I wanted to throw some ideas out and see what people think
of them.

So the use case here is be able to run GeoServer "live", that is
straight off a CD or a USB stick. The problem is however that, as many
know, GeoServer needs write access to be able to run. Now with a USB
stick with enough space on it this is not an issue, but after a recent
bad experience with USB sticks in labs, not having a CD to fall back on
is suicide in my opinion :).

To find the instances I started GeoServer with an unwritable data
directory and it blew up with issues related to logging, writable file
checks, data like shapefiles locking and writing out index files, and more.

Past startup there is also the obvious fact that without a writable data
directory there would be no ability to save any changes made via the web
ui. Not ideal in a workshop situation.

So... my thought about the easiest way to get around this situation
would be to somehow tell GeoServer to use the temporary O/S space, or
use the users home directory for the data dir.

My first thought on how to do this is to use "special" values for the
GEOSERVER_DATA_DIR parameter. Something like:

-DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]

Then the GeoServerDataDirectory.init() method would recognize these
values and set the data directory path accordingly.

So continuing on with this, what about content inside the data
directory? If you start geoserver with an "empty" data directory it
still chokes. So my thought was to have GeoServerDataDirectory.init()
not only set the path based on the special values, but also initialize
the directory structure (only on the first run of course).

It seems logical to me to just use the minimal data directory in this
case, which is just a skeleton catalog.xml and services.xml, and 4 sld
files. However... in a workshop situation this is also not ideal, since
we are going to want people to have a data directory which has been
pre-configured.

So my thought to get around this would be to support an additional
startup parameter, called something like "GEOSERVER_DATA_DIR_TEMPLATE".
The value of the parameter is a path to a data directory... however
instead of using that path directly, the behavior is instead to copy the
contents of it to temporary O/S space / home directory. So startup would
look something like:

-DGEOSERVER_DATA_DIR=[TMP]
-DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir

End of rant. Feedback welcome :).

-JD

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

David_Winslow · August 22, 2008, 2:55am

It seems to me that the best setup for a workshop situation would be a bootable CD; pop it in, reboot the system, and you have a GeoServer setup ready to go, with whatever customizations needed in something that looks like a writable filesystem (but resets to known-good with just another reboot.) You can even throw in whatever clients and other tools you think might come in handy for the tutorial and not worry about whether they have made accommodations for running live as well.

That said, I'm sure there are situations where a read-only GeoServer makes sense. Looking over your proposal, I see you are suggesting we respect a special flag value for GEOSERVER_DATA_DIR that indicates 'read-only filesystem access' and add another environment variable to specify where to load the data from. Since we are adding an environment variable anyway, does it make more sense to leave the DATA_DIR variable as specifying the data directory and add a GEOSERVER_READ_ONLY flag? That is,
-DGEOSERVER_DATA_DIR=/path/to/data -DGEOSERVER_READ_ONLY
instead of
-DGEOSERVER_DATA_DIR=[TMP] -DGEOSERVER_DATA_DIR_TEMPLATE=/path/to/data

This also avoids the possibility for users to enter a valid datadir path for both fields, which seems like a potentially confusing aspect of the original proposal.

With the tutorial use-case in mind, it would probably be useful to have these set up in a configuration file (probably web.xml) instead of required as command-line args on every startup; I presume this is implied but just wanted to mention it.

-David

Justin Deoliveira wrote:

Hi all,

This is something that has been floating around in my head for quite some time and I wanted to throw some ideas out and see what people think of them.

So the use case here is be able to run GeoServer "live", that is straight off a CD or a USB stick. The problem is however that, as many know, GeoServer needs write access to be able to run. Now with a USB stick with enough space on it this is not an issue, but after a recent bad experience with USB sticks in labs, not having a CD to fall back on is suicide in my opinion :).

To find the instances I started GeoServer with an unwritable data directory and it blew up with issues related to logging, writable file checks, data like shapefiles locking and writing out index files, and more.

Past startup there is also the obvious fact that without a writable data directory there would be no ability to save any changes made via the web ui. Not ideal in a workshop situation.

So... my thought about the easiest way to get around this situation would be to somehow tell GeoServer to use the temporary O/S space, or use the users home directory for the data dir.

My first thought on how to do this is to use "special" values for the GEOSERVER_DATA_DIR parameter. Something like:

-DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]

Then the GeoServerDataDirectory.init() method would recognize these values and set the data directory path accordingly.

So continuing on with this, what about content inside the data directory? If you start geoserver with an "empty" data directory it still chokes. So my thought was to have GeoServerDataDirectory.init() not only set the path based on the special values, but also initialize the directory structure (only on the first run of course).

It seems logical to me to just use the minimal data directory in this case, which is just a skeleton catalog.xml and services.xml, and 4 sld files. However... in a workshop situation this is also not ideal, since we are going to want people to have a data directory which has been pre-configured.

So my thought to get around this would be to support an additional startup parameter, called something like "GEOSERVER_DATA_DIR_TEMPLATE". The value of the parameter is a path to a data directory... however instead of using that path directly, the behavior is instead to copy the contents of it to temporary O/S space / home directory. So startup would look something like:

-DGEOSERVER_DATA_DIR=[TMP] -DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir

End of rant. Feedback welcome :).

-JD

Arne_Kepp · August 22, 2008, 2:59am

Most LiveCD's use something called UnionFS [1] that should fix this, essentially it makes a read-only filesystem act like a regular filesystem by copying changed files to RAM. If the machines have 1Gb or more, and we tell Java to user 256 to 512, we should be good.

I'd use https://help.ubuntu.com/community/LiveCD as the starting point, there's also a track for LiveCDPersistence which can use a USB stick for storage.

-Arne

1: http://www.filesystems.org/project-unionfs.html

Justin Deoliveira wrote:

Hi all,

This is something that has been floating around in my head for quite some time and I wanted to throw some ideas out and see what people think of them.

So the use case here is be able to run GeoServer "live", that is straight off a CD or a USB stick. The problem is however that, as many know, GeoServer needs write access to be able to run. Now with a USB stick with enough space on it this is not an issue, but after a recent bad experience with USB sticks in labs, not having a CD to fall back on is suicide in my opinion :).

To find the instances I started GeoServer with an unwritable data directory and it blew up with issues related to logging, writable file checks, data like shapefiles locking and writing out index files, and more.

Past startup there is also the obvious fact that without a writable data directory there would be no ability to save any changes made via the web ui. Not ideal in a workshop situation.

So... my thought about the easiest way to get around this situation would be to somehow tell GeoServer to use the temporary O/S space, or use the users home directory for the data dir.

My first thought on how to do this is to use "special" values for the GEOSERVER_DATA_DIR parameter. Something like:

-DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]

Then the GeoServerDataDirectory.init() method would recognize these values and set the data directory path accordingly.

So continuing on with this, what about content inside the data directory? If you start geoserver with an "empty" data directory it still chokes. So my thought was to have GeoServerDataDirectory.init() not only set the path based on the special values, but also initialize the directory structure (only on the first run of course).

It seems logical to me to just use the minimal data directory in this case, which is just a skeleton catalog.xml and services.xml, and 4 sld files. However... in a workshop situation this is also not ideal, since we are going to want people to have a data directory which has been pre-configured.

So my thought to get around this would be to support an additional startup parameter, called something like "GEOSERVER_DATA_DIR_TEMPLATE". The value of the parameter is a path to a data directory... however instead of using that path directly, the behavior is instead to copy the contents of it to temporary O/S space / home directory. So startup would look something like:

-DGEOSERVER_DATA_DIR=[TMP] -DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir

End of rant. Feedback welcome :).

-JD

Stefan_Keller · August 22, 2008, 5:30am

Justin,

USB stick with enough space on it this is not an issue, but after a recent
bad experience with USB sticks in labs, not having a CD to fall back on
is suicide in my opinion :).

What was the problem with USB sticks?

-S.

2008/8/22 Justin Deoliveira <jdeolive@anonymised.com>

Hi all,

This is something that has been floating around in my head for quite
some time and I wanted to throw some ideas out and see what people think
of them.

So the use case here is be able to run GeoServer “live”, that is
straight off a CD or a USB stick. The problem is however that, as many
know, GeoServer needs write access to be able to run. Now with a USB
stick with enough space on it this is not an issue, but after a recent
bad experience with USB sticks in labs, not having a CD to fall back on
is suicide in my opinion :).

To find the instances I started GeoServer with an unwritable data
directory and it blew up with issues related to logging, writable file
checks, data like shapefiles locking and writing out index files, and more.

Past startup there is also the obvious fact that without a writable data
directory there would be no ability to save any changes made via the web
ui. Not ideal in a workshop situation.

So… my thought about the easiest way to get around this situation
would be to somehow tell GeoServer to use the temporary O/S space, or
use the users home directory for the data dir.

My first thought on how to do this is to use “special” values for the
GEOSERVER_DATA_DIR parameter. Something like:

-DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]

Then the GeoServerDataDirectory.init() method would recognize these
values and set the data directory path accordingly.

So continuing on with this, what about content inside the data
directory? If you start geoserver with an “empty” data directory it
still chokes. So my thought was to have GeoServerDataDirectory.init()
not only set the path based on the special values, but also initialize
the directory structure (only on the first run of course).

It seems logical to me to just use the minimal data directory in this
case, which is just a skeleton catalog.xml and services.xml, and 4 sld
files. However… in a workshop situation this is also not ideal, since
we are going to want people to have a data directory which has been
pre-configured.

So my thought to get around this would be to support an additional
startup parameter, called something like “GEOSERVER_DATA_DIR_TEMPLATE”.
The value of the parameter is a path to a data directory… however
instead of using that path directly, the behavior is instead to copy the
contents of it to temporary O/S space / home directory. So startup would
look something like:

-DGEOSERVER_DATA_DIR=[TMP]
-DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir

End of rant. Feedback welcome :).

-JD

–
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

Justin_Deoliveira · August 22, 2008, 6:39am

David Winslow wrote:

It seems to me that the best setup for a workshop situation would be a bootable CD; pop it in, reboot the system, and you have a GeoServer setup ready to go, with whatever customizations needed in something that looks like a writable filesystem (but resets to known-good with just another reboot.) You can even throw in whatever clients and other tools you think might come in handy for the tutorial and not worry about whether they have made accommodations for running live as well.

Yeah a set up like this would definitely be ideal. I have little experience with doing such things. What sort of tools are available to us? And can we set up a windows environment with them?

That said, I'm sure there are situations where a read-only GeoServer makes sense. Looking over your proposal, I see you are suggesting we respect a special flag value for GEOSERVER_DATA_DIR that indicates 'read-only filesystem access' and add another environment variable to specify where to load the data from. Since we are adding an environment variable anyway, does it make more sense to leave the DATA_DIR variable as specifying the data directory and add a GEOSERVER_READ_ONLY flag? That is,
-DGEOSERVER_DATA_DIR=/path/to/data -DGEOSERVER_READ_ONLY
instead of
-DGEOSERVER_DATA_DIR=[TMP] -DGEOSERVER_DATA_DIR_TEMPLATE=/path/to/data

Hmmm... i am not sure "read only" is the best way to put it, perhaps i am mis explaining myself. Its a fully functional geoserver able to write like normal... just in a well known location. Similar to how hudson just automatically stores of all its configuration in the users home directory.

This also avoids the possibility for users to enter a valid datadir path for both fields, which seems like a potentially confusing aspect of the original proposal.

Not sure I follow. When i write [TMP] i mean the actual string "[TMP]", which gets resolved to the java system property java.io.tmpdir on startup. The only path specified is the "template" data directory.

With the tutorial use-case in mind, it would probably be useful to have these set up in a configuration file (probably web.xml) instead of required as command-line args on every startup; I presume this is implied but just wanted to mention it.

Indeed.

-David

Justin Deoliveira wrote:

Hi all,

This is something that has been floating around in my head for quite some time and I wanted to throw some ideas out and see what people think of them.

So the use case here is be able to run GeoServer "live", that is straight off a CD or a USB stick. The problem is however that, as many know, GeoServer needs write access to be able to run. Now with a USB stick with enough space on it this is not an issue, but after a recent bad experience with USB sticks in labs, not having a CD to fall back on is suicide in my opinion :).

To find the instances I started GeoServer with an unwritable data directory and it blew up with issues related to logging, writable file checks, data like shapefiles locking and writing out index files, and more.

Past startup there is also the obvious fact that without a writable data directory there would be no ability to save any changes made via the web ui. Not ideal in a workshop situation.

So... my thought about the easiest way to get around this situation would be to somehow tell GeoServer to use the temporary O/S space, or use the users home directory for the data dir.

My first thought on how to do this is to use "special" values for the GEOSERVER_DATA_DIR parameter. Something like:

-DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]

Then the GeoServerDataDirectory.init() method would recognize these values and set the data directory path accordingly.

So continuing on with this, what about content inside the data directory? If you start geoserver with an "empty" data directory it still chokes. So my thought was to have GeoServerDataDirectory.init() not only set the path based on the special values, but also initialize the directory structure (only on the first run of course).

It seems logical to me to just use the minimal data directory in this case, which is just a skeleton catalog.xml and services.xml, and 4 sld files. However... in a workshop situation this is also not ideal, since we are going to want people to have a data directory which has been pre-configured.

So my thought to get around this would be to support an additional startup parameter, called something like "GEOSERVER_DATA_DIR_TEMPLATE". The value of the parameter is a path to a data directory... however instead of using that path directly, the behavior is instead to copy the contents of it to temporary O/S space / home directory. So startup would look something like:

-DGEOSERVER_DATA_DIR=[TMP] -DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir

End of rant. Feedback welcome :).

-JD

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

Justin_Deoliveira · August 22, 2008, 6:42am

Looks pretty slick... but all of our materials are written for windows users. Unless i am mistaken this is only feasible in a linux environment?

Arne Kepp wrote:

Most LiveCD's use something called UnionFS [1] that should fix this, essentially it makes a read-only filesystem act like a regular filesystem by copying changed files to RAM. If the machines have 1Gb or more, and we tell Java to user 256 to 512, we should be good.

I'd use https://help.ubuntu.com/community/LiveCD as the starting point, there's also a track for LiveCDPersistence which can use a USB stick for storage.

-Arne

1: http://www.filesystems.org/project-unionfs.html

Justin Deoliveira wrote:

Hi all,

This is something that has been floating around in my head for quite some time and I wanted to throw some ideas out and see what people think of them.

So the use case here is be able to run GeoServer "live", that is straight off a CD or a USB stick. The problem is however that, as many know, GeoServer needs write access to be able to run. Now with a USB stick with enough space on it this is not an issue, but after a recent bad experience with USB sticks in labs, not having a CD to fall back on is suicide in my opinion :).

To find the instances I started GeoServer with an unwritable data directory and it blew up with issues related to logging, writable file checks, data like shapefiles locking and writing out index files, and more.

Past startup there is also the obvious fact that without a writable data directory there would be no ability to save any changes made via the web ui. Not ideal in a workshop situation.

So... my thought about the easiest way to get around this situation would be to somehow tell GeoServer to use the temporary O/S space, or use the users home directory for the data dir.

My first thought on how to do this is to use "special" values for the GEOSERVER_DATA_DIR parameter. Something like:

-DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]

Then the GeoServerDataDirectory.init() method would recognize these values and set the data directory path accordingly.

So continuing on with this, what about content inside the data directory? If you start geoserver with an "empty" data directory it still chokes. So my thought was to have GeoServerDataDirectory.init() not only set the path based on the special values, but also initialize the directory structure (only on the first run of course).

It seems logical to me to just use the minimal data directory in this case, which is just a skeleton catalog.xml and services.xml, and 4 sld files. However... in a workshop situation this is also not ideal, since we are going to want people to have a data directory which has been pre-configured.

So my thought to get around this would be to support an additional startup parameter, called something like "GEOSERVER_DATA_DIR_TEMPLATE". The value of the parameter is a path to a data directory... however instead of using that path directly, the behavior is instead to copy the contents of it to temporary O/S space / home directory. So startup would look something like:

-DGEOSERVER_DATA_DIR=[TMP] -DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir

End of rant. Feedback welcome :).

-JD

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

Justin_Deoliveira · August 22, 2008, 6:44am

Nothing at all... when they work. We tried to give a workshop with 300 or so USB sticks which had been corrupted. Perhaps it just left a bad taste in my mouth but CD's seem like a more reliable medium :).

Although I think the plan is to try the USB sticks again for foss4g... with CD's as a backup plan.

What was the problem with USB sticks?
-S.

2008/8/22 Justin Deoliveira <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>>

    Hi all,

    This is something that has been floating around in my head for quite
    some time and I wanted to throw some ideas out and see what people think
    of them.

    So the use case here is be able to run GeoServer "live", that is
    straight off a CD or a USB stick. The problem is however that, as many
    know, GeoServer needs write access to be able to run. Now with a USB
    stick with enough space on it this is not an issue, but after a recent
    bad experience with USB sticks in labs, not having a CD to fall back on
    is suicide in my opinion :).

    To find the instances I started GeoServer with an unwritable data
    directory and it blew up with issues related to logging, writable file
    checks, data like shapefiles locking and writing out index files,
    and more.

    Past startup there is also the obvious fact that without a writable data
    directory there would be no ability to save any changes made via the web
    ui. Not ideal in a workshop situation.

    So... my thought about the easiest way to get around this situation
    would be to somehow tell GeoServer to use the temporary O/S space, or
    use the users home directory for the data dir.

    My first thought on how to do this is to use "special" values for the
    GEOSERVER_DATA_DIR parameter. Something like:

    -DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]

    Then the GeoServerDataDirectory.init() method would recognize these
    values and set the data directory path accordingly.

    So continuing on with this, what about content inside the data
    directory? If you start geoserver with an "empty" data directory it
    still chokes. So my thought was to have GeoServerDataDirectory.init()
    not only set the path based on the special values, but also initialize
    the directory structure (only on the first run of course).

    It seems logical to me to just use the minimal data directory in this
    case, which is just a skeleton catalog.xml and services.xml, and 4 sld
    files. However... in a workshop situation this is also not ideal, since
    we are going to want people to have a data directory which has been
    pre-configured.

    So my thought to get around this would be to support an additional
    startup parameter, called something like "GEOSERVER_DATA_DIR_TEMPLATE".
    The value of the parameter is a path to a data directory... however
    instead of using that path directly, the behavior is instead to copy the
    contents of it to temporary O/S space / home directory. So startup would
    look something like:

    -DGEOSERVER_DATA_DIR=[TMP]
    -DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir

    End of rant. Feedback welcome :).

    -JD

    --
    Justin Deoliveira
    Software Engineer, OpenGeo
    http://opengeo.org/>

    -------------------------------------------------------------------------
    This SF.Net email is sponsored by the Moblin Your Move Developer's
    challenge
    Build the coolest Linux based applications with Moblin SDK & win
    great prizes
    Grand prize is a trip for two to an Open Source event anywhere in
    the world
    http://moblin-contest.org/redirect.php?banner_id=100&url=/
    <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

Justin_Deoliveira · August 22, 2008, 6:49am

Rob Atkinson wrote:

What about allowing the logging to be separated from the config?
Logging is a different issue than configuration for a production
system, and its very unusual not to have a separate location.

Actually this hits on another issue that I have yet to bring up, but yes, i think i agree with you on this. Simply because having logging dependent on config means you cant accurately log the loading the config :).

It would be nice to have a load location and a write location for the
config - this is the template idea you have, but all you do is change
the data dir to the [save] location if you want to save a modified
config. on startup it could just check - if the [save] directory
exists ignore the [load] location.

And, for the icing on the cake, it would be nice on startup, if these
parameters are not defined, to allow the config of these via the UI.
challenge i guess is saving these settings somewhere sensible.

Rob

On Fri, Aug 22, 2008 at 12:35 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Hi all,

This is something that has been floating around in my head for quite
some time and I wanted to throw some ideas out and see what people think
of them.

So the use case here is be able to run GeoServer "live", that is
straight off a CD or a USB stick. The problem is however that, as many
know, GeoServer needs write access to be able to run. Now with a USB
stick with enough space on it this is not an issue, but after a recent
bad experience with USB sticks in labs, not having a CD to fall back on
is suicide in my opinion :).

To find the instances I started GeoServer with an unwritable data
directory and it blew up with issues related to logging, writable file
checks, data like shapefiles locking and writing out index files, and more.

Past startup there is also the obvious fact that without a writable data
directory there would be no ability to save any changes made via the web
ui. Not ideal in a workshop situation.

So... my thought about the easiest way to get around this situation
would be to somehow tell GeoServer to use the temporary O/S space, or
use the users home directory for the data dir.

My first thought on how to do this is to use "special" values for the
GEOSERVER_DATA_DIR parameter. Something like:

-DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]

Then the GeoServerDataDirectory.init() method would recognize these
values and set the data directory path accordingly.

So continuing on with this, what about content inside the data
directory? If you start geoserver with an "empty" data directory it
still chokes. So my thought was to have GeoServerDataDirectory.init()
not only set the path based on the special values, but also initialize
the directory structure (only on the first run of course).

It seems logical to me to just use the minimal data directory in this
case, which is just a skeleton catalog.xml and services.xml, and 4 sld
files. However... in a workshop situation this is also not ideal, since
we are going to want people to have a data directory which has been
pre-configured.

So my thought to get around this would be to support an additional
startup parameter, called something like "GEOSERVER_DATA_DIR_TEMPLATE".
The value of the parameter is a path to a data directory... however
instead of using that path directly, the behavior is instead to copy the
contents of it to temporary O/S space / home directory. So startup would
look something like:

-DGEOSERVER_DATA_DIR=[TMP]
-DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir

End of rant. Feedback welcome :).

-JD

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

David_Winslow · August 22, 2008, 1:48pm

This also avoids the possibility for users to enter a valid datadir path for both fields, which seems like a potentially confusing aspect of the original proposal.

Not sure I follow. When i write [TMP] i mean the actual string "[TMP]", which gets resolved to the java system property java.io.tmpdir on startup. The only path specified is the "template" data directory.

Right; what happens if I do
-DGEOSERVER_DATA_DIR=/path/to/datadir -DGEOSERVER_DATA_DIR_TEMPLATE=/path/to/minimal

Does GeoServer just ignore the template? Does my data get wiped out? Do I end up with some kind of combination of the two data dirs? This is the confusion I was talking about.

-David

Justin_Deoliveira · August 22, 2008, 4:18pm

Right; what happens if I do
-DGEOSERVER_DATA_DIR=/path/to/datadir -DGEOSERVER_DATA_DIR_TEMPLATE=/path/to/minimal

Does GeoServer just ignore the template? Does my data get wiped out? Do I end up with some kind of combination of the two data dirs? This is the confusion I was talking about.

My thought is that if the data directory already exists things just startup normally. Not sure... maybe that isn't the best way...

-David

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org