#1

OK, so since I am a masochist that enjoys living at the leading edge with the occasional insanity tromp through the bleeding edge, I have to ask. What is/are the suggested approach(es) to getting a usable system based upon Silverblue? Should a person’s first steps focus on the core ostree, and getting containers and podman set up to cover desired potential usage cases, then populate those containers with the pertinent flatpaks? Although I have been watching the use of containers grow, I have been sticking with what works for me in regards to the traditional Fedora Workstation based system, with the occasional headless server when needed. Thus I have been ignoring the gory details of using containers daily, and even flatpak as an application package deploy method. I understand the advantages that would seem to be in their potential, and I am wondering if through use, some of the community members have experiences they would share with those of us just beginning to use these technologies?

#2

I’ve been building Docker images for a few years now, but the concept of a “pet container workstation” is relatively new. I’m planning to run Silverblue 29 and Antergos in a dual-boot on my workstation and sticking with Windows 10 Pro and Antergos on my gamer laptop.

My main workload is data science, specifically R / RStudio and PostgreSQL. So it lends itself well to a container environment - this project was in part inspired by Silverblue: https://github.com/znmeb/data-science-pet-containers.

The gotcha with a pet container workflow is that it doesn’t really work on Windows 10 Pro or MacOS. Docker on those systems is done inside a full virtual machine running Linux. That machine has a virtual disk drive and is typically allocated a fraction of the RAM the system has.

For example, on my gamer laptop, the Docker VM gets 2 GB of RAM out of the 8 GB the laptop has. This kind of inefficiency is intolerable for data science, so I run native binaries on Windows.

Advice for setting up a Silverblue workstation: I’d say do as much as you can with pre-built images from the Docker Store / Docker Hub. For example, Data Science Pet Containers is built on the official PostgreSQL and pgAdmin images along with the official “Rocker” RStudio image. I’m still using Docker Compose for orchestration but the trend is clearly towards Kubernetes.

And do as much as you can on the desktop with Flatpaks. In my case, the only apps I have on my desktop that are available as Flatpaks but installed from the Silverblue repos are stable Firefox and GNOME Boxes.

1 Like
#3

I was thinking that it would be best to avoid layering as much as possible. Towards that end I can envision circumstances where I may require to use containers, which I see as being very good at providing a base image to build upon by adding flatpaks as necessary. The problem I am trying to wrap my head around is that I am used to the way I set up my Fedora Workstation and the associated workflow I put through it consequently is pretty firmly entrenched in my psyche. Resolving that and translating to a immutable OS + Container base image + flatpak application for the desktop is where I fall short of the vision. Somewhat due to the urge to have everything available all of the time from any perspective. As well as things like hardware that I use sometimes, such as a Mixed Signal Oscilloscope require physical port access and control. Thankfully, I don’t have the need to run containers on my Windows 10 Pro laptop, since it is specifically for proprietary software needed by me to support my customers, and unfortunately there are not available open source alternatives.

#4

Thanks for the advice. I’m still working through the ‘pet container’ idea, which I cannot seem to get a lot of info about. I thought a good place to start would be podman or libpod, I guess it is actually called. I went through the getting started and managed to create a container which won’t run since I didn’t have ‘slirp4net’? Which is something I must install apparently, and likely layered as well. I did manage to get the info about the pod image which was informative, and easily readable. So now I’m off to the Docker Store / Docker Hub to check into the Pet Containers. Ahhhhh! I can smell the mind numbing technical acronyms from here!

1 Like
#5

I’m still working through the ‘pet container’ idea, which I cannot seem to get a lot of info about.

It’ll be hard to find any concrete information about them, because (almost by definition) they are all going to be unique. Each person is going to have their own settings and packages they want to include.

What has worked for me is to examine the configs for other people’s pet containers and iterate on those. I found @jlebon’s container to be very useful (in fact all of his dotfiles) as a starting point:

Or have a look at @walters set of dev containers:

And I’ll even include my own for grins:

It will be interesting to see if we can collate these kinds of examples into some sort of framework that would allow users to build their own pet containers using some sort of tool (or dare I say…wizard!?).

I would be interested if you find any ‘pet containers’ labeled as such on Docker Hub/Store, simply because I don’t know if that concept has gained adoption outside of the Silverblue users.

#6

I have a “more traditional Docker” version - I build a network of containers with Docker Compose from official repos in the Docker Store / Docker Hub, rather than trying to build one “pet container” that has everything on my desktop. Presumably I could run the identical network on a cloud server from a Chromebook, bandwidth willing, of course.

One of the attractions of the pet container approach is that quite a few third party packages aren’t tested on Fedora - just RHEL/CentOS and Ubuntu LTS. So rather than build them from source and have to do my own support, I run them in containers.

#7

Thank you for providing the links. I understand what you mean by the variances of user set up’s, I realize there won’t be a single solution. I’ll have a look through the files, it’s good to have examples to refer to.

#8

Thank you for the advice, I went to Docker Hub, and did manage to pull an image. The only issue I ran into was missing slirp4netns. I had to install (slirp4netns) using rpm-ostree, and reboot. I note this is a library used by Podman and other apps, and since you cannot load an image in podman without it, I was thinking maybe there is some issue there with dependencies not being met at install of podman. In any case, once I installed slirp4netns things worked, I could load an image. Now I am armed with examples and advice, I will be reading for the weekend I see. Perhaps, before Silverblue get’s a “wizard” for post installation configuration options as @miabbott points out, a guide may be a good place to start. In my case, I consider myself a layman in terms of current best practices for container use, indeed the same could be said for my level of Systems Admin knowledge. Silverblue presents (for the average Fedora user) a significant paradigm shift in how the PC is being used. The simple concept of sandboxed everything outside of your core OS bits, is quite subtly more involved than first blush would indicate. Having said all of that, I will say that I was still able to use Silverblue right out of the box when I installed F28 Silverblue on bare metal. Aside from the missing flatpaks of favourite apps, everything worked, at least until it didn’t.

