Caddy: Command-line parameter to turn TLS off please?

[ekkis]

1. What version of Caddy are you running (caddy -version)?

latest version

2. What are you trying to do?

turn TLS off from the command line

3. What is your entire Caddyfile?

<not relevant>

4. How did you run Caddy (give the full command and describe the execution environment)?

caddy -tlsoff

5. What did you expect to see?

that caddy would turn tls off

6. What did you see instead (give full error messages and/or log)?

the syntax error: "flag provided but not defined: -tlsoff"

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

yes

[wendigo]

Why do you need to turn off TLS from the command line? It can be turned off using Caddyfile

[krishamoud]

TLS off examples

1.

http://www.example.com {
  ...
}

2.

www.example.com:80 {
  ...
}

[ekkis]

I'm attempting to use caddy from a docker container that manages the Caddyfile and I don't have access to it. what I do have access to are the command-line parameters to the executable.

for development purposes I want to turn TLS off since I'm testing with entries in my /etc/hosts file and thus the domains I'm using don't actually exist, which causes problems with the Let's Encrypt, ergo my request.

it should be a big deal to add this parameter and it would make external control of caddy more complete

[mholt]

Did you know you can pass the Caddyfile in through the command line? There's two ways. https://caddyserver.com/docs/cli - scroll down to "Short Caddyfile" and "Pipe a Caddyfile". That should be what you want. :)

[ekkis]

right, but I can't pass it to the docker container. the software in the container manages the creation of the Caddyfile via docker-gen

[mholt]

I thought you said you had control of the command line arguments of the executable.

[ekkis]

I do. command-line parameters are specified in an environment variable that the container reads upon instantiation, but a reference to a local file would be meaningless to the container, which has its own local file system. so I could pass -tlsoff but -conf /etc/caddy.conf would refer to a file in my local filesystem, which the container would not have access to

[mholt]

Did you even read the "Short Caddyfile" section? No file required.

[ekkis]

yes, of course. but I'm not quite sure I would use it because I would need to include the tls off directive in each entry of the Caddyfile that the container generates for me

[mholt]

Since the command line options are for 'global' configuration, and TLS is a per-site configuration, you're better off figuring out how to get the short caddyfile or piped caddyfile methods to work for you.

[ekkis]

but what I'm suggesting is that for development purposes, having a global configuration parameter would be most useful. I would want it to apply to all sites defined, unless a given site overrode the global definition. you do understand that for testing one would want to create names in the /etc/hosts file and that use of such names would fail the TLS mechanism right? I may not have a domain name that I can use for testing yet but I can manufacture it in the /etc/hosts file. this serves my purposes during development and having a way to make caddy work under such conditions would be very useful

[mholt]

I frankly don't want to make it that easy to disable TLS. It's already too easy.

I figure if you're automating the generation of these hostnames and stuff, you can just as easily automate the generation of the Caddyfile that adds a "tls off" where you need it.

[ekkis]

ok. in that case I would need to lobby the author of https://github.com/BlackGlory/caddy-proxy instead, but why not turn TLS off? it's a great feature during development

[mholt]

Because people will use it in production.

[ekkis]

sure, and if that's what they want to do it should be up to them

[elcore]

@ekkis

sure, and if that's what they want to do it should be up to them

There is no excuse not to use TLS in production.

[ekkis]

I don't disagree but that's not a decision that we should be making

[elcore]

I don't disagree but that's not a decision that we should be making

I will never agree to you!

Have a nice day @ekkis