I installed ubuntu 20.04.3 to replace a slightly older ubuntu.
Thunderbird 78.14.0 was installed along with the new Ubuntu.

1. I clicked the TB icon and it asked the basic questions: username,
email address & password. So I entered those.
2. Then it says: "thunderbird failed to find the settings for your email
account"
3. and it shows the following chart of settings:

protocol: IMAP/SMTP
server: .comcast.net/.comcast.net (note: these are not server names)
port: Auto/Auto
SSL: Autodetect/Autodetect
authentication: Autodetect/Autodetect
user name: myemailaddress/myemailaddress

4. I checked my other PC that has slightly older Ubuntu and TB versions,
and I used those settings in the new setup, as follows:

incoming server protocol: IMAP
incoming server: imap.comcast.net
port: 993
connection security: SSL/TLS
authentication: normal password
user name: myemailaddress

outgoing server protocol: SMTP
outgoing server: smtp.comcast.net
port: 465
connection security: SSL/TLS
authentication: normal password
user name: myemailaddress

5. Now I tried to get my email and it says:

"failed to connect to server .comcast.net"

which leads me to believe it is using the string ".comcast.net" for the
server name.

QUESTION#1: I am really sure the settings listed in item 4 above are
correct. I can't figure what can be the problem. Has anyone had a
similar problem?

QUESTION#2: I think I had this problem on a previous Ubuntu/TB rebuild
and maybe I solved it by installing

libnss-resolve

but when I try I get the error message:
Temporary failure resolving 'us.archive.ubuntu.com'.

How can I install libnss-resolve?

TIA Bill S.

On 12/01/2022 7:23, bilsch01 wrote:
> I installed  ubuntu 20.04.3 to replace a slightly older ubuntu. Thunderbird 78.14.0 was installed along with the new
> Ubuntu.
>
> 1. I clicked the TB icon and it asked the basic questions: username, email address & password. So I entered those.
> 2. Then it says: "thunderbird failed to find the settings for your email account"
> 3. and it shows the following chart of settings:
>
> protocol: IMAP/SMTP
> server: .comcast.net/.comcast.net (note: these are not server names)
> port: Auto/Auto
> SSL: Autodetect/Autodetect
> authentication: Autodetect/Autodetect
> user name: myemailaddress/myemailaddress
>
> 4. I checked my other PC that has slightly older Ubuntu and TB versions, and I used those settings in the new setup, as
> follows:
>
> incoming server protocol: IMAP
> incoming server: imap.comcast.net
> port: 993
> connection security: SSL/TLS
> authentication: normal password
> user name: myemailaddress
>
> outgoing server protocol: SMTP
> outgoing server: smtp.comcast.net
> port: 465
> connection security: SSL/TLS
> authentication: normal password
> user name: myemailaddress
>
>
> 5. Now I tried to get my email and it says:
>
> "failed to connect to server  .comcast.net"
>
> which leads me to believe it is using the string ".comcast.net" for the server name.
>
> QUESTION#1: I am really sure the settings listed in item 4 above are correct. I can't figure what can be the problem.
> Has anyone had a similar problem?
>
> QUESTION#2: I think I had this problem on a previous Ubuntu/TB rebuild and maybe I solved it by installing
>
> libnss-resolve
>
> but when I try I get the error message:
> Temporary failure resolving 'us.archive.ubuntu.com'.
>
> How can I install libnss-resolve?
>
> TIA   Bill S.
>
>
On Ub 20.04, from Synaptic:

nss-resolve is a plugin for the GNU Name Service Switch (NSS) functionality
of the GNU C Library (glibc) providing DNS and LLMNR resolution to programs via
the systemd-resolved daemon (provided in the systemd package).

Installing this package automatically adds resolve to /etc/nsswitch.conf.

found in "universe" repository (check your repositories)
Dunno about the TB address problem

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691

The problems were with the bundled Thunderbird and Firefox. I
downloaded a different .iso file, did the install and everything works
excellently.

Here's the link to the good iso file:
https://mirror.lstn.net/ubuntu-releases/20.04.3/ubuntu-20.04.3-desktop-amd64.iso

Bill S.

bilsch01 wrote:
> I downloaded a different .iso file, did the install and everything works
> excellently.

