[-] sudo@programming.dev 8 points 8 hours ago

The good news is it won't be full bipartisian. Plenty of junior politicians know which way the wind is blowing here. But its still going to pass and it will be largely bipartisan.

[-] sudo@programming.dev 13 points 9 hours ago

Operation Paperclip was real but the CIA wasn't founded by (German) Nazis. IIRC NATO had ex-nazis in its founding but they were like Wehrmacht or politicians not SS.

Now the CIA did organize former SS agents in West Germany to act as terrorists/partisans should the Soviets invade in the German version of Operation Gladio.

[-] sudo@programming.dev 5 points 12 hours ago

That would be Henry Gao.

[-] sudo@programming.dev 4 points 2 days ago

It was pushed back down to panama before but it took half a century (1950-2000) to do it. All that effort undone by some kid named big balls.

[-] sudo@programming.dev 1 points 2 days ago

"More easily configurable" would be more accurate, because there's less things that could get in your way. The system is designed to make it as simple as possible from a developers perspective.

[-] sudo@programming.dev 4 points 2 days ago

That wouldn't have fixed the AUR incident because the attacker updated the PKGBUILD which is roughly the same as the nixfile. And there are no packages provided by the AUR, just PKGBUILDs. You always build the package yourself locally.

[-] sudo@programming.dev 2 points 2 days ago

Official packages are already vetted so they don't need user scoping. They could just enforce user scoping in the AUR and use the provides array for resolving conflicts. Its not a perfect solution but there's no such thing as perfect security, just better security.

Also having an AUR helper that properly containerized the build step would be an even bigger improvement.

[-] sudo@programming.dev 8 points 2 days ago

Arch is deliberately minimal making it a good base system in the same way Debian or Fedora is. It's smaller, simpler, updates faster than the others and is far more configurable. It is however not built for the average user and most distros built on top of it that try to make it more "usable" are IMO pretty dangerous ideas. I think the only derivative i've tried that was good was SteamOS because they made it Atomic like nix or silverblue.

None of this really has to do with the AUR. That was always labelled as "use at your own risk". And to their credit they caught and addressed the attack within a day of it happening. Still, hosting user PKGBUILDs and leaving it to individual users to audit them is not a secure solution, its just punting on the responsibility.

[-] sudo@programming.dev 10 points 2 days ago

npm: Node Package Manager.
AUR: Arch User Repository.

Bazzite is based on fedora not Arch so you don't need to worry.

[-] sudo@programming.dev 6 points 4 days ago

The batteries inside the pack are far cheaper. Opening the pack to replace them will be a challenge.

[-] sudo@programming.dev 6 points 4 days ago* (last edited 4 days ago)

The US is letting Iran access its own money that the US had frozen with sanctions. Same as with the JCPOA. The US tax payers are not footing this bill.

Update only $25B is from frozen assets, the $300B is from the GCC. The people we dragged into this war are footing the bill. LOL fuck the UAE.

6
submitted 2 weeks ago* (last edited 2 weeks ago) by sudo@programming.dev to c/tailscale@programming.dev

The goal is to share an http service privately on my tailnet but with an HTTPs connection. It seems others have spent lots of time figuring out and never sharing their solutions. I just got a setup to work satisfactorily so I'll share it. Criticism is welcome. First a few notes:

  • I'm using headscale on a VPS behind Caddy.
  • Official tailscale allegedly can do this out of the box with tailscale serve or tailscale cert.
  • Headscale supports tailscale serve but not with https. Maybe if I removed caddy and let headscale to https directly it would. I haven't tested that yet.
  • Yes I know https over wireguard is redundant. This effort is not only to make Firefox shut up but to make some clients that demand https work.

I also have deliberately avoided the "Private CA" because installing the cert of every client on my tailnet sounds like a nightmare. If someone can prove me wrong there, please share.

The context

  1. I have a VPS and a public domain with DNS A and AAAA records that point all sub domains *.mydomain.net to that VPS.
  2. The VPS runs caddy and headscale and is on the tailnet itself.
  3. Caddy route the hs subdomain to headscale.
  4. I have numerous devices on my tailnet, many running different http services but only some of them I want public.
  5. I can publicly expose a service with https by simply adding an entry to caddy like so,
publicservice.mydomain.net {
    reverse_proxy privatehost:8080
}

Restart caddy and that's it.

The solution

