Maltfield Log/2026

From Eco-Libre
Revision as of 19:24, 5 May 2026 by Maltfield (talk | contribs) (adding logs 'till 4/20)

2026-04-20

  1. I got a link from a friend from a pretty cool sounding similar project https://projectkamp.com/
    1. sounds like they have similar ideas as Eco-Libre, except they already bought land already
    2. They claim to use CC BY-SA to license all their works, but their videos are not marked as-such on YouTube. And, because YouTube is trash, I can't view their videos https://academy.projectkamp.com/start/intro/#open-source--license
    3. I wanted to email them to update the license on their YouTube videos (so, at least, they could be archived on archive.org and uploaded to PeerTube, etc), but I couldn't find their email https://projectkamp.com/faq.html
    4. Their footer says they're part of One Army (along with, eg Precious Plastic), so I emailed One Army asking for the email address of Project Kamp https://www.onearmy.earth/
Hello,

Can you please tell me the email address of Project Kamp?

I'm looking to get in contact with Project Kamp over email, but I couldn't find a way to email them from their website:

 * https://projectkamp.com/faq.html

Please send me the email address for Project Kamp.


Thank you,

Michael Altfield
https://www.michaelaltfield.net
PGP Fingerprint: 0465 E42F 7120 6785 E972  644C FE1B 8449 4E64 0D41
    1. TODO: add Project Kamp to our 'common-files' repo's docs as a "Similar Project"
  1. ...
  2. Tomorrow we're publishing our partnership with Raft Foundation, so we can accept tax-deductable donations https://www.eco-libre.org/raft-2026/
  3. Some weeks ago I did updates of wordpress, including adding new plugins. One of them was ActivityPub
  4. I enabled ActivityPub, but the Settings page gives me a "504 Gateway Time-out" error from nginx https://www.eco-libre.org/wp-admin/options-general.php?page=activitypub
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx</center>
</body>
</html>
    1. here's the error.log entry for nginx
2026/04/20 17:37:36 [error] 1992101#1992101: *2507383 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.42.180.66, server: www.eco-libre.org, request: "GET /wp-admin/options-general.php?page=activitypub HTTP/1.1", upstream: "http://127.0.0.1:6081/wp-admin/options-general.php?page=activitypub", host: "www.eco-libre.org
    1. and here's the apache logs
==> www.eco-libre.org/access.log <==
64.42.180.66 - - [20/Apr/2026:17:54:54 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 792 "https://www.eco-libre.org/wp-admin/plugins.php?plugin_status=all&paged=1&s" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"

==> www.eco-libre.org/error.log <==
[Mon Apr 20 17:55:23.176842 2026] [proxy_fcgi:error] [pid 526343:tid 526374] (70007)The timeout specified has expired: [client 64.42.180.66:0] AH01075: Error dispatching request to : (polling)

==> www.eco-libre.org/access.log <==
64.42.180.66 - - [20/Apr/2026:17:54:23 +0000] "GET /wp-admin/options-general.php?page=activitypub HTTP/1.1" 504 467 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
    1. I don't know what's wrong, and that's not enough to debug it. I tested ActivityPub on another site, and the config page had no issues. But I ended-up not finishing its setup because I wanted the actor URL to use the naked domain, and I'm still waiting to hear back on that https://github.com/Automattic/wordpress-activitypub/issues/3164
  1. anyway, I wrote a newsletter, scheduled it to go out for tomorrow at 15:00 UTC
  2. I also wrote the update for Open Collective
  3. I put the "Donate" page in the menu bar
    1. on mobile, this made the top navbar spill over into a second row, so I moved "Contact" under "Join Us"
      1. to make up for this, I started creating footer areas
      2. the theme supports three footers. one on the left, center, and right
      3. I put copyright & copyleft info on the right footer
      4. I put social media icons in the middle footer
      5. I put a "Contact" link on the left footer
    2. As I was styling the left footer, I stopped being able to update it suddenly. I kept getting error
There was an error. Could not get a valid response from the server.
    1. closer inspection of the networking tab of the browsers debugger showed an error when doing an OPTIONS request
    2. well, that's probably because (for security) we block all but GET POST and HEAD
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
   # note: 444 is a meta code; it doesn't return anything, actually
   #       it just logs, drops, & closes the connection (useful
   #       against malware)
   return 444;
}
    1. well, fuck, our widgets are bricked
    2. I asked about this here https://wordpress.org/support/topic/configure-wordpress-to-never-use-options-requests/
    3. as a workaround, I found that I *can* edit these footer widgets from the theme -> customize -> widgets section of the site – which sends POST as expected https://www.eco-libre.org/wp-admin/customize.php?return=%2Fwp-admin%2Fwidgets.php
  1. I realized that I can't post to lemmy anymore, because our sdf instance has been down since 2026-04-07
  2. I went ahead and created an accout request on the solar punk instance https://slrpnk.net/
    1. if we're accepted, I'd also like to create a community specific to Eco-Libre
  3. I also created one on lemmy.vg

2026-04-19

  1. I failed to login to the wiki today. I got error
[REDACTED] 2026-04-19 20:34:48: Fatal exception of type "DomainException"
  1. exception.log seems to suggest that I set a bad config for the password policy yesterday
==> exception.log <==
2026-04-19 20:36:27 mail wiki_el_db-rHb3: [REDACTED] /index.php?title=Special:UserLogin&returnto=MediaWiki
%3ARequestaccount-agree   DomainException: Invalid password policy config. No check defined for 'PasswordCannotMatchUsername'
.
#0 /usr/share/mediawiki/includes/password/UserPasswordPolicy.php(88): MediaWiki\Password\UserPasswordPolicy->checkPolicies()
#1 /usr/share/mediawiki/includes/user/User.php(995): MediaWiki\Password\UserPasswordPolicy->checkUserPassword()
#2 /usr/share/mediawiki/includes/auth/AbstractPasswordPrimaryAuthenticationProvider.php(114): MediaWiki\User\User->checkPassw
ordValidity()
#3 /usr/share/mediawiki/includes/auth/AbstractTemporaryPasswordPrimaryAuthenticationProvider.php(155): MediaWiki\Auth\Abstrac
tPasswordPrimaryAuthenticationProvider->checkPasswordValidity()
#4 /usr/share/mediawiki/includes/auth/AuthManager.php(625): MediaWiki\Auth\AbstractTemporaryPasswordPrimaryAuthenticationProv
ider->beginPrimaryAuthentication()
#5 /usr/share/mediawiki/includes/auth/AuthManager.php(535): MediaWiki\Auth\AuthManager->continueAuthentication()
#6 /usr/share/mediawiki/includes/specialpage/AuthManagerSpecialPage.php(390): MediaWiki\Auth\AuthManager->beginAuthentication
()
#7 /usr/share/mediawiki/includes/specialpage/AuthManagerSpecialPage.php(524): MediaWiki\SpecialPage\AuthManagerSpecialPage->performAuthenticationStep()
#8 [internal function]: MediaWiki\SpecialPage\AuthManagerSpecialPage->handleFormSubmit()
#9 /usr/share/mediawiki/includes/htmlform/HTMLForm.php(822): call_user_func()
#10 /usr/share/mediawiki/includes/specialpage/AuthManagerSpecialPage.php(455): MediaWiki\HTMLForm\HTMLForm->trySubmit()
#11 /usr/share/mediawiki/includes/specialpage/LoginSignupSpecialPage.php(403): MediaWiki\SpecialPage\AuthManagerSpecialPage->trySubmit()
#12 /usr/share/mediawiki/includes/specialpage/SpecialPage.php(728): MediaWiki\SpecialPage\LoginSignupSpecialPage->execute()
#13 /usr/share/mediawiki/includes/specialpage/SpecialPageFactory.php(1717): MediaWiki\SpecialPage\SpecialPage->run()
#14 /usr/share/mediawiki/includes/actions/ActionEntryPoint.php(505): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#15 /usr/share/mediawiki/includes/actions/ActionEntryPoint.php(147): MediaWiki\Actions\ActionEntryPoint->performRequest()
#16 /usr/share/mediawiki/includes/MediaWikiEntryPoint.php(200): MediaWiki\Actions\ActionEntryPoint->execute()
#17 /usr/share/mediawiki/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#18 {main}
  1. here's what we have
$wgPasswordPolicy['policies']['default']['PasswordCannotMatchUsername'] = true;
  1. but the docs suggest there's an additioanl array needed for "value"
$wgPasswordPolicy['policies']['default']['PasswordCannotMatchUsername']['value'] = false;
  1. if I expand "Older Versions" then the 'PasswordCannotMatchUsername' disappears from mediawiki >1.37. The docs still say it's an option, but I didn't find it in our files https://www.mediawiki.org/wiki/Manual:$wgPasswordPolicy#Default
root@mail:/var/www/html/wiki.eco-libre.org# grep -irl PasswordCannotMatchUsername *
LocalSettings.20260419.php
LocalSettings.php
root@mail:/var/www/html/wiki.eco-libre.org# 
  1. it does appear that 'PasswordCannotBeSubstringInUsername' is available. let's use that instead.
  2. ugh, next attempt gives another failure
==> exception.log <==
2026-04-19 21:04:26 mail wiki_el_db-rHb3: [REDACTED] /index.php?title=Special:UserLogin&returnto=MediaWiki
%3ARequestaccount-agree   DomainException: Invalid password policy config. No check defined for 'PasswordCannotBePopular'
  1. I removed this; I guess we're supposed to use 'PasswordNotInCommonList', which we already use.
  2. ok, that worked. I'm able to login-in. here's the final
# PASSWORD POLICIES

$wgPasswordPolicy['policies']['default']['MinimalPasswordLength'] = 10;
$wgPasswordPolicy['policies']['default']['PasswordCannotBeSubstringInUsername']['value'] = true;
$wgPasswordPolicy['policies']['default']['PasswordNotInCommonList'] = true;

$wgPasswordPolicy['policies']['sysop']['MinimalPasswordLength'] = 20;
  1. now that I can login, I was going to change the text that appears on the Request Account page https://wiki.eco-libre.org/wiki/MediaWiki:Requestaccount-text
Complete and submit the following form to request a user account.

Make sure that you first read the Terms of Service before requesting an account.

Once the account is approved, you will be emailed a notification message and the account will be usable at login. 
    1. my intention was to add a notebox to highlight that the user would need to first complete the Eco-Libre Volunteer Test (https://eco-libre.github.io/volunteer-test/) before their new wiki account would be approve, and tell them to contact us (https://eco-libre.org/contact/)
    2. unforutnately, the notebox template doesn't exist!
    3. I found the docs on templates, and it says there's no way to import a bunch of standard templates https://www.mediawiki.org/wiki/Help:Templates
    4. this third-party guide says we can make the export/import (eg from Wikipedia) of a mass of templates easier with the Scribunto extension https://www.ryadel.com/en/how-to-add-wikipedia-mbox-templates-to-your-own-mediawiki/
    5. this extension ships with core mediawiki, it seems
root@mail:/var/www/html/wiki.eco-libre.org# ls htdocs/extensions/
AbuseFilter     ConfirmEdit      InputBox          Nuke             ReplaceText            TemplateData    Widgets
CategoryTree    DeleteBatch      Interwiki         OATHAuth         Scribunto              TextExtracts    WikiEditor
Cite            DiscussionTools  Linter            PageImages       SecureLinkFixer        Thanks
CiteThisPage    Echo             LoginNotify       ParserFunctions  SmiteSpam              TitleBlacklist
CodeEditor      Gadgets          Math              PdfHandler       SpamBlacklist          UserMerge
ConfirmAccount  ImageMap         MultimediaViewer  Poem             SyntaxHighlight_GeSHi  VisualEditor
root@mail:/var/www/html/wiki.eco-libre.org# 
  1. TODO: finish installing Scribunto, then do a mass-export & mass-import of common templates from Wikipedia. Then finish configuring ''MediaWiki:Requestaccount-text''
  2. I thought that, maybe, a lower hanging fruit would be to implement the Privacy Policy, but I realized that page actually requires the user to accept the Terms of Service, not the Privacy Policy
    1. OSE appears to have never set a ToS (And I created the Privacy Policy, largely based on the creative commons' privacy policy https://wiki.opensourceecology.org/wiki/Terms_of_Service
    2. The wikipedia Terms of Service is actually named Terms of Use, and it's pretty specific to Wikipedia (including their mission, etc). In it, it references the Privacy Policy https://foundation.wikimedia.org/wiki/Policy:Terms_of_Use/en
    3. Appropedia doesn't appear to have a page dedicated to ToS (or ToU) or Privacy Policy. Instead, it's just on one page named Policies https://www.appropedia.org/Appropedia:Policies

2026-04-18

  1. continuing where I left off yes terday to fix mediawiki after the unattended-upgrade deleted our LocalSettings.php file
  2. I need to push-out a new php.ini config (with ansible) to include /etc/mediawiki/ in the open_basedir setting
  3. ansible is broken suddenly; it says it can't find python
fatal: [michaelaltfield.net]: UNREACHABLE! => {"changed": false, "msg": "EOF on stream; last 100 lines received:\nbash: line 1: /usr/bin/python: No such file or directory", "unreachable": true}
  1. well, idk, did debian remove a symlink from python to python3?
root@mail:/var/lib/mediawiki# ls -lah /usr/bin/python
ls: cannot access '/usr/bin/python': No such file or directory
root@mail:/var/lib/mediawiki# ls -lah /usr/bin/python3
lrwxrwxrwx 1 root root 10 Jun 30  2025 /usr/bin/python3 -> python3.13
root@mail:/var/lib/mediawiki# 
  1. looks like there's a var I can set for this named ansible_python_interpreter, but it's only available in python >= 2.2.0 https://stackoverflow.com/a/41431540
  2. and we only have ansible v2.14.18, installed in apt on debian 12 on my client machine
$ dpkg -l | grep -i ansible
ii  ansible                                       7.7.0+dfsg-3+deb12u1                     all          Configuration management, deployment, and task execution system
ii  ansible-core                                  2.14.18-0+deb12u2                        all          Configuration management, deployment, and task execution system
ii  ansible-mitogen                               0.3.3-9+deb12u1                          all          Fast connection strategy for Ansible
$

$ cat /etc/issue
Debian GNU/Linux 12 \n \l

$ 
  1. looks like debian 13 only has ansible core v2.18, so that won't help https://packages.debian.org/trixie/ansible
  2. fuck it, I just created a symlink. maybe it'll get deleted a and I'll have to recreate it again. maybe not
root@mail:/var/lib/mediawiki# ln -s /usr/bin/python3 /usr/bin/python
root@mail:/var/lib/mediawiki# 
  1. ok, that fixed ansible, and I was able to push-out the udpdated php.ini file
  2. restarted php
root@mail:/var/lib/mediawiki# systemctl restart php8.4-fpm
root@mail:/var/lib/mediawiki# 
  1. ...aaaand the wiki is fixed
[user@disp3459 ~]$ curl -IL https://wiki.eco-libre.org/
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sat, 18 Apr 2026 17:38:39 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: keep-alive
X-Content-Type-Options: nosniff
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
X-Request-Id: REDACTED
X-Frame-Options: SAMEORIGIN
Last-Modified: Sat, 18 Apr 2026 17:38:06 GMT
Location: https://wiki.eco-libre.org/wiki/Main_Page
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: deny
Referrer-Policy: strict-origin
X-Varnish: 6288299 13705059
Age: 33
Via: 1.1 mail (Varnish/7.7)
Strict-Transport-Security: max-age=86400;includeSubDomains

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 18 Apr 2026 17:38:40 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 15926
Connection: keep-alive
X-Content-Type-Options: nosniff
Content-language: en
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
X-Request-Id: REDACTED
X-Frame-Options: SAMEORIGIN
Last-Modified: Sat, 18 Apr 2026 01:16:13 GMT
X-Mod-Pagespeed: Powered By mod_pagespeed
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: deny
Referrer-Policy: strict-origin
X-Varnish: 18702490 13705062
Age: 31
Via: 1.1 mail (Varnish/7.7)
Accept-Ranges: bytes
Strict-Transport-Security: max-age=86400;includeSubDomains

[user@disp3459 ~]$ 
  1. ...
  2. alright, now let's try to install & configure all the 3TOFU'd extensions
  3. we have 6 new extensions to install
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# ls
ConfirmAccount-REL1_43-38c4602.tar.gz  extensions.txt  OATHAuth-REL1_43-015a49e.tar.gz   UserMerge-REL1_43-27425da.tar.gz
DeleteBatch-REL1_43-b3b052b.tar.gz     info.txt        SmiteSpam-REL1_43-483b81b.tar.gz  Widgets-REL1_43-60a09f0.tar.gz
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# 
  1. I extracted them
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# for file in $(ls *.tar.gz); do tar -xvf $file; done.
...
Widgets/vendor/smarty/smarty/CHANGELOG.md
Widgets/COPYING
root@mail:/var/tmp/mediawiki/extensions.2026-03-29#

root@mail:/var/tmp/mediawiki/extensions.2026-03-29# ls
ConfirmAccount                         info.txt                          UserMerge
ConfirmAccount-REL1_43-38c4602.tar.gz  OATHAuth                          UserMerge-REL1_43-27425da.tar.gz
DeleteBatch                            OATHAuth-REL1_43-015a49e.tar.gz   Widgets
DeleteBatch-REL1_43-b3b052b.tar.gz     SmiteSpam                         Widgets-REL1_43-60a09f0.tar.gz
extensions.txt                         SmiteSpam-REL1_43-483b81b.tar.gz
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# 

  1. let's start with OATHAuth, which is probably the most important (for security)
  2. oh wait, we already have OATHAuth??
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# ls /var/www/html/wiki.eco-libre.org/htdocs/extensions/
AbuseFilter   ConfirmEdit      InputBox     MultimediaViewer  PdfHandler       SpamBlacklist          TitleBlacklist
CategoryTree  DiscussionTools  Interwiki    Nuke              Poem             SyntaxHighlight_GeSHi  VisualEditor
Cite          Echo             Linter       OATHAuth          ReplaceText      TemplateData           WikiEditor
CiteThisPage  Gadgets          LoginNotify  PageImages        Scribunto        TextExtracts
CodeEditor    ImageMap         Math         ParserFunctions   SecureLinkFixer  Thanks
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# 
  1. ugh, yeah, this syas it has been inclued in MediaWiki core since v1.31 https://www.mediawiki.org/wiki/Extension:OATHAuth
This extension comes with MediaWiki 1.31 and later, so you do not need to download it. The remaining configuration instructions must still be followed.
  1. well, maybe that's why it got updated so much. anyway, that's better; we get it directly from apt
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# dpkg -l | grep -i mediawiki
ii  mediawiki                         1:1.43.8+dfsg-1~deb13u1                 all          website engine for collaborative work
ii  mediawiki-classes                 1:1.43.8+dfsg-1~deb13u1                 all          website engine for collaborative work - standalone classes
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# 

root@mail:/var/tmp/mediawiki/extensions.2026-03-29# dpkg-query -L mediawiki | grep -i oathauth | head
/usr/share/mediawiki/extensions-core/OATHAuth
/usr/share/mediawiki/extensions-core/OATHAuth/COPYING
/usr/share/mediawiki/extensions-core/OATHAuth/OATHAuth.alias.php
/usr/share/mediawiki/extensions-core/OATHAuth/ServiceWiring.php
/usr/share/mediawiki/extensions-core/OATHAuth/composer.json
/usr/share/mediawiki/extensions-core/OATHAuth/extension.json
/usr/share/mediawiki/extensions-core/OATHAuth/i18n
/usr/share/mediawiki/extensions-core/OATHAuth/i18n/ang.json
/usr/share/mediawiki/extensions-core/OATHAuth/i18n/api
/usr/share/mediawiki/extensions-core/OATHAuth/i18n/api/ar.json
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# 

root@mail:/var/tmp/mediawiki/extensions.2026-03-29# dpkg-query -L mediawiki | grep -i oathauth | tail
/usr/share/mediawiki/extensions-core/OATHAuth/src/OATHAuth.php
/usr/share/mediawiki/extensions-core/OATHAuth/src/OATHAuthModuleRegistry.php
/usr/share/mediawiki/extensions-core/OATHAuth/src/OATHAuthServices.php
/usr/share/mediawiki/extensions-core/OATHAuth/src/OATHUser.php
/usr/share/mediawiki/extensions-core/OATHAuth/src/OATHUserRepository.php
/usr/share/mediawiki/extensions-core/OATHAuth/src/Special
/usr/share/mediawiki/extensions-core/OATHAuth/src/Special/DisableOATHForUser.php
/usr/share/mediawiki/extensions-core/OATHAuth/src/Special/OATHManage.php
/usr/share/mediawiki/extensions-core/OATHAuth/src/Special/VerifyOATHForUser.php
/var/lib/mediawiki/extensions/OATHAuth
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# 
  1. I wonder if there's any others we get? looks like it's only this one
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# ls /usr/share/mediawiki/extensions-core | grep -iE 'ConfirmAccount|SmiteSpam|DeleteBatch|UserMerge|Widgets|OATHAuth'
OATHAuth
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# 
  1. just another quick check – none of these are in apt either
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# apt-cache search mediawiki | grep -i extension
libreoffice-wiki-publisher - LibreOffice extension for working with MediaWiki articles
mediawiki-extension-codemirror - Syntax highlighting in MediaWiki's wikitext editor
mediawiki-extension-youtube - Embed YouTube and other videos into MediaWiki pages
php-luasandbox - PHP extension that provides a sandboxed Lua environment
php-wmerrors - PHP extension that enhances and customizes handling of PHP errors
root@mail:/var/tmp/mediawiki/extensions.2026-03-29# 
  1. anyway, back to OATHAuth
    1. it says to enable caching
It is strongly recommended to setup caching when using OATHAuth.
  1. I confirmed that we already have cachign setup with APC
root@mail:/var/www/html/wiki.eco-libre.org# grep -ir cache LocalSettings.php 
$wgMainCacheType = CACHE_ACCEL;
$wgMemCachedServers = [];
## Set $wgCacheDirectory to a writable directory on the web server
#$wgCacheDirectory = "$IP/cache";
$wgCacheDirectory = "/var/www/html/wiki.eco-libre.org/cache";
root@mail:/var/www/html/wiki.eco-libre.org# 
      1. CACHE_ACCEL means APC, which is the recommended option for single-server wikis, per the official mediawiki docs on performance tuning https://www.mediawiki.org/wiki/Manual:Performance_tuning#Single_web_server
      2. it also says to ue varnish. check
      3. it also says to use php-fpm w/ event MPM (instead of mod_php with prefork MPM), which we changed-to last month. check.
    1. our notes from OSE had the following options https://wiki.opensourceecology.org/wiki/CHG-2025-XX-XX_migrate_wiki_to_hetzner3
wfLoadExtension( 'OATHAuth' );

# Relaxed mode with +/- 4 minutes time drift tolerance. This is important or users will complain and/or disable 2FA entirely
# The security consequences are small. The usability benefits are huge.
$wgOATHAuthWindowRadius = 8;

# make admins require 2FA
$wgOATHRequiredForGroups = ['sysop', 'interface-admin', 'bureaucrat', 'suppress', 'widgeteditor' ];

# make 'powerful' rights require 2FA
$wgOATHExclusiveRights =  [ 'apihighlimits', 'applychangetags', 'autoconfirmed', 'autopatrol', 'bigdelete', 'block', 'blockemail', 'bot', 'changetags', 'createaccount', 'createtalk', 'delete', 'deletechangetags', 'deletedhistory', 'deletedtext', 'deletelogentry', 'deleterevision', 'editcontentmodel', 'editinterface', 'editprotected', 'editsemiprotected', 'editsitecss', 'editsitejs', 'editsitejson', 'editusercss', 'edituserjs', 'edituserjson', 'hideuser', 'import', 'importupload', 'ipblock-exempt', 'managechangetags', 'markbotedits', 'mergehistory', 'move-categorypages', 'move-rootuserpages', 'move-subpages', 'nominornewtalk', 'noratelimit', 'patrol', 'protect', 'renameuser', 'reupload-shared', 'sendemail', 'suppressionlog', 'suppressredirect', 'suppressrevision', 'unblockself', 'unwatchedpages', 'userrights', ];

# full list for reference (taken from htdocs/includes/MainConfigSchema.php) https://www.mediawiki.org/wiki/Extension:OATHAuth#Configuration
#$wgOATHExclusiveRights =  [ 'apihighlimits', 'applychangetags', 'autoconfirmed', 'autopatrol', 'bigdelete', 'block', 'blockemail', 'bot', 'browsearchive', 'changetags', 'createaccount', 'createpage', 'createtalk', 'delete', 'deletechangetags', 'deletedhistory', 'deletedtext', 'deletelogentry', 'deleterevision', 'edit', 'editcontentmodel', 'editinterface', 'editmyoptions', 'editmyprivateinfo', 'editmyusercss', 'editmyuserjs', 'editmyuserjson', 'editmyuserjsredirect', 'editmywatchlist', 'editprotected', 'editsemiprotected', 'editsitecss', 'editsitejs', 'editsitejson', 'editusercss', 'edituserjs', 'edituserjson', 'hideuser', 'import', 'importupload', 'ipblock-exempt', 'managechangetags', 'markbotedits', 'mergehistory', 'minoredit', 'move', 'move-categorypages', 'movefile', 'move-rootuserpages', 'move-subpages', 'nominornewtalk', 'noratelimit', 'patrol', 'protect', 'read', 'renameuser', 'reupload', 'reupload-shared', 'rollback', 'sendemail', 'suppressionlog', 'suppressredirect', 'suppressrevision', 'unblockself', 'undelete', 'unwatchedpages', 'upload', 'userrights', 'viewmyprivateinfo', 'viewmywatchlist', 'viewsuppressed' ];
      1. I strongly agree with the relaxed window of codes
      2. I guess that list of requirements is good
      3. the other two are no longer listed on the wiki, but I guess they're good ?
    1. the docs show an additional option = $wgOATHSecretKey, used for encrypting the secret keys in the db. it suggests this command to generate it https://www.mediawiki.org/wiki/Extension:OATHAuth
hexdump -vn32 -e'8/8 "%08X" "\n"' /dev/urandom
      1. says it's only available since 1.45. I'm not sure if that's the mediawiki version or the extension version.
      2. oh, I guess it's mediawiki, since they ship together. We're running 1.43.8, so I guess we can't use it yet https://wiki.eco-libre.org/wiki/Special:Version
      3. well, I guess let's define it. then it'll automatically start to use it when we upgrade to the next LTS. I think.
    1. ok, here's what I added
root@mail:/var/www/html/wiki.eco-libre.org# diff LocalSettings.20260418.php LocalSettings.php 
220a221,240
> 
> # configure OATHAuth for MFA (2FA). See also:
> # * https://www.mediawiki.org/wiki/Extension:OATHAuth
> # * https://wiki.eco-libre.org/wiki/Maltfield_Log/2026
> wfLoadExtension( 'OATHAuth' );
> 
> # Relaxed mode with +/- 4 minutes time drift tolerance. This is important or users will complain and/or disable 2FA entirely
> # The security consequences are small. The usability benefits are huge.
> $wgOATHAuthWindowRadius = 8;
> 
> # make admins require 2FA
> $wgOATHRequiredForGroups = ['sysop', 'interface-admin', 'bureaucrat', 'suppress', 'widgeteditor' ];
> 
> # make 'powerful' rights require 2FA
> $wgOATHExclusiveRights =  [ 'apihighlimits', 'applychangetags', 'autoconfirmed', 'autopatrol', 'bigdelete', 'block', 'blockemail', 'bot', 'changetags', 'createaccount', 'createtalk', 'delete', 'deletechangetags', 'deletedhistory', 'deletedtext', 'deletelogentry', 'deleterevision', 'editcontentmodel', 'editinterface', 'editprotected', 'editsemiprotected', 'editsitecss', 'editsitejs', 'editsitejson', 'editusercss', 'edituserjs', 'edituserjson', 'hideuser', 'import', 'importupload', 'ipblock-exempt', 'managechangetags', 'markbotedits', 'mergehistory', 'move-categorypages', 'move-rootuserpages', 'move-subpages', 'nominornewtalk', 'noratelimit', 'patrol', 'protect', 'renameuser', 'reupload-shared', 'sendemail', 'suppressionlog', 'suppressredirect', 'suppressrevision', 'unblockself', 'unwatchedpages', 'userrights', ];
> 
> # full list for reference (taken from htdocs/includes/MainConfigSchema.php) https://www.mediawiki.org/wiki/Extension:OATHAuth#Configuration
> #$wgOATHExclusiveRights =  [ 'apihighlimits', 'applychangetags', 'autoconfirmed', 'autopatrol', 'bigdelete', 'block', 'blockemail', 'bot', 'browsearchive', 'changetags', 'createaccount', 'createpage', 'createtalk', 'delete', 'deletechangetags', 'deletedhistory', 'deletedtext', 'deletelogentry', 'deleterevision', 'edit', 'editcontentmodel', 'editinterface', 'editmyoptions', 'editmyprivateinfo', 'editmyusercss', 'editmyuserjs', 'editmyuserjson', 'editmyuserjsredirect', 'editmywatchlist', 'editprotected', 'editsemiprotected', 'editsitecss', 'editsitejs', 'editsitejson', 'editusercss', 'edituserjs', 'edituserjson', 'hideuser', 'import', 'importupload', 'ipblock-exempt', 'managechangetags', 'markbotedits', 'mergehistory', 'minoredit', 'move', 'move-categorypages', 'movefile', 'move-rootuserpages', 'move-subpages', 'nominornewtalk', 'noratelimit', 'patrol', 'protect', 'read', 'renameuser', 'reupload', 'reupload-shared', 'rollback', 'sendemail', 'suppressionlog', 'suppressredirect', 'suppressrevision', 'unblockself', 'undelete', 'unwatchedpages', 'upload', 'userrights', 'viewmyprivateinfo', 'viewmywatchlist', 'viewsuppressed' ];
> 
> $wgOATHSecretKey='REDACTED';
root@mail:/var/www/html/wiki.eco-libre.org# 
    1. ok, now let's update the db
      1. oh, this failed. we need to use the special privliged db user, since we hardened the normal db user
root@mail:/var/www/html/wiki.eco-libre.org# sudo -u www-data php /usr/share/mediawiki/maintenance/run.php update
MediaWiki 1.43.8 Updater

Your composer.lock file is up to date with current dependencies!
Going to run database updates for wiki_el_db-rHb3
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with --quick) ...0
Updating category collations...
Selecting next 100 pages from cl_from = 0... processing... 0 done.
0 rows processed
...done.
Modifying rd_title field of table redirect...Wikimedia\Rdbms\DBQueryError from line 1198 of /usr/share/mediawiki/includes/libs/rdbms/database/Database.php: Error 1142: ALTER command denied to user 'wiki_el_user'@'localhost' for table `wiki_el_db`.`rHb3redirect`
Function: Wikimedia\Rdbms\Database::sourceFile( /usr/share/mediawiki/maintenance/archives/patch-redirect-rd_title-varbinary.sql )
Query: ALTER TABLE `rHb3redirect` MODIFY rd_title VARBINARY(255) NOT NULL default '',
 MODIFY rd_fragment VARBINARY(255) default NULL


#0 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(1182): Wikimedia\Rdbms\Database->getQueryException()
#1 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(1156): Wikimedia\Rdbms\Database->getQueryExceptionAndLog()
#2 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(647): Wikimedia\Rdbms\Database->reportQueryError()
#3 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(2791): Wikimedia\Rdbms\Database->query()
#4 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(2729): Wikimedia\Rdbms\Database->sourceStream()
#5 /usr/share/mediawiki/includes/libs/rdbms/database/DBConnRef.php(127): Wikimedia\Rdbms\Database->sourceFile()
#6 /usr/share/mediawiki/includes/libs/rdbms/database/DBConnRef.php(799): Wikimedia\Rdbms\DBConnRef->__call()
#7 /usr/share/mediawiki/includes/installer/DatabaseUpdater.php(797): Wikimedia\Rdbms\DBConnRef->sourceFile()
#8 /usr/share/mediawiki/includes/installer/DatabaseUpdater.php(1074): MediaWiki\Installer\DatabaseUpdater->applyPatch()
#9 /usr/share/mediawiki/includes/installer/DatabaseUpdater.php(595): MediaWiki\Installer\DatabaseUpdater->modifyField()
#10 /usr/share/mediawiki/includes/installer/DatabaseUpdater.php(548): MediaWiki\Installer\DatabaseUpdater->runUpdates()
#11 /usr/share/mediawiki/maintenance/update.php(195): MediaWiki\Installer\DatabaseUpdater->doUpdates()
#12 /usr/share/mediawiki/maintenance/includes/MaintenanceRunner.php(703): UpdateMediaWiki->execute()
#13 /usr/share/mediawiki/maintenance/run.php(51): MediaWiki\Maintenance\MaintenanceRunner->run()
#14 {main}
root@mail:/var/www/html/wiki.eco-libre.org# 
  1. alright, this worked
root@mail:/var/www/html/wiki.eco-libre.org# sudo -u www-data php /usr/share/mediawiki/maintenance/run.php update --dbuser wiki_el_superuser --dbpass REDACTED
...
done.
Purging caches...done.

Done in 8.3 s.
root@mail:/var/www/html/wiki.eco-libre.org# 
    1. after that, I tried to login. it worked
    2. I expected to be sent to some 2fa registration page, but that didn't happen. it was just like any normal login
    3. I went to special pages to see if I could get it to yell at me to enable 2fa, but that didn't happen
      1. I only see the following bold options on /wiki/Special:SpecialPages (usually admin page). I wonder if this is a subset because the others are just hidden since I don't have 2FA setup? https://wiki.eco-libre.org/wiki/Special:SpecialPages
        1. Manage Two-Factor Authentication, Watchlist, Upload file, Change content model of a page
    4. anyway, I went to "Manage Two-factor authentication" https://wiki.eco-libre.org/wiki/Special:AccountSecurity
    5. I clicked the "Enable" button under TOTP
    6. I scanned the code. It entered it in my TOTP app as "Eco-Libre" – that's not ideal. It should say "Eco-Libre Wiki"
    7. So I updated the LocalSettings.php config with
# This is the name that the entry will have in the user's TOTP app
$wgOATHAuthAccountPrefix='Eco-Libre Wiki';
    1. anyway, I was able to finish the 2FA enrollment process
    2. I went back to SpecialPages, and already I see a *ton* more SpecialPages in bold. So it looks like that restriction worked. Currently I have access to
      1. Unwateched pages, Block user, Create account, Delete user contributions, Disable user's two-factor authentication, Rename user, Unblock user, Verify two-factor authentication status, Watchlist, Upload file, Replace text, Change content model of a page, Import pages, Mass delete, Merge page histories, and View deleted pages.
    3. I also have a notifcation "Two-factor authenication has been enabeld on your account. If you did not do this, your account may have been comprimised."
    4. I logged-out
    5. I logged-in.
      1. First I teted it with 6 zeros (bullshit code), and it rejected it
      2. next I entered the real OTP from my app; it worked
    6. ok, this extension is done.
  1. ...
  2. probably the next-most important one is ConfirmAccount.
    1. Honestly I don't know if I'll use this, as I decided it's better to raise the barrier of entry on the wiki to users that have passed the Eco-Libre test (which is itself very accessible, but it does allow for a onboarding & alignment process that should eliminate spam issues that most wikis have)
    2. perhaps if I can set it up to email the applicant a link to the "volunteer test" docs, that would be helpful to funnel wiki users into the proper volunteer join workflow..
  3. first let me copy the extensions; I ran these commands to put them in-place (yet still deactivated)
rsync -av --progress ./ConfirmAccount /var/www/html/wiki.eco-libre.org/htdocs/extensions/
rsync -av --progress ./SmiteSpam /var/www/html/wiki.eco-libre.org/htdocs/extensions/
rsync -av --progress ./DeleteBatch /var/www/html/wiki.eco-libre.org/htdocs/extensions/
rsync -av --progress ./UserMerge /var/www/html/wiki.eco-libre.org/htdocs/extensions/
rsync -av --progress ./Widgets /var/www/html/wiki.eco-libre.org/htdocs/extensions/
rsync -av --progress ./OATHAuth /var/www/html/wiki.eco-libre.org/htdocs/extensions/
fix_web_permissions.sh
    1. that finished
  1. ok, here's the ConfirmAccount https://www.mediawiki.org/wiki/Extension:ConfirmAccount
    1. hmmm...it says we should use cache type CACHE_DB https://www.mediawiki.org/wiki/Extension:ConfirmAccount#Installation
wfLoadExtension( 'ConfirmAccount' );
$wgSessionCacheType = CACHE_DB; // Avoids stale session state across requests.
$wgGroupPermissions['*']['createaccount'] = false; // REQUIRED to enforce account requests
$wgGroupPermissions['bureaucrat']['createaccount'] = true; // Optional to allow account creation by this trusted user group
        1. I can't find elsewhere that says this specific cache type is requried. We're using APC, which I think is supposed to be more preformant than
      1. I checked the OSE LocalSettings.php config, and it also uses ConfirmAccount *and* CACHE_ACCEL (APC), so surely it's fine
      2. but it also used a bunch of other optimiazations, some of which are necessary for varnish caching
#################
# VARNISH CACHE #
#################

# note that these are named "squid" for historical reasons: wikipedia used to
# use squid, now they use varnish. They say "squid," but also apply to varnish
# * https://www.mediawiki.org/wiki/Manual:Configuration_settings#Squid

# See this guide for more info:
#  * https://www.mediawiki.org/wiki/Manual:Varnish_caching

#$wgUseSquid = true;
#$wgSquidServers = array('opensourceecology.org');
#$wgSquidServersNoPurge = array('127.0.0.1');

$wgUseSquid = true;
$wgSquidServers = array( '127.0.0.1:6081' );
$wgUsePrivateIPs = true;

#################
# OPTIMIZATIONS #
#################

# See these links for more info:
#  * https://www.mediawiki.org/wiki/Manual:Performance_tuning
#  * https://www.mediawiki.org/wiki/Manual:Caching
#  * https://www.mediawiki.org/wiki/User:Aaron_Schulz/How_to_make_MediaWiki_fast

# INTERNAL MEDIAWIKI CACHE OPTIONS (DISTINCT FROM VARNISH)

# MainCache and MessageCache should use APCU per Aaron Schulz
$wgMainCacheType = CACHE_ACCEL;

# note that if message cache uses the db (per defaults), then it may make every
# page load include a db change, which causes mediawiki to emmit a set-cookie
# for cpPosTime. The cookie's presence coming from the backend causes varnish
# not to cache the page (rightfully so), and the result is that varnish (which
# is our most important cache) is rendered useless. For more info, see:
#  * https://www.mediawiki.org/wiki/Topic:U9fys4phj04a85vu
#  * https://wiki.opensourceecology.org/wiki/Maltfield_log_2018#Thr_Mar_15.2C_2018
$wgMessageCacheType = CACHE_ACCEL;
$wgUseLocalMessageCache = true;

# Parser Cache should still use the DB per Aaron Schulz
$wgParserCacheType = CACHE_DB;

# enable caching navigation sidebar per Aaron Schulz
$wgEnableSidebarCache = true;

# cache interface messages to files in this directory per Aaron Schulz
# note that this should be outside the docroot!
$wgCacheDirectory = "$IP/../cache";

# OTHER OPTIMIZATIONS

# decrease db-heavy features per Aaron Schulz
$wgMiserMode = true;

# Causes serious encoding problems
$wgUseGzip = false;
    1. I added this to our LocalSettings.php, except I hard-coded the wgCacheDirectory to '/var/www/html/wiki.eco-libre.org/cache'
    2. here's the ConfirmAccounts-related (and ConfirmEdit-related) config from OSE's LocalSettings.php
# ConfirmAccount
# This extension and directory requires an admin to confirm a user before their 
account is created

require_once "$IP/extensions/ConfirmAccount/ConfirmAccount.php";
$wgFileStore['accountreqs'] = "$IP/images/ConfirmAccount";
$wgFileStore['accountcreds'] = "$IP/images/ConfirmAccount";
$wgConfirmAccountContact = 'REDACTED@opensourceecology.org';


# ConfirmEdit
# reCaptcha settings and keys

wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/ReCaptcha' ]);
#$wgCaptchaClass = 'ReCaptcha';
$wgCaptchaClass = 'SimpleCaptcha';
#$wgCaptchaClass = 'QuestyCaptcha';

#$wgReCaptchaPublicKey = 'REDACTED';
#$wgReCaptchaPrivateKey = 'REDACTED';
$wgReCaptchaPublicKey = 'REDACTED';
$wgReCaptchaPrivateKey = 'REDACTED';

# https://www.google.com/recaptcha/admin/site?siteid=REDACTED - old style
#$recaptcha_public_key = 'REDACTED';
#$recaptcha_private_key = 'REDACTED';

$wgGroupPermissions['*'            ]['skipcaptcha'] = false;
$wgGroupPermissions['user'         ]['skipcaptcha'] = true;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = true;
$wgGroupPermissions['bot'          ]['skipcaptcha'] = true; // registered bots
$wgGroupPermissions['sysop'        ]['skipcaptcha'] = true;

# Allow admins to approve (and unapprove) users via Special:UserRights
$wgAddGroups['sysop']['approved'] = true;
$wgRemoveGroups['sysop']['approved'] = true;
    1. of note is that I was planning on moving OSE from recaptcha to FancyCaptcha https://wiki.opensourceecology.org/wiki/CHG-2025-XX-XX_migrate_wiki_to_hetzner3
# re-enable ConfirmEdit and switch to FancyCaption
grep 'FancyCaptcha' ${vhostDir}/LocalSettings.php || perl -0777 -pi -e "s%\\\$wgCaptchaClass = 'SimpleCaptcha';%\#\\\$wgCaptchaClass = 'SimpleCaptcha';\n\nwfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/FancyCaptcha' ]);\n\\\$wgCaptchaDirectory = '/var/www/html/wiki.opensourceecology.org/htdocs/images/captcha/';\n\\\$wgCaptchaSecret = '$wgCaptchaSecret';\n%igs" ${vhostDir}/LocalSettings.php
    1. oh shit, there's a known issue with ConfirmAccounts that it doesn't work at all on mediawiki v1.43. it was opened a year ago X_x https://www.mediawiki.org/wiki/Extension:ConfirmAccount#Known_issues
      1. well, hopefully that gets fixed before we upgrade to the latest LTS?
    2. ok, I'm just going to add this to LocalSettings.php
# configure ConfirmAccount. See also:
# * https://www.mediawiki.org/wiki/Extension:ConfirmAccount
# * https://wiki.eco-libre.org/wiki/Maltfield_Log/2026
wfLoadExtension( 'ConfirmAccount' );

# REQUIRED to enforce account requests
$wgGroupPermissions['*']['createaccount'] = false;
    1. and, per the wiki extensions' page, I ran the update script
root@mail:/var/www/html/wiki.eco-libre.org# sudo -u www-data php /usr/share/mediawiki/maintenance/run.php update --dbuser wiki_el_superuser --dbpass REDACTED
...
...Update 'MediaWiki\Maintenance\FixAutoblockLogTitles' already logged as completed. Use --force to run it again.
Purging caches...done.

Done in 2.2 s.
root@mail:/var/www/html/wiki.eco-libre.org# 
    1. I went to the SpecialPages, I now see "ConfirmAccounts Requests" https://wiki.eco-libre.org/wiki/Special:ConfirmAccounts
    2. Now, in a tor browser where I'm *not* logged-in, I can click on "Anonymous" in the top-right and click on "Request account" https://wiki.eco-libre.org/wiki/Special:RequestAccount
    3. there's this weird thing that people have to agree to the ToS *and* that their real name is real.
      1. that first one is reasonable (though we haven't written a ToS yet)
      2. that second one is dumb. why wouldn't we let users contribute anonymously?
        1. so I edited the LocalSettings.php with this
# we let folks contribute under pseudonyms 
$wgConfirmAccountRequestFormItems = [
   'UserName'        => [ 'enabled' => true ],
   'RealName'        => [ 'enabled' => false ],
   'Biography'       => [ 'enabled' => false, 'minWords' => 50 ],
   'AreasOfInterest' => [ 'enabled' => true ],
   'CV'              => [ 'enabled' => true ],
   'Notes'           => [ 'enabled' => true ],
   'Links'           => [ 'enabled' => true ],
   'TermsOfService'  => [ 'enabled' => true ],
 ];
    1. ugh, it still has the same text about the "Real Name" – even after we disabled it
    2. looks like I need to create a wiki arrticle with the text that I want here https://wiki.eco-libre.org/wiki/MediaWiki:Requestaccount-text
      1. so the default text for this article is
'Complete and submit the following form to request a user account'.

Make sure that you first read the Terms of Service before requesting an account.

Once the account is approved, you will be emailed a notification message and the account will be usable at login.
      1. what I want is the "accept" text, which replaces this
I have read and agree to abide by the Terms of Service of Eco-Libre. The name I have specified under "Real name" is in fact my own real name.
      1. here's a list of all the system messages, according to the extensions wiki page https://www.mediawiki.org/wiki/Extension:ConfirmAccount#Minimal
        1. requestaccount-text, requestaccount-notes, requestaccount-ext-text, requestaccount-acc-text
          1. this is not it https://wiki.eco-libre.org/wiki/MediaWiki:Requestaccount-acc-text
A confirmation message will be sent to your email address once you submit this request. The address will not be published. Please respond by clicking on the confirmation link provided by the email. Finally, your password will be emailed to you when your account is created. 
        1. nor this https://wiki.eco-libre.org/wiki/MediaWiki:Requestaccount-ext-text
The following information is kept private and will only be used for this request. You may want to list contacts such a phone number to aid in identify confirmation. 
      1. I just searched the string, and found this
root@mail:/var/www/html/wiki.eco-libre.org# grep -irl 'is in fact my own real name' *
cache/l10n_cache-en.cdb
htdocs/extensions/ConfirmAccount/i18n/requestaccount/en.json
root@mail:/var/www/html/wiki.eco-libre.org# 
        1. so it looks like we need to edit one of these
root@mail:/var/www/html/wiki.eco-libre.org# grep -i 'real name' htdocs/extensions/ConfirmAccount/i18n/requestaccount/en.json
		"requestaccount-real": "Real name (optional):",
		"requestaccount-real-i": "Real name is optional. If you choose to provide it, this will be used for giving the user attribution for their work.",
		"requestaccount-same": "(same as real name below)",
		"requestaccount-agree": "You must certify that your real name is correct and that you agree to our Terms of Service.",
		"requestaccount-tos": "I have read and agree to abide by the [[{{MediaWiki:Requestaccount-page}}|Terms of Service]] of {{SITENAME}}.\nThe name I have specified under \"Real name\" is in fact my own real name.",
root@mail:/var/www/html/wiki.eco-libre.org# 
        1. I edited these two pages
          1. https://wiki.eco-libre.org/wiki/MediaWiki:Requestaccount-tos
          2. https://wiki.eco-libre.org/wiki/MediaWiki:Requestaccount-agree
      1. that worked; the agree text changed when I refresh the RequsetAccount form in tor browser
      2. I entered the min inforamtion, and got this response
Your account request has been sent and is now pending review. A confirmation email has been sent to your email address.

Return to Main Page.
        1. curiously, that means it didn't force me to enter a CV, bio, or the list of websites
        2. I also got an email from noreply@eco-libre.org. It just basically asked me to click an email. Good GDPR compliance.
          1. wait, I refreshed the special page as admin. it shows-up for review. so I guess not GDPR compliant :(
          2. also the ip address listed is 127.0.0.1. Perhaps I need to configure MediaWiki to process X-Forwarded-For headers
      1. I changed 'false' to 'true' for the biography; now it appears again
$wgConfirmAccountRequestFormItems = [
   'UserName'        => [ 'enabled' => true ],
   'RealName'        => [ 'enabled' => false ],
   'Biography'       => [ 'enabled' => true, 'minWords' => 50 ],
   'AreasOfInterest' => [ 'enabled' => true ],
   'CV'              => [ 'enabled' => true ],
   'Notes'           => [ 'enabled' => true ],
   'Links'           => [ 'enabled' => true ],
   'TermsOfService'  => [ 'enabled' => true ],
 ];
    1. the workflow is for, after being approved, the system emails the passowrd. that's not very secure. we should, at least, make sure to require the user to change their password on first login
      1. I was looking for a way to force users to change their password on first login, but I first found this in the OSE config
#############
# HARDENING #
#############

$wgSecureLogin = true;
$wgSecretKey = 'REDACTED';

# PASSWORD POLICIES

$wgPasswordPolicy['policies']['default']['MinimalPasswordLength'] = 10;
$wgPasswordPolicy['policies']['default']['PasswordCannotBePopular'] = PHP_INT_MAX;
$wgPasswordPolicy['policies']['default']['PasswordCannotMatchUsername'] = true;

$wgPasswordPolicy['policies']['sysop']['MinimalPasswordLength'] = 20
      1. I added this to stack exchange https://webapps.stackexchange.com/questions/182290/how-to-force-new-users-to-reset-their-password-mediawiki
  1. TODO: figure-out how to force new users to change their password, if it was auto-generated by mediawiki
  2. TODO: create ToS page https://wiki.eco-libre.org/wiki/Eco-Libre:Terms_of_Service
  3. TODO: figure-out how to make mediawiki see the IP as X-Forwarded-For (to play nice with nginx->varnish->apache)
  4. TODO: finish activating & configuring the remaining "new" extensions

2026-04-17

  1. shit, we're getting a 500 error on the wiki today
[user@disp3459 ~]$ curl -iL https://wiki.eco-libre.org
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Sat, 18 Apr 2026 00:57:02 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: keep-alive
X-Content-Type-Options: nosniff
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Request-Id: REDACTED
X-Frame-Options: SAMEORIGIN
Set-Cookie: mw_installer_session=REDACTED; path=/; secure; HttpOnly; SameSite=Strict;HttpOnly;Secure
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: deny
Referrer-Policy: strict-origin
X-Varnish: 18804052
Age: 0
Via: 1.1 mail (Varnish/7.7)

[user@disp3459 ~]$ 
  1. looks like open_basedir?
[Sat Apr 18 00:59:28.202275 2026] [proxy_fcgi:error] [pid 3214280:tid 3214323] [client 127.0.0.1:0] AH01071: Got error 'PHP message: PHP Warning:  is_readable(): open_basedir restriction in effect. File(/usr/share/mediawiki/LocalSettings.php) is not within the allowed path(s): (...) in /usr/share/mediawiki/includes/Output/NoLocalSettings.php on line 59; PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function Wikimedia\\ObjectCache\\ini_set() in /usr/share/mediawiki/includes/libs/objectcache/APCUBagOStuff.php:55\nStack trace:\n#0 /usr/share/mediawiki/includes/utils/FileContentsHasher.php(37): Wikimedia\\ObjectCache\\APCUBagOStuff->construct()\n#1 /usr/share/mediawiki/includes/utils/FileContentsHasher.php(47): FileContentsHasher->construct()\n#2 /usr/share/mediawiki/includes/utils/FileContentsHasher.php(93): FileContentsHasher::singleton()\n#3 /usr/share/mediawiki/includes/Html/TemplateParser.php(271): FileContentsHasher::getFileContentsHash()\n#4 /usr/share/mediawiki/includes/Html/TemplateParser.php(173): MediaWiki\\Html\\TemplateParser->compile()\n#5 /usr/share/mediawiki/includes/Html/TemplateParser.php(296): MediaWiki\\Html\\TemplateParser->getTemplate()\n#6 /usr/share/mediawiki/includes/Output/NoLocalSettings.php(54): MediaWiki\\Html\\TemplateParser->processTemplate()\n#7 /usr/share/mediawiki/includes/WebStart.php(51): require_once('...')\n#8...'
  1. it's just a symlink to a symlink to a non-existant file. is that the issue?
root@mail:/usr/share/mediawiki/includes/libs/rdbms/database# ls -lah /usr/share/mediawiki/LocalSettings.php
lrwxrwxrwx 1 root root 36 Apr 10 22:17 /usr/share/mediawiki/LocalSettings.php -> /var/lib/mediawiki/LocalSettings.php
root@mail:/usr/share/mediawiki/includes/libs/rdbms/database# ls -lah /var/lib/mediawiki/LocalSettings.php
lrwxrwxrwx 1 root root 32 Apr 10 22:17 /var/lib/mediawiki/LocalSettings.php -> /etc/mediawiki/LocalSettings.php
root@mail:/usr/share/mediawiki/includes/libs/rdbms/database# ls -lah /etc/mediawiki/LocalSettings.php
ls: cannot access '/etc/mediawiki/LocalSettings.php': No such file or directory
root@mail:/usr/share/mediawiki/includes/libs/rdbms/database# 
  1. wtf. the file is here, but it's not here?
root@mail:/var/lib/mediawiki# ls LocalSettings.php 
LocalSettings.php
root@mail:/var/lib/mediawiki# cat LocalSettings.php 
cat: LocalSettings.php: No such file or directory
root@mail:/var/lib/mediawiki# 
  1. oh, it's because it's a symlink
root@mail:/var/lib/mediawiki# ls -lah /var/www/html/wiki.eco-libre.org/htdocs/LocalSettings.php 
lrwxrwxrwx 1 root root 32 Apr 10 22:17 /var/www/html/wiki.eco-libre.org/htdocs/LocalSettings.php -> /etc/mediawiki/LocalSettings.php
root@mail:/var/lib/mediawiki# cat /var/www/html/wiki.eco-libre.org/htdocs/LocalSettings.php 
cat: /var/www/html/wiki.eco-libre.org/htdocs/LocalSettings.php: No such file or directory
root@mail:/var/lib/mediawiki# 
  1. that definitely was a file before. I set it to just require() the real file from one dir up (outside the docroot). but why is it gone now? could it have been deleted by a security upgrade in apt? unattended-upgrades perhaps?
    1. well, that's a match
root@mail:/var/log/unattended-upgrades# grep -irl mediawiki *
unattended-upgrades-dpkg.log
unattended-upgrades.log
root@mail:/var/log/unattended-upgrades# 
  1. yeah, it looks like we upgraded on 2026-04-13. That was Monday. Today is Friday.
root@mail:/var/log/unattended-upgrades# grep -ir mediawiki *
unattended-upgrades-dpkg.log:Preparing to unpack .../mediawiki_1%3a1.43.8+dfsg-1~deb13u1_all.deb ...
unattended-upgrades-dpkg.log:Unpacking mediawiki (1:1.43.8+dfsg-1~deb13u1) over (1:1.43.6+dfsg-1~deb13u1) ...
unattended-upgrades-dpkg.log:Preparing to unpack .../mediawiki-classes_1%3a1.43.8+dfsg-1~deb13u1_all.deb ...
unattended-upgrades-dpkg.log:Unpacking mediawiki-classes (1:1.43.8+dfsg-1~deb13u1) over (1:1.43.6+dfsg-1~deb13u1) ...
unattended-upgrades-dpkg.log:Setting up mediawiki-classes (1:1.43.8+dfsg-1~deb13u1) ...
unattended-upgrades-dpkg.log:Setting up mediawiki (1:1.43.8+dfsg-1~deb13u1) ...
unattended-upgrades-dpkg.log:apache2_invoke mediawiki: already enabled
unattended-upgrades-dpkg.log:mediawiki-jobrunner.service is a disabled or a static unit not running, not starting it.
unattended-upgrades.log:2026-04-13 06:07:02,546 INFO Packages that will be upgraded: mediawiki mediawiki-classes
root@mail:/var/log/unattended-upgrades# 
  1. mediawiki announced two releases on 2026-04-01. One was a normal maintenance release (1.43.8). One was a security release (1.43.7)
    1. https://lists.wikimedia.org/hyperkitty/list/mediawiki-announce@lists.wikimedia.org/thread/DIBLSBHISKX6NFRUFNOGZRVW42E7R2QP/
    2. https://lists.wikimedia.org/hyperkitty/list/mediawiki-announce@lists.wikimedia.org/thread/6VW6OGVSC7LO3QUMBEZOPQFYYOFDJ452/
  2. well, it's good that we confirmed that securty updates are getting automatically installed.
  3. ok, well, obviously we need to follow the debian-way and put the LocalSettings.php file in /etc/.\
    1. I did that
root@mail:/var/lib/mediawiki# cat /etc/mediawiki/LocalSettings.php
<?php
# including separate file that contains the database password so that it is not stored within the document root.
# For more info see:
#  * https://tech.michaelaltfield.net/2020/02/14/phplist-hardening-security/
#  * https://www.mediawiki.org/wiki/Manual:Security
#  * https://wiki.r00tedvw.com/index.php/Mediawiki/Hardening
 
#$docRoot = dirname( $_SERVER['DOCUMENT_ROOT'] );
#require_once "$docRoot/LocalSettings.php";

# docRoot didn't work for all of:
#  1. php-fpm (the normal website)
#  2. cli
#  3. the fact that we're in /var/lib/mediawiki due to debian's install symlink
#
# ...so I'm just hardcoding the path to LocalSettings.php, so it always works!

require_once( "/var/www/html/wiki.eco-libre.org/LocalSettings.php" );
?>
root@mail:/var/lib/mediawiki# 
  1. I tried the site; it's still broken
  2. I cleared varnish cache; it's still broken
root@mail:/var/lib/mediawiki# varnishadm 'ban req.url ~ "."'

root@mail:/var/lib/mediawiki# 
  1. yeah, I think the problem is that I never added /etc/mediawiki into the basedir, because I wasn't using it there. Ugh.
  2. I don't like doing this, but there's nothing else there. should be fine
root@mail:/var/lib/mediawiki# ls -lah /etc/mediawiki/
total 20K
drwxr-xr-x   2 root root 4,0K Apr 18 01:16 .
drwxr-xr-x 120 root root  12K Apr 17 20:30 ..
-rw-r--r--   1 root root  741 Apr 18 01:16 LocalSettings.php
root@mail:/var/lib/mediawiki# 

2026-04-14

  1. Appropedia responded to me, indicating that they use Vector 2022 skin, with these config options https://wordpress.org/support/topic/support-for-automatic-exchange-rates-wp_http_block_external-2/#
:wfLoadSkin( 'Vector' );
:$wgDefaultSkin = 'vector-2022';
:$wgSkipSkins[] = 'vector'; // Disable old Vector
:$wgVectorResponsive = true;
:$wgVectorMaxWidthOptions['exclude']['mainpage'] = false;
:$wgVectorNightMode['logged_out'] = true;
:$wgDefaultUserOptions['vector-main-menu-pinned'] = 0;
:$wgDefaultUserOptions['vector-page-tools-pinned'] = 0;
:$wgDefaultUserOptions['vector-appearance-pinned'] = 0;
:$wgDefaultUserOptions['vector-toc-pinned'] = 0;
:$wgDefaultUserOptions['vector-font-size'] = 1;
  1. they said they use this extension for "read mode" which they developed themselves https://www.mediawiki.org/wiki/Extension:ReadMode

2026-04-13

  1. Here's TOFU 3/3 (Tor, exit in The Netherlands)
The Netherlands
	  Congratulations. This browser is configured to use Tor.
2026-04-13
######################################################################### 100.0%
2026-04-13
14M	OATHAuth-REL1_43-015a49e.tar.gz
9ee56e843931edd87b631b264d680e9f8d77f18b5ffdbc18b9a4f5b15330878e  OATHAuth-REL1_43-015a49e.tar.gz
user@host:/tmp/user/1000/tmp.eIvrMPff3B$ 

2026-04-10

  1. Here's TOFU 2/3 (VPN, exit in US)
United States
2026-04-10
######################################################################### 100.0%
2026-04-10
14M	OATHAuth-REL1_43-015a49e.tar.gz
9ee56e843931edd87b631b264d680e9f8d77f18b5ffdbc18b9a4f5b15330878e  OATHAuth-REL1_43-015a49e.tar.gz
user@disp5712:/tmp/tmp.oTeGPpTCzP$ 
  1. finally, they all match! great, that's our last extension

2026-04-09

  1. Here's TOFU 3/3 (ISP, exit in Ecuador)
Ecuador
2026-04-09
######################################################################### 100.0%
2026-04-09
4.0K	OATHAuth-REL1_43-967ccd4.tar.gz
8351c0267c2cd7866ff04c04261f06cd75af9a7130aac848ca43fd047404e229  OATHAuth-REL1_43-967ccd4.tar.gz
user@disp7124:/tmp/tmp.wlx3U02c6r$ 
  1. fuck, it's already unavailable; says 'libraryupgrader' from 3 hours ago >:0
  2. let's try again
REMOTE_FILES="https://extdist.wmflabs.org/dist/extensions/OATHAuth-REL1_43-015a49e.tar.gz"

CURL="/usr/bin/curl --retry 5 --retry-all-errors"
PYTHON="/usr/bin/python3"

# in tails, we must torify
if [[ "`whoami`" == "amnesia" ]] ; then
	CURL="/usr/bin/torify ${CURL}"
	PYTHON="/usr/bin/torify ${PYTHON}"
fi

tmpDir=`mktemp -d`
pushd "${tmpDir}"

# first get some info about our internet connection
${CURL} -s https://ifconfig.co/country | head -n1
${CURL} -s https://check.torproject.org | grep Congratulations | head -n1

# and today's date
date -u +"%Y-%m-%d"

# get the file
for file in ${REMOTE_FILES}; do
	${CURL} --progress-bar -O ${file}
done

# checksum
date -u +"%Y-%m-%d"
du -sh *
sha256sum *
  1. Here's TOFU 1/3 (ISP, exit in Ecuador)
Ecuador
2026-04-09
######################################################################### 100.0%
2026-04-09
14M	OATHAuth-REL1_43-015a49e.tar.gz
9ee56e843931edd87b631b264d680e9f8d77f18b5ffdbc18b9a4f5b15330878e  OATHAuth-REL1_43-015a49e.tar.gz
user@disp7124:/tmp/tmp.rGKb4qtHLX$ 


2026-04-08

  1. Here's TOFU 2/3 (VPN, exit in UK)
United Kingdom
2026-04-08
############################################################################## 100.0%
2026-04-08
14M	OATHAuth-REL1_43-967ccd4.tar.gz
5992bf6044ba5bd6404d51ec5bef936e6eb724576a2003fc176648c7fcf9c6b7  OATHAuth-REL1_43-967ccd4.tar.gz
user@disp6902:/tmp/tmp.KDMVCsn1cU$ 

2026-04-07

  1. here's TOFU 3/3 (Tor, exit in The Netherlands)
The Netherlands
	  Congratulations. This browser is configured to use Tor.
2026-04-07
####################################################################### 100.0%
####################################################################### 100.0%
####################################################################### 100.0%
2026-04-07
448K	ConfirmAccount-REL1_43-38c4602.tar.gz
124K	DeleteBatch-REL1_43-b3b052b.tar.gz
4.0K	OATHAuth-REL1_43-2cdbefb.tar.gz
95b2bc67977c22d069867a7225aa1a9720b7593ed5ab49aa27cc293f01b2e2bb  ConfirmAccount-REL1_43-38c4602.tar.gz
d1e7c01cf709f2b57137bb3d76f73b4e8fd36ce57c12b750b04fe20ffce9be61  DeleteBatch-REL1_43-b3b052b.tar.gz
8351c0267c2cd7866ff04c04261f06cd75af9a7130aac848ca43fd047404e229  OATHAuth-REL1_43-2cdbefb.tar.gz
user@host:/tmp/user/1000/tmp.qw9hrOvh3l$ 
  1. ok, well, we're 2/3 for that one. ConfirmAccount and DeleteBatch both have the same on all 3 TOFUs.
    1. But OATHAuth must have had a new release, because it's now 404
user@host:/tmp/user/1000/tmp.qw9hrOvh3l$ cat OATHAuth-REL1_43-2cdbefb.tar.gz 
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>
user@host:/tmp/user/1000/tmp.qw9hrOvh3l$ 
  1. I checked the changelog. looks like this extension is getting updated almost every 1-2 days from "Translation updater bot" – that's terrible. We need three consecutive days of no changes for 3TOFU https://www.mediawiki.org/wiki/Extension:OATHAuth
    1. hmm, well, if I look back further, there was a gap of 2 months before the update 6 days ago. So there certainly is *some* stability.
    2. also, that was *all* commits. This one limits to just the 1.43 branch, which is what we want https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/OATHAuth/+log/refs/heads/REL1_43
      1. hmm, that one shows the last update was 10 hours ago, and the one before that was 2 months ago (Jan 22). That would be fine, but didn't we have two consecutive 3TOFUs fail on us?
      2. oh, wait, woah. the commits are out of order! First it shows "10 hours ago" and then "2 months ago" and then "7 days ago" wtf!
gerrit.wikimedia.org / mediawiki / extensions / OATHAuth / refs/heads/REL1_43

	967ccd4 Localisation updates from https://translatewiki.net. by Translation updater bot · 10 hours ago REL1_43
	2cdbefb SECURITY: Don't leak user's lack of 2FA to other users by Roan Kattouw · 2 months ago
	bfcd5cf Localisation updates from https://translatewiki.net. by Translation updater bot · 7 days ago
	d8e7578 build: Updating npm dependencies by libraryupgrader · 12 days ago
	be14e83 Localisation updates from https://translatewiki.net. by Translation updater bot · 2 weeks ago
	77c70f5 build: Updating flatted to 3.4.2 by libraryupgrader · 3 weeks ago
	87d04d4 Localisation updates from https://translatewiki.net. by Translation updater bot · 3 weeks ago
	8e176b2 Localisation updates from https://translatewiki.net. by Translation updater bot · 4 weeks ago
	14596de Localisation updates from https://translatewiki.net. by Translation updater bot · 5 weeks ago
	8c7891a build: Updating ajv to 6.14.0, 8.18.0 by libraryupgrader · 6 weeks ago
	0406194 Localisation updates from https://translatewiki.net. by Translation updater bot · 6 weeks ago
	4c94235 Localisation updates from https://translatewiki.net. by Translation updater bot · 7 weeks ago
	7d0b2d7 Localisation updates from https://translatewiki.net. by Translation updater bot · 8 weeks ago
	a896cff Localisation updates from https://translatewiki.net. by Translation updater bot · 9 weeks ago
	b8e8afa Localisation updates from https://translatewiki.net. by Translation updater bot · 2 months ago
	4b3cb73 build: Updating lodash to 4.17.23 by libraryupgrader · 2 months ago
  1. well, it looks like the translator bot runs once per week. so we should have 6 days before that one changes again..
  2. anyway, here's our (hopefully last) 3TOFU script, just for OATHAuth
REMOTE_FILES="https://extdist.wmflabs.org/dist/extensions/OATHAuth-REL1_43-967ccd4.tar.gz"

CURL="/usr/bin/curl --retry 5 --retry-all-errors"
PYTHON="/usr/bin/python3"

# in tails, we must torify
if [[ "`whoami`" == "amnesia" ]] ; then
	CURL="/usr/bin/torify ${CURL}"
	PYTHON="/usr/bin/torify ${PYTHON}"
fi

tmpDir=`mktemp -d`
pushd "${tmpDir}"

# first get some info about our internet connection
${CURL} -s https://ifconfig.co/country | head -n1
${CURL} -s https://check.torproject.org | grep Congratulations | head -n1

# and today's date
date -u +"%Y-%m-%d"

# get the file
for file in ${REMOTE_FILES}; do
	${CURL} --progress-bar -O ${file}
done

# checksum
date -u +"%Y-%m-%d"
du -sh *
sha256sum *
  1. and TOFU 1/3 (Tor, exit in The Netherlands)
The Netherlands
	  Congratulations. This browser is configured to use Tor.
2026-04-07
####################################################################### 100.0%
2026-04-07
14M	OATHAuth-REL1_43-967ccd4.tar.gz
5992bf6044ba5bd6404d51ec5bef936e6eb724576a2003fc176648c7fcf9c6b7  OATHAuth-REL1_43-967ccd4.tar.gz
user@host:/tmp/user/1000/tmp.RBxv6XdjXd$ 

2026-04-06

  1. here's TOFU 2/3 (VPN, exit in Germany)
Germany
2026-04-06
#################################################################################### 100.0%
#################################################################################### 100.0%
#################################################################################### 100.0%
2026-04-06
448K	ConfirmAccount-REL1_43-38c4602.tar.gz
124K	DeleteBatch-REL1_43-b3b052b.tar.gz
14M	OATHAuth-REL1_43-2cdbefb.tar.gz
95b2bc67977c22d069867a7225aa1a9720b7593ed5ab49aa27cc293f01b2e2bb  ConfirmAccount-REL1_43-38c4602.tar.gz
d1e7c01cf709f2b57137bb3d76f73b4e8fd36ce57c12b750b04fe20ffce9be61  DeleteBatch-REL1_43-b3b052b.tar.gz
f71115af96a1ed5297d8d56f56683635b7c9e0b8b32151b184feea1fbec3350a  OATHAuth-REL1_43-2cdbefb.tar.gz
user@disp8963:/tmp/tmp.JNwdKPbQIW$ 

2026-04-01

  1. continuing with the wiki setup today
  2. I saw our db partition reached 90%. It's been growing slowly, but adding mediawiki to the server didn't help, so I spent some time expanding the disks. Now we're down to 48% usage on the db partition, and everything else is hovering around 60% used, +/- 5%
  3. here's our last TOFU on the mediawiki extensions
    1. TOFU 3/3 (ISP, exit in Ecuador)
Ecuador
2026-04-01
######################################################################### 100.0%
######################################################################### 100.0%
######################################################################### 100.0%
######################################################################### 100.0%
######################################################################### 100.0%
######################################################################### 100.0%
2026-04-01
4.0K	ConfirmAccount-REL1_43-9cc1a82.tar.gz
4.0K	DeleteBatch-REL1_43-24a81e4.tar.gz
4.0K	OATHAuth-REL1_43-d8e7578.tar.gz
108K	SmiteSpam-REL1_43-483b81b.tar.gz
140K	UserMerge-REL1_43-27425da.tar.gz
492K	Widgets-REL1_43-60a09f0.tar.gz
8351c0267c2cd7866ff04c04261f06cd75af9a7130aac848ca43fd047404e229  ConfirmAccount-REL1_43-9cc1a82.tar.gz
8351c0267c2cd7866ff04c04261f06cd75af9a7130aac848ca43fd047404e229  DeleteBatch-REL1_43-24a81e4.tar.gz
8351c0267c2cd7866ff04c04261f06cd75af9a7130aac848ca43fd047404e229  OATHAuth-REL1_43-d8e7578.tar.gz
997c9edfe7ab78d6e1f1268d48ec19f13d036f584ad54c4281e210940a59f7c9  SmiteSpam-REL1_43-483b81b.tar.gz
5f28fdf7c0b727d699d42f14073359e13c8db1b2d389d78219845b5912cc0ccc  UserMerge-REL1_43-27425da.tar.gz
bed64d3c98842f7ec3675e17a24c21fb4720862084857e6834fb7813d14ab865  Widgets-REL1_43-60a09f0.tar.gz
user@disp7799:/tmp/tmp.YkN2s6MgT6$ 

  1. huh, 3TOFU failed for 3/5 of the extensions
    1. SmiteSpam, UserMerge, and Widgets matched on all three
    2. but ConfirmAccount, DeleteBatch, and OATHAuthOATHAuth diff'd
  2. I see that the file size of the three that failed is "4.0K". that suggests that it didn't actually download
  3. sure enough, they're 404'd
user@disp7799:/tmp/tmp.YkN2s6MgT6$ cat ConfirmAccount-REL1_43-9cc1a82.tar.gz
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>
user@disp7799:/tmp/tmp.YkN2s6MgT6$ 
user@disp7799:/tmp/tmp.YkN2s6MgT6$ cat DeleteBatch-REL1_43-24a81e4.tar.gz
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>
user@disp7799:/tmp/tmp.YkN2s6MgT6$ 
user@disp7799:/tmp/tmp.YkN2s6MgT6$ cat OATHAuth-REL1_43-d8e7578.tar.gz
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>
user@disp7799:/tmp/tmp.YkN2s6MgT6$ 
  1. if I go to download these plugins again, here's the URLs I get
    1. ConfirmAccount https://www.mediawiki.org/wiki/Extension:ConfirmAccount
      1. https://extdist.wmflabs.org/dist/extensions/ConfirmAccount-REL1_43-38c4602.tar.gz
    2. DeleteBatch https://www.mediawiki.org/wiki/Extension:ConfirmAccount
      1. https://extdist.wmflabs.org/dist/extensions/DeleteBatch-REL1_43-b3b052b.tar.gz
    3. OATHAuth https://www.mediawiki.org/wiki/Extension:OATHAuth
      1. https://extdist.wmflabs.org/dist/extensions/OATHAuth-REL1_43-2cdbefb.tar.gz
  2. here's our old 3TOFU script, for comparison
REMOTE_FILES="https://extdist.wmflabs.org/dist/extensions/ConfirmAccount-REL1_43-9cc1a82.tar.gz https://extdist.wmflabs.org/dist/extensions/DeleteBatch-REL1_43-24a81e4.tar.gz https://extdist.wmflabs.org/dist/extensions/OATHAuth-REL1_43-d8e7578.tar.gz https://extdist.wmflabs.org/dist/extensions/SmiteSpam-REL1_43-483b81b.tar.gz https://extdist.wmflabs.org/dist/extensions/UserMerge-REL1_43-27425da.tar.gz https://extdist.wmflabs.org/dist/extensions/Widgets-REL1_43-60a09f0.tar.gz"

CURL="/usr/bin/curl --retry 5 --retry-all-errors"
PYTHON="/usr/bin/python3"

# in tails, we must torify
if [[ "`whoami`" == "amnesia" ]] ; then
	CURL="/usr/bin/torify ${CURL}"
	PYTHON="/usr/bin/torify ${PYTHON}"
fi

tmpDir=`mktemp -d`
pushd "${tmpDir}"

# first get some info about our internet connection
${CURL} -s https://ifconfig.co/country | head -n1
${CURL} -s https://check.torproject.org | grep Congratulations | head -n1

# and today's date
date -u +"%Y-%m-%d"

# get the file
for file in ${REMOTE_FILES}; do
	${CURL} --progress-bar -O ${file}
done

# checksum
date -u +"%Y-%m-%d"
du -sh *
sha256sum *
  1. so, yeah, I guess they delete the old releases when the push a new one? that's pretty annoying
https://extdist.wmflabs.org/dist/extensions/ConfirmAccount-REL1_43-9cc1a82.tar.gz
https://extdist.wmflabs.org/dist/extensions/ConfirmAccount-REL1_43-38c4602.tar.gz

https://extdist.wmflabs.org/dist/extensions/DeleteBatch-REL1_43-24a81e4.tar.gz
https://extdist.wmflabs.org/dist/extensions/DeleteBatch-REL1_43-b3b052b.tar.gz

https://extdist.wmflabs.org/dist/extensions/OATHAuth-REL1_43-d8e7578.tar.gz
https://extdist.wmflabs.org/dist/extensions/OATHAuth-REL1_43-2cdbefb.tar.gz
  1. anyway, let's try it again, and hope we get all three before they push another release in the next ~1 week
  2. here's a new 3TOFU script
REMOTE_FILES="https://extdist.wmflabs.org/dist/extensions/ConfirmAccount-REL1_43-38c4602.tar.gz https://extdist.wmflabs.org/dist/extensions/DeleteBatch-REL1_43-b3b052b.tar.gz https://extdist.wmflabs.org/dist/extensions/OATHAuth-REL1_43-2cdbefb.tar.gz"

CURL="/usr/bin/curl --retry 5 --retry-all-errors"
PYTHON="/usr/bin/python3"

# in tails, we must torify
if [[ "`whoami`" == "amnesia" ]] ; then
	CURL="/usr/bin/torify ${CURL}"
	PYTHON="/usr/bin/torify ${PYTHON}"
fi

tmpDir=`mktemp -d`
pushd "${tmpDir}"

# first get some info about our internet connection
${CURL} -s https://ifconfig.co/country | head -n1
${CURL} -s https://check.torproject.org | grep Congratulations | head -n1

# and today's date
date -u +"%Y-%m-%d"

# get the file
for file in ${REMOTE_FILES}; do
	${CURL} --progress-bar -O ${file}
done

# checksum
date -u +"%Y-%m-%d"
du -sh *
sha256sum *
  1. And TOFU 1/3 (ISP, exit in Ecuador)
Ecuador
2026-04-01
######################################################################### 100.0%
######################################################################### 100.0%
######################################################################### 100.0%
2026-04-01
448K	ConfirmAccount-REL1_43-38c4602.tar.gz
124K	DeleteBatch-REL1_43-b3b052b.tar.gz
14M	OATHAuth-REL1_43-2cdbefb.tar.gz
95b2bc67977c22d069867a7225aa1a9720b7593ed5ab49aa27cc293f01b2e2bb  ConfirmAccount-REL1_43-38c4602.tar.gz
d1e7c01cf709f2b57137bb3d76f73b4e8fd36ce57c12b750b04fe20ffce9be61  DeleteBatch-REL1_43-b3b052b.tar.gz
f71115af96a1ed5297d8d56f56683635b7c9e0b8b32151b184feea1fbec3350a  OATHAuth-REL1_43-2cdbefb.tar.gz
user@disp7799:/tmp/tmp.oWTEqi2mpP$ 
  1. and all the files are >4K, so that's promising.
  2. TODO: finish 3TOFU, install & configure extensions
  3. ...
  4. I also edited some wiki articles, namely
    1. this Maltfield_Log and Maltfield_Log/2026
    2. the Main_Page
    3. the Eco-Libre:About page (from the footer)
    4. a Documentation page, which describes what the wiki is for and what it's not for
  5. TOOO: write Eco-Libre:Privacy_policy

2026-03-31

Hello World!

  1. I installed this wiki last week on 2026-03-27
  2. since then, I did some hardening and basic setup (skin, logos)
  3. today I continued through the process of configuring its built-in plugins
  4. I'm still in the process of a 3TOFU on the desired extensions.
  5. now I'm finally editing some pages
  6. TODO: download, activate, and configure additional extensions