All of the modern yubikeys (and it looks like the nitro keys as well) can have fido2 enabled so that you can use them as a hardware token for sites that support passkeys. I think yubikeys come with only OTP enabled so you need to download their utility to enable the other modes.

If you are a Linux user (that’s required to be on Lemmy right?) you can use either the fido2 or ccid (smart card through pkcs11) mode to keep SSH keys protected. The fido2 ssh key type (ed25519-sk) hasn’t been around that long so some service might not support it. The pkcs11 version gives you a normal RSA key, but is harder to get setup, and if you want extra security they don’t have any way to verify user presence. With fido2 you can optionally require that you must physically touch the key after entering the pin.

There are also pkcs11 and fido2 pam modules so you can use it as a way to login/sudo on your system with an easy to use pin.

And if you have a luks encrypted volume you can unlock that volume with your pin at boot with either pkcs11 or fido2.

Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248

If you are on an Ubuntu based distro initramfs-tools doesn’t build the initramfs with the utilities required for doing that. The easiest way to fix that is to switch to dracut.

Dracut is officially “supported” on 24.10 and is planned to be the default for Ubuntu 25.10 forward, but it can work on previous versions as well. For 24.04 I needed hostonly enabled and hostonly_mode set to sloppy. Some details on that in these two links:

https://askubuntu.com/questions/1516511/unlocking-luks-root-partition-with-fido2-yubikey-and-ideally-without-dracut

https://discourse.ubuntu.com/t/please-try-out-dracut/48975

So a single hardware token can handle your passkeys, your ssh keys, computer login, and drive encryption. Basically you will never have to type a password ever again.

If your NAS has enough resources the happy(ish) medium is to use your NAS as a hypervisor. The NAS can be on the bare hardware or its own VM, and the containers can have their own VMs as needed.

Then you don’t have to take down your NAS when you need to reboot your container’s VMs, and you get a little extra security separation between any externally facing services and any potentially sensitive data on the NAS.

Lots of performance trade offs there, but I tend to want to keep my NAS on more stable OS versions, and then the other workloads can be more bleeding edge/experimental as needed. It is a good mix if you have the resources, and having a hypervisor to test VMs is always useful.

If you have Ethernet cables that are old or have damaged ends in your pile just sacrifice them to make your own cable ties. Cut it into pieces as long as you need to wrap your other cables and in each section you cut you get four twist ties.

Cheap, readily at hand, and if the cables were bad you can call it recycling.

If you are just using a self signed server certificate anyone can connect to your services. Many browsers/applications will fail to connect or give a warning but it can be easily bypassed.

Unless you are talking about mutual TLS authentication (aka mTLS or two way ssl). With mutual TLS in addition to the server key+cert you also have a client key+cert for your client. And you setup your web server/reverse proxy to only allow connections from clients that can prove they have that client key.

So in the context of this thread mTLS is a great way to protect your externally exposed services. Mutual TLS should be just as strong of a protection as a VPN, and in fact many VPNs use mutual TLS to authenticate clients (i.e. if you have an OpenVPN file with certs in it instead of a pre-shared key). So they are doing the exact same thing. Why not skip all of the extra VPN steps and setup mTLS directly to your services.

mTLS prevents any web requests from getting through before the client has authenticated, but it can be a little complicated to setup. In reality basic auth at the reverse proxy and a sufficiently strong password is just as good, and is much easier to setup/use.

Here are a couple of relevant links for nginx. Traefik and many other reverse proxies can do the same.

How To Implement Two Way SSL With Nginx

Apply Mutual TLS over kubernetes/nginx ingress controller

The biggest question is, are you looking for Dolby Vision support?

There is no open source implementation for Dolby Vision or HDR10+ so if you want to use those formats you are limited to Android/Apple/Amazon streaming boxes.

If you want to avoid the ads from those devices apart from side loading apks to replace home screens or something the only way to get Dolby Vision with Kodi/standard Linux is to buy a CoreELEC supported streaming device and flashing it with CoreELEC.

List of supported devices here

CoreELEC is Kodi based so it limits your player choice, but there are plugins for Plex/Jellyfin if you want to pull from those as back ends.

