Closed xparq closed 6 months ago
I think you either need to use an absolute path for the config file or put it in refer to it relative to the web directory.
(Task Manager? What's wrong with ps
?)
I think you either need to use an absolute path for the config file or put it in refer to it relative to the web directory.
Abs. paths are hopefully not required for this, and they indeed don't appear to be: both options work fine separately with rel. paths.
The config path and the "home" path should be treated independent from each other, because they (mostly) are.
If that "home" dir wasn't just a sad misnomer (from upstream) with the actual meaning of "web root", but had they meant something like "installation root" (closer to the usual meaning of a "home" dir), then there could be a valid case for coupling the -c and -h paths by assuming some default fs layout, when using relative paths. But -h
is not that, it's just the web root.
Also (as --help kinda also suggests), the natural option "precedence" is -c
-h
, as the web root could be specified in the config (at least in theory), so -c
should depend on -h
even less.
\
\ Just looked up: seems to be a thing IRL. Good. Also, they do seem to call the -h path "server root" in the config... :)
Also, having the config -- god forbid -- inside the web root (-h dir) is something I would be to prude to consider... (even though that's exactly the impression one might get from the --help output).
Nevertheless, I still tried some permutations trying to guess an assumed config dir location (if any) relative to the web dir, but had no luck. (Sorry, no records of those (pretty quick & random) attempts.)
I'll keep trying a little more then. :) But I think the case in the initial comment should still work regardless.
(Task Manager? What's wrong with ps?)
(Hehe, it's just that I'm mostly on Windows, and the super convenient Ctrl+Shift+Esc
is already bound to TaskMan by default (and is in my muscle memory). Poor little ps
would need some extra love & effort from daddy to be run. Also, TaskMan just keeps refreshing, once started, so a proper alternative would be top
in a separate window, which is even less competitive with that Ctrl+Shift+Esc
.
BTW, the reason I mentioned it by name was just to preemptively answer the potential question "What do you mean doesn't start?" :) )
Oh, OK, I've found a mental model to salvage the situation: -h
has a secret double life, meaning both the web root, and also some abstract "installation root", where the config file is supposed to be, and then the config is supposed to override -h to actually set the real web root!...
Haven't tested it yet, but I wager it'll work. It's weird though, all that should be trivially achievable just by the cmdline options alone, which are (supposedly) perfectly well equipped for that already.
The intent seems to be that there should be a main configuration file and, optionally, configuration files in each directory being served. The per-directory configuration files restrict what can be set: they don't affect the web root, for example, but they allow per-directory passwords to be set up.
When the server starts it initially sets home_httpd
to the current working directory. This will be an absolute path. If the -h
option is provided it will override that default setting and, per the comment mentioned elsewhere, if it's a relative path it will remain so.
The server then does chdir(home_httpd)
and tries to read the main config file.
-c
option it uses /etc/httpd.conf
.-c
option has been given it'll use whatever path has been provided.
home_httpd
to be changed and perform chdir(home_httpd)
to change the current directory. Normally a per-directory config file isn't allowed to do that.When the server is forked to handle a request it remains in the web root directory and tries to read a config file from the directory containing the file to be served.
Of course, it's also possible that the Windows implementation gets some of this wrong.
Thanks a lot for the insider details, Ron! This can be closed as "not planned" then, I suppose.
The question mentioned in that "comment elsewhere" is still up though, so if you happen to know, still interested why relative -h
paths are not normalized. E.g. is there a use case where the -h
path may get appended to some other (rooter) root explicitly in the busybox code?
If you're satisfied the code is working as intended (leaving aside whether it's sensible for it to work like that) then this issue can be closed.
The other question requires further investigation. If/when I have anything to report I'll do that on issue #266.
I may be doing something wrong, but
and
both start OK, but
Doesn't.
I'm not sure if there's a log somewhere, but no error is printed. The server process just doesn't show up in Task Manager (Win10/64).
BTW, the config file is this one line, just to have sex with the new CGI script interpreter feature: