Wwwconfig-common, was: Re: Web applications
Hi
I saw this discussion and would like to comment on wwwconfig-common so
people understand why it was designed as it is.
Quote from mail from sean finney <seanius@seanius.net>:
> > The apache include question is, AFAICT, basically solved. Drop a symlink
> > in /etc/apache/conf.d and let $DEITY sort them out.
>
> i think their preferred method is to use the "modules-config" (or
> whatever they've renamed it to) which is designed to work with the many
> incarnations of the apache server config setup. wwwconfig-common
> is a parallel method which behaves differently, but Ola is fairly
> responsive in my experience and could probably be convinced to rework the
> guts so that people currently using that system would be transparently
> brought along, assuming we could come to some working conclusion.
Yes I'm very open to new solutions. My plan (when woody was about to be
released) was to rewrite wwwconfig-common to be a more general configuration
system helper but ... well it never got much further than a new project
in CVS and some design scetches. Oh we have a name for the project too. :)
Help on this is very appriciated. We can probably have it in full function
to sarge+1.
On Thu, Aug 19, 2004 at 03:14:30PM +0200, Pierre Habouzit wrote:
*SNIP*
> > I have just come across wwwconfig-common. Perhaps it just needs some
> > patches regarding the new powers of debian-sys-maint of mysql-server,
> > its importance re-instated and the "apache type" (httpd) question
> > scrutinised (again).
>
> I guess there are plenty other questions, sean listed quite a lot of them
> (but not all of them I believe). maybe we should just make a good list of
> them, sort them between db engines questions, web apps questions, http
> server questions, etc ... and then write a policy for each sort of
> problem, should we ?
Sounds like a good plan.
> moreover, wwwconfig-common is a great idea, and the actual maintianer is
> really responsive. But I think that it's not very well done (all args are
Thanks. I must admit that I have not been very responsive the last
year or so. Right now I have quite a lot of time for Debian though.
> given through env vars, and that clearly sucks : not very secure (any API
> change, and we fuck up the entire thing), not very readable (using a
> script is in 3 steps : settings envs, sourcing the script, and reading
> envs, it's IMHO quite hard to read, and difficult to use -> not really
> possible to simply use those scripts in loops)
Yes I know that this is not a perfect solution but you understand why,
below.
> IMHO, we should think at a brand new tool, more secure (comprehensive
> error semantics, and stuff like that), easier to use (these env vars are
> nonsense), providing some registered ressource database (then we only
> have to choose an already registered ressource, instead of telling all
> its parameters each time) ...
Fully agree.
Now to wwwconfig-common and some history.
I wrote wwwconfig-common for one thing only (in the beginning). I maintained
horde and imp back then and wanted them to be easier to install than they
were before. I did so but when doing that I realized that we had vcery much
code duplication in the two packages. So I wrote a middle layer that I
named wwwconfig-common to reduce the amount of code in each package.
The design has been kept since then and they have this strange syntax for
some simple reasons.
1) Shell script because I wanted to keep the dependencies on a minimum.
2) Environment passing because then you can set variables and then just
call the functions and forget about the variables. Sort of anyway.
3) Sourced scripts, simply because there are no good way to pass
information back to the calling script to tell how the operation went
and what the problem was (if any). If anyone comes up with a good
solution on this, much can be solved.
Yesterday I did a reverse depends on wwwconfig-common and was a bit
surprised. So many packages depending on my hack! I thought that maybe
7-10 packages depended on it, but not 48!!! Well some are my own but
really not all of them.
Now here is what I would like to do in the future:
1) Write a new tool that solves the issues in wwwconfig-common.
2) Split the package in separate parts depending on that they are able
to configure.
3) Abstract the database configuration so it is (at least simpler)
just to set a variable (or similar) to tell what kind of database
you want to fill and with what kind of data. What user to create etc.
4) Get rid of the apache-*include* things. Applications should not
automatically be added to apache, for more (maybe) than a default-include
thing. It is not very nice to include over and over again even if
the maintainer do not want it. Right now it can be prevented by just
commenting out the line or move it to another file in the apache dir.
If you just remove it, it will be added again on upgrade. Yes that
is a bug but I know of no good solution within the current structure.
I want to keep the principle of not depending on some "big" interpreter.
I just want to use simple posix compatible shell-scipt unless someone comes
up with a really good argument of why.
The best thing is to have it language-independent (like the check functions
in nagios).
Well this was a quite long mail for a simple subject. I simply want to
have more people that want to help me.
Regards,
// Ola
> --
> Pierre Habouzit http://www.madism.org/
> -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
> gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE
> spam: mad.junk@madism.org
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Annebergsslingan 37 \
| opal@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: