[pmwiki-devel] One click installation process...

The Editor editor at fast.st
Sun Nov 26 18:38:18 CST 2006


On 11/26/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Sun, Nov 26, 2006 at 11:52:43AM -0500, The Editor wrote:
> > Someone just posted a suggestion for a one click module installation
> > feature.  After a bit of thought, it occurred to me something like
> > this might be reasonably doable...  Thought I would post some ideas
> > and see if there was any feedback.
>
> For security reasons, it's almost a non-starter.  Consider:
>
> > First, for a one click module installation feature, we'd need to 1)
> > have a way to automatically download the recipe (so we don't have to
> > include them all automatically with the basic download).
>
> Ick.  This means that the directory containing recipes (i.e.,
> executable code) has to be writable by the webserver.  Bad.
>
> > And 2)
> > automatically write one or more lines to the configuration file to
> > enable it.
>
> Ick.  This means that the (executable) configuration files have to be
> writable by the webserver.  Also Bad.
>
> Personally, I think the automatic download of scripts is in general
> a bad idea -- indeed, this is why PmWiki doesn't have something
> like an "?action=upgrade" feature to automatically upgrade the PmWiki
> software.  To me, it's just too dangerous to have the script files and
> script directories writable by the webserver.

Pm, you have my confidence and I KNOW I don't fully understand all the
permissions stuff, BUT...  If I understand you right, you are saying
certain folders should have chmod set so you can't write to (or read?)
by the webserver--requiring you to use ftp or some editor on the
server. These folders include: local, scripts, cookbook.  The wiki d
folder is the only one that is supposed to be writable, eh, plus
uploads.  The pub directory and wikilib.d are readable, but not
writable.  Am I correct?

Actually, is there a place somewhere that says what permissions the
PmWiki folders should have?  I have had trouble on several uploads
where permissions were not set right and I had a fair bit of trouble
getting things to finally work.  In the process I realize now I may
not have all my folders reset properly but don't really know how to
check...  Like what numbers, where?  755, 644, etc.

> So, at best we could provide a web interface for configuring
> recipes, but no matter how good the interface is, we'll always be
> limited to only handling a subset of the available options and
> features.  There would always be some things that could only
> be done directly in .php configuration files.  And just as a person
> with two clocks is never certain of the time, an admin with two or
> more configuration interfaces has to worry about how the settings
> in one interface are interacting with the settings of the other.
>
> (PITS #00394 has some similar discussion on this topic.)

When I was doing Drupal, it was a nightmare getting things installed,
upgraded, etc., mostly because it was database driven.  Many modules I
never could get to work.  However, it did have a nice module
*interface*.  After you downloaded a module and unzipped it to your
module folder (I forget the details), you had to go to a certain web
page (like Site.Modules) to enable it.  This page (I presume) scanned
the modules folder, listed all the possible modules, and put
checkboxes beside them for enabling/disabling.  Plus, if there were
configuration options, there was something like a link to a setup page
where those options could be set.  And perhaps help pages.

What about an approach like this?  The user would still download the
recipe and upload to his server manually.  Then there would have to be
some kind of writable modules list (perhaps like a .htconfig file or
something) that simply listed enabled modules--which PmWiki would read
and do the includes for.  Any configuration variables for the recipe
could somehow, perhaps, be stored in this file, or left to the config
files as usual.  I actually suspect most recipes only require setting
config variables when you are changing from default behavior.

Anyway, this way no php pages/folders would be writable and we could
make enabling most recipes possible without a user having to get their
hands dirty.  And we might even be able make configuring recipes
possible directly from the wiki.  Recipes that didn't install this way
could of course continue to be installed as usual.

> > Also, 3) it might be nice to optionally setup a help page
> > for each recipe and/or a configuration page for the recipe.
>
> Recipes can already do this; in fact, many skins already do.

How exactly do they do this?  I would like to be able to create
various pages automatically.  I know I could do this in PHP using
something like UpdatePage(), but I only want these pages created when
they first install the recipe.  And I don't want to have to do checks
to see if certain pages exist everytime my recipe is called.  Are you
talking about bundling pages in with the zip file and then having them
dropped into the appropriate folders when you you unzip them?

> If someone wants to create a module that allows for
> automatic downloading and/or modifying configuration files,
> that's fine, but given the wide variety of webserver and
> PmWiki configurations (and the associated scripting
> security issues) I'd personally be quite wary of ever using it
> or recommending its use to others.

Well, we would really need you to standardize this Pm, or it won't
really work.  Personally, I have little need for it, but I was think
about the good of PmWiki in the long run.  I do recall ALMOST
concluding the same thing as that guy who wrote the post on this.  I
thought--wow this is pretty hands on kind of stuff.  Fortunately I was
willing to get under the hood (to avoid databases), and after I tried
it and discovered how easy it was--I was hooked.  But I could just as
easily have moved on, to my great loss...  : )  To give some kind of
semblance at least of automatic module installs would make a big
positive impression, even if it changed nothing under the surface as
far as how PmWiki worked.

> P.S.:  Since writing PITS #00394 I have toyed with the idea of
> coming up with a form-based configuration system for some of
> the more common PmWiki and recipe settings -- i.e., an admin
> would simply do
>
>    include_once('cookbook/formconfig.php');
>
> and then use the form for lots of basic configuration settings,
> which could then be augmented or overridden by other statements
> in the config.php file.  But things still get complex when we
> start thinking about per-group or per-page customizations --
> where do those get stored?  Ultimately I get the feeling that we're
> just increasing the complexity rather than reducing complexity
> or simplifying it.

If this could be done for PmWiki as a whole (a nice idea), something
similar could be done for individual recipes, I presume.  I'm not sure
what the answer is to getting customizations tied to local groups or
pages.  But my inclination at this point is, getting recipe
configuration variables to work could come down the road.  Right now,
getting them to install a bit easier might be a nice first step.

Cheers,
Caveman

PS.  I wonder if this thread shouldn't be moved to the user mail list
to see what other non-developers might think?



More information about the pmwiki-devel mailing list