i summon one kim

I occasionally want to run nested screen sessions and this configuration allows me to use the same control character for both the inner and outer sessions by switching between them. (more…)

After installing sudo 1.8.29 from pkgsrc (security/sudo) I started frequently seeing this warning message:

sudo: setrlimit(3): Invalid argument

It took a few rounds, but eventually I applied an acceptable patch for the pkgsrc-2019Q4 release. Later an upstream workaround was committed and included in the sudo 1.8.30 release. (more…)

The new requirements for trusted certificates on macOS Catalina and iOS 13 blocked me from accessing the web UI on Proxmox installations (NET::ERR_CERT_REVOKED). Fresh installations would work, as Proxmox has been updated to generate “better” certificates. Existing installations, unfortunately, are not automatically fixed on upgrading to Proxmox 6.

Certificate management on Proxmox is handled with pvenode(1) — except when it isn’t. There is no functionality there for regenerating the self-signed certificates. An older wiki page for HTTPS certificate configuration provided some useful hints: pvecm(1) has an updatecerts command. It won’t, however, regenerate existing (unexpired) certificates.

Against the warnings on the Certificate mangement page I thought I’d try removing the apparently relevant files manually:

cd /etc/pve
rm pve-root-ca.pem priv/pve-root-ca.key nodes/*/pve-ssl.{key,pem}

Then I regenerated the certificates and restarted pveproxy(8) on each node:

pvecm updatecerts --force
systemctl restart pveproxy

Refreshing the page in the browser restores access to the web UI.

I noticed that tcsh 6.22.02 has a broken configure script:

./configure: gl_HOST_CPU_C_ABI_32BIT: not found

This looked like an unexpanded m4 macro to me. I was unable to reproduce the error if I ran autoreconf under Debian buster, so I switched to a NetBSD host and tried there. Indeed, running autoreconf resulted in the same broken configure script.

Upon closer inspection, it turns out that devel/gettext-m4 had been updated to a new version in pkgsrc without noticing that generated configure scripts now throw an error. The cause was a missing file (host-cpu-c-abi.m4).

For some reason the package Makefile has a hardcoded list of files to install from gettext-tools/gnulib-m4 (as opposed to calling the install target via make). The reason is probably to avoid unnecessary or irrelevant files. However, this means that any relevant changes to gettext-tools/gnulib-m4/Makefile can easily go unnoticed.

I’ve added the missing file to the list, but I worry that this approach is prone to errors. Perhaps some easy check could be added and noted in the package Makefile to detect problems, e.g. generating a sample configure script before committing a version update.

By default many Linux network interface card drivers set their SMP affinity mask to either all zeroes or all ones (“ff” — the length of the mask depends on the number of CPUs on the system). The former results in all queues and interfaces running on CPU ID 0, which can become a performance bottleneck due to insufficient computing power. The latter results in all queues and interfaces being scheduled on multiple CPUs, which can become a performance bottleneck due to increased CPU memory cache misses. (more…)

Since switching to the iCloud Photo Library, the Photos app on my laptop has kept telling me that

• 1 Item on This Mac Only
• Unable to Upload 9 Items

To identify the oddball photos, I created the following smart folders respectively:

• [Photo] [is] [referenced]
• [Photo] [is] [unable to upload to iCloud Photo Library]

Referenced photos can be consolidated into the library and would then be uploaded to iCloud — mine was a duplicate, so I just deleted it. The photos that could not be uploaded were photos that had been deleted, but somehow a reference had been kept or imported.

References:

• Items on This Mac Only
• Photos for Mac says “Unable to upload 222 items”

If you have already upgraded to jessie and have systemd as init, you can switch back with these commands:

apt-get install -y sysvinit-core
reboot
apt-get purge -y systemd

Running with sysvinit works better on my servers, as daemons have a chance of doing their own graceful shutdown before the network is brought down.