This is the administrative journal/log/record for the TWiki site. Significant changes, site-wide changes, and/or things that won't show up in a TWiki page edit history somewhere, should be documented here. See also
TWikiMods for a current-state (as opposed to chronological) view of things.
It is in Main Web simply so we do not have to put
Main.
in front of every
WikiName.
Just protected TWiki.cfg from web browsing - this was recommended by the TWiki core team. This required changing Apache's httpd.conf for the gnhlug.org site.
I changed templates/mailnotify.tmpl to not have HTML in it. This substantailly reduces the content of the message, but I think that's what people want anyway.
Upgrade TWiki from release 3.x dated 2004 September 01 (Cairo?) to 6.1 (2018-07-16). Also move to a new server, was
justice
, now
petra
. First significant upgrade to our TWiki software in almost two decades. (Not something to be proud of.)
This was a clean install. The
GNHLUG and
Org Webs had their content migrated over (
data
and
pub
), but other Webs were created anew. The old install had a ton of spam accounts, mostly neutered, but still cluttering things up. And I judged it easier/better to start fresh than try to figure out what should be kept in webs like Main and TWiki. This does mean users have to create new accounts again, but that is very easy to do, and if one uses the same name, all the history links even keep working.
- installed TWiki 6.1 from tarball from the twiki.org website
- created group gnhlugweb
- installing packages needed by TWiki
- these per TWikiSystemRequirements#Optional
- libcgi-session-perl for CGI::Session
- libmldbm-perl as suggested by libcgi-session-perl
- libcrypt-smime-perl for Crypt::SMIME
- libcryptx-perl for Digest::SHA1
- libjson-perl for JSON
- liblocale-maketext-lexicon-perl for Locale::Maketext::Lexicon
- unpacked TWiki 6.1.0 kit to /srv/web/gnhlug/twiki6
- cd /srv/web/gnhlug/twiki6/bin
- cp LocalLib.cfg.txt LocalLib.cfg
- edit LocalLib.cfg
- $twikiLibPath = "/srv/web/gnhlug/twiki6/lib";
- stripped comments and examples
- used TWiki website config file generator to create an Apache config
- used that as a starting point to create
- /etc/apache2/sites/gnhlug-twiki6.conf
- /etc/apache2/sites/gnhlug-twiki6.inc
- restarted Apache
- the configure script produces a page but complaints of permissions (valid)
- created /srv/web/gnhlug/twiki6/webroot/ for the DocumentRoot
- put a placeholder index.html there
- created /srv/web/gnhlug/twiki6/doc/ and moved the top-level doc files there
- shim'ed my /etc/hosts to use new server as if it were live
- cd /srv/web/gnhlug/twiki6
- mkdir log
- chown -R www-data:www-data working pub data log
- touch lib/LocalSite.cfg
- chown www-data:www-data lib/LocalSite.cfg
- chmod g+w lib/LocalSite.cfg
- chmod a-rx /srv/web/gnhlug/twiki6/bin/configure
- now the do/configure URL yields HTTP 500 Internal Error
- chown bscott:gnhlugweb /srv/web/gnhlug/twiki6/lib/LocalSite.cfg
- chmod -R o-rwx /srv/web/gnhlug/twiki6/tools
- $TWiki::cfg{Stats}{TopicPerYear} = 1;
- otherwise the single stats page gets very slow with years of history
- $TWiki::cfg{Stats}{DisableInvocationFromBrowser} = 1;
- not needed if cron is working, and potential security exposure
- mv bin/.htaccess.txt doc/bin-htaccess.txt
- mv bin/configure mv bin/configure.renamed
- create a new "dummy" bin/configure
- a small shell script to nicely tell people to go away
- MimeTypesFileName = '/etc/mime.types'
I set up Apache to require authentication for the register script. This was
(intended to be) done outside of TWiki, as a separate process, with Apache
using HTTP Basic authentication to get credentials. It worked fine on the
Apache side, but TWiki was picking up the HTTP Basic Auth username "register"
from Apache via the REMOTE_USER environment variable, and treating that as
a TWiki user (despite the lack of user Topic page). I found others with
similar problems at
https://twiki.org/cgi-bin/view/Codev/UnregisteredUsersShouldBeTWikiGuests
but no built-in way to handle it. My fix was to modify lib/TWiki.pm
and insert at the top
$ENV{REMOTE_USER} = undef;
so that REMOTE_USER is always removed from the environment for every TWiki
script. This seems to have worked.
disabled all plugins as part of debugging OOM
2023-12-17 11:28:15 enabled Apache 2 module suexec
2023-12-17 14:20:13 added some robots to Apache blacklist
Still getting OOM crashes. It looks like a single random IP address in the AWS cloud is spidering the entire site as fast it can, and so we get tons of Perl
view
processes running sucking up all the RAM. Tried adding
MemoryHigh=70%
and
MemoryMax=90%
to
/etc/systemd/system/apache2.service
but all that is going to do is make sure it's Apache that crashes and not something else. What we really need is a way to limit running CGI process count that doesn't break everything instantly.
18:30 Re-enabled plugins
TinyMCEPlugin
and
WysiwygPlugin
Edited
TWikiPreferences to turn the link to
SmiliesPlugin into static text. Otherwise spiders try to follow the link and cause log spew since that plugin is disabled. To edit the nominally read-only page, manually type in the URL of the edit action.
Added
rdiff
to
AuthScripts
in
LocalSite.cfg
per
TWiki.org - How to run TWiki reliably on a public website