Unauthorized VPNs (non government approved) are illegal in China. If a business needs their own they can get approval but they have to apply for those exceptions.
It isn’t really enforced, probably especially so for non citizens, but if you do something they don’t like it is something they could use against you.
You would probably be less breaking the law to just directly open up SSH and access that instead of tunneling through a VPN. Even though SSH can do tunneling of its own.
A lot of the Qanon stuff was about draining the swamp by arresting all of the pedo Dems.
They were basically told everything they see in the media is a cover for the real plan to catch these people and that there are already all sorts of sealed indictments that they are just waiting to execute at once, etc.
So some of his most rabbid supporters are realizing something is up about denying this even exists.
Your $1 has absolutely changed in value by 10pm. What do you think inflation is? It might not be enough change for the store to bother changing prices but the value changes constantly.
Watch the foreign exchange markets, your $1 is changing in value compared to every other currency constantly.
The only difference between fiat and crypto is that changing the prices in the store is difficult, and the volume of trade is high enough to reduce volatility in the value of your $. There are plenty of cases of hyperinflation in history where stores have to change prices on a daily basis, meaning that fiat is not immune to volatility.
To prevent that volatility we just have things like the federal reserve, debt limits, federal regulations, etc that are designed to keep you the investor (money holders) happy with keeping that money in dollars instead of assets. The value is somewhat stable as long as the government is solvent.
Crypto doesn’t have those external controls, instead it has internal controls, i.e. mining difficulty. Which from a user perspective is better because it can’t be printed at will by the government.
Long story short fiat is no different than crypto, there is no real tangible value, so value is what people think it is. Unfortunately crypto’s value is driven more by speculative “investors” than by actual trade demand which means it is more volatile. If enough of the world changed to crypto it would just as stable as your $.
Not saying crypto is a good thing just saying that it isn’t any better or worse. It needs daily usage for real trade by a large portion of the population to reduce the volatility, instead of just being used to gamble against the dollar.
Our governments would likely never let that happen though, they can’t give up their ability to print money. It’s far easier to keep getting elected when you print the cash to operate the government, than it is to raise taxes to pay for the things they need.
The absolutely worthless meme coin scams/forks/etc are just scammers and gamblers trying to rip each other off. They just make any sort of useful critical mass of trade less and less plausible because it gives all crypto a bad name. Not that Bitcoin/Ethereum started out any different but now that enough people are using them splitting your user base is just self defeating
Yeah it is pretty bad when an emulator offers a better experience than even a modded Switch.
Easy to load your choice of directory sync tool (i.e. NextCloud Sync Client/Synology Drive Client/etc, or Google Drive/OneDrive if you are on Windows) pointed at your emulators save directory and have your own automatic cloud sync that you have full control over, built in versioning, the works.
Nope, the switch only keeps saves on the internal storage or synced to their cloud if you pay for it. When doing transfers between devices like this there is no copy option only a move and delete.
There are some legitimate reasons they want to prevent this like preventing users from duplicating items in multiplayer games, etc. Even if you got access to the files they are encrypted so that only your user can use them.
I think the bigger reason they do this is there are occasionally exploits that are done through corrupted saves. So preventing the user from importing their own saves helps protect the switch from getting soft modded.
If you mod your switch you can get access to the save files and since it has full access it can also decrypt them, so that you can back them up. One of several legitimate reasons to mod your switch.
I just did a playthrough recently and I think it holds up pretty well. A lot of wasted time on little cutscenes like opening Atla/boxes, and switching characters that gets quite annoying, but gameplay was fine.
One or two bosses that are difficult but a little leveling up, or wiki hints on how to cheese them, and they are a piece of cake. Once you hit the ship dungeon and have easier access to backrooms (since you can buy the fish to enter them) you can grind for gemstones and you end up being able to one hit almost everything from there on out.
Grinding gets a bit boring after a while, I’ll admit I enabled some fish point cheats in my emulator after I had one character with a maxed out weapon. Clear that I could easily do it myself but wasn’t going to waste that time to upgrade the other weapons I wanted leveled up.
Probably a terrible idea but have you considered a private Lemmy instance? At the end of the day Lemmy/PieFed/Reddit are just forums with conversation threads and upvotes.
Lemmy is probably way more of a resource hog than the other various php options but from a usability standpoint if you have a favorite Lemmy mobile app it would work for your private instance as well.
There appears to be a private instance mode that disables federation.
Docker(/Compose) can do mounts directly to the container as well.
https://blog.stefandroid.com/2021/03/03/mount-nfs-share-in-docker-compose.html
https://docs.docker.com/engine/storage/volumes/#create-a-service-which-creates-an-nfs-volume
I’ve used NFS mounts with docker compose before but I see the second link also includes an example for CIFS as well.
Named volumes are often the default because there is no chance of them conflicting with other services or containers running on the system.
Say you deployed two different docker compose apps each with their own MariaDB. With named volumes there is zero chance of those conflicting (at least from the filesystem perspective).
This also better facilitates easier cleanup. The apps documentation can say “docker compose down -v”, and they are done. Instead of listing a bunch of directories that need to be cleaned up.
Those lingering directories can also cause problems for users that might have wanted a clean start when their app is broken, but with a bind mount that broken database schema won’t have been deleted for them when they start up the services again.
All that said, I very much agree that when you go to deploy a docker service you should consider changing the named volumes to standard bind mounts for a couple of reasons.
When running production applications I don’t want the volumes to be able to be cleaned up so easily. A little extra protection from accidental deletion is handy.
The default location for named volumes doesn’t work well with any advanced partitioning strategies. i.e. if you want your database volume on a different partition than your static web content.
Old reason and maybe more user preference at this point but back before the docker overlay2 storage driver had matured we used the btrfs driver instead and occasionally Docker would break and we would need to wipe out the entire /var/lib/docker btrfs filesystem, so I just personally want to keep anything persistent out of that directory.
So basically application writers should use named volumes to simplify the documentation/installation/maintenance/cleanup of their applications.
Systems administrators running those applications should know and understand the docker compose well enough to change those settings to make them production ready for their environment. Reading through it and making those changes ends up being part of learning how the containers are structured in the first place.
For shared lines like cable and wireless it is often asymmetrical so that everyone gets better speeds, not so they can hold you back.
For wireless service providers for instance let’s say you have 20 customers on a single access point. Like a walkie-talkie you can’t both transmit and receive at the same time, and no two customers can be transmitting at the same time either.
So to get around this problem TDMA (time division multiple access) is used. Basically time is split into slices and each user is given a certain percentage of those slices.
Since the AP is transmitting to everyone it usually gets the bulk of the slices like 60+%. This is the shared download speed for everyone in the network.
Most users don’t really upload much so giving the user radios equal slices to the AP would be a massive waste of air time, and since there are 20 customers on this theoretical AP every 1mbit cut off of each users upload speed is 20mbit added to the total download capability for anyone downloading on that AP.
So let’s say we have APs/clients capable of 1000mbit. With 20 users and 1AP if we wanted symmetrical speeds we need 40 equal slots, 20 slots on the AP one for each user to download and 1 slot for each user to upload back. Every user gets 25mbit download and 25mbit upload.
Contrast that to asymmetrical. Let’s say we do a 80/20 AP/client airtime split. We end up with 800mbit shared download amongst everyone and 10mbit upload per user.
In the worst case scenario every user is downloading at the same time meaning you get about 40mbit of that 800, still quite the improvement over 25mbit and if some of those people aren’t home or aren’t active at the time that means that much more for those who are active.
I think the size of the slices is a little more dynamic on more modern systems where AP adjusts the user radios slices on the fly so that idle clients don’t have a bunch of dead air but they still need to have a little time allocated to them for when data does start to flow.
A quick Google seems to show that DOCSIS cable modems use TDMA as well so this all likely applies to cable users as well.
They are from the Lemmynsfw instance. Probably automatically applied to any post coming from that instance.
I am assuming this is the LVM volume that Ubuntu creates if you selected the LVM option when installing.
Think of LVM like a more simple more flexible version of RAID0. It isn’t there to offer redundancy but it take make multiple disks aggregate their storage/performance into a single block device. It doesn’t have all of the performance benefits of RAID0, particularly with sequential reads, but in the cases of fileservers with multiple active users it can probably perform even better than a RAID0 volume would.
The first thing to do would be to look at what volume groups you have. A volume group is one or more drives that creates a pool of storage that we can allocate space from to create logical volumes. Run vgdisplay and you will get a summary of all of the volume groups. If you see a lot of storage available in the ‘Free PE/Size’ (PE means physical extents) line that means that you have storage in the pool that hasn’t been allocated to a logical volume yet.
If you have a set of OS disks an a separate set of storage disks it is probably a good idea to create a separate volume group for your storage disks instead of combining them with the OS disks. This keeps the OS and your storage separate so that it is easier to do things like rebuilding the OS, or migrating to new hardware. If you have enough storage to keep your data volumes separate you should consider ZFS or btrfs for those volumes instead of LVM. ZFS/btrfs have a lot of extra features that can protect your data.
If you don’t have free space then you might be missing additional drives that you want to have added to the pool. You can list all of the physical volume which have been formatted to be used with LVM by running the pvs command. The pvs command show you each formatted drive and if they are associated with a volume group. If you have additional drives that you want to add to your volume group you can run pvcreate /dev/yourvolume to format them.
Once the new drives have been formatted they need to be added to the volume group. Run vgextend volumegroupname /dev/yourvolume to add the new physical device to your volume group. You should re-run vgdisplay afterwards and verify the new physical extents have been added.
If you are looking to have redundancy in this storage you would usually build an mdam array and then do the pvcreate on the volume created my mdadm. LVM is usually not used to give you redundancy, other tools are better for that. Typically LVM is used for pooling storage, snapshots, multiple volumes from a large device, etc.
So one way or another your additional space should be in the volume group now, however that doesn’t make it usable by the OS yet. On top of the volume group we create logical volumes. These are virtual block devices made up of physical extents on the physical disks. If you run lvdisplay you will see a list of logical volumes that were created by the Ubuntu installer which is probably only one by default.
You can create new logical volumes with the lvcreate command or extend the volume that is already there. Or resize the volume that you already have with lvresize. I see other posts already explained those commands in more detail.
Once you have extended the logical volume (the virtual block device) you have to extend the filesystem on top of it. That procedure depends on what filesystem you are using on your logical volume. Likely resize2fs for ext4 by default in Ubuntu, or xfs_growfs if you are on XFS.
Cisco c3850-12x48u is about $150 on eBay.
The main problem is the idle power consumption. About 150w with nothing plugged in.
Can you run more cat6? There are plenty of HDMI over cat6 adapters that work well over some fairly long distances.
There are also plenty of extended length HDMI cables that are 50+ feet if you can fish through the HDMI end. They get a bit expensive at that length because they are hybrid fiber optic but no noise concerns.
USB also has adapters to run over cat6. They are usually limited to USB2.0 but that should be plenty to plug a small hub in for mouse and keyboard.
Good catch on the redundancy, at the time posting this I didn’t realize I needed the physical space/drives to set up that safety net. 8 should be plenty for the time being. Say if I wanted to add another drive or two down the road, what sort of complications would that introduce here?
With TrueNAS your underlying filesystem is ZFS. When you add drives to a pool you can add them:
Each of these sets is called a vdev. Each pool can have multiple vdevs and there is essentially a RAID0 across all of the vdevs in the pool. ZFS tends to scale performance per vdev so if you want it to be really fast, more smaller vdevs is better than fewer larger vdevs.
If you created a mirror vdev with two drives, you could add a second mirror vdev later. Vdevs can be of diferent sizes so it is okay if the second pair of drives is a different size. So if you buy two 10TB drives later they can be added to your original pool for 18TB usable.
What you can’t do is change a vdev from one type to another. So if you start with a mirror you can’t change to a raidz1 later.
You can mix different vdev types in a pool though. So you could have two drives in a mirror today, and add an additional 5 drives in a raidz1 later.
Drives in a vdev can be different sizes but the vdev gets sized based on the smallest drive. Any drives that are larger will be wasting space until you replace that smaller drive with a similar sized one.
A rather recent feature lets you expand raidz1/2/3 vdevs. So you could start with two drives today in a raidz1 (8TB usable), and add additional 8TB or higher drives later adding 8TB of usable space each time.
If you have a bunch of mismatched drives of different sizes you might want to look at UnRAID. It isn’t free but it is reasonably priced. Performance isn’t nearly as good but it has its own parity system that allows for mixing drives of many sizes and only your single largest drive needs to be used for parity. It also has options to add additional parity drives later so you can start at RAID5 and move to RAID6 or higher later when you get enough drives to warrant the extra parity.
My server itself is a little HP mini PC. i7, 2 TB SSD, solid little machine so far. Running Proxmox with a single debian VM which houses all my docker containers - I know I’m not using proxmox to its full advantage, but whatever it works for me. I mostly just use it for its backup system.
Not sure how mini you mean but if it has spots for your two drives this should be plenty of hardware for both NAS and your VMs. TrueNAS can run VMs as well, but it might be a pain migrating from Proxmox.
Think of Proxmox as a VM host that can do some NAS functions, and TrueNAS as a NAS that can do some VM functions. Play with them both, they will have their own strengths and weaknesses.
I’ve been reading about external drive shucking, since apparently that’s a thing? Seems like my best bet here would be to crack both of these external drives open and slap them into a NAS. 16TB would be plenty for my use.
It’s been a couple of years since I have shucked drives but occasionally the drives are slightly different than normal internal drives. There were some western digital drives that had one pin that was different from normal and worked in most computers, but some power supplies which had that pin wired required you to mask the pin before the drive would fire up.
I wouldn’t expect any major issues just saying you should research your particular model.
You say 16TB with two 8TB drives so I assume you aren’t expecting any redundancy here? Make sure you have some sort of backup plan because those drives will fail eventually, it’s just a matter of time.
You can build those as some sort of RAID0 to get you 16TB or you can just keep them as separate drives. Putting them in a RAID0 gives you some read and write performance boost, but in the event of a single drive failure you lose everything.
If 8TB is enough you want to put them in a mirror which give you 8TB of storage and allows a drive to fail without losing any data. There is still a read performance boost but maybe a slight loss on write performance.
Hardware: while I like the form factor of Synology/Terramaster/etc, seems like the better choice would be to just slap together my own mini-ITX build and throw TrueNAS on it. Easy enough, but what sort of specs should I look for? Since I already have 2 drives to slap in, I’d be looking to spend no more than $200. Alternatively, if I did want the convenience and form factor of a “traditional” NAS, is that reasonable within the budget? From what I’ve seen it’s mostly older models in that price range.
If you are planning on running Plex/Jellyfin an Intel with UHD 600 series or newer integrated graphics is the simplest and cheapest option. The UHD 600 series iGPU was the first Intel generation that has hardware decode for h265 so if you need to transcode Plex/Jellyfin will be able to read almost any source content and reencode it to h264 to stream. It won’t handle everything (i.e. AV1) but at that price range that is the best option.
I assume I can essentially just mount the NAS like an external drive on both the server and my desktop, is that how it works? For example, Jellyfin on my server is pointed to /mnt/external, could I just mount a NAS to that same directory instead of the USB drive and not have to change a thing on the configuration side?
Correct. Usually a NAS offers a couple of protocols. For Linux NFS is the typical filesystem used for that. For Windows it would be a Samba share. NFS isn’t the easiest to secure, so you will either end up with some IP ACLs or just allowing access to any machine on your internal network.
If you are keeping Proxmox in the mix you can also mount your NFS share as storage for Proxmox to create the virtual hard drives on. There are occasionally reasons to do this like if you want your NAS to be making snapshots of the VMs, or for security reasons, but generally adding the extra layers is going to cut down performance so mounting inside of the VM is better.
Will adding a NAS into the mix introduce any buffering/latency issues with Jellyfin and Navidrome?
Streaming apps will be reading ahead and so you shouldn’t notice any changes here. Library scans might take longer just because of the extra network latency and NAS filesystem layers, but that shouldn’t have any real effect on the end user experience.
What about emulation? I’m going to set up RomM pretty soon along with the web interface for older games, easy enough. But is streaming roms over a NAS even an option I should consider for anything past the Gamecube era?
Anything past GameCube era is probably large ISO files. Any game from a disk is going to be designed to load data from disk with loading screens, and an 8tb drive/1gb Ethernet is faster than most disks are going to be read. PS4 for example only reads disks at 24MB/s. Nintendo Switch cards aren’t exactly fast either so I don’t think they should be a concern.
It wouldn’t be enough for current gen consoles that expect NVMe storage, but it should be plenty fast for running roms right from your NAS.
Depending on how you setup your reverse proxy it can reduce random scanning/login attempts to basically zero. The point of a reverse proxy is to act as a proxy, as a sort of web router, and to validate that the http requests are correctly formatted.
For the routing depending on what DNS name/path the request comes in with it can route to different backends. So you can say that app1.yourdomain.com is routed to the internal IP address of your app1, and app2.yourdomain.com goes to app2. You can also do this with paths if the applications can handle it. Like yourdomain.com/app1.
When your client makes a request the reverse proxy uses the “Host” header or the SNI string that is part of the TLS connection to determine what certificate to use and what application to route to.
There is usually a “default” backend for any request that doesn’t match any of the names for your backend services (like a scanner blindly trying to access your IP). If you disable the default backend or redirect default requests to something that you know is secure any attacker scanning your IP for vulnerabilities would get their requests rejected. The only way they can even try to hit your service is to know the correct DNS name of your service.
Some reverse proxies (Traefik, HAproxy) have options to reject the requests before the TLS negation has even completed. If the SNI string doesn’t match the connection just drops it doesn’t even bother to send a 404/5xx error. This can prevent an attacker from doing information gathering about the reverse proxy itself that might be helpful in attacking it.
This is security by obscurity which isn’t really security, but it does reduce your risk because it significantly reduces the chances of an attacker being able to find your applications.
Reverse proxies also have a much narrower scope than most applications as well. Your services are running a web server with your application, but is Jellyfin’s built in webserver secure? Could an attacker send invalid data in headers/requests to trigger a buffer overflow? A reverse proxy often does a much better job of preventing those kinds of attacks, rejecting invalid requests before they ever get to your application.
Btrfs is a copy on write (COW) filesystem. Which means that whenever you modify a file it can’t be modified in place. Instead a new block is written and then a single atomic operation is done to flip that new block to be the location of that data.
This is a really good thing for protecting your data from things like power outages or system crashes because the data is always in a good state on disk. Either the update happened or it didn’t there is never any in-between.
While COW is good for data integrity it isn’t always good for speed. If you were doing lots of updates that are smaller than a block you first have to read the rest of the block and then seek to the new location and write out the new block. On ssds this isn’t a issue but on HDDs it can slow things down and fragment your filesystem considerably.
Btrfs has a defragmentation utility though so fragmentation is a fixable problem. If you were using ZFS there would be no way to reverse that fragmentation.
Other filesystems like ext4/xfs are “journaling” filesystems. Instead of writing new blocks or updating each block immediately they keep the changes in memory and write them to a “journal” on the disk. When there is time those changes from the journal are flushed to the disk to make the actual changes happen. Writing the journal to disk is a sequential operation making it more efficient on HDDs. In the event that the system crashes the filesystem replays the journal to get back to the latest state.
ZFS has a journal equivalent called the ZFS Intent Log (ZIL). You put the ZIL on fast SSDs while the data itself is on your HDDs. This also helps with the fragmentation issues for ZFS because ZFS will write incoming writes to the ZIL and then flush them to disk every few seconds. This means fewer larger writes to the HDDs.
Another downside of COW is that because the filesystem is assumed to be so good at preventing corruption, in some extremely rare cases if corruption gets written to disk you might lose the entire filesystem. There are lots of checks in software to prevent that from happening but occasionally hardware issues may let the corruption past.
This is why anyone running ZFS/btrfs for their NAS is recommended to run ECC memory. A random bit flipping in ram might mean the wrong data gets written out and if that data is part of the metadata of the filesystem itself the entire filesystem may be unrecoverable. This is exceedingly rare, but a risk.
Most traditional filesystems on the other hand were built assuming that they had to cleanup corruption from system crashes, etc. So they have fsck tools that can go through and recover as much as possible when that happens.
Lots of other posts here talking about other features that make btrfs a great choice. If you were running a high performance database a journaling filesystem would likely be faster but maybe not by much especially on SSD. But for a end user system the snapshots/file checksumming/etc are far more important than a tiny bit of performance. For the potential corruption issues if you are lacking ECC backups are the proper mitigation (as of DDR5 ECC is in all ram sticks).
Agreed. The nonstandard port helps too. Most script kiddies aren’t going to know your service even exists.
Take it another step further and remove the default backend on your reverse proxy so that requests to anything but the correct DNS name are dropped (bots just are probing IPs) and you basically don’t have to worry at all. Just make sure to keep your reverse proxy up to date.
The reverse proxy ends up enabling security through obscurity, which shouldn’t be your only line of defence, but it is an effective first line of defence especially for anyone who isn’t a target of foreign government level of attacks.
Adding basic auth to your reverse proxy endpoints extends that a whole lot further. Form based logins on your apps might be a lot prettier, but it’s a lot harder to probe for what’s running behind your proxy when every single URI just returns 401. I trust my reverse proxy doing basic auth a lot more than I trust some php login form.
I always see posters on Lemmy about setting up elaborate VPN setups for as the only way to access internal services, but it seems like awful overkill to me.
VPN still needed for some things that are inherently insecure or just should never be exposed to the outside, but if it is a web service with authentication required a reverse proxy is plenty of security for a home lab.
Even with https if you aren’t on TLS 1.3 the SNI (server name indicator) is not encrypted so the hostname you are trying to access would be visible to your ISP.
Forcing your browser to only use TLS1.3 would fix that but who knows how many sites it would break.