Archive for category PC Tweakage
Pi-Hole with DNS-over-HTTPS
Posted by Ed in Home Ec, PC Tweakage, Software on 2018-10-02
With none other than Troy Hunt recommending Pi-Hole, I got a Round Tuit:
unzip 2018-06-27-raspbian-stretch-lite.zip -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
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 cd 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 https://install.pi-hole.net | bash
Configure Pi-Hole:
- Static IP: 192.168.1.2/24
- DNS using, say, Cloudflare’s 1.1.1.1
- DHCP turned off, which is the default
Configure the router’s DHCP to hand out the Pi-Hole’s IP, with, say, 9.9.9.9 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/ wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz 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 https://1.1.1.1/.well-known/dns-query --upstream https://1.0.0.1/.well-known/dns-query INFO[0000] Adding DNS upstream url="https://1.1.1.1/.well-known/dns-query" INFO[0000] Adding DNS upstream url="https://1.0.0.1/.well-known/dns-query" INFO[0000] Starting metrics server addr="127.0.0.1:37777" 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
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:
[Unit] Description=CloudFlare DNS over HTTPS Proxy Wants=network-online.target After=network.target network-online.target [Service] ExecStart=/opt/cloudflare/cloudflared proxy-dns --port 54 --upstream https://1.1.1.1/.well-known/dns-query --upstream https://1.0.0.1/.well-$ Restart=on-abort [Install] WantedBy=multi-user.target
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
Posted by Ed in Home Ec, PC Tweakage, Software on 2018-09-27
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
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
Posted by Ed in PC Tweakage, Software on 2018-09-21
So this happened:
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
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
Posted by Ed in PC Tweakage, Software on 2018-09-13
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 …
SANE Scanner vs. Xubuntu 18.04
Posted by Ed in PC Tweakage on 2018-09-12
I recently bumped the desktop PC with the scanner from an old Mint to Xubuntu 18.04, which killed a day with all the system and UI tweakage.
The old guides for setting up a networked SANE scanner became inoperative with systemd ruling the configurations, so, after some flailing around, I found a newer guide referencing a guide for USB scanners and pointing to a deeper guide for network sharing in the age of systemd.
The USB guide points out the existence of Access Control Lists for the various device files, which I didn’t know was a thing. AFAICT, you must still be in the scanner group for remote access to happen.
I lost track of the changes during all the flailing around, but it definitely didn’t Just Work.
I’m sure all this will change before I must do it again.
Amazon Basics AA Cells: Capacity
Posted by Ed in Electronics Workbench, PC Tweakage on 2018-07-26
Being that sort of bear, I (sometimes) note the date on cells when I change them, as with this notation on the AA alkaline cells in the Logitech trackball:
Amazon Basics AA cell – mouse runtime
These Amazon Basics AA cells lasted almost exactly two years, compared with 15 and 20 months from the previous two pairs of Duracell AAs. A few months one way or the other probably don’t mean much, but the Amazon cells aren’t complete duds.
The new Amazon Basics cells have a gray paint job, so they’ve either changed suppliers or branding.
Toshiba 3 TB Drive Format & Speed
Posted by Ed in PC Tweakage, Photography & Images on 2018-07-02
A new Toshiba Canvio Basics 3 TB drive has two partitions:
sudo fdisk -l /dev/sdb Disk /dev/sdb: 2.7 TiB, 3000592979968 bytes, 5860533164 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 575F7910-3F93-4FC5-B50F-7D1F05810EE6 Device Start End Sectors Size Type /dev/sdb1 34 262177 262144 128M Microsoft reserved /dev/sdb2 264192 5860532223 5860268032 2.7T Microsoft basic data Partition 1 does not start on physical sector boundary.
The “Microsoft reserved” partition is new to me. It’s apparently not a real partition, but a dumping ground for Windows disk management information.
The drive is a classic Black Box:
Toshiba 3 TB USB drive
It comes with no specs, other than the tediously qualified “3 TB”, and the Toshiba web page shows only a 5 Gb/s = 625 MB/s “Max. transfer rate”.
A quick test slurping data from the Sandisk video-rated MicroSD card extracted from the Fly6 camera shows it can write data at a sustained 21 MB/s:
time rsync -ahu --progress /mnt/Fly6/ /mnt/part/test/
sending incremental file list
./
CONFIG.TXT
33 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=29/31)
FLY6.VER
14 100% 13.67kB/s 0:00:00 (xfr#2, to-chk=28/31)
DCIM/
DCIM/15880604/
DCIM/15980609/
DCIM/15980609/09490001.AVI
499.32M 100% 21.61MB/s 0:00:22 (xfr#3, to-chk=21/31)
DCIM/15980609/09590002.AVI
497.75M 100% 20.95MB/s 0:00:22 (xfr#4, to-chk=20/31)
DCIM/15980609/10090003.AVI
499.06M 100% 21.31MB/s 0:00:22 (xfr#5, to-chk=19/31)
DCIM/15980609/10190004.AVI
278.10M 100% 21.48MB/s 0:00:12 (xfr#6, to-chk=18/31)
... snippage ...
real 6m26.272s
user 0m55.900s
sys 0m25.496s
That’s with the card jammed into an Anker USB 3.0 adapter and both devices plugged into the two USB 3.0 “Super Speed” ports in the front of my desktop box. Plugging them both into the adjacent USB 2.0 ports drops the data rate to 18 MB/s.
The Sandisk card claims read-write speeds of “up to” 20 MB/s, so it’s the limiting factor.
Getting reliable performance numbers is surprisingly difficult:
dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random.bin 4177526784 bytes (4.2 GB, 3.9 GiB) copied, 214.064 s, 19.5 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 214.922 s, 19.5 MB/s dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random2.bin 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s
Obviously, prying bits out of the random number generator limits the overall write speed.
Zeros, however, are cheap and readily available:
dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null.bin 4169138176 bytes (4.2 GB, 3.9 GiB) copied, 23.0091 s, 181 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.1775 s, 181 MB/s dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null2.bin 4093640704 bytes (4.1 GB, 3.8 GiB) copied, 25.031 s, 164 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 25.7781 s, 163 MB/s
But the caches take a while to drain, even after the command returns:
time ( dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null3.bin ; sync ) 4118806528 bytes (4.1 GB, 3.8 GiB) copied, 23.0004 s, 179 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.5305 s, 178 MB/s real 0m35.887s user 0m0.008s sys 0m4.824s
Dividing 4 GB / 35.9 s says the mechanical write speed is close to 110 MB/s.
Reading proceeds a bit faster, while also running up against the effect of the many caches between the spinning platter and the screen:
time ( cp /mnt/part/random.bin /dev/null ) real 0m36.565s user 0m0.048s sys 0m1.712s time ( cp /mnt/part/random.bin /dev/null ) real 0m29.157s user 0m0.036s sys 0m1.800s time ( cp /mnt/part/random.bin /dev/null ) real 0m10.265s user 0m0.028s sys 0m1.040s time ( cp /mnt/part/random.bin /dev/null ) real 0m0.608s user 0m0.004s sys 0m0.600s time ( cp /mnt/part/random.bin /dev/null ) real 0m0.590s user 0m0.008s sys 0m0.580s time ( cp /mnt/part/random2.bin /dev/null ) real 0m31.035s user 0m0.056s sys 0m1.816s time ( cp /mnt/part/random2.bin /dev/null ) real 0m31.024s user 0m0.052s sys 0m1.860s
Unsurprisingly, copying a brace of 4 GB files in parallel takes twice as long as each cold-buffer read, so disk’s raw read speed seems to be around 130 MB/s.
The drive’s write speed won’t be the limiting factor while saving camera video data!
-
You are currently browsing the archives for the PC Tweakage category.
Blowback