TCB13

TCB13 , 6 months ago

This video was all cool until he said “using spicy remote desktop protocol”. That’s when I knew it was all the typical bs guide that results in a slow system not usable for anything remotely close to real time. Also the guy is running without any GPU acceleration making things very bad.

TCB13 , 6 months ago

What’s the status of SmartDNS (that is used by OpenWRT and DD-WRT) on this? Anyone knows anything?

TCB13 , 6 months ago

Its literally a violation of the EU human rights agreement…

Is it? In Portugal there have been a similar law for years and nobody cares apparently. It isn’t as wide as the Italian one, it just says ISPs are required to block access to websites a govt. entity lists.

Also no company will comply with that shitshows ridiculous orders.

Are you sure? Think about it… “All VPN and open DNS services must also comply with blocking orders”. A VPN provider can’t legally sell their services in Italy unless they comply. The best part is: since the govt is blocking websites they can also block providers who doesn’t play according to their rules :)

TCB13 , 6 months ago

Or not. “All VPN and open DNS services must also comply with blocking orders”. A VPN provider can’t legally sell their services in Italy unless they comply. The best part is: since the govt is blocking websites they can also block providers who doesn’t play according to their rules :)

TCB13 , 6 months ago

Putting performance aside, you can but still raises some legal and billing questions.

TCB13 , 6 months ago

I agree with you, but still the portuguese law is equally a violation of the EU human rights agreement.

TCB13 , 6 months ago

Kind of, the law doesn’t actually say that it only applies to ISPs… technically speaking the Portuguese law could be applicable and enforced with a VPN provider is a court decided to do so. The legislation is kind of written in a vague way that may apply to more than just ISPs. So far they only pressured ISPs to block websites.

TCB13 , 6 months ago

but the processes are so fucking long that getting something blocked takes time, our ISPs fight almost every time (…) The only actual option to get something out of the internet is to find the server and shut it down.

Not the case at all around here (Portugal), the blocks are quick and ISPs don’t even complain, they simply comply. What the law says is that there’s a govt entity called IGAC that is allowed to ask ISPs to block a website (domain name) as long as the website is flagged as containing / hosting piracy or other form of copyright infringement. The only requirement is that IGAC has to notify the website owner asking to remove the content prior blocking. After 48 if the website is still hosting said content then IGAC will ask the ISPs to block it.

Since this is all DNS based one can, obviously, set their DNS servers as Google or Cloudflare and bypass the block. Now the problem is that this is all fun and games until someone in the govt decides to go against Cloudflare and other DNS providers, the law would allow them to easily do it the way its written.

TCB13 , 6 months ago

Just because something is “technically” possible doesn’t mean its scalability and costs are a actually considerable option.

Any mid-range / price firewall solution is capable of effectively blocking most VPN solutions. Both OVPN and Wireguard VPN traffic is trivial to identify as such and block. Here’s an example and another.

Btw, I’ve never seen something like that, my VPN worked even in China, and that must mean something…

China’s great firewall works a little bit differently. They aren’t actively blocking certain kinds of traffic by default because that would mean a large DPI effort they don’t want to undertake. Also if you google a bit about it you’ll find that people’s experiences are mostly “my VPN worked fine for a day/week/month and then it was blocked”. It seems they’ve some IPs and domains blocked and the rest is some kind of machine learning that applies rules as it sees fit, this guy here has a good analysis of it.

TCB13 , 6 months ago

That’s some authoritarian shitshow right there. But i think its not a violation of EU laws or agreements.

😂 😂 😂 well the irony is that this is the kind of “authoritarian shitshow” we got by electing the left. That and a tax on digital storage (flash drives, disks etc) because they might be used to hold piracy. Even phones are taxed.

TCB13 , 6 months ago

I mean if even one of those just shuts down service in or for Portugal the entire Internet is fucked instantly.

Yes, but what if the govt just politely tells them “look, we’ve a law about piracy and we think you should block websites at the DNS level like our ISPs are doing”. Do you think Google / Cloudflare will fight it? They already have mechanisms for that in place for parental controls etc. so… the effort of adding a block list for a country shouldn’t be a big deal.

TCB13 , 6 months ago

Great piece of shit of a tax indeed.

TCB13 , 6 months ago

As said, I’ve never seen a network that even tried to block any kind of VPN, and i have seen numerous networks… I kinda built them even. Good, i don’t think anyone outside of a clownshow authoritarian circlejerk would even try to do that.

