Upgrade to 2.3.1 has failed

[Daniel Miller]

As a LetsEncrypt user myself, I have:

ssl_cert = </etc/letsencrypt/live/myserver/fullchain.pem
ssl_key = </etc/letsencrypt/live/myserver/privkey.pem

So nothing further should be required.  You say Dovecot fails to start - 
have you tried simply executing "dovecot -F"?

Daniel

On 12/16/2018 6:19 AM, C. Andrews Lavarre wrote:
> 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 
> *(yes, 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/74ef2c54/attachment.html>