[conspire] The simpler life

[Rick Moen]

On my Web server, some of the main pages have been needlessly
complicated, creating security risk and lowering performance and
(potentially) reliability.  I'm in the middle of fixing that.


1.  Needless use of CGIs, and in particular one with problems.

Years ago, I stumbled across a neat little refugee from the year 1999, 
called PerlHoo.
http://www.webreference.com/search.php?q=Perlhoo
It's a Yahoo-like information directory (some will remember what that
was) in less than 100 lines of Perl, that you run as a Web CGI script.
This helped me organise a bunch of miscellaneous information, and I 
also crafted a nice little Python script to HTMLise a bunch of my ASCII 
text files.  Result here:

http://linuxmafia.com/kb/   <- Linuxmafia.com Knowledgebase

Well, sort of:  For about ten years until this evening, I generated the 
Linuxmafia.com Knowledgebase dynamically using PerlHoo.  I just
converted the entire Knowledgebase to flat HTML.  (I have a few editing
macros to maintain it going forward, and ideas about how to do that
better still.)

PerlHoo had two problems, small and large.

Small:  The 'submit a link' feature was already obsolete in 1999 because
of comment spam.  That feature could have been fixed with, say, just 
requiring the user to provide inline the answer to an arithmetic
problem before being able to do HTTP POST, and the arithmetic problem 
wouldn't even need to change.  Just _that perfunctory_ an antispam 
measure would have stopped the spambots, because comment scripts
tailored for indivicual target sites just aren't a problem.

Large:  Author Jonathan Eisenzopf simply did not bother to bear in mind
security, and committed the sin of failing to validate input (in this
case, the URL line that the CGI handles).  Result was this XSS:
https://www.xssposed.org/incidents/85269/  

This problem was kindly pointed out somehting like a year ago, and I
posted the advisory here asking if any Perlista would please have a look
to see if it's easy to fix.  Nobody ever offered any help.

Anyway, the CGI is not gone, but the knowledgebase remains, further
cleaned up.


2.  My personal FAQ / rants page at http://linuxmafia.com/~rick/faq/
were dynamic, relying on Apache mod_php and PHP5 for every page load,
for no good reason.  

For those pages, I built the navbar and table of contents elements
dynamically using PHP case statements and the #include directive --
which is a bit lazy.  This evening, I rearchitected that entire tree to 
be generated via GNU make from HTML snippets.  So, again, it's now 
100% flat HTML.


3.  The BALE and CABAL pages will be next.  Once again, I committed 
a rather dumb and wasteful overuse of dynamic HTML in a place where it's
not actually needed at all.  Each time you load the
http://linuxmafia.com/bale/ page, for example, Apache calls mod_php and
PHP5 to assemble an index page from multiple PHP #include snippets, plus 
it generates a complex SQL query to send to mysqld to look up data in
two tables to fill out LUG decriptions and dated events.  This is really
stupid because the resulting page is compeletely unchanging except for 
one changeover on the first of each month.

On the first of each month, cron runs a Python script that populate the
MySQL events table three months out from the present, based on a
templates table.  Every page load after that is identical, until the
1st of the following month comes around.  Thus, the page is pointlessly
dynamic for no benefit.  And really rather a performance hog.

Instead of generating the page afresh with a big database query on each
load, what I _should_ do is add a second cron job immediately after the
Python script, on the first of the moneth, to build index.html _once_
for that month using PHP and MySQL queries.  I've tested this from the
command line, and it appears to be really simple.  I'll probably convert
first http://linuxmafia.com/cabal/ and then http://linuxmafia.com/bale/,
as the first is a simplified variant of the second.


Once I've completed the above simplification work, there will no longer
be any dynamic content on linuxmafia.com, no CGIs, and no need for
mod_php -- with one occasional exception.  Being lazy and spoiled, I
tend to use a lovely little PHP application called Adminer as a nice
front-end to doing MySQL maintenance.  https://www.adminer.org/  Anyone
who's used phpMyAdmin will recognise the similarity, except Adminer is 
greatly simpler and greatly better performing.

I am likely to normally leave mod_php unloaded and load it into Apache
only on the rare occasions when I use Adminer.