Fossil SCM
Added my sad tale of failure and woe with systemd-nspawn to the container docs, both as a warning to those who follow, and as a cry for help to someone who can make this work. I can't be bothered to spend more time on it, but there's no point throwing the work away.
Commit
1e8c6655280010f704db2b849db975b0017c593b8bc7cd3179597aa5933156ba
Parent
bf5030883ae32fd…
1 file changed
+41
+41
| --- www/containers.md | ||
| +++ www/containers.md | ||
| @@ -761,7 +761,48 @@ | ||
| 761 | 761 | This suggests one method around the problem of rootless Podman containers: |
| 762 | 762 | `sudo crun`, following the examples above. |
| 763 | 763 | |
| 764 | 764 | [crun]: https://github.com/containers/crun |
| 765 | 765 | |
| 766 | + | |
| 767 | +### <a id="nspawn"></a>`systemd-nspawn` | |
| 768 | + | |
| 769 | +As of `systemd` version 242, its optional `nspawn` piece | |
| 770 | +[reportedly](https://www.phoronix.com/news/Systemd-Nspawn-OCI-Runtime) | |
| 771 | +now has the ability to run OCI container bundles directly. You might | |
| 772 | +have it installed already, but if not, it’s only about 2 MiB. It’s | |
| 773 | +in the `systemd-containers` package as of Ubuntu 22.04 LTS: | |
| 774 | + | |
| 775 | +``` | |
| 776 | + $ sudo apt install systemd-containers | |
| 777 | +``` | |
| 778 | + | |
| 779 | +It’s also in CentOS Stream 9, under the same name. | |
| 780 | + | |
| 781 | +You create the bundles the same way as with [the `runc` method | |
| 782 | +above](#runc). The only thing that changes are the top-level management | |
| 783 | +commands: | |
| 784 | + | |
| 785 | +``` | |
| 786 | + $ sudo systemd-nspawn \ | |
| 787 | + --oci-bundle=/var/lib/machines/fossil \ | |
| 788 | + --machine=fossil \ | |
| 789 | + --network-veth \ | |
| 790 | + --port 48331:8080 | |
| 791 | + $ sudo machinectl list | |
| 792 | + No machines. | |
| 793 | +``` | |
| 794 | + | |
| 795 | +This is why I wrote “reportedly” above: it doesn’t work on two different | |
| 796 | +Linux distributions, and I can’t see why. I’m putting this here to give | |
| 797 | +someone else a leg up, with the hope that they will work out what’s | |
| 798 | +needed to get the container running and registered with `machinectl`. | |
| 799 | + | |
| 800 | +As of this writing, the tool expects an OCI container version of | |
| 801 | +“1.0.0”. I had to edit this at the top of my `config.json` file to get | |
| 802 | +the first command to read the bundle. The fact that it errored out when | |
| 803 | +I had “`1.0.2-dev`” in there proves it’s reading the file, but it | |
| 804 | +doesn’t seem able to make sense of what it finds there, and it doesn’t | |
| 805 | +give any diagnostics to say why. | |
| 806 | + | |
| 766 | 807 | |
| 767 | 808 | <div style="height:50em" id="this-space-intentionally-left-blank"></div> |
| 768 | 809 |
| --- www/containers.md | |
| +++ www/containers.md | |
| @@ -761,7 +761,48 @@ | |
| 761 | This suggests one method around the problem of rootless Podman containers: |
| 762 | `sudo crun`, following the examples above. |
| 763 | |
| 764 | [crun]: https://github.com/containers/crun |
| 765 | |
| 766 | |
| 767 | <div style="height:50em" id="this-space-intentionally-left-blank"></div> |
| 768 |
| --- www/containers.md | |
| +++ www/containers.md | |
| @@ -761,7 +761,48 @@ | |
| 761 | This suggests one method around the problem of rootless Podman containers: |
| 762 | `sudo crun`, following the examples above. |
| 763 | |
| 764 | [crun]: https://github.com/containers/crun |
| 765 | |
| 766 | |
| 767 | ### <a id="nspawn"></a>`systemd-nspawn` |
| 768 | |
| 769 | As of `systemd` version 242, its optional `nspawn` piece |
| 770 | [reportedly](https://www.phoronix.com/news/Systemd-Nspawn-OCI-Runtime) |
| 771 | now has the ability to run OCI container bundles directly. You might |
| 772 | have it installed already, but if not, it’s only about 2 MiB. It’s |
| 773 | in the `systemd-containers` package as of Ubuntu 22.04 LTS: |
| 774 | |
| 775 | ``` |
| 776 | $ sudo apt install systemd-containers |
| 777 | ``` |
| 778 | |
| 779 | It’s also in CentOS Stream 9, under the same name. |
| 780 | |
| 781 | You create the bundles the same way as with [the `runc` method |
| 782 | above](#runc). The only thing that changes are the top-level management |
| 783 | commands: |
| 784 | |
| 785 | ``` |
| 786 | $ sudo systemd-nspawn \ |
| 787 | --oci-bundle=/var/lib/machines/fossil \ |
| 788 | --machine=fossil \ |
| 789 | --network-veth \ |
| 790 | --port 48331:8080 |
| 791 | $ sudo machinectl list |
| 792 | No machines. |
| 793 | ``` |
| 794 | |
| 795 | This is why I wrote “reportedly” above: it doesn’t work on two different |
| 796 | Linux distributions, and I can’t see why. I’m putting this here to give |
| 797 | someone else a leg up, with the hope that they will work out what’s |
| 798 | needed to get the container running and registered with `machinectl`. |
| 799 | |
| 800 | As of this writing, the tool expects an OCI container version of |
| 801 | “1.0.0”. I had to edit this at the top of my `config.json` file to get |
| 802 | the first command to read the bundle. The fact that it errored out when |
| 803 | I had “`1.0.2-dev`” in there proves it’s reading the file, but it |
| 804 | doesn’t seem able to make sense of what it finds there, and it doesn’t |
| 805 | give any diagnostics to say why. |
| 806 | |
| 807 | |
| 808 | <div style="height:50em" id="this-space-intentionally-left-blank"></div> |
| 809 |