Personally it is a lot easier to just grab the latest gen Onn 4k Pro from Walmart for $50 and deal with the Google TV ads (never leave my streaming app anyways). Only downside with the Onn is lack of Dolby TrueHD/DTS Master audio output, but it handles AV1, and more Dolby Vision profiles than the Shield does at a much cheaper price. It also handles HDR10+ which the Shield doesn’t but that for at isn’t nearly as common and many of the big TV brands don’t support it anyways.

I’ve got about 30 zwave devices, and at first the idea of the 900mhz mesh network sounded like a really solid solution. After running them for a few years now if I were doing it again I would go with wifi devices instead.

I can see some advantages to the mesh in a house lacking wifi coverage. However I would guess most people implementing zigbee/zwave probably have a pretty robust wifi setup. But if your phone doesn’t have great signal across the entire house a lightswitch inside of a metal box in the wall is going to be worse.

Zwave is rather slow because it is designed for reliability not speed. Not that it needs to be fast but when rebooting the controller it can take a while for all of the devices to be discovered, and if a device goes missing things break down quickly, and the entire network becomes unresponsive even if there is another path in the mesh. Nothing worse than hitting one of your automations and everything hangs leaving you in the dark because one outlet three rooms over is acting up.

It does have some advantages, like devices can be tied to each other (i.e. a switch tied to a light) and they will work even without your hub being up and running (zwave controller I think can even be down).

Zwave/Zigbee also guarantee some level of compatibility/standardization. A lightswitch is a lightswitch it doesn’t matter which brand you get.

On the security front Zwave has encryption options but it slows down the network considerably. Instead of just sending out a message into the network it has to negotiate the encrypted connection each time it wants to send a message with a couple of back and forth packets. You can turn it on per device and because of the drawbacks the recommendation tends to be, to only encrypt important things like locks and door controls which isn’t great for security.

For Zwave 900mhz is an advantage (sometimes). 900mhz can be pretty busy in densely populated areas, but so can 2.4 for zigbee/wifi. If you have an older house with metal boxes for switches/plaster walls the mesh and the 900mhz penetration range may be an advantage.

In reality though I couldn’t bridge reliably to my garage about thirty feet away, and doing so made me hit the Zwaves four hop limit so I couldn’t use that bridge to connect any additional devices further out. With wifi devices connecting back to the house with a wifi bridge, a buried Ethernet cable, etc can extend the network much more reliably. I haven’t tried any of the latest gens of Zwave devices which are supposed to have higher range.

The main problem with wifi devices is that they are often tied to the cloud, but a good number of them can be controlled over just your LAN though. Each brand tends to have their own APIs/protocols though so you need to verify compatibility with your smart hub before investing.

So if you go the wifi route make sure your devices are compatible and specifically check that your devices can be controlled without a cloud connection. Especially good to look for devices like Shelly that allow flashing of your own firmware or have standardized connection methods in their own firmware (Shelly supports MQTT out of the box)

All of the “snooping” is self contained. You run the network controller either locally on a PC, or on one of their dedicated pieces of hardware (dream machine/cloud key).

All of the devices connect directly to your network controller, no cloud connections. You can have devices outside of your network connected to your network controller (layer 3 adoption), but that requires port forwarding so again it is a direct connection to you.

You can enable cloud access to your network controller’s admin interface which appears to be some sort of reverse tunnel (no port forwarding needed), but it is not required. It does come in handy though.

As far as what “snooping” there is, there is basic client tracking (what IP/mac/hostnames) to show what is connected to your network. The firewall can track basics like bandwidth/throughout, and you can enable deep packet inspection which classifies internet destinations (streaming/Amazon/Netflix sort of categories). I don’t think that classification reaches out to the internet but that probably needs to be confirmed.

All of their devices have an SSH service which you can login to and you have pretty wide access to look around the system. Who knows what the binaries are doing though.

I know some of their WISP (AirMAX) hardware for long distance links has automatic crash reporting built in which is opt out. There is a pop up to let you know when you first login. No mention of that on the normal Unifi hardware, but they might have it running in the background.

I really like their APs and having your entire network in the network controller is really nice for visibility but my preference is to build my own firewall that I have more control over and then Unifi APs for wireless. If I were concerned about the APs giving out data, I know I could cut that off at the firewall easily.

A lot of the Unifi APs can have OpenWRT flashed on them, but the latest Wifi7 APs might be too locked down.

