lemmyvore

lemmyvore , 2 months ago

It's not a cost issue. It's about taking responsibility for maintaining a reliable, highly-available service.

I'm pretty sure a solution will be found eventually. EU institutions need IT infrastructure to work and communicate like everybody else and all EU countries have highly available infrastructure like emergency services, secure channels etc. It's just a matter of putting this task in the right context.

It's a very good thing that they've stumbled across this snag because solving it can also open the way for running more internet public services in the EU in an open, transparent manner, and may open the way to weaning ourselves off commercial platforms.

Having a distributed, federated, secure, privacy-friendly and open EU-run messaging platform for example would be a huge boon for its citizens and have wide implications for other regions as well.

lemmyvore , 2 months ago

Unrelated but curious, why do people say that nixpkgs is the largest package repo? Debian unstable has over 200k packages.

lemmyvore , 2 months ago

I've heard a theory that says all the apps and services they make only have the purpose of collecting data. Sort of like limited time experiments. Once they get all they need from one of them they kill it and move on.

Sometimes they pretend to roll a dead service into another product in order to drive customers to that product but it's done only in name, by a completely unrelated team and with only a vaguely related feature subset.

It would certainly explain a lot.

lemmyvore , 2 months ago

Install Tailscale on the remote server and leave it up. Whenever you need to connect to it launch Tailscale on another device that you have access to, and you'll be able to connect to the remote server at its Tailscale IP.

Tailscale consists of a config tool called tailscale and a daemon called tailscaled. The daemon needs to be up for connectivity, and it will raise a network interface called tailscale0 when it works. To connect/disconnect from the tailnet you say tailscale up or down. This is independent of whether the daemon runs or not – that's a separate issue that's usually dealt with by systemd or whatever service manager you use.

Tailscale doesn't need public IPs because all the clients connect outward to a pairing server, which uses STUN to negociate direct connections between the nodes. The connection keys always stay with each client machine, the established connections cannot be snooped by Tailscale, and the clients are FOSS to make sure of that.

If by any chance the ISP of any node does aggressive UDP filtering STUN may not work and result in connections being relayed through a network of so-called DERP servers maintaned by Tailscale. These servers are reduced in number and locations so relayed connections will be bandwidth- and latency-limited. If STUN succeeds you'll only be limited by each node's internet connection.

Tailscale can provide DNS names for the enrolled nodes if you want, but you can also assign fixed IPs to each node in the range 100.64.0.0/10. I'm not a huge fan of the provided DNS because it's a bit invasive (works by replacing /etc/resolv.conf temporarily with a version that resolves via 100.100.100.100 on the tailnet, and integrating it with local DNS can be a chore as you can imagine). There's an option for tailscale nodes to not accept this DNS.

Make sure that services on the remote server that you want to access via Tailnet (also) bind to the Tailscale IP (or to 0.0.0.0).

Should you mess up, so long as the Tailscale client is still up on the remote server and it has an internet connection you can still reach it by enabling the Tailscale "fake" ssh service, which works through the tailscale client rather than a real ssh daemon. But please read up on what it involves to have this fake ssh access available (you don't want to have to issue a command on the remote server to enable it).

lemmyvore , 2 months ago

You mean how to expose the local services on the machine via Tailscale? You can use the TS_DEST_IP env var. Let me show you my compose.yaml:

services:
  tailscale:
    image: tailscale/tailscale:v1.62.0
    container_name: tailscale
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - TS_HOSTNAME=tailnet-node-name
      - TS_AUTHKEY=tailnet-node-key
      - TS_STATE_DIR=/var/lib/tailscale # see below for persistence
      - TS_ACCEPT_DNS=true # to resolve tailnet names (not necessary if you use IPs)
      - TS_USERSPACE=false # to be able to raise tailscale0 interface
      - TS_DEST_IP=local-ip # the IP where you bind services you want to expose
      - TS_ROUTES=192.168.1.0/24 # optionally expose other local devices 
    volumes:
      - "./data/var/lib/tailscale:/var/lib/tailscale" # persist daemon preferences
      - "/dev/net/tun:/dev/net/tun" # to be able to raise tailscale0 interface
    deploy:
      resources:
	 limits:
	   memory: 256M
	   pids: 100
    restart: always

With TS_USERSPACE=false Tailscale will use kernel access to raise tailscale0 and allocate the tailnet IP you've specificed in Tailscale admin.

(TS_USERSPACE=true doesn't use a network interface at all, you have to use a forward HTTP or SOCKS5 proxy. If you use =true and set up a proxy you don't have to use TS_DEST_IP.)

With TS_DEST_IP you can bridge the tailnet IP to a local IP. By choosing that local IP well you can expose services to Tailscale selectively.

The simplest approach is to have docker services listen on 0.0.0.0 (happens by default if you don't specify IP in the "ports:" section, and put the machine's loopback or LAN IP in TS_DEST_IP. That way you'll expose all the services automatically.

But you can also expose things explicitly. Let's say the machine LAN IP is 192.168.1.1. You make up 10.100.100.100 on the host specifically for Tailscale exposure so you say TS_DEST_IP=10.100.100.100. Then in your "ports:" section in compose you add ports explicitly depending on what you want them exposed on. Let's say you want Jellyfin exposed on both LAN and Tailscale, you add an entry for - 192.168.1.1:8096:8096/tcp and one for - 10.100.100.100:8096:8096/tcp. You only want CUPS exposed on the LAN not on Tailscale so you only add - 192.168.1.1:631:631/tcp for it. For Deluge you want to use the web interface on the LAN so you say - 192.168.1.1:8112:8112/tcp but you want RCP over Tailscale so you can use a phone admin app so you say - 10.100.100.100:58846:58846/tcp.

You get the idea. Yeah it's a bit more work to specify everything explicitly but it's a lot more precise (and you can still use the default and listen on 0.0.0.0 for when you want to expose everywhere).

lemmyvore , 2 months ago

Does Audacity still only work with ALSA? Wish they'd use at least pulse if not pipewire...

lemmyvore , 2 months ago

Can it also record from Pulse?

lemmyvore , 5 months ago

For those curious how efficient these things are, recently I did some tests using this tool (clear your cache between tests).

I had decided to install an additional DNS blocker on my OpenWRT router so I was curious how these methods stack up against each other.

I tested uBlock Origin (default lists, reports 116k network filters), the Firefox (122) built-in ETP (Enhanced Tracking Protection) and the router adblock (only a modest 65k IPs in the default set, you can add more lists).

• Everything off gives me a score of only 3% blocked. Those 3% must be stuff so outrageous that they probably get blocked by upstream DNS servers.
• Firefox ETP only, set to strict: 41%
• Router adblock only: 69%
• Firefox + router both on: 83%
• uBlock Origin (alone or in combination): 97%

lemmyvore , 4 months ago

It's the Adblock package for OpenWRT. The default selection is
adaway, adguard, disconnect, yoyo, which is 3 x 10k lists and one 30k list.

I see that it has support for compiling Steve Black lists but SB can vary 50 - 500k and I only have a router with 128 MB RAM. I'll have to experiment with the "standard" SB list, see if it fits and if it makes any difference.

lemmyvore , 5 months ago

You seriously need to stop what you're doing. Log in with ssh only. If you need multiple terminals use multiple ssh sessions, or screen/tmux. If you need to search something do it on your desktop system.

The server should not have Firefox installed, or KDE, or anything related to desktop apps. There's no point and nothing good can come of it.

lemmyvore , 7 months ago

Good in what sense? Firefox is already blocking third party cookies as part of its enhanced tracking protection (which you should set to "strict" level, go do that right now if you didn't already).