~dricottone/huttese

cca3438daed384a0d00059775881a964b69ddeb0 — Dominic Ricottone 1 year, 6 months ago 2d2a6f6 dev
Final
1 files changed, 6 insertions(+), 50 deletions(-)

M README.md
M README.md => README.md +6 -50
@@ 1,57 1,13 @@
# huttese

Sourcehut is only officially supported on x86 Alpine Linux.

I say **challenge accepted**.
This repo walks through the process of running Sourcehut within containers (either `docker` or `podman`, possibly other runtimes as well) and even on ARM processors.
See the [huttese-apk project](https://git.dominic-ricottone.com/~dricottone/huttese-apk).


## Usage

Locate all the `*.changeme` files and add your own information in place of my redacted information.

Select the recipes for your container runtime: `Makefile.docker` or `Makefile.podman`.
`ln -s Makefile.selection Makefile` to get going from there.

Select the image for your architecture: `Dockerfile.x86` or `dockerfile.aarch64`.
`ln -s Dockerfile.selection Dockerfile` to proceed.

Note that hosting on an ARM machine will additionally require building the APKs.
See huttese-apk for more information.

Run `make setup && make image && make dbinit && make start`.
Then `USER_NAME=admin USER_EMAIL=admin@example.com make addadmin` to setup an admin account.
Consider also `USER_NAME=me USER_EMAIL=me@example.com make adduser` to setup non-admin accounts.
Then `make shell` and `passwd git` to enable SSH access to git.

For subsequent use, run `make image && make dbmigrate && make start`.

Or to just restart the service if stopped (as by `make stop`), try `make restart`.

To clean up the main container, use `make clean`.

To clean up all containers, use `make clean && make cleanup`.
If you even want to throw out the postgres database, try `sudo rm -f pg/datadir`.


## To-Do

There are cron jobs involved with administration:
 + `gitsrht-periodic` runs `git gc` to save storage
   + it also syncs S3 storage, which does not matter here
 + `metasrht-daily` expires audit logs to save storage
   + it also processes payments for billing, which does not matter here
I should look into options for running these from the host system.

`lists.sr.ht` will require handling inbound mail, which seems like a whole lot of not fun, but could be managed.

`builds.sr.ht` requires virtualization by way of qemu running inside a Docker container. Not really within scope of this project.

This is the repository for my earliest attempts at building, deploying,
and maintaining a self-hosted sr.ht environment.
My efforts are now focused on the srht* images found here:
https://git.dominic-ricottone.com/~dricottone/container-images.
I am leaving this repository public, but do not recommend using this
anymore.

## License

I am supporting this infrastructure only to the ends of maintaining my own deployment.
Good luck.
I license everything under BSD 0 clause, except for subrepositories where a different license is specified.