I loved FFSend. When it died, I ended up standing up a GOKAPI server, as it was the closest alternative I could find at the time: https://github.com/Forceu/Gokapi

Definitely not as nice as FFSend though. I may have to give that fork a try instead.

If most of the boxes are Windows, probably Samba4.

But if you’re mostly using Linux, FreeIPA is actually really nice.

Here’s the note taking and editors page of awesome-selfhosted. Looks like there are a few contenders in there. DailyTxT looks decent for your use case.

https://awesome-selfhosted.net/tags/note-taking--editors.html

Yeah, it can for sure. Definitely worth mentioning. Gotta watch what interface is set as the default router, or you’re bound to have a bad time. That said, the same is true with his originally proposed solution of pushing a trunk port to the VM, so it’s not any worse in that regard.

But yeah, full agreement on the correct solution. Keep it simple.

I wouldn’t let every VM have an interface into your management network, regardless of how you implement this. Your management network should be segregated with the ability to route to all the other VLANs with an appropriate firewall setup that only allows “related/established” connections back into it.

As for your services, having them on separate VLANs is fine, but it seems like you would benefit from having a reverse proxy to forward things to the appropriate VLAN, to reduce your management overhead.

But in general, having multiple interfaces per VM is fine. There shouldn’t be any performance hit or anything. But remember that if you have a compromised VM, it’ll be on any networks you give it an interface in, so minimizing that is key for security purposes. Ideally it would live in a VLAN that only has Internet access and/or direct access to your reverse proxy.

I think there’s several reasons for that, not the least of which is that you can’t distribute python bytecode.

With java, I run through an intentional compilation step and then ship the jar file to my consumers. I’d never ship a .pyc to the field.

In python (specifically cpython), that step is just an implementation detail of the interpreter/runtime.
If you ever used something other than the default python interpreter, it probably wouldn’t implement the same bytecode subsystem under the hood. Python bytecode isn’t part of the spec.

You’re gonna get mocked for saying compiler instead of interpreter, since python isn’t compiled.

But, to answer the spirit of your question, I’ve had good experiences with “Pydroid 3.” Clean interface and gets the job done.