I imagine more people would use Tor if they could get paid to provide bandwidth (like Orchid as described on FLOSS Weekly 633).
/ˈbɑːltəkʊteɪ/. Knows some chemistry and piping stuff. TeXmacs user.
Website: reboil.com
Mastodon: baltakatei@twit.social
I imagine more people would use Tor if they could get paid to provide bandwidth (like Orchid as described on FLOSS Weekly 633).
Maybe try out FreedomBox? freedombox
is a Debian package which automatically sets up apache2
, firewalld
, fail2ban
and Letʼs Encrypt. It also automatically adds pre-canned configuration files for applications you install with it (e.g. Mediawiki, WordPress, Matrix, Postfix/Dovecot). The theoretical goal of FreedomBox is to allow anyone to set up a webserver and administer it via a webUI. So, although I would say itʼs not quite there yet for command-line-illiterate users, I have found the software useful as a turnkey server to see what makes certain web applications tick, albeït in mostly vanilla form.
For example, after installing a new app like WordPress, you could examine what exactly the FreedomBox scripts changed in the /etc/apache2/
or /etc/fail2ban/
configuration files.
TL;DR: fgallery
is a dumb static web gallery generator: EXAMPLE, SETUP.
There’s fgallery which is a small Debian package that takes an input directory (e.g. photo-dir
) and creates a static website in a new directory (e.g. my-gallery
).
$ fgallery photo-dir my-gallery
From the Debian package details page.
static HTML+JavaScript photo album generator
“fgallery” is a static photo gallery generator with no frills that has a stylish, minimalist look. “fgallery” shows your photos, and nothing else.
There is no server-side processing, only static generation. The resulting gallery can be uploaded anywhere without additional requirements and works with any modern browser.
Among all the Debian packages similar to this one, this seems the most recently maintained (version 1.9.1 came out 2022-12-31). It is licensed GPLv2+ so the source code is available.
After running fgallery
as described above, upload my-gallery
to your static web page directory (e.g. /var/www/html/
with a typical apache2
setup) and open the index.html
through a web browser.
Here’s an example gallery I made just now (setup procedure).
( Photo by Baltakatei / 🅭🅯🄎 4.0 )
To view the gallery locally without uploading to a web server (e.g. a Digital Ocean droplet) or static content hosting service (e.g. AWS S3), you can do so with your own web browser. However, because the fgallery
webpage uses Javascript and since modern browsers refuse to render Javascript in HTML pages at local file system addresses (e.g. file:///
) due to same-origin policy, the easiest solution is to make a simple webserver via python3:
$ python3 -m http.server -d ./my-gallery
Then, you can visit the my-gallery/index.html
file via a local http://
address at http://localhost:8000/
.
fgallery
lacks many complex features (no image database, no metadata editing, no dynamic server processes for editing images, etc.). However, I’d argue its lack of features is the main feature. It just takes a directory of photos and spits out a directory you can plug into your hosting service. Updating the the gallery is just a matter of running the same $ fgallery photo-dir my-gallery
command again and re-uploading.
Edit(2023-07-07T12:05+00): Clarify python3 commend.
TL;DR: fgallery
is a dumb static web gallery generator: EXAMPLE, SETUP.
Thunderbird’s Blogs and News Feeds feature. Allows me to backup RSS feed data alongside my emails in MBOX format via the ImportExportTools NG add-on.
Theoretically, I don’t think an MX record is absolutely needed to send, but it definitely is needed to receive. An MX record helps an email sending server to figure out which IP address to actually send email data packets towards based on the domain name in the email address (i.e. the @apple.com
in steve@apple.com
).
Even if you’re self-hosting your own email server and are using the same domain name for all services and are using port number to differentiate incoming traffic, incoming email won’t come in unless an MX record can explicitly tell other email servers where to send emails labeled with your domain name. An MX record can also be a handy way to redirect email traffic to a different IP address in case the one your server uses is blacklisted by other email servers (e.g. if spammers have used your IP address in the past).
An A record can associate an IP address with a domain name but an MX record is needed to tell a sending server that a domain name is prepared to accept email at all.
That said, if you examine the DNS setup instructions that a transactional email company will send you, you’ll see that they also want you to create other DNS records for purposes. For example, Mailgun has me store a public key in a TXT record (making it a DKIM record) used to cryptographically authenticate emails against emails sent by your server (that are forwarded and signed by Mailgun’s private key) to prevent email address impersonation, which might be important even if you’re only sending password reset emails and not expecting to receive email. (I recall receiving several emails from emperorpalpatine@senate.gov
while in college, probably sent by mischievous CS students learning about email stuff themselves and realizing our school’s email setup was old and crusty) Mailgun also has me keep a CNAME record as well for some kind of delivery confirmation service (a transactional email service is basically a trusted man-in-the-middle); I forget the details. But, basically, thanks to spammers, there’s more to setting up your own email service than creating an MX record, even if all you’re doing is setting up a Lemmy instance that only needs to send password reset emails.
Source: someone who has bumbled through Discourse and Mediawiki email setup for small projects.
If it’s anything like SMTP on a Mediawiki or Discourse instance (example notes, then what you probably need is something called “transactional email” (I’m guessing you’re looking at a guide like this?). I’ve made use of this guide for looking up vendors for that service.
In theory, the same server hosting a Lemmy service could also send and receive emails. However, in practice there’s a high probability of these emails landing in spam boxes. The defacto proof-of-work hurdle that inhibits email spam today is paying commercial transactional email companies a monthly fee. I’m hopeful that one day self-hosted email server software will become easier to set up through things like FreedomBox (via Postfix, Dovecot, and Rspamd), but the fundamental reputation problem remains, imo.
So, I doubt a Lemmy setup guide would automatically take care of email setup. In any case, the process involves creating at least one MX record (according to instructions provided by your transactional email service) with your DNS provider which depends on the name servers you have configured for your domain registrar. The transactional email service you select should provide instructions for what port to open, as well as what SMTP URL, user name, password, and postmaster email address to provide to Lemmy.
How many arms does a catboy need? Honestly.