TCB13

joined 2 years ago
[–] TCB13@lemmy.world 6 points 1 week ago

Audio recordings in this would be useful, but the rest just kills the product.

[–] TCB13@lemmy.world 3 points 1 month ago* (last edited 1 month ago)

At least archive.today actually works to bypass paywalls... and provides content quickly. archive.org is massive and cool but it usually doesn't contain snapshots from paid articles, it is also very very slow, US-controlled and the way you look for a snapshot and move the dates is painfully slow.

[–] TCB13@lemmy.world 1 points 1 month ago

Yeah Microsoft for what's worth does play ball, you can open complaints and they'll actually read those and act fast. Google is a total pain to deal with, even if you're on some type of google partnership they'll not do much.

[–] TCB13@lemmy.world 1 points 1 month ago

It’s also good to make notes on every configuration setting.

I do save my settings for the various programs in a git repository...

[–] TCB13@lemmy.world -4 points 1 month ago (3 children)

If it need documentation means things are over the line when comes to complexity and I should scale down / simplify. :)

Complexity and over-engineering are a serious problem, I really try to keep it as simple as possible so I don't have to waste time managing it, dealing with updates and potential security issues. Simple code/infrastructure breaks less and has less potential insecure points.

[–] TCB13@lemmy.world 1 points 2 months ago

Unless someone finds a way to advertise nodes that doesn't depend on the entry point then yes. Consider this example: https://github.com/bitcoin/bitcoin/blob/1b2460bd5824170ab85757e35f81197199cce9d6/src/chainparams.cpp#L112 if someone takes down those domains it is game over for a new node until someone updates the code.

[–] TCB13@lemmy.world 1 points 2 months ago (2 children)

I get your point, those systems make it harder to take down things permanently but they aren't as resilient and perfect as people paint them to be - an it has nothing to do with being pedantic, it is just the reality of things.

[–] TCB13@lemmy.world 0 points 2 months ago (4 children)

My point was: if you still need some central point of contact what's the point in decentralized, you can still get fucked.

For instance the DHT systems you talk about, they're good but still require some centralized points. In a bittorrent network with DHT a new client cannot join without either a tracker or the knowledge of at least one member of the network to exchange peers with. Bitcoin still has some hardcoded DNS seeds in the core client... etc.

[–] TCB13@lemmy.world 2 points 2 months ago (2 children)

bittorrent decentralization

True bittorrent decentralization never happened.

[–] TCB13@lemmy.world 17 points 2 months ago (17 children)

There's no real / true decentralization. You're always dependent on something, somewhere in some way. It can be harder to shut it down but there's also a point of failure somewhere. Blockchain is all fun and games until you've to consider resource waste and that you still need DNS and IPs working.

 

uSentry is a lightweight, self-hosted Identity and Access Management (IAM) and Single Sign-On (SSO) solution designed for homelab and small-scale environments.

⚡ A single PHP file. < 400 lines of code. No database. No background processes. No cloud. Just works. ⚡

Most IAM and SSO solutions require databases, certificates and background services baked into a dozen containers. This is all fine but also also overkill for homelabs and impossible for low-power ARM devices. uSentry is different, it isn't pretty but it sucks less for a lot of use cases.

Enjoy!

 

Considering a lot of people here are self-hosting both private stuff, like a NAS and also some other is public like websites and whatnot, how do you approach segmentation in the context of virtual machines versus dedicated machines?

This is generally how I see the community action on this:

Scenario 1: Air-gapped, fully Isolated Machine for Public Stuff

Two servers one for the internal stuff (NAS) and another for the public stuff totally isolated from your LAN (websites, email etc). Preferably with a public IP that is not the same as your LAN and the traffic to that machines doesn't go through your main router. Eg. a switch between the ISP ONT and your router that also has a cable connected for the isolated machine. This way the machine is completely isolated from your network and not dependent on it.

Scenario 2: Single server with VM exposed

