I hate upgrades, but python3 on my debian stretch box doesn't grok
f-strings,
because its python3 is python3.5; fstrings were added in python3.6.
It’s been a couple years since I upgraded to stretch (debian9), and
security updates have just been discontinued, so I thought, why not
skip buster (debian10) and just
upgrade to debian11 (bullseye)? Then maybe I could wait
four years rather than
two before having to do it again.
Of course I didn't see any instructions for a 2-release upgrade,
so the first thing was to upgrade stretch to buster. I basically followed
the instructions in
this article. As root:
- change “stretch” to “buster” in /etc/apt/sources.list
Casting all caution to the wind, I skipped the part about making a backup
- apt-get update; apt-get upgrade; apt-get dist-upgrade
- reboot
That’s all I did. There was one
surprise: thunderbird complained about not being able to connect to “mini1”
but I had no idea why. I did, however, try to ssh there from my now-buster desktop;
passwordless ssh failed. “
ssh -v” showed me that I had the wrong kind of keys now,
so I regenerated keys on mini1 (a mac mini),
added the the contents of .ssh/id_mini1.pub mini1’s .ssh/authorized_keys, and copied the private
key into .ssh/id_mini1. Things started looking better. But thunderbird
still said it couldn't connect to mini1. Why was that? The
server settings said it was connecting to 127.0.0.1:143; was I running
dovecot locally? I had to be, right? Yes, according to
/etc/dovecot/dovecot.conf:
26 # A comma separated list of IPs or hosts where to listen in for connections.
27 # "*" listens in all IPv4 interfaces, "::" listens in all IPv6 interfaces.
28 # If you want to specify non-default ports or anything more complex,
29 # edit conf.d/master.conf.
30 #listen = *, ::
31 listen = 127.0.0.2
So when I tried "sudo dovecot", it said the ssl key couldn’t be found, and even gave me a pathname.
So I commented it out in /etc/dovecot/conf.d/10-ssl.conf:
1 ##
2 ## SSL settings
3 ##
4
5 # SSL/TLS support: yes, no, required.
6 ssl = no ←was “yes”
7
8 # PEM encoded X.509 SSL/TLS certificate and private key. They're opened before
9 # dropping root privileges, so keep the key file unreadable by anyone but
10 # root. Included doc/mkcert.sh can be used to easily generate self-signed
11 # certificate, just make sure to update the domains in dovecot-openssl.cnf
12 ssl_cert = </etc/dovecot/private/dovecot.pem
13 #ssl_key = </etc/dovecot/private/dovecot.key ←commented out
I also decided that we don’t need SSL, since hey, 127.0.0.2.
I think I’ll have to do something about the scanner, but otherwise i believe phase I (Stretch → Buster) was pretty easy.
Phase II: Buster → Bullseye
The first part was straightforward but took ... a couple hours? As above, all these steps were done as root:
- change /etc/apt/sources.list to refer to Bullseye rather than Buster
- apt-get update; apt-get ugrade; apt-get dist-upgrade
- reboot
And then…
“…something about the scanner” ⇐ THIS
So xsane couldn't find the scanner. I got some advice to “
sudo scanimage -L” which found
only another device (our renter's all-in-one).
A web search on “brother scanners linux” (no quotes) led me to
Install the scanner driver (deb) - Linux - BrotherUSA, where I learned what to do, again as root:
collin@p64:~$ brsaneconfig4 -q
← nothing appeared here at all!
collin@p64:~$ sudo brsaneconfig4 -a name=mfc9340 model=MFC-9340CDW ip=192.168.1.40
collin@p64:~$ brsaneconfig4 -q
* *MFC-9340CDW [ 192.168.1.40] mfc9340 ← Now that’s more like it!
collin@p64:~$ sudo scanimage -L
device `brother4:net1;dev0' is a Brother mfc9340 MFC-9340CDW
device `escl:https://192.168.0.235:443' is a HP ENVY 6400 series [BA2627] SSL flatbed scanner
collin@p64:~$
And with that, the scanner works. Mail works. Browsers (both firefox and chrome) work. Maybe something else won’t, but that's all for today.
July 29 update: auto-sleep, crashplan
A new-ish feature in Bullseye (it may have come in with Buster?) is that the
box will sleep if I walk away for 20 minutes or so. This is fine, except
when I'm logged in over VPN and I'm using vmware horizon (yes i have to use that for work).
I need to disable it when I'm at work, so I just leave the Settings app up, with Power settings
selected. Then it's front and center and it's obvious to me that auto-sleep is either
on or off. Usually I re-enable it when I'm done with work for the day.
I got email yesterday or so, saying that my backups haven't happened since
the OS upgrade. My first thought was, oh, it's because of being asleep.
But then I turned off auto-sleep and tried logging in to the code42 app... no joy.
After thrashing for a while, I went to the code42.com support site, where I
couldn't login. Oh, I had forgotten that I'd already added google authenticator
to firefox! I used it to get my magic rotating number and I was in.
I saw the advice to reinstall the app. OK, fine; I downloaded the package,
did what came naturally, and said: sudo /usr/local/crashplan/service.sh start
Which didn't work. I looked at /usr/local/crashplan/log/service.log.0 and...
something about missing libuaw.so; a web search led me to
this post on reddit
with the answer: zcat the "CrashPlanSmb_10.0.0.cpi" file (it's in the downloaded tarball),
find libuaw.so in the appropriate subdirectory of nlib/ (they didn't have "debian11" but
the Reddit-or said ubuntu20, which thankfully worked) and copy it into /usr/local/crashplan/nlib;
shazzam! up and running.
August 20 update: convert(1) issue solved; crashplan, not so much
I wanted to convert
a ".png" file to PDF, as I have done many times before, but now I get:
convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.
How annoying! A web search got me to
this stackoverflow post; I followed its advice, but kept the old
/etc/ImageMagick-6/policy.xml as
/etc/ImageMagick-6/policy.xml-dist; here's the diff:
$ diff -u /etc/ImageMagick-6/policy.xml{-dist,}
--- /etc/ImageMagick-6/policy.xml-dist 2021-04-20 07:37:59.000000000 -0700
+++ /etc/ImageMagick-6/policy.xml 2022-08-20 20:19:06.962756505 -0700
@@ -90,10 +90,12 @@
<!-- in order to avoid to get image with password text -->
<policy domain="path" rights="none" pattern="@*"/>
<!-- disable ghostscript format types -->
- <policy domain="coder" rights="none" pattern="PS" />
+ <!-- -->
+ <policy domain="coder" rights="read|write" pattern="PS" />
<policy domain="coder" rights="none" pattern="PS2" />
<policy domain="coder" rights="none" pattern="PS3" />
<policy domain="coder" rights="none" pattern="EPS" />
- <policy domain="coder" rights="none" pattern="PDF" />
+ <!-- -->
+ <policy domain="coder" rights="read|write" pattern="PDF" />
<policy domain="coder" rights="none" pattern="XPS" />
</policymap>
And now,
convert(1) can do everything I was accustomed to using it for.
Crashplan, though… I thought (from a few weeks back) that the service started so everything was good, but not so much!
/usr/local/crashplan/log/engine_output.log ends like this:
Java virtual machine created.
Starting service.
[08.20.22 10:24:56.599 INFO main com.code42.utils.ClassFinder] Loaded classpaths in 1960 ms
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fc570a458a7, pid=326423, tid=326535
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.12+7 (11.0.12+7) (build 11.0.12+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (11.0.12+7, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C [libuaw.so+0x1c8a7] std::filesystem::path::~path()+0x7
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /usr/local/crashplan/hs_err_pid326423.log
[thread 326523 also had an error]
#
# If you would like to submit a bug report, please visit:
# https://github.com/adoptium/adoptium-support/issues
#
WHOA, did you see that
libuaw.so part up there?
Do I maybe have a bad
libuaw.so?
It's late now, though, so maybe in another day or two I'll…
September 24 update: crashplan solved!
OK, so what happened last month was: I did more searching and read another reddit post
which said that in 2019 (!) there was no excuse not to run apps in containers.
Good point! But I didn't want to do that without learning more about containers.
I mean, I can spell "runc exec -it <CONTAINERNAME> bash"
(wait, did I get that right?) but beyond that…
I ordered and waited for my own personal copy of Docker: Up & Running 2/e
then procrastinated… today I decided, better get to it. Now, where was that
reddit post that pointed me at the container to…? Huh, couldn’t find it.
Instead I re-found the reddit article linked above, but this time I noticed
this comment:
Thanks a lot! Worked on Debian 10 with the ubuntu18 file and on Debian 11 with the ubuntu20 file.
WHOA; I’ve got debian11; which one did I install last month (which crashed)?
Based on this output
$ ls -o /tmp/code42-install/nlib/*/libuaw.so
-rw-rw-r-- 1 collin 486008 Aug 21 08:25 /tmp/code42-install/nlib/rhel7/libuaw.so
-rw-rw-r-- 1 collin 243440 Aug 21 08:25 /tmp/code42-install/nlib/rhel8/libuaw.so
-rw-rw-r-- 1 collin 232944 Aug 21 08:25 /tmp/code42-install/nlib/ubuntu18/libuaw.so
-rw-rw-r-- 1 collin 52456 Aug 21 08:25 /tmp/code42-install/nlib/ubuntu20/libuaw.so
$
I evidently installed the rhel7 one. D’oh! Replacing it by the ubuntu20 one
and crashplan is running, without having to do the container thing.
PS: the container thing is https://github.com/jlesage/docker-crashplan
