[Brad Eacker] | Randy Terbush <[EMAIL PROTECTED]> writes: | >Storage of the config info could move to: | >- Berkeley DB 2.0 | >- SQL | >- others? | | This is an interesting thought. But if we go and change the config | storage information mechanism for apache, it implies that there will need | to be changes to the code base to do so. This is something we should | think long and hard about. Since it would imply that the only way to | update the config information is thru the gui. I believe that this | would be a mistake.
not necessarily. I have been using mSQL to store configuration information for UNIX machines at a customer site. parts of their password files, their group files, their Apache configuration etc. is stored in an SQL database and generated by various small C-programs that, in a very flexible way can generate the configuration files. | I think that we would be better served to treat the gui config | manipulation as an adjunct to the base apache code. This gives us | the most freedom in how we do things. But still maintains | compatibility with the code base. I agree that this project does not belong in the Apache source tree and that it should not interfere with the Apache project, although we might stumble across ideas that should be implemented in Apache. my feelings are that we should design a solution that is based on usage of an SQL database for data maintainance, consistance and storage. the interface should primarly be one for maintaining the data in the database. the interface to the database should be implemented through some sort of database abstraction layer -- or at least, we should offer support for various databases�. in practice we need 3 things. 1) The configuration server 2) The administration client (GUI / tty) 3) The configuration server client (update routine) the configuration server is the one that sits on the data and has information about who is allowed to connect to it. every server it serves needs an entry in the ACL, and every client needs another entry in the ACL. (ACL is short for Access Control List, and the term is loosely used about...well, access control stuff). the configuration server holds data for one or more servers. the administration client talks to the configuration server and presents the user with a GUI or a tty-interface. the client should be portable so people can use it on UNIX, Windows, Mac etc. and at this time it's not very important what language� we write it in. the configuration server client resides on every machine where an Apache server runs (or perhaps other kinds of servers? :). it can be started from inetd when the configuration server wants to update ut BUT it will not receieve any data through that connection. when started via inetd the configuration server client could perhaps take some simple commands from the configuration server. now for security. I would very much like to use SSL for this project, securing all connections and using public key based authentication. this poses a few problems however. I am not sure about the state of affairs in the US, but the rest of the world (with the exception of France, China etc.) probably has no problem with this). I think a good strategy might be to implement it in a way that makes adding SSL easy/trivial so that a patch can be downloaded and added. without using SSL we need to think up methods for doing things securely. �) this does give us a "least common denominator problem" but I think we can get around this by keeping it simple in the beginning. �) I am currently having a look at Python, but I don't know Python yet. it promises great cross-platform portability and I would be very interested in optinions. the server parts should be written in C. -Bj�rn -- Bj�rn Borud <[EMAIL PROTECTED]> | "The Net interprets censorship <URL:http://www.pvv.unit.no/~borud/> | as damage and routes around it." UNIX person, one of "them" | - John Gilmore
