Is is possible to use something like a docker container running postgres/etc
for it? I noticed on the debian package it installs them itself, which is
somewhat redundant when running them in a container already.
On 5/6/21 3:22 PM, Hanna wrote:
> Is is possible to use something like a docker container running postgres/etc > for it? I noticed on the debian package it installs them itself, which is> somewhat redundant when running them in a container already.
It's presumably possible, but the sourcehut/Drew ethos is opposed to
using docker to abstract away your understanding of the stack you're
using. This is e.g. why sourcehut provides distro packages for the
services, to run sourcehut on Alpine/Arch/Debian, but does not provide
dockerfiles to run sourcehut in Docker containers.
So too, the Debian packages aren't designed to assume they depend on
your running some docker container and pointing your sr.ht configs at
its interfaces. If you want that, you could try setting it up yourself
but I don't think this community is going to help you out beyond maybe
wishing you good luck.
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
> but does not provide dockerfiles to run sourcehut in Docker containers.
I mean more of sr.ht on the host itself, while-as the database in a container,
shared across services
> So too, the Debian packages aren't designed to assume they depend on> your running some docker container and pointing your sr.ht configs at> its interfaces.
I suppose I'd probably have to manually setup the files myself so it doesn't install
everything needlessly.
> but I don't think this community is going to help you out beyond maybe> wishing you good luck.
Yeah that's one thing unfortunate thing about this community.
> you could try setting it up yourself> but I don't think this community is going to help you out beyond maybe> wishing you good luck.
Untrue. Drew once offered to help debug
our orgs sourcehut installation - I think it's disingenuous to
say that nobody here will help out - I'd certainly chime in if
I knew a thing.
That said, be warned that sr.ht is not easy to install or to
maintain. Plan on spending at least several hours per week
keeping it up to date and running into various edge cases.
We've decided that while the project is great, it's not
worth the maintenance burden to self host - and we tried for more
than a year. It requires a dedicated admin, and can't really be done
on volunteer time currently.
It's a great project and a good learning experience, but it's not
yet trivial or friendly to self host, and isn't meant to be. Yee be warned.
> It's a great project and a good learning experience, but it's not > yet trivial or friendly to self host, and isn't meant to be. Yee be warned.
Yeah was mainly curious as I run a development group and gitlab is
too heavy and bloated, there's gitea, etc but I prefer the simplicity of
sourcehut (using it at least.
On 5/6/21 5:16 PM, j3s@c3f.net wrote:
>> you could try setting it up yourself>> but I don't think this community is going to help you out beyond maybe>> wishing you good luck.> > Untrue. Drew once offered to help debug> our orgs sourcehut installation - I think it's disingenuous to> say that nobody here will help out - I'd certainly chime in if> I knew a thing.
Were you running it in docker? I said I don't believe people will be
interested in helping do it via docker -- people setting it up via the
recommended method (distro packages) do indeed get plenty of help.
It's the "docker" component that is the issue, as I don't believe anyone
is actually trying to do this, it's not particularly interesting to the
current community of self-hosters to experiment with dockerizing the
software, and hence docker-specific issues are going to get "I dunno,
prolly some weird docker thing -- good luck" rather than "I understand
the stack you're using and this is probably the problem -- try X and
report the results if it still doesn't work".
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
On Thu May 6, 2021 at 11:16 PM CEST, j3s wrote:
> That said, be warned that sr.ht is not easy to install or to> maintain. Plan on spending at least several hours per week> keeping it up to date and running into various edge cases.>> We've decided that while the project is great, it's not> worth the maintenance burden to self host - and we tried for more> than a year. It requires a dedicated admin, and can't really be done> on volunteer time currently.
That's interesting, it's really not my experience with selfhosting sourcehut.
Granted I am only using it for myself but I really don't need to maintain
it much for it to just work™.
> Is is possible to use something like a docker container running postgres/etc> for it? I noticed on the debian package it installs them itself, which is> somewhat redundant when running them in a container already.
Debian packages only have a Recommends on postgresql (and redis), so if
you don't install recommended packages (or uninstall them afterwards),
things should work fine. (Those packages could arguably be in Suggests
section.)
So if you have postgres/redis running in containers and sr.ht services
running on your vps, adjusting the sr.ht/config.ini to point to
interfaces of docker services should just work.
On Thu May 6, 2021 at 4:29 PM CDT, Nicolai Dagestad wrote:
> That's interesting, it's really not my experience with selfhosting> sourcehut.> Granted I am only using it for myself but I really don't need to> maintain> it much for it to just work™.
do you run every component? and for how long?
some services do "just work", but others
do not. The build system in particular has been a struggle to
get working in the first place, and to keep running.
# builds
the postgres work was partially documented, and required many permissions
not outlined in the docs
redis connections between masters and workers requires stunnel to function,
and stunnel fails to start on the server-side due to an alpine bug that we
haven't had the time to dive into.
getting docker + qemu + ssh to work on the runners was quirky, and adding
runner images took a lot of labor.
even on a good day with nothing going on, the workers will ocassionally
disconnect from the master if the builds they run are too heavy. some
of our workers are pretty weak machines - this is presumably why. I believe
that sr.ht uses pretty beefy machines for their workers, which could explain
why we see issues (perhaps our use-case isn't as well tested).
# git
getting ssh cloning to function properly was another hunk of labor.
there are certain paths in the git UI that result in full worker CPU utilization,
thus driveby bots were taking down the git system by scraping simple endpoints.
# lists
the lists setup is also not trivial, requiring a local SMTP server to forward specific
mail to an LMTP socket. this service has largely worked since install though.
# upgrades
upgrades largely worked, but with the new API stuff that Drew has been working on, our
install busted awhile ago and hasn't been the same since - no doubt we're missing
a single configuration option or similar - but we have other priorities.
Quite often, we would spent ~1 hour on issues that amounted to a missing line in nginx.
we found ourselves consulting the nginx package in Drew's personal repos for updates.
I would say that we have a lot of Linux and troubleshooting knowledge between the several
members of our community who maintained sr.ht, and we spent probably several dozen hours
setting it up, and further dozens of hours troubleshooting it over the last year.
that simply isn't tenable for us.
tl;dr: sr.ht requires a lot of time to setup, maintain, and debug. the documentation is
stark, so it requires a lot of diving into the code to figure out what might be
wrong. thus, it must be run by someone with motivation, time, and a deep pool of
knowledge.
that doesn't fit our use-case, but that doesn't mean it doesn't fit yours.
On Fri May 7, 2021 at 5:47 PM CEST, j3s wrote:
> do you run every component? and for how long?
I do not use the build system, and it does look like it is the hardest one to maintain.
That's probably the main difference in our experiences.
> that doesn't fit our use-case, but that doesn't mean it doesn't fit> yours.
Obviously, I am not trying to convince you to go back to it.
Thank you for sharing your experience with sourcehut it was quite informative.