/meta/ - meta

General sitewide meta


New Reply[×]
Name
Email
Subject
Message
Files Max 5 files50MB total
Tegaki
Password
[New Reply]


As you might have noticed, trashchan was down again last night for more than 6 hours. I could go on and rant about BuyVM (and I probably will), but for now, I decided to look for alternatives.
I'd like to move the backend first (the proxy will likely stay, it's better if I just spin up another somewhere else). It's a bit problematic though, as being an image board means pretty basic CPU and RAM usage, but a lot of disk space, which immediately disqualifies about 80% of VPS providers where you can't buy additional block storage without switching to a higher plan for gazillion more shekels. And they should be ok with TOR. (Not deleting your account immediately at the first fake report of dolphin porn is useful, but less important here, the backend won't be reported as it's not publicly available)
If anyone has any recommendations, shoot it, because not a lot of VPS provides have block storage at not insane prices (it doesn't have to be an NVME SSD for fucks sake).
Replies: >>1870
>>1869 (OP) 
Thanks for the update, Admin.

>any recommendations
Apparently 2 or 3 sites on the WR use the same provider. Any ideas (or ways to find out) what the other sites use?

Also, maybe we could discuss ways to reduce the disk space usage? Some kind of automated archiving that allows for offloading of older content over onto filestorage / downloading providers or something?

Just know that we're all grateful for you providing a place for us all to 'live' here. I'm sure some reasonable solutions can be found.
Replies: >>1871 >>1877
>>1870
>reduce the disk space usage
The biggest problem here is that jschan expects everything to be on a single FS. And while you have things like sshfs, s3fs and whatnot, it's not really something I'd like to run jschan on. Ideally you'd only put the media files on the object storage, but I'm afraid that'd need some more jschan patches. Of course it's not impossible, but lot of pain, so in the first round I'd look for providers which provide a somewhat sane storage solution out of the box.
The second problem is my current backup strategy depending on btrfs snapshots...
Replies: >>1872
>>1871
>Of course it's not impossible, but lot of pain, so in the first round I'd look for providers which provide a somewhat sane storage solution out of the box.
Yes, this would be the ideal. Good hunting. I hope other Anons that have practical knowledge on this will join in this conversation.

>Ideally you'd only put the media files on the object storage, but I'm afraid that'd need some more jschan patches.
Is @Tom active in responding to PRs? If this is a common need, maybe other devs can pitch in ideas/work as well on the repo?

---
>The second problem is my current backup strategy depending on btrfs snapshots...
I presume that makes full-sized backups each and every time? What if we devised some kind of approach that only performed incremental daily backups shuttling them off to a local-storage scheme? For BUMP, I only grab anything that has bumped since the previous time for any new downloads, then the secondary simply uses the standard flags of the cp command to perform only incremental changes saved onto a second disk. Not exactly "disaster recovery -tier", but effective so far. Perhaps a more-robust form of something similar?

Or at the very least, perhaps only keeping just a couple of full-sized btrfs snapshots at any one time?
Replies: >>1873
>>1872
I'm not sure if Tom is active at all, last commit in the jschan repo was 11 months ago: https://gitgud.io/fatchan/jschan

About btrfs snaphots: yes, they're full snapshots, but copy-on-write, so they only take a very little disk space (practically only the modified files have to be stored). What I like about them is that they're atomic (so it stores the state of the FS in an exact point of time, unlike normal backup tools which go through each file one by one and back them up, which can mess up things if the FS is modified during that). Also the files here are served directly from the btrfs snapshots: http://trashbakket2sfmaqwmvv57dfnmacugvuhwxtxaehcma6ladugfe2cyd.onion/
It has 5 backups, ~109.5GB each (the website says 109.3 because it calculates with the raw file size, ignoring the fact that small files will be rounded up to the FS sector size), but total disk usage is just 109.8GB

I've checked the prices at hetzner where I also have a few stuff (even though I'd never host jschan there, you don't want to comply with the nazi german laws), storage box (which is like an object store) ~2EUR/TB, volume (which is I think a block device, but on SSD) ~58EUR/TB. Yeah, that's the difference between HDD and SSD.
Replies: >>1874
>>1873
Hmm. I see. I hope @Tom is doing OK.

>What I like about them is that they're atomic
Yeah, that's good. I've been so out-of-the-loop with tech over the past 2 or 3 years, that its probably a good idea if I find a project to get my feet wet again. I have a little spare notebook I've set aside rn for a robowaifu project I'm working towards, maybe I can spin up a Jschan instance and run a backup'd instance of Trashchan as per your
> http://trashbakket2sfmaqwmvv57dfnmacugvuhwxtxaehcma6ladugfe2cyd.onion/
instructions. Any further tips you could give me would be appreciated I was never very good at sysadmin lol. Also, what OS do you recommend I use? (Clean slate; I'll nuke the box from scratch according to your instructions.)
That way, I can at least contribute to this conversation with some basic firsthand knowledge (and the machine will still serve it's basic robowaifu need).

Good luck, Admin! Cheers.
Last edited by chobitsu
Replies: >>1875
>>1874
I generally use alpine on my boxes, but alpine lacks mongodb packages, so you'll have to patch and compile it manually (There's some APKBUILD in my jschan fork, but it's not trivial). Maybe going with debian or something is a better idea lol.
And so far, looking for a provider who 1) is not afraid of a little porn, 2) not afraid of a little Tor, 3) not sketchy as shit, 4) not expensive as shit, I found nothing.
Replies: >>1876
>>1875
>Maybe going with debian or something is a better idea lol.
Lol, maybe so. OK, I'll do that.
__akemi_homura_mahou_shoujo_madoka_magica_and_1_more_drawn_by_fc_efushii__da754307ab33463500fc90f641e39cfa.png
[Hide] (426.1KB, 740x598)
>>1870
Hello, I was pointed this way by chobitsu. I'm illya, admin of Homurachan.
>Any ideas (or ways to find out) what the other sites use?
Homurachan uses Incognet. It's no great secret since we don't use Cloudflare to hide the server IP.

