I initially set it up because both sonarr and radarr were making their own api calls to indexers and I would get some "daily max exceeded" for certain sites. The idea was that if one host made the calls instead of 2, I wouldn't get rate limited as much.
Now I only have my nzb and pb indexers, the first has no such limits because I pay for it, and the second is only used as a second priority, so I don't really hit limits anymore.
If you have a bunch of arr services, this is useful. But I only have the two, so I don't think it's much work to set indexers up individually.
Edit: this ^^ is my suggestion. Add the indexers manually.
Yeah. I have a dell r430 sitting unused and a supermicro xeon-d board, both have a BMC.
It's really nice to have, but server stuff is expensive and power hungry.
Plus, I've shifted my way of looking at the setup where I'd rather it just default to starting back up properly. Even if I have a failed disk, if I'm away there's nothing incan do about it until I'm physically back.
I'm almost 30yrs in it/devops/infosec and I'm no longer interested in owning an excavator just because I can.
Incus, all services running in lxc. Ansible and templates to run startup stuff for new containers (ssh keys, etc). My docker setup is primitive, I regressed down to individual containers for each with docker compose. It's so trivial to restore last night's lxc backup that k3s/k8s doesn't really help me. In fact, i've been simplifying everything to suit my use case, including hardware.
sonarr
radarr
bazarr
prowlarr (I'm close to getting rid of this)
transmission
sabnzbd
kavita for comics only
calibre Web automated (CWA)
frigate NVR
navidrome
immich
openwisp to manage 2x openwrt access points
homeassistant
technitium DNS x2
uptimekuma monitoring x2
ntfy for push notifications
ansible
jellyfin
radicale
syncthing
Wireguard
wanderer for GPS track mgmt on "big screen". I track my GPS trails and drives as a hobby. I'd love a self-hosted comaps web client, but I can't really find one. :(
Plus lots of transient trials that come and go with interest. Rotating 7 day/4 week/3 months
backups by NFS with pruning, includes snapshots, but I set expires on these.
This is running on 2x minipcs with 48GB ram each, but they are way overkill. I just received a mini itx i5 board, which will house all of the containers, save VPN and 1x DNS, which I will run on an SBC.
So I'm going down from 2x servers + 1 NFS nas to one 1u server for everything plus one SBC so I can reboot it.
You should look up "baseband radio vulnerabilities".
It is still unknown how many radios have code that might allow a back door similar to Intel's mgmt engine. But the firmware blobs are all closed, and very few ppl know what they actually contain.
If you don't want to be tracked, get an open platform device.
And in light of the tools out there that can fingerprint you by a lot of metrics, if you truly don't want to be tracked, at all, don't use connected technology.
Websites are complicated. Easy, secure, cheap: pick two. There is no such thing as a universally easy, secure and cheap solution, or else we would always be using it.
Assuming you want secure and easy, I would suggest you pay someone who knows what they're doing.
I think we're talking past each other here: You are talking about blocks as physical delineations in an ssd, containing many pages with erase cycles. Op is talking about the filesystem view of blocks, which is different altogether. ZFS, for instance, should have its block size aligned with what a disk presents to the HAL, or you end up with lots of wasted space or terrible performance.
For SSDs (you're right, outside op's problem), the internal block size is usually much bigger than the emulated block size, often 128K. But we don't use filesystems with 128K block sizes, or we couldn't reasonable run databases or store small files.
There was a brief time in the wild west of SSDs being new where some shipped with 8k blocks, but this caused a bunch of problems for storage drivers because no one had yet decided if the translation of FS blocks to should be handled by filesystems or by disk firmware. We now let manufacturers decide how they should r/w to media, and trust the firmware's presented block size.
That block size is now 4k for most disks, spinning or ssd. We still see some weird layouts in high-performance or high-endurance disks, but they are exceptions.
so if a 512e SSD doesn’t receive the rest of the page in time (e.g. with IO scheduling, 512 byte fs sectors, unaligned partitions, or bad luck)
I'm not sure what this means, pages are a concept in an ssd's physical structure, they don't mean anything to a filesystem (except in volatile memory).
Agree on the Jonsbo. I have an N1 and it is not great for cooling HDD either. Jonsbo seem to design their cases as ideas and never actually test them.
I have found that a combo of Terraform and ansible cover almost everything, if that's of any use.
Will test, thx. Keep up the good work.
I initially set it up because both sonarr and radarr were making their own api calls to indexers and I would get some "daily max exceeded" for certain sites. The idea was that if one host made the calls instead of 2, I wouldn't get rate limited as much.
Now I only have my nzb and pb indexers, the first has no such limits because I pay for it, and the second is only used as a second priority, so I don't really hit limits anymore.
If you have a bunch of arr services, this is useful. But I only have the two, so I don't think it's much work to set indexers up individually.
Edit: this ^^ is my suggestion. Add the indexers manually.
To me, it's a good stack. A lot of ppl have lower numbers than this, but then they set up a VM with docker and just run 12 extra things there. :P
Yeah. I have a dell r430 sitting unused and a supermicro xeon-d board, both have a BMC.
It's really nice to have, but server stuff is expensive and power hungry.
Plus, I've shifted my way of looking at the setup where I'd rather it just default to starting back up properly. Even if I have a failed disk, if I'm away there's nothing incan do about it until I'm physically back.
I'm almost 30yrs in it/devops/infosec and I'm no longer interested in owning an excavator just because I can.
Incus, all services running in lxc. Ansible and templates to run startup stuff for new containers (ssh keys, etc). My docker setup is primitive, I regressed down to individual containers for each with docker compose. It's so trivial to restore last night's lxc backup that k3s/k8s doesn't really help me. In fact, i've been simplifying everything to suit my use case, including hardware.
Plus lots of transient trials that come and go with interest. Rotating 7 day/4 week/3 months backups by NFS with pruning, includes snapshots, but I set expires on these.
This is running on 2x minipcs with 48GB ram each, but they are way overkill. I just received a mini itx i5 board, which will house all of the containers, save VPN and 1x DNS, which I will run on an SBC.
So I'm going down from 2x servers + 1 NFS nas to one 1u server for everything plus one SBC so I can reboot it.
Power consumption is king factor for me now.
You should look up "baseband radio vulnerabilities".
It is still unknown how many radios have code that might allow a back door similar to Intel's mgmt engine. But the firmware blobs are all closed, and very few ppl know what they actually contain.
If you don't want to be tracked, get an open platform device.
And in light of the tools out there that can fingerprint you by a lot of metrics, if you truly don't want to be tracked, at all, don't use connected technology.
There have been other fires in other years.
Second.
Yes, the emergency mylar blankets. We got a presentation on this at Search and Rescue, they make finding ppl with FLIR difficult.
I suppose so, but all they'll see is a an encrypted session.
I haven't found one, no. I just use markdown and a static HTML site generator.
Is this a trick question?
Websites are complicated. Easy, secure, cheap: pick two. There is no such thing as a universally easy, secure and cheap solution, or else we would always be using it.
Assuming you want secure and easy, I would suggest you pay someone who knows what they're doing.
It was time in 2013.
I think we're talking past each other here: You are talking about blocks as physical delineations in an ssd, containing many pages with erase cycles. Op is talking about the filesystem view of blocks, which is different altogether. ZFS, for instance, should have its block size aligned with what a disk presents to the HAL, or you end up with lots of wasted space or terrible performance.
For SSDs (you're right, outside op's problem), the internal block size is usually much bigger than the emulated block size, often 128K. But we don't use filesystems with 128K block sizes, or we couldn't reasonable run databases or store small files.
There was a brief time in the wild west of SSDs being new where some shipped with 8k blocks, but this caused a bunch of problems for storage drivers because no one had yet decided if the translation of FS blocks to should be handled by filesystems or by disk firmware. We now let manufacturers decide how they should r/w to media, and trust the firmware's presented block size.
That block size is now 4k for most disks, spinning or ssd. We still see some weird layouts in high-performance or high-endurance disks, but they are exceptions.
I'm not sure what this means, pages are a concept in an ssd's physical structure, they don't mean anything to a filesystem (except in volatile memory).
Except for leaving things default, almost none of that comment is true.
4k is default for most disks today. Some transition-era ssds used 8k blocks.
Do not worry about emulated block size, because ssds only use that to report to the filesystem, no sectors exist on solid state media.
Erasing the partition table and/or uefi metadata space.
Are you new to corporate lies about privacy?
Proton is beholden to Swiss disclosure law, and swiss law caves to international requests pretty often.
Just assume your emails are being read by proton.
I mean, it's a proton.me product. They say lots of stuff that isn't really true.