The more SSIDs being broadcast the more airtime is wastes on broadcasting them. SSIDs are also broadcast at a much lower speed so even though it’s a trivial amount of data, it takes longer to send. You ideally want as few SSIDs a possible but sometimes it’s unavoidable, like if you have an open guest network, or multiple authentication types used for different SSIDs.
The APs know who the Wi-Fi clients are and just drops traffic between them. This is called client/station isolation. It’s often used in corporate to 1) prevent wireless clients from attacking each other (students, guests) and 2) to prevent broadcast and multicast packets from wasting all your airtime. This has the downside of breaking AirPlay, AirPrint and any other services where devices are expected to talk to each other.
Seconding the RAM issue possibility. If you can, shut down the host and run a memory test over a few days to see if it trips. Memory tests can take days to trip in some circumstances, in others, it’s immediate.
When buying disks do some research for the exact model to ensure they are not SMR drives if you plan on using them in RAID. Some manufacturers will not tell you if they are SMR drives and this can do anything from tank write performance to make the RAID reject the drive entirely.
Seperate DB container for each service. Three main reasons: 1) if one service requires special configuration that affects the whole DB container, it won’t cross over to the other service which uses that DB container and potentially cause issues, 2) you can keep the version of one of the DB containers back if there is an incompatibility with a newer version of the DB and one of the services that rely on it, 3) you can rollback the dataset for the DB container in the event of a screwup or bad service (e.g. Lemmy) update without affecting other services. In general, I’d recommend only sharing a DB container if you have special DB tuning in place or if the services which use that DB container are interdependent.
The snowy mountains are incredible! There’s a series of Shiey videos for B&H where he surfs trains, camps and does a pushbike ride through the mountains: https://redirect.invidious.io/watch?v=V9huXurs678
Good! You wanna automate away a human task, sure! But if your automation screws up you don’t get to hide behind it. You still chose to use the automation in the first place.
Hell, I’ve heard ISPs here work around the rep on the phone overpromising by literally having the rep transfer to an automated system that reads the agreement and then has the customer agree to that with an explicit note saying that everything said before is irrelevant, then once done, transfer back to the rep.
Would be nice to see fines replaced with community service in many cases. Though I feel like you would then need to ensure that those doing community service are compensated the equivalent of their wage(s) prior to conviction if community service requires you use hours otherwise used by your job. Otherwise, somebody dependent on their job effectively pays more for smaller fines due to loss of work. It would also help to prefer out-of-hours community service (weekends for example) to avoid losing hours from your job in the first place. Ideally, jail would be reserved for cases where the person is a genuine danger, rather than use it as punishment.
I used to have all VMs in my QEMU/KVM server on their own /30 routed network to prevent spoofing. It essentially guaranteed that a compromised VM couldn’t give itself the IP of say, my web server and start collecting login creds. Managing the IP space got painful quick.
Run at home/lab to learn AD and also gives you a place to test out ideas before pushing to production. You may be able to run a legit AD server with licensing on AWS or similar if they have a free tier.
Damn! Using .af for a LGBT+ site is insane! The country could have redirected the domain to their own servers and started learning the personal details of those on the site who I imagine wouldn’t be terribly thrilled having an anti-LGBT+ government learn their personal information (namely information not displayed publicly). Specifically, they could put their own servers in front of the domain so they can decrypt it, then forward the traffic on to the legitimate servers, allowing them to get login information and any other data which the user sends or receives.
Buying your own domain often includes DNS hosting but that’s not really the point unless all you’re doing is exclusively running an externally-facing website or e-mail. The main reason for buying a domain online is so everybody else recognises you control that namespace. As a bonus, it means you can get globally-cognised SSL certificates which means you no longer have you manage your own CA and add it’s root to all the devices which wish to access your services securely. It’s also worth noting that you cannot rely on external DNS servers for entries that point to private IPs, because some DNS servers block that.
People who do not wish to buy a GTLD can use home.arpa as it is already reserved. If you are at the point of setting up your own DNS but cannot afford $15 a year AND cannot use home.arpa I’d be questioning purchasing decisions. Hell, you can always use sub-domains in home.arpa if you need multiple unique namespaces in a single private network.
Basically, if you’re a business in a developed country or maybe developing country, you can afford the domain and would probably spend more money on IT hours working around using non-GTLDs than $15 a year.
Soooo…. the work of self-hosting with none of the benefits? It sounds like this has all the core problems of Twitter.