#9

The only issue I ran into was missing slirp4netns. I had to install (slirp4netns) using rpm-ostree, and reboot. I note this is a library used by Podman and other apps, and since you cannot load an image in podman without it, I was thinking maybe there is some issue there with dependencies not being met at install of podman.

You are hitting this issue - https://pagure.io/teamsilverblue/issue/39

TL;DR - podman should have slirp4netns as a dependency

It’s currently a Recommends, but might need to be a hard Requires

https://src.fedoraproject.org/rpms/podman/blob/master/f/podman.spec#_76

#10

In my opinion, we need input from all types of users. From experts to laymen. :slight_smile:

If you can document your experiences trying to create your own pet container, what worked and what didn’t, we could start to build out documentation around this. We know there isn’t going to be a one size fits all, but the more documentation and examples we provide, the better off we will be in the long term.

#11

I’ll definitely take some notes while going through the process. Be glad to share, if they’ll be of help is an entirely different matter.

#12

Currently, I am in the middle of machine repairs for my customers, so I am not able to get to this forum as often, but thanksgiving is here and a bit of a break. I looked over the info you provided, which was quite a bit and was very informative for me. It truly brought home your point about the variance in set up. It also reminded me of my need to understand what I am asking before asking it, sort of a conundrum. In this case the question seemed simple enough to ask, “What is the suggested approach(es) to correctly set up a Silverblue Workstation?”. It isn’t in fact a simple question to answer, especially succinctly. I think there is a commonality of approach between the examples you provided for me, and it is that approach I am interested in. Perhaps the Install/Upgrade could offer the option to have automatic setup/configuration prior to creating the ostree, eventually. In the interim, I am starting my approach with writing a list of things I absolutely need to have as part of the immutable kernel, layer appropriately, then move onto flatpak installation of pretty much everything else, including the development setup I choose. I would like to keep within the bounds of operating Silverblue, with minimal/no layering, and copious use of flatpaks. Avoidance of OSTree compromising technologies should be viewed as verboten IMO.

1 Like
#13

Hello all,

I have wrestled with this thought for awhile, over the years, and using Silverblue brought it out for me again. I had become accustomed to my rote when setting up a Fedora Workstation for myself or others. As such progressed, unfortunately, the gap between fully understanding what exactly I was doing, and what I thought I was doing during the process widened. With Silverblue I have been forced to come to terms with that knowledge gap. That is what led me to the question I posted here in the first place. It is, not coincidentally, also what gets me to think that another guide/manual may be in order. Fedora has loads of Documentation around it, and also from the greater open source community. In the case of Fedora, I note Installation Guides, and System Administrator Guides, and the Release Notes. What I am now wondering is should there be a manual for Setup/Operation of Silverblue, to cover the topics that are encountered during the lifecycle of use of the OS? I would be willing to put effort into authoring such a document, and not just as a way to pay forward to the community, but also it has been my experience that making technical documentation on any given topic generally adds to your own knowledge about said topic. I am thinking that the above noted setup’s, and others in the community can be used as solutions to show what is possible. The guide would range from the very basic to the more elaborate, and even into automation of setup. So what does the community think?

1 Like
#14

I’ve also thought we need something more detailed and more Silverblue-specific than what currently exists in the Fedora documentation.

Before Silverblue had a permanent home, I was floating around the idea of these kinds of docs and finally got a copy of it logged on the fedora-docs site.

I would love it if we could get more collaboration over there. Let me know if the ideas are good, where we can add instruction or where we could simplify things.

#15

Hello,

I took a fast look and commented on pagure. I think it is a solid first pass concept and I will go through my personal notes on my efforts with Silverblue so far to see if I can add to what you have started. I definitely would like to help, since selfishly I will learn more about Fedora/Silverblue/Flatpaks/Containers, etc… in the process.

#16

Sounds great!

I don’t think we need to get the docs absolutely perfect the first time…they just need to be correct with the information contained within. We can iteratively improve them as time moves on; so don’t hesitate to submit anything you have, even if the formatting is off or there is more content to be added later.

Also, if you have suggestions on how to improve that original outline, just comment as such and we can continue to tweak it.

#17

So I started an asciidoc document from your suggestions at the fedora-docs site. I was thinking of only lightly touching on the installation since Silverblue already has a pretty good installation document already. Perhaps a bit on making the usb stick using fedora media writer for instance. Once into the manual partitioning vs automatic, again the installation doc does a pretty good job I think. Perhaps some info from the howto’s and guides available in the community already around Atomic say, and ostree too perhaps, could augment whatever we have. I’ve only just got your basic titles and sub-titles arranged in the document so far. I was wondering if I should put it on github for us to cooperatively work on it at first. Asciidoc is pretty good to work with, I use Atom for the editor right now.

#18

Yes, please submit it to the fedora-docs repo. Just getting it started is the hardest part :wink:

#19

Hello,
Do you want me to submit it (the doc) in the template format? Or can I submit just my asciidoc file?

#20

Just submit whatever you have. We can tweak it as needed.