It’s not actually going that great, there is already infighting on the direction of the scripts.

Are you having trouble reading context?

No, I’m not applying 2005 security, I’m saying NFS hasn’t evolved much since 2005, so throw it in a dedicated link by itself with no other traffic and call it a day.

Yes, iscsi allows the use of mounted luns as datastores like any other, you just need to use the user space iscsi driver and tools so that iscsi-ls is available. Do not use the kernel driver and args. This is documented in many places.

If you’re gonna make claims to strangers on the internet, make sure you know what you’re talking about first.

Yes, i have. Same security principles in 2005 as today.

Proxmox iscsi support is fine.

Oh, OK. I should have elaborated.

Yes, agreed. It’s so difficult to secure NFS that it’s best to treat it like a local connection and just lock it right down, physically and logically.

When i can, I use iscsi, but tuned NFS is almost as fast. I have a much higher workload than op, and i still am unable to bottleneck.

I don’t know what you’re on about, I’m talking about segregating with vlans and firewall.

If you’re encrypting your San connection, your architecture is wrong.

Your workload just won’t see much difference with any of them, so take your pick.

NFS is old, but if you add security constraints, it works really well. If you want to tune for bandwidth, try iSCSI , bonus points if you get zfs-over-iSCSI working with tuned block size. This last one is blazing fast if you have zfs at each and you do Zfs snapshots.

Beyond that, you’re getting into very tuned SAN things, which people build their careers on, its a real rabbit hole.

According to this, 6.2.4.x is not affected.

OVS is fine, you can make live changes and something like spanning port traffic is a bit less hassle than using tc, but beyond that, it’s not really an important component to a failover scenario over any other vswitch, since it has no idea what a TCP stream is.

For sure, if your thing is leaning into network configs, nothing wrong with it, especially if you have proper failover set up.

I think virtualized routing looks fun to the learning homelabber, and it is, but it does come with some caveats.

HA… Do you mean failover? It would need some consideration, either a second wan link or accepting that a few TCP sessions might reset after the cutover, even with state sync. But it’s definitely doable.

I’m currently in a state of ramping down my hardware from a 1u dual Xeon to a more appropriate solution on less power-hungry gear, so I’m not as interested in setting up failover if it means adding to my power consumption simply for the uptime. After 25 years in IT, its become clear to me that the solutions we put in place at work come with some downsides like power consumption, noise, complexity and cost that aren’t offset by any meaningful advantage.

All that said, i did run that setup for a few years and it does perform very well. The one advantage of having a router virtualized was being able to revert to a snapshot if an upgrade failed, which is a good case for virtualizing a router on its own.

I did it for a few years, it looks interesting on paper, but in practice, it’s a nightmare.

At home, you’ll be getting real sick of asking for change windows to reboot your hypervisor.

At work, you will rue the day you convinced mgmt to let it happen, only to now have hypervisor weirdness to troubleshoot on top of chasing down bgp and TCP header issues. If it’s a dedicated router, you can at least narrow the scope of possible problems.

Because bringing up nftables is not relevant to op’s question.

Depends on your workflow.

• Paperless itself is great, but it cannot ingest half my PDF bills and invoices due to limitations on the conversion tools dependency.
• support for interpreting US/EU conventions for date and time takes careful workflow rules, automation can have weird results
• multi user support is a bit of a mess

In short, it’s great for single user, single workflow cases, but not so much for just ingesting all kinds of docs and having truly helpful doc processing.

No v4/v6 dual stack mentioned here, nor any multi-action rules required, so nftables would be of no advantage here.

Unless you’re just saying “new thing good, old thing bad” here, I’m not sure why bother mentioning nftables.

Photoprism is less “resource intensive” because it’s offloading face detection to a cloud service. There are also many who don’t like the arbitrary nature of which features photoprism paywalls behind its premium version.

If you can get past immich’s initial face recognition and metadata extraction jobs, it’s a much more polished experience, but more importantly it aligns with your goal of getting out of the cloud.

Currently still fixing alpine Linux lxc running docker that decided to stop being able to network after a PVR update.

I’ve managed to migrate my services to debian-based docker Lxc, but it bothers me that I can’t figure this out.

Best I have so far is that flushing the iptables in alpine lxc works temporarily.

How efficient is using a GPU? I understood the efficiency wasn’t nearly as good, but that may have been info from a while back.

It’s well worth it to get a $50 coral tpu for object detection. Fast inference speed and nearly zero CPU usage.

Keys spread out? I don’t understand…

I appreciate the reply, but I guess I wasn’t clear on what I was asking.

It’s obvious who this is for in the literal sense, what I mean is: what is the use case for this?

On the homelab front, I don’t see enough need to unify my GUI access, and i have roughly 30 containers to manage. At that point, most homelab admins gravitate to automation.

On the professional front, I can tell you that unifying the keys to mgmt interfaces to critical infrastructure in a single app is not a welcome tool to see on my junior admin desktops. And if it’s simply the interface to mgmt portals without storing keys, then I would have my doubts about a junior admin who hasn’t developed a personal strategy to manage this themselves.

Don’t get me wrong, I’m happy to encourage you to develop this, but the second you write “trying to make a living from this”, you should know that these questions are coming.

If I were across the table from you trying to understand what you’re selling me, I would want to know:

• how do you handle secrets in transit and at rest?
• can I deploy this once and set access for various departments or employees?
• can I find out who has been using the tool?
• how does the app handle updates?

You can see where this is going. If I buy this tool for use by several people, I don’t want to have to wrap it in vault entries and update scripts just to meet compliance with my client’s environment.