Archive for category PC Tweakage

Imagemagick 6 vs. PDF

Come to find out Xubuntu 18.04 ratcheted the ImageMagick security settings up to a dangerous chattering whine:

convert p???.jpg "Machining D-bit Drills.pdf"
convert-im6.q16: not authorized `Machining D-bit Drills.pdf' @ error/constitute.c/WriteImage/1037.

Fortunately, someone who understands this stuff encountered the problem before I did and posted a great description of the solution.

To forestall link rot, the process looks like:

cd /etc/ImageMagick-6/
sudo cp policy.xml policy.xml.base
sudo nano policy.xml
… change one line …
 policy domain="coder" rights="read|write" pattern="PDF"

It is completely unclear to me whether ImageMagick (as of ImageMagick 6.9.7-4 Q16 x86_64 20170114 ) requires or merely tolerates the vertical bar in place of commas, nor whether it’s in my best interest to replace "coder" with "*".

In any event, I can once again stuff bitmap images into PDF files.



LinuxCNC 2.7 vs. Logitech Joggy Thing

The old Atom running LinuxCNC for the Sherline finally stopped booting, so I popped the Optiplex 760 off the stack and did a live-USB trial run. The latency / jitter worked out around 25 µs, slightly worse than before, but still Good Enough, and the StepConf utility coerced the motors into working OK.

What didn’t work was the old Eagle-to-HAL code defining the Logitch Gamepad as a Joggy Thing to allow smooth joystick jog control. Well, stuff changes over the course of eight years, but, in this case, the fix turned out to be a one-liner: the probe_parport module isn’t needed nowadays.

With that out of the way, it runs fine:

LinuxCNC - Sherline Mill - Logitech Gamepad

LinuxCNC – Sherline Mill – Logitech Gamepad

The INI and HAL files defining the Sherline configuration as a GitHub Gist:

, ,

1 Comment

Xubuntu Startup Delay vs. xsetwacom

Over the years, various xsetwacom incantations have confined the tablet stylus to the left-hand landscape monitor on my desk. Updating to Xubuntu 18.04 once again changed the monitors names (from HEAD-0 back to DP-1), but xsetwacom stopped working.

My script runs from Xubuntu’s “Application Autostart” list, so X is already running and xsetwacom should do the right thing. Alas, even with $XAUTHORITY and $DISPLAY set correctly (automagically by X), xsetwacom still didn’t corral the cursor.

Some rummaging around the Intertubes suggested a delay would allow X to get up to speed and, indeed, sleeping for two seconds solved the problem:

logger " - copying Xauthority values"
whoami > /tmp/who
cp /home/ed/.Xauthority /tmp/Xauthority.txt
cp $XAUTHORITY /tmp/xauth.cp
echo $DISPLAY > /tmp/DISPLAY.txt
# xsetwacom needs an additional delay after $XAUTHORITY and $DISPLAY become correct
logger " - waiting aimlessly"
sleep 2s
logger " - doing wacom setup"
xsetwacom --verbose set "Wacom Graphire3 6x8 Pen stylus" MapToOutput "DP-1"
xsetwacom --verbose set "Wacom Graphire3 6x8 Pen eraser" MapToOutput "DP-1"

Sheesh & similar remarks.

The complete Bash script as a GitHub Gist:

The cruft in there reminds me of previous fixes / workarounds / haxx, so it’s not entirely wasted space.

Leave a comment

Pi-Hole with DNS-over-HTTPS

With none other than Troy Hunt recommending Pi-Hole, I got a Round Tuit:

unzip -d /tmp
sudo dcfldd status=progress bs=1M of=/dev/sde if=/tmp/2018-06-27-raspbian-stretch-lite.img

Raspbian now arrives with ssh disabled, so the first boot requires a keyboard and display:

Pi-Hole first boot wiring

Pi-Hole first boot wiring

Then do some configuration required to get a fresh Raspberry Pi ready for remote access:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install screen iotop
sudo raspi-config   # enable ssh
ssh-keygen -t rsa
cd ~/.ssh
cp -a /my/public/key authorized_keys
chmod go-rwx authorized_keys
sudo nano /etc/ssh/sshd_config  # unusual port, no root login, etc
sudo service ssh restart

As the good folks at Pi-Hole say, “Piping to bash is controversial, as it prevents you from reading code that is about to run on your system.” I took a look, it’s beyond my comprehension, so just get it done:

curl -sSL | bash

Configure Pi-Hole:

  • Static IP:
  • DNS using, say, Cloudflare’s
  • DHCP turned off, which is the default

Configure the router’s DHCP to hand out the Pi-Hole’s IP, with, say, as a backup.

Boot a few random PCs and whatnot to verify it works as expected, which it did the second time around, thus this particular post.

Install the Cloudflare Argo Tunnel dæmon, approximately according to suggestions:

mkdir Downloads
cd Downloads/
tar zxvf cloudflared-stable-linux-arm.tgz
sudo mkdir /opt/cloudflare
sudo cp cloudflared /opt/cloudflare/

Start the daemon from within a screen session, also as suggested:

sudo /opt/cloudflare/cloudflared proxy-dns --port 54 --upstream --upstream
INFO[0000] Adding DNS upstream                           url=""
INFO[0000] Adding DNS upstream                           url=""
INFO[0000] Starting metrics server                       addr=""
INFO[0000] Starting DNS over HTTPS proxy server          addr="dns://localhost:54"

Contrary to the suggestions, you can configure Pi-Hole to use the DoH tunnel (or whatever it’s called) by tweaking its upstream DNS configuration:

Pi-Hole - Cloudflare DNS config

Pi-Hole – Cloudflare DNS config

Then set up systemd to start the daemon automagically:

sudo nano /etc/systemd/system/dnsproxy.service

Because I put the daemon in /opt/cloudflare, that file differs slightly from the suggestion:

Description=CloudFlare DNS over HTTPS Proxy

ExecStart=/opt/cloudflare/cloudflared proxy-dns --port 54 --upstream --upstream$

And then It Just Worked.

Controversies over the ethics of ad and tracker blocking will go nowhere here, as I’ve cleaned out enough Windows machines to have absolutely no sympathy with the unholy spawn of adtech (not just the company, which I didn’t know existed until just now, but, yeah, them too).



Wyze Cam vs. Xiamoi-Dafang Hacks

The Wyze Cam is a surprisingly inexpensive camera firmly lashed to the Wyze app, with no provision for ordinary IP camera streaming. It seems to be a generic camera with custom firmware and, unsurprisingly, one can commandeer the bootloader with different firmware from a MicroSD card, thereby adding missing functions and suppressing undesired actions.

Oddly, buying a genuine Wyze Cam directly from Wyze isn’t significantly more expensive than a generic from the usual eBay / Amazon sellers. Bonus: the legit camera arrives next week rather than in a month or two.

I found one of my few remaining 2 GB MicroSD cards, formatted it with a 512 MB (!) FAT32 partition (per the suggestions), set up the “custom firmware” bootloader, and installed it with no issues.

Installing the new firmware requires copying a directory tree, configuring the WiFi SSID and password in the usual wpa_supplicant, and rebooting. Works fine and, yeah, the camera now runs Linux.

I told the router to assign a known IP address to the camera’s MAC address, set up port forwarding for port 8554 to that IP address, put the camera against the storm window in the kitchen, and rebooted everything to get it working:

Wyze Cam in kitchen window

Wyze Cam in kitchen window

Unfortunately, while it works more-or-less well with browsers on the local network, it’s apparently inaccessible from outside. The router manages a DDNS name-to-IP mapping to make itself findable, the port is open, the forwarding seems correct, no image data arrives to browsers outside, and they eventually time out.

Changing to port 8080 doesn’t help, nor does using MJPEG instead of H264 encoding.

Even more unfortunately, the router doesn’t do hairpin connections (inside to outside to inside), so I can’t debug this mess from the Comfy Chair.

This is a placeholder for what I’ve done while I accumulate more knowledge …


Troubles in PC Land

So this happened:

Dell Optiplex - SSD failure

Dell Optiplex – SSD failure

As far as I can tell, the Crucial M5500 SSD in that PC (an off-lease Dell Optiplex 760) stopped being a SATA hard drive, although it seems to work OK when jammed in a USB adapter.

So I picked up a new-to-me Optiplex 9020 with Windows 8.1 on an SSD, shrank the partition, tried to install Xubuntu 18.04, fat-fingered the UEFI password dance, reinstalled Windows from the SSD’s recovery partition, and got this display after a while (clicky for more dots):

Dell Optiplex - recovery disk stall

Dell Optiplex – recovery disk stall

After letting it stew in its own juices during supper, I forced it off (pushed the power button until it died), restarted, got through the UEFI dance, and it now seems All Good. I made recovery DVDs (remember DVDs?), both before and after the fumbled Xubuntu installation, but didn’t need them.

I expect we’ll never boot Windows 8.1 again, but it’s there Just In Case.



LibreOffice 5.3+ vs. Adobe Type 1 Fonts

LibreOffice from 5.3 onward (Xubuntu 18.04 uses LO 6.0) no longer supports Adobe Type 1 fonts, which comes as a surprise to those of us who actually bought fonts, back in the day, and have been using them ever since. Apparently, Windows dropped Type 1 font support some time ago.

Based on some hints, I set up the Adobe Font Development Kit for OpenType. It’s a Python thing, preferably running in a virtual environment to avoid screwing up the rest of one’s system with bizarre dependencies. It seems one (“I”) must not update pip using pip after installing python-pip using apt-get; recovering from that mess was good for another hour of flailing.

The default AFDKO installation spat out an error message about ufolib (I am not making this up) being at 2.1.1, instead of the required 2.3.1. In for a penny, in for a pound, I updated ADFKO with the “prerelease” option:

pip install -U afdko --pre

Which fetched ufolib 2.3.1, apparently from wherever Python keeps its prerelease stash. I have NFC what’s going on with any of this.

An Adobe blog post on the AFDKO tx tool suggested it can convert Type 1 fonts to CFF (a.k.a. Adobe Type 2) fonts and some poking around suggested CFF also figures in OTF fonts.

tx -cff -n -N -A awb_____.pfb
--- Filename: awb_____.pfb
--- FontName: ACaslon-Bold
tx: --- awb_____.pfb
tx: (cfw) unhinted
tx: (cfw) unhinted
tx: (cfw) unhinted
tx: (cfw) unhinted
tx: (cfw) unhinted
tx: (cfw) There are 222 additional reports of 'unhinted'.

The -A option replaces the bizarre Adobe 8.3 file names with actual font information:

awrg____.pfb ⇒ ACaslon-Bold.cff
awbi____.pfb ⇒ ACaslon-BoldItalic.cff
awi_____.pfb ⇒ ACaslon-Italic.cff
awrg____.pfb ⇒ ACaslon-Regular.cff
awsb____.pfb ⇒ ACaslon-Semibold.cff
awsbi___.pfb ⇒ ACaslon-SemiboldItalic.cff

Regrettably, CFF files don’t actually work as fonts, at least as far as LibreOffice 6.0 (or whatever it uses as a font engine) is concerned.

Although it’s possible to convert fonts locally with fontforge, doing it one-by-one is tedious and the learning curve for its Python scripting feature seems rather steep. I fired the most vital fonts at Convertio, an online converter running fontforge in the background, got a matching pile of OTF fonts, and installed them in /usr/share/fonts/custom/type1 to indicate their heritage.

Whereupon LO rammed into a problem I’d had before. The solution this time required sorting the various Caslon and American Typewriter fonts into different “font families” and forcing the TTF names to match their new families. The difference between Medium and Regular seems to have Gone Away.

I should just use Comic Sans and be done with it …