I was really excited when I came across Caddy, everything seemed to be so easy and fast to set up! However, I’ve now reached a bit of a pickle.
I’m trying to create a quick CGI node.js script that can execute a shutdown on Windows, using shutdown.exe that is available in CMD and PS. When executing the script directly, it works without a problem. Executing through Caddy, however, will result in a: The system could not find the environment option that was entered.(203)
I’ve tried passing as many ENV variables as I can to the CGI script… The only shell commands that work are extremely basic ones such as cd, dir, echo, … I can spawn a new instance of CMD, PS, however, they inherit the same problem. It’s impossible to execute any executable files by absolute path, the same error applies…
This is not a problem with node. Even a simple batch script: shutdown -s -t 600 2>&1
yields the same error when viewed in the browser…
While this seems like a small thing, I understood that caddy was designed as a super-simple web server, giving you power at your fingertips with minimal configuration. Plain old CGI seems like an incredibly elegant solution to run scripts/node.js/php on demand without any additional configuration in a dirty development enviroment, but why is it so heavily sandboxed? Or am I missing something here?
A reply would be greatly appreciated! Thank you for your amazing software!
I’ve tried passing as many ENV variables as I can to the CGI script…
My guess is that there is still some variable node looks for and doesn’t find. On Unix systems, env -i is helpful to execute a command with an empty environment; variables can be added incrementally until the command runs successfully. This is generally easier than reloading the web server’s configuration over and over. I am not sure if there is something like this for Windows.
It’s impossible to execute any executable files by absolute path, the same error applies…
Even an executable that does not require environment variables besides the CGI variables that Caddy provides? If so, this indicates some other problem with your setup. Do the simple examples in the documentation work for you?
but why is it so heavily sandboxed?
Like all CGI implementations of which I am aware, the Go standard library (see host.go) executes the subprocess with an environment restricted to CGI variables. Inherited and additional environment variables need to be specified in the configuration.
I’ve tried passing as many ENV variables as I can to the CGI script…
My guess is that there is still some variable node looks for and doesn’t find.
On second thought, this is a Windows error, not a node error, so there is a shell involved, likely because node is run through a batch script. Have you specified COMPSEC as a variable to be inherited?
Thank you very much for your enthusiasm and assistance in the matter!
I managed to find the problem in the end after a good night’s sleep. The command I was trying to execute (Windows shutdown) required the COMPUTERNAME environmental variable, which is definitely an unusual one. My solution was just to brute force the problem, typing out every variable I could find set by default and slowly reducing the list, restarting Caddy each time.
Indeed, Node.js seems to start new sub-processes with a shell, inheriting everything from before. I was worried that the CGI was sand-boxing the process for security reasons and that it would be impossible to configure my intention without a separate node.js server, using caddy only as a proxy. Windows was just extremely unhelpful in not specifying that the error was occurring during the execution of the shutdown command, and not, in fact, due to it being unable to find the executable.
I would suggest adding a pass_all_env option to the CGI plugin, however I seem to have hit a very particular issue involving the shutdown command, but as the CGI plugin is meant for easy dynamic content, without the complexity or performance of a separate daemon process, it wouldn’t hurt to simplify the usage.
Thank you for your time and wisdom, I was frustrated after hours of troubleshooting, having written a script only to find out that the final intended purpose failed in the shell. It works beautifully now!
I would suggest adding a pass_all_env option to the CGI plugin
Good suggestion. Doing so would be easier if the Go standard library supported that option, but since it doesn’t, the Caddy CGI plugin would have to walk the environment and list each encountered variable. I will consider this.
Another option would be for Windows to change its error message from
The system could not find the environment option that was entered.(203)
to
The system could not find an expected environment variable. It knows the name of this environment variable but telling you would require one minute of developer time to enhance this message. (203)