All the serious companies (financial sector) I worked for so far did it, because as I linked is really easy with any cheap firewall solution.

clownshow authoritarian circlejerk

Well… a bank could be considerar that indeed, but you know, security concerns and all.

VPNs are very very necessary when you work with sensitive data in BtoB, wanna do remote checkup of a server? You better use a fucking VPN or you aint getting in.

So what? A company can use a firewall to block VPNs when the target IP isn’t on some whitelist, or the source computer isn’t authorized to use VPNs. On those high security setups at banks and whatnot client machines inside the company network won’t need to touch a VPN to do a “remote checkup of a server” at some cloud provider as the network will be configured to internally route the traffic from all computers / users (backed by SSO/AD credential) to access those resources via a special VPN setup on some router / server.

Wanna help someone over TeamViewer? Thats not much different from a VPN…

Fortinet and WatchGuard can both distinguish a VPN from TeamViewer. They can actually do much more than that, even TeamViewer from RDP or VNC is just a couple of clicks on their UIs.

TCB13 , 6 months ago

An Italian citizen or resident can go online and buy vpn service from me. There is not law im subjected to that says I can’t sell vpn services to Italians.

This isn’t true. If you don’t comply with the other law regarding the website blocks then the Italian govt will politely ask you to. If your business happens to be on another EU member state they might even try to get your local authorities involved in the asking. Either way, if you don’t comply or they can’t reach you (cause you’re ouside the EU) they’ll proceed to block your website / domains in Italy and no more business for you.

TCB13 , 6 months ago

Its just impossible to even start a VPN from these systems unless you have administrator privileges, so im not used to your way of doing it.

That’s also the policy for the majority of the machines/users but there are a few that do have admin privileges like IT teams and whatnot and even if they manage to install a VPN solution (the app would most likely get blocked by endpoint security either way) they couldn’t communicate to the outside because the firewalls, as I described, are all set to block VPN traffic. Except for those situations I specified above.

The bottom line is: distrust everything, everyone and anything. Even if you can ensure nobody can install a VPN application on their computers, assume someone might get around that and add proper firewall checks and blocks as well.

TCB13 , 6 months ago

I use it too, works just fine.

TCB13 , 6 months ago (edited 6 months ago)

I wonder now, how big the delta is for people like me: All my desktops/servers are based on Debian stable with heavy customization, but 100% automated via Ansible.

Close to none. Immutable solve the same problem that was solved years ago with Ansible and BTRFS/ZFS snapshots, there’s an important long-term difference however…

Immutable distros are all about making thing that were easy into complex, “locked down”, “inflexible”, bullshit to justify jobs and payed tech stacks and a soon to be released property solution. We had Ansible, containers, ZFS and BTRFS that provided all the required immutability needed already but someone decided that is is time to transform proven development techniques in the hopes of eventually selling some orchestration and/or other proprietary repository / platform like Docker / Kubernetes does. Docker isn’t totally proprietary and there’s Podman but consider the following: It doesn’t really matter if there are truly open-source and open ecosystems of containerization technologies. In the end people/companies will pick the proprietary / closed option just because “it’s easier to use” or some other specific thing that will be good on the short term and very bad on the long term.

“Oh but there are truly open-source immutable distros” … true, but again this hype is much like Docker and it will invariably and inevitably lead people down a path that will then require some proprietary solution or dependency somewhere (DockerHub) that is only required because the “new” technology itself alone doesn’t deliver as others did in the past. Those people now popularizing immutable distributions clearly haven’t had any experience with it before the current hype. Let me tell you something, immutable systems aren’t a new thing we already had it with MIPS devices (mostly routers and IOTs) and people have been moving to ARM and mutable solutions because it’s better, easier and more reliable.

The RedHat/CentOS fiasco was another great example of this ecosystems and once again all those people who got burned instead of moving to a true open-source distribution like Debian decided to pick Ubuntu - it’s just a matter of time until Canonical decides to do some move.

Nowadays, without Internet and the ecosystems people can’t even do shit anymore. Have a look at the current state of things when it comes to embedded development, in the past people were able to program AVR / PIC / Arduino boards offline and today everyone moved to ESP devices and depends on the PlatformIO + VSCode ecosystem to code and deploy to the devices. Speaking about VSCode it is also open-source until you realize that 1) the language plugins that you require can only compiled and run in official builds of VSCode and 2) Microsoft took over a lot of the popular 3rd party language plugins, repackage them with a different license… making it so if you try to create a fork of VSCode you can’t have any support for any programming language because it won’t be an official VSCode build. MS be like :).

All those things that make development very easy and lowered the bar for newcomers have the dark side of being designed to reconfigure and envelope the way development gets done so someone can profit from it. That is sad and above all set dangerous precedents and creates generations of engineers and developers that don’t have truly open tools like we did.

This is all about commoditizing development - it’s a negative feedback loop that never ends. Yes I say commoditizing development because if you look at it those techs only make it easier for the entry level developer and companies instead of hiring developers for their knowledge and ability to develop they’re just hiring “cheap monkeys” that are able to configure those technologies and cloud platforms to deliver something. At the end of the they the business of those cloud companies is transforming developer knowledge into products/services that companies can buy with a click.

TCB13 , 6 months ago

So, you really think, that this must be the reason immutable desktops were invented?

Most likely not, but the people pushing for the / the narrative certainly are for that.

TCB13 , 6 months ago

You just missed the point. There are always alternatives, generally not as good and unlike before all tooling is now hostage of some big provider.

TCB13 , 6 months ago

Immutable distros are a solution to a real problem, and this problem is not solved by Ansible/BTRFS etc.

Just tell me what that problem is and how it isn’t already solved with Ansible/BTRFS.

TCB13 , 6 months ago

Ansible is imperativ and applies changes to a starting state. Immutable distros replicate a known state 100%, which is in every respect superior and prevents nasty surprises Immutable distros are 100% reproducible from a config file, which is a big thing for cyber security, building software etc. Debian has too many packages given the amount of contributors they have.

So does Ansible. Pick something like Alpine and destroy and recreate instances whenever you need to change your setup. Done.

TCB13 , 6 months ago

And LXD/Incus…

Why use Proxmox when half of it’s technology (the container part) was made by the same people who made LXD/Incus? I mean Incus is free, well funded and can be installed on a clean Debian system with way less overhead and also delivers both containers and VMs.

TCB13 , 6 months ago

Did you ever try LXD/Incus?

TCB13 , 6 months ago

Well, suit yourself. :)

TCB13 , 6 months ago

Oh yeah it runs fine until they kill their free tier like ESXi did or… it completely fails over and over again.

TCB13 , 6 months ago

Oh yeah, zfs send ftw. I personally run most of stuff on BTRFS and I can say the same.

TCB13 , 6 months ago

Since you are apparently on an anti-proxmox crusade. Have you tried that iscus thing in enterprise? Like a very large scale production deployment?

Maybe if you read the comment I linked you’ll find that that’s precisely what we had with Proxmox and then migrated to LXD.

I am curious if anyone dares to use it in enterprise when people are even scared of proxmox or anything not VMware or MAYBE hyperV

I guess it depends on the kind of “enterprise” we’re talking about. If your “enterprise” is somewhat of a provider / ISP they should be okay with LXD. A lot of service providers are running some form of LXC/LXD right now with very good results.

If by “enterprise” you mean your typical 400+ people company that does something not related to tech with an overworked and barely competent IT / infrastructure team, then the answer is: they won’t move out of vmware ever.

TCB13 , 6 months ago

Pretty much like all Debian forks. They’re all forked from Debian because of conflicts between developers / different ways of seeing things. :P

TCB13 , 6 months ago

Well. Linux on the Dreamcast seems more interesting. Or NetBSD.

TCB13 , 6 months ago

Yes it does run, but BSD-based VMs running on Linux have their details as usual. This might be what you’re looking for: discuss.linuxcontainers.org/t/…/15799

Since you want to run a firewall/router you can ignore LXD’s networking configuration and use your opnsense to assign addresses and whatnot to your other containers. You can created whatever bridges / vlan-based interface on your base system and them assign them to profiles/containers/VMs. For eg. create a cbr0 network bridge using systemd-network and then run lxc profile device add default eth0 nic nictype=bridged parent=cbr0 name=eth0 this will use cbr0 as the default bridge for all machines and LXD won’t provide any addressing or touch the network, it will just create an eth0 interface on those machines attached to the bridge. Then your opnsense can be on the same bridge and do DHCP, routing etc. Obviously you can passthrough entire PCI devices to VMs and containers if required as well.

