Podman-compose + tt-rss

Tiny Tiny RSS Development
1

In Home.md - ttrss-docker-compose.wiki.git - Wiki repository for ttrss-docker-compose, the last service is missing a :ro in ./html:/var/www/html. Should be:

web-nginx:
    build: ./web-nginx
    volumes:
      - ./html:/var/www/html:ro
    env_file:
      - .env

Otherwise fails with Error: conflict at mount destination /var/www/html: duplicate mount destination

2

Also, running it locally, a consecutive docker-compose up results in trss-docker-compose_app_1, looped at:

chown: /var/www/html/tt-rss/.git/index: Operation not permitted

as well as on any other newly-added file in the folder, e.g.

chown: /var/www/html/tt-rss/.idea: Operation not permitted

Note I am running podman here in place of docker, it could affect things.

Disabling chown lines in startup script helps intermittently. I suppose the actual solution is to map UIDs/GIDs accordingly.

3

Also, the host IP detected is actually not routable to host here with podman. AFAIK only host.containers.internal or host.docker.internal should be used, to let Podman/Docker do its magic.

Setting TTRSS_XDEBUG_HOST to host.containers.internal on my end fixes the issue.

4

IIRC podman does not use root privileges to start containers. So the podman container won’t be able to chown files.

5

Podman can do both, but I am indeed not running it in a privileged mode — which is podman’s default, anyway. I imagine this comes as a result of a growing awareness over blatant security risks Docker’s default rootful approach imposes.

As noted above, the solution would be to map UIDs/GIDs accordingly, which should allow chmod/chown to work as expected.

EDIT: Just realized UID/GID is actually configurable in .env/Dockerfile.

6

see ttrss-docker-compose/.env-dist at fb2eee1edcd2ef57b5aeb290581de096905a14b5 - ttrss-docker-compose - Tiny Tiny RSS for setting UID/GID containers (try to) run as.

Having this in sync with podman and the volume access rights should do the trick.

7

Having this in sync with podman and the volume access rights should do the trick.

Yeah, I found out about it already. But it’s not enough for podman, see:

Running it with PODMAN_USERNS=keep-id podman-compose up -d actually helps a bit, but now looped in:

waiting until db is ready...
db:5432 - no response
waiting until db is ready...

PS. Currently cannot be set in compose, see Does podman-compose have a way to pass the "--userns keep-id" argument? · Issue #166 · containers/podman-compose · GitHub

8

when i was using podman i had to set UID/GID to 0 through .env which made it use my own UIDs otherwise it did strange things with userns.

i don’t support podman though so you’re on your own with anything that doesn’t work. i’m going to split your posts into a separate thread to minimize confusion.