Yeah like I said it only works if they don’t look too deep.

My assumption would be that they aren’t going to bother to go to court if they can’t see any public records (vehicle registration, titles, etc) without liens that they would be able to get money out of.

So if they don’t bother to check who the lien holder is they will likely just move on to the next person to squeeze money out of.

And yeah if they do go to court the scheme will quickly fail, but the whole reason these people think their magic incantations work is because the courts/creditors/etc often just ignore them because it ends up costing more to fight them than to properly enforce the law/contracts.

If you owe money they can still sue you and the court can force you to turn over assets.

There are some protections around the court taking away your primary residence, but I don’t think there is anything stopping them from taking away automobiles (likely varies state to state).

So I wasn’t talking about the original lein holder repossessing th vehicle, but instead other creditors that now see assets that are open on the books and seeking legal action to get their money back. Unlikely they will want to pay lawyers to do that for your car, but still possible.

Presumably saying that if the loan is discharged that means there is no longer a lien on it. Putting one on it yourself (if that is possible?) might prevent creditors from using the courts to repossess it to get their money back. In reality the best it might do is to make them think it isn’t an asset they can come after you for if they don’t look close enough at the lien holder.

I am not a SAN admin but work closely with them. So take this with a grain of salt.

Best practice is always going to be to split things into as many failure domains as possible. The main argument being how would you test upgrades to the switch firmware without potentially affecting production.

But my personal experience says that assuming you have a typical A/B fabric that is probably enough to handle those sorts of problems, especially if you have director class switches where you have another supervisor to fail back to.

I’ve personally seen shared dev/prod switches for reasonably large companies (several switches with ~150 ports lit on each switch), and there were never any issues.

If you want to keep a little separation between dev and prod keep those on different VSANs which will force you to keep the zones separated.

Depending on how strict change management is for your org keep in mind that tangling dev+prod might make your life worse in other ways. i.e. you can probably do switch firmware updates/zoning changes/troubleshooting in dev during work hours but as soon as you connect those environments together you may have to do all of that on nights and weekends.

Before I had the helmet units I used to ride with in-ear wired headphones. Those worked pretty well but as you put the helmet on it often pulled at least one side slightly out of your ear making a worse seal. In ear means you also get some hearing protection as well which it is always good to have, especially at highway speeds or if you have loud exhaust. I will say the audio quality/clarity/volume going this route is unbeatable. If all you want is music finding an in-ear solution will be much better than speakers in your helmet. Especially if you have a loud exhaust.

You can get relatively high quality wired headphones for quite cheap that are very low profile.

I would think any wireless headphone like airpods would probably be too big to stay in when you put your helmet on, but you might be able to make it work.

One issue with headphones is that it is probably not legal in most placese, so be cautious about that. You can easily rip them out before the police would notice anyways, but still a risk.

If you go the Sena/Cardo route you should consider hearing protection as well. I usually use the foam inserts. It sounds counterintuitive but having the earplugs in actually makes the speakers easier to hear. They tend to filter the wind noise but the more direct sound from the speakers can get through.

I’ve run both Cardo (Packtalk Slim, Packtalk Edge), Sena (30k), and some $30 Amazon units and very much prefer Cardo units.

The first thing to do is ask any friends you might ride with what they use. It’s been a while since I tried, but getting Sena to pair with anything other than Sena used to be quite a pain.

The Sena units hardware seems a little better, and the phone software may be a little more polished, but the actual comms are terrible. Filtering of background noise is nowhere near as good as Cardo, and general audio clarity is much better on Cardo.

Probably fixed by now but all sorts of problems with mesh pairing and pairing in general on the Senas.

Cardos work well enough, still a bit of a pain to get things paired sometimes, but you can do the whole process from the phone app so you don’t need to know button combos.

Cardo’s Bluetooth bridge capability is awesome if you have a group of Cardo users and the occasional Amazon user that you want to bring into the mesh. The mesh connects all of your Cardo units together and each Cardo unit can use its Bluetooth bridge to bring in one normal Bluetooth headset. I don’t recall if we could get this working to bring Sena units into the group but I have seen release notes saying they improved compatibility so maybe it works now.

