* [gentoo-portage-dev] webapp-config and webapps
@ 2004-10-28 20:02 Wendall Cada
2004-10-28 20:20 ` Paul de Vrieze
2004-10-28 20:52 ` Grant Goodyear
0 siblings, 2 replies; 19+ messages in thread
From: Wendall Cada @ 2004-10-28 20:02 UTC (permalink / raw
To: GentooPortage
Hello,
I've been using Gentoo on a couple production servers since January of
this year. I have been very happy with Gentoo on the server and it has
been very easy to administer and update until the introduction of
webapp-config and its related tools, file structures, etc.
I understand that the Gentoo web-apps are trying to conform more with
Linux standards. For instance, the move from /home to /var for the web
root. Many configuration file moves, etc, etc. Many of these have been
documented and discussed before hand. Recently however, I don't feel
this has been the case and tools like webapp-config have broken the use
of portage as a package maintainer and reduced it to a download utility.
Here is an example of why:
In the past if you wanted a web application, you could look through the
portage database of apps and do an:
emerge mywebapp
mywebapp is now installed and ready for use in
/var/www/localhost/htdocs/mywebapp
read configuration docs
configure apache
then use mywebapp
Now there is a similar install process.
emerge mywebapp
mywebapp is installed in
/usr/share/webapps/mywebapp/mywebappversion/htdocs/
webapp-config -I -d /var/www/localhost/htdocs/mywebapp
read configuration docs
use webapp-config to configure apache
then use mywebapp
Now the theory behind web-app config is good in that the author/authors
wanted to give the ability to let me use it on multiple sites from a
single install, manage virtual sites, etc. Forcing me to use something
to do installations outside of portage is a bad idea. Creating a
millions symlinks and/or hardlinks throughout my filesystem is a
horrible thing.
First, what if I want the ability to use portage to update and manage my
web-app, just like the other packages on my system? I can't unless I
write my own ebuilds to use portage for installing web-apps. If I have
a need for web-app config, let me make that choice. Please don't make
the choice for me. How long before someone comes along and decides my
Gnome desktop needs to be managed and installed with its own installer.
You guys may think that is ridiculous, but if someone would have told me
that portage would only be used for downloading web-apps last year, I
would have thought they were crazy. I don't or won't use the thing,
because it is not useful to me. Not for my desktop or on my server. I
have management tools I choose to use that suit my needs much better.
Also, many of the web-apps I use have virtual site capabilities built
in, and I prefer using the built-in tools they provide.
Many will argue that portage still does the updating, I disagree. If I
update mywebapp from version 1.1 to 1.2, the original install is deleted
from /usr/share/webapps/mywebapp/1.1/ and a new directory is created
/usr/share/webapps/mywebapp/1.2/ This isn't really updating the app.
Just deletes the old one and puts the new one in a different directory.
No different than if I just download the tarball and untar it myself.
Using the old portage method, I would have protected config files and
directories and the new files would be installed in the same directory
as the old one. I run the upgrade script for that particular app if
necessary and I'm up and running. The old method would be great in
conjunct use with webapp-config, but what if I don't want to use
webapp-config? It is rendered worthless to me without alot of advanced
scripting that is really unnecessary had webapp-config been left as an
optional tool.
If web-app config was a tool for me to use at my discretion, great. But
a tool that replaces the functionality of portage? That sucks no matter
how I look at it.
I have, as do other Gentoo web-app developers that I'll leave unnamed
many ideas about how this could be done better. My input is pointless if
webapp-config is the way things are going to be done. It really negates
the usefulness of many other tools. Was a roadmap created? Was anybody
who uses this stuff asked? Was it mentioned that portage would just
manage the downloading from here on out? Why weren't these features if
necessary made a part of portage?
Portage is a great tool for managing applications. I'd like to use it
for my entire Gentoo system.
Wendall
--
"Only the ideas that we really live have any value." --Hermann Hesse
(Demian)
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 20:02 [gentoo-portage-dev] webapp-config and webapps Wendall Cada
@ 2004-10-28 20:20 ` Paul de Vrieze
2004-10-28 20:34 ` Wendall Cada
2004-10-28 20:52 ` Grant Goodyear
1 sibling, 1 reply; 19+ messages in thread
From: Paul de Vrieze @ 2004-10-28 20:20 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On Thursday 28 October 2004 22:02, Wendall Cada wrote:
> Now the theory behind web-app config is good in that the author/authors
> wanted to give the ability to let me use it on multiple sites from a
> single install, manage virtual sites, etc. Forcing me to use something
> to do installations outside of portage is a bad idea. Creating a
> millions symlinks and/or hardlinks throughout my filesystem is a
> horrible thing.
The system should work in a way that such a separate install set is only
necessary when virtual host support is enabled. (In which case it makes
sense). If you have your system set up for single host webserving it is a bug
if things are not installed automatically.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 20:20 ` Paul de Vrieze
@ 2004-10-28 20:34 ` Wendall Cada
2004-10-28 20:55 ` Wendall Cada
2004-10-28 21:13 ` Stuart Herbert
0 siblings, 2 replies; 19+ messages in thread
From: Wendall Cada @ 2004-10-28 20:34 UTC (permalink / raw
To: gentoo-portage-dev
> The system should work in a way that such a separate install set is only
> necessary when virtual host support is enabled. (In which case it makes
> sense). If you have your system set up for single host webserving it is a bug
> if things are not installed automatically.
>
> Paul
I use a virual hosting environment, and do not want to use or enable
webapp-config. I also don't think that it is a good criteria to base the
use of the tool from. I have not found a way to disable it. As soon as
all webapps were converted over to it, I have had to use it or nothing.
I think it should be setup by the user if they need the functionality
and left out by default if not. Let portage do the job it was designed
for and toolkits to do the jobs they were designed for.
Wendall
--
"Only the ideas that we really live have any value." --Hermann Hesse
(Demian)
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 20:34 ` Wendall Cada
@ 2004-10-28 20:55 ` Wendall Cada
2004-10-28 21:19 ` Stuart Herbert
2004-10-28 21:28 ` Stuart Herbert
2004-10-28 21:13 ` Stuart Herbert
1 sibling, 2 replies; 19+ messages in thread
From: Wendall Cada @ 2004-10-28 20:55 UTC (permalink / raw
To: gentoo-portage-dev
Ok, I may have jumped the gun a bit. I gave read all the documents at
this point and read all the same bitches in the forums. I see reference
to -vhost which is in theory the default. Maybe on an new install. Not
on my existing installs. When the switch way made, it was done poorly.
Previous implementations should have been honored. Instead, it appeared
as though a user was forced to use webapp-config. Which I still believe
is the case for the most part. I can adjust to the new stuff, but I
think it needs some serious consideration from the portage devs as it
breaks the use of portage. If this is the way of the future, I guess I'm
stuck. Else, please consider moving back to making non-structural
changes be handled by portage.
Wendall
On Thu, 2004-10-28 at 13:34, Wendall Cada wrote:
> > The system should work in a way that such a separate install set is only
> > necessary when virtual host support is enabled. (In which case it makes
> > sense). If you have your system set up for single host webserving it is a bug
> > if things are not installed automatically.
> >
> > Paul
>
> I use a virual hosting environment, and do not want to use or enable
> webapp-config. I also don't think that it is a good criteria to base the
> use of the tool from. I have not found a way to disable it. As soon as
> all webapps were converted over to it, I have had to use it or nothing.
> I think it should be setup by the user if they need the functionality
> and left out by default if not. Let portage do the job it was designed
> for and toolkits to do the jobs they were designed for.
>
> Wendall
--
"Only the ideas that we really live have any value." --Hermann Hesse
(Demian)
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 20:55 ` Wendall Cada
@ 2004-10-28 21:19 ` Stuart Herbert
2004-10-28 21:28 ` Stuart Herbert
1 sibling, 0 replies; 19+ messages in thread
From: Stuart Herbert @ 2004-10-28 21:19 UTC (permalink / raw
To: gentoo-portage-dev
On Thursday 28 October 2004 21:55, Wendall Cada wrote:
> When the switch way made, it was done poorly.
How could we have done it better?
News items were published on www.gentoo.org, in GWN, and in a popular
magazine. Announcements were posted to Gentoo mailing lists.
The one thing we do lack is documentation on www.gentoo.org. However, the man
pages that come with webapp-config are very comprehensive.
> Previous implementations should have been honored.
Not possible, practical, or desirable. Sorry.
> If this is the way of the future, I guess I'm
> stuck. Else, please consider moving back to making non-structural
> changes be handled by portage.
What is it about webapp-config that concerns you?
Best regards,
Stu
--
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 20:55 ` Wendall Cada
2004-10-28 21:19 ` Stuart Herbert
@ 2004-10-28 21:28 ` Stuart Herbert
1 sibling, 0 replies; 19+ messages in thread
From: Stuart Herbert @ 2004-10-28 21:28 UTC (permalink / raw
To: gentoo-portage-dev
PS:
On Thursday 28 October 2004 21:55, Wendall Cada wrote:
> I see reference to -vhost which is in theory the default.
> Maybe on an new install. Not on my existing installs.
The default is indeed -vhosts, which tells Portage to automatically install a
copy of a web-based app into /var/www/localhost/htdocs/<app-name>/. Portage
does this by running webapp-config. You can find the code responsible
in /usr/portage/eclass/webapp.eclass.
> I gave read all the documents at this point and read all the same bitches
> in the forums.
If people are having trouble with webapp-config, it's a shame that they
haven't filed bugs or emailed me. My email address *is* included in the
AUTHOR section of the man pages ;-)
I don't read the forums very regularly. Could you post some URLs for some of
the threads? I'd be interested to read (and comment on) them.
Best regards,
Stu
--
Stuart Herbert stuart@gentoo.org
Gentoo Developer http://www.gentoo.org/
http://stu.gnqs.org/diary/
GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
--
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 20:34 ` Wendall Cada
2004-10-28 20:55 ` Wendall Cada
@ 2004-10-28 21:13 ` Stuart Herbert
2004-10-28 21:48 ` Anthony Gorecki
1 sibling, 1 reply; 19+ messages in thread
From: Stuart Herbert @ 2004-10-28 21:13 UTC (permalink / raw
To: gentoo-portage-dev
(Thanks to Paul for pointing me to this discussion)
On Thursday 28 October 2004 21:34, Wendall Cada wrote:
> I use a virual hosting environment, and do not want to use or enable
> webapp-config.
I respect your decision to choose not to use webapp-config. Is there any
particular reason why you don't want to use webapp-config?
> I also don't think that it is a good criteria to base the
> use of the tool from.
What criteria would you prefer?
At the moment, webapp-config is used whether or not you're using a virtual
hosting environment. The only difference is that webapp-config isn't
automatically executed if you have the 'vhosts' USE flag set.
> I have not found a way to disable it.
There currently isn't a way. It's certainly something I could make possible
though.
> As soon as
> all webapps were converted over to it, I have had to use it or nothing.
> I think it should be setup by the user if they need the functionality
> and left out by default if not.
If we leave it out, then we're back to the bad old days of Portage being
unable to install (and especially!) upgrade web-based applications.
This doesn't seem to be the best way to serve the majority of our users.
We know that webapp-config needs improvements, especially in the area of
auto-configuring web-based apps. Those improvements will be available
through Portage once they are ready. We could always use extra help ;-)
> Let portage do the job it was designed
> for and toolkits to do the jobs they were designed for.
webapp-config was introduced specifically *because* Portage can't install a
web-based application on its own. And it can't upgrade a web-based app on
its own either. These problems are well documented in GLEP 11
(http://glep.gentoo.org) and the references it cites.
Our goal in Gentoo is for packages to work after installation without
requiring manual configuration. We can't do that with Portage alone.
We could fold the code into Portage, but it would still have to work the same
way. The whole point of installing the code into /usr/share/webapps is to
vastly reduce wasted disk space on servers which need to host more than one
copy of the app.
Best regards,
Stu
--
Stuart Herbert stuart@gentoo.org
Gentoo Developer http://www.gentoo.org/
http://stu.gnqs.org/diary/
GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
--
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 21:13 ` Stuart Herbert
@ 2004-10-28 21:48 ` Anthony Gorecki
2004-10-28 22:13 ` Stuart Herbert
0 siblings, 1 reply; 19+ messages in thread
From: Anthony Gorecki @ 2004-10-28 21:48 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
On Thursday 28 October 2004 2:13 pm, Stuart Herbert wrote:
> On Thursday 28 October 2004 21:34, Wendall Cada wrote:
> > I use a virual hosting environment, and do not want to use or enable
> > webapp-config.
>
> I respect your decision to choose not to use webapp-config. Is there any
> particular reason why you don't want to use webapp-config?
I concur with Wendall's decision; I don't use it because I've found that it
creates -more- work than manually installing web applications. See your
comment on self-configuring web applications.
In addition, some web applications will download their own source files on
demand and update themselves on demand, in a manner similar to Portage.
webapp-config would be completely unsuitable for these applications.
As a second addition to the above, and in response to "Web applications should
not be owned by the same user as the web server," some web applications
-should- and are -designed and required- to be owned by the web server's
user.
An example of the aforementioned web application would be one that is also
responsible for managing the entire file hierarchy of a website: it must be
able to do so without any additional file ownership work-arounds (using FTP
to update the website is not acceptable).
In these cases, additional backend configuration is necessary to protect
websites from unauthorized access (PHP's open_basedir, for example), however
this would be soley the responsibility of web host and the script.
webapp-config should be completely oblivious to this, as these safeguards
would obviously beyond the scope of the program; however, it should support
the functionality if it is required.
> At the moment, webapp-config is used whether or not you're using a virtual
> hosting environment. The only difference is that webapp-config isn't
> automatically executed if you have the 'vhosts' USE flag set.
If the vhost flag is not set, is there a way to alter the install location
from /var/www/localhost? If there isn't, why isn't there? I haven't had a
chance to look through all of the software resources for this program, though
I haven't seen anything helpful this far.
--
Anthony Gorecki
Ectro-Linux Foundation
[-- Attachment #2: Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 21:48 ` Anthony Gorecki
@ 2004-10-28 22:13 ` Stuart Herbert
2004-10-28 22:52 ` Anthony Gorecki
0 siblings, 1 reply; 19+ messages in thread
From: Stuart Herbert @ 2004-10-28 22:13 UTC (permalink / raw
To: gentoo-portage-dev
On Thursday 28 October 2004 22:48, Anthony Gorecki wrote:
> I concur with Wendall's decision; I don't use it because I've found that it
> creates -more- work than manually installing web applications. See your
> comment on self-configuring web applications.
Hrm ... I haven't made any comment on self-configuring web applications.
> In addition, some web applications will download their own source files on
> demand and update themselves on demand, in a manner similar to Portage.
> webapp-config would be completely unsuitable for these applications.
And so is Portage ;-)
Until UPSTREAM apps play nicely, this will always be a problem with any tool
that anyone writes. And UPSTREAM can't play nicely until there's a tool to
play nicely with.
> As a second addition to the above, and in response to "Web applications
> should not be owned by the same user as the web server," some web
> applications -should- and are -designed and required- to be owned by the
> web server's user.
webapp-config copes with this just fine; Portage cannot. It also allows you
to have application config files owned by a different shell user if you need.
We're also looking at adding support for alternative MPM's for Apache 2, so
that individual websites can be wholy owned by a single shell account, for
added security.
> In these cases, additional backend configuration is necessary to protect
> websites from unauthorized access (PHP's open_basedir, for example),
> however this would be soley the responsibility of web host and the script.
The next version of webapp-config will be able to handle that sort of
configuration too. We need to provide a tool to do it; we can't expect all
of our users to have the skills to secure a PHP app by hand.
> webapp-config should be completely oblivious to this, as these safeguards
> would obviously beyond the scope of the program; however, it should support
> the functionality if it is required.
Why 'obviously' beyond the scope?
Every web-based app installed on practically every platform out there is
hampered by the limited capabilities of package managers and current
automated installers.
We're going to have to get there a step at a time, but I think it's worth the
effort.
> If the vhost flag is not set, is there a way to alter the install location
> from /var/www/localhost? If there isn't, why isn't there? I haven't had a
> chance to look through all of the software resources for this program,
> though I haven't seen anything helpful this far.
Take a look at /etc/vhosts/webapp-config and the man page for webapp-config.5.
The support you need is there. I don't run any of own sites from /var/www.
'localhost' *is* currently hard-coded as the hostname that an app is installed
into when USE=-vhosts. This is something we can change.
Best regards,
Stu
--
Stuart Herbert stuart@gentoo.org
Gentoo Developer http://www.gentoo.org/
http://stu.gnqs.org/diary/
GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
--
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 22:13 ` Stuart Herbert
@ 2004-10-28 22:52 ` Anthony Gorecki
2004-10-28 23:31 ` Stuart Herbert
0 siblings, 1 reply; 19+ messages in thread
From: Anthony Gorecki @ 2004-10-28 22:52 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 4487 bytes --]
On Thursday 28 October 2004 3:13 pm, Stuart Herbert wrote:
> Hrm ... I haven't made any comment on self-configuring web applications.
"We know that webapp-config needs improvements, especially in the area of
auto-configuring web-based apps."
> > In addition, some web applications will download their own source files
> > on demand and update themselves on demand, in a manner similar to
> > Portage. webapp-config would be completely unsuitable for these
> > applications.
>
> And so is Portage ;-)
>
> Until UPSTREAM apps play nicely, this will always be a problem with any
> tool that anyone writes. And UPSTREAM can't play nicely until there's a
> tool to play nicely with.
And in the case of the above, the tip of a sword is as close to playing nicely
as those applications will come.
*sighs at his application frameworks*
> > In these cases, additional backend configuration is necessary
>
> The next version of webapp-config will be able to handle that sort of
> configuration too. We need to provide a tool to do it; we can't expect all
> of our users to have the skills to secure a PHP app by hand.
I personally would not trust webapp-config to reconfigure my web server or
modify web service configuration files, especially considering that I
replaced the stock configurations with my own as soon as I installed Apache.
How would you implement an automatic open_basedir restriction in PHP, after a
web application was installed? I certainly wouldn't want my Apache processes
receiving a SIGHUP after every software installation to reload the
configuration, which is the only place open_basedir may be altered.
Compounding the problem, many scripts heavily modify the PHP runtime
configuration directives: how would an automated tool be able to factor in
all the necessary information for every web application? This doesn't seem
realistic.
IMHO, an automated tool would never be suitable for securing a web
environment, composed of a non-homogeneous solution of different
applications. I simply don't see how it's possible to secure against every
possible method of script exploitation (or even a marginal majority) for
every web language (or even one web language), without knowing the specific
workings of the scripts in question.
As an "upstream provider," I would also never waste my time providing the
specifications to any tool designed for such purposes.
I can take the necessary steps to reasonably secure my web services and can
provide information that would instruct others on how to do the same, however
there is no way I could explain every possible combination of every possible
scenario to every possible user on every possible configuration. It doesn't
make sense, it's not practical and it's not feasible; the same applies for a
unified "secure-it" tool, regardless of how idealistic the principle of its
creation.
> > webapp-config should be completely oblivious to this, as these safeguards
> > would obviously beyond the scope of the program; however, it should
> > support the functionality if it is required.
>
> Why 'obviously' beyond the scope?
See the above.
> Every web-based app installed on practically every platform out there is
> hampered by the limited capabilities of package managers and current
> automated installers.
>
> We're going to have to get there a step at a time, but I think it's worth
> the effort.
Is it? A large number of hosting providers do not even allow their clients to
access a shell console, nevermind Portage derivatives. In the same way, I
would never allow one of my -client's- web applications to have any influence
whatsoever on the operations of -my- web server. Most websites have no
concept of a package manager, in the traditional sense: this is why my web
applications provide their own means of filesystem management and software
updates. At present, the only viable package management system I see for web
applications is one they provide themselves.
> Take a look at /etc/vhosts/webapp-config and the man page for
> webapp-config.5. The support you need is there. I don't run any of own
> sites from /var/www.
Thanks for the clarification.
> 'localhost' *is* currently hard-coded as the hostname that an app is
> installed into when USE=-vhosts. This is something we can change.
Please feel free :)
--
Anthony Gorecki
Ectro-Linux Foundation
[-- Attachment #2: Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 22:52 ` Anthony Gorecki
@ 2004-10-28 23:31 ` Stuart Herbert
2004-10-29 1:04 ` Anthony Gorecki
2004-10-29 9:55 ` Paul de Vrieze
0 siblings, 2 replies; 19+ messages in thread
From: Stuart Herbert @ 2004-10-28 23:31 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 6419 bytes --]
On Thursday 28 October 2004 23:52, Anthony Gorecki wrote:
> On Thursday 28 October 2004 3:13 pm, Stuart Herbert wrote:
> > Hrm ... I haven't made any comment on self-configuring web applications.
>
> "We know that webapp-config needs improvements, especially in the area of
> auto-configuring web-based apps."
That's auto-configuration, not self-configuration. There are web-based apps
out there with their own (normally web-based) configuration support. That's
what I'd call self-configuration.
> And in the case of the above, the tip of a sword is as close to playing
> nicely as those applications will come.
>
> *sighs at his application frameworks*
That's true today. It'll stay true tomorrow if no-one does anything to try
and change it. But if we try - who knows what we can achieve?
> I personally would not trust webapp-config to reconfigure my web server or
> modify web service configuration files, especially considering that I
> replaced the stock configurations with my own as soon as I installed
> Apache.
> How would you implement an automatic open_basedir restriction in
> PHP, after a web application was installed?
open_basedir can only be set in php.ini or the Apache config file.
It's always best to avoid setting anything other than system-wide defaults in
php.ini.
I'd do what I do on my boxes at work. I'd create a per-app-instance config
file which contained the necessary settings, and have apache include it the
next time it was SIGHUP'd.
How would I decide whether an open_basedir restriction was required? That is
a policy decision, which would be managed through the vhost-tools.
> I certainly wouldn't want my
> Apache processes receiving a SIGHUP after every software installation to
> reload the configuration, which is the only place open_basedir may be
> altered.
The SIGHUP is required for a change to take effect. That doesn't prevent any
tool from putting the configuration in place ready for a scheduled change.
Again, scheduling config reloads is a policy decision, which could be managed
through the vhost-tools.
> Compounding the problem, many scripts heavily modify the PHP runtime
> configuration directives: how would an automated tool be able to factor in
> all the necessary information for every web application? This doesn't seem
> realistic.
You're assuming that the tool has to learn about each app, me thinks. That's
not what I intend to do. I'm intending to provide tools which will generate
config files for the various apps - and which will get the information from
config files maintained by the local administrator.
There aren't that many scripts that modify php.ini - and any script that does
is (as far as I'm concerned) broken.
> IMHO, an automated tool would never be suitable for securing a web
> environment, composed of a non-homogeneous solution of different
> applications. I simply don't see how it's possible to secure against every
> possible method of script exploitation (or even a marginal majority) for
> every web language (or even one web language), without knowing the specific
> workings of the scripts in question.
I hope to prove you wrong in time.
> As an "upstream provider," I would also never waste my time providing the
> specifications to any tool designed for such purposes.
I'm sorry to hear that you think it's a waste of time to try and improve the
ease of installation of your packages.
> I can take the necessary steps to reasonably secure my web services and can
> provide information that would instruct others on how to do the same,
> however there is no way I could explain every possible combination of every
> possible scenario to every possible user on every possible configuration.
Why are there so many scenarios where your services would be insecure?
> It doesn't make sense,
If it's too complicated to do by hand, then it definitely needs automating
> it's not practical and it's not feasible;
When was the last time you installed a Windows application by hand? Or a
non-web-app on Linux? Most apps in the world can be installed automatically;
there's no reason why web-based apps should be treated as a special case.
> Is it? A large number of hosting providers do not even allow their clients
> to access a shell console, nevermind Portage derivatives. In the same way,
> I would never allow one of my -client's- web applications to have any
> influence whatsoever on the operations of -my- web server. Most websites
> have no concept of a package manager, in the traditional sense: this is why
> my web applications provide their own means of filesystem management and
> software updates. At present, the only viable package management system I
> see for web applications is one they provide themselves.
My experience is different from yours. Aside from the '50Mb free with your
dial-up account' type hosting, most of the hosting over here in the UK
provides shell access.
It's not possible to support non-privileged users running webapp-config with
the default Apache 2 MPM, as these users can't perform the chown operations
that the tool needs to do. We could provide a setuid-safe script to do this,
but that's not top of my todo list.
The problem with each web-based package providing its own package management
is that you're left with widely varying quality. You also have the problem
that it's harder to lock down a site and prevent unauthorised change. And
these tools don't work too well on secured and/or disconnected intranets (and
these are surprising common in the public sector at least). Tools that
extend Portage - tools that allow for disconnected upgrades - still have
their advantages :)
What you describe is how things are today. If the tools existed to do these
things for you, would you still want to live in today? Even if you do, there
are plenty of people out there who do not.
Best regards,
Stu
--
Stuart Herbert stuart@gentoo.org
Gentoo Developer http://www.gentoo.org/
http://stu.gnqs.org/diary/
GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
--
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 23:31 ` Stuart Herbert
@ 2004-10-29 1:04 ` Anthony Gorecki
2004-10-29 9:55 ` Paul de Vrieze
1 sibling, 0 replies; 19+ messages in thread
From: Anthony Gorecki @ 2004-10-29 1:04 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 4535 bytes --]
On Thursday 28 October 2004 4:31 pm, Stuart Herbert wrote:
> That's auto-configuration, not self-configuration. There are web-based
> apps out there with their own (normally web-based) configuration support.
> That's what I'd call self-configuration.
I'm unclear as to where you differentiate. An automated installer configures
an application in much the same manner as a reconfiguration engine in a
script that's already been installed. Wouldn't any userspace tool be
essentially accomplishing the same thing?
> It's always best to avoid setting anything other than system-wide defaults
> in php.ini.
I agree. I have PHP engine disabled in the global configuration file, and only
enable it on a virtual-host basis where needed, with the appropriate
filesystem restrictions.
> How would I decide whether an open_basedir restriction was required? That
> is a policy decision, which would be managed through the vhost-tools.
What about the users who don't want to use vhost-tools?
> The SIGHUP is required for a change to take effect. That doesn't prevent
> any tool from putting the configuration in place ready for a scheduled
> change.
Granted, however that would leave the web application broken or disabled at
best, and vunerable to attack at worst. I don't see how this would work with
proprietary virtual host configurations.
> I'm intending to provide tools which will
> generate config files for the various apps - and which will get the
> information from config files maintained by the local administrator.
By "config files" do you mean on a per-package basis, or config files for the
web application to use?
I don't see any problems in developing the latter if the generator was
properly programmed with the configuration requirements of the web
application, however the former gives me pause: the exact requirements of
each script can be quite complex. Would a normal developer who wasn't
involved with the software be able to outline these correctly, and in a
usable fashion?
> There aren't that many scripts that modify php.ini - and any script that
> does is (as far as I'm concerned) broken.
Not only the script, but the php.ini file permissions, for allowing such a
change to be made.
> > As an "upstream provider," I would also never waste my time providing the
> > specifications to any tool designed for such purposes.
>
> I'm sorry to hear that you think it's a waste of time to try and improve
> the ease of installation of your packages.
I should have phrased my reply more clearly: Supporting a tool designed to
make software installation easier isn't something I would make objections
towards, however supporting a tool that makes the upstream provider jump
through hoops while bending over backwards is not tolerable.
> Why are there so many scenarios where your services would be insecure?
With the PHP language, how many ways could an expert programmer compromise a
poorly configured or poorly protected server environment?
> When was the last time you installed a Windows application by hand? Or a
> non-web-app on Linux? Most apps in the world can be installed
> automatically; there's no reason why web-based apps should be treated as a
> special case.
I agree, I just don't see a feasible way of accomplishing the same result
using an automated system, with current technologies and methodologies.
> My experience is different from yours. Aside from the '50Mb free with your
> dial-up account' type hosting, most of the hosting over here in the UK
> provides shell access.
Perhaps this is worthy of a user survey? I would be interested in seeing the
actual percentages of those who have access to this feature, from a sampling
of hostees.
> The problem with each web-based package providing its own package
> management is that you're left with widely varying quality.
Hence the same need for some type of standardized solution.
> You also have
> the problem that it's harder to lock down a site and prevent unauthorised
> change.
Perhaps, although I believe strong arguments could be made for either side.
> And these tools don't work too well on secured and/or disconnected
> intranets (and these are surprising common in the public sector at least).
> Tools that extend Portage - tools that allow for disconnected upgrades -
> still have their advantages :)
I agree.
--
Anthony Gorecki
Ectro-Linux Foundation
[-- Attachment #2: Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 23:31 ` Stuart Herbert
2004-10-29 1:04 ` Anthony Gorecki
@ 2004-10-29 9:55 ` Paul de Vrieze
2004-10-30 10:17 ` Stuart Herbert
1 sibling, 1 reply; 19+ messages in thread
From: Paul de Vrieze @ 2004-10-29 9:55 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
On Friday 29 October 2004 01:31, Stuart Herbert wrote:
> It's not possible to support non-privileged users running webapp-config
> with the default Apache 2 MPM, as these users can't perform the chown
> operations that the tool needs to do. We could provide a setuid-safe
> script to do this, but that's not top of my todo list.
Let's say how I would do this if I were an administrator for such a server.
Well I'd take the easy road of doing the following:
- Make a webpage that users/customers can select the desired webapps for their
virtual host, including the version. With a big-fat warning that
autoupdating by the app itself doesn't work.
- Have that webpage append to a pending-transformation list.
- Have a root cronjob that parses (strictly) the pending-transformation list
and runs webapp-config for eacht of those transformations. Then the pending
list is flushed.
As the administrator I now only need to select the offered apps, the rest is
left to the users.
> The problem with each web-based package providing its own package
> management is that you're left with widely varying quality. You also have
> the problem that it's harder to lock down a site and prevent unauthorised
> change. And these tools don't work too well on secured and/or disconnected
> intranets (and these are surprising common in the public sector at least).
> Tools that extend Portage - tools that allow for disconnected upgrades -
> still have their advantages :)
I still consider it bad design. Even though I understand the reasons.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-29 9:55 ` Paul de Vrieze
@ 2004-10-30 10:17 ` Stuart Herbert
2004-10-30 21:24 ` Paul de Vrieze
0 siblings, 1 reply; 19+ messages in thread
From: Stuart Herbert @ 2004-10-30 10:17 UTC (permalink / raw
To: gentoo-portage-dev
On Friday 29 October 2004 10:55, Paul de Vrieze wrote:
> Let's say how I would do this if I were an administrator for such a server.
> Well I'd take the easy road of doing the following:
> - Make a webpage that users/customers can select the desired webapps for
> their virtual host, including the version. With a big-fat warning that
> autoupdating by the app itself doesn't work.
> - Have that webpage append to a pending-transformation list.
> - Have a root cronjob that parses (strictly) the pending-transformation
> list and runs webapp-config for eacht of those transformations. Then the
> pending list is flushed.
>
> As the administrator I now only need to select the offered apps, the rest
> is left to the users.
/me nods. I want to make it possible for others to write that kind of app.
But you don't need webapp-config to be setuid to do that. All you need to do
is ensure that all files are owned by the user that apache runs as.
You can achieve that securely by using the experimental perchild MPM (which
will soon be available through Portage), or by running each site in its own
chroot environment.
> I still consider it bad design. Even though I understand the reasons.
Sorry - that statement's ambiguious. What's the "it" that you are refering
to?
Best regards,
Stu
--
Stuart Herbert stuart@gentoo.org
Gentoo Developer http://www.gentoo.org/
http://stu.gnqs.org/diary/
GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
--
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] webapp-config and webapps
2004-10-28 20:02 [gentoo-portage-dev] webapp-config and webapps Wendall Cada
2004-10-28 20:20 ` Paul de Vrieze
@ 2004-10-28 20:52 ` Grant Goodyear
2004-10-31 16:38 ` [gentoo-portage-dev] Setting an env var for a specific ebuild felix
1 sibling, 1 reply; 19+ messages in thread
From: Grant Goodyear @ 2004-10-28 20:52 UTC (permalink / raw
To: GentooPortage
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
Wendall Cada wrote: [Thu Oct 28 2004, 03:02:38PM CDT]
> I have, as do other Gentoo web-app developers that I'll leave unnamed
> many ideas about how this could be done better. My input is pointless if
> webapp-config is the way things are going to be done. It really negates
> the usefulness of many other tools. Was a roadmap created? Was anybody
> who uses this stuff asked? Was it mentioned that portage would just
> manage the downloading from here on out? Why weren't these features if
> necessary made a part of portage?
The "roadmap" was, indeed, created, and discussed in length on the
gentoo-dev mailing list. Take a look at GLEP 11 at glep.gentoo.org,
and search one of the gentoo-dev list archives to see the entire
discusion.
If you have a better idea, please do feel free to write your own GLEP.
Very little in Gentoo is ever set in stone, so if your idea is better
than the current system, and you or somebody else is willing to provide
the code to implement it, then the odds are high that it will be
adopted.
Best,
g2boojum
--
Grant Goodyear
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-portage-dev] Setting an env var for a specific ebuild
2004-10-28 20:52 ` Grant Goodyear
@ 2004-10-31 16:38 ` felix
2004-10-31 17:02 ` Sri Gupta
0 siblings, 1 reply; 19+ messages in thread
From: felix @ 2004-10-31 16:38 UTC (permalink / raw
To: gentoo-portage-dev
I have a problem with building Apache and have not found any answers
in searching the forums or asking. Please let me know if this is not
the right place to ask.
Apache uses a wrapper called suexec to run setuid cgi programs. As
part of its security check, suexec refuses to run any program whose
location does not match a compiled-in path, which by default is
.../public_html/... Note that this path is NOT picked up from the run
time configuration, but from the build time configuration.
The net-www/apache-2.0.52-ebuild sets this build time value with an
env var:
apache_setup_vars() {
# Sets the USERDIR to default.
USERDIR="public_html"
But I have always used a different USERDIR value, and do not know how
to override this. I have resorted to editing the ebuild directly,
which means that I forget it on every upgrade and have to scratch my
head every time the first suexec program fails. I am getting quicker
at diagnosing the problem :-)
Of course editing the ebuild is not the right way to do it, but I have
not found any way of setting an override in /etc/portage or anywhere
else. I don't see how my own usr/local/portage ebuild would help; I'd
have to copy it from /usr/portage and edit anyway.
Is there a better way, or any way, to set a more-or-less permanent
override of this env var?
On an unrelated subject, rebuilding imagemagick found a conflicting
file, libltdl.a ...
media-gfx/imagemagick-6.1.0.1 (/usr/lib/libltdl.a)
sys-devel/libtool-1.5.2-r5 (/usr/lib/libltdl.a)
I have never enjoyed using bugzilla, it seems like the kind of
bureaucratic molasses that a faceless corporation would set up to show
compliance with the letter of a court order while actually
discouraging its use. Is there any other way, or has bugzilla gotten
better in the year or two since I last tried it elsewhere?
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] Setting an env var for a specific ebuild
2004-10-31 16:38 ` [gentoo-portage-dev] Setting an env var for a specific ebuild felix
@ 2004-10-31 17:02 ` Sri Gupta
2004-10-31 18:22 ` Michael Stewart
0 siblings, 1 reply; 19+ messages in thread
From: Sri Gupta @ 2004-10-31 17:02 UTC (permalink / raw
To: gentoo-portage-dev
On Sun, Oct 31, 2004 at 08:38:51AM -0800, felix@crowfix.com wrote:
> I have a problem with building Apache and have not found any answers
> in searching the forums or asking. Please let me know if this is not
> the right place to ask.
>
> Apache uses a wrapper called suexec to run setuid cgi programs. As
> part of its security check, suexec refuses to run any program whose
> location does not match a compiled-in path, which by default is
> .../public_html/... Note that this path is NOT picked up from the run
> time configuration, but from the build time configuration.
>
> The net-www/apache-2.0.52-ebuild sets this build time value with an
> env var:
>
> apache_setup_vars() {
> # Sets the USERDIR to default.
> USERDIR="public_html"
>
> But I have always used a different USERDIR value, and do not know how
> to override this. I have resorted to editing the ebuild directly,
> which means that I forget it on every upgrade and have to scratch my
> head every time the first suexec program fails. I am getting quicker
> at diagnosing the problem :-)
>
> Of course editing the ebuild is not the right way to do it, but I have
> not found any way of setting an override in /etc/portage or anywhere
> else. I don't see how my own usr/local/portage ebuild would help; I'd
> have to copy it from /usr/portage and edit anyway.
>
> Is there a better way, or any way, to set a more-or-less permanent
> override of this env var?
This mailing list is more for portage development.
Gentoo-server would be a better one to ask on.
anyway, I have the same problem, and usually edit the ebuild every upgrade.
I haven't found a more graceful way to change the suexec path.
-Sri
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-portage-dev] Setting an env var for a specific ebuild
2004-10-31 17:02 ` Sri Gupta
@ 2004-10-31 18:22 ` Michael Stewart
0 siblings, 0 replies; 19+ messages in thread
From: Michael Stewart @ 2004-10-31 18:22 UTC (permalink / raw
To: gentoo-portage-dev
Sri Gupta wrote:
>>Apache uses a wrapper called suexec to run setuid cgi programs. As
>>part of its security check, suexec refuses to run any program whose
>>location does not match a compiled-in path, which by default is
>>.../public_html/... Note that this path is NOT picked up from the run
>>time configuration, but from the build time configuration.
>
> I have the same problem, and usually edit the ebuild every upgrade.
> I haven't found a more graceful way to change the suexec path.
I am currently working on a fix for this. You may track it's progress at
http://bugs.gentoo.org/show_bug.cgi?id=66397
~vericgar
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2004-10-31 18:21 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-28 20:02 [gentoo-portage-dev] webapp-config and webapps Wendall Cada
2004-10-28 20:20 ` Paul de Vrieze
2004-10-28 20:34 ` Wendall Cada
2004-10-28 20:55 ` Wendall Cada
2004-10-28 21:19 ` Stuart Herbert
2004-10-28 21:28 ` Stuart Herbert
2004-10-28 21:13 ` Stuart Herbert
2004-10-28 21:48 ` Anthony Gorecki
2004-10-28 22:13 ` Stuart Herbert
2004-10-28 22:52 ` Anthony Gorecki
2004-10-28 23:31 ` Stuart Herbert
2004-10-29 1:04 ` Anthony Gorecki
2004-10-29 9:55 ` Paul de Vrieze
2004-10-30 10:17 ` Stuart Herbert
2004-10-30 21:24 ` Paul de Vrieze
2004-10-28 20:52 ` Grant Goodyear
2004-10-31 16:38 ` [gentoo-portage-dev] Setting an env var for a specific ebuild felix
2004-10-31 17:02 ` Sri Gupta
2004-10-31 18:22 ` Michael Stewart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox