I'm working on my transition plan away from Windows and testing out various things in VMs as I do so, and one big hurdle is making sure the VPN client my work requires can connect. Bazzite is my target distro (primarily gaming, work less frequently), though other more traditionally structured ones like Pop!_OS and Garuda are possibilities.
I'm currently trying and failing to get the VPN client working in a distrobox (throws an error during connection saying PPP isn't installed or supported by the kernel). However, I can successfully get the VPN connected if I overlay the client and its dependencies via rpm-ostree install, but I read somewhere that Bazzite's philosophy is to use rpm-ostree as sparingly as possible for installing software to preserve as much containerization as possible.
Since I can get it working outside of a container, am I overthinking it? Should I just accept that this might be one of the "sparing" cases? Is Bazzite perhaps a poor fit for my use case? I've been trying to make sense of this guide, but I'm having trouble understanding how to apply it to my situation, since I'm not that familiar with Docker or Podman.
Also, don’t jump straight into a universal blue derivative. Actually learn how to use Linux before you start in with something that relies on a bunch of convenience features.
Very good advice, though I've personally been dabbling for many years and generally know a handful of things. Still, I would recommend the same thing for anyone new to Linux. There's some fantastic options, these days!
I might just be a glutton for punishment, however. 😆
Even if you know how to do stuff, I’d avoid doing ostree on a universal blue derivative.
I been using Linux for 25 years and just recently embraced the “don’t break Debian” part of the backport manual.
Stuff you do and don’t document or don’t force yourself to recognize comes back to bite you years later when you can’t use the normal tooling in order to deal with it.
Anyway, good luck, it sounds like you’ll be fine.
Stuff you do and don’t document or don’t force yourself to recognize comes back to bite you years later when you can’t use the normal tooling in order to deal with it.
And it's this right here that forces me to really consider if Bazzite is right for me in this case (and why I didn't just immediately go with the easier
rpm-ostreeoption). Podman is kind of a necessary tool, at least currently, and if your use case falls outside flatpaks, rpm-ostree, and appimages, it's Podman or bust (and I currently have an app like that, which I haven't yet figured out).I appreciate your experienced advice. I have probably a total five years of experience, so I would be foolish not to consider to the long-timers offering similar advice in these comments.
OP, it seems as if the fear mongering and misinformation may have reached you through your cautious disposition.
I've gone through every single comment found below your post and at times I've been dumbfounded and/or astonished by the ludicrous claims that are spouted.
FFS, someone even expressed a problem found on imperative systems... While Fedora Atomic can be made (relatively) declarative (i.e. the exact opposite of imperative) for over a year now.
I will leave you with two videos in which the recent conference talks by the very same people that work on Fedora Atomic can be found. Consider watching these if you're interested to know what they're actually currently working on. If you pay attention, you will even notice how they mention common misconceptions that have also been brought up here...
First watch this one. Then, watch this.
The only fair criticism that I've found is the required investment and effort to adjust due to the associated paradigm shift and learning curve. However, this is peanuts compared to Guix System or NixOS.
Okay, I appreciate the links. I've had a chance to go over both, and I think I get the gist:
rpm-ostreeis a work in progress, and it will be depreciated and replaced withbootc+dnf
However, I'm still struggling to understand how it all works together. For example, I have a VPN client that is installed via a
.runscript, so it doesn't work withostree. If I wanted to apply this software to my system, I'd have to create a bootable container, then rebase to that. But my goal isn't to create a new image, just to apply transient packages to the base Bazzite image, so my remaining questions are these (and it's fine if you don't know):If I made a bootable container(file), would that derived image fall out of sync with the parent Bazzite project? Would I have to manually build a new container and rebase each time I wanted to check for updates? I feel like I'm on the cusp of seeing the big picture, but I'm not quite getting it, and maybe that's because I haven't worked at all with services like Podman and Docker.
Yo OP, this is me @poki@discuss.online from another account. I had intended to leave the Lemmyverse for a while, but had to come back earlier than intended when I read your comment 😅.
So, without further a due.
Okay, I appreciate the links. I've had a chance to go over both, and I think I get the gist:
Thank you for your time!
rpm-ostreeis a work in progress, and it will be depreciated and replaced withbootc+dnf
What do you mean with "work in progress"? You've been using it relatively often in this thread (and IIRC even in others) when talking about Fedora Atomic and/or uBlue and its technologies. Like, do you consider
dnfto be work in progress becausednf5is around the corner?I don't recall any mention of deprecating
rpm-ostree, though I might be wrong. But, yeah; it will definitely lose focus in favor ofbootc+dnf.For example, I have a VPN client that is installed via a
.runscript, so it doesn't work withostree. If I wanted to apply this software to my system, I'd have to create a bootable container, then rebase to that.I'm not actually sure if it works out just like that as of right now. Creating your own image or bootable container is definitely a powerful tool that can help bypass some imposed limits; like e.g. populating files in
/usror baking in (current)rpm-ostreeactions -some of which actually wouldn't work otherwise (as of right now)- directly into the image. Finally, it allows one to move from an imperative to a declarative system. However, I'm not aware if it enables one to bake-in the installation of.runfiles. My only experience with.runfiles myself was with Davinci Resolve, but that's notoriously difficult to install regardless. Thankfully, it's a popular piece of software and thus avenues have been created by which one could install it on Fedora Atomic and related projects.So, in short, I don't see how creating your own bootable container would help you to bypass this.
But my goal isn't to create a new image, just to apply transient packages to the base Bazzite image
Exactly.
If I made a bootable container(file), would that derived image fall out of sync with the parent Bazzite project?
If you achieve it through legit means (i.e. uBlue's own documentation on this or through a sister project called BlueBuild), then no.
Would I have to manually build a new container and rebase each time I wanted to check for updates?
By either of the two earlier mentioned means, the building is done automatically (on a daily basis) by GitHub. Furthermore, when you update, you just receive the latest image from your own GitHub repository in which your own image resides. Updates continue to be done automatically in the background, so you won't even notice. Finally, if it wasn't clear yet, you only have to rebase once.
I feel like I'm on the cusp of seeing the big picture, but I'm not quite getting it, and maybe that's because I haven't worked at all with services like Podman and Docker.
That's fine. Please feel free to inquire if you so desire!
Alright, having said all of that, let's get to the crux!
So, did you try the following methods when installing the
.runfile? If so, how did it go?- Simply double press or right-click then install (of course, after applying
chmod +x). - Within a terminal with
./<name of .run file>.run - Within a terminal with
./<name of .run file>.run --appimage-extractand then interacting with the AppImage.
If all of the above have absolutely failed, I only see three ways going forward:
- Creating your own Flatpak 😅.
- (OR) Taking this to COPR 😅.
- (OR) Succumb to Toolbx/Distrobox 😅. Like have you tried running the
.runfile within Toolbx/Distrobox? If so, how did it go?
EDIT: 😅. I had hoped you'd return with a reply soon~ish. But alas... Uhmm..., I'll be off for a couple of days and will return only next week. Just wanted to let you know*. FYI, I'll probs return with (yet) another account.
Sorry I didn't get back sooner, but I made some progress.
What do you mean with "work in progress"?
Their words (second video, I think), and more in reference to how they are still working out how they haven't yet covered all of the use cases (like maybe my needs can't currently be met by
rpm-ostreeorbootc).rpm-ostreehas functional limitations, andbootcis still being developed. Obviously, both are still useable and useful, and Universal Blue has been using them for quite a while. I may have been reading too much into it with the "depreciation" comment.So, did you try the following methods when installing the
.runfile? If so, how did it go?It can't work on its own. Running with
shor making it executable runs the script, but it fails when it tries to write its icon and.desktopentry to/usr(it also doesn't take an--appimage-extractargument). You can usesudo rpm-ostree usroverlayto create a temporary FS overlay for /usr, but it's wiped on the next boot. Still, that allowed the installation to complete.I discovered that it's installing all of the necessary components to
/opt, and they remain functional. I was able to manually run the daemon script required and get a WireGuard tunnel established in the client.Now, I'm trying to get a
.servicemodule to work so it can run automatically as root on a reboot withsystemd. So far, it's giving me a 126 exit code, so I still haven't figured out how to escalate its privileges automatically, but this is the most progress I've made to date.
A VPN is definitely an example of software you should use rpm-ostree to install.
To add some detail, anything you install in a distrobox (or other sandbox/container) can't add kernel modules, which I think is the error you're getting.
A VPN is definitely an example of software you should use rpm-ostree to install.
I think it's fine if you use rpm-ostree for it, but it's not necessarily required. I recently found out that the Mozilla VPN developers are experimenting (!) with building a Flatpak, and having tried it myself, it works very well.
It's definitely not required. ProtonVPN has a flatpak client, so it's not like the client can't exist in other layers, in theory.
I may have to follow up with IT, because they have OVPN for connecting to a different domain on the network, but not this one (probably low priority to change). Perhaps they can offer a way to connect that isn't this specific client.
Oh! Note that in Settings under Network, there's also a VPN setting that allows you to manually configure a VPN. It has an "Import from file..." option, so presumably, there's a way to obtain a config file that should make it work. If not, knowing which options to set might work as well.
My advice is to stick to a popular and well known general purpose distro. Even though I have never tried Pop os myself I would recommend it over that Brazzite thing (which has a very similar name to that one very popular video streaming site if you know) because I have heard good things about Pop os.
Not Brazzite, "Bazzite." It's a mineral, and its naming proximity to an adult website is entirely coincidental (and I would hazard a guess that the mineral was named first).
Honestly, I'm not that concerned with Bazzite being newer, because it's based on Fedora CoreOS. It utilizes
rpm-ostreeto manage system upgrades, so for any bad updates, you justrollbackto any previous deployments (and you can pin specific ones so you are guaranteed a stable rollback point). Additionally, you canrebaseat any time, so you can swap out the system layer for another ostree-based image without touching any of your files in/etc,/var, and/home.Pop!_OS is a great choice, too, but the biggest problem facing the family of Universal Blue distros isn't notoriety, it's the fact that Fedora Atomics in general are still relatively new. The examples are still being written, and people are getting used to new tooling.
But if you don't need specific customizations like me, and all your software can be found as appimages or flatpaks (or is already installed), Aurora, Bluefin, and Bazzite are all rock-solid choices that will "just work."
Vpns are the things that make more sense to layer. It's fine, have fun with bazzite