-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hi,
i'm the senior Unix administrator for the Toolserver project. i'm mostly involved in the WMF side, and i haven't done much with the OSM stuff. however, i have been observing the progress of the OSM Toolserver (cassini), since that is ostensibly part of the Toolserver cluster, and i have a few concerns.
firstly, i'd like to see proper integration between the OSM and WMF parts of the Toolserver. for example, someone has configured a web server on cassini, and people are already deploying tools at http://cassini.toolserver.org/~username/. it should be clear why using "cassini.toolserver.org" in a URL is a bad idea; but i don't see why cassini needs to host user tools at all.
the Toolserver already has a web server which works quite well, and has plenty of spare resources. by putting OSM user tools there, we can combine resources and make efficient use of them; if/when the web server is full, we can add additional resources and both WMF and OSM users will immediately be able to take advantage of them. (i understand OSM needs some special Apache module for serving tiles; keeping that on cassini probably makes sense.)
it's also not clear to me whether cassini needs to be a login server at all; the WMF databases at the TS don't allow user login, and users connect to them remotely. is there something special about OSM tools that prevents them from running on the existing TS login servers?
secondly, in the rush to deploy cassini as quickly as possible, it seems that little planning has been done. one thing we've learnt from the Toolserver is that it's a lot less effort to plan things properly from the start, instead of deploying something, then discovering it has to be redone later. might i suggest that people take a step back, consider what exactly the "OSM Toolserver" is meant to be, and come up a plan before going any further?
- river.
i'm the senior Unix administrator for the Toolserver project. i'm mostly involved in the WMF side, and i haven't done much with the OSM stuff. however, i have been observing the progress of the OSM Toolserver (cassini), since that is ostensibly part of the Toolserver cluster, and i have a few concerns.
firstly, i'd like to see proper integration between the OSM and WMF parts of the Toolserver. for example, someone has configured a web server on cassini, and people are already deploying tools at http://cassini.toolserver.org/~username/. it should be clear why using "cassini.toolserver.org" in a URL is a bad idea; but i don't see why cassini needs to host user tools at all.
the Toolserver already has a web server which works quite well, and has plenty of spare resources. by putting OSM user tools there, we can combine resources and make efficient use of them; if/when the web server is full, we can add additional resources and both WMF and OSM users will immediately be able to take advantage of them. (i understand OSM needs some special Apache module for serving tiles; keeping that on cassini probably makes sense.)
it's also not clear to me whether cassini needs to be a login server at all; the WMF databases at the TS don't allow user login, and users connect to them remotely. is there something special about OSM tools that prevents them from running on the existing TS login servers?
secondly, in the rush to deploy cassini as quickly as possible, it seems that little planning has been done. one thing we've learnt from the Toolserver is that it's a lot less effort to plan things properly from the start, instead of deploying something, then discovering it has to be redone later. might i suggest that people take a step back, consider what exactly the "OSM Toolserver" is meant to be, and come up a plan before going any further?
Hi. I'm the senior administrator for Cassini, evidently :)
I'm in complete agreement with everything you suggest. It makes much more sense to use cassini as a backend server that provides map-specific stuff such as PostGIS databases and other remote services while other servers handle user login and serving web requests.
The reason this isn't the case is (as far as I know) a bit of a turf conflict between Wikimedia Germany and the rest of the Toolserver cluster. WMDE paid for "A Map Toolserver" and got me to admin it. I only agreed to admin it because I needed some hardware to test the MediaWiki embedding of OpenStreetMap maps, I really don't have time to properly do it, nor am I familiar enough with the Toolserver cluster/procedures to do it in the time that I have.
The current setup on Cassini is the outgrowth of a hack I set up to have something to present for Wikimania 2009. The things that are currently going on on it are test replications of the OSM database which people like Peter Körner who are interested in writing map tools need to get their job done.
There have been a few threads on this mailing list and/or #ts-admins (can't find them now) suggesting that we re-arrange the architecture as you suggest. But for some reason we don't have that yet.
So who needs to give the OK before we can do things as you suggest? It's completely clear to anyone who's looked at the current architecture that it's completely non-optimal and an obstacle to providing mapping services to Toolserver users.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ævar Arnfjörð Bjarmason:
WMDE paid for "A Map Toolserver" and got me to admin it. I only agreed to admin it because I needed some hardware to test the MediaWiki embedding of OpenStreetMap maps, I really don't have time to properly do it, nor am I familiar enough with the Toolserver cluster/procedures to do it in the time that I have.
perhaps it would be a good idea to integrate cassini as a Toolserver database (like the MySQL ones). i would be quite happy to take over general admin work and database maintenance for it, as long as someone else can handle the OSM-specific bits (i have no idea how that works).
this would require that it run Solaris, as all our install/admin infrastructure is set up for this. if user tools were moved to other servers, i assume this wouldn't make much difference; PostgreSQL should be much the same everywhere.
So who needs to give the OK before we can do things as you suggest?
from our side, nothing needs to be done; it should already be possible for people to start running OSM tools on the TS login/web servers. i don't know what needs to be done on cassini to make this work, though.
- river.
Hi River
firstly, i'd like to see proper integration between the OSM and WMF parts of the Toolserver. for example, someone has configured a web server on cassini, and people are already deploying tools at http://cassini.toolserver.org/~username/. it should be clear why using "cassini.toolserver.org" in a URL is a bad idea; but i don't see why cassini needs to host user tools at all.
I don't see the necessity for a tool-webserver on cassini, too. If we could connect to the postgresql-db on cassini from the other toolserver login-/webservers, it would be ok for most tools as well.
If we could set up mapnik on the login servers I don't see any reasons to login on cassini except for administrative tasks.
Atm. Cassini is only in testing phase. I have written a tool on it just to see how & if it works. Also the imports I'm currently doing are more of educational nature (I'm learning how to populate the postgis-db, keep the minutely replication running, etc.).
the Toolserver already has a web server which works quite well, and has plenty of spare resources. by putting OSM user tools there, we can combine resources and make efficient use of them; if/when the web server is full, we can add additional resources and both WMF and OSM users will immediately be able to take advantage of them.
+1
(i understand OSM needs some special Apache module for serving tiles; keeping that on cassini probably makes sense.)
I think cassini should keep running the postgis-db, the rendering stack and a dev-tileserver, where we can play with different mapnilk-styles -- nothing more.
it's also not clear to me whether cassini needs to be a login server at all; the WMF databases at the TS don't allow user login, and users connect to them remotely. is there something special about OSM tools that prevents them from running on the existing TS login servers?
No, except for a mapnik installation, that can be installed on the regular login servers as well.
secondly, in the rush to deploy cassini as quickly as possible, it seems that little planning has been done. one thing we've learnt from the Toolserver is that it's a lot less effort to plan things properly from the start, instead of deploying something, then discovering it has to be redone later. might i suggest that people take a step back, consider what exactly the "OSM Toolserver" is meant to be, and come up a plan before going any further?
Okay, here're my ideas:
Put some HD-Space from ptolemy or from a store ;) into cassini and get two databases on it: - a complete osm-clone including history - a postgis db for rendering
Ptolemy only needs the latter for serving as database-backend for the live renderer.
Connect Postgresql with LDAP and open it read-only to the regular login- & webservers.
Get regular update running on cassini, later porting this effort to ptolemy (I already wrote a task to do a complete planet update, located in /sql/planet.osm on cassini)
Get some Mapnik-Styles (the multilanguage, the hike'n'bike style and maybe others) on Cassini.
Define a procedure (like "post it on the mailing list") that allows others to put their style on cassini. Document how to access cassinis DB from the toolservers, how an when the updates take place etc.
What are yours? Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
If we could set up mapnik on the login servers
is any set up required besides installing it?
Put some HD-Space from ptolemy or from a store ;) into cassini
the current plan seems to be swapping cassini and ptolemy, so ptolemy (which has twice as much space) will become the OSM Toolserver.
Connect Postgresql with LDAP and open it read-only to the regular login- & webservers.
i don't think using LDAP is a good idea. it will encourage users to write their LDAP passwords into their tools, and it's not uncommon for people to expose these passwords due to programming errors. while LDAP passwords can't be used to log in, it seems better to use separate database passwords, like we do for MySQL.
i can't comment on the OSM-specific tasks as i don't know much about that.
What are yours?
Marcin and i have agreed on a plan for ptolemy: it will become the OSM Toolserver, running PostgreSQL and Apache (for tiles), but with no user access. OSM tools will move to the regular Toolserver, and access ptolemy remotely. we are currently waiting on WMF approval to implement this.
- river.
On Fri, Nov 6, 2009 at 2:06 PM, River Tarnell river@loreley.flyingparchment.org.uk wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
If we could set up mapnik on the login servers
is any set up required besides installing it?
Mapnik needs to be on the normal user servers (e.g. webserver) if users want to for example create custom OSM wallpaper images or something other than tiles.
Mapnik in its normal operation will connect to a PostgreSQL server defined in your stylesheet. If the user supplies cassini as the remote server and has appropriate permissions this should just work.
However if we're going to do on-demand rendering on the tileserver this user-supplied stylesheet will have to be moved over there. Alternatively if someone would implement something that did what renderd does in e.g. FastCGI this could be on a normal webserver. What renderd does is basically:
1. Get a GET request like /foo/18/136758/91112.png 2. Render the stylesheet cofigured for /foo/ at zoom level 18, tile 136758x91112 by calling out to mapnik 3. Put the rendered tile in a tile store 4. Serve it to the user 5. When the tile is requested next time skip step 1-3 (unless it's expired)
Tile expiry is relatively simple. Basically you can either just run a find(1) command in cron and remove everything older than N seconds. Or you can have osmosis compute a list of changed tiles every time it applies a diff and that can be piped into rm -rf.
(bah)
Anyway regarding installing it we need to have a pretty recent version of mapnik since the osmosis/osm2psql/mapnik chain is pretty bleeding edge. Currently OSM rendering only works with mapnik >6.0 (and maybe only 6.1?).
Put some HD-Space from ptolemy or from a store ;) into cassini
the current plan seems to be swapping cassini and ptolemy, so ptolemy (which has twice as much space) will become the OSM Toolserver.
Connect Postgresql with LDAP and open it read-only to the regular login- & webservers.
i don't think using LDAP is a good idea. it will encourage users to write their LDAP passwords into their tools, and it's not uncommon for people to expose these passwords due to programming errors. while LDAP passwords can't be used to log in, it seems better to use separate database passwords, like we do for MySQL.
Sounds nice. Should also be simpler so set up.
i can't comment on the OSM-specific tasks as i don't know much about that.
What are yours?
Marcin and i have agreed on a plan for ptolemy: it will become the OSM Toolserver, running PostgreSQL and Apache (for tiles), but with no user access. OSM tools will move to the regular Toolserver, and access ptolemy remotely. we are currently waiting on WMF approval to implement this.
Yay.
Ævar Arnfjörð Bjarmason schrieb:
On Fri, Nov 6, 2009 at 2:06 PM, River Tarnell river@loreley.flyingparchment.org.uk wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
If we could set up mapnik on the login servers
is any set up required besides installing it?
Mapnik needs to be on the normal user servers (e.g. webserver) if users want to for example create custom OSM wallpaper images or something other than tiles.
Mapnik in its normal operation will connect to a PostgreSQL server defined in your stylesheet. If the user supplies cassini as the remote server and has appropriate permissions this should just work.
However if we're going to do on-demand rendering on the tileserver this user-supplied stylesheet will have to be moved over there.
I think that users can play with their styles on cassini, using e.g. my osm-render frontend:
mazder@cassini:~$ /tmp/osm-render --help Usage: osm-render [options]
Options: -h, --help show this help message and exit -s STYLE, --style=STYLE path to the mapnik stylesheet xml, defaults to
the openstreetmap default style: /sql/mapnik-stylesheets/osm-like/osm-de.xml -f FILE, --file=FILE path to the destination file without the file extension, defaults to map -t TYPE, --type=TYPE file type to render, defaults to png -x SIZE, --size=SIZE requested sizeof the resulting image in pixels, format is <width>x<height>, defaults to 800x600 -b BBOX, --bbox=BBOX the bounding box to render in the format l,b,r,t, defaults to (-180, -85, 180, 85)
e.g. /tmp/osm-render --bbox 12.44671,41.89479,12.46276,41.90784 \ --style /sql/mapnik-stylesheets/osm-like/osm-fr.xml --file fr
If the style is ready to be tested on the whole planet, the user can contact us on jira and we'll add his style to cassini's renderd.
Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
I think that users can play with their styles on cassini
the current plan is that normal users will not have login access to the PostgreSQL database / tile server.
- river.
River Tarnell schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
I think that users can play with their styles on cassini
the current plan is that normal users will not have login access to the PostgreSQL database / tile server.
Sorry, I wanted to say "I think that users can play with their styles on *the login server* as long as mapnik is installed there. The osm-render tool could then be copied to the login servers where it uses the local mapnik installation to connect to cassini's database. No need to logon on cassini.
Sorry for that :)
Peter
On Fri, Nov 6, 2009 at 9:06 AM, River Tarnell river@loreley.flyingparchment.org.uk wrote:
i don't think using LDAP is a good idea. it will encourage users to write their LDAP passwords into their tools, and it's not uncommon for people to expose these passwords due to programming errors. while LDAP passwords can't be used to log in, it seems better to use separate database passwords, like we do for MySQL.
pg_hba.conf can be setup to authenticate users without passwords, but instead by IP address/range + username:
host osmdb all 192.168.93.0/24 (or whatever the toolserver ip/range) ident
http://developer.postgresql.org/pgdocs/postgres/auth-pg-hba-conf.html
Alternatively, .pgpass can be used similarly to using my.cnf for MySQL authentication.
http://wiki.postgresql.org/wiki/Pgpass
I would recommend configuring permissions in pg_hba.conf rather than pgpass, but either would work.
Marcin and i have agreed on a plan for ptolemy: it will become the OSM Toolserver, running PostgreSQL and Apache (for tiles), but with no user access. OSM tools will move to the regular Toolserver, and access ptolemy remotely. we are currently waiting on WMF approval to implement this.
And use Cassini as the production db server?
-Kate
- river.
On Fri, Nov 6, 2009 at 2:48 PM, Kate maps2wiki@gmail.com wrote:
And use Cassini as the production db server?
We're just switching Cassini and Ptolemy. Ortelius will remain the DB server.
Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
On Fri, Nov 6, 2009 at 2:48 PM, Kate wrote:
And use Cassini as the production db server?
We're just switching Cassini and Ptolemy. Ortelius will remain the DB server.
Er, I thought that Ptolemy was about to be the prod db server, so, answering Kate's question - yes, current Cassini would become produciton db server. And the ortelius will stay as the rendering box.