toad.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon server operated by David Troy, a tech pioneer and investigative journalist addressing threats to democracy. Thoughtful participation and discussion welcome.

Administered by:

Server stats:

211
active users

#lxc

0 posts0 participants0 posts today
Replied in thread

@nabor@troet.cafe @Klimakipppunkt@troet.cafe @CrazyIT@freiburg.social @alexantemachina@mastodon.social

Da ich tatsächlich keine Möglichkeit sehe, HA auf ein vernünftiges Filesystem zu installieren - so ich das sehe, hat man, egal welche Installationsvariante man wählt, immer ein
#vFat #Dateisystem - wird wohl das Auslagern der #Datenbank respektive, eine ganz andere DB anzuflanschen, der einzige Ansatz sein, der Sinn macht, um ein stabiles System zu bekommen, bei dem nicht nach jedem Stromausfall alle Daten weg sind.

Den statischen Teil von /homeassistant kann man ja einmal wegsichern und bei Bedarf zurückspielen.

Die Datenbank muss aber stabil sein, um nicht immer wieder zeitweise Datenverlust zu haben, weil zwischen letzem Backup und Ausfall Zeit vergangen ist.

Am Besten kenne ich mich mit
#mySQL / #MariaDB aus. Da würde ich eine VM in #Proxmox damit machen und dann mit dem ensprechenden #Addon von HA anflanschen.

Eine komplette (Debian o.ä.)-VM für die Datenbank halte ich für übertrieben. Also
#LXC, oder was spricht dagegen (außer, dass ich LXC noch nie genutzt und deshalb damit keine Erfahrung habe)?

Wichtig wäre mir, wenn ich dieSQLite-DB schon in eine echte DB auslagere, dass ich mit
#phpMyAdmin darauf zugreifen kann. phpMyAdmin lief bisher bei mir immer auf demselben Server wie die DB. Ist das bei LXC easy?

Continued thread

what’s funny is that after using docker for a while, i hate it.

it’s a huge resource hog on any computer/server i’ve set it up. but what irks me, is that it was created by MS-dependent techbros to mimic linux containers.

so when the fuckers said, "oops! docker is now kinda sorta proprietary", i just said dahellwidat.

so taught myself to use LXD/LXC. as with everything #linux, THE UI/UX SUX cuz there’s none, but it’s FLOSS and it works.

so: YAY #LXC! boooooooooooo #docker!

I have finally caved in and dove into the rabbit hole of #Linux Container (#LXC) on #Proxmox during my exploration on how to split a GPU across multiple servers and... I totally understand now seeing people's Proxmox setups that are made up exclusively of LXCs rather than VMs lol - it's just so pleasant to setup and use, and superficially at least, very efficient.

I now have a
#Jellyfin and #ErsatzTV setup running on LXCs with working iGPU passthrough of my server's #AMD Ryzen 5600G APU. My #Intel #ArcA380 GPU has also arrived, but I'm prolly gonna hold off on adding that until I decide on which node should I add it to and schedule the shutdown, etc. In the future, I might even consider exploring (re)building a #Kubernetes, #RKE2 cluster on LXC nodes instead of VMs - and if that's viable or perhaps better.

Anyway, I've updated my
#Homelab Wiki with guides pertaining LXCs, including creating one, passing through a GPU to multiple unprivileged LXCs, and adding an #SMB share for the entire cluster and mounting them, also, on unprivileged LXC containers.

🔗 https://github.com/irfanhakim-as/homelab-wiki/blob/master/topics/proxmox.md#linux-containers-lxc

Testing Open WebUi with Gemma:3 on my proxmox mini PC in a LXC. My hardware is limited, 12th Gen Intel Core i5-12450H so I’m only using the 1b (28 token/s) and 4b (11 token/s) version for now.

Image description is functioning, but it is slow; it takes 30 seconds to generate this text with the 4b version and 16G allocated for the LXC.

Next step, trying this on my Mac M1.

🧐 Partir de #VMWare, pourquoi ce n'est pas si simple ?

Vous cherchez une alternative #OpenSource pour remplacer VMWare ? Thibaut Démaret, CTO de Worteks vous a préparé un guide.
De #LXC/LXD à #Kubernetes en passant par #Proxmox et #OpenStack, il y dresse un comparatif pour vous mettre à jour sur l'état du marché.

⏩ Découvrez son analyse et ses conseils pour bien choisir la solution de virtualisation qui correspond à vos besoins : worteks.com/blog/2025-01-08-al

@ow2 @OpenInfra
@fsfe

