Item11633: Run checkers from a Foswiki page

There are times were you want to be able to run configure from a foswiki page (for example, when you are fighting with a particularly troublesome configuration debug, like I am)

It should be fairly easy to write a plugin to do this (also a good test of the separation between the bits of configure)

-- CrawfordCurrie - 11 Mar 2012

I just stumbled across this code. It's harder than you might think to get this right. Your code is not passing the Value item to the checkers - which checkers do count on. And of course, it doesn't understand the Feedback (AJAX) extensions.

All generic, and some item checkers need input from CHECK= clauses from Foswiki.spec - this is extracted when FoswikiCfg builds the UI 'model.' If you try to check items that are in extensions' .spec files, they need to be in the model too.

I recommend wrapping all calls to checkers in eval - many of them die on internal errors or corrupt data.

But, given all the configure upgrades, is this plugin still necessary? I don't understand the use model, since running configure in a parallel window or tab is straightforward...

-- TimotheLitt - 30 Dec 2012

As I recall the problem was with the Apache configuration. Foswiki scripts can be run under accelerators (mod_perl etc) and as such the configuration is different to configure. I solved the problem I was having with a hack - I dumped all the $ENV into a topic - and was able to solve it that way.

-- CrawfordCurrie - 08 Jan 2013

Thanks. There is a new mechanism that enables Configure to get %ENV from the accelerated environment.

It currently only gets the CGI-related entries, but there's no reason it can't more.

I'll expose it in the configuration audit when I get a few minutes.

These are the entries it currently returns. Are there others that you would find useful?

Can we then retire the plugin that you created under this item?

 
  # CGI standard
  AUTH_TYPE CONTENT_LENGTH CONTENT_TYPE GATEWAY_INTERFACE PATH_INFO
  PATH_TRANSLATED QUERY_STRING REMOTE_ADDR REMOTE_HOST REMOTE_IDENT
  REMOTE_USER REQUEST_METHOD SCRIPT_NAME SERVER_NAME SERVER_PORT
  SERVER_PROTOCOL SERVER_SOFTWARE
  # Apache/common extensions
  DOCUMENT_ROOT PATH_TRANSLATED REQUEST_URI SCRIPT_FILENAME
  SCRIPT_URI SCRIPT_URL SERVER_ADDR
  # HTTP headers
  grep /^HTTP_/, keys %ENV 
  # SSL data
  grep /^SSL_/, keys %ENV

-- TimotheLitt - 08 Jan 2013

Yes, please do. I think you covered all the important $ENV above - though a simple mechanism for adding more in extremis would be a sensible idea.

-- CrawfordCurrie - 09 Jan 2013

The latest configure exposes the execution environment variables. See Configuration Audit => Webs server & Environment Web server.

If the execution environment requires password-based webserver authentication, you must enter a valid username/password (Only basic is supported) first.

If the execution environment is not accessible due to authentication or misconfiguration, the configure environment will still be reported. (This is no worse than your plugin; one had to be able to access the wiki to run it.)

Environment variables that exist only in the configure or only in the execution environment are labeled. Variables that differ show both values - note that many are EXPECTED to differ, so some intelligence is required to interpret the output. E.G. the audit is triggered by an AJAX POST, while the execution variables are retrieved via a (magical) GET.

I may upgrade this to include the "general environment" variables (e.g. UMASK, @INC, etc) later, as they can also differ (and cause problems).

With respect to in extremis additions: the exported variables list is in lib/Foswiki/Configure/ImageTest.pm - note that this is not a source file, but in extermis it can be edited by someone knowledgeable. Changes are automagically picked up by the auditor, so it's just a matter of adding the desired variable name(s).

I consider the ConfigureCheckPlugin officially retired as of 1.2, and so won't worry about its broken use of the checker API.

I won't close this item in case you are inclined to do anything more to support earlier versions of Foswiki. (But I'd prefer that you don't, as people tend to stick with old tools and supporting the plugin going forward will not be fun - for you

-- TimotheLitt - 09 Jan 2013

This has been superseded by the reworking of configure.

-- CrawfordCurrie - 20 Jan 2015

Commenting is disabled while not logged in