Gentoo Archives: gentoo-dev

From: Stuart Herbert <stuart@g.o>
To: Max Kalika <max@g.o>, Troy Dack <tad@g.o>, gentoo-dev@g.o
Subject: Re: [gentoo-dev] [GLEP] Web Application Installation
Date: Sun, 03 Aug 2003 14:48:25
Message-Id: 200308031546.22388.stuart@gentoo.org
In Reply to: Re: [gentoo-dev] [GLEP] Web Application Installation by Max Kalika
1 Hi Max,
2
3 On Sunday 03 August 2003 3:26 am, Max Kalika wrote:
4 > > I'd prefer /etc/webapps/<application>/, again for future flexibility
5 > > where a web application has more than one configuration file. I don't
6 > > mind frigging apps to look in more than one place for a config file. I
7 > > do mind patching apps to use just the one file.
8 >
9 > You want to mix the apache config block with other configuration files that
10 > come with the application?
11
12 /etc/webapps/<application>/ is the directory for the *application's* config
13 files. Nothing to do with Apache per se.
14
15 There is an alternative that should be considered. Maybe there shouldn't be
16 an /etc/webapps directory at all, and the config files should live under the
17 Document Root. Yes, this might be better. How would you support multiple
18 installations of phpMyAdmin using a /etc/webapps/ scheme?
19
20 > Yes! Which is why a patch is probably not always appropriate -- sed is
21 > more resilient to pieces of configuration moving around upstream.
22
23 Not sure I understand you here. A patch is applied against a known set of
24 files. Portage only installs known sets of files. So a patch is no less
25 appropriate than sed.
26
27 > > If Robin doesn't beat me to it, I'll write a script that we can add to
28 > > Portage to standardise getting this information.
29 >
30 > What did you have in mind to achieve this?
31
32 Last night, I thought I was sure. Unfortunately, waking up today I've
33 forgotten ;-) I'll go back and re-read the thread.
34
35 > > What shape are other languages in for their dependencies? Not every
36 > > webapp is going to be written in PHP ...
37 >
38 > Many apps are CGIs. Others can of course be mod_perl, mod_python, java,
39 > you name it. I see no problems using the eclass with these because it was
40 > written with flexibility in mind. Like I've said in the past. My initial
41 > idea for this was to fix nut and apcuspd to cleanly install their CGI
42 > components.
43
44 We're going to use the one eclass for CGIs, mod_perl-dependent,
45 mod_python-dependent, and so on? Mmmm. That way lies pain and misery me
46 thinks.
47
48 I think we'll need a webapps-base eclass, and then a webapps-<language> set of
49 eclasses. All the language-neutral stuff goes in the base, and everything
50 else goes into each specific language eclass.
51
52 > > Well, write access to directories under htdocs at any rate. TikiWiki -
53 > > which we're looking to use for a Gentoo website - has this annoying
54 > > feature.
55 >
56 > What bothers me though, is that having any directory under /usr writeable
57 > is really bad form (I made a policy at work for all servers -- configure a
58 > system where /usr can be mounted read-only). If at all possible, I'd like
59 > to have these directories created under something like /var/lib/ and
60 > symlinked back to where the app needs to write. If not symlinked then an
61 > Apache alias (or whatever is equivalent to other servers).
62
63 Writable /usr is something I'll have no part in.
64
65 I thought Robin's idea was this. The master copy of the app goes in
66 /usr/webapps. Then we have a script that symlinks in the app under the
67 Document Root as required by the local admin, or uses .htaccess tricks as
68 appropriate.
69
70 Robin - can you explain your idea again plz?
71
72 > See above. But I agree, we _can't_ standardize on the approach simply
73 > because it depends on what needs to be done. I imagine that there will be
74 > some apps where we would just have complete config files living in
75 > ${FILESDIR} that get installed over the ones that come with the package.
76
77 Urgh. Only if the patch is larger than the replacement file, I'd hope ;-)
78
79 > Having said that, I say we _should_ standardize on installation of packages
80 > from the same family (i.e. Horde).
81
82 Well, that'd be up to the maintainer of the packages I'd hope.
83
84 > >> Standardization should always be applauded. :-)
85 > >
86 > > Urgh ;-) If everything in life was standardised, we'd be running RedHat,
87 > > not busy upsetting the apple-cart with this upstart project ;-)
88 >
89 > Having run redhat for the past 4 years, I can safely say that that pile of
90 > stuff strewn loosely together with twine and masking tape into a
91 > nightmarish packaging system is far from standardized.
92
93 Lots of laughter. My intention wasn't to start a RedHat flame war ;-)
94
95 > Forgot to bring this up. Can't agree more. Web-* makes sense to me.
96 > There's a slew of things that can go into web-mail and web-net just to
97 > start.
98
99 Definitely.
100
101 > > Secondly, are we going to establish a webapps herd to look after the
102 > > packages that will be added? If so, feel free to add me to the list of
103 > > maintainers. If not, then what solution do you suggest?
104 >
105 > A herd makes sense. I'll leave this to the higher-ups thought. :-)
106
107 As I understand it, if there's a group of us want a herd, then it's up to us
108 to put it in place and make it a success.
109
110 > As I've said before many times, I'd like to see the eclass grow into
111 > something that can be used with all the webservers we have in portage. I
112 > don't know if userland tools can be flexible enough to create config blocks
113 > for all the apps that we're going to have. An ebuild knows enough of the
114 > application to pass the necessary information to the eclass to create
115 > whatever config is needed. At the same time, we have to be careful to not
116 > balloon this into something unmaintainable. Which is why it may be best to
117 > start this as apache-only (as it is the more popular of the webservers).
118 > Get everything converted over and working and only then add support for
119 > others.
120
121 Just what webserver-specific configuration do these apps need? I'd hope that,
122 for the vast majority of apps, it's little to none.
123
124 If we start down the apache-only route now, it's something that'll probably
125 never get fixed. Let's identify just what apache config stuff you think is
126 needed, and let's generalise it now. It can't be that difficult - it's only
127 a web server.
128
129 Best regards,
130 Stu
131 --
132 Stuart Herbert stuart@g.o
133 Gentoo Developer http://www.gentoo.org/
134 Beta packages for download http://dev.gentoo.org/~stuart/packages/
135
136 GnuGP key id# F9AFC57C available from http://pgp.mit.edu
137 Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
138 --

Replies

Subject Author
Re: [gentoo-dev] [GLEP] Web Application Installation Max Kalika <max@g.o>