I know a couple of people with Shoei helmets with the built in Sena hookups so they get forced into Sena. Seems like the hardware for the integrated units lags behind (took them a few extra years to get a mesh option), and you are certainly locking yourself in. I would personally prefer to not have myself locked in.

If you plan to ride with multiple people getting everyone on the same system especially with mesh units is a must. We just have one big mesh group with everyone we know and as soon as you meet up everything auto connects and is good to go.

The $30 Amazon units actually work well too. Probably not remotely waterproof, and they can usually only connect to one rider at a time, but for the price you might want to start there.

Video is old now but maybe still relevant: https://youtu.be/-AMoXbXHALc

He recommends the Packtalk Slim because it is so low profile, but the new Packtalk Edge is removable, has a lower profile than the old Bolds, uses USB-C, fixes most of his problems with the removable ones and lets you charge without tethering directly to your helmet.

The slims are also little less waterproof because they are more complicated with more wires in and out. The edge being self contained, I would expect to have much better water resistance (haven’t had to take my edges apart yet so I can’t say that for sure).

I’ve had a group of us with slims in pouring rain for three hours and they did survive, one or two had some issues with buttons afterwards but they still functioned. Not sure I can even blame it on the units as we had those universal magnetic charger buttons plugged in which kept the little rain cover open at the back.

Also had one Slim unit where the microphone cable went out, not perfect, but warranty is usually pretty good. Again a win for the Edge/Bold removable units because those cables are separate from the unit itself so you could buy a helmet kit if it fails out of warranty.

Is there anything that really makes their job shittier about this though? Than than dealing with three orders instead of one?

If anything with the focus these days on metrics around how fast they can serve customers these three simple orders probably made their metrics look better so they could slack off on the next few orders.

But yeah just says “I’m a cheapskate.”

Assuming you mean hot plugged devices (thumb drives and external drives) KDE mounts them under /media

If you are expecting them to auto mount, KDE distros often don’t have that enabled by default. Though I think Kubuntu has that enabled by default now so maybe that has changed. Go to System Settings -> Hardware -> Removable Devices to adjust the automount settings defaults and per drive settings.

If you don’t have automount enabled you probably will need to browse to them in Dolphin once to get KDE to mount the drive first.

Digitizer issues are usually from getting the wrong digitizer. They are programmed differently for the HAC-001(-01) (v2 classic switch) vs the HAC-001 (v1 classic switch).

More specifically the game card reader board that the digitizer plugs into needs to match. So make sure you buy your digitizer to match the game card reader version, or buy a game card reader to go with it (you can get them for ~$14). Unfortunately many digitizer sellers on eBay don’t say which model it is designed for.

Alternatively you can mix and match those versions if you have an unpatched/modded switch. Just launch Hekate, go to tools and run the digitizer calibration.

I haven’t repaired too many switches but the first time it happened to me I had a spare v2 game card reader and that fixed it immediately. Second time I used the Hekate method and that worked just as well

I recently bought a used switch from eBay which didn’t come with Joy-Cons as a gift for someone else. Took my OLED’s Joy-Cons and popped them on to test while I was waiting for the new Joy-Cons to arrive…

Well little did I know there was something sticky that had gotten on the contacts of this used switch, which then transferred to the Joy-Cons. I of course plugged them back into my OLED trying to figure out what was going on and transferred enough of whatever it was to my OLED to start causing problems as well.

Long story short it doesn’t take much to break that contact.

If you have an original switch and the right tools to open it up (needs a tri-wing screw driver), it is pretty easy to open it up, remove the contacts from the rail and thoroughly clean them. Worked perfectly to get the used switch back to brand new.

Of course don’t forget to do the same on the contacts of the Joy-Cons They need the same tri-wing screwdriver to open.

The OLED is a bit more of a PITA to get the rails out, so if you have an OLED or don’t have the tools to open your original you can make a makeshift cleaner like this person did (sorry about the reddit link). Joy-Con Rail Contact Cleaning Tool

I used a much smaller cable tie so that I could fit some isopropyl dipped gauze around the tip to get into the contacts (power off your switch entirely first!!!).

Careful on the Joy-Cons if you try to use something like that tool. The Joy-Cons are the spring side of the contact so you could easily bend them and make things worse.

If you have problems with stick drift and feel comfortable opening them up, you can get replacement sticks on eBay for $5-6 a piece.