We're starting now. Please. Please quiet down.
Hello folks. Today we are here to talk about Fedora
Corvus and how you can use that to do some fun stuff.
The fun stuff being, you know, hosting your own dedicated multiplayer server so that you
and your friends can have some fun. I'm joined here by Sumanthro, myself Akash
Deep Dhar. We both work for Red Hat, but we are Fedora Project Contributors, and part
of Fedora Council as well. So we welcome you to this talk.
So about the things that we would want to talk about, the first and the foremost thing
would of course be the OS, the thing that we run our containers on, and why exactly
should you give a damn about it when there are like a plethora of Linux distributions
out there with their own twists and turns attached to them.
The next thing is of course putting that operating system to use, that of course is to have our
own dedicated Minecraft server, understand how that process works and how easy or difficult
it can be to actually put that to use. We'll put that to use again for the Valheim
server too, because guess what? The community is great, and the folks have always created
containers, and when it comes to containers, we always have something, some kind of platform
to make use of. And by all means, if you trust me enough,
you can totally scan this QR code, and it will lead you to the documentation, so you
can totally go along with the talk, because this will be more hands-on. We'll be doing
stuff over here, and we'll be making you folks understand as to what is happening behind
the scenes and why exactly are we doing that. Or you can totally head over to the schedules
page on the Container Step Room and find our links over there, so documentation is
over there as well. Speaking of the operating system that we're
going to talk about, what exactly is Fedora CoreOS? To begin with, it's a set of packages
that's very minimal in nature, but it's very focused to the container-based workflows.
So you won't get to see a lot of bells and whistles out of the box. Sure, there's an
option to add those by yourself whenever you feel like, but then again, it's the networking,
it's the container-based workflows like Moby, Podman, which I installed over there, as well
as some tools like Firewall that you would need to make sure that people actually connect
to your containers and be able to do what they want to do, which are pre-installed,
which gives you just enough of a stuff to get started, and a canvas to actually add
your own distributions, your own packages on the top of it, and grow upon it as you go
on. And there's this thing called RPMOS Tree, which is based on LibOS Tree. The entire file
system is transactional in nature, which essentially means that if I were to add packages on the
top of the existing deployment, well, an existing set of installed packages, I can do so by
ease without actually worrying that, oh, what's going to happen if I add this bleeding edge
package? Will my deployment stop failing to work? And if it does, you can always find
your way back. It's a Git kind of a workflow, so if you understand Git, it's pretty much
like that, so you can always rebase your deployments, your own set collection of packages at any
point in time, and just fall back at any point in time you want to go back to. The next thing
is the fact that this is secure as well as scalable. So we, of course, would like to
have this not only deployed in bare metal servers, but as well in a plethora of VMs
having their own set of purposes. Now, the way we do that is by the use of configuration,
and it's kind of difficult that you need to configure like tens of thousands of machines
with hand, so guess what? You don't. You use something called beauty in configuration,
which is a human readable form of something called ignition, and what it exactly does
is you specify what kind of change that you want to make on that operating system. Some
users that you want to add, some files that you want to make create, some networking rules,
firewall rules, services to start stuff like that. You can do so so that when in the first
boot, you get the operating system exactly the way you want, so you don't really have
to install stuff and then configure it and then do that like thousands of times just
because scalability is the thing. The next thing that I want to talk about is the fact
that this operating system is available in not just x86 underscore 64, but in a lot of
other places, architectures such as AR64 and ST90X as well, and we plan on providing the
support for other operating systems architectures in the coming times. Speaking of the minimal
set of packages, how minimal is it that we're talking? Let's give that a number. So we have
like three release sets, the one for stable, the testing, as for us next, they are determined
by the number at the penultimate decimal place, so 3.0 is stable, 2.x is testing, and 1.x
is next. And you can totally see what those purposes are for and why exactly would someone
want to go for a next over stable or vice versa. So say for instance, if there's a contributor
who wants to develop this thing, they want to test all the bleeding edge packages that
comes to this platform, they know what they can choose, and for the ones who really want
to set up a server for their home people, they don't really want to move around a lot
of stuff. They can either go for stable or they can reach out to our friends at CentOS
because they have a CentOS team called OS2. So how exactly does this operating system
become secure and scalable? I mean, I do sure like giving a business pitch because it's
all buzzwords. So there are ways to make sure that the packages that you have installed
or to say layered on the top of your existing installation, the way it gets automatically
updated is very much in your control, which essentially means that it can go out in the
open, start downloading everything, every new and bleeding edge stuff if you ask it
to, or just hold back on it just because you want a stable operating system, you want to
really curate the packages that you end up having so you have a lesser variness to updates
that you end up having. So it's totally in your control and by all means there are ways
to totally disable automated updates as and when you see fit. And these updates for the
packages that you have installed, these don't get applied as soon as they get installed,
but rather you kind of make those applications of those updates when you want them to happen.
Usually it's a reboot because, well, the service actually happens to go through all the packages
and refresh them based on the updates that has happened in the last boot, but you can
always do it either live or in the next time as well. So at any point in time you feel like
that a certain update has gone through which should not have, you can rest assured because
that has not yet applied and you can always fall back to the previous deployment. And
oh, I just happened to explain the last point. So that is rolling back whenever you feel
like it. So depending on how you want to use this, you can use it on a Raspberry Pi if you
are having one on your shelf gathering dust or you can have multiple VMs of yours on that
desktop of yours that you think is an overkill and you don't use it anything else other than
gaming. And of course there are choices to use it on the cloud too, which we totally suggest
because this is something that we want to deploy on scale. So the kind of replicated
deployment that you can have kind of depends on the kind of purpose that you would want
to use this for. Right. So that's basically about operating system itself. Now we're going
to make that thing, put that thing into use and understand how we can do some fun stuff,
you know, set ourselves up an environment on this laptop itself. I set myself up a virtualization
host and I'll configure it to the way I want it to. So if I want a user, I'll add it there.
If I want a server to run in a certain way, maybe allow for no more than 32 people, I'd
do so too. And by all means here again, this is a thing that you can follow along. So you
can feel free to read the documentation by scanning the QR code and we'll move on to
the next one. Right. So the set up environment that we have in place is VMware workstation.
We really wanted to make sure that things are a lot more easier and off-limited scope
for scope of this presentation. But you can use Quemu, you can use virtual box, you can
use anything that you want or if you want to just nail it, you really want to make use
of a bare metal too. And the specification that we provided it for are listed over here
and for this case just because we want a server that actually runs, that actually is something
that won't get a lot of packages, a lot of updates down the line, we really want to make
sure that this runs in the long term, we have approached the stable stream for this one.
Right. So I'm going to exit out of the screen for a bit and go more into detail about the
stuff that I talked about over here. Right. So speaking of the demonstration, I have an
entire directory of files that I need. Now these can either be firewall rules, the system,
the units that I want to enable on the first boot, the packages that I want to install,
the configuration for the swap that I want to put into place, stuff like that. So to
get started, like I mentioned, we required a butane configuration. Now what exactly would
that be? Let's find out. Pute cons and of course mine.pu. Well, basically it's just
a list of directives that lets you do the stuff that you want to make happen. So if
you want to create users with the set password for them, add SSS authorized keys, stuff like
that, you can have them over here. The same goes for the stories, the symbolic links that
you want to make happen from one folder to another directory. And you can have files
that you source from a remote location and place it to somewhere else. Then finally we
get to the system, the units part, where you can actually declare services. Now these services
can either be for installing packages, adding firewall rules, enabling containers, stuff
like that, and you can totally control them the way you want. And finally, you know, there's
this cadence about what needs to be done first that you can use with the use of system D
directives, like before, depends on, but you can also mention them over here. Right. So
as you can see that we have roughly three system D units that we have mentioned over
here. The first, of course, is to install portman compose and firewall D. We have portman
pre-installed but not portman compose, so we might as well end up getting one. And the
next is to allow Minecraft server to firewall. So before that we, of course, would reboot
because like I mentioned, your updates only get applied when you want them to be applied,
which by this case, by the default is reboot. There's also an option to apply them live,
but then again you'd want to use them for applications like, well, a text editor or
something of that kind, but definitely not for something that will end up becoming a
service on itself. And then finally starting the dedicated server, now that the stuff that
we needed for the firewall D service rules are everything in place. So just to avoid
using more time during the presentation, what we did was, well, we did that in the hindsight
like previously. And now what we have over here is the IP that we can connect to the
container, the one that's running firewall D, the one that runs that firewall D service
as well as the Minecraft dedicated server. To go forward in detail, I would show the
status of the units that I mentioned off, like those for allowing these and depending
on what kind of condition that you make happen, you can either make them run once, like if
the firewall D service has been enabled, so you don't want to enable it again. So you
can always put a flag of some kind telling that if a certain condition satisfies, which
it seems to have, it won't run again. So the next thing that I want to show you is,
of course, the server itself. So if I were to follow a certain unit, let's just say start
Minecraft server, but I'm going to save myself some effort and go like that. So we have this
container right here that's running on Podman. And yeah, there's this internal IP address
as well that lets us connect to that. And finally, about the services that lets you
install both Podman Compose as well as the firewall D. We'll head over here. Where's
the terminal? There it is. And do, of course, mine. It's just a moment. And allowing system
D system, allowing Minecraft server to the firewall. So we have set also the condition
which tells that once that thing is done, you create a file called done, allow Minecraft
server to firewall. So with the services like these, we kind of make sure that the service
runs exactly when we want it to and not any time more than that. So once it's done, it's
done. And of course, the condition for setting up in the first boot kind of falls in line
for the one that helps us install these packages, especially for the Podman Compose and firewall
D. So condition for the first boot is true, but you reboot after this thing has completely
done. And by that, we help applying these packages on the existing deployment. Right.
Let's say we'll go over here and we'll check the IP address again. This happens to be,
this is not forwarded. So as much as any of you folks have Minecraft installed, I'm really
sorry that you folks won't be able to connect to this one for the security purposes. But
I'm going to connect to it and see what kind of world it gets me into. So we have the IP
192.168.234.129. Let's see if it's reachable. Well, actually it's kind of a firewall D thing
if it's the service runs. And if the rules have been applied, we would be able to. Hmm,
just a moment folks. Oh, it seems to have run. Now to have a plan B and a plan C, I have
heard stories of folks losing their presentations. They have like three flash drives. So I also
thought of deploying one in my home, but we probably won't need that because guess what?
We have a sour that says that it's running on this host and it's running on, well, the
forced and set up that we have here. Well, the other one, the plan C, of course, does
not happen to be a plan C anymore because there's something that I can't reach out to.
So I'm going to connect over to this one. Right. So the worst thing that can happen
to a player when the entire Minecraft world has happened. But then again, if I were to
all tab out and were to check the logs of the service, I should be able to see that
I indeed have connected and have reached. So, you know, folks can totally get creative with
what they can do with this. They can have their own servers hosted on their local place,
maybe have an OCI cloud to do some reverse proxing to have their friends connect to it
as well. The possibilities are endless. And when it gets deployed on scale on cloud, it
just goes to the next level. And it's not just for gaming, but rather for if you want
to do a local deployment for Plex or anything for that matter, which uses containers, it
is possible. Now I'm going to hand it over to Sumanthro to be able to talk about the
Valheim setup, say, back to the presentation. Or to you, Sumanthro.
Hey, guys. So exactly much like the Minecraft setup, we have the Valheim setup, which is
basically setting up the environment variables, configuring the host, making it work. Technically
all the documentation has been put out on that QR code. So, if I go over here. Yeah,
so all the required files has been put out here. So, like Akash explained, we have a
buton conf. So, if I go inside, you would have a buton conf configuration generated
by this ignition file. So, if you look at it over here, the buton conf configuration
has the storage, the directories, and all we need the files, any rules. And finally,
the system D unit services that needs to run, specifically in much like the exact case of
Minecraft. If I go back, this is actually the ignition file. This is the back door of
how CoreOS would basically look at that configuration and parse it for its own purposes. So, this
is perfectly mission readable, not supposed to be edited by hand. But, you know, if you
guys wanted to change something, that's supposed to be on the buton side of things. Coming
back to the configuration, there's a root. There's supposed to be ETC system D and then
the ZRAM generator service. And this one is swap on ZRAM service. By default, we have
put a ZRAM zero as the default setting. It requires a bunch of RAM and we literally have
put one of those services over there just to ensure things are going fine. Going back
to my systems, there are going to be a server through the firewall. That's exactly the same.
If I open it, that's a very basic, that's a very basic thing. Going back, we have the
start well dedicated service and this one is going to have the podman compose parts
and that's an execute script with the up and down. Coming back to the point, so one
more thing, we actually hosted it on private servers back in the home. The way that we
kind of can get it up and running right now is reaching, where was the terminal? Go ahead.
So for the interest of time. I should probably practice turning on microphones before speaking.
For the interest of time, what we'll do is we'll just not show the Valheim demo. Unfortunately,
apologies for that. But this is totally reachable on the VM that we have set up over here and
the port that it goes on is reachable. But the point being that these things are very
possible, fun stuff and kind of gives you a reason why you would want to try a new workflow
where the entire file system, the entire packaging workflow is nothing but a get kind of a thing.
So you can always roll back, roll front, depending on what you want to do. And the best thing
that you can do is, well, try it out today if you have a VM to spare or a device to do
say. Right. So that's about it for the presentation. We'd really love to have your questions and
answer them too.
We have a bunch of time for questions.
So thank you very much for your presentation. I had a question about the relationship between
Fedora Core, Fedora Core OS and persistent storage. My understanding is that when you're
working in containers, you want everything to be ethereal and temporary and don't worry
about that. But like you mentioned, if you have some sort of media server, how would
you address that sort of like persistent sort of ButterFS data pool? Is that part of butane
or how is that configured and managed? The way we have it is by setting up mounts. The
way it works is anything that gets affected by the installation, removal, updating of
the packages, these are the ones that are very transient in nature. So these can get
affected. But if you have mounts that lead to some different place, they most likely
won't be, the home directory would most likely stay untouched. So as long as it does not
have anything to do with a certain package, if it's not a file that gets introduced when
you install a package or something of that kind, it for most likely won't be touched
and it would always stay the safe. Any more questions?
Okay. What is the relationship between 4.0.x and 4.0.i.o.t? And does it make any sense?
Has everyone got that? What's the difference between Fedora CoreOS and what?
Fedora IoT. So for the record, Fedora IoT was an official
edition for a long time, which means Fedora would push in updates regularly. CoreOS recently
became an edition which is a release back, which now brings into question the release
criteria for IoT and the boards that we support. They were very officially declared as supported.
But in case of CoreOS, there's no such official support that was given before. It was never
made an edition. So that's one thing that you're missing out on. Second thing that you're
missing out on is IoT, on the other hand, is released every six months with the release.
Fedora in CoreOS, in this case, would have a stream cycle, which means the next would
be if today we get a next stream, in 15 days that would become testing, and then in next
15 days it would become the stable. And then that's how it's going to roll. Obviously,
given the fact that the next stream is tested by the CoreOS's own CI, which runs for almost
all the basic tests which is required for the thing to run, both are based out of OS
free. But again, every 15 days, CoreOS updates to the next stream or moves through the next
stream. In case of IoT, you get it every six months.
Hi, thanks for the talk. I would love to see this kind of bootstrapping of CoreOS happening
on SystemDN spawn, for instance. Would that be feasible, like having that butane declarative
way of just instantiate me something under SystemDN spawn? Is that something that can
work already? It technically can. But then again, we kind of have to understand if SystemDN
spawn, well, the environment inside of it will have SystemDN or not. So it's very much
possible. And one of the use cases that I've seen using it is building packages or testing
them for that matter. So the very fact that, you know, you don't really have to configure
it when it's up, but rather decide how it's going to look like from the get-go, and that
deployment can be replicated like anywhere. So that really makes it a prime image of some
kind. And it does not even have to be a container image, right? That thing can be based upon
and using a virtual machine or SystemDN spawn, as you mentioned, you can have that kind of
a blueprint. But guess what? It's not a container. It's a full-blown operating system, which
is running like it would on a bare-metal node.
Okay.
Thank you.
Okay. This is the last question we can take.
So I was wondering this ignition file is only applied on the first startup. Can we make
some kind of declarative configuration for Silver Blue? Or for, and not for Silver Blue
for CoreOS? Is this also supported?
So if I get your question correctly, you are wondering if a certain configuration can be
run again if I want to, on the same deployment.
Right. So it's totally possible. You know, the thing that you end up getting after running
these many steps after running the butane configuration is a deployment. So what you
can do is you can use that deployment and run a butane configuration on the top of it.
So that becomes your base deployment. And anything that you add on the top of it is
the resulting deployment. So the very thing that deployment states in this case is a state
in which the operating system is in right now. So, yeah. So if you just mangle the state
to create a new one, that state becomes your existing state. That's about it.
One last thing, guys. We have a Fedora boot. Feel free to go there, grab swags and whatnot.
And thanks for attending. Thanks.
Hey, guys.