When you’re searching around for help, instead of “Incus” you can search for “LXD” as it tend to give you better results. Not sure if you’re aware but LXD was the original project run by Canonical, recently it was forked into Incus (and maintained by the same people who created LXD at Canonical) to keep the project open under the Linux Containers initiative.

TCB13 , 6 months ago

I guess I’m not using proxmox for anything other than managing VMs, network bridges and backups.

And LXD/Incus can do that as well for you. Install it an by running incus init it will ask you a few questions and get an automated setup with networking, storage etc. all running and ready for you to create VMs/Containers.

What I was saying is that you can also ignore the default / automated setup and install things manually if you’ve other requirements.

TCB13 , 6 months ago

Enjoy your 30 min of Incus :P

TCB13 , 6 months ago

It depends on how fast you want updates. I’m sure you know how Debian works, so if you install LXD from Debian 12 repositories you’ll be on 5.0.2 LTS most likely for ever. If you install from Zabbly you’ll get the latest and greatest right now.

My companies’ machines are all running LXD from Debian repositories, except for two that run from Zabbly for testing and whatnot. At home I’m running from Debian repo. Migration from LXD 5.0.2 to a future version of Incus with Debian 13 won’t be a problem as Incus is just a fork and stgraber and other members of the Incus/LXC projects work very closely or also work in Debian.

Debian users will be fine one way or the other. I specifically asked stgraber about what’s going to happen in the future and this was his answer:

We’ve been working pretty closely to Debian on this. I expect we’ll keep allowing Debian users of LXD 5.0.2 to interact with the image server either until trixie is released with Incus available OR a backport of Incus is made available in bookworm-backports, whichever happens first.

I hope this helps you decide.

TCB13 , 6 months ago

You aren’t wrong, the WebUI is stateless, it doesn’t know of any users nor it stores any other context information.

The certificates are required for the UI client to authenticate with the underlying LXD server itself. Much like the SSH authentication is boils down to creating a public/private key pair and the PK is added to your browser(s) and the public key to the server. I believe this is a good walkthrough of the process for anyone starting out.

At work we use Authelia and HAProxy to get around the need to distribute a certificate for each client / mange our logins with SSO and 2FA. At home I simply use Nginx as a reverse proxy to the WebUI with the proxy_ssl_certificate passing a certificate down to it. Here another configuration example of how to use Nginx to pass the certificate, you can then use Basic HTTP Auth to add a simple username/password to it.

TCB13 , 6 months ago (edited 6 months ago)

LXD uses QEMU/KVM/libvirt for VMs thus the performance is at least the same as any other QEMU solution like Proxmox, the real difference is that LXD has a much smaller footprint, doesn’t depend on 400+ daemons thus boots and runs management operations much faster. The virtualization tech is the same and the virtualization performance is the same.

TCB13 , 6 months ago

While I get your point… I kind of can’t: lemmy.world/comment/7476411

TCB13 , 6 months ago

Sorry I meant high availability as in the ability to live transfer a VM to a different host without downtime or service interruptions.

Oh, my bad then. But yes, like Proxmox, LXD/Incus can do live migrations of VMs since 4.20 (2021 I believe). Live migration of containers can be done under specific circunstantes as well.

Are you using a container runtime in the LXC container? (i.e. docker or podman)

In some of them yes. At least under Debian as long as you’ve set security.nesting=true it will work fine.

TCB13 , 6 months ago

I’ve just found LXD to be lacking as you can’t live transfer it to a different host

It isn’t lacking… linuxcontainers.org/incus/docs/…/move_instances/#… but as with Proxmox there are details when it comes to containers. VMs can fully migrate live.

I was unable to get docker running in a unprivileged LXC container

What host OS are you running on? Did you set security.nesting true on said container?

TCB13 , 6 months ago

First they’re always nagging you to get a subscription. Then they make system upgrades harder for free customers. Then the gatekeep you from the enterprise repositories in true RedHat fashion and have important fixes from the pve-no-subscription repository multiple times.

TCB13 , 6 months ago

Okay if you want to strictly look at licenses per si no issues there. But the rest of what I described I believe we can agree is very questionable, takes into questionable open-source.

TCB13 , 6 months ago

besmirching their reputation on moral grounds doesn’t do anyone any favors.

I’m not sure if you came across my other comment about Proxmox (here) but unfortunately it isn’t just “besmirching their reputation on moral grounds”.

