<html><head></head><body><div>Phil hi.</div><div><br></div><div>Thank you for explaining what the symbol does... so it is like the BASH <b>from</b> symbol. OK.That is new information.</div><div><br></div><div>So without it dovecot reads the <b>path/to/file</b> as if it were a hashed cert, which of course doesn't work. So <b>with</b> 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 <b>cat</b> the path/to/file and read the cert or key...</div><div><br></div><div>Now, while the /path/to/file permission is presently <b>root:root 0777 </b>(yes, I know 0777 is not good, but I was trying to eliminate any prevention to reading it)<b> </b>it is actually a soft link to yet another file. Let'sEncrypt has to be renewed every so often so the cert engine (<b>certbot</b>) recreates the softlink to the new cert so that we don't need to edit <b>10-ssl.conf</b>. </div><div><br></div><div>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. </div><div><br></div><div>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 (<b>ls, cat</b>) the file? What changed in that regard from 2.2.x to 2.3.1?</div><div><br></div><div>----</div><div><br></div><div>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.</div><div><br></div><div>But "something is wrong with your configuration", while equally factual, is also equally ineffective. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div>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. :-)</div><div><br></div><div>Thanks again.</div><div><br></div><div>Andy</div><div><br></div><div>On Sun, 2018-12-16 at 07:41 -0500, Phil Turmel wrote:</div><blockquote type="cite"><pre>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:
<blockquote type="cite">
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.
</blockquote>
Regards,
Phil
</pre></blockquote></body></html>