[conspire] Update for BALE
rick at linuxmafia.com
Mon Jan 6 19:34:00 PST 2020
Quoting D. Joe (cabal at etrumeus.com):
> The "yet again" was my hint that details of how this is done might be out there for the finding.
> I've found
> with its reference to autobale at
Thanks, D. Joe. However, the referenced mailing list post covers so
many things that I'll just do a quick pass:
BALE is a static HTML page generated on the first of each month by a
cron-driven Python script that builds it from MySQL queries. MySQL
contents include a couple of different kinds of templates for
constructing page content from rules, plus a separate table of dated
events for generating listed entries based on applying the rules to the
Therefore, making changes to a group's meeting schedule, location, or
other details isn't just a matter of 'executing /usr/bin/vi'. In order:
(a) Use your preferred MySQL client to update the group template and
the group-description template.
(b) Either edit each of the already-generated dated events affected by
the change using your preferred MySQL client, or use your preferred
MySQL client to delete all of those events, and then re-run the monthly
cron job that uses that Python program and shell templating to construct
Not only is this significant work that I prefer to do as a large batch
to update all covered groups at one go, but also the closest thing I
have to a 'preferred MySQL client' is Adminer (https://www.adminer.org/).
I love everything about Adminer except the fact of it being a PHP
script. Certain current realities about my legacy server mean I am
unwilling to expose /usr/bin/php to public Internet access for
compelling security reasons. There are complicated workarounds; I'm not
going into those here and now.
If someone cares to recommend a MySQL client better than /usr/bin/mysql
that I might run as a console task and preferably run as a modest
script or locally-compiled utility in /usr/local/bin , I would be
interested in hearing recommendations. Yes, anything do-able with
Adminer can (obviously) also be done using /usr/bin/mysql, but I
consider the latter painful to use and likely to cause me to
introduce erroneous data to the database through mishap.
What I typically have done in the past is (1) Plan in detail all BALE
updates to make, taking copious notes because I'll need to execute the
changes without Internet access, (2) take down Apache httpd.
(3) Power down my Raw Bandwidth Communications aDSL uplink. (4)
Reconfigure Apache httpd to re-enable inline mod_php. (5) Restart
Apache httpd (with aDSL deliberately down, so no public access to inline
PHP is possible even in theory. (6) Using a Web browser, navigate to
my local Adminer instance and update BALE's templates and events.
(7) Do what the lines in /etc/crontab say to do, to populate the
event table and then generate the BALE and CABAL pages:
/usr/bin/php5 /var/www/cabal/index.inc > /var/www/cabal/index.html
/usr/bin/php5 /var/www/bale/index.inc > /var/www/bale/index.html
(8) Reconfigure Apache httpd to lose the mod_php support. Restart it.
(9) Power the Raw Bandwidth Communications aDSL uplink back up.
Attentive CABAL people may have already noticed the new complication:
There's no longer Raw Bandwidth aDSL. Pffft! So, I'll probably have to
finally sit down and figure out how to kludge into the Apache conffiles
some access ACLs, to be present while mod_php is enabled, restricting
client access to Chez Moen's IP space only.
 You are probably thinking of those and want to blurt one out, so
I'll spare you the effort: 'Dude! Just add a local-only copy of
$MY_FAVOURITE_TINY_HTTPD with inline PHP on a high-numbered port.'
More information about the conspire