rdelaage
/
gmid
mirror of https://github.com/omar-polo/gmid.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

update faqs

This commit is contained in:
Omar Polo 2024-01-05 20:06:02 +00:00
parent ac6c76f8a8
commit 6660c0bd41
1 changed files with 25 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
site/faq.gmi
View File

@ -2,9 +2,12 @@
## How can I report a bug, suggest a feature or send a patch?
Just drop an email to <gmid [at] omarpolo [dot] com> or open a GitHub issue/pull request.
Just drop an email to <gmid [at] omarpolo [dot] com> or open an issue/pull request on Codeberg or Github.
When reporting a bug please include the relevant information to reproduce the issue you're facing: your configuration file, the gmid version, and your distro.
=> https://codeberg.org/op/gmid Codeberg mirror
=> https://github.com/omar-polo/gmid GitHub mirror
When reporting a bug please include the relevant information to reproduce the issue you're facing: your configuration file, the gmid version, and your operating system or distro at least.
## How can I define the right MIME types for my files?
@ -22,54 +25,34 @@ types {
```
## CGI scripts don't work
## How to run CGI scripts?
There may be various reasons for it
As of gmid 2.0, to run CGI scripts an external program like fcgiwrap or slowcgi are needed.
* make sure the `cgi' rule in the `server' block matches the CGI script
* if using a chroot, make sure that all the libraries and executable are available inside the chroot (e.g. sh, python, perl, ...)
From the gmid side, one `fastcgi' block needs to be defined with the `socket' pointing at the fcgiwrap or slowcgi socket inside the chroot. The `SCRIPT_NAME' parameter pointing to the script path is often needed since gmid is unable to deduce the right path otherwise.
``` example configuration that runs a CGI via slowcgi
server "example.com" {
listen on *
cert "/path/to/cert"
key "/path/to/key"
## (linux) gmid doesn't seem to work / some tests are failing
gmid uses a security feature of the linux kernel called "seccomp".
Seccomp allows to define a set of allowed system calls (in layman's term "things that a program can do") and terminate the program if it attempts to do something else. While this is cool, sometimes the kernel developers may add some new system calls, or the libraries used by gmid could start using others system calls to achieve the same thing, so the seccomp filter may need adjustments over the time.
Simptoms of a possible failure due seccomp are gmid not seeming to work or hangs/failure as soon as some features of gmid (cgi scripts, reverse proxying, ...) are used.
To debug a (supposed) seccomp issue, decomment SC_DEBUG in sandbox.c
```
/* uncomment to enable debugging. ONLY FOR DEVELOPMENT */
/* #define SC_DEBUG */
location "/cgi-bin/hello" {
fastcgi {
socket "/run/slowcgi.sock"
param SCRIPT_NAME = "/cgi-bin/hello"
}
}
}
```
so that it becomes
Then, fcgiwrap or slowcgi need to be started as well.
```
/* uncomment to enable debugging. ONLY FOR DEVELOPMENT */
#define SC_DEBUG
```
then recompile gmid and run the regress suite:
## How to automatically renew the certificates?
```
$ make regress
```
It depends on how the certificate were obtained. For example, if acme-client or certbot are used they provide their own mechanism to renew the certs and restart daemons.
If it's indeed a seccomp failure it should print something like the following among the other logs:
In case of a self-signed certificate, contrib/renew-certs could help. It's meant to be scheduled periodically with cron(8) and automatically generate a new key and certificate when one is about to expire and restarts gmid.
```
unexpected system call (arch:...,syscall:... @ ...)
```
Please attach the `make regress' output, the distro you're using and `uname -m' in the bug report (either on github or via email.)
If you're technically inclined, you could also try to write a patch to fix the issue and attach it to the bug report: receiving patches makes me really happy!
You can get the syscall name from the numbers by looking in the linux kernel headers. Unfortunately, the exact position differs from distro to distro, but they should be somewhere under /usr/include. Once you know the name of the syscall, you can add it to the list in the `filter' array and reiterate the whole procedure until it works.
Providing a patch *is not expected* and *is not a requirement* either. It's just nice to do if you have the skill, time and patience to do so.
Don't forget to comment SC_DEBUG after playing with it if you're gonna use the executable.
=> TREE/contrib/renew-certs contrib/renew-certs