I'm going to talk to you about system manager, I'm really interested to hear about this and
I want to talk to you about this.
Hi, so I'm Ramsis.
The title of the talk is a niche in Nixon, almost any distro.
That's a very...
Yeah, we'll see.
We're not very young, but that's the goal that we would eventually like to reach.
So who am I? Ramsis, RVDP, most places online.
In this and past, I used to be a theoretical high energy physicist,
but then I kind of figured out that's not really much of a job market for that.
So I went going to IT, worked as a fertilizer, like a full-steck Java scholar, developer.
Then I took a bit of a detour and worked as a tech lead security engineer for international NGO.
After that, I went back to more hardcore engineering,
and I became like an independent software engineer.
I'm currently working mainly with a lot of mixed related consulting.
I've been using Nixon's maybe 2017, so quite a while.
And in general, I just love working on all kinds of open source projects.
I think it's just really rewarding.
Yeah, you can find me on Matrix.
So I'm just going to quickly introduce system manager,
project that I've been working on a little bit, started maybe a year ago.
So that's a problem that we're trying to solve.
What did we come up with?
What are the hopefully current limitations and what's next?
So the problem we all know next was we love it, it's great.
But the problem is it's kind of all or nothing solution.
So if you want to use Nixon's, you kind of have to do everything with Nixon's.
Your whole system is running the distro.
And you kind of have to immediately dive into the deep ends,
like just no way to like start with another distro,
and kind of start using Nixon without needing the whole package.
There is a whole manager that's usually done the next best thing,
which you can use on a distro,
because you can manage your home profiles and such,
but you cannot do anything on the system level.
So you cannot manage system level, system g services,
and these kind of things.
And that's kind of what we try to solve.
So can we have next manage system level configuration,
but not necessarily have it managed the whole system?
There's a couple of potential solutions that you can think of.
One of them is system depotable services.
It's something that system the introduced,
I think now a couple of years ago.
The idea there is that you take one or multiple services.
You package it up into a kind of image.
You can send it on another machine,
and you can kind of have system restart those services.
That's one thing that works,
but it was not really ideal.
There's also Nixon's containers,
that I haven't really looked into it too deep,
but I heard that some people do similar things
as what we're trying to achieve using Nixon's containers,
unlike other distros.
I'm not exactly sure how they do it.
In the end, just system the end spawn.
So I guess I take kind of wrap up the directory and then move it to another system,
and run system the end spawn directly.
The other option is to kind of do what home energy it did,
and you write like a custom switch to configuration,
that takes some kind of top level directory,
that links to all the things that you want,
and you put that in place.
So that's what we want with.
It's like the most straightforward option
and we have kind of knowledge of how it works.
The advantage is so it's a well understood system.
We've been there, we do it on Nixon's,
we do it with home energy,
so we kind of understand the trade-offs.
Also we get native system B services,
so the idea that we will actually populate ETC with a bunch of sim links,
and then you just run like you use the host system
to run those services.
So we don't have containers, we don't have images,
we don't have not working stuff.
We don't have to deal with any of that thing,
of those things that can be the complicated stuff.
And it turns out it's actually a very small number of
fundamental operations that you have to support
for Nixon's style modules to work.
So mainly you need to be able to create fast and ETC.
You need some way to run system the temp files,
since all of stuff depends on that to put stuff in place.
And you need to have some kind of reconciliation loop
to look at the current system,
the state look at what changed,
and what you have to do like start,
start restart, reload, services,
start, that timer, sockets, these kind of things.
Some things are missing in what we have right now.
Some notable things are uses and groups,
mainly because I couldn't really figure out
yet a way to do that without, like,
crashing too much with embedding disorder,
or working on things like file systems,
probably never going to work,
because there are some things that are just,
yeah, you cannot kind of co-exist and manage it from two sites.
Same with not working, maybe there's a way,
but we didn't really invest in that yet.
Also things like global system D settings,
so you have, like, your ETC system,
the system.conf style of things.
Also there are the main question is,
how are you going to deal with embedding
destroy doing something,
you want to do something,
it's not really a clear way of how to combine that.
At some point you have to make, like,
a limit to the things that we are willing to manage.
The disadvantages of this approach,
we actually need to write that custom switch to configuration thing.
We need to write it, we need to maintain it,
so that's a bit of work.
We would like to be able to reuse as much as possible,
existing mix of modules.
But when you try that, it turns out that they actually have
a lot of interdependencies between each other,
because, like, we didn't mix packages.
They all live in the same manner,
and so they're kind of free to depend on a lot of stuff from each other.
So just taking a couple of them out is actually not easy at all.
And a lot of them are also just written for a mix of us,
and were only intended to have a work on mix of us.
So as soon as you take them out,
you notice there's a lot of hidden assumptions in these modules.
So that turned out to be actually not that easy.
Especially coupled with the fact that there's things that we cannot support,
like users and such.
And we also with this approach,
we have to be really careful,
but because we're literally sharing this space with you and
but in this row, so you have to be a bit careful
that you don't screw things up by starting to override stuff
that and but in this row is actually managing.
So that's a bit tricky.
We try to be very conservative in this,
so that if you kind of deactivate your system manager config,
ideally you should be back where you started off.
If it doesn't work, it's basically a work.
So what does it do currently?
So one thing is you need to have mix available,
which may or may not be an easy thing depending on your current set up,
but that's not something that we as the system manager provide.
So that's kind of the prerequisite.
Apparently it has to be running in demon mode,
where a couple of people that try to using it in single user mode,
apparently that they don't work.
I didn't really investigate much further.
There might be weird things if you're running in single user mode.
If you have mix available, then you can just mix from the binary,
pass it off like a system manager config,
and that should be it.
If you do that, what do you get?
So we run system V10 files,
scripted only the time file rules that were defined by system manager,
because of course them, but in this row can also have
time file rules that you don't necessarily want to re-evaluate.
We create a run system manager,
as well you follow pretty much like mix was this,
containing all the installed packages.
We create a drop-in in ETC profile,
that will populate your path,
so that actually the packages that are in run system manager software,
you can actually run them on the shell,
if you just refresh your session.
We create a system manager target that gets pulled in by the default target,
so whatever them, but in this rows default target,
that one will pull in the system manager target,
so that then we can have a bunch of system manager,
merge services that sit on the meat there.
So basically you're expected to have
every service that you want to run
a dependent system manager to target.
And then we register a profile and
an ETC route just so that mix doesn't delete your stuff
from underneath you while you're running.
So it's pretty close to what you would expect
from such a system.
It should be if you're used to mix
or home manager, this should sound like pretty standard.
This is not really any surprises there.
So what you found up with under-actual system,
you will have an EXTOR.
That was already there when EXTOR installed,
but so you will have a bunch of stuff
in that EXTOR that you built for you.
You will end up with a bunch of siblings in ETC,
very similar to what you would expect in EXTORs.
You will have your system B services,
that will also just be siblings.
You will get the mix kind of static linking
as I like to call it in the services.
So all stuff can refer to each other.
And you kind of get the thing that we like on EXTORs
where stuff doesn't just break,
because as far as I move the rounder,
search with everything,
it's kind of like statically assembled through all the
singleings in your next door.
And most importantly, one writing your config,
you can use a normal mix into relation
to just template all this stuff.
And you get a bunch of packages in path.
So all of these events should feel really familiar
if you used to mix with us,
because it's basically what we get on EXTORs.
So we need to go to this,
like if you know how mix us works,
you should be getting more as the same thing
within the constraints that we discussed earlier.
Can we use this today?
Yes, but it's a little bit of a working progress.
So it's, yeah,
we got it to work for the things that like
I wanted to use it for can be a working on this.
Basically anything that I didn't need
is pretty much not there.
There's no lot of documentation.
So that's something that we need to improve on.
And then the main theme for this,
we need more modules.
Which is kind of a chicken and acting.
Like ideally, we have people that want to use it
and that put over modules.
We try to have a bit of a compatibility layer
with mixed packages.
So we try to make it such that you can,
in large, take an mixed-packed,
just module,
copy it into your, your flake or whatever.
And have it work.
That sometimes works.
Sometimes it doesn't.
If it doesn't,
you can open a back report.
We can see maybe we should add some extra things
to the compatibility layer.
Maybe we just have to rewrite the module
because it assumes the way the one thing is in the
packages.
I think what would be really cool
is if this kind of,
if many people like this idea,
maybe there's a way to work with mixed packages
upstream and see like,
can we,
can we see if modules need to be
so mixed packages specific or not.
We can also go to home manager
route where they basically,
they have their own set of modules
completely independent.
But of course, it's a lot of maintenance.
So that would require quite a lot of people
to spend time on maintaining these modules.
Better works.
So if you just write the module for it,
it works.
There's a couple of potential improvements
that I see.
One thing that wasn't around yet when we started this is
the whole ETC overlay thing that was introduced
in the packages,
which is really cool.
If you're not familiar with it,
check it out.
It's really nice.
So the idea is that instead of like,
kind of incredibly creating
whole bunch of siblings in ETC,
you create like a,
an immutable far system image,
like an ERAVS image.
And then you create an overlay of that
and like a mutable part of your ETC.
And that's the real ETC that you see.
One idea that I had,
but I've not played with the ETC,
is that we could do the same on like,
this kind of,
but in this struggle,
we kind of mount,
like we make an overlay of us
of the actual,
the real ETC,
unlike the,
our static image underneath.
And then we kind of like the,
embedding this row ETC
remains like the mutable layer on top
and we just like put all stuff underneath.
Which could be a pretty nice way to,
not like,
clash too much with a distro.
If they already have a file
that we are supervision,
basically we'll see theirs.
And so if you don't see the file
that you're expecting,
it basically means you're clashing
with the embedding distro,
which may be a pretty nice,
like way to degrade.
You've as groups is something
that I think have already several issues
have been opened for that.
Yeah,
I think it,
we have to look into what's possible.
I'm not sure if it's even like,
theoretically possible.
Can we do this without like,
completely messing up here
or embedding distro?
I'm not sure,
maybe.
And then as I said,
figure out how to reuse
more just from mixed packages,
much as possible.
Just to like,
reduce the amount of wood
that's required to,
to boot shop a project like this.
One thing also that we,
that's interesting that we worked on,
is how do we test this?
Because in mixed packages,
we have of course the whole VM testing framework,
which is really amazing
and really enjoyed the work with
if you want to test these kind of things.
So what I kind of wanted is
be able to reuse that
but on different distros.
Turns out,
it's actually not that hard at all.
So I worked on,
kind of taking the task driver
and then just instead of a mixed image,
you take,
you've been to cloud image,
you take a fedora image,
that being image,
whatever you boot it up
and you get exactly the same test
instrumentation.
And actually that works pretty well.
And so this is one example.
It's very pretty small,
but you see the normal,
all put that you would expect from mixed stress,
even though it's actually booting,
you're going to kernel.
So this is like you're going to cloud image
that you just load with the same test driver.
And because we really like this so much,
we don't pull it out into a separate project
called mixed VM test.
Many PICMA Felix work a lot on there.
So this is a separate project
that came out of system manager,
but it's very interesting that you can also use for all the things.
So if you work a lot with different distributions,
and you like the mixed packages testing framework,
this is really cool.
I think now we have Ubuntu fedora,
and there will be only if I'm not mistaken,
but it's really not at all too at different distros.
And that if you're on a different distro,
make a pull request,
we would be very happy to merge it.
Yeah, if you want to try it out,
numtide system manager is there.
Yeah, that's it. Thank you.
Thank you very much.
This was a great talk.
Really interesting.
I'm going to have to check out those projects.
We have more time available for Q&A now.
So are there any questions in the audience?
And please repeat the question, right?
Yeah.
Will you work with, let's say,
the read on the Prec system distribution like fedora,
she's a group, or is it like that?
Please repeat the question.
Yeah, the question is whether we do work with,
like a read-only distribution like fedora silver blue.
I never worked with,
it's a little blue actually, so I don't know.
We assume that we can write,
but I think on this, this was probably,
I also write it just not persisted, right?
I think it was probably,
you will have to bake some parts into the original image.
Or you would have to have some way to at least
run like your system manager activate every time you boot.
But besides that, as long as you can actually still write
even in non-presistent,
it's kind of over-nade, that's what persistors such.
I would expect that you could get it to work, yes?
Do you use a work around,
do we add users or services?
No, they have to be there.
Yeah, the question is whether we use any workaround for use the groups,
basically we'll have to provision them in the,
abiding this draw.
And yeah, the whole issue is that you have only one,
like ETC password or ETC group,
so it's hard if two sources are writing in it at the same time.
Maybe we could, I'm not super familiar,
but I know that on modern systems,
that's actually not the real source of truth for users and groups,
and it's kind of, I think,
some kind of other database behind
that also system behaviors for this kind of dynamic users,
stuff and such.
So maybe there's a way there to kind of interact with that,
and not actually persist anything on the file system,
but I've not looked at it in detail,
but I think there might be ways to improve the situation,
but probably we just do nothing for them.
Okay.
Is Josh Lee here who's going to be giving you a talk after the next one?
Josh Lee?
Okay, I'm not seeing anyone.
Oh, I have a question.
You have a question?
All right, there's time for more questions.
And how do you, or how could you combine this with remote deployment?
How would I combine this with remote deployment?
Well, basically, you just have to copy closure over the store path, right?
So we don't have anything written up for that,
but I think it's only a couple of lines of bash if you want to do that.
You basically, so it would be the same way as other needs.
Yeah, because you have a particular closure in the closure,
you will have a deactivation script.
So basically, you can copy over the closure,
if you want the right script, and it will do everything.
So I think it's not really two commands.
All right, we have time for another question.
Have you actually tested using system manager on NICS?
Or have some, you know, how would you then try to see it?
So the question is if I tried using system manager on NICSOS?
Yes, I did, because actually I only used NICSOS,
so when I was developing this, I actually run on NICSOS.
So it's funny, and you have to be, yeah, there's a lot of, like, footprints.
But you can, yeah.
As long as you know, actually it's pretty much the same constraint as another destroyer.
You just don't want to ride the same thing as the already there,
and also we kind of cross deactivation if you try to do that.
So you can ride just new services into your ETC that also linked to the NICSOS,
and not much fun is going to happen.
You're going to get, like, next to your current system software.
You're going to get, like, a system manager software on the run,
and both will be added to the path, which is also fine.
So there's not that many surprises, yeah.
I'm actually works.
But I don't think it's pretty useful besides testing, basically.
I have a quick follow-up to that.
Can you basically reuse the same service definition for NICSOS and your system?
So can you reuse the same system services?
Yes, we have exactly the same NICS code,
like, to define the system resources.
Yeah.
Thank you very much.
Last question.
Okay.
You know that.
I think the chances of that extending to the NICS started right now.
Sorry.
Can we get?
I think that, again, to the experiment, the half services.
Oh, so what do we can extend this to NICS Darwin?
Oh, I think I've never run Darwin, so I'm not super familiar,
but I think NICS Darwin is already more or less this.
No.
Like, yeah, it's older than the last two,
great, like, background services and so on.
Yeah.
Thank you.
Yeah, I think the implementation of how you create a service
and such a sport is probably quite different, because then I think it
beyond the use of the launch, these stuff and such.
I think, like, I would.
You can really service definitions.
Yeah, except I probably don't have the same sort of option that they
supports.
My gut feeling is that NICS Darwin is basically this on Darwin,
but I'm very Darwin specific where this is really focused on Linux.
I'm not sure how much is in the intersection of, like, how much can we actually
utilize between the two?
I'm not familiar with NICS Darwin to be able to say.
Maybe there's a way to neutralize certain parts.
Yeah.
I think we have to conclude the Q&A at this point, please.
Another round of applause for NICS Darwin.