Sam on Nostr: The "How to set up #snac" guides linked in its readme definitely seem very helpful. ...
The "How to set up #snac" guides linked in its readme definitely seem very helpful. They certainly do provide some great examples of how to set up various parts of the server stack. However, they also make some assumptions about your system (i.e. that you have root access to the full thing) that sent me down fruitless rabbit holes while trying to set this instance up.
Specifically, I use #NearlyFreeSpeech.net for hosting my webpages. I'm sure it's not the only host which provides nearly full control over your own content, and this guide would presumably be easy enough to adapt to whatever other containerized/jailed shared server they use, but NFS.net is the first I found years ago, has a very nice pay-for-what-you-use pricing structure with (as far as I know) good rates, and if you're already looking at snac for "lightweight" or "JavaScript-free" then they follow exactly the same design mentality.
This is likely not going to be a wholly-complete guide, since I did the setup over several days and I don't want to go back through the process just to be sure I remember everything correctly. Take this all with a grain of salt, but then again if you're trying to use either NFS.net or snac, and you can't work out how to correct a non-functional/mistaken instruction, you might want to rethink your tooling.
The first step is setting up your user+account+domain+site on NearlyFreeSpeech; that's more levels than is particularly comfortable to deal with if this is the only thing you're going to need hosted, but they have a fair amount of FAQs and other documentation describing how to do that and what each is for, so I'll not repeat it here. For the site itself, unless you're happy with being known as @you@yoursite.nfshost.com, you're going to want to set up an alias; subdomains can still be a bit tricky/incomplete in edge cases, but unless you're like me and are trying to be fancy with having your feed at https://fed.eitilt.life/sam but your handle as just @sam@eitilt.life, you shouldn't have any trouble. Also, go with their Apache Generic server type: snac doesn't need PHP, but it does need a daemon process.
NFS.net doesn't provide any web panel for managing content, so pull up your terminal and ssh into the user and hostname listed on the site information tab (something along the lines of ssh you_yoursite@ssh.nyc1.nearlyfreespeech.net). You'll probably be dumped into /home/public where you'd normally put any content your site should publish, but with snac's content model, that's actually going to remain entirely empty -- like the FAQ says, "for daemon processes, everything but static content typically goes inside protected" and snac doesn't even put static content there. Instead, cd over to /home/private and git clone https://codeberg.org/grunfink/snac2.git. Unless you want to live on the bleeding edge in your servers as well as your personal systems (you don't), git tag to find the most recent release and git checkout 2.65 or whatever other number is highest, then make the program as normal.
This is where the fun begins. make install doesn't work -- we don't have the permissions to write anything outside of /home. Instead, make install PREFIX=/home/protected/ ; cd /home/protected. Go ahead and follow the rest of the standard server setup, except that wherever they use $HOME/, explicitly use /home/protected/ instead, and since it's not on your path you have to write out the full/relative path to the binary manually. The local address needs to be 127.0.0.1 or (possibly, untested) http://localhost, but the port is free game: 8001 as used in the other guides is good here as well, 8080 would also make sense... At this point, my excessive cleanliness moved both /home/protected/bin and /home/protected/man into the snac-data directory, but if you don't want to, just replace protected/snac-data/bin wherever it occurs below with simply protected/bin; this after-the-fact move is required since the PREFIX can't be set to dump them in there initially -- snac init requires a non-existent target -- but in order to call it you have to have already run make install, so there's a bit of a Catch-22 there.
Fire up your favorite editor (or even just echo -- it's only two lines) and create /home/protected/snac-data/bin/daemon.sh with the httpd launch invocation and give it ug+x/750 permissions:
#!/bin/sh
exec /home/protected/snac-data/bin/snac httpd /home/protected/snac-data
One final modification that tripped me up for a while while I tried to debug why my site was working fine when testing locally but hung or couldn't be found in production: chgrp -R web /home/protected/snac-data. If you didn't move bin, run it on that directory as well -- but in either case since we don't want any theoretical exploits in snac gaining an easy arbitrary code execution, be sure to lock things back down with chmod -R g-w,o= /home/protected/snac-data/{bin,man,*.json,*.html} (the JSON and HTML risk breaking things, but until and unless snac starts providing server-level controls via the web interface, I'm of the mind that it's better safe than sorry).
Finally, go back to the NearlyFreeSpeech site page, and add both a proxy and a daemon (between the config and billing boxes) to get things hooked up correctly to Apache. The proxy is a very simple http, /, /, 8001 (or whatever other port you specified). I imagine if you set a URL prefix when setting up snac, you need to give that after the slashes, and likely include a few of the other aliases the other guides list, but that's not anything I experimented with. For the daemon, the tag is arbitrary but you probably want it to be snac, the command line needs to point to the daemon script so /home/protected/snac-data/bin/daemon.sh, the working directory would presumably require the prefix as well but I just have /home/public, and be sure that it's running as web.
Click start if on the daemon if it's not already (any errors will show up in /home/logs/daemon_snac.log), and congrats, you are now part of the fediverse, no messing with httpd.conf, acme-client, nginx, or rc.d required!
CC: The Real Grunfink (nprofile…73zh)
Specifically, I use #NearlyFreeSpeech.net for hosting my webpages. I'm sure it's not the only host which provides nearly full control over your own content, and this guide would presumably be easy enough to adapt to whatever other containerized/jailed shared server they use, but NFS.net is the first I found years ago, has a very nice pay-for-what-you-use pricing structure with (as far as I know) good rates, and if you're already looking at snac for "lightweight" or "JavaScript-free" then they follow exactly the same design mentality.
This is likely not going to be a wholly-complete guide, since I did the setup over several days and I don't want to go back through the process just to be sure I remember everything correctly. Take this all with a grain of salt, but then again if you're trying to use either NFS.net or snac, and you can't work out how to correct a non-functional/mistaken instruction, you might want to rethink your tooling.
The first step is setting up your user+account+domain+site on NearlyFreeSpeech; that's more levels than is particularly comfortable to deal with if this is the only thing you're going to need hosted, but they have a fair amount of FAQs and other documentation describing how to do that and what each is for, so I'll not repeat it here. For the site itself, unless you're happy with being known as @you@yoursite.nfshost.com, you're going to want to set up an alias; subdomains can still be a bit tricky/incomplete in edge cases, but unless you're like me and are trying to be fancy with having your feed at https://fed.eitilt.life/sam but your handle as just @sam@eitilt.life, you shouldn't have any trouble. Also, go with their Apache Generic server type: snac doesn't need PHP, but it does need a daemon process.
NFS.net doesn't provide any web panel for managing content, so pull up your terminal and ssh into the user and hostname listed on the site information tab (something along the lines of ssh you_yoursite@ssh.nyc1.nearlyfreespeech.net). You'll probably be dumped into /home/public where you'd normally put any content your site should publish, but with snac's content model, that's actually going to remain entirely empty -- like the FAQ says, "for daemon processes, everything but static content typically goes inside protected" and snac doesn't even put static content there. Instead, cd over to /home/private and git clone https://codeberg.org/grunfink/snac2.git. Unless you want to live on the bleeding edge in your servers as well as your personal systems (you don't), git tag to find the most recent release and git checkout 2.65 or whatever other number is highest, then make the program as normal.
This is where the fun begins. make install doesn't work -- we don't have the permissions to write anything outside of /home. Instead, make install PREFIX=/home/protected/ ; cd /home/protected. Go ahead and follow the rest of the standard server setup, except that wherever they use $HOME/, explicitly use /home/protected/ instead, and since it's not on your path you have to write out the full/relative path to the binary manually. The local address needs to be 127.0.0.1 or (possibly, untested) http://localhost, but the port is free game: 8001 as used in the other guides is good here as well, 8080 would also make sense... At this point, my excessive cleanliness moved both /home/protected/bin and /home/protected/man into the snac-data directory, but if you don't want to, just replace protected/snac-data/bin wherever it occurs below with simply protected/bin; this after-the-fact move is required since the PREFIX can't be set to dump them in there initially -- snac init requires a non-existent target -- but in order to call it you have to have already run make install, so there's a bit of a Catch-22 there.
Fire up your favorite editor (or even just echo -- it's only two lines) and create /home/protected/snac-data/bin/daemon.sh with the httpd launch invocation and give it ug+x/750 permissions:
#!/bin/sh
exec /home/protected/snac-data/bin/snac httpd /home/protected/snac-data
One final modification that tripped me up for a while while I tried to debug why my site was working fine when testing locally but hung or couldn't be found in production: chgrp -R web /home/protected/snac-data. If you didn't move bin, run it on that directory as well -- but in either case since we don't want any theoretical exploits in snac gaining an easy arbitrary code execution, be sure to lock things back down with chmod -R g-w,o= /home/protected/snac-data/{bin,man,*.json,*.html} (the JSON and HTML risk breaking things, but until and unless snac starts providing server-level controls via the web interface, I'm of the mind that it's better safe than sorry).
Finally, go back to the NearlyFreeSpeech site page, and add both a proxy and a daemon (between the config and billing boxes) to get things hooked up correctly to Apache. The proxy is a very simple http, /, /, 8001 (or whatever other port you specified). I imagine if you set a URL prefix when setting up snac, you need to give that after the slashes, and likely include a few of the other aliases the other guides list, but that's not anything I experimented with. For the daemon, the tag is arbitrary but you probably want it to be snac, the command line needs to point to the daemon script so /home/protected/snac-data/bin/daemon.sh, the working directory would presumably require the prefix as well but I just have /home/public, and be sure that it's running as web.
Click start if on the daemon if it's not already (any errors will show up in /home/logs/daemon_snac.log), and congrats, you are now part of the fediverse, no messing with httpd.conf, acme-client, nginx, or rc.d required!
CC: The Real Grunfink (nprofile…73zh)