Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)G
Posts
0
Comments
69
Joined
2 yr. ago

  • I've had one of these 3d printed keys in my wallet as a backup in case I get locked out for 5 years now. I certainly don't use it often but yeah it holds up fine.

    The couple of times I have used it works fine but you certainly want to be a little extra careful with it. I've got locks that are only 5ish years old so they all turn rather easily, and I avoid my door with the deadbolt when I use it because that would probably be too much for it.

    Mine is PETG but for how thin it is, it flexes a lot. I figured flexing is better than snapping off, but I think PLA or maybe a polycarbonate would function better. A nylon would probably be too flexible like the PETG.

  • 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 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.

  • Like most have said it is best to stay away from ZFS deduplication. Especially if your data set is media the chances of an entire ZFS block being the same as any other is small unless you somehow have multiple copies of the same content.

    Imagine two mp3s with the exact same music content but with slightly different artist metadata. A single bit longer or shorter at the beginning of the file and even if the file spans multiple blocks ZFS won't be able to duplicate a single byte. A single bit offsetting the rest of the file just a little is enough to throw off the block checksums across every block in the file.

    To contrast with ZFS, enterprise backup/NAS appliances with deduplication usually do a lot more than block level checks. They usually check for data with sliding window sizes/offsets to find more duplicate data.

    There are still some use cases where ZFS can help. Like if you were doing multiple full backups of VMs. A VM image has a fixed size so the offset issue above isn't an issue, but if beware that enabling deduplication for even a single ZFS filesystem affects the entire pool, even ZFS filesystems that have deduplication disabed. The deduplication table is global for the pool and once you have turned it on you really can't get rid of it. If you get into a situation where you don't have enough memory to keep the deduplication table in memory ZFS will grind to a halt and the only way to completely remove deduplication is to copy all of your data to a new ZFS pool.

    If you think this feature would still be useful for you, you might want to wait for 2.3 to release (which isn't too far off) for the new fast dedup feature which fixes or at least prevents a lot of the major issues with ZFS dedup

    More info on the fast dedup feature here https://github.com/openzfs/zfs/discussions/15896

  • Slows down then freezes sure sounds like an out of memory situation, so to add to yours here they might actually want less swap. Sometimes you would rather hit the oom killer sooner instead of waiting on swap to fill.

    Ideally login via SSH from another machine to figure out what is using the memory (hopefully the system is responsive enough for SSH), and if it is your critical programs causing the problem then you should consider a memory upgrade.

  • Contrary to a lot of posts that I have seen, I would say ZFS isn't pointless with a single drive. Even if you can't repair corruption with a single drive knowing something is corrupt in the first place is even more important (you have backups to restore it from right?).

    And a ZFS still has a lot of features that are useful regardless. Like snapshots, compression, reflinks, send/receive, and COW means no concerns about data loss during a crash.

    BTRFS can do all of this too and I believe it is better about low memory systems but since you have ZFS on your NAS you unlock a lot of possibilities keeping them the same.

    I.e. say you keep your T110ii running with ZFS you can use tools like syncoid to periodically push snapshots from the Optiplex to your T110.

    That way your Optiplex can be a workhorse, and your NAS can keep the backup+periodic snapshots of the important data.

    I don't have any experience with TrueNAS in particular but it looks like syncoid works with it. You might need to make sure that pool versions/flags are the same for sending/receive to work.

    Alternatively keep that data on an NFS mount. The SSD in the Optiplex would just be for the base OS and wouldn't have any data that can't be thrown away. The disadvantage here being your Optiplex now relies on a lot more to keep running (networking + nas must be online all the time).

    If you need HA for the VMs you likely need distributed storage for the VMs to run on. No point in building an HA VM solution if it just moves the single point of failure to your NAS.

    Personally I like Harvester, but the minimum requirements are probably beyond what your hardware can handle.

    Since you are already on TrueNAS Scale have you looked at using TrueNAS Scale on the Optiplex with replication tasks for backups?

  • Credit unions use the NCUA instead of FDIC. So if they don't go after that as well there are still some options.

  • If you are just looking to repurpose an old device for around the house use and it won't ever be leaving your home network, then the simplest method is to set a static IP address on the device and leave the default gateway empty. That will prevent it from reaching anything other than the local subnet.

    If you have multiple subnets that the device needs to access you will need a proper firewall. Make sure that the device has a DHCP reservation or a static IP and then block outgoing traffic to the WAN from that IP while still allowing traffic to your local subnets.

    If it is a phone who knows what that modem might be doing if there isn't a hardware switch for it. You can't expect much privacy when that modem is active. But like the other poster mentiond a private DNS server that only has records from your local services would at least prevent apps from reaching out as long as they aren't smart enough to fall back to an IP address if DNS fails.

    A VPN for your phone with firewall rules on your router that prevent your VPN clients from reaching the WAN would hopefully prevent any sort of fallback like that.

  • If you are accessing your files through dolphin on your Linux device this change has no effect on you. In that case Synology is just sharing files and it doesn't know or care what kind of files they are.

    This change is mostly for people who were using the Synology videos app to stream videos. I assume Plex is much more common on Synology and I don't believe anything changed with Plex's h265 support.

    If you were using the built in Synology videos app and have objections to Plex give Jellyfin a try. It should handle h265 and doesn't require a purchase like Plex does to unlock features like mobile apps.

    Linux isn't dropping any codecs and should be able to handle almost any media you throw at it. Codec support depends on what app you are using, and most Linux apps use ffmpeg to do that decoding. As far as I know Debian hasn't dropped support for h265, but even if they did you could always compile your own ffmpeg libraries with it re-enabled.

    How can I most easily search my NAS for files needing the removed codecs

    The mediainfo command is one of the easiest ways to do this on the command line. It can tell you what video/audio codecs are used in a file.

    With Linux and Synology DSM both dropping codecs, I am considering just taking the storage hit to convert to h.264 or another format. What would you recommend?

    To answer this you need to know the least common denominator of supported codecs on everything you want to play back on. If you are only worried about playing this back on your Linux machine with your 1080s then you fully support h265 already and you should not convert anything. Any conversion between codecs is lossy so it is best to leave them as they are or else you will lose quality.

    If you have other hardware that can't support h265, h264 is probably the next best. Almost any hardware in the last 15 years should easily handle h264.

    When it comes to thumbnails for a remote filesystem like this are they generated and stored on my PC or will the PC save them to the folder on the NAS where other programs could use them.

    Yes they are generated locally, and Dolphin stores them in ~/.cache/thumbnails on your local system.

  • Add a -f to your umount and you can clear up those blocked processes. Sometimes you need to do it multiple times (seems like it maybe only unblocks one stuck process at a time).

    When you mount your NFS share you can add the "soft" option which will let those stuck calls timeout on their own.

  • North Dakota like many states has a renters refund for those with lower incomes which is designed to at least partially offset that. Limits look to be a bit low but every little bit helps.

  • Here

    H2i® models provide heating, even in outdoor temperatures as low as -13° F, producing up to 100% heating capacity at 5° F. These units offer year-round comfort even in extreme climates

    Their technical documents show that they are down to about 20% of their usual heat output at that lowest temperature so they need to be sized up accordingly. The reality for most folks in an area cold enough to require these is they have backup heat sources for the coldest days anyways.

  • Gerrymandered districts are more in danger not less. Gerrymandering is about spreading out areas which are easy wins, and instead spreading those votes over multiple districts.

    You gain more seats, but you make every race closer.

  • In any KDE app you can connect with SFTP in the open file dialog. Just type sftp://user@server/path and you can browse/open/edit files the remote server. ssh keys+agent make things a lot easier here obviously.

  • The switches don't have to control the lights they are wired to. I have Inovelli z-wave switches, and on these you can disable the relay. So the switch can still send out commands/scenes on the network but the relay is always on.

    Then you would put in a relay unit in the electrical box of the lights or if you have enough room in with the switches. Then setup the switches to control their respective sets of lights.

    Might even be a switch out there that lets you disconnect the relay from the buttons on the switch but still control the relay which would cut down on the device count.