[gentoo-portage-dev] webapp-config and webapps

[gentoo-portage-dev] webapp-config and webapps

[Wendall Cada]

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

Re: [gentoo-portage-dev] webapp-config and webapps

[Paul de Vrieze]

[-- 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 --]

Re: [gentoo-portage-dev] webapp-config and webapps

[Wendall Cada]

> 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

Re: [gentoo-portage-dev] webapp-config and webapps

[Grant Goodyear]

[-- 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 --]

Re: [gentoo-portage-dev] webapp-config and webapps

[Wendall Cada]

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

Re: [gentoo-portage-dev] webapp-config and webapps

[Stuart Herbert]

(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

Re: [gentoo-portage-dev] webapp-config and webapps

[Stuart Herbert]

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

Re: [gentoo-portage-dev] webapp-config and webapps

[Stuart Herbert]

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

Re: [gentoo-portage-dev] webapp-config and webapps

[Anthony Gorecki]

[-- 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 --]

Re: [gentoo-portage-dev] webapp-config and webapps

[Stuart Herbert]

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

Re: [gentoo-portage-dev] webapp-config and webapps

[Anthony Gorecki]

[-- 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 --]

Re: [gentoo-portage-dev] webapp-config and webapps

[Stuart Herbert]

[-- 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 --]

Re: [gentoo-portage-dev] webapp-config and webapps

[Anthony Gorecki]

[-- 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 --]

Re: [gentoo-portage-dev] webapp-config and webapps

[Paul de Vrieze]

[-- 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 --]

Re: [gentoo-portage-dev] webapp-config and webapps

[Stuart Herbert]

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

Re: [gentoo-portage-dev] webapp-config and webapps

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Saturday 30 October 2004 12:17, Stuart Herbert wrote:
> > 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?

Sorry, it in this case is those packages providing their own management 
system, often in effect meaning that the security is worse than that of 
windows. Applications should allways be able to run when they are not 
owned/writeable by the user that runs them.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-portage-dev] Setting an env var for a specific ebuild

[felix]

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

Re: [gentoo-portage-dev] Setting an env var for a specific ebuild

[Sri Gupta]

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

Re: [gentoo-portage-dev] Setting an env var for a specific ebuild

[Michael Stewart]

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