website-pictures2

The World's Worst Way To Do This

What

What I Did Before

My website is not hosted locally and my server is perpetually running out of space (actually, this is not true anymore???)

website-pictures1 used GitHub to host compressed and encrypted JPGs that would then be cloned on a cloud server (OCI free tier 🙏) and built into a static site. This model was based around assuming the following:

1. I don't want people to see these pictures without fist being authorized
   • i.e. HTTP Basic Auth
2. I do not trust GitHub to hold my pictures in an unencrypted format (follows from 1)
3. Ramiel was the sole source of truth for building the picture directories and
4. the cloud server was responsible for building the static pages.

That Was Bad, Actually

The previous model was lame because:

1. If I do not have access to Ramiel, I can't do anything
   • it was all symlinks oh my god
2. it was literally shell scripts
   • ok, no diss to shell scripts, these in particular were actually super manageable.
   • the problem is that expanding them to do more sucks bigly
3. key point: I never added more pictures because it was a Huge Pain

What I Will Be Doing Now

I've just confirmed that bigrack has more than enough space to do the following:

1. Store pictures compressed, locally
   • you can just add to a 7z archive whenever, so uncompressed images need not exist more than transiently
2. Build a static page, locally
   • big if true: imagine being able to debug without doing a full rebuild on your server
3. Deploy the static page to shrimplover
   • no like seriously why do I pick hostnames like this

How

python or something idk

Usage

Archive management

python main.py archive add -a PATH_TO_ARCHIVE -p FOLDER_NAME_ON_WEBSITE [Files to add]

Deployment

python main.py deploy -a PATH_TO_ARCHIVE SSH_HOST PATH_ON_REMOTE_TO_PICTURES_DIR