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 ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