Whenever I dl an .iso, I always check the hash and if at all possible,
authenticate the .sig.

The idea of the hash being in case some bit gets lost. Sometimes I
think the authentication step is either a form of 'overkill'
security-wise or 'pretentious' (pretend-y-ous) considering that we
don't actually follow a proper prescribed web of trust acquiring keys.

--
Mike Easter

On 1/12/2022 5:18 PM, Mike Easter wrote:
> bilsch01 wrote:
>> I downloaded a different .iso file, did the install and everything works excellently.
>
> Whenever I dl an .iso, I always check the hash and if at all possible, authenticate the .sig.
>
> The idea of the hash being in case some bit gets lost.  Sometimes I think the authentication step is either a form of 'overkill' security-wise or 'pretentious' (pretend-y-ous)  considering that we don't actually follow a proper prescribed web of trust acquiring keys.
>

At least some of the Ubuntu DVDs I have here, when you boot
them, they verify the DVD contents. You might notice a 3 minute
boot time on some of them. It would not be quite as bad, if using
a really fast USB stick to hold the media.

[Picture] Ubuntu doing a verify when the DVD boots

https://i.postimg.cc/5t52qCM2/boot-time-livedvd-verification.gif

Previous Ubuntu Live materials did not do that, and you had to
do the traditional md5sum or sha1sum or whatever, to check media
against web site.

Paul

Paul wrote:
> Mike Easter wrote:
>> bilsch01 wrote:
>>> I downloaded a different .iso file, did the install and everything
>>> works excellently.
>>
>> Whenever I dl an .iso, I always check the hash and if at all possible,
>> authenticate the .sig.
>>
>> The idea of the hash being in case some bit gets lost.  Sometimes I
>> think the authentication step is either a form of 'overkill'
>> security-wise or 'pretentious' (pretend-y-ous)  considering that we
>> don't actually follow a proper prescribed web of trust acquiring keys.
>>
>
> At least some of the Ubuntu DVDs I have here, when you boot
> them, they verify the DVD contents. You might notice a 3 minute
> boot time on some of them. It would not be quite as bad, if using
> a really fast USB stick to hold the media.
>
The last time I did a media check option at the time of boot took 'forever'.

But then, I'm typically using a yesteryear resource machine w/ usb2; but
my point is that whatever that media check is about is very slow
compared to a hash checker, which of course is reading off the hdd not
the usb.

--
Mike Easter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Mike Easter wrote:
> [...]
> But then, I'm typically using a yesteryear resource machine w/ usb2; but
> my point is that whatever that media check is about is very slow
> compared to a hash checker, which of course is reading off the hdd not
> the usb.

Checking the hash of the ISO file is fine, but doesn't verify that the
burn was actually "good". It's perfectly plausible to burn a coaster[1]
from an otherwise good ISO file.

[1]Granted, USB sticks don't make very good coasters, unlike failed
burns to optical media.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmHgTYkACgkQbWVw5Uzn
KGAZAg/9FAUHq1EoaUgamdglKN/4JOWIeHc9McJJOR4pLc+o5anjFvP3LIDghteF
Yto/N2IvOj3Es+YudZMq5I/BE3I+iQHOqpLOCjIRwBtfchBJ80+JZIV1Lqa+euC3
n6w64/b1dHdFuwpEXXdt9Ch7uZ0kR2mdhy+N6iTVlFBdojjoiwN/fvqljD4DNOny
AUJXePqc9d40tKl+MzTGeIIxfJHp3uRCPjfXmNnzdD/x5Od2AhJel+RzsFwbae8N
um+TVZP0g0DaEomYr3KCUjdLcSPVUIJArSAaj4MGjl8hlXFE2it5TNY0dzkSnhAT
kZZHpzruJpoqF3yhYCjs3sPLmXcl4ysnab5P6YIDj0tstFIegqhUvsMwv3fpQRvD
WoctNDBXTehNjUlaqp3SiYlcOQVm/vT9WVKpwPdA3BSjhXKTst8JnWBkIOl4/4y8
kqyG9JljXvRXmtbCTebL4r4tvGPP7PtHQLUlFzCOuth64FofAu/ac3tFmOYyWWHb
HpnK9FdSB7hPgKkYnqQyyIfBARiH+d1H12dKjRL0K8qlH2rNL/IJHSxjmvVgyVWv
vKsA1XtZ/mPjq++iSSK9fZ2Y93J7+j62v8KsEu4Rfy2CZfk6UuZeI2cUXkFwem4r
JvHrcGuvxaX8PCQ6Nkl5Olkn2xbLMUwKGEYW0loHjg5zRtq84fs=
=b9Mh
-----END PGP SIGNATURE-----

