Table of Contents
Welcome to fiwswe's BLOG
Currently there are 30 entries in this BLOG.
DokuWiki 2026-07-14c "Mort" has been released
The Hotfix release 2026-07-14c "Mort" is now available.
To find out what's new, see the Changelog. But in summary a security issue was fixed.
Note: Some plugins may need updates, as there is a side effect to this fix. (E.g. Bureaucracy Plugin #359, PR #360.) This also discussed in several threads in the DokuWiki User Forum,
See also:
DokuWiki 2026-07-14b "Mort" has been released
The Hotfix release 2026-07-14b "Mort" is now available.
To find out what's new, see the Changelog. But in summary a security issue was fixed along with some other minor fixes.
See also:
DokuWiki 2026-07-14a "Mort" has been released
The Hotfix release 2026-07-14a "Mort" is now available.
To find out what's new, see the Changelog. But in summary a few (long standing) security issues were fixed along with other fixes.
DokuWiki 2026-07-14 "Mort" has been released
It's been a while but this is a welcome update (Changelog, Download). There are only some minor glitches so far.
-
Apparently the Move Plugin has some serious issues!
-
For a (temporary) fix, see: compatibility with next DokuWiki release #313 (PR #319) Update: The fix is included in version 2026-06-16 of the plugin (confusingly released on July 15, 2026). So make sure to update before using it.
The Extended List Syntax Plugin has some issues specific to "Mort" as well as a number of previously existing issues. I have opened "Mort" fixes and more (PR #17) to address these. And I am manually patching my wikis with these changes as an interim solution.An issue in the Extension Manager has been fixed after the release of "Mort": extension: don't crash on malformed conflict/dependency ids.The charpicker Plugin has some display glitches in "Mort" and also with the sprintDoc Template. A temporary fix is to include this inconf/userstyle.css:/* Fixes for the charpicker Plugin */ /* See: https://github.com/turnermm/charpicker/issues/16 */ .tpl_sprintdoc #dokuwiki__content { overflow-y: visible; overflow-x: clip; } .page div.toolbar div.picker { z-index: 1; } /* End fixes. */
Two things I recommend after updating:
-
Delete the cache immediately after upgrading the wiki using
rm -rf data/cache/[0-9a-f]. A stale cache can cause very weird rendering issues. -
Rebuild the search index. I prefer to use the Searchindex Manager plugin for that.
-
Doing it on the command line is possible, but in a large wiki, steps may need to be taken to avoid running into the PHP maximum execution time limit (default: 30s). Run
php bin/indexer.php -cas the same user the webserver is using. Add-d max_execution_time=1200or similar if the time limit is too short.
-
Upcoming DokuWiki Release "Mort"
A new release of DokuWiki is making progress. Its release name will be Mort (which follows Librarian, released 2025.05.14).
The major new features are:
-
Optional Markdown1) (actually GFM with minor deviations) support.
-
Note that this support still has some limitations, both in the supported syntax and for things like missing editor toolbar support.
-
I haven't explored much yet, but at least some settings seem to allow both DokuWiki syntax and Markdown to be used, even on the same page.
Rewritten (improved) search.And more …The minimum PHP version is now PHP 8.2, which corresponds to the oldest version still under some sort of support at this time.
-
DokuWiki — Dealing with very large pages
On one of my wikis I have a complex page of about 575 KB source text size. After any modifications it runs into the default maximum execution time for PHP of 30s and only an error message is displayed.
As we can't make DokuWiki any faster, and the hardware needs to stay the same as well, the only alternative is to increase the time limit.
The PHP maximum execution time is set via the max_execution_time INI setting. It can also be adjusted at runtime using the set_time_limit() function.
Altering the value of max_execution_time works, but it affects more than just the DokuWiki instance. So this is not ideal.
The best solution is to use set_time_limit() during DokuWiki startup to set a higher time limit. This is actually fairly easy to accomplish: Code added in the file
DOKU_BASE/conf/local.protected.phpis executed early during DokuWiki startup. So creating this file if necessary and adding e.g.set_time_limit(90);
will solve the problem.
The complete file would look like this (if no other code is needed at startup):
- local.protected.php
<?php set_time_limit(90); ?>
An additional advantage of using set_time_limit() instead of adjusting max_execution_time is that the file
…/conf/local.protected.phpwould be copied along with the rest of the DokuWiki instance to backup sites, thus ensuring that the adjusted timeout is applied there as well without needing to fiddle with global PHP settings on those sites.Note: The new time limit should be chosen large enough that it works for the DokuWiki instance as well as any backup/mirror sites. The backup/mirror sites might use different hardware, thus exhibiting different performance compared to the main site. The requirements of the slowest site should be used to determine an appropriate value.
How to bypass greylisting for sender addresses with Postgrey & Postfix
Greylisting is an effective way to reduce the amount of SPAM sent by non-standard sources, such as scripts. I relies on the fact that a real SMTP sender will respond to a temporary rejection with a later retry.
Postgrey is service that implements greylisting. It is easily integrated into Postfix confgurations.
To this end Postgrey will build triples of
CLIENT The source IP of the sending server SENDER The sender's email address RECIPIENT The recipient's email address If a triple was not previously seen, the mail is temporarily rejected. When the sending server retries a delivery after a configurable minimum delay (default 300s) the mail is accepted and the triple is marked as a valid combination, so that the next email with the same triple will be accepted without any delays. After a certain time (default 35 days) unused triples will expire.
Postgrey allows for exceptions by specifying allowed sending servers and allowed recipients.
It does not allow exceptions for the sender's email address though. Some services use multiple sending servers, so the retry might come from a different server. This then does not match the previous triple and results in another temporary rejection. These cases can only be handled by defining exceptions for the sender's email address, which Postgrey does not implement. See Enhancement Request: Sender Whitelist (#56) which is unlikely to be implemented.
One solution would be to filter by sender address before passing the email to Postgrey.
A typical Postfix configuration using Postgrey will contain something like the following in master.cf:
smtp inet n - y - - smtpd -o { smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service inet:127.0.0.1:10023 } ...Here the check_policy_service directive passes the message to the Postgrey service listening on 127.0.0.1:10023, which then decides on temporary rejection or immediate acceptance.
Since the smtpd_recipient_restrictions options are evaluated in order until the first match is found, inserting a filter right before the check_policy_service directive will do the trick. This filter could look like this:
check_sender_access hash:/etc/postfix/nogreylist-senders, which requires an access table similar to:- /etc/postfix/nogreylist-senders
# The following sender email address patterns will be used to exclude # emails from these senders from being subjected to greylisting by # postgrey. # # Beware that email sender addresses are easily forged. So use this # judiciously. # # NOTE 1: This affects all recipient addresses on this server, so # don't be too permissive. # NOTE 2: Please only use the ACCEPT ACTION OK because any other action # is not appropriate semantically in this file. # https://www.postfix.org/access.5.html#accept_actions # REJECT actions are technically possible but their use should # be separated from the goal of bypassing greylisting, thus # inappropriate here. # # For syntax see: # https://www.postfix.org/access.5.html # # Always run `postmap /etc/postfix/nogreylist-senders` after making changes. # Allow emails from senders in the domain example.com to bypass greylisting example.com OK # # EOF. #
Thus the entry in master.cf will now look like this:
smtp inet n - y - - smtpd -o { smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_sender_access hash:/etc/postfix/nogreylist-senders check_policy_service inet:127.0.0.1:10023 } ...This method has been successfully tested on OpenBSD 7.9 running Postfix 3.11.3 and Postgrey 1.37.
OpenBSD 7.9 has been released
Not surprising for those who follow the OpenBSD mailing lists, and somewhat late but still within the normal release schedule, on 2026.05.19 OpenBSD 7.9 was released. This is the 60th release of OpenBSD.
As usual the Upgrade instructions work fine and the first impression is good.
Apple's Secret Security Update
Apple has released an urgent security update for iOS 26.3.1 and other OSes. See About the security content of Background Security Improvements for iOS 26.3.1, iPadOS 26.3.1, macOS 26.3.1, and macOS 26.3.2.
Unfortunately it does not show up in Settings → General → Software Update! And I saw no notification about it either.
Users apparently need to find the Settings → Privacy & Security → Background Security Improvements setting and manually install the update (requiring a reboot in this case). And note that the Automatically Install setting is turned ON on my device. Apparently that doesn't do anything though. (The update was released on March 17, 2026 and I checked on March 20. So for 3 days the automatic update did not happen.)
So I predict that only a few users will actually find and install the important security fix.
Nice going Apple!
Update: On one Apple iPad running iPadOS 26.3.1 the security update appears to have installed automatically. So that seems to sometimes work? Still, from a user interface perspective it makes no sense to split of the UI for installing background security updates from the normal Software Update UI.
Update #2: On March 24, 2026, only a week later, iOS/iPadOS/macOS 26.4 where released. Thus for this specific case the issue is effectively moot. However the point of the security update was to get a fix for an issue out to the devices as soon as possible. And hiding the mechanism for installing such fixes is counterproductive.
OpenBSD — How upgrade with limited free space on /usr
On small systems, or on VMs with small virtual boot disks, the automatic partitioning will sometimes lead to a
/usrpartition that is too limited in size. During normal operations this will probably not hurt anything but sysupgrade(8) may complain that there is not enough free space on/usr.1)Markdown was originally invented by John Gruber and Aaron Swartz in 2004 and debuted as a Perl script to convert text to HTML. It has since become a de facto standard for many systems, including GitHub, which enhanced the specification.weblog.txt · Last modified: by fiwswe
-