Upgrade to 2.3.1 has failed

[C. Andrews Lavarre]

Phil hi.
Thank you for explaining what the symbol does... so it is like the
BASH from symbol. OK.That is new information.
So without it dovecot reads the path/to/file as if it were a hashed
cert, which of course doesn't work. So with the symbol dovecot tries to
follow the path to read the cert but for some reason cannot read it.
Now, that is curious, since I can cat the path/to/file and read the
cert or key...
Now, while the /path/to/file permission is presently  root:root 0777 (y
es, I know 0777 is not good, but I was trying to eliminate any
prevention to reading it) it is actually a soft link to yet another
file. Let'sEncrypt has to be renewed every so often so the cert engine
(certbot) recreates the softlink to the new cert so that we don't need
to edit 10-ssl.conf. 
So I have entered the actual full path/to/file for the cert and key
(not the softlinks) to eliminate that possibility, buty it didn't help.
So it's something else. 
As you say, focus on the problem: Simply put, why can 2.3.1 not read a
file while we can list and print out (ls, cat) the file? What changed
in that regard from 2.2.x to 2.3.1?
----
I'm very grateful for the time folks have spent on this, including my
own time. I'm not being rude, just factual. This is what is happening.
But "something is wrong with your configuration",  while equally
factual, is also equally ineffective. 
OTOH, in my experience factually describing an anomaly can lead to
someone wondering why it might be, and if they are more knowledgeable
of the inner workings of the system be better able to understand why
that might be. 
For example, I didn't know anything about AppArmor before, now I do,
have gone down that rabbit hole, and seem to be able to say, nope,
that's not the problem. So now I can move on to checking out something
else. 
Similarly, under BASH the path/to/files are all correct and I can read
them from the command line. And 2.2.x didn't have any problem with
them. So why might 2.3.1 not be able to read them?
So we all need to leave this alone, for now. I'll work along, and
when/if I figure it out shall return to report. I'm sure it's something
simple: Easy when you know how. :-)
Thanks again.
Andy
On Sun, 2018-12-16 at 07:41 -0500, Phil Turmel wrote:
> Andy,
> 
> This is just rude.  You have been told multiple times that the less-
> than
> symbol is required to read the certificate from the file.  Otherwise,
> the filename is parsed as if it is the certificate itself.  Which
> yields
> garbage.
> 
> If dovecot can't read that file, it is *not* dovecot's fault.  You
> are
> simply not going to succeed until *you* figure out what security
> differences you have in your new installation.  So dovecot can read
> the
> files.  Every single attempt to connect via openssh depends on
> dovecot
> reading your certificate and key files.  They are pointless exercises
> until dovecot actually loads your files.  Focus on the real problem
> if
> you wish to fix your service.
> 
> On 12/15/18 5:12 PM, C. Andrews Lavarre wrote:
> > 
> > Alexander, Thanks, as described before, if I include the "<" then
> > Dovecot fails to start at all.
> > 
> > Thank you again for your time. I have forwarded my latest to Aki to
> > the
> > group.
> 
> Regards,
> 
> Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20181216/535f33f5/attachment.html>