A single server hosting two VMs, one to host a NAS along with a few internal services running in containers, and another to host publicly exposed websites. Each website could have its own container inside the VM for added isolation, with a reverse proxy container managing traffic.

For networking, I typically see two main options:

  • Option A: Completely isolate the "public-facing" VM from the internal network by using a dedicated NIC in passthrough mode for the VM;
  • Option B: Use a switch to deliver two VLANs to the host—one for the internal network and one for public internet access. In this scenario, the host would have two VLAN-tagged interfaces (e.g., eth0.X) and bridge one of them with the "public" VM’s network interface. Here’s a diagram for reference: https://ibb.co/PTkQVBF

In the second option, a firewall would run inside the "public" VM to drop all inbound except for http traffic. The host would simply act as a bridge and would not participate in the network in any way.

Scenario 3: Exposed VM on a Windows/Linux Desktop Host

Windows/Linux desktop machine that runs KVM/VirtualBox/VMware to host a VM that is directly exposed to the internet with its own public IP assigned by the ISP. In this setup, a dedicated NIC would be passed through to the VM for isolation.

The host OS would be used as a personal desktop and contain sensitive information.

Scenario 4: Dual-Boot Between Desktop and Server

A dual-boot setup where the user switches between a OS for daily usage and another for hosting stuff when needed (with a public IP assigned by the ISP). The machine would have a single Ethernet interface and the user would manually switch network cables between: a) the router (NAT/internal network) when running the "personal" OS and b) a direct connection to the switch (and ISP) when running the "public/hosting" OS.

For increased security, each OS would be installed on a separate NVMe drive, and the "personal" one would use TPM with full disk encryption to protect sensitive data. If the "public/hosting" system were compromised.

The theory here is that, if properly done, the TPM doesn't release the keys to decrypt the "personal" disk OS when the user is booted into the "public/hosting" OS.

People also seem to combine both scenarios with Cloudflare tunnels or reverse proxies on cheap VPS.


What's your approach / paranoia level :D

Do you think using separate physical machines is really the only sensible way to go? How likely do you think VM escape attacks and VLAN hopping or other networking-based attacks are?

Let's discuss how secure these setups are, what pitfalls one should watch out for on each one, and what considerations need to be addressed.

 

The most severe restrictions to the general public are imposed within a 20-mile (32 km) radius of the Green Bank Observatory.[5] The Observatory polices the area actively for devices emitting excessive electromagnetic radiation such as microwave ovens, Wi-Fi access points and faulty electrical equipment and request citizens discontinue their usage. It does not have enforcement power[6] (although the FCC can impose a fine of $50 on violators[7]), but will work with residents to find solutions.

0
submitted 2 years ago* (last edited 2 years ago) by TCB13@lemmy.world to c/selfhosted@lemmy.world
 

The Banana Pi BPI-M7 single board computer is equipped with up to 32GB RAM and 128GB eMMC flash, and features an M.2 2280 socket for one NVMe SSD, three display interfaces (HDMI, USB-C, MIPI DSI), two camera connectors, dual 2.5GbE, WiFi 6 and Bluetooth 5.2, a few USB ports, and a 40-pin GPIO header for expansion.

 

cross-posted from: https://lemmy.world/post/7123708

In this article, you will discover the ISO images that Debian offers and learn where and how to download them. I’ll also provide some useful tips on how to use Jigdo to archive the complete Debian repository into ISO images.

 

Here is what I don't get about Wine. Even in 2023 it seems to fail to handle basic Windows software written in 1996-1995 like the classic convert.exe (https://joshmadison.com/convert-for-windows/). This program and others run flawless in ReactOS for instance, why not under Wine?

Another things I don't get include:

  • Why is Wine is still stuck on that Windows 98 style GUI instead of a more modern thing;
  • Flickering;
  • How can ReactOS, that shares code with Wine, run everything way more smoothly?

For reference I'm using Debian 12, Wine 8.0. Also tried with Soda 7.0, same results.

view more: next ›