On Wed, Mar 12, 2003 at 08:31:06AM +0100, Michael Bell wrote:
You mean it tages ca.xml + ca.conf.template and outputs ca.conf?
Yes and in the future we take ca.xml.template and ca.xml and output ca.xml. Sounds stupid? Ok, I will try to explain it.
Ok, but we probably want to give ca.xml and ca.xml different names...
If we have a working prototype then we can start thinking about such thinkgs :)
Sounds good...
As an alternative to ca.xml.template though (I like alternatives!), how about using xpath/xpointer (or whatever the standard is called, I always get these mixed up), eg:
<template> <config name="country" xpath="/openca/software_config/country"/> [...] </template>
> > Which would say: take the value of "country" from the input ca.xml > file, search for the /openca/software_config/country element in the > output data file, and replace it.
If we use such features of XML then we have have two problems.
1. Do you know the performance of Perl xpath implementations?
2. Do you now a Perl module which support such things.
Until now I only use the simplest XML features as possible.
Which would say: take the value of "country" from the input ca.xml file, search for the /openca/software_config/country element in the output data file, and replace it.
This means you only have to replace certain elements in the XML file, not the entire file, and is more "XMLish".
Sounds reasonable for the future but the actual configuration files and mails are not in XML.
As for implementing it... I am not an experienced XML programmer... ;-)
I implemented a persistent database backend for XML but I never used XML itself before - so at some point we are all beginners :)
Alternatively (if thats not enough options already), you could go somewhere inbetween, ie translate the files and cache them somewhere.
I think a dynamical translation is ok for the first time. After a first time we can implement a cache directory in var/tmp/interface_name/. I think we can start with some practical aspects:
Just make this directory configurable. And watch out for potential security problems in /var/tmp, a malicious user could create a file called var/tmp/interface_name for instance, and stop openca from working.
This cannot happen. OpenCA has a private tmp-directory in var to avoid such attacks (e.g. symlink attack). Only root or the webserver user can create files in this directory and such users can corrupt the whole server. We don't use /tmp or /var/tmp. If you find code in OpenCA which use /tmp or /var/tmp then this is a security bug.
Do you expect the adminstrator to want to make changes to the input files?
I coded the necessary changes for a prototype and will commit the changes during the day. I will place all files which are changing in etc/ to support such guidelines like the on from debian and make my colleague happy which fight after every OpenCA update with i18n problems. The new design will fix such flaws too!
After the commit I will send a mail which describes the deactivation of the access control and the new configuration mechanism.
Best regards
Michael -- ------------------------------------------------------------------- Michael Bell Email (private): [EMAIL PROTECTED] Rechenzentrum - Datacenter Email: [EMAIL PROTECTED] Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482 Unter den Linden 6 Fax: +49 (0)30-2093 2704 10099 Berlin Germany http://www.openca.org
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
