Access_by_lua_block and certbot

Feature Requests
1

So I finally figured out the cryptic

Could not parse file: /etc/nginx/conf/nginx.conf due to Expected stringEnd, found 'h'

error and it's this apparent decision to not support Lua...and indirectly openresty.

Any chance of a reevaluation of this? Can't think of why you can't just ignore those blocks. Perhaps it's obvious to others but this occurs not just with init: also occurs with access_by_lua_block .

2

Could you please provide a little more context about the problem you’re having? For example, is this with Certbot, or some other client? (Although Certbot is popular, this forum covers everything Let’s Encrypt, including at least dozens of clients.)

4 Likes
3

I'm sorry for the lack of detail. This is certbot with nginx plugin.

Here's a related link: BUG! init_by_lua_block and certbot

4

It's probably a better idea to request these kind of things on the Certbot github repository @ GitHub - certbot/certbot: Certbot is EFF's tool to obtain certs from Let's Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol., as the Certbot ACME client has been handed over from Let's Encrypt to the EFF a lot of years ago already.

Please search for an existing issue before opening a new one first.

@JamesLE Maybe About the Feature Requests category should only mention the LE CA? The post from 2015 still mentions the "the Let’s Encrypt client" from when Certbot was still called letsencrypt I guess.

3 Likes
5

You should be able to use --webroot method. That does not parse the nginx config. It just relies on placing a file in your root folder for that domain.

3 Likes
6

Certbot uses a 3rd party C library, Augeas, to parse Configuration files for Apache and Nginx. Augeas is fully capable of parsing vanilla/standard configuration files, but is incapable of correctly parsing - or even paring at all - advanced files that bring in dynamic language processing (such as mod_perl under Apache and OpenResty under Nginx). I have an open ticked to detect and notify users of this - see Detect and Notify Users about Incompatible/Not-Fully-Compatible Apache Modules · Issue #9558 · certbot/certbot · GitHub

The odds of support for these files happening is pretty much Zero. Like mod_perl, OpenResty brings in a lot of new custom directives, interpolates the text configuration with code blocks, and even changes how existing directives are processed. Correctly parsing those things would require an enormous development effort, and it would still get a lot of things wrong.

IMHO, the best way to handle this would be to run Certbot in standalone mode on a higher port -- such as 8081 via the --http-01-port=8081 command, then proxypass your traffic from /.well-known/acme_challenge/ onto the Certbot server.

4 Likes
7

This is also officially unplanned in Certbot , with a decision to best attempt to notify the user with a message : see nginx: support *_by_lua_block directives · Issue #9066 · certbot/certbot · GitHub

4 Likes
8

@jvanasco I don't think Certbot uses Augeas for nginx, just for Apache.

2 Likes
9

You are right. Thanks for the correction. It's an internal parser, which makes support even less likely. The blocks are supposed to be ignored, so the OP's config file probably misses one of the regexes or parser tokens.

3 Likes
10

that got reverted because it caused nginx parsing 3x slower

4 Likes
11

I think some of these are provably impossible to parse correctly in every case ("formally undecidable" in Gödel's phrasing). The developers may not have thought about what they were giving up by increasing the power and expressiveness of the configuration languages with actual executable code.

For example, you might be able to make a web server configuration which displays the answer to an unsolved math problem... by doing a potentially infinitely-long search to see if any number is a counterexample, from inside the web server configuration. The web server might take infinitely long to start up if there's no counterexample, and a configuration parser might also take infinitely long to parse the configuration in that case. :slight_smile: [in practice the computer can't actually represent numbers larger than some practical memory limit and so it would eventually get some kind of integer overflow or out-of-memory behavior, but maybe inconceivably far in the future]

2 Likes
12

100% agreed. (sidenote: now I want to re-read Gödel Escher Bach again)

IIRC, some of the Apache mods allow you to define and interpolate variables into the directive names. i.e. you could potentially have a block that is:

<$var1>
    $var2 = "/path/to/";
</$var1>

I spent 10+ years on mod_perl, mod_python, and some others before going all-in on nginx -- and then OpenResty, so I have seen many weird and wonderful things in this time.

4 Likes
13

If you don't have recursion or unbounded loops, systems with variable assignment and substitution can still be decidable.

Although if you allow conditionals that refer to external I/O or anything else that's not determined in advance, it's infeasible to determine whether an arbitrary condition is never, sometimes, or always taken. (And even where you can determine that the theoretical answer is "sometimes", it's possible that the actual inputs will be such that the practical behavior will be either "never" or "always"!) I don't remember what existing parsers do about that problem!

3 Likes
14

though about doing Plain string search for find Lua commands in that, but we can't know what will be included before we parse that file, right?

3 Likes
15

Yes. Good catch. A decent fallback would be a simple string match for the lua blocks (not the pricey regex), but the include could be dynamically generated and thus never searched.

2 Likes
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.