Also, I would like to add that a LOT of people use Proxmox to run containers and those containers are currently LXC containers. If one is already running LXC containers why not have the full experience and move to LXD/Incus that was made by the same people and designed specifically to manage LXC and later on VMs?

After all Proxmox jumps through hoops when managing LXC containers as they simply retrofitted both their kernel and pve-container / pct that were originally developed to manage OpenVZ containers.

TCB13 , 6 months ago

Thankfully, it’s been forked as incus, and debian is encouraging users to migrate.

Yes, the people running the original LXC and LXD projects under Canonical now work on Incus under the Linux Containers initiative. Totally insulated from potential Canonical BS. :)

The move from LXD to Incus should be transparent as it guarantees compatibility for now. But even if you install Debian 12 today and LXD from the Debian repository you’re already insulated from Canonical.

TCB13 , 6 months ago

Also it’s weird that you take issue with Proxmox but not LXD. From what I read in the Incus initial announcement, what Canonical did with LXD is barely legal and definitely against the spirit of its license. Incus is a drop in replacement. Why even bring LXD up?

Mostly because we’re on a transition period from LXD into Incus. If you grab Debian 12 today you’ll get LXD 5.0.2 LTS from their repositories that is supported both by the Debian team and the Incus team. Most online documentation and help on the subject can also be found under “LXD” more easily. Everyone should be running Incus once Debian 13 comes along with it, but until then the most common choice is LXD from Debian 12 repositories. I was never, and will never suggest anyone to install/run LXD from Canonical.

It’s really the “Proxmox is fake open source” discourse I take issue with. I think it would be more helpful if you said “and you get all security updates for free with Incus, unlike Proxmox.” It’s a clear, factual message, devoid of a value judgement. People don’t like to be told what to think.

I won’t say I don’t get your point, I get it, I kinda pushed it a bit there and you’re right. Either way what stops Proxmox from doing the same thing BCM/ESXi did now? We’re talking about a for profit company and the alternative Incus sits behind the Linux Containers initiative that is effectively funded by multiple parties.

And, as far as micro to small installations go, TrueNAS is another alternative that plays well with open source (AFAIK). Unlikely to be used specifically for VMs or containers, but it’s a popular choice for home servers for a reason.

Yes, TrueNAS can be interesting for a lot of people and they also seem to want to move into the container use-case with TrueNAS Scale but that one is still more broken than useful.

TCB13 , 6 months ago (edited 6 months ago)

So I’m kind of scared about the future of LXC and Incus. Do you have any more information about that?

Canonical decided to take LXD away from the Linux Containers initiative and “close it” by changing the license. Meanwhile most of the original team at Canonical that made both LXC and LXD into a real thing quit Canonical and are not working on Incus or somehow indirectly “on” the Linux Containers initiative.

no one else participating apart from Canonical devs.

Yes, because everyone is pushing code into Incus and the team at Canonical is now very, very small and missing the key people.

The future is bright and there’s money to make things happen from multiple sources. When it comes to the move from LXD to Incus I specifically asked stgraber about what’s going to happen in the future to the current Debian LXD users and this was his answer:

We’ve been working pretty closely to Debian on this. I expect we’ll keep allowing Debian users of LXD 5.0.2 to interact with the image server either until trixie is released with Incus available OR a backport of Incus is made available in bookworm-backports, whichever happens first.

As you can see, even the LTS LXD version present on Debian 12 will work for a long time. Eventually everyone will move to Incus in Debian 13 and LXD will be history.

---

Update: here’s an important part of the Incus release announcement:

The goal of Incus is to provide a fully community led alternative to Canonical’s LXD as well as providing an opportunity to correct some mistakes that were made during LXD’s development which couldn’t be corrected without breaking backward compatibility.

In addition to Aleksa, the initial set of maintainers for Incus will include Christian Brauner, Serge Hallyn, Stéphane Graber and Tycho Andersen, effectively including the entire team that once created LXD.

TCB13 , 6 months ago

What stops Proxmox is the same thing “stopping” Canonical.

But Canonical is no longer a concern since Incus has nothing to do with them…

TrueNAS, there’s nothing broken.

As I said, a lot of the interesting software available via TrueCharts is broken or poorly maintained, this is sad as it would be a great solution.

TCB13 , 6 months ago

Yes, no question there.