moreentropy

How about just shipping a networkd.conf(.d) config snippet and .network file with the wanted defaults. This is just another instance of I-hate-systemd-for-no-reason whining

P.S. I actually run systemd-nspawn in production, but I am probably the only person on earth to do so.

You're not alone, systemd-nspawn is very much underrated. I have used it a lot for machine containers, though I'm using podman+quadlet+systemd more right now. systemd-nspawn with mkosi for generating workload images is still a nice & powerful ecosystem.

I would consider PIV and SSH through PIV/OpenPGP legacy and undesired nowadays. If you're only interested in state of the art second factor instead of passwords for sensitive use cases, a simple FIDO2 security key w/o all the extra features on a yubikey 5 is enough.

You can solve most of those with only FIDO2 nowadays:

Webauthn with fido/u2f is supported on most websites and oidc providers.

SSH with FIDO and resident / non-resident keys is supported.

PAM -> as documented in the guide, although setting origin and type manually isn't necessary and you can save keys in ~/.config/Yubico so non-root users can manage their keys. I would recommend enabling PIN verification with pamu2fcfg --pin-verification.

LUKS hard disk encryption with FIDO2 for unlocking isn't covered but is possible, systemd-cryptenroll can set this up on modern linux distributions.

While having a YK neo with all the features, I prefer the simple FIDO security key. Everything you could want apart from legacy/special use cases can be achieved with fido.

websites -> fido/u2f ssh -> native fido support in ssh-keygen login -> fido2 for windows, libpam-u2f for linux luks encryption -> systemd-cryptenroll

Currently, it is. The "S" offering is at 2€/month long term. I'm still on a "S" contract that stays at 1€.

Can't complain about 1&1, also had dedicated 1HE boxes there for a long time w/o issues but I understand the grief in case something goes wrong.

I host DNS elsewhere so I can relocate such a simple proxy within a few minutes, that's what my desaster recovery plan looks like.

No specific reason against Cloudflare, just a DIY attutide in this case.

HAProxy is fun, and I also run it as a TCP proxy, so HTTPS is terminated in my (hidden) home server and I don't need to trust my proxy server, I guess that's not possible with cloudflare.

I'm using a Ionos (oneandone) VPS S: https://www.ionos.de/server/vps

1&1/Ionos is one of the largest and best connected ISP and Hosting providers in Germany, not some small shady shop. I see they doubled the price to 2€ though :)

I'm in the same situation (50 Mbps uplink at one place, 100Mbps at another) and that's enough to do all hosting for hobby projects at home, which I really love.

Instead of exposing my home directly using DynDNS, I got a really cheap low end server (currently a VM w/ 1 CPU, 512MB RAM and 400mbps traffic flat) for 1€/month that proxies all traffic to the (hidden) servers hosted at home.

The spec is enough to reliably run a HAproxy that can max out the available bandwidth w/o sweat and it allows me to do failover between servers in my two "home datacenters" + possibly cache assets.

I have some buildroot external trees on github that build images using github actions. It's for personal stuff I needed and only need to update occasionally.

The Buildroot manual is fantastic and it's worth working through the getting started section to get an idea. It boils down to creating a br_external tree that contains everything necessary to create a custom sdcard image as documented here:

https://buildroot.org/downloads/manual/manual.html#outside-b...

Building images from a br_external tree is pretty trivial, see the gitub actions in these example repos:

This builds a raspi4 64 bit image for tvheadend (I'm using this image for a SAT-IP TV dish w/ Kodi clients in my sister's house - so far no complaints about a crashed tv server after 1.5 years of uptime). This image runs the whole rootfs from initramfs w/o mounting a persistent root filesystem. I don't care for the additional ~150MB RAM that is used in this use case:

https://github.com/markuslindenberg/dvbheadend

My most recent buildroot based raspi image builds a 32 bit image pulling binary distribution of openhab and it's recommended jre into the image, running them from a read only root filesystem. I'm using this to reliably run openhab home automation in multiple places. This repo also is a br_external tree and embarrasingly doesn't have a README yet, I really really need to write one becaus I think it's quite useful and mature.

https://github.com/markuslindenberg/habfw

While these tutorials are a great way to teach system administration to those who want to start tinkering, I wish people would put more energy into building well crafted firmware images using frameworks like openembedded or buildroot and teaching people how to use those.

Most of the raspbian-based tutorials or images out there treating the raspberry pi like a normal server are just going to trash the SD or fail because system state is mutating in unexpected ways.

Start building immutable images that hold temporary data strictly in RAM.

I wonder why systemd-nspawn isn't mentioned/used more. I've been using it for years for full system containerization and I'm really happy with how lightweight and functional it is. No need for additinal LXC/LXD layers.

WG exposes a point to point / l3 network interface like any other to userspace, so an answer would not be specific to wireguard but about networking and routing in general.