--
|_|O|_| Github: https://github.com/dpurgert
|_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
|O|O|O|

Dan Purgert wrote:
> Mike Easter wrote:
>> [...]
>> But then, I'm typically using a yesteryear resource machine w/ usb2; but
>> my point is that whatever that media check is about is very slow
>> compared to a hash checker, which of course is reading off the hdd not
>> the usb.
>
> Checking the hash of the ISO file is fine, but doesn't verify that the
> burn was actually "good". It's perfectly plausible to burn a coaster[1]
> from an otherwise good ISO file.
>
> [1]Granted, USB sticks don't make very good coasters, unlike failed
> burns to optical media.
>
Some USB writers, like many optical writers, can do a verify after the
write.

My experience has been that nothing has been as slow as my observation
of 'media check' of a USB from a boot option.

Where 'nothing' refers to:
- hashcheck .iso
- optical write verify media
- usb write verify media

.... in my limited experience; I haven't done it in a long time. Maybe
something has improved since then.

--
Mike Easter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Mike Easter wrote:
> Dan Purgert wrote:
>> Mike Easter wrote:
>>> [...]
>>> But then, I'm typically using a yesteryear resource machine w/ usb2; but
>>> my point is that whatever that media check is about is very slow
>>> compared to a hash checker, which of course is reading off the hdd not
>>> the usb.
>>
>> Checking the hash of the ISO file is fine, but doesn't verify that the
>> burn was actually "good". It's perfectly plausible to burn a coaster[1]
>> from an otherwise good ISO file.
>>
>> [1]Granted, USB sticks don't make very good coasters, unlike failed
>> burns to optical media.
>>
> Some USB writers, like many optical writers, can do a verify after the
> write.

Yep, and I've still had coasters after that. :(

Turned out it was bad RAM in the burning machine that my "normal" usage
didn't really touch at the time.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmHhXysACgkQbWVw5Uzn
KGAb4w/9G4f9wymoQsOuOfVQ0VVBIXRE9u/+neGDdrxML5bYPUOHy9dhDtfYv0FD
4cAF4XOP897bY1ZePluK22CFzEGN8quWSeSc8yhgiqTZa7lROyU+R7h6QR6Yw+sZ
xamMAN1wW6Xfcp6onP05EOyUYgjktK35xAsxvxvDNtjolR9ocSLjFq6F8eUtUASh
UEDXpfDeDHW4r5u7VpVhxJnwRrxjVtzgdeBMa5yP2u7gODnQsu1uVRT6ana9FcJb
KoNT6KNM62yBB+gjxdYUqcKaFzDxvHkh88S6KabDfJLyutz/3pNU46HugXgYN/Ys
dMiBKTzhlIftl8k2bCFjU86RkoVdW4nwGFtoLUCG465ZGsxIed2bihKo1CAkHkl/
kJ2F7stLjq2UJcg4dP7IpQUVtGlDlWN8jg6W7vdUdp9Tq1wrLSyGahfiPYmakuz5
Ku34Yf/uu7uxchlSP5d4wj7j7f55+euWqdtubkwAo1ehCox5q/iLlEimzc5myUOL
GceInaBF6OBL01zWKAtJS874bNF3hqz7V6VTZmxGn7372hZ4l+JL6KqZrUXUCkVM
MOsnYS9dFogkX0SsoxBBzCa7pSaRD/nCmn4zzzPH1Bvl3xItzIrxMnXqb4kQ9gkA
CbgmF+LfbMSY4Vs6zcNlmmtjv1JjYoq5Qrpj+HkSUgnZ08qzbls=
=7LyY
-----END PGP SIGNATURE-----

--
|_|O|_| Github: https://github.com/dpurgert
|_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
|O|O|O|