First, I used sub domains of the public domain instead of headscales base domain. eg Use *.ts.mydomain.net instead of ts.net. I made a *.ts.mydomain.net A record pointing to my servers public IP. Caddy will automatically fetch https certificates for any *.mydomain.net domains automatically. It cannot for a domain not routed to it. (DNS01 authentication might circumvent this but I haven't tested that yet).

Second, I restrict caddy to only accept tailscale connections by using the bind directive. Otherwise it will accept and route public traffic. A caddy entry for a private service would look like this,

privateservice.ts.mydomain.net {
    bind 100.64.0.1 [fd7a:115c:a1e0::1]
    reverse_proxy privatehost:8081
}

The IP addresses come from the output of tailscale ip on the caddy/headscale machine.

Now privateservice.ts.mydomain.net routes to the caddy server with https but it gets a default blank 200 response from caddy because its coming from the machine's public IP instead of the tailnet.

The last step is to configure headscale's DNS to route private services to the headscale server on its its tailscale IP instead of the public IP.

# /etc/headscale/config.yaml
# ...
dns:
  magic_dns: true
  # base_domain is irrelevant
  nameservers:
    global: [ whatever ]
    split:
        # required to override the public dns records
        ts.mydomain.net: 100.100.100.100
  extra_records:
     - type: "A"
       name: "privateservice.mydomain.net"
       value: "100.64.0.1"
     - type: "AAAA"
       name: "privateservice.mydomain.net"
       value: "fd7a:115c:a1e0::1"
     # repeat for each service, always the same IPs

You can have base_domain be whatever or make it ts.mydomain.net if you want to be consistent and aren't worried about collisions with your extra records.

I tried using wildcard DNS records in headscale and it didn't work. It felt like it completely broke DNS without any clear warnings or errors. Idk if that's a bug or what. DNS just timed out internally

Limitations

All internal HTTPS traffic is routed through my VPS instead of directly peer to peer, which is a real bummer for internal latency. I think the only way around that is to give each internal host their own caddy server, have the DNS records point directly to them, but then use a private CA and all the hassle that's worth. Maybe DNS01 challenges will work...

Also while I have no public records indicating what private subdomains I have beyond *.ts.mydomain.net for DNS, I do have them for my TLS certificates... somewhere. I'm not super concerned about that though. I think only a private CA will hide those.

12
CPU barely detected (programming.dev)
submitted 7 months ago by sudo@programming.dev to c/buildapc@lemmy.world

I recently swapped motherboards between two builds. One went well but the other is being very finicky with detecting the CPU. Right now its laying on its side like a beached whale with the left side panel open. The heatsink is simply sitting on the CPU, no mounts, no fans. Sometimes I can strap the heatsink down, stand up the box, and close the case, but never with the fans on. Its like that's too much weight and some connection is broken. Is anyone familiar with this problem?

I had this issue previously with a different motherboard and fixed it by using a stock heatsink. But this is a fairly simple CoolerMaster 212. Its not massive. I feel like its a problem with the board or the socket.

More details: when uninstalled the old motherboard in this build, it had the same CM212 heatsink in it. When I removed that heatsink the CPU (Ryzen 5700) came out with it to my horror. Neither that CPU or that motherboard are in this build though. But that CPU was supposed it be. It did have bent pins and I did try to install it before discovering the bent pins. After straightening them the CPU still didn't work so i switched to an old Ryzen 1600, which is currently being finicky. Maybe I damaged the motherboard socket?

21

I start my coding workspaces in tmux sessions which persist when I log out. If I switch from a wayland session to an x11 session, then my copy and paste functionality in those neovim sessions are broken because it's still trying to use wl-copy. To be more precise:

  1. Start a wayland session.
  2. Open a terminal and start a tmux session.
  3. Open neovim and do some work.
  4. Log out of wayland, log into an X11 environment
  5. Open a terminal and reconnect to the tmux session
  6. "+y broken. clipboard: error invoking wl-copy: Failed to connect to a Wayland server...

Restarting neovim isn't sufficient. I have to restart the entire tmux session or switch back to wayland. Is there some short cut I can take here?

23

Everything I read says it's a feature enabled in what ever compositor you choose, if your compositor supports it. Why isn't there a general purpose keybinding program like setxkbmap? Does it just not exist yet or must it be built into the compositor?

I've read [this stackexchange thread] on something related but it all seems to be using XKB which should imply I'm using XWayland?

view more: next ›

sudo

joined 2 years ago