nitrolife

If you’re installing an HBA at home, it’s better to immediately install something like a Noctua NF-A4x10 on it. You should also immediately check the type of hardware initialization. If the system boots into EFI and the HBA is old and only supports BIOS, there may be problems. Otherwise, everything works perfectly with almost every device.

Because of the Wayland architecture, you simply cannot do it differently. Because Wayland is not a window manager, but a subsystem for working directly with video. This is not a new X11 server, it’s a different architecture. Therefore, by default, no matter where you choose, the render will be output to tty0 of your main server. You have only 2 options - use Wolf as is or manually assemble https://github.com/games-on-whales/gst-wayland-display and limit it to one video card via systemd. gst-wayland-display literally forcibly transfers the render not to tty0, but immediately to the stream for Moonlight.

So it’s not that Wolf is too complicated, it’s just that what you want is a rather complicated case.

UPD: although it is possible that you will be able to do this using wlheadless-run, but this will most likely be worse in terms of performance compared to gst-wayland-display. Although for a simple KDE session, I think there is no difference.

UPD2: I checked and, as I thought, regular applications will get along fine if you run them through wlheadless-run, but everything that requires vulkan may break. it’s the same with video cards. Simply specifying primary will not guarantee the use of a fixed card. But just for office work, I think it will be fine. however, as soon as the case starts to go beyond the standard, everything will start to break down if you have more than one GPU.

Just use wolf: https://games-on-whales.gitbook.io/wolf/stable/en/user/quickstart.md. Everything is ready out of the box. However, for a KDE session, you’ll have to rebuild KDE in the container instead of wolf-ui.

Never mind what’s ideal, in reality, one of my servers is running on a Core 2 Duo T7600 and when I installed ubuntu on it, it took 24 minutes to boot due to the unzipping of the base snap image in ubuntu server. Older hardware does not become faster just because os requirements change. And yes, I left ubuntu as soon as snap came out, i think that was 2018.

UPD: and of course I’m not going to change one of the local servers just because Canonical decided to release another system. Thanks. For 20 years the processor has been routing packets and will do so for another 20 without any problems. Just switched to another OS.

SNAP in the recommended packages of the ubuntu-server metapackage. Ubuntu installs all recommended packages by default. So SNAP is in the server installation, moreover, it can’t even be simply removed without completely blocking in apt policy.

SNAP also doesn’t work well with old hardware because of compression. It’s ironic to recommend system riddled with incompatible compression to someone who explicitly wrote in a post that they would be using outdated hardware.

If you’re planning to use old hardware for hosting, don’t use Ubuntu. SNAP will kill performance.

So your choice is Debian.

P.S. VPS is already a Virtual Private Server and you can’t install ProxMox or any virtualization on it. If you want experiments, look into containers.

In any program, you still have to execute a challenge somewhere. No program will issue certificates without that. In the case of certbot, you can simply write a small post hook that will transfer the certificates to cloudflare.

Just don’t expose SSH to internet. It’s a complex protocol with many CVEs. And you realyy don’t need access to SSH from anywhere. Replace access from ineternet to a WireGuard tunnel that has almost zero attack surface area and properly configured iptables rules. And that’s it.

I think the problem has been slightly exaggerated. If you’re not hosting several dozen services, you can reduce your attack surface down to one Nginx server. For an even stricter setup, just enable mTLS.

I think in the fediverse such services are not designed for fully private mode. And to be honest I can’t even remember any other services. Maybe set up an instance of Mastodon and defederate it, plus add something like basic auth. But that’s not a ‘out of the box’ solution.

The first step is to understand what you want exactly. Microblogging like Twitter? A social network like Facebook? A video hosting like YouTube? This depends on a lot. Lemmy communities can’t be closed out of the box, but YouTube for example can be closed to registered users or with a private link.

Good. It seems I unconsciously used my own experience. In my country, even having users limit on a platform requires you to register with the state service.

In that case, it doesn’t matter much what you set up. If you just need a chat, Matrix is a good option. Or maybe Mattermost if you need a nice client. There are also several social network platforms in the Fediverse.