Network Namespaces and VRFs are the correct way to approach this I think: https://www.kernel.org/doc/Documentation/networking/vrf.txt

sure. freenode for free and open projects and hackint for everything ccc / chaos community related.

That's your most pressing question?

Private messages, relaying for 3rd parties and encryption are prohibited in Ham Radio, so thinking about (international) transactions over ham radio is just plain bullshit. This is the first thing every licensed Ham learns.

What you're looking at here are licensed commercial radio services.

Welcome to enterprise IT. You'll receive your badge in two weeks eventually and your login won't work for another month.

You don't seem to have spent a single minute researching before posting :/

The original implementation is a kernel module. You can find a bunch of (excellent) talks online by wireguard's author which all have a focus on security aspects and avoiding vulnerabilities. Besides, Go and Rust (3rd pty) implementations exist.

I wonder if the Maidenhead locator system devised by radio amateurs in 1980 and still used by all hams today would be a better fit. This uses geocodes not much longer than a zip code which are not random.

It's easy to check if two locators are close just by looking at them and of course I know my locator as it's easy to remember.

https://en.m.wikipedia.org/wiki/Maidenhead_Locator_System

Here is a Google map showing grid locators as you zoom in: https://www.egloff.eu/googlemap_v3/carto.php

The CCCamp 2019 badge will be a (low cost) smart watch called card10:

https://gitlab.hamburg.ccc.de/card10/logix

Yes, TermBot (Fork of ConnectBot with YK support) can use the Authentications key of the OpenPGP applet for SSH using OpenKeychain.

Works like a charm but you need have the key in the OpenPGP applet, not the PIV applet.

Thanks, cattlepi looks super interesting!

I started building "real" firmware for my raspi appliances using buildroot. That makes it super easy to build images that completely run from initramfs without a single write on the sd card (and are fully booted in a few seconds including userland).

Only works if I don't need any local persistence but makes the Pi just work super reliably. Upgrading is as easy as swapping the Linux Kernel image on the fat32 and rebooting.

Is the limit he found CPU bound? IO bound?

I suspect he basically tested some random SD card's performance.

This was exactly my experience from two years ago. But to my surprise with recent gpg2 versions most of those issues are gone (plus EC ssh key files are supported, older gpg-agent could only do RSA)

scdaemon used to crash all the time, that doesn't happen anymore. GPG doesn't lock the card so I have to stop scdaemon to use it w/ other apps.

So for the last half year I've happily used gpg-agent/scdaemon also as SSH agent and it works really well without any issues.

But setting this up (w/ Ubuntu+Gnome) is still a ridiculous task:

- Ensure gnupg2, scdaemon, pinentry-gnome3 are installed

- cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/

- edit ~/.config/autostart/gnome-keyring-ssh.desktop and add "X-GNOME-Autostart-enabled=false"

- edit ~/.gnupg/gpg-agent.conf and add "enable-ssh-support"

Gnome session startup will read both the "X-GNOME-Autostart-enabled=false" and the "enable-ssh-support" and set up and start gpg-agent as ssh agent in the session. There are other ways to disable a .desktop file, but the String "X-GNOME-Autostart-enabled=false" has to be there for this to work.

When all this is set up usability is excellent. the system will even prompt to plug in the right yubikey when you ssh into something. No need to add/remove the card to/from the agent.

While this might improve user experience for some, I don't see the greater value in a VPN solution like this.

It's the fast path to replacing the decentralized internet with a few proprietary CDNs. I'm much more excited about those projects that actually try to fix the raised issues:

Unencrypted connections -> TLS / Letsencrypt

TCP sucks on mobile/roaming devices -> QUIC & HTTP/3

Would love to see FIDO2 / Webauthn in SSH. Working with PKI tokens for key auth works but has to be set up in the client.

He's comparing a language (w/ extensive standard library) with a web application framework.

I'd recommend using Restic (https://restic.net/), it supports backing up to Backblaze B2 and generally is the best and most innovative backup tool I've ever used.

Backblaze has a Restic howto: https://help.backblaze.com/hc/en-us/articles/115002880514-Ho...

Pretty far in the current release. I'm using ffmpeg to encode to HLS/MPEG/AAC and DASH/WebM/OPUS w/ three different bitrates each. All necessary HLS Playlists and DASH Manifests are created and updated, old chunks are automatically deleted.

Depends on how you configure buffers, chunk sizes, key frames and other parameters. It is possible to get the same or better latency with chunked streaming compared to Icecast. With DASH the client knows the timestamps of available chunks and the server time, so it can deliberately play as close to the live edge as possible or keep a larger buffer depending on network conditions.

Edit: If you want really really low latencies (<100ms) you can use WebRTC for broadcast streaming to the browser. If the network has a hiccup it will instantly show in the stream though, so for robustness chunked HTTP streaming is a much better choice at the cost of a few seconds latency.