Greg's diary, recent entries

Friday, 10 April 2026	Dereel
		Top of page
		next day
		last day

Fixing TUHS

Topic: technology, opinion

Link here

Spent some time today, not overly long, in looking at tuhs.org's mailman issues. I've never seen it before, but in principle the web interface (intuitively called “Postorius”, which I thought was a German politician) doesn't look too bad. With the marginal help from Google Gemini found a tab “Alter Messages”, which only accepts specific MIME types. But it included the types specified in my messages, text/plain and application/pgp-signature, presumably after Warren added them. So what could it be? Is there something hidden in my messages?

Yes! Looking at the message as stored on /var/mail/groggyhimself, the whole thing is enclosed in a multipart/signed which is invisible to the user. It did accept multipart, so it wasn't clear whether adding multipart/signed would help. But it did. And promptly G. Branden Robinson piped up: he, too, had had the same problem, and possibly others who hadn't noticed it. As I wrote in my test message,

I'm not overly secure, but cryptographic signatures have so far been only refused by systems in the Microsoft space.

And there was general agreement.

More git fun

Topic: technology, opinion

Link here

After one success, how about another try to commit the file that failed so dramatically on Wedensday. I had written to Philip Paeps to ask him to check my access.

Fool! I had tried to ~~commit~~push to a read-only repository! I should push to gitrepo.freebsd.org, not git.freebsd.org. Read the git primer.

Well, yes, that's what I had read. It states:

Then you should have the official mirrors as your remote:

% git remote -v freebsd https://git.freebsd.org/${repo}.git (fetch) freebsd https://git.freebsd.org/${repo}.git (push)

Ah, but ignore that. Some way further down it says:

% git remote set-url --push freebsd git@gitrepo.freebsd.org:\${repo}.git

Now isn't that misleading? But there's more in there, including what to do when—once again—I got the message

=== grog@hydra (/dev/pts/37) /src/FreeBSD/git/main/usr.bin/du 48 -> git push To gitrepo.freebsd.org:src.git ! [rejected] main -> main (fetch first) error: failed to push some refs to 'gitrepo.freebsd.org:src.git' hint: Updates were rejected because the remote contains work that you do not hint: have locally. This is usually caused by another repository pushing to hint: the same ref. If you want to integrate the remote changes, use hint: 'git pull' before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

So far it seems that the first thing is to ignore the illegible text, but I need to read the whole document first. It seems that it is in great need of updating; apart from the misleading text, some of the information is over 10 years out of date. But at least I can see a way forward.

One thing still doesn't work, and nobody can tell me what to do: HOW can I get rid of this half-coloured output from git, like in the example above?

Another Hokkien Mee recipe

Topic: food and drink

Link here

I eat KL Hokkien Mee relatively frequently. I also have a recipe for Singapore Hokkien Mee, but only pre-prepared sauce or my own experiments. Today I found this recipe, which, like others, stresses the importance of using home-made prawn head broth. It also emphasizes that the noodles should be half Hokkien noodles and half rice vermicelli, something that I think also applies to KL Hokkien Mee, and it mentions two further varieties, both from Penang: Hokkien Char and Penang Hokkien Mee. Time to consolidate.

Saturday, 11 April 2026	Dereel	Images for 11 April 2026
		Top of page
		previous day

Good deeds don't go unpunished

Topic: technology, opinion

Link here

Warren Toomey was very happy about yesterday's success in persuading mailman to deliver signed email messages. So he added me to the admin list! Now as long as nobody tries to claim that I'm a mailman expert.

That required getting more access to minnie.tuhs.org. Allow it to contact me? In principle I had (somewhat unorthodox) shell access, but it can't harm to add it explicitly:

ipfw add 111 allow ip from minnie.tuhs.org to any

The result? The existing shell connection to minnie was aborted. Why? That doesn't make any sense at all. I had to remove the rule, after which things worked.

The incredible dying named

Topic: technology, opinion

Link here

My hourly start of named on lax.lemis.com seems to have leveled out. Until recently. Today I had no fewer than 12 restarts—every other hour. Presumably that means that there was no named running for 6 hours! A good thing I have a backup on fra, but this is unacceptable.

More garden work

Topic: gardening

Link here

Jesse Walsh along today for what proved 5 hours' work in the garden. It certainly makes a difference.

While he was there, he changed the light globe that I had noted last month. Surprise, surprise! It wasn't the remaining one that still worked: it was the other one.

Blocking more bots

Topic: technology, opinion

Link here

My web site load is rising again, due to many anonymous bots. How can I protect myself?

=== root@lax (/dev/pts/2) /var/log/www 117 -> tail -1000 /var/log/www/www.lemis.com.log | sed 's: .*::' | uniq -c | sort -n ... 18 57.141.2.8 19 52.167.144.171 19 57.141.2.55 26 40.77.167.143 126 57.141.2.45

OK, 57.141.2.45 only accounts for 12.6% of the load, but there are others:

=== root@lax (/dev/pts/2) /var/log/www 117 -> grep 57.141.2 | wc -l 963

And it's too polite to have reverse lookup. Goodbye 57.141.2.45:

=== root@lax (/dev/pts/2) /var/log/www 119 -> ipfw add 113 deny ip from 57.141.2/24 to any 00113 deny ip from 57.141.0.0/24 to any

Huh? I said 57.141.2, not 57.141.0. It seems that I needed to specify the entire address:

=== root@lax (/dev/pts/2) /var/log/www 127 -> ipfw add 113 deny ip from 57.141.2.0/24 to any 00113 deny ip from 57.141.2.0/24 to any

And how about that, the load dropped significantly:

=== root@lax (/dev/pts/2) /var/log/www 133 -> ipfw show | grep ^00113; sleep 10; ipfw show | grep ^00113 00113 1128 65000 deny ip from 57.141.2.0/24 to any === root@lax (/dev/pts/2) /var/log/www 134 -> ipfw show | grep ^00113; sleep 10; ipfw show | grep ^00113 00113 1168 67400 deny ip from 57.141.2.0/24 to any

But there must be a better way. I had thought of blocking requesters without reverse lookup, but that probably excludes many valid requests. I really should rework my photo display functions to use POST instead of GET.