| 1 |
On Thursday 28 October 2004 4:31 pm, Stuart Herbert wrote: |
| 2 |
> That's auto-configuration, not self-configuration. There are web-based |
| 3 |
> apps out there with their own (normally web-based) configuration support. |
| 4 |
> That's what I'd call self-configuration. |
| 5 |
|
| 6 |
I'm unclear as to where you differentiate. An automated installer configures |
| 7 |
an application in much the same manner as a reconfiguration engine in a |
| 8 |
script that's already been installed. Wouldn't any userspace tool be |
| 9 |
essentially accomplishing the same thing? |
| 10 |
|
| 11 |
|
| 12 |
> It's always best to avoid setting anything other than system-wide defaults |
| 13 |
> in php.ini. |
| 14 |
|
| 15 |
I agree. I have PHP engine disabled in the global configuration file, and only |
| 16 |
enable it on a virtual-host basis where needed, with the appropriate |
| 17 |
filesystem restrictions. |
| 18 |
|
| 19 |
|
| 20 |
> How would I decide whether an open_basedir restriction was required? That |
| 21 |
> is a policy decision, which would be managed through the vhost-tools. |
| 22 |
|
| 23 |
What about the users who don't want to use vhost-tools? |
| 24 |
|
| 25 |
|
| 26 |
> The SIGHUP is required for a change to take effect. That doesn't prevent |
| 27 |
> any tool from putting the configuration in place ready for a scheduled |
| 28 |
> change. |
| 29 |
|
| 30 |
Granted, however that would leave the web application broken or disabled at |
| 31 |
best, and vunerable to attack at worst. I don't see how this would work with |
| 32 |
proprietary virtual host configurations. |
| 33 |
|
| 34 |
|
| 35 |
> I'm intending to provide tools which will |
| 36 |
> generate config files for the various apps - and which will get the |
| 37 |
> information from config files maintained by the local administrator. |
| 38 |
|
| 39 |
By "config files" do you mean on a per-package basis, or config files for the |
| 40 |
web application to use? |
| 41 |
|
| 42 |
I don't see any problems in developing the latter if the generator was |
| 43 |
properly programmed with the configuration requirements of the web |
| 44 |
application, however the former gives me pause: the exact requirements of |
| 45 |
each script can be quite complex. Would a normal developer who wasn't |
| 46 |
involved with the software be able to outline these correctly, and in a |
| 47 |
usable fashion? |
| 48 |
|
| 49 |
|
| 50 |
> There aren't that many scripts that modify php.ini - and any script that |
| 51 |
> does is (as far as I'm concerned) broken. |
| 52 |
|
| 53 |
Not only the script, but the php.ini file permissions, for allowing such a |
| 54 |
change to be made. |
| 55 |
|
| 56 |
|
| 57 |
> > As an "upstream provider," I would also never waste my time providing the |
| 58 |
> > specifications to any tool designed for such purposes. |
| 59 |
> |
| 60 |
> I'm sorry to hear that you think it's a waste of time to try and improve |
| 61 |
> the ease of installation of your packages. |
| 62 |
|
| 63 |
I should have phrased my reply more clearly: Supporting a tool designed to |
| 64 |
make software installation easier isn't something I would make objections |
| 65 |
towards, however supporting a tool that makes the upstream provider jump |
| 66 |
through hoops while bending over backwards is not tolerable. |
| 67 |
|
| 68 |
|
| 69 |
> Why are there so many scenarios where your services would be insecure? |
| 70 |
|
| 71 |
With the PHP language, how many ways could an expert programmer compromise a |
| 72 |
poorly configured or poorly protected server environment? |
| 73 |
|
| 74 |
|
| 75 |
> When was the last time you installed a Windows application by hand? Or a |
| 76 |
> non-web-app on Linux? Most apps in the world can be installed |
| 77 |
> automatically; there's no reason why web-based apps should be treated as a |
| 78 |
> special case. |
| 79 |
|
| 80 |
I agree, I just don't see a feasible way of accomplishing the same result |
| 81 |
using an automated system, with current technologies and methodologies. |
| 82 |
|
| 83 |
|
| 84 |
> My experience is different from yours. Aside from the '50Mb free with your |
| 85 |
> dial-up account' type hosting, most of the hosting over here in the UK |
| 86 |
> provides shell access. |
| 87 |
|
| 88 |
Perhaps this is worthy of a user survey? I would be interested in seeing the |
| 89 |
actual percentages of those who have access to this feature, from a sampling |
| 90 |
of hostees. |
| 91 |
|
| 92 |
|
| 93 |
> The problem with each web-based package providing its own package |
| 94 |
> management is that you're left with widely varying quality. |
| 95 |
|
| 96 |
Hence the same need for some type of standardized solution. |
| 97 |
|
| 98 |
|
| 99 |
> You also have |
| 100 |
> the problem that it's harder to lock down a site and prevent unauthorised |
| 101 |
> change. |
| 102 |
|
| 103 |
Perhaps, although I believe strong arguments could be made for either side. |
| 104 |
|
| 105 |
|
| 106 |
> And these tools don't work too well on secured and/or disconnected |
| 107 |
> intranets (and these are surprising common in the public sector at least). |
| 108 |
> Tools that extend Portage - tools that allow for disconnected upgrades - |
| 109 |
> still have their advantages :) |
| 110 |
|
| 111 |
I agree. |
| 112 |
|
| 113 |
|
| 114 |
-- |
| 115 |
Anthony Gorecki |
| 116 |
Ectro-Linux Foundation |
Archives