2
Caddy seems to good to be true? I just set it up and it works perfect, straight out of the box (alien.top)
submitted 2 years ago by [B] to c/main@selfhosted.forum
63 comments fedilink hide all child comments
 

This seems too straightforward, what's the catch?

Like how secure is it? Should I be turning it off (and disabling the port forwarding) when not using it?

Do I need any additional security? Mainly just want to use it for Jellyfin

Thanks

you are viewing a single comment's thread
view the rest of the comments
[–] [B] 1 point 2 years ago (1 child)

Totally agree.

The main problem is it's all written as a reference -- for people who already understand what/how, who need to just refresh their memory of the actual syntax.

There's very little explanatory stuff for people who need more than that. I had to read the same stuff multiple times, traversing many (or often, the same!) links, make notes, and then form a mental picture of what is going on.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [B] 1 point 2 years ago (4 children)

    Caddy maintainer here, if you could point to specific sections you find confusing, that would help. We rarely receive actionable feedback about the docs, so it's hard for us to make improvements.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] [B] 1 point 2 years ago (1 child)

    at the moment my caddy setup is stable; I am recounting my experience from memory.

    It may be useful to consider what I said in a broader perspective -- i.e., what you have is an excellent reference but it does not help discovery of task-oriented solutions.

    Sorry I am unable to express the problem better than that. Will keep an eye out in future if I can get more concrete and open an issue or something.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [B] 1 point 2 years ago (1 child)

    😬 Well, that's not helpful. Without specific feedback, there's nothing we can do to improve the docs. It's exhausting to read vague complaints about the docs, because it's 90% of the feedback we get.

    But yes, please do reach out (open a GitHub issue, comment on the forums etc) if you do notice something that doesn't meet your expectations in the docs.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [B] 1 point 2 years ago (2 children)

    What I think they meant is more “how to achieve X or Y” focused documentation, rather than just explaining how features A or B work. The former approach explains what you should use and how to do it, the latter only documents what each variable does.

    To use an analogy: I could probably build a bicycle from the individual parts based on a tutorial with that goal in mind, but not based on the individual technical descriptions of each part.

    /u/xkcd__386 is that what you meant?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [B] 1 point 2 years ago (2 children)

    I understand what they meant, but it's broad/vague, and not specific/actionable.

    We do have a tutorials section in the docs, and we have the https://caddyserver.com/docs/caddyfile/patterns page which are that.

    Our question is how are those lacking? Just saying "more please" doesn't help because we don't know what the need is. We can't imagine every single possible usecase, because it's actually infinite. Caddy is a "general purpose webserver" which means "it can do just about anything".

    Help us by telling us what specifically what usecase is important to you. We don't have telemetry, we need users to tell us.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [B] 1 point 2 years ago

    The tutorials section is very basic; I am not talking at that level. The patterns page is closer to the level of complexity that one needs help with, and it does cover several items, but you have 30-40 directives, many with several options, global options, and so on, so there're bound to be gaps.

    In the other comment you said this is "90% of the feedback we get", and I can certainly understand the frustration -- people want documentation to magically solve their specific problem quickly, without having to read anything extraneous to it, which is clearly impossible.

    As I said before, I'll keep it in mind next time I need to do something if I can't find it easily in the docs I'll at least highlight the effort it took, what I searched/read/found, etc., so you have something concrete.

  • permalink
  • fedilink
  • source
  • parent
  • [–] [B] 1 point 2 years ago (1 child)

    Something I encountered last week.

    • wanted to test running caddy without https and without being open to the world, to turn off automatic https.
    • Googled and came up with auto_https off documentation that I read.
    • It did not work, http still did not work
    • Googled more and landed on forum page that explained why auto_https is not working and that it needs explicitly stated http:\\ or port :80 in the address. Otherwise caddy will listen by default for only https.

    It was no biggie, that forum post is literally the second google result for auto_https and does good job, but you asked and I have it fresh in memory...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [B] 1 point 2 years ago

    Thanks, that's helpful. Yeah the docs for auto_https should explain up-front that this only affects the feature called "Automatic HTTPS" and does not change the default port/procotol of Caddy, which is always HTTPS unless otherwise specified (i.e. by using http:// as a site address prefix, or :80 as a suffix).

  • permalink
  • fedilink
  • source
  • parent
  • [–] [B] 1 point 2 years ago

    I found the practical use cases helpful, probably should expand that cookbook.

    E.g. I've found this sort of construct helpful (not sure how safe using {host} here is though):

    app.example.com, another.example {
   reverse_proxy unix//srv/backend/{host}/server.socket
}

    It is hard to understand the whole thinking behind the config system, with directives, matchers, placeholders, invisible reordering of rules, and all the other concepts. And to add to the complication, Caddyfile and API are completely distinct systems and it is not very clearly explained [that one really ought to be using Caddyfile and ignoring the API for most use cases]. And that distros do ship Caddyfile-based systemd service now (some also API-based, and perhaps with root-only control socket to add to the confusion).

    I did dig into it to really understand how it works but that took a couple of weeks to digest, which is a lot for someone who only needs a simple server/proxy.

  • permalink
  • fedilink
  • source
  • parent
  • [–] [B] 1 point 2 years ago (1 child)

    One thing that threw me in the beginning was that the docs didn't show examples in context. As an example, if you look at the basicauth docs it shows:

    basicauth /secret/* {
	Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
}...
}

    Where can I use this? Globally? In the top-level of the virtualhost definition? If I'm reverse proxying, do I put it inside the reverse_proxy stanza? I used Apache for years and the docs always stated what context directives could be used in, eg.

    https://httpd.apache.org/docs/2.4/mod/core.html#acceptpathinfo

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •