Caddy 2 app

[mholt]

I remember hearing about this project a while ago, and I think it's really cool! I like that it's inspired by CoreDNS, which is inspired by Caddy.

Caddy v2 is almost ready, and has greatly improved support for serving things other than just HTTP. It'd be great to see a DHCP app for Caddy 2!

Caddy 2 apps inherently benefit from a real-time, on-line configuration API and automatic config documentation so you won't have to worry about those parts. Basically you just make your structs, bring over the DHCP server logic, and then wire it up to Caddy (~20 lines of code).

I think it makes a lot of sense for this to be a Caddy plugin. Let me know if I can help in any way!

[insomniacslk]

Hello Matt! Thanks for opening this issue, CoreDHCP actually started as a Caddy plugin (since I'm a big fan and user of Caddy), but at that time I think the framework was not mature enough (or I didn't understand it well enough), and I felt I was not getting enough benefits from making it a Caddy plugin.

While I don't think we have a lot of bandwidth at the moment (this is a side project for all of us), I am interested in re-evaluating CoreDHCP as Caddy plugin. We are currently redesigning the configuration format to be more declarative and user-friendly (see #89). If you see my proposal on the gist linked on the issue, you may notice that I had the Caddyfile syntax in mind, so this may come next after agreeing on the syntax.

Thanks for offering to help! We will surely ping you here once we agree on the path forward.

[insomniacslk]

CC @pmazzini @Natolumin @mdlayher

[mholt]

@insomniacslk That's excellent! I can understand why Caddy 1 was not ideal, but in Caddy 2 I've made sure to give "apps" (as I call them; these are top-level, long-running modules which may even have their own Caddyfile structure) first-class priority. Your DHCP server can look like this in Caddy's native JSON config:

{
    "apps": {
        "dhcp": { ... }
    }
}

You'd want to expose as many config parameters as you want in the JSON, since it's meant for full flexibility, and programmable/advanced use cases. You won't have to worry about the config API or documentation, they come for free (docs via godoc comments, can be added to website).

You can also write a config adapter to support the Caddyfile structure. The Caddyfile adapter just converts the Caddyfile to JSON.

Right now, in Caddy 2, we call it the "Caddyfile" when it refers to an HTTP server, since that's what most people use it for. Sometimes I call it the "HTTP Caddyfile" in the docs. But CoreDNS calls theirs the "Corefile" -- so, if you want to call it a Caddyfile, maybe "DHCP Caddyfile".

The HTTP Caddyfile adapter is plugged in like so: https://sourcegraph.com/github.com/caddyserver/caddy@v2/-/blob/caddyconfig/httpcaddyfile/httptype.go#L33

The token parsing will be taken care of for you, you just need to write the Setup function that decides how to interpret the parsed structure.

With that implemented, the DHCP Caddyfile can then be used for the 90% of use cases where people want an easy configuration for simple setups. They can always drop down to JSON if they need more flexibility.

Note that the HTTP Caddyfile was designed to be highly extensible (custom directives, etc.) -- and admittedly, it's a little complex to do all that, but if you're set on doing that for the DHCP Caddyfile, I can guide you through it. Just expect it to be more of an undertaking.

Anyhow, Caddy 2 sounds like the perfect fit for your proposed changes/rewrite! I'll be here to answer your questions.

[ppacher]

Hi,
I started a similar project (nextdhcp) this summer and implemented a DHCPv4 server type based on Caddy 1 and similar to CoreDNS. Unfortunately I didn't found CoreDHCP earlier and as I mostly needed a DHCPv4 server I focused on that project for now. Since developing 2 DHCP servers that are inspired by Caddy and CoreDNS seems overkill I'd be happy to help out on a Caddy2 server type as well.

[mholt]

@ppacher Sounds awesome, that would be great!

[mholt]

Still think this would be awesome btw 🙃