Well then, your choices are: 1. Buy a server under a false name 2. Never connect directly to the server or the host’s site. Use proxies for management (preferably proxies in another country). 3. Change keys more often. 4. Reinstall the system on a VPS so that the disk is fully encrypted in case the VPS is seized or management is intercepted. LUKS is the best choice. 5. Don’t keep any logs on the server.

Even with all this, your VPS provider can still reveal the addresses of everyone who connected to the instance, so the most challenging part from a user experience perspective is: none of your users should connect directly to the instance, only through proxies or VPNs on other nodes.

Honestly, it’s much easier to publish an instance on Tor or I2P networks. But in any case, even if the server is published on I2P, follow all the points from the first paragraph.

UPD: honestly, it’s better to put a i2p Floodfill router on a VPS to support the anonymous network within the country. And promote node hosting. This will give much more benefit. Publishing something inside an anonymous network is much less risky than on the internet, though caution must still be exercised.

My provider doesn’t provide IPv6, but I rented a server in a data center, bought a subnet, and tunneled it home via WireGuard. So the scheme is roughly: VPS (fd00:1::/64) <-> (fd00:1::/64) Home router (realv6/64) <-> Home network

Router configuration:

/etc/sysctl.d/10-ipv6-privacy.conf

net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1

/etc/radvd.conf

interface br0 {
    AdvSendAdvert on;
    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 30;

    AdvManagedFlag on;      # M=1 → Address via DHCPv6
    AdvOtherConfigFlag on;  # O=1 → Additional options via DHCPv6

    # SLAAC is still possible for Android
    prefix realv6::/64 {
        AdvOnLink on;
        AdvAutonomous on;   # Allow SLAAC
    };

    RDNSS realv6::1 {
        AdvRDNSSLifetime 1800;
    };
    DNSSL home.lan {
        AdvDNSSLLifetime 1800;
    };
};

/etc/kea/kea-dhcp6.conf

{
  "Dhcp6": {
    "interfaces-config": {
      "interfaces": [ "br0" ]
    },

    "lease-database": {
      "type": "memfile",
      "persist": true,
      "lfc-interval": 86400,
      "name": "/var/lib/kea/dhcp6.leases"
    },

    "renew-timer": 21600,
    "rebind-timer": 43200,
    "preferred-lifetime": 43200,
    "valid-lifetime": 86400,

    "subnet6": [
      {
        "id": 1,
        "subnet": "realv6::/64",
        "interface": "br0",
        "pools": [
          { "pool": "realv6::1000 - realv6::ffff" }
        ],
        "option-data": [
          { "name": "dns-servers",   "data": "realv6::1" },
          { "name": "domain-search", "data": "home.lan" }
        ]
      }
    ],

    "loggers": [
      {
        "name": "kea-dhcp6",
        "output-options": [
          { "output": "stdout" }
        ],
        "severity": "WARN"
      }
    ]
  }
}

And of course, iptables is necessary. Something like: /etc/iptables/ip6tables.rules

# Generated by ip6tables-save v1.6.0 on Thu Sep  8 13:29:11 2016
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
#BASE INPUT
-A INPUT -i eno1 -j DROP
-A OUTPUT -o eno1 -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eno1 -j DROP
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p ipv6-icmp -j ACCEPT
COMMIT

Just looking for “minipc pfsense”

if you have an uplink of 1 Gbit/s or less, you can easily solve the problem of ports by purchasing a switch for $3. By the way, there is a mini PC with 4/6/8 ports and even with optical fiber.

and in general, if topic starter build own server, he can just build a router out of it too. the set of programs is not very large: kea-dhcp, radvd, iptables. that’s all. for WiFi, you will need a compatible card in the server or a separate access point like ubiquity.

I think 1 modifications fix this: User migration via Lemmy federation. When you can migrate from Instance to instance with old profile (comments, posts and all another) what instance you choice right now don’t importand.

Without display? Ok. But wolf can stream xfce inside podman.

You need virtual dislay so that meat that you don’t connect video card to TV. Maybe best choice - use wolf? No DE, no display. Just GPU and podman.