Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add podman auto-start info and cleanup structure #200

Merged
merged 2 commits into from
Sep 18, 2024
Merged

docs: add podman auto-start info and cleanup structure #200

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fa86311
docs: add podman auto-start info and cleanup structure
alangrainger Sep 6, 2024
83c27e4
Update README.md
alangrainger Sep 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 56 additions & 17 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,11 +22,13 @@ Please take a look at the included modifications, and help us improve uCore if t
- [Manual Install/Rebase](#manual-installrebase)
- [Tips and Tricks](#tips-and-tricks)
- [CoreOS and ostree Docs](#coreos-and-ostree-docs)
- [Immutability and Podman](#immutability-and-podman)
- [Podman](#podman)
- [Immutability and Podman](#immutability-and-podman)
- [Docker/Moby and Podman](#dockermoby-and-podman)
- [Podman and FirewallD](#podman-and-firewalld)
- [Automatically start containers on boot](#automatically-start-containers-on-boot)
- [Default Services](#default-services)
- [SELinux Troubleshooting](#selinux-troubleshooting)
- [Docker/Moby and Podman](#dockermoby-and-podman)
- [Podman and FirewallD](#podman-and-firewalld)
- [Distrobox](#distrobox)
- [NAS - Storage](#nas---storage)
- [NFS](#nfs)
Expand Down Expand Up @@ -212,12 +214,62 @@ sudo rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/IMAGE:TAG

It's a good idea to become familar with the [Fedora CoreOS Documentation](https://docs.fedoraproject.org/en-US/fedora-coreos/) as well as the [CoreOS rpm-ostree docs](https://coreos.github.io/rpm-ostree/). Note especially, this image is only possible due to [ostree native containers](https://coreos.github.io/rpm-ostree/container/).

### Immutability and Podman
### Podman

#### Immutability and Podman

A CoreOS root filesystem system is immutable at runtime, and it is not recommended to install packages like in a mutable "normal" distribution.

Fedora CoreOS expects the user to run services using [podman](https://podman.io). `moby-engine`, the free Docker implementation, is also installed for those who desire docker instead of podman.

#### Docker/Moby and Podman

> [!IMPORTANT]
> CoreOS [cautions against](https://docs.fedoraproject.org/en-US/fedora-coreos/faq/#_can_i_run_containers_via_docker_and_podman_at_the_same_time) running podman and docker containers at the same time. Thus, `docker.socket` is disabled by default to prevent accidental activation of the docker daemon, given podman is the default.
>
> Ony run both simultaneously if you understand the risk.

#### Podman and FirewallD

Podman and firewalld [can sometimes conflict](https://github.com/ublue-os/ucore/issues/90) such that a `firewall-cmd --reload` removes firewall rules generated by podman.

As of [netavark v1.9.0](https://blog.podman.io/2023/11/new-netavark-firewalld-reload-service/) a service is provided to handle re-adding netavark (Podman) firewall rules after a firewalld reload occurs. If needed, enable like so: `systemctl enable netavark-firewalld-reload.service`

#### Automatically start containers on boot

By default, UCore does not automatically start `restart: always` containers on system boot, however this can be easily enabled:

##### For containers running under the `core` user

```bash
# Copy the system's podman-restart service to the user location
cp /lib/systemd/system/podman-restart.service /var/home/core/.config/systemd/user

# Enable the user service
systemctl --user enable podman-restart.service
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

either before or after describing this for user run podman, could you also add the global?

Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, what do you mean? What is "the global"?

The system (non-user) podman-restart service doesn't do anything useful whether it is enabled or disabled.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, by global, i mean system... podman-restart does the same thing for system as it does for users... but for starting restart: always rootful podman containers.

Or am I missing something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I must be missing something. Podman should never be rootful, no? It should always be running under the core user - isn't that the whole purpose of running rootless Podman instead of Docker?

Since all containers on UCore run rootless under the core user, there should be no need to describe Fedora's podman-restart system service?

Regardless, the system service already exists and needs nothing done to it. People can already immediately enable that should they need it, but I can't see why they would need it.

Copy link
Collaborator

@bsherman bsherman Sep 18, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Podman runs rootful just fine.

Making decisions about "what is right, rootless or rootful" is not something I want to get into. People can use a system how they want.
I know several users delete the core user and create other users via ignition and also many run rootful podman containers.

All I'm asking for is to add, "if you want to run your rootful podman containers to autostart, just run this command."

Copy link
Contributor Author

@alangrainger alangrainger Sep 18, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks I will do. I'm not being argumentative - I literally only started using Podman and Docker when I started using Aurora, and it's all brand new to me. I have zero clue what is the right way to do things.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks I will do. I'm not being argumentative

No worries! I think your suggestion is very helpful, as clearly it's not always easy to find something that seems like it should be obvious (especially when more momentum of documentation seems to be around docker and docker-compose).

I just think your suggestion applies equally well to both root/user podman operation. :-)

I literally only started using Podman and Docker when I started using Aurora, and it's all brand new to me. I have zero clue what is the right way to do things.

You have much more than zero clue! You are correct in your belief that many advocate for "only run podman as user", but that's not because podman itself is less secure than anything else, it's just to encourage more secure practices. So if you can and are willing to run all rootless, excellent!

And again, I thank you for your contribution.


# Check that it's running
systemctl --user list-unit-files | grep podman
```

When you next reboot the system, your `restart: always` containers will automatically start.

You may also need to enable “linger” mode on your user session, to prevent containers exiting which you have started interactively. To do that, run:

```bash
loginctl enable-linger $UID
```

You can find more information regarding this on the [Podman troubleshooting page](https://github.com/containers/podman/blob/main/troubleshooting.md#21-a-rootless-container-running-in-detached-mode-is-closed-at-logout).

##### For containers running under the root user (rootful containers)

You just need to enable the built-in service:

```bash
sudo systemctl enable podman-restart.service
```

### Default Services

To maintain this image's suitability as a minimal container host, most add-on services are not auto-enabled.
Expand Down Expand Up @@ -256,19 +308,6 @@ Enforcing

Fedora provides useful docs on [SELinux troubleshooting](https://docs.fedoraproject.org/en-US/quick-docs/selinux-troubleshooting/).

### Docker/Moby and Podman

> [!IMPORTANT]
> CoreOS [cautions against](https://docs.fedoraproject.org/en-US/fedora-coreos/faq/#_can_i_run_containers_via_docker_and_podman_at_the_same_time) running podman and docker containers at the same time. Thus, `docker.socket` is disabled by default to prevent accidental activation of the docker daemon, given podman is the default.
>
> Ony run both simultaneously if you understand the risk.

### Podman and FirewallD

Podman and firewalld [can sometimes conflict](https://github.com/ublue-os/ucore/issues/90) such that a `firewall-cmd --reload` removes firewall rules generated by podman.

As of [netavark v1.9.0](https://blog.podman.io/2023/11/new-netavark-firewalld-reload-service/) a service is provided to handle re-adding netavark (Podman) firewall rules after a firewalld reload occurs. If needed, enable like so: `systemctl enable netavark-firewalld-reload.service`

### Distrobox

Users may use [distrobox](https://github.com/89luca89/distrobox) to run images of mutable distributions where applications can be installed with traditional package managers. This may be useful for installing interactive utilities such has `htop`, `nmap`, etc. As stated above, however, *services* should run as containers.
Expand Down