4 ms·

systemd user units can be run by non-root users. https://wiki.archlinux.org/title/Systemd/User https://wiki.archlinux.org/title/Systemd/User

pydry 2y ago
not the point as i mentioned above. systemd itself requires root.
- voxadam 2y ago
  Installing packages (like podman or moby/docker) using dnf and apt requires root as well, so I'm not sure what your point is.
  - pydry 2y ago
    making systemd - a root service - a necessary dependency in order to orchestrate > 1 nonroot containers is both unnecessary and bad architecture. It was a shitty decision that renders it just "a less popular docker" and not "a better docker".
    - linuxandrew 2y ago
      Podman doesn't have a dependency on systemd. e.g. it is packaged in Void Linux. Podman has a better architecture than Docker in that it can easily run on a non-privileged user. Quadlet (aka podman-systemd.unit) is a podman-systemd integration which can make it easy to launch and orchestrate podman containers via systemd. You can get all if the systemd dependency handling, require other units to run after a container finishes, and all sorts of other useful things. Systemd "user" units (systemctl --user) also works here with the containers running as a non-privileged user in a non-root systemd context. Just to be clear, Quadlet is just an integration and you can still run podman without it. You can still run podman on non-systemd systems as well.
      - dharmab 2y ago
        And you can use podman to run multiple containers together (as a Pod). With or without systemd.
      - pydry 2y ago
        >Podman doesn't have a dependency on systemd Just to be clear we're talking about QUADLETS, red hat's recommended way to orchestrate containers. >Just to be clear, Quadlet is just an integration and you can still run podman without it. Just to be clear, nobody was unclear about that. It is, just to be clear, red hat's recommended way to orchestrate podman containers despite having this nasty dependency analogous to the one docker has on a root service. Hope that helps.
        coldtea 2y ago
        >Just to be clear, nobody was unclear about that Oh, you were quite unclear. Also wrong in saying you need systemd with podman to orchestrate multiple containers without root. >It is, just to be clear, red hat's recommended way to orchestrate podman containers despite having this nasty dependency analogous to the one docker has on a root service. It's not "red hat's recommended way to orchestrate podman containers" in general. It's "red hat's recommended way to orchestrate containers on top of systemd", that its whole point. Nothing nasty about it either, you'd already be running systemd on your redhat system (and many non red-hat ones).
        pydry 2y ago
        >Also wrong in saying you need systemd with podman to orchestrate multiple containers without root I explicitly said thay it wasnt needed and that there werent other ways just that it was the recommended way. >It's not "red hat's recommended way to orchestrate podman containers It is.
    - exceptione 2y ago
      wut? Containers need an operating system. systemd runs on a linux host, the rootless container runs on a linux host, controlled by `systemctl --user ...`.
      - esseph 2y ago
        But you don't understand, it also needs an operating system therefore it is vulnerable, because things on it run as root! /s
- steeleduncan 2y ago
  systemd is the init process, the Linux kernel non-optionally runs the init process as root
  - pydry 2y ago
    yeah thats what i said. and that particular init process did way more than any init process ever should even before somebody had the bright idea to add "docker compose substitite" to its ever growing list of responsibilities. you could put a word processor and games in their too if you really wanted. is that a good idea? ill leave that for the reader's judgment.
    - ratorx 2y ago
      systemd just provides the feature to use a custom external application to configure a service based on a declarative spec, which podman uses to create actual systemd services from a declarative container spec. From the podman docs: > Podman supports building and starting containers (and creating volumes) via systemd by using a systemd generator. Putting aside all the other issues one may have with systemd, this feels like a decent feature for a service manager to have (custom generation of service specifications). > bright idea to add “Docker compose substitute” Why is this so revolutionary? Docker-compose is just a service manager for containers. Systemd is a service manager. Systemd allowing podman to give it “container” features seems pretty reasonable.
    - xienze 2y ago
      > before somebody had the bright idea to add "docker compose substitite" to its ever growing list of responsibilities. systemd itself isn’t acting as a docker-compose substitute. Podman simply translates unit files containing docker-esque configuration (image name, volumes, etc.) into plain systemd unit files that contain (among other things) an ExecStart line that starts the container with the proper arguments.
- dharmab 2y ago
  How were you planning to run podman compose without an init process running as root?
  - pydry 2y ago
    what else would you like to bundle in the init process? docker compose as well? maybe kubernetes too. a webserver? a word processor perhaps? maybe an email client?
    - robertlagrant 2y ago
      Podman compose isn't bundled in the init process.
      - pydry 2y ago
        Yep, but have you used it? It's crap. It implements about half of what docker compose does. I'd stop complaining about quadlets being a hunk of crap if podman compose were decently maintained.
        robertlagrant 2y ago
        I'm contesting your claim that podman compose is bundled with systemd.
        pydry 2y ago
        I never made this claim.
        robertlagrant 2y ago
        So what was this about? What's the thing that the "else" refers to? > what else would you like to bundle in the init process? docker compose as well? maybe kubernetes too. a webserver? a word processor perhaps? maybe an email client?

