ACME client not starting (22.1.6 w/ /var on tmpfs)

[Grossartig]

I noticed that the ACME client doesn't start when I change /var to be on tmpfs. The only way to get it going again is to disable, then enable the ACME client in its settings. However, on the next OPNsense reboot, it's red again and I cannot start it until I go through the same sequence described above. This doesn't seem to happen when /var is not in RAM.

I see the following in the system log:

Code Select Expand


<13>1 2022-05-02T03:01:43-04:00 OPNsense.lan root 65690 - [meta sequenceId="26"] /usr/local/etc/rc.d/acme_http_challenge: WARNING: /var/etc/lighttpd-acme-challenge.conf is not readable.
<13>1 2022-05-02T03:01:43-04:00 OPNsense.lan root 66935 - [meta sequenceId="27"] /usr/local/etc/rc.d/acme_http_challenge: WARNING: failed precmd routine for acme_http_challenge


The file it's complaining about not being able to read has the following permissions:

Code Select Expand


# ll /var/etc/lighttpd-acme-challenge.conf
-rw-r--r--  1 root  wheel  2522 May  2 11:34 /var/etc/lighttpd-acme-challenge.conf


When I do get it going again, even though it's green, it still shows the following in the system log:

Code Select Expand


<147>1 2022-05-02T11:34:53-04:00 OPNsense.lan config 12736 - [meta sequenceId="7"] [2022-05-02T11:34:53-04:00][error] [OPNsense\AcmeClient\AcmeClient:settings.UpdateCron] Related cron not found.{23b7041f-6697-456f-9a42-4bfff087f806}


There is, however, an active cron job scheduled for ACME in the OPNsense web UI cron settings.

I know there's a broader discussion underway about which folders under /var should be allowed to be on tmpfs and which ones shouldn't. I assume this is part of that conversation (i.e. whether /var/etc should be on tmpfs or not).

[Grossartig]

Still an issue in 22.1.7

EDIT: Bug report filed at https://github.com/opnsense/plugins/issues/2979

[Grossartig]

Franco, c'mon man, really love OPNsense but that response of yours to my bug report just puzzles me. I spent time filing a legitimate, detailed bug report and the checkboxes you are saying I omitted are usually optional in most other projects' GitHub bug reports and are meant to merely ensure the author acknowledges to himself that all of those statements are true, not to the public. And I did that.

https://github.com/opnsense/plugins/issues/2979

And I wasn't complaining to you, but to a bot, so you shouldn't take it personal that I didn't like the bot's response.

I'll leave this here regardless. It's a detailed bug report. If no one else has this problem with the /var on tmpfs filesystem, just ignore it. I won't file it a second time. Off to work now.

[franco]

First time for me to close a discussion with a bot as "too heated" to be honest. ;)

The general rule is please use the full template so we can look at it. Some people don't bother at all and it's hard to communicate with them anyway. The raised bar for complete submissions tries to do this and does so most of the time.

In practice /var MFS has always been a terrible and deceiving concept: most of persistent /var content needs to be moved elsewhere with trickery and that leaves /var/log as the real reason why /var MFS exists... and there are more issues with it now that circular logging has gone:

https://github.com/opnsense/core/issues/5727

I would favour ditching /var MFS for /var/log MFS which would solve this situation pretty easy and doesn't lead maintainers of plugins to wonder why they have to work around this silly historic option if they even can since most of it is worked around in core alone and /var is simply a clean slate after boot.

For the time being advice that would be given in business support: don't use /var MFS if it causes these types of problems.


Cheers,
Franco

[Grossartig]

Thank you for the kind response and point taken on the template -- I will submit it 100% complete next time.

Regarding the whole /var on tmpfs discussion, yes, I have seen it being mentioned in various other threads and concluded that some changes will be forthcoming on this in the future.

This is by no means an urgent issue of course.

Thanks

P.S.: Yes, main reason for me to enable /var on tmpfs is for logging. So I, too, would favor just putting /var/log on tmpfs instead of the entire /var tree.

[franco]

We will be discussing this tomorrow internally on how to proceed with /var MFS so thanks for your input on why you enabled it. It will help with the decision moving forward for sure. :)


Cheers,
Franco