Deployment questions

Deployment questions

From: Lydia Sobot
Hi, I was wondering the following 2 things when reading through the README to deploy scooper on my system:
1) what was the reasoning behind vendoring SQLite when that means that
the vendored version will lag behind the system version used by
litterbox? Is it still necessary?
2) does slowcgi from OpenBSD base not work for some reason given the
specific chroot and socket setup required given that httpd runs under
www:www and litterbox usually runs under your own user?

Thanks in advance and loving your software ❤️

P.S.: it might be useful to cut a release with the manpage updates for
replacing catsit with kitd to avoid package maintainers having to
backport a patch for that

Re: Deployment questions

From: june
> On Oct 1, 2025, at 16:56, Lydia Sobot <chilledfrogs@disroot.org> wrote:
> 
> Hi, I was wondering the following 2 things when reading through the README to deploy scooper on my system:
> 1) what was the reasoning behind vendoring SQLite when that means that
> the vendored version will lag behind the system version used by
> litterbox? Is it still necessary?

I decided to vendor sqlite so that scooper could consistently be
statically linked. I think FreeBSD stopped building libsqlite3.a
in their port and I cared about that at the time.

> 2) does slowcgi from OpenBSD base not work for some reason given the
> specific chroot and socket setup required given that httpd runs under
> www:www and litterbox usually runs under your own user?

yeah, that's why it's more convenient to run it with kfcgi(8).

> Thanks in advance and loving your software ❤️
> 
> P.S.: it might be useful to cut a release with the manpage updates for
> replacing catsit with kitd to avoid package maintainers having to
> backport a patch for that

yeah a lot of my projects could probably use new releases... I'll
get around to them eventually maybe.

Re: Deployment questions

From: Lydia Sobot
To: june
> I decided to vendor sqlite so that scooper could consistently be
> statically linked. I think FreeBSD stopped building libsqlite3.a
> in their port and I cared about that at the time.
Makes perfect sense, however then maybe it should be bumped to the
latest release of SQLite?

>> 2) does slowcgi from OpenBSD base not work for some reason given the
>> specific chroot and socket setup required given that httpd runs under
>> www:www and litterbox usually runs under your own user?
>
> yeah, that's why it's more convenient to run it with kfcgi(8).
Fair, but considering that unless I missed something obvious, slowcgi(8)
also has the ability to switch to a different user and put the socket
and chroot at an arbitrary location, just like kfcgi(8), so are there
other subtleties that make it break with slowcgi(8)?

> yeah a lot of my projects could probably use new releases... I'll
> get around to them eventually maybe.
Great~

Re: Deployment questions

From: june
> On Oct 5, 2025, at 19:18, Lydia Sobot <chilledfrogs@disroot.org> wrote:
> 
>> I decided to vendor sqlite so that scooper could consistently be
>> statically linked. I think FreeBSD stopped building libsqlite3.a
>> in their port and I cared about that at the time.
> Makes perfect sense, however then maybe it should be bumped to the
> latest release of SQLite?

yeah I guess so.

>>> 2) does slowcgi from OpenBSD base not work for some reason given the
>>> specific chroot and socket setup required given that httpd runs under
>>> www:www and litterbox usually runs under your own user?
>> 
>> yeah, that's why it's more convenient to run it with kfcgi(8).
> Fair, but considering that unless I missed something obvious, slowcgi(8)
> also has the ability to switch to a different user and put the socket
> and chroot at an arbitrary location, just like kfcgi(8), so are there
> other subtleties that make it break with slowcgi(8)?

as far as I know it would work fine with slowcgi(8) if it was
configured properly. I just haven't run it that way.

> 
>> yeah a lot of my projects could probably use new releases... I'll
>> get around to them eventually maybe.
> Great~