I know someone who listened Terry Pratchett's "Wachen! Wachen!" audiobook on Spotify while living in Germany for few years. It was so well narrated that he also acquired some peculiarities of local dialects used by specific characters in the book. Locals in Bavaria were quite surprised of a foreigner speaking such language.
This is probably technically out of scope for this article. Long-running processes that respond to SIGHUP will usually be running detached (with no controlling TTY). Thus it is a bit of stretch to call them "terminal programs".
This behavior seems difficult to actually implement in practice, no? Your application has to be careful not to accidentally cache any configuration state, as well as any state derived from the configuration, otherwise it will go out of sync. Maybe easy for trivial apps but most apps requiring configuration files are non trivial.
Thanks, need to make the docs less verbose in some places :-)
https://clace.io/docs/configuration/authentication/ lists the supported auth mechanisms for apps. A builtin system account is the default. The OAuth providers supported are : github google digitalocean bitbucket amazon azuread microsoftonline gitlab auth0 okta oidc. Any other provider supported by https://github.com/markbates/goth can be easily added, with a small code change.
For admin operations (creating/updating apps) using the client CLI, a unix domain socket is used. No other auth is used for UDS other than the file system level permissions. A REST API for admin operations can be optionally enabled, in which case it will use the system account https://clace.io/docs/configuration/security/#admin-api-acce....
Client cert based auth is not supported currently. Were you wanting that for app access or for admin API access?
In terms of performance, I did some testing few months back. The app access API does not hit the database (sqlite), everything is cached after the first call. So the performance will be limited by the API performance of the downstream container. The Clace server itself should not be a bottleneck. First API call to a containerized app builds the image and starts the container. That depends on how fast the image build and container startup are.
The client cert based auth would be for the app access.
Our use-case is review apps, i.e. <some-feature>.example.com should only be accessible by users with a valid client cert. Currently we use Caddy, but I'd like to give clace a shot for this. :)
[1]: In both senses of the word.