[web-team] Volunteer

[Rick Moen]

Quoting Lisa Corsetti (svlug at flygirl.com):

> I seem to recall that WebFetch no longer worked, or we had no
> one to support it -- or something like that.  I do remember that
> I didn't feel like *I* was able/willing to support it. :-)

{glyph of heartfelt agreement}  

Man, that WebFetch stuff was _weird_ even when it worked properly -- and
the former use of it for pseudo-RSS-type 'news' from popular sites just
reeked of 1995 'The Internet is _so_ exciting that we need to shove it
at you.'
 
In the case of WebFetch, I don't mind shedding reliance on a hostile
upstream, either.

For the record, it's still in CPAN, and I suspect there's nothing wrong
with it.  Upstream last checked in updates in 2008.


> Well, the "includes" parts can certainly be de-PHP-ified easily
> enough.

Yeah, OTOH, PHP is a perfectly OK way of assembling page includes, and
the work's already done.  Back in dinosaur days, I at one point did
similar things with m4.  (Don't laugh.  ;->  )  My point is less the use
of PHP for a convenient purpose than the security exposure and need to 
run the PHP interpreter on every page load for pages that aren't
actually dynamic.


Just to be really clear about this, this is _definitely_ a fine point.
OK?  I'm far from complaining.  Your conversion work was brilliant.


I started thinking about this not-actually-dynamic point concerning the
evolution of my own site, especially when my wife Deirdre kindly recoded
the BALE calendar to be mostly automated.

The original BALE page (http://linuxmafia.com/bale/) was just plain ol'
HTML that I maintained using vi and a lot of copy-and-paste.  It was
an excellent solution for its original problem space, but Deirdre's
redesign was (1) less butt-ugly and (2) templated and largely automatic.
The templates and individual calendar events are in a MySQL table.  Each 
month's events table gets populated by a Python script run by cron on
the first of each month.  Last, the BALE page itself is now PHP,
generated dynamically from SQL calls at each page load.

Long after the conversion, I had an epiphany:  'Wait, the contents of
each month never changes.  It's generated once on the 1st, and is then
static.  So, why are we doing a bunch of SQL lookups on each page load?'

I asked Deirdre -- while taking care not to sound ungrateful.  She
admitted that, yes, the flurry of SQL lookups on each page load is kinda
dumb and avoiable.  The same Python script that generates the new
month's events _could_ just do a mass PHP routine whose HTML output of
events got redirected to a static HTML file.  And thus, it then would
become unnecessary to run the PHP interpreter using Apache mod_php with
every page load any more.


As I mentioned, I made the same error (treating non-dynamic pages as
dynamic, and making them needlessly dependent on mod_php) concerning
http://linuxmafia.com/~rick/faq/ and subpages -- for no advantage other
than the include() function.  That was dumb.  

I've been meaning to make a http://linuxmafia.com/~rick/faq2/ scratch 
directory and test-convert that over to a Makefile.

(A Makefile is just one of many ways to do that.  Heck, it could just 
be an ugly shell script.  The point is that /usr/bin/php can process 
PHP source and output a static HTML file, as a better solution for any
page that isn't actually dynamic but is maintained in PHP for reasons of 
editing convenience and what amount to PHP's macro-expansion features.)

If I eliminate the httpd-loadtime use of /usr/bin/php for my personal
FAQ pages and BALE, then nothing on my site will require mod_php any
more, which will be a performance and security gain.
http://linuxmafia.com/kb/ needs mod_perl (for PerlHoo), but I'm _way_ 
happier about that public Perl in http than I am about public PHP in
httpd.  The security consciousness of the two scripting languages are
night and day, e.g., it's a scandal that PHP _still_ has nothing like
Perl's 'taint mode' to enforce input validation.


> Agreed 100%... I'd be willing to help solve this problem.  If we're
> okay with all pages being rewritten by a cron script once a day or
> manuall called when files are changed or something similar, that
> should NOT be a serious task.

That might be the easiest way to accomplish that.  Again, this is a fine
point only!  ;->

> Do we have specific languages in mind?  Python?  Java?  What?

Nothing wrong with PHP.  :->

> I believe that there is nothing on any of these sites that can't be
> statically re-done (with a periodic running script).  The only thing
> that currently changes load-to-load, IIRC, is the "sponsor" logo that
> gets displayed -- I suspect that it would be okay to change that once
> a day -- or every few hours.

Concur.  sponsor-spinner is, I'm pretty sure, the only element on the
entire SVLUG site (not counting Mailman's mod_python-driven pages on
lists.svlug.org) that even approaches being dynamic.
 

> Well, that sounds like I took the position of ramming it down SVLUG's
> throat.  That doesn't sound like me.

Well, it isn't -- and now I feel like I probably sounded grumpy.  It was
a decision entirely within your bailiwick as Web Software Coordinator.

In that important respect it differs from a bunch of other unilateral
decisions other people have made and then walked away, leaving me
holding the bag.  On reflection, I'm sure that its these other things
that have left me irritable about anything new that resembles them.

A few examples off the top of my head:

o  VP Micah Dowty unilaterally decided in 2006 that 80MB RAM on a Linode
virthost should _easily_ house all of SVLUG's Internet operations.  (1GB
is an accurate estimate.)  He also decided that it will run Ubuntu
Server (which I dislike and have found lacking ever since).  He imposed
those two choices and then immediately walked away.

o  Daniel Gimpelevich decided one day that root-user ssh access into 
lists.svlug.org is undesirable and disables it, without discussing 
this with anyone and without documenting the change anywhere.  He 
broke the backup scripts and didn't realise he'd done so.  He then
walked away.

o  Daniel decides in 2008 to change /var/www and and /var/svn on
www.svlug.org to locations under /srv on grounds of some FHS mandate or
other -- without discussion and without documenting his work in
site-docs/ChangeLog.  Service continuity gets maintained through a crazy
forest of symlinks -- thereby impairing performance and needlessly
doubling the amount of filesystem activity.  He then walked away.  I
discovered this in 2011, reverse-engineered and reverted Daniel's
changes, and retroactively documented his changes (and my reversion) in
site-docs/ChangeLog


You can perhaps empathise with getting grumpy after a decade of such
things.


> If, OTOH, it's all well-in-hand, I'll stay out of the way and I have
> NO complaints of moving from PHP :-)

I like the PHP.  I merely think it'd be a nice fillip on your most
excellent work to make the page generation be offlie (writing to static
HTML files) rather than inline at pageload time.