ProxLB 1.0.7 (an opensource DRS alike solution for #Proxmox clusters) is just around the corner!

1.0.7 will be the last version before I'm going to publish the new refactored code base in a modern and object oriented way. Version 1.1.0 squashes some more bugs that were postponed on the current code base and makes the overall future handling much easier (including new features).

Website: proxlb.de
GitHub: lnkd.in/eEZWEU7s
Blog post: lnkd.in/e5_b6u-A
Tags: #ProxmoxVE #DRS #Loadbalancer #opensource #virtualization #gyptazy #Proxmox #ProxLB #homelab #enterprise #balancer #balancing #virtualmachines #VM #VMs #VMware #LXC #container #cluster

After taking the nickle tour of #Qubes, my hasty conclusion is that it is anti-#KISS; there are seemingly many moving parts under the surface, and many scripts to grok to comprehend what is going on.

I plan to give it some more time, if only to unwrap how it launches programs in a VM and shares them with dom0's X server and audio and all that; perhaps it's easier than I think.

I also think #Xen is a bit overkill, as the claim is that it has a smaller kernel and therefore smaller attack surface than the seemingly superior alternative, #KVM. Doing some rudimentary searching out of identified / known VM escapes, there seem to be many more that impact Xen than KVM, in the first place.

Sure, the #Linux kernel may be considerably larger than the Xen kernel, but it does not need to be (a lot can be trimmed from the Linux kernel if you want a more secure hypervisor), and the Linux kernel is arguably more heavily audited than the Xen kernel.

My primary concern is compartmentalization of 'the web', which is the single greatest threat to my system's security, and while #firejail is a great soltion, I have run into issues maintaining my qutebrowser.local and firefox.local files tuned to work well, and it's not the simplest of solutions.

Qubes offers great solutions to the compartmentalization of data and so on, and for that, I really like it, but I think it's over-kill, even for people that desire and benefit from its potential security model, given what the threats are against modern workstations, regardless of threat actor -- most people (I HOPE) don't have numerous vulnerable services listening on random ports waiting to be compromised by a remote threat.

So I am working to refine my own security model, with the lessons I'm learning from Qubes.

Up to this point, my way of using a system is a bit different than most. I have 2 non-root users, neither has sudo access, so I do the criminal thing and use root directly in a virtual terminal.

One user is my admin user that has ssh keys to various other systems, and on those systems, that user has sudo access. My normal user has access to some hosts, but not all, and has no elevated privileges at all.

Both users occasionally need to use the web. When I first learned about javascript, years and years ago, it was a very benevolent tool. It could alter the web page a bit, and make popups and other "useful" things.

At some point, #javascript became a beast, a monster, something that was capable of scooping up your password database, your ssh keys, and probe your local networks with port scans.

In the name of convenience.

As a result, we have to take browser security more seriously, if we want to avoid compromise.

The path I'm exploring at the moment is to run a VM or two as a normal user, using KVM, and then using SSH X forwarding to run firefox from the VM which I can more easily firewall, and ensures if someone escapes my browser or abuses JS in a new and unique way, that no credentials are accessible, unless they are also capable of breaking out of the VM.

What else might I want to consider? I 'like' the concept of dom0 having zero network access, but I don't really see the threat actor that is stopping. Sure, if someone breaks from my VM, they can then call out to the internet, get a reverse shell, download some payloads or build tools, etc.

But if someone breaks out of a Qubes VM, they can basically do the same thing, right? Because they theoretically 'own' the hypervisor, and can restore network access to dom0 trivially, or otherwise get data onto it. Or am I mistaken?

Also, what would the #LXC / #LXD approach look like for something like this? What's its security record like, and would it provide an equivalent challenge to someone breaking out of a web browser (or other program I might use but am not thinking of at the moment)?

I need to take a step back and reassess my network setup. Here’s what I have:
• Proxmox VE running on a mini PC, directly connected to my router (no VLANs).
• The Proxmox host has a single virtual adapter with a static private IP, which is also reserved on the router.
• A Cloudflared LXC (running in Proxmox) with its own reserved private IP on the same subnet as the Proxmox host.
• A VM on the same subnet running Docker, where the containers are on a user-defined bridge network, but this bridge network is on a different subnet than the host.

My goal:

I want the Cloudflared LXC to properly route public hostname(s) to the appropriate Docker containers (which provide public services) on the VM.

The challenge:

Since the Docker containers are on a different subnet than the VM itself, how should I structure my networking so that:
1. Cloudflared can route requests correctly to the Docker services.
2. The setup remains clean and maintainable.

What’s the best approach to configure this? Should I adjust Proxmox networking, use additional routes, or take a different approach?