this post was submitted on 30 Aug 2023
69 points (100.0% liked)

Linux

48031 readers
1196 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
nooter692@lemmy.ml
AgreeableLandscape@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
69
Running NixOS from any Linux Distro in systemd-nspawn Containers (nixcademy.com)
submitted 1 year ago by pnutzh4x0r@lemmy.ndlug.org to c/linux@lemmy.ml
12 comments fedilink hide all child comments
 

When showing Nix or NixOS to newcomers, the first instinct is often to run the NixOS Docker image on Docker or Podman. This week we’re having a look at how to do the same with systemd’s systemd-nspawn facility via the machinectl command. This has huge benefits to both trying out NixOS and also professionally using it like a sidecar VM, as we shall see. If you’re using Ubuntu, Debian, Fedora, Rocky Linux, or similar, jump right in!

In this tutorial-like article, we learned, how to quickly run a nearly full instance of NixOS on any GNU/Linux distribution that uses systemd (e.g. Ubuntu, Debian, Fedora, Rocky Linux, etc…).

This NixOS instance can be configured to our needs and also be run like a sidecar to our normal host system. systemd can treat it like a system service that boots up by default with the host system, using machinectl enable nixos.

top 12 comments
sorted by: hot top controversial new old
[–] TCB13@lemmy.world 13 points 1 year ago (3 children)

Finally someone taking advantage of what systemd has to offer instead of bitching around.

Systemd is incredibly versatile and most people, including myself, are unaware of its full potential. Despite its usefulness, it is often overlooked due to controversy and the current state of things when it comes to software development. Begin today your journey thought Systemd’s capabilities and discover how to efficiently manage systems with fewer processes than traditionally required. More: https://tadeubento.com/2023/systemd-hidden-gems-for-a-better-linux/

[–] Syudagye@pawb.social 1 points 1 year ago

You can declare containers when building a nixos system, and it also uses systemd-nspawn

[–] nik282000@lemmy.ca 1 points 1 year ago

TIL, thanks!

[–] jecxjo@midwest.social -5 points 1 year ago (3 children)

That is pretty cool.

But its also another example of systemd doing stuff other services already did (see lxc).

[–] baru@lemmy.world 6 points 1 year ago (1 children)

But its also another example of systemd doing stuff other services already did

And?

[–] jecxjo@midwest.social 1 points 1 year ago

Their complaint was that people bitch about systemd. The issue people have is that systemd does too much.

[–] meteokr@community.adiquaints.moe 2 points 1 year ago (1 children)

systemd manages cgroups, a very well standardized kernel interface for process management, which I would say is something init should be able to do. The gap between that, and a container is mostly semantic.

[–] jecxjo@midwest.social 2 points 1 year ago (1 children)

Personally I'd like my container/vm/chroot handled by something detached from pid 1. I get that much of the overal systemd project is separate blocks of code but it's the fact they are bound together that it becomes an issue. I would have loved for the systemd team yo first publish a set of APIs that all their components would us and allow the same integration while being completely different projects.

[–] meteokr@community.adiquaints.moe 2 points 1 year ago (1 children)

Yeah the preference is yours, at the end of the day, I don't think it matters what tools you use as long as it works.

Worth noting is that a process not managed by pid 1 isn't really a thing you want generally. If you use systemd to start the docker daemon, which then starts your container, its still managed by pid 1 eventually. Perhaps you prefer the tooling and interface of docker more than machinectl, or maybe podman just isnt working for you, they're all just tools to interact with kernel namespaces and cgroups. For doing a little dabbling in another distro, installing docker is pretty heavy vs what the article is talking about.

[–] jecxjo@midwest.social 1 points 1 year ago

I don’t think it matters what tools you use as long as it works.

That would be true if other systems and services depend on them. Would have been nice to come out with a standard and designed systemd around that standard. Then you pick the tool you want that follows the standard rather than be tied into systemd.

Worth noting is that a process not managed by pid 1 isn’t really a thing you want generally

I would disagree. A compromised Docker doesn't mean i have access to things managed by PID1. The entire control model is based around moving your publicly available services further away from something with the highest level of access. Be it users or processes.

[–] TCB13@lemmy.world 1 points 1 year ago (1 children)

LXC is way more resource intensive and actually systemd had containers for a very long time... not to forget that if you use those you don't need to install one more thing :)

[–] jecxjo@midwest.social 1 points 1 year ago

And systemd is far more resources intensive than runit. Wasn't really the point.

Kind of nice to not have a bug in my container service possibly have access to pid 1.