pydry 2y ago

not the point as i mentioned above. systemd itself requires root.

voxadam 2y ago
Installing packages (like podman or moby/docker) using dnf and apt requires root as well, so I'm not sure what your point is.
- pydry 2y ago
  making systemd - a root service - a necessary dependency in order to orchestrate > 1 nonroot containers is both unnecessary and bad architecture. It was a shitty decision that renders it just "a less popular docker" and not "a better docker".
  - linuxandrew 2y ago
    Podman doesn't have a dependency on systemd. e.g. it is packaged in Void Linux. Podman has a better architecture than Docker in that it can easily run on a non-privileged user. Quadlet (aka podman-systemd.unit) is a podman-systemd integration which can make it easy to launch and orchestrate podman containers via systemd. You can get all if the systemd dependency handling, require other units to run after a container finishes, and all sorts of other useful things. Systemd "user" units (systemctl --user) also works here with the containers running as a non-privileged user in a non-root systemd context. Just to be clear, Quadlet is just an integration and you can still run podman without it. You can still run podman on non-systemd systems as well.
    - dharmab 2y ago
      And you can use podman to run multiple containers together (as a Pod). With or without systemd.
    - pydry 2y ago
      >Podman doesn't have a dependency on systemd Just to be clear we're talking about QUADLETS, red hat's recommended way to orchestrate containers. >Just to be clear, Quadlet is just an integration and you can still run podman without it. Just to be clear, nobody was unclear about that. It is, just to be clear, red hat's recommended way to orchestrate podman containers despite having this nasty dependency analogous to the one docker has on a root service. Hope that helps.
      - coldtea 2y ago
        >Just to be clear, nobody was unclear about that Oh, you were quite unclear. Also wrong in saying you need systemd with podman to orchestrate multiple containers without root. >It is, just to be clear, red hat's recommended way to orchestrate podman containers despite having this nasty dependency analogous to the one docker has on a root service. It's not "red hat's recommended way to orchestrate podman containers" in general. It's "red hat's recommended way to orchestrate containers on top of systemd", that its whole point. Nothing nasty about it either, you'd already be running systemd on your redhat system (and many non red-hat ones).
        pydry 2y ago
        >Also wrong in saying you need systemd with podman to orchestrate multiple containers without root I explicitly said thay it wasnt needed and that there werent other ways just that it was the recommended way. >It's not "red hat's recommended way to orchestrate podman containers It is.
  - exceptione 2y ago
    wut? Containers need an operating system. systemd runs on a linux host, the rootless container runs on a linux host, controlled by `systemctl --user ...`.
    - esseph 2y ago
      But you don't understand, it also needs an operating system therefore it is vulnerable, because things on it run as root! /s
steeleduncan 2y ago
systemd is the init process, the Linux kernel non-optionally runs the init process as root
- pydry 2y ago
  yeah thats what i said. and that particular init process did way more than any init process ever should even before somebody had the bright idea to add "docker compose substitite" to its ever growing list of responsibilities. you could put a word processor and games in their too if you really wanted. is that a good idea? ill leave that for the reader's judgment.
  - ratorx 2y ago
    systemd just provides the feature to use a custom external application to configure a service based on a declarative spec, which podman uses to create actual systemd services from a declarative container spec. From the podman docs: > Podman supports building and starting containers (and creating volumes) via systemd by using a systemd generator. Putting aside all the other issues one may have with systemd, this feels like a decent feature for a service manager to have (custom generation of service specifications). > bright idea to add “Docker compose substitute” Why is this so revolutionary? Docker-compose is just a service manager for containers. Systemd is a service manager. Systemd allowing podman to give it “container” features seems pretty reasonable.
  - xienze 2y ago
    > before somebody had the bright idea to add "docker compose substitite" to its ever growing list of responsibilities. systemd itself isn’t acting as a docker-compose substitute. Podman simply translates unit files containing docker-esque configuration (image name, volumes, etc.) into plain systemd unit files that contain (among other things) an ExecStart line that starts the container with the proper arguments.
dharmab 2y ago
How were you planning to run podman compose without an init process running as root?
- pydry 2y ago
  what else would you like to bundle in the init process? docker compose as well? maybe kubernetes too. a webserver? a word processor perhaps? maybe an email client?
  - robertlagrant 2y ago
    Podman compose isn't bundled in the init process.
    - pydry 2y ago
      Yep, but have you used it? It's crap. It implements about half of what docker compose does. I'd stop complaining about quadlets being a hunk of crap if podman compose were decently maintained.
      - robertlagrant 2y ago
        I'm contesting your claim that podman compose is bundled with systemd.
        pydry 2y ago
        I never made this claim.
        robertlagrant 2y ago
        So what was this about? What's the thing that the "else" refers to? > what else would you like to bundle in the init process? docker compose as well? maybe kubernetes too. a webserver? a word processor perhaps? maybe an email client?