RBL claims in the bounce notices below motivated me to check the BALUG
IP (96.86.170.229) and domain on DNSBLs. There are some reputation
problems for the IP address...
$ dig -t a +short 229.170.86.96.dnsbl-1.uceprotect.net
127.0.0.2
$ dig -t a +short 229.170.86.96.all.s5h.net
127.0.0.2
$ dig -t a +short 229.170.86.96.b.barracudacentral.org
127.0.0.2
$ dig -t a +short 229.170.86.96.bb.barracudacentral.org
127.0.0.2
$ dig -t a +short 229.170.86.96.black.dnsbl.brukalai.lt
127.0.0.2
$
...and for the domain:
$ dig -t a +short balug.org.postmaster.rfc-clueless.org
127.0.0.3
$
The domain claim is definitely bogus, and I don't know why the RBL
claims balug.org doesn't accept mail to postmaster -- as I just verified
that it does:
$ telnet balug.org smtp
Trying 96.86.170.229...
Connected to balug.org.
Escape character is '^]'.
220-balug.org ESMTP Exim 4.92 (EximConfig 2.5) Sat, 27 Jun 2020 03:41:33
+0000
220-.
220-WARNING: Unsolicited commercial E-mail (UCE/SPAM), pornographic
220-material, viruses and relaying is prohibited by this server and
220-any such messages will be rejected/filtered automatically
220-depending on content.
220-.
220-By using this server, you agree not to send any messages of the
220-above nature. Please disconnect immediately if you do not agree
220-to these terms and conditions.
220-.
220-Please contact postmaster(a)balug.org if you have any
220-enquiries about or problems with this server.
220-.
220-Find out more about EximConfig for the Exim mailer by visiting
220-the following URL: http://www.jcdigita.com/eximconfig
220 .
HELO linuxmafia.com
250 balug-sf-lug-v2.balug.org Hello linuxmafia.com [96.95.217.99]
MAIL FROM: <root(a)linuxmafia.com>
250 OK
RCPT TO: <postmaster(a)balug.org>
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
From: root(a)linuxmafia.com
To: postmaster(a)balug.org
Subject: Just testing postmaster deliverability
postmaster.rfc-clueless.org lists the balug.org domain, so I'm just
doing a test. Am guessing the RBL's claim is bogus.
.
250 OK id=1jp1kE-0004HS-RP
quit
221 balug-sf-lug-v2.balug.org closing connection
Connection closed by foreign host.
$
It could be that rfc-clueless.org's testing is aggressive enough
to occasionally cause Exim to reject the test mails to postmaster,
or that their text seems spammy to the rulesets, or something like
that. I cannot remember exactly where EximConfig's whitelisting
is, but, if logfile analysis reveals where rfc-clueless.org's test
mails originate, that would be a preventative.
The other listings are more troubling, claiming that balug.org's IP
has been functioning as a spamhaus.
The bounce message (below) talks about the IP address also being listed
at 'spamrl.com', but according to
https://www.gmass.co/blog/domain-blacklists-comprehensive-guide/ ,
'SpamRL.com is a domain blacklist cloaked in secrecy' with no Web-based
or other query tools, though one can manually de-list one's IP for up
to seven days at their Web site.
----- Forwarded message from mailman(a)lists.balug.org -----
Date: Sat, 27 Jun 2020 00:50:51 +0000
From: mailman(a)lists.balug.org
To: balug-talk-owner(a)lists.balug.org
Subject: Bounce action notification
This is a Mailman mailing list bounce action notice:
List: BALUG-Talk
Member: dale(a)skywriterhosting.com
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman(a)lists.balug.org.
Received: from Debian-exim by balug-sf-lug-v2.balug.org with local (Exim 4.92 #3 (EximConfig 2.5))
id 1joyqL-0001nw-BL ; Sat, 27 Jun 2020 00:37:17 +0000
X-Failed-Recipients: pricen(a)live-int.com,
james(a)globaltap.com,
jack(a)puppetlabs.com,
luke(a)teyssier.com,
zen(a)pengaru.com,
embeddedlinuxguy(a)gmail.com,
dale(a)skywriterhosting.com,
melissa(a)ginormus.com
Reply-To: postmaster(a)balug.org
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer-Daemon(a)balug.org>
To: balug-talk-bounces(a)lists.balug.org
Content-Type: multipart/report; report-type=delivery-status; boundary=1593218237-eximdsn-1255133696
MIME-Version: 1.0
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1joyqL-0001nw-BL(a)balug-sf-lug-v2.balug.org>
Date: Sat, 27 Jun 2020 00:37:17 +0000
X-SA-Do-Not-Run: Yes
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From:
X-SA-Exim-Scanned: No (on balug-sf-lug-v2.balug.org); SAEximRunCond expanded to false
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
pricen(a)live-int.com
retry timeout exceeded
james(a)globaltap.com
host mxa.spamstick.net [192.73.242.154]
SMTP error from remote mail server after RCPT TO:<james(a)globaltap.com>:
550 no mailbox by that name is currently available
jack(a)puppetlabs.com
host aspmx.l.google.com [2607:f8b0:400e:c07::1a]
SMTP error from remote mail server after RCPT TO:<jack(a)puppetlabs.com>:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/?p=NoSuchUser k88si9124651pjk.22 - gsmtp
luke(a)teyssier.com
host mail.teyssier.com [64.26.60.153]
SMTP error from remote mail server after end of data:
550 The sending IP (96.86.170.229) is listed on https://spamrl.com/. Please resolve this and retry.
zen(a)pengaru.com
host mail.pengaru.com [66.240.222.126]
SMTP error from remote mail server after RCPT TO:<zen(a)pengaru.com>:
554 5.7.1 Service unavailable; Client host [96.86.170.229] blocked using b.barracudacentral.org; http://www.barracudanetworks.com/reputation/?pr=1&ip=96.86.170.229
embeddedlinuxguy(a)gmail.com
host gmail-smtp-in.l.google.com [2607:f8b0:400e:c08::1b]
SMTP error from remote mail server after RCPT TO:<embeddedlinuxguy(a)gmail.com>:
552-5.2.2 The email account that you tried to reach is over quota. Please direct
552-5.2.2 the recipient to
552 5.2.2 https://support.google.com/mail/?p=OverQuotaPerm y34si3775952pgk.91 - gsmtp
dale(a)skywriterhosting.com
Unrouteable address
melissa(a)ginormus.com
Unrouteable address
Reporting-MTA: dns; balug-sf-lug-v2.balug.org
Action: failed
Final-Recipient: rfc822;melissa(a)ginormus.com
Status: 5.0.0
Action: failed
Final-Recipient: rfc822;dale(a)skywriterhosting.com
Status: 5.0.0
Action: failed
Final-Recipient: rfc822;embeddedlinuxguy(a)gmail.com
Status: 5.0.0
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 552-5.2.2 The email account that you tried to reach is over quota. Please direct
552-5.2.2 the recipient to
552 5.2.2 https://support.google.com/mail/?p=OverQuotaPerm y34si3775952pgk.91 - gsmtp
Action: failed
Final-Recipient: rfc822;zen(a)pengaru.com
Status: 5.0.0
Remote-MTA: dns; mail.pengaru.com
Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host [96.86.170.229] blocked using b.barracudacentral.org; http://www.barracudanetworks.com/reputation/?pr=1&ip=96.86.170.229
Action: failed
Final-Recipient: rfc822;luke(a)teyssier.com
Status: 5.0.0
Remote-MTA: dns; mail.teyssier.com
Diagnostic-Code: smtp; 550 The sending IP (96.86.170.229) is listed on https://spamrl.com/. Please resolve this and retry.
Action: failed
Final-Recipient: rfc822;jack(a)puppetlabs.com
Status: 5.0.0
Remote-MTA: dns; aspmx.l.google.com
Diagnostic-Code: smtp; 550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/?p=NoSuchUser k88si9124651pjk.22 - gsmtp
Action: failed
Final-Recipient: rfc822;james(a)globaltap.com
Status: 5.0.0
Remote-MTA: dns; mxa.spamstick.net
Diagnostic-Code: smtp; 550 no mailbox by that name is currently available
Action: failed
Final-Recipient: rfc822;pricen(a)live-int.com
Status: 5.0.0
Return-path: <balug-talk-bounces(a)lists.balug.org>
Received: from localhost ([127.0.0.1]:50342 helo=balug.org)
by balug-sf-lug-v2.balug.org with esmtp (Exim 4.92 #3 (EximConfig 2.5))
id 1joyoo-0001ju-Jy ; Sat, 27 Jun 2020 00:35:42 +0000
Received: from mail-lj1-f174.google.com ([209.85.208.174]:44764)
by balug-sf-lug-v2.balug.org with esmtps
(Cipher TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92 #3 (EximConfig
2.5)) id 1joyog-0001jQ-H0
for <balug-talk(a)lists.balug.org>; Sat, 27 Jun 2020 00:35:39 +0000
Received: by mail-lj1-f174.google.com with SMTP id s9so12067445ljm.11
for <balug-talk(a)lists.balug.org>; Fri, 26 Jun 2020 17:35:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=Wn8H2ShFdHhe4BNguMg/UIqr20XvfG9VUNOkJ854sRE=;
b=tXPJdqLthil1+swKuvMfVwBMeCKXD6EQCsxoaMi5rizt2LJGsRMTPYFSsClES7RVRF
Z3bpm8VCikrxXu6vyxd9cMaXZYnuD+4flBU6TUhrIINccno2Z+ilmgQbl3Opl1fr6IVC
aQ/D1EkmaBobeM2J2sLZZ8jko22xjqVQHZa9pPCeJCUbEqUgTDKoYmZFjEN64/oFviiS
nCZ3alynwZCqRGupT0kHyxfbuXHBIAf6MPg6UA/dVxyCEbTj+ig40uA35ElojuAopJX5
eWqnXiBO4oSC+1O36B31v66dAkvXv74zuFsBJzb+SFrIfgClW6gSOOWzpWkZNXfUpdZG
kMOw==
X-Gm-Message-State: AOAM530EzYEexmMPf1V7QDIi06oBzbRcWMkVwQ2ondPw36bOL0dnHHX1
3mPgUhjt8MLR/ZjrwirAE5FDP2yivNNlkJufiOCJ8HIY
X-Google-Smtp-Source: ABdhPJzAIqjhfbbkmBjG+4rYayUqSbTSQa6zyj9Z7hxTUx7Qw5khYM/hYXwXVV39a460nB5k6JtvA8ASIhifOlN7xN4=
X-Received: by 2002:a50:d790:: with SMTP id w16mr5805036edi.231.1593216865715;
Fri, 26 Jun 2020 17:14:25 -0700 (PDT)
MIME-Version: 1.0
References: <20200626023605.17604atnvm66m8ao(a)webmail.rawbw.com>
In-Reply-To: <20200626023605.17604atnvm66m8ao(a)webmail.rawbw.com>
From: Tony Godshall <togo(a)of.net>
Date: Fri, 26 Jun 2020 17:13:48 -0700
Message-ID: <CAAOvATjh27eGzrAMmnDUCxsKPskbdO0XG02FvzZHij0gt9kv1g(a)mail.gmail.com>
To: Michael Paoli <Michael.Paoli(a)cal.berkeley.edu>
X-Flood-Protect-Sender-Added: Yes
X-Flood-Protect-Sender-Rcpt-Added: Yes
Received-SPF: pass (gmail.com ... _spf.google.com: Sender is authorized to use
'apgodshall(a)gmail.com' in 'mfrom' identity (mechanism
'include:_netblocks.google.com' matched) (gmail.com ... _spf.google.com:
Sender is authorized to use 'apgodshall(a)gmail.com' in 'mfrom' identity
(mechanism 'include:_netblocks.google.com' matched)))
X-Greylist-Verify-Added: Yes
X-Greylist-Passed: Yes
X-Flood-Protect-Repeat-Fail-Added: Yes
X-Flood-Protect-Message-Added: Yes
X-SA-Do-Not-Teergrube: Yes
X-EximConfig: v2.5 on balug.org (http://www.jcdigita.com/eximconfig)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
balug-sf-lug-v2.balug.org
X-Spam-Level:
X-Spam-Status: No, score=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,
RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.2
Subject: Re: [BALUG-Talk] Company in Concord seeks to donate older PCs to a
LUG
X-BeenThere: balug-talk(a)lists.balug.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General discussion list for BALUG <balug-talk.lists.balug.org>
List-Unsubscribe: <https://lists.balug.org/cgi-bin/mailman/options/balug-talk>,
<mailto:balug-talk-request@lists.balug.org?subject=unsubscribe>
List-Archive: <https://lists.balug.org/pipermail/balug-talk/>
List-Post: <mailto:balug-talk@lists.balug.org>
List-Help: <mailto:balug-talk-request@lists.balug.org?subject=help>
List-Subscribe: <https://lists.balug.org/cgi-bin/mailman/listinfo/balug-talk>,
<mailto:balug-talk-request@lists.balug.org?subject=subscribe>
Cc: BALUG-Talk <balug-talk(a)lists.balug.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: balug-talk-bounces(a)lists.balug.org
Sender: "BALUG-Talk" <balug-talk-bounces(a)lists.balug.org>
X-SA-Do-Not-Run: Yes
X-EximConfig: v2.5 on balug.org (http://www.jcdigita.com/eximconfig)
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: balug-talk-bounces(a)lists.balug.org
X-SA-Exim-Scanned: No (on balug-sf-lug-v2.balug.org); SAEximRunCond expanded to false
Ah, I recall times I participated in Installfest For The Schools, I
think these guys were involved...
On Fri, Jun 26, 2020 at 2:37 AM Michael Paoli
<Michael.Paoli(a)cal.berkeley.edu> wrote:
>
> Also replied to 'em off-list regarding Partimus and such.
>
> references/excerpts:
>
> > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu>
> > To: "Cameron Abrams" <cameronabrams25(a)gmail.com>, "Christian
> > Einfeldt" <christian(a)partimus.org>, "Grant Bowman"
> > <grant(a)partimus.org>, "James Howard" <james(a)partimus.org>
> > Cc: "Rick Moen" <rick(a)linuxmafia.com>
> > Subject: Re: Company in Concord seeks to donate older PCs to a LUG
> > Date: Fri, 26 Jun 2020 02:15:09 -0700
>
> > Cameron / Partimus folks, perhaps y'all ought connect. :-)
> >
> > I believe Partiums is (approximately?) based in(/around?) San Francisco,
> > and also does / has done work with some East Bay (Oakland, if I
> > recall correctly) school(s). I believe Grant is also out in East Bay,
> > East of Concord.
> >
> > Also including link to list of lists (of [L]UGs), in case that's
> > also useful.
> >
> > Thanks for reaching out and asking!
> >
> > http://www.partimus.org/
> > http://www.partimus.org/contact.php
> >
> > https://www.wiki.balug.org/wiki/doku.php?id=balug:bay_area_open_source_linu…
> >
> > references/excerpts:
> > http://linuxmafia.com/pipermail/dvlug/2020q2/000608.html
> > http://linuxmafia.com/pipermail/dvlug/2020q2/000609.html
> > https://groups.google.com/g/berkeleylug/c/Tr_WRg1STpI/m/qOZ_8bheCQAJ
> > https://lists.balug.org/pipermail/balug-talk/2020-June/000213.html
> >
> >> From: "Rick Moen" <rick(a)linuxmafia.com>
> >> To: dvlug(a)linuxmafia.com
> >> Subject: [dvlug] Company in Concord seeks to donate older PCs to a LUG
> >> Date: Thu, 25 Jun 2020 11:02:25 -0700
> >
> >> ----- Forwarded message from Cameron Abrams
> >> <cameronabrams25(a)gmail.com> -----
> >>
> >> Date: Thu, 25 Jun 2020 09:28:39 -0700
> >> From: Cameron Abrams <cameronabrams25(a)gmail.com>
>
>
> > From rick(a)linuxmafia.com Thu Jun 25 18:11:04 2020
> > Date: Thu, 25 Jun 2020 11:10:49 -0700
> > From: Rick Moen <rick(a)linuxmafia.com>
> > To: BALUG-Talk(a)lists.balug.org
> > Subject: [BALUG-Talk] Company in Concord seeks to donate older PCs to a LUG
> >
> > ----- Forwarded message from Cameron Abrams <cameronabrams25(a)gmail.com> -----
> >
> > Date: Thu, 25 Jun 2020 09:28:39 -0700
> > From: Cameron Abrams <cameronabrams25(a)gmail.com>
> > To: dvlug-owner(a)linuxmafia.com
> > Subject: Do you take donations?
> >
> > Hello,
> >
> > I am contacting you on behalf of the company I work for. We are located in
> > Concord, and are in the midst of a transition. We would like to get rid of
> > some older PCs we have replaced with newer ones, and we are in the midst of
> > wiping all of our hard drives. We were wondering if perhaps this was a
> > Linux group that took donations, as we would rather put the PCs to use than
> > scrap them as e-waste. If you do accept donations and would like to discuss
> > this matter further, or if you do not accept donations but do know of other
> > local groups that accept donations, please email me back.
> >
> > Thanks,
> >
> > Cameron
> >
> > ----- End forwarded message -----
>
>
> _______________________________________________
> BALUG-Talk mailing list
> BALUG-Talk(a)lists.balug.org
> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-talk
--
--
Best Regards.
This is unedited.
This message came out of me
via a suboptimal keyboard.
_______________________________________________
BALUG-Talk mailing list
BALUG-Talk(a)lists.balug.org
https://lists.balug.org/cgi-bin/mailman/listinfo/balug-talk
----- End forwarded message -----
> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu>
> To: BALUG-Talk <balug-talk(a)lists.balug.org>
> Subject: test DNS that returns SERVFAIL? ... ! :-)
> Date: Mon, 13 Apr 2020 03:14:35 -0700
> Ah yes, I'm quite starting to get used to and like/prefer dynamic DNS
> update. Significantly more goof-resistant, and most of the time I don't
> even have to think about the zone serial number. Which reminds me,
> I do still want to add some version "control" (tracking) ... driven via
> cron, so I'll at least have periodic snapshots of changes (since no
> longer using ye olde manual method & manual version control). For
> more recent changes, and fine-grained history of changes, logs cover
> that quite well. But for the longer historical record ... wee bit 'o
> gap presently to fill on that.
And now added. Doesn't catch the "why", and doesn't catch
change-by-change, but automatic daily check-in of any changes,
"good enough" for my(/our?) purposes here, and have that now:
$ cat /etc/cron.d/local-bind-master-auto-rcs
0 10 * * * root exec >>/dev/null 2>&1 && for zone in
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa berkeleylug.comsf-lug.comsflug.comsf-lug.netsflug.netbalug.orgberkeleylug.orgsf-lug.orgsflug.org; do rndc sync -clean "$zone" && rndc freeze "$zone" && {
rcsdiff digtitalwitness.org || { rcsdiffrc="$?"; [ "$rcsdiffrc" -ne 1
] || { ci -l -d -M -m'checking in change(s)' "$zone"; }; }; rndc thaw
"$zone"; }; done; :
$ hostname
balug-sf-lug-v2.balug.org
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 27 Apr 19 09:56 /etc/localtime ->
/usr/share/zoneinfo/Etc/UTC
$
Okay, one more time ... hopefully relatively smoothly this time.
Have done fair bit more thorough testing, essentially on
"cloned" virtual machines (while also taking the appropriate
precautions to avoid conflicts with the running production).
Anyway, will restart the upgrade process soon.
If all goes relatively smoothly, should be complete after
a few hours or so.
Services - for the most part will mostly remain up and operational
throughout, but there will definitely be at least some disruptions,
due to some required reboot(s) and stopping and restarting of
services. I'll update once things have completed and things
look good ... or any substantially different results.
This BALUG VM is the host that supports essentially all (except some
additional DNS slaves) services of:
BALUG
and likewise excepting list services, for:
SF-LUG
BerkeleyLUG
references/excerpts:
https://lists.balug.org/pipermail/balug-admin/2020-February/001017.htmlhttps://lists.balug.org/pipermail/balug-admin/2020-February/001018.htmlhttp://linuxmafia.com/pipermail/conspire/2020-April/010521.htmlhttp://linuxmafia.com/pipermail/conspire/2020-April/010525.html
The BALUG.org Virtual Machine (VM)
balug / balug-sf-lug-v2.balug.org
which also hosts most all things, not only BALUG.org,
but also SF-LUG.org (excepting it's lists) and BerkeleyLUG.com,
I'm intending to upgrade the operating system soon.
Expecting some modest outages with some service restarts and reboots,
etc. But expecting for the most part it will remain up.
I did also earlier upgrade "vicki"
https://lists.balug.org/pipermail/balug-admin/2020-February/001016.html
just fine,
and also successfully completed a dry run test upgrade:
created LVM snapshot of the running balug VM,
copied snapshot to LVM volume,
built VM around that volume - and configured to be
highly similar to balug (differing only in Ethernet
MAC address and VM related UUID(s) and name
and networking (different subnet/network/vLAN)),
disabled network link at VM before "powering up" the VM,
reconfigured network so as to not conflict with balug,
disabled services (most especially anything that would attempt
to send email), enabled network link and networking,
went through the full upgrade process - all went well,
no issues of any significance encountered.
Anyway, now I move on to the "real deal" (the actual balug VM).
I'll report if any significant issues come up - otherwise
presume all has gone fine and the upgrade will be completed soon (likely
today).
So, starting on 2020-01-31
I upgraded the "vicki" host (physical: Supermicro PDSMi)
from:
Debian GNU/Linux 9.11 (stretch) x86_64
to:
Debian GNU/Linux 10.2 (buster) x86_64
vicki is the host that's the occasional* host that hosts the
balug Virtual Machine (VM) - that
VM hosts most all things:
BALUG.orgSF-LUG.org (excepting list(s))
BerkeleyLUG.com
(and excepting DNS slaves thereof)
*occasional - vicki mostly hosts the BALUG VM when it's not otherwise
being hosted on its nominal host (which is much quieter and has
significantly more RAM, but alas, is a laptop, and semi-regularly
ventures out or is otherwise unavailable for hosting the balug VM -
hence the VM typically live migrates first to vicki on such occasions,
and then back again when the nominal host is available again). The
(rather loud, and power hungry) vicki hosts spends most of its time
powered off when it's not hosting the balug VM.
And the upgrade ... mostly was done live and went mostly quite smoothly.
Here are the slight bits that took a little more/additional attention:
apt[-get] autoremove - After the upgrade, apt[-get] was suggesting
using autoremove to remove a bunch of "no longer needed" stuff. I
reviewed the list, most of it was fine/routine (e.g. lots of libraries
- which would otherwise remain if that dependent upon them also
remained), ... but some bits of it weren't, e.g. bridge-utils (notably
at least, I sometimes use brctl, and it may also be used by ifup/ifdown
and friends, and/or libvirt). There may have been a small number of
packages other than that, which autoremove would've defaulted to
removing, but which I opted to retain. After suitably adjusting the
status of those (so apt[-get] would show them as explicitly requested
rather than just brought in to satisfy some dependency(/ies),
proceeded fine with the autoremove (with --purge - the relevant
pre-upgrade backups were done, so no need to otherwise explicitly retain
configs for packages being removed).
libvirt - live migration from of VM from
Debian GNU/Linux 9.11 (stretch) x86_64
to:
Debian GNU/Linux 10.2 (buster) x86_64
worked fine, but trying to live migrate back failed.
Found and corrected issue to allow backwards compatibility to Stretch,
from the (hand maintained for human(s)) logs:
To allow live migration back to Debian 9.x without apparmor,
in file /etc/libvirt/qemu.conf
changed:
security_driver = "selinux"
to:
#security_driver = "selinux"
#####
security_driver = "none"
#####
and restarted libvirtd
I did end up rebooting the VM after making that change though.
Although the live migration to Buster had added the different security
bit, I wasn't able to quickly and easily determine a way to live remove
that. But the balug VM was long overdue for a reboot anyway (not on
latest security kernel update, likewise older libraries/binaries still
in process RAM from long-running daemon processes, etc.), so rebooted,
as the expedient way to both address that and the apparmor bit that
Buster had dragged into the running VM. Was then able to live migrate
back to Stretch without issue.
That was basically it, no other issues of note bumped into (did review
the install and release notes documentation, did first cover relevant
items from there - most notably network device names - and having
covered that first avoided any surprises on that).