I don't know if storage prices are competitive since meguca uses relatively little by its nature, but Incognet's bandwidth is functionally infinite for a small imageboard. Incognet has been okay in terms of stability, we've had a few hours of downtime a few times in the last year. My biggest issue with them was that their Washington (west coast) location hosting had major stability issues if you enabled IPv6, I still haven't turned it back on since I moved the hosting elsewhere.
Replies: >>1878 >>1884
>>1877
Yes, I've seen that, and Incognet might be good as a proxy, but as far as I see they don't have block storage. The smallest plan which would fit the current trashchan is the 10GB ram (which is ridiculously large) one with 4 cores (also overkill) and 120GB storage (which would just fit the current usage, so I'd likely need an even bigger plan), and it's sold out.

On the other hand it looks like s3ql is back from dead, so I might go in this direction, as it actually emulates a normal posix FS over S3 with caching and encryption. I have no idea how performant it would be
https://github.com/s3ql/s3ql/
Honestly, I might be running trashchan on a machine in my moms basement. I could get similar uptime to buyvm at this point. With aggressive enough caching, it would be likely usable, and it would be way more powerful than whatever lousy VPS providers would provide me for basically free. And my ISP has no problem with Tor or me sometimes uploading 5+TB in a month, and unlike VPSes, they have no access to the files stored whatsoever.
Still, it's probably a bad idea.
Replies: >>1880
>>1879
>Still, it's probably a bad idea.
Can you run it that way in some kind of 'failover mirror' fashion?
The problem is jschan is not really scalable, it runs on a single machine and that's it. I can put multiple proxies in front of it with no problem, but that won't solve the problem of the service disappearing if the master node becomes inaccessible.
What you could do is have multiple instances of jschan ready, select one as the master, and that could for example every n minute replicate the changes to everywhere else. If that goes down, the proxies can chose a different node as the master and continue from there. I'm not sure if there's a ready made software to do this though,
I actually had a fork of jschan trying to improve things in this regard, but it was a pain to keep it up with Tom's changes (and it still required an always available master node). But on the other hand, there are no more jschan updates...
Replies: >>1882
>>1881
>every n minute replicate
This would of course also mean changes in the last n minutes can be lost.
Replies: >>1883
>>1882
>This would of course also mean changes in the last n minutes can be lost.
I think that's a reasonable compromise TBH. It's not like this is a financial institution or something?
>>1877
Hello, Homurachan! Thanks for stopping by. Thanks for your input...please look around the site while you're here. Cheers.
Replies: >>1885
>>1884
>please look around the site while you're here
I keep up with the active boards here like I do with the rest of the webring. I've been posting on /animu/ lately, seems friendly.
Random planning notes for myself:
cronjob do every n minutes:
* take a mongodb and redis dump, place into jschan's dir, make a btrfs snapshot
* btrfs send it over to the other server(s)
* can delete old snapshots once everyone else has them
when need to switch over:
* drop whatever state we might have, and create a writable subvol from the last snapshot
* restore redis & mongodb
* start jschan
* from this point this node can replicate to the other servers

active master selection:
* raft protocol (but complicated to implement and ready made implementations are either way too barebones to use or overly bloated...)
* alternate: gossip protocol (when something changes, just broadcast it to everyone, conflict resolution based on timestamps)
* this should run on all nodes (servers & proxies, not just servers) (with 2 nodes it's a bit hard to tell if you disconnected from the net or the other node died)
* when a server starts: attempt to get master node status from the distributed store, if it fails assume we're offline and don't start (could also ping some outside service with better than garage level SLA for extra sanity check, like 8.8.8.8)
* for proxies this is less important (at worst we'll try to communicate with a dead server vs. if multiple servers start, that can get chaotic)
* while active send out a hearbeat every say 1 minute
* if no heartbeat received from the active server for say 5 minutes, another server can take over
* sanity check: we shouldn't take over if we got offline (see first point). so probably all node should send a heartbeat, and only switch if we seen a heartbeat recently, but not from the active server. can sanity check internet connection here too
* how to select next active server? with only 2 servers the solution is trivial, but with more? you don't want to accidentally start two servers. handling this would probably require raft

Is there an easier way to do this? It feels like a minefield to implement from scratch with all the stupid edge cases. But worst case I just destroy an altchan, so what can go wrong?

Also since it's not like trashchan gets 1938 posts every second, it's possible to just trigger the sync after each post to decrease the window where data loss can occur (but it's still need some cooldown/whatever, so someone flooding the site with posts wouldn't case even more load on the server than there is already).
[New Reply]
17 replies | 1 file | 11 UIDs
Connecting...
Show Post Actions

Actions:

Captcha:

- news - rules - faq -
jschan 1.7.3