[OSM-Devserver] Globales Directory für tirex Stylefiles

[Frederik Ramm]

Hallo,

Peter Körner wrote:
> Deine Argumentation über die unterschiedliche Server-Konfiguration 
> leuchtet mir jedoch ein. Ich weiß nicht genau, wie eure Planung für 
> diese konfiguration ist. Da ich ein Fan dieser "plug-and-play" 
> Architektur (du nennst es Magie :) bin, würde ich vorschlagen, diese 
> Render-Konfiguration in einem eigenen XML-Namespace in das Style-XML 
> einzubinden.

Es gibt sicher Plaetze, an denen das vernuenftig ist. Bei den aktuellen 
Linux-Distributionen werden ja auch mehr und mehr diese 
"blabla.d"-Verzeichnisse eingesetzt - allerdings in den meisten Faellen 
fuer Situationen, in denen viele installierte Programme/Pakete irgendwas 
von einem anderen Paket wollen (/etc/logrotate.d, /etc/cron.d und 
aehnliches). Eine Rechte-Separation (jemand darf zwar Files in das .d 
legen, aber das Configfile editieren darf er nicht) wird damit in der 
Regel nicht realisiert - sowas gibt es, wenn ueberhaupt, dann mit einem 
Mechanismus a la .forward oder .public_html im Homeverzeichnis des 
Benutzers.

Deine Idee, dass man es dadurch auf den Wikipedia-Servern einfacher 
haben koennte, mag zutreffen, aber sollten wir wirklich mit Softwar um 
die (offenbar) kranke Admin-Politik auf diesen Serven herumbasteln? Oder 
anders gesagt: Wenn die Installation von Zeugs so aufwendig ist, dann 
bitte doch um die Installation eines "sudo" ;-)

Ich als Sysadmin zumindest wuerde es sicherheitstechnisch gleich 
bewerten, ob ich jemandem jetzt sudo-Rechte fuer den User tirex gebe 
oder ob ich der Person erlaube, tirex-Configfiles in ein Verzeichnis zu 
werfen, von wo Tirex sie liest. Letzteres ist m.E. nicht "sicherer" als 
ersteres.

Wir haben es mit drei Konfigurationsebenen zu tun:

* Tirex (und mod_tile) muessen wissen, welche Styles gibt und welches 
Render-Backend dafuer angesprochen werden muss; evtl. welche 
Einschraenkungen (Zoomlevel usw.) gelten.

* Das Render-Backend, derzeit also der tirex-renderd, muss die Styles 
kennen, die er bearbeiten soll;

* Mapnik braucht die Style-Information selbst.

Dies alles in ein gemeinsames File zu packen ist zwar moeglich, aber ich 
empfinde es nicht als eine gute Loesung, weil man damit alles vermischt. 
Der Tirex-Master zum Beispiel interessiert sich ueberhaupt nicht fuer 
die Style-Definition, ob das jetzt XML ist oder Binaer oder vom Mapnik 
irgendwo vom Netz gezogen wird, kann dem egal sein. Wieso sollte er also 
das Mapnik-Stylefile oeffnen und da anhand eines eigenen Namespace 
irgendwelche Sachen rauslesen?

Bye
Frederik