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