Topic: Suddenly getting lots of theses reports

[DanB35]

I know. But if there's nothing to report and nothing in a log, what should I report?

Literally nothing happens when you type "dehydrated -c"?  It just returns you to a shell prompt?  Even that would have been helpful, and more than you stated, but it also would be very surprising.

It'd be helpful to try to troubleshoot it, rather than to just blow out the contrib and move to a manual installation.  Or better yet, file a bug against the contrib.  A couple of ideas here:

What's the output of "which dehydrated"?

What are the contents of /etc/dehydrated/config?  Mask your email address if you like; the rest isn't sensitive.

What are the contents of /etc/dehydrated/domains.txt?  Is your hostname listed there?

[DanB35]

Please make sure you remove everything. Uninstalling the contrib does not remove e.g. db config info e.g. 'config show letsencrypt'

Although it's a good idea to keep the database clean, stray entries won't affect a manual installation if there's no template referring to them (which there wouldn't be with a manual installation).

[guest22]

Although it's a good idea to keep the database clean, stray entries won't affect a manual installation if there's no template referring to them (which there wouldn't be with a manual installation).

Correct regarding the contrib specific templates (fragments) The service entry by itself will trigger processing by the default expand-templates engines, in returned called by all kinds of signal-events and actions.


A service entry tagged as 'service' will be processed, where as we could choose to tag an entry with 'uninstalled' which would then bypass all other events.

[DanB35]

Really, there shouldn't be any situation where the dehydrated script produces no output at all, which is what makes me wonder if it's actually running at all.  Hence the request for the output of "which dehydrated", as it would show where it's trying to run from.

If, for example, your PATH were completely bizarre, and looked to /etc/cron.daily/ before it looked to /usr/bin/, it would have that effect.  Or if you were in /etc/cron.daily/, and instead of typing "dehydrated -c", you typed "./dehydrated -c", that would explain it.  Or if you were in /etc/cron.daily/ and your PATH included "." (which it probably never should at all, and certainly never should as root), that would explain it.  But all of these sound pretty far-fetched.

[guest22]

I guess the easiest way to se what is going on is for the author of the contrib to test the contrib on a clean vm. I was installing on a production server under the 'assumption' it was fully tested and 'approved'.

[DanB35]

The contrib has been tested, repeatedly, on a clean VM--I know because I did a lot of the testing.  The easiest way to see what is going on is for those who are having problems to actually try to troubleshoot rather than just saying forget it.

[guest22]

I would if it was a test. This was a scheduled production server, and not available for trouble shooting.

[Stefano]

I guess the easiest way to se what is going on is for the author of the contrib to test the contrib on a clean vm. I was installing on a production server under the 'assumption' it was fully tested and 'approved'.

Installed and working with no issues on at least a dozen of servers

[guest22]

Stefan tried yesterday and I tried 2 days back. Maybe something has changed during the last few days?

[DanB35]

Stefan tried yesterday and I tried 2 days back. Maybe something has changed during the last few days?

Unlikely; I have the current versions installed, and they're working fine.

I'm not saying you aren't having a problem, but it's frustrating (not to mention at least a little insulting) to see you suggest that not even the most basic testing was done on the contrib, especially when you know better--you reported the bug, for heaven's sake, and quite a bit of the discussion and testing took place there.

So, something apparently isn't working as expected for you, or for @SchulzStefan.  That's unfortunate, and the results you're both describing are surprising (at least to me).  Since it is working perfectly for me and for @Stefano (and @ReetP, and I suspect many others), that points to something different in your installation.  Can you test it on a VM?  If so, do you see the same results?

[guest22]

I'm not saying you aren't having a problem, but it's frustrating (not to mention at least a little insulting) to see you suggest that not even the most basic testing was done on the contrib, especially when you know better--you reported the bug, for heaven's sake, and quite a bit of the discussion and testing took place there.ation.  Can you test it on a VM?  If so, do you see the same results?

No insulting intended, just reporting events. As you describe, 'we have it installed' means it was not installed on a new machine/VM during the last few days. Updating and testing already installed contrib is different from installing it on a new machine/VM, especially since we went over to SME Server 9.2. If I have time i will try to test on a VM, but I have so little spare time. Reporting and following this is all I can do for now.

[DanB35]

I did install it on clean VMs several times throughout the development process for testing, and it is currently working on my main machine.  I just built a clean test VM with 9.2 and installed it, though, and I'm seeing similar (though not identical) results to what you're reporting:

Code: [Select]

[root@sme92-test ~]# dehydrated -c
# INFO: Using main config file /etc/dehydrated/config
[root@sme92-test ~]#

My apologies.  As penance, I've reported the bug: https://bugs.contribs.org/show_bug.cgi?id=10300

[guest22]

My apologies.  As penance, I've reported the bug: https://bugs.contribs.org/show_bug.cgi?id=10300

No problem, glad we have identified something odd and concur.

[SchulzStefan]

To all:

Switching to https://bugs.contribs.org/show_bug.cgi?id=10300

regards,
stefan

[DanB35]

Switching to https://bugs.contribs.org/show_bug.cgi?id=10300

Replying back here, since the comment you added to the bug really deals with something else.

I can only assume Stefano didn't consider the possibility of your firewall blocking outbound connections from your server; I know I didn't.  Yes, your server must be able to make outbound connections on ports 80 and 443, and the entire Internet needs to be able to reach your server on port 80.  No, you can't whitelist particular inbound IPs for the validation; Let's Encrypt has repeatedly stated that they intend to validate from a wide range of IPs and networks.

You should not have needed to manually edit domains.txt.  Simply set letsencryptSSLcert to enabled for those hostnames and/or domains you want to be named on the cert, and only for those hostnames and/or domains.  Then, a signal-event console-save will generate the files properly.

The problem you're encountering is that xxx.de apparently goes somewhere other than to your SME server, so the challenge doesn't succeed--when the LE servers try to get the challenge file, it gets a 404 error.