The site links to a site that accepts payment data. So because the author’s site is http, a MITM attacker could change the payment links from lulu.com to site-that-actually-steals-your-credit-card.com.
That’s one huge thing https provides over http… assurance of unadulterated content, including links to sites that actually deal in sensitive data.
I haven’t used an out-of-the-box self-hosted solution for this, but I agree with others that blog or static site generator software could work. I think the main challenges you’ll find though are: 1. Formatting the content/site for long-form readability, and 2. Adding a table of contents and previous/next chapter links without a bunch of manual work.
Fortunately blog and static site software have plugins that can add missing functionality like this. Here’s one for WordPress (that I have no first-hand experience with): https://wordpress.org/plugins/book-press/
I also want to ask: What’s your plan for discovery/marketing? Because one of the benefits of the non-self-hosted web novel sites is that readers can theoretically discover your story there. But if you instead just post it on your own site, how will readers ever find it?
That’s unfortunate about NPM and Proxy Protocol, because plain ol’ nginx does support it.
I hear you about Traefik… I originally came from nginx-proxy (not to be confused with NPM), and it had pretty clunky configuration especially with containers, which is how I ended up moving to Traefik… which is not without its own challenges.
Anyway, I hope you find a solution that works for your stack.
I struggled with this same problem for a long time before finding a solution. I really didn’t want to give up and run my reverse proxy (Traefik in my case) on the host, because then I’d lose out on all the automatic container discovery and routing. But I really needed true client IPs to get passed through for downstream service consumption.
So what I ended up doing was installing only HAProxy on the host, configuring it to proxy all traffic to my containerized reverse proxy via Proxy Protocol (which includes original client IPs!) instead of HTTPS. Then I configured my reverse proxy to expect (and trust) Proxy Protocol traffic from the host. This allows the reverse proxy to receive original client IPs while still terminating HTTPS. And then it can pass everything to downstream containerized services as needed.
I tried several of the other options mentioned in this thread and never got them working. Proxy Protocol was the only thing that ever did. The main downside is there is another moving part (HAProxy) added to the mix, and it does need to be on the host. But in my case, that’s a small price to pay for working client IPs.
More at: https://www.haproxy.com/blog/use-the-proxy-protocol-to-preserve-a-clients-ip-address
I’m not super familiar with Unraid, but yeah, the borgserver image sounds like it’d work for this… You don’t need borgmatic on the server side unless you want it there to make running Borg commands easier.
Nope! Borg always requires Borg on the remote side. It’s Borg’s biggest strength and weakness versus competing backup systems IMO. Strength, because it can do pretty smart stuff with its own code running on both sides. Weakness, because it means it doesn’t work natively with cloud object storage like S3. It’s a tradeoff like anything else.
Glad to hear it’s (mostly) working out for you! I know you came here looking for best practices with restores, but if you end up coming up with anything yourself, feel free to comment on that Docker borgmatic ticket with requests or ideas. I use the container myself on some systems for the same reasons you do, and I also wouldn’t mind smoother restores!
borgmatic dev here. First of all, if Vorta is working well for you to recover files, then by all means use Vorta! Right tool for the job and all. Having said that, a couple of thoughts on using borgmatic in Docker and recovering files:
borgmatic has a search feature that makes finding a particular file in an archive or across archives pretty easy. So that might be step one in restoring an accidentally deleted file.
Once you’ve found the file and archive to restore, you can either use borgmatic extract or borgmatic mount. With extract, you copy one or more files out of a backup archives. The challenge though is that with borgmatic in a container, by default there’s not an easy way to copy those files into their original locations. However I think the “fix” is to mount your source volumes as read-write instead of (the documented) read-only. That way you can easily copy extracted files back to where they belong.
As for borgmatic mount, you’ve got a similar challenge and fix. You can presumably mount backup archives (or a whole repository) within the container, but then you need to copy your recovered files out of that mount into their original source volumes. So that probably also means those volumes need to be mounted read-write.
Let me know if you have any questions!
Maybe I’m being naive, but it seems like the biggest threat of unchecked AI is “just” the further concentration of wealth (among humans). Which, ironically, poses a catastrophic risk to humanity…
Lots of hotels tack on “amenity fees” or “resort fees” separate from those. It’s pretty obnoxious, especially since they don’t show them to you til you’re halfway through booking.
Ooh, lucky you! Maybe it was both the rDNS and the SNDS. Part of the problem IMO is it’s such a black box…
I’ve had similar experiences trying to send mail to Microsoft-hosted email addresses. My current “solution” is to send all outgoing mail directly from my VPS-hosted Mailu server… EXCEPT for Microsoft-destined mail. For those messages, they get transparently relayed from Postfix to a third-party email sending service that Microsoft apparently trusts.
The upshot is I can still use my own Postfix daemon for all mail sent to sane (non-Microsoft) providers.
Yup that’s exactly how it came off (to me).
So then I guess I’m not seeing how it serves as an example…
How many examples do you think are needed before people stop doing drugs?
Intolerance of intolerance is essential to a free society. https://en.m.wikipedia.org/wiki/Paradox_of_tolerance
borgmatic dev here. What I do is run borgmatic locally on each server that needs to get backed up. That’s a whole lot easier IMO than setting up network filesystems / rclone or tunnels or screwing around with database dumps yourself, and potentially more reliable. So in your case, I’d run borgmatic on the VPS and then have it connect locally to your MariaDB database using borgmatic’s native filesystem support. And then if you also backup the local files with that same VPS instance of borgmatic as well, there’s nothing to “merge.”
I’d generally recommend one Borg repository per source server / instance of borgmatic.
Lastly, my raspberry uses rclone to push to S3 and I don’t want the keys to be accessible on the VPS’s, that’s why I’m trying to have borgmatic only on my raspberry.
You could always have borgmatic backup to a local Borg repository on the VPS, and then run rclone on your trusted server to copy that repository to S3. Personally I’d probably just put the S3 keys on the VPS and lock it down so that I trust its security, but you do you. 😀
Thanks for weighing in. That’s historically been my take as well, although as of this thread I’m starting to wonder if modern PHP can be better and/or particular projects can be.
Also team borgmatic here. ;)
I use Ansible to meet this need. Whenever I want to deploy to one or more remote hosts, I run Ansible locally and it connects via SSH to the remote host(s). There, it can run Docker Compose, configure services, lay down files on the host, restart things, etc.