I really want to get rid of the `executor' process hack for CGI scripts
and its escalation to allow fastcgi and proxying to work on non-OpenBSD.
This drops the CGI support and the `executor' process entirely and is
the first step towards gmid 2.0. It also allows to have more secure
defaults.
On non-OpenBSD systems this means that the sandbox will be deactivated
as soon as fastcgi or proxying are used: you can't open sockets under
FreeBSD' capsicum(4) and I don't want to go thru the pain of making it
work under linux' seccomp/landlock. Patches are always welcome however.
For folks using CGI scripts (hey, I'm one of you!) not all hope is lost:
fcgiwrap or OpenBSD' slowcgi(8) are ways to run CGI scripts as they were
FastCGI applications.
fixes for the documentation and to the non-OpenBSD sandboxes will
follow.
add_mime nows allocate dinamically copies of the passed strings, so
that we can actually free what we parse from the config file.
This matters a lot especially with lengthy `types' block: strings that
reach the internal mapping are never free'd, so every manual addition
is leaked.
it doesn't make any sense to keep the proxying info per-location:
proxying only one per-vhost. It can't work differently, it doesn't make
sense anyway.
Add to gmid the ability to forwad a request to another gemini server and
thus acting like a reverse proxy. The current syntax for the config
file is
server "example.com" {
...
proxy relay-to host:port
}
Further options (like the use of custom certificates) are planned.
cf. github issue #7
Currently dogfooding this patch at gemini.sgregoratto.me. To test,
run the following command and look for the "OCSP response" header:
openssl s_client -connect "gemini.sgregoratto.me:1965" -status
This adds a barebone dumping of the parsed configuration. It is not
complete, but I'm interested in dumping the full path to `cert' and
`key' in order to write some scripts that can inspect the
configuration, extract the certificates and renew them when expired
automatically.
It's not easy to parse gmid configuration otherwise because the syntax
is flexible and users can use macros. Instead, the idea is to run
gmid and let it dump the configuration once it's been parsed in a
static and predictable format.
Now is possible to parse gmid configuration with, say, awk or perl.
It's not intuitive to print
open ... for domain xyz
it doesn't convey that the open failed.
now it appends the error string, at least the user can understand that
something went wrong.
reported by cage on irc, thanks!
FastCGI is designed to multiplex requests over a single connection, so
ideally the server can open only one connection per worker to the
FastCGI application and that's that.
Doing this kind of multiplexing makes the code harder to follow and
easier to break/leak etc on the gmid side however. OpenBSD' httpd
seems to open one connection per client, so why can't we too?
One connection per request is still way better (lighter) than using
CGI, and we can avoid all the pitfalls of the multiplexing (keeping
track of "live ids", properly shut down etc...)
There's no difference, but bzero(3) says
STANDARDS
The bzero() function conforms to the X/Open System Interfaces option of
the IEEE Std 1003.1-2004 (“POSIX.1”) specification. It was removed from
the standard in IEEE Std 1003.1-2008 (“POSIX.1”), which recommends using
memset(3) instead.
so here we are.
Initialize the logger as soon as possible and log by default to
stderr. With this, some (common?) errors are printed early instead of
ending up in syslog.
# NB: this is in configless mode
% ./gmid -p 80
[2021-07-07 11:05:57] bind: Address already in use
% ./gmid -p 81
[2021-07-07 11:13:53] bind: Permission denied
%
we need to delete the events associated with the backends, otherwise
the server process won't ever quit.
Here, we add a pending counter to every backend and shut down
immediately if they aren't handling any client; otherwise we try to
close them as soon as possible (i.e. when they close the connection to
the last connected client.)
GMID_VERSION follows the CGI/FastCGI style, i.e. project_name/version.
Define GMID_STRING with a more "human" variant "project_name version",
and reuse that in the --help and --version codepath.
the logger process now can receive a file descriptor to write logs
to. At the moment the logic is simple, if it receives a file it logs
there, otherwise it logs to syslog. This will allow to log on custom
log files.
it's not technically required, since a couple of lines below we free
whole host struct, and we don't have code that may use
h->{env,aliases} afterwards, but it's nice not to have invalid
pointers around. it may bite in the future.
Not production-ready yet, but it's a start.
This adds a third ``backend'' for gmid: until now there it served
local files or CGI scripts, now FastCGI applications too.
FastCGI is meant to be an improvement over CGI: instead of exec'ing a
script for every request, it allows to open a single connection to an
``application'' and send the requests/receive the responses over that
socket using a simple binary protocol.
At the moment gmid supports three different methods of opening a
fastcgi connection:
- local unix sockets, with: fastcgi "/path/to/sock"
- network sockets, with: fastcgi tcp "host" [port]
port defaults to 9000 and can be either a string or a number
- subprocess, with: fastcgi spawn "/path/to/program"
the fastcgi protocol is done over the executed program stdin
of these, the last is only for testing and may be removed in the
future.
P.S.: the fastcgi rule is per-location of course :)
Omar Polo
Stephen Gregoratto