#nspawn — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #nspawn, aggregated by home.social.
-
@ndreas once Podman/Docker add the corresponding support, this will work just fine, running containers inside nspawn:
https://github.com/systemd/systemd/blob/main/NEWS#L4573-L4599 -
@ndreas once Podman/Docker add the corresponding support, this will work just fine, running containers inside nspawn:
https://github.com/systemd/systemd/blob/main/NEWS#L4573-L4599 -
@ndreas once Podman/Docker add the corresponding support, this will work just fine, running containers inside nspawn:
https://github.com/systemd/systemd/blob/main/NEWS#L4573-L4599 -
@ndreas once Podman/Docker add the corresponding support, this will work just fine, running containers inside nspawn:
https://github.com/systemd/systemd/blob/main/NEWS#L4573-L4599 -
@ndreas once Podman/Docker add the corresponding support, this will work just fine, running containers inside nspawn:
https://github.com/systemd/systemd/blob/main/NEWS#L4573-L4599 -
CW: tech, linux, networking, firewall
For a few weeks I had some strange errors with my self-hosted webmail, Snappymail. After working for some time it complained that it couldn't connect to tcp://mydomain.tld:143. My email clients worked, though. The situation got worse a few days ago when I updated the server and rebooted it.
My webmail is hosted in a systemd-nspawn system container. I use such containers for a lot of different services.
For debugging purposes I tried some telnet and openssl s_client stuff today but I've been on the wrong track with that. ping'ing from the webmail container already failed. There was something more fundamental amiss.
-
CW: tech, linux, networking, firewall
For a few weeks I had some strange errors with my self-hosted webmail, Snappymail. After working for some time it complained that it couldn't connect to tcp://mydomain.tld:143. My email clients worked, though. The situation got worse a few days ago when I updated the server and rebooted it.
My webmail is hosted in a systemd-nspawn system container. I use such containers for a lot of different services.
For debugging purposes I tried some telnet and openssl s_client stuff today but I've been on the wrong track with that. ping'ing from the webmail container already failed. There was something more fundamental amiss.
-
CW: tech, linux, networking, firewall
For a few weeks I had some strange errors with my self-hosted webmail, Snappymail. After working for some time it complained that it couldn't connect to tcp://mydomain.tld:143. My email clients worked, though. The situation got worse a few days ago when I updated the server and rebooted it.
My webmail is hosted in a systemd-nspawn system container. I use such containers for a lot of different services.
For debugging purposes I tried some telnet and openssl s_client stuff today but I've been on the wrong track with that. ping'ing from the webmail container already failed. There was something more fundamental amiss.
-
CW: tech, linux, networking, firewall
For a few weeks I had some strange errors with my self-hosted webmail, Snappymail. After working for some time it complained that it couldn't connect to tcp://mydomain.tld:143. My email clients worked, though. The situation got worse a few days ago when I updated the server and rebooted it.
My webmail is hosted in a systemd-nspawn system container. I use such containers for a lot of different services.
For debugging purposes I tried some telnet and openssl s_client stuff today but I've been on the wrong track with that. ping'ing from the webmail container already failed. There was something more fundamental amiss.
-
CW: tech, linux, networking, firewall
For a few weeks I had some strange errors with my self-hosted webmail, Snappymail. After working for some time it complained that it couldn't connect to tcp://mydomain.tld:143. My email clients worked, though. The situation got worse a few days ago when I updated the server and rebooted it.
My webmail is hosted in a systemd-nspawn system container. I use such containers for a lot of different services.
For debugging purposes I tried some telnet and openssl s_client stuff today but I've been on the wrong track with that. ping'ing from the webmail container already failed. There was something more fundamental amiss.
-
CW: tech, admin, nextcloud
Ich hatte ja fast vergessen, dass ich noch eine Nextcloud laufen habe, die als Server für eine Galerie einer Veranstaltung dient. Das Update von 28.0.5 bis hoch auf 31.0.4 verlief komplett unproblematisch (via Kommandozeile). Im Zuge dessen mal alle nspawn-Systemcontainer und den Host aktualisiert und neugestartet. Abgesehen davon, dass einer der Container nicht enabled war und der Keycloak-Service in einem anderen Container ebenfalls nicht, lief es komplett sauber durch.
Vielleicht kann ich das doch so langsam 😆
-
CW: tech, admin, nextcloud
Ich hatte ja fast vergessen, dass ich noch eine Nextcloud laufen habe, die als Server für eine Galerie einer Veranstaltung dient. Das Update von 28.0.5 bis hoch auf 31.0.4 verlief komplett unproblematisch (via Kommandozeile). Im Zuge dessen mal alle nspawn-Systemcontainer und den Host aktualisiert und neugestartet. Abgesehen davon, dass einer der Container nicht enabled war und der Keycloak-Service in einem anderen Container ebenfalls nicht, lief es komplett sauber durch.
Vielleicht kann ich das doch so langsam 😆
-
CW: tech, admin, nextcloud
Ich hatte ja fast vergessen, dass ich noch eine Nextcloud laufen habe, die als Server für eine Galerie einer Veranstaltung dient. Das Update von 28.0.5 bis hoch auf 31.0.4 verlief komplett unproblematisch (via Kommandozeile). Im Zuge dessen mal alle nspawn-Systemcontainer und den Host aktualisiert und neugestartet. Abgesehen davon, dass einer der Container nicht enabled war und der Keycloak-Service in einem anderen Container ebenfalls nicht, lief es komplett sauber durch.
Vielleicht kann ich das doch so langsam 😆
-
CW: tech, admin, nextcloud
Ich hatte ja fast vergessen, dass ich noch eine Nextcloud laufen habe, die als Server für eine Galerie einer Veranstaltung dient. Das Update von 28.0.5 bis hoch auf 31.0.4 verlief komplett unproblematisch (via Kommandozeile). Im Zuge dessen mal alle nspawn-Systemcontainer und den Host aktualisiert und neugestartet. Abgesehen davon, dass einer der Container nicht enabled war und der Keycloak-Service in einem anderen Container ebenfalls nicht, lief es komplett sauber durch.
Vielleicht kann ich das doch so langsam 😆
-
CW: tech, admin, nextcloud
Ich hatte ja fast vergessen, dass ich noch eine Nextcloud laufen habe, die als Server für eine Galerie einer Veranstaltung dient. Das Update von 28.0.5 bis hoch auf 31.0.4 verlief komplett unproblematisch (via Kommandozeile). Im Zuge dessen mal alle nspawn-Systemcontainer und den Host aktualisiert und neugestartet. Abgesehen davon, dass einer der Container nicht enabled war und der Keycloak-Service in einem anderen Container ebenfalls nicht, lief es komplett sauber durch.
Vielleicht kann ich das doch so langsam 😆
-
CW: tech, linux, forgejo, nspawn, podman
Because of my stupid curiosity I always try to achieve what other people do with a different toolset. People use LXC? I use systemd-nspawn. Docker? Nah, podman!
And today I setup Forgejo running in a systemd-nspawn container. I setup a second nspawn-container for the Forgejo runner.
It went as is to be expected. "Error: cannot ping the docker daemon. […]"
Of course I can't find anything regarding my special situation. 🤷
I got it working by overridng the podman.socket with SocketMode=0666 (default is 0660). Doesn't seem to be safe, though. After adding a group podman and adding the runner to this group the forgejo-runner.service also works with SocketGroup=podman.
-
CW: tech, linux, forgejo, nspawn, podman
Because of my stupid curiosity I always try to achieve what other people do with a different toolset. People use LXC? I use systemd-nspawn. Docker? Nah, podman!
And today I setup Forgejo running in a systemd-nspawn container. I setup a second nspawn-container for the Forgejo runner.
It went as is to be expected. "Error: cannot ping the docker daemon. […]"
Of course I can't find anything regarding my special situation. 🤷
I got it working by overridng the podman.socket with SocketMode=0666 (default is 0660). Doesn't seem to be safe, though. After adding a group podman and adding the runner to this group the forgejo-runner.service also works with SocketGroup=podman.
-
CW: tech, linux, forgejo, nspawn, podman
Because of my stupid curiosity I always try to achieve what other people do with a different toolset. People use LXC? I use systemd-nspawn. Docker? Nah, podman!
And today I setup Forgejo running in a systemd-nspawn container. I setup a second nspawn-container for the Forgejo runner.
It went as is to be expected. "Error: cannot ping the docker daemon. […]"
Of course I can't find anything regarding my special situation. 🤷
I got it working by overridng the podman.socket with SocketMode=0666 (default is 0660). Doesn't seem to be safe, though. After adding a group podman and adding the runner to this group the forgejo-runner.service also works with SocketGroup=podman.
-
CW: tech, linux, forgejo, nspawn, podman
Because of my stupid curiosity I always try to achieve what other people do with a different toolset. People use LXC? I use systemd-nspawn. Docker? Nah, podman!
And today I setup Forgejo running in a systemd-nspawn container. I setup a second nspawn-container for the Forgejo runner.
It went as is to be expected. "Error: cannot ping the docker daemon. […]"
Of course I can't find anything regarding my special situation. 🤷
I got it working by overridng the podman.socket with SocketMode=0666 (default is 0660). Doesn't seem to be safe, though. After adding a group podman and adding the runner to this group the forgejo-runner.service also works with SocketGroup=podman.
-
CW: tech, linux, forgejo, nspawn, podman
Because of my stupid curiosity I always try to achieve what other people do with a different toolset. People use LXC? I use systemd-nspawn. Docker? Nah, podman!
And today I setup Forgejo running in a systemd-nspawn container. I setup a second nspawn-container for the Forgejo runner.
It went as is to be expected. "Error: cannot ping the docker daemon. […]"
Of course I can't find anything regarding my special situation. 🤷
I got it working by overridng the podman.socket with SocketMode=0666 (default is 0660). Doesn't seem to be safe, though. After adding a group podman and adding the runner to this group the forgejo-runner.service also works with SocketGroup=podman.
-
Trying to get a bit familiar with systemd-nspawn (little bit clumsy name) by following this article:
https://benjamintoll.com/2022/02/04/on-running-systemd-nspawn-containers/
Its a bit outdated, eg. `machinectl pull-raw ...` is `importctl pull-raw`, but it can be translated.
Trying to create an image using `mkosi` that then later can be started.
Overall aim is to start a firefox in a spawned container. Let's see...
-
Trying to get a bit familiar with systemd-nspawn (little bit clumsy name) by following this article:
https://benjamintoll.com/2022/02/04/on-running-systemd-nspawn-containers/
Its a bit outdated, eg. `machinectl pull-raw ...` is `importctl pull-raw`, but it can be translated.
Trying to create an image using `mkosi` that then later can be started.
Overall aim is to start a firefox in a spawned container. Let's see...
-
Trying to get a bit familiar with systemd-nspawn (little bit clumsy name) by following this article:
https://benjamintoll.com/2022/02/04/on-running-systemd-nspawn-containers/
Its a bit outdated, eg. `machinectl pull-raw ...` is `importctl pull-raw`, but it can be translated.
Trying to create an image using `mkosi` that then later can be started.
Overall aim is to start a firefox in a spawned container. Let's see...
-
The thing I hate about #Discourse is the need to use docker. Docker is a PITA to run in systemd-nspawn, and I guess #lxc, too. I would put much more energy into hosting my Discourse if I just could install it in my system containers without too much hassle.
Other than that, Discourse is great.
-
The thing I hate about #Discourse is the need to use docker. Docker is a PITA to run in systemd-nspawn, and I guess #lxc, too. I would put much more energy into hosting my Discourse if I just could install it in my system containers without too much hassle.
Other than that, Discourse is great.
-
The thing I hate about #Discourse is the need to use docker. Docker is a PITA to run in systemd-nspawn, and I guess #lxc, too. I would put much more energy into hosting my Discourse if I just could install it in my system containers without too much hassle.
Other than that, Discourse is great.
-
The thing I hate about #Discourse is the need to use docker. Docker is a PITA to run in systemd-nspawn, and I guess #lxc, too. I would put much more energy into hosting my Discourse if I just could install it in my system containers without too much hassle.
Other than that, Discourse is great.
-
The thing I hate about #Discourse is the need to use docker. Docker is a PITA to run in systemd-nspawn, and I guess #lxc, too. I would put much more energy into hosting my Discourse if I just could install it in my system containers without too much hassle.
Other than that, Discourse is great.
-
Ok #systemd #nixos #nspawn container question.
On the host I've mounted a nfs share rw.
In a nixos container i've a bind mount of that nfs mount into another directory.
If I open a shell inside that container as root I see that nfs/bindmount rw. But all other users (if I look at their /proc/<pid>/mounts see that nfs share mounted as ro read-only ...
-
Ok #systemd #nixos #nspawn container question.
On the host I've mounted a nfs share rw.
In a nixos container i've a bind mount of that nfs mount into another directory.
If I open a shell inside that container as root I see that nfs/bindmount rw. But all other users (if I look at their /proc/<pid>/mounts see that nfs share mounted as ro read-only ...
-
Ok #systemd #nixos #nspawn container question.
On the host I've mounted a nfs share rw.
In a nixos container i've a bind mount of that nfs mount into another directory.
If I open a shell inside that container as root I see that nfs/bindmount rw. But all other users (if I look at their /proc/<pid>/mounts see that nfs share mounted as ro read-only ...
-
Ok #systemd #nixos #nspawn container question.
On the host I've mounted a nfs share rw.
In a nixos container i've a bind mount of that nfs mount into another directory.
If I open a shell inside that container as root I see that nfs/bindmount rw. But all other users (if I look at their /proc/<pid>/mounts see that nfs share mounted as ro read-only ...
-
Ok #systemd #nixos #nspawn container question.
On the host I've mounted a nfs share rw.
In a nixos container i've a bind mount of that nfs mount into another directory.
If I open a shell inside that container as root I see that nfs/bindmount rw. But all other users (if I look at their /proc/<pid>/mounts see that nfs share mounted as ro read-only ...
-
CW: tech, systemd-nspawn, network, ipv6
Ich habe auf meinem Server 2 #systemd-#nspawn-Container. Beiden habe ich ein IPVLAN-Interface konfiguriert und ihnen jeweils 1 IPv4-Adresse zugewiesen. Die sind erreichbar. Ich habe beiden auch jeweils 1 #IPv6-Adresse zugewiesen. Aber erreichbar ist nur 1 von 2 nspawn. Trotz identischer Konfiguration, so weit ich das überblicken kann. Der 2. Container ist heute dazugekommen, der 1. läuft seit Mai mit der Config. Es ist kein DNS-Problem, `ping` auf die IPv6-Adresse selbst sind 100% Paketverlust.
`tcpdump -n -i enp0s31f6 icmp6` auf der Host-Schnittstelle zeigt ICMP-Pakete für die 1. IPv6, aber nicht für die 2. IPv6. Beide sind Teil meines /64, die eine endet auf ::80, die andere auf ::81.
`ping` vom 2. nspawn ins Netz geht auch […]
-
CW: tech, systemd-nspawn, network, ipv6
Ich habe auf meinem Server 2 #systemd-#nspawn-Container. Beiden habe ich ein IPVLAN-Interface konfiguriert und ihnen jeweils 1 IPv4-Adresse zugewiesen. Die sind erreichbar. Ich habe beiden auch jeweils 1 #IPv6-Adresse zugewiesen. Aber erreichbar ist nur 1 von 2 nspawn. Trotz identischer Konfiguration, so weit ich das überblicken kann. Der 2. Container ist heute dazugekommen, der 1. läuft seit Mai mit der Config. Es ist kein DNS-Problem, `ping` auf die IPv6-Adresse selbst sind 100% Paketverlust.
`tcpdump -n -i enp0s31f6 icmp6` auf der Host-Schnittstelle zeigt ICMP-Pakete für die 1. IPv6, aber nicht für die 2. IPv6. Beide sind Teil meines /64, die eine endet auf ::80, die andere auf ::81.
`ping` vom 2. nspawn ins Netz geht auch […]
-
CW: tech, systemd-nspawn, network, ipv6
Ich habe auf meinem Server 2 #systemd-#nspawn-Container. Beiden habe ich ein IPVLAN-Interface konfiguriert und ihnen jeweils 1 IPv4-Adresse zugewiesen. Die sind erreichbar. Ich habe beiden auch jeweils 1 #IPv6-Adresse zugewiesen. Aber erreichbar ist nur 1 von 2 nspawn. Trotz identischer Konfiguration, so weit ich das überblicken kann. Der 2. Container ist heute dazugekommen, der 1. läuft seit Mai mit der Config. Es ist kein DNS-Problem, `ping` auf die IPv6-Adresse selbst sind 100% Paketverlust.
`tcpdump -n -i enp0s31f6 icmp6` auf der Host-Schnittstelle zeigt ICMP-Pakete für die 1. IPv6, aber nicht für die 2. IPv6. Beide sind Teil meines /64, die eine endet auf ::80, die andere auf ::81.
`ping` vom 2. nspawn ins Netz geht auch […]
-
CW: tech, systemd-nspawn, network, ipv6
Ich habe auf meinem Server 2 #systemd-#nspawn-Container. Beiden habe ich ein IPVLAN-Interface konfiguriert und ihnen jeweils 1 IPv4-Adresse zugewiesen. Die sind erreichbar. Ich habe beiden auch jeweils 1 #IPv6-Adresse zugewiesen. Aber erreichbar ist nur 1 von 2 nspawn. Trotz identischer Konfiguration, so weit ich das überblicken kann. Der 2. Container ist heute dazugekommen, der 1. läuft seit Mai mit der Config. Es ist kein DNS-Problem, `ping` auf die IPv6-Adresse selbst sind 100% Paketverlust.
`tcpdump -n -i enp0s31f6 icmp6` auf der Host-Schnittstelle zeigt ICMP-Pakete für die 1. IPv6, aber nicht für die 2. IPv6. Beide sind Teil meines /64, die eine endet auf ::80, die andere auf ::81.
`ping` vom 2. nspawn ins Netz geht auch […]
-
CW: tech, systemd-nspawn, network, ipv6
Ich habe auf meinem Server 2 #systemd-#nspawn-Container. Beiden habe ich ein IPVLAN-Interface konfiguriert und ihnen jeweils 1 IPv4-Adresse zugewiesen. Die sind erreichbar. Ich habe beiden auch jeweils 1 #IPv6-Adresse zugewiesen. Aber erreichbar ist nur 1 von 2 nspawn. Trotz identischer Konfiguration, so weit ich das überblicken kann. Der 2. Container ist heute dazugekommen, der 1. läuft seit Mai mit der Config. Es ist kein DNS-Problem, `ping` auf die IPv6-Adresse selbst sind 100% Paketverlust.
`tcpdump -n -i enp0s31f6 icmp6` auf der Host-Schnittstelle zeigt ICMP-Pakete für die 1. IPv6, aber nicht für die 2. IPv6. Beide sind Teil meines /64, die eine endet auf ::80, die andere auf ::81.
`ping` vom 2. nspawn ins Netz geht auch […]
-
Alright , play time aka show off useless craps ... enjoy!
#linuxadmin #opensuse #fedora #systemd #nspawn #tool #opensource
-
Alright , play time aka show off useless craps ... enjoy!
#linuxadmin #opensuse #fedora #systemd #nspawn #tool #opensource
-
Alright , play time aka show off useless craps ... enjoy!
#linuxadmin #opensuse #fedora #systemd #nspawn #tool #opensource
-
Alright , play time aka show off useless craps ... enjoy!
#linuxadmin #opensuse #fedora #systemd #nspawn #tool #opensource
-
Alright , play time aka show off useless craps ... enjoy!
#linuxadmin #opensuse #fedora #systemd #nspawn #tool #opensource
-
With Open Source IDE: #Lapce - https://lapce.dev/
and the ubiquity of #SystemD #nspawn #containers , It is possible to have a bloat-free workstation on #Linux
Just use the nspawn container to store all the dev-related packages and use the remote/SSH connection feature of Lapce to connect to those containers.
Your workstation will stay 'clean' relative to a situation if you had Java, Ruby, NodeJS, Python, Go and Rust all installed directly on the workstation.
-
With Open Source IDE: #Lapce - https://lapce.dev/
and the ubiquity of #SystemD #nspawn #containers , It is possible to have a bloat-free workstation on #Linux
Just use the nspawn container to store all the dev-related packages and use the remote/SSH connection feature of Lapce to connect to those containers.
Your workstation will stay 'clean' relative to a situation if you had Java, Ruby, NodeJS, Python, Go and Rust all installed directly on the workstation.
-
With Open Source IDE: #Lapce - https://lapce.dev/
and the ubiquity of #SystemD #nspawn #containers , It is possible to have a bloat-free workstation on #Linux
Just use the nspawn container to store all the dev-related packages and use the remote/SSH connection feature of Lapce to connect to those containers.
Your workstation will stay 'clean' relative to a situation if you had Java, Ruby, NodeJS, Python, Go and Rust all installed directly on the workstation.
-
With Open Source IDE: #Lapce - https://lapce.dev/
and the ubiquity of #SystemD #nspawn #containers , It is possible to have a bloat-free workstation on #Linux
Just use the nspawn container to store all the dev-related packages and use the remote/SSH connection feature of Lapce to connect to those containers.
Your workstation will stay 'clean' relative to a situation if you had Java, Ruby, NodeJS, Python, Go and Rust all installed directly on the workstation.
-
With Open Source IDE: #Lapce - https://lapce.dev/
and the ubiquity of #SystemD #nspawn #containers , It is possible to have a bloat-free workstation on #Linux
Just use the nspawn container to store all the dev-related packages and use the remote/SSH connection feature of Lapce to connect to those containers.
Your workstation will stay 'clean' relative to a situation if you had Java, Ruby, NodeJS, Python, Go and Rust all installed directly on the workstation.
-
Creating Sandboxes with systemd-nspawn and debootstrap
Exploring new #Linux features is exciting, but it can be risky! I sometimes break my system while testing packages. To avoid this, I recently tried #systemd-nspawn with #debootstrap - it's a lightweight #container that works well for isolated testing.
#Debian users, this guide shows you how to get systemd-#nspawn up and running, no fuss.
Installing the packages
First things first, we need to install two packages:
systemd-containeranddebootstrap:sudo apt install systemd-container debootstrapdebootstrap lets you spin up a lightweight Debian right on your host, and systemd-container utilites such as systemd-nspawn and machinectl manage the OS in a lightweight container.
Create a Debian virtual machine
Let's generate a minimal Debian image called debian-testing with the following command:
sudo debootstrap --include=systemd,dbus stable /var/lib/machines/debian-testingTo verify successful installation, run
machinectl list-images. Look for 'debian-testing' in the output.Logging into virtual machine
Use the following command to start the debian-testing container.
sudo systemd-nspawn -D /var/lib/machines/debian-testingSince you're now inside your virtual machine, let's set a password for the root user. This will come in handy when you want to manage the container using machinectl.
To swiftly terminate the container, press the
Ctrl+]key combination three times in quick succession while inside the container.Running a graphical application in vm
To run graphical apps like Chromium within the container, we need to set up display sharing. First, gracefully shut down the container. Then, use this command to establish the connection:
xhost local:; sudo systemd-nspawn -E DISPLAY="$DISPLAY" -D /var/lib/machines/debian-testingNow that you're logged in, it's time to fire up Chromium! Just type the following commands to install and open it:
apt update apt install chromium chromium --no-sandboxReferences
- Tutorial: Systemd: The Adventure Continues - Lee Elston, The Linux Foundation: https://www.youtube.com/watch?v=-Tijw1SIXts. Slides: https://ossna2020.sched.com/event/c47t/tutorial-systemd-the-adventure-continues-lee-elston-the-linux-foundation
- https://wiki.debian.org/nspawn
- https://man7.org/linux/man-pages/man1/systemd-nspawn.1.html
- https://wiki.archlinux.org/title/Systemd-nspawn#Avoiding_xhost
- https://wiki.archlinux.org/title/systemd-nspawn
- https://man7.org/linux/man-pages/man1/machinectl.1.html
