because it's pretty hard to recommend anything you don't use. Seeking advice on a distribution in geek forums, therefore, is a losing plan right from the start. It's smarter to install whatever you want and then come to the forums with your problems.

What's the value of this advice? You can google the same thing in about 2 minutes. People usually expect real-world experience.

own only what is available to a farmer from the past (a piece of land and a couple of barns), desire only what is available to a farmer from the past (a hearty dinner and strong tobacco, not a new iPhone), and then you can live like a farmer from the past today.

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.

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.

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.

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.

not a very popular opinion, but if you want an inexpensive, really inexpensive variant, take the AMD MX9070XT. AMD is not the most popular AI cards, but they are not bad with ROCm and for the price of 5090 you can put 5 cards (80 GB vram)

I've been running all my servers and my work computer on Arch since around 2018, ever since Ubuntu started shoving snaps everywhere. Even the instance I'm writing this from is running Arch. Overall, everything is great. The instance has 98-99% uptime. No issues with the work PC either.

UPD: While rereading the post, I remembered that rabbitmq was recently broken in the repositories. But everything was solved with a two-minute rollback and blocking of the version in pacman.

UPD2: I build packages with my hands periodically. It's not like I haven't done the same thing on Ubuntu or CentOS. On Arch make PKGBUILD really more easy then spec file for CentOS or deb structure for ubuntu. On Ubuntu this is really awful.

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.

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 relax, buddy. How many downvotes there? Dozens? Hundreds? There are 7 billion people on the planet. It's impossible to please everyone. and that's okay. in the end, they at least bothered to press the button. in this sense, indifference is much worse.

I don't know about you, but I believe that the people who gave me a negative review can still create content that interests me. After all, if a person doesn't agree with my opinion, it doesn't make their comments and posts any worse for me. Otherwise, i can say something stupid that i would be ashamed to reread in 5 years and then block half of the platform.

Lemmi already has one of the softest voting systems. on Habr, for example, if your rating is negative, you can't write comments at all.

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.

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.

Just looking for "minipc pfsense"

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.

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.

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.