Hybrid mode using one user per process is not working

[bricewge]

I've tried to run some docker containers with your template but I stumbled onto a little issue.
In #1 you said supervisor can run a process as any user desired, witch run fine when the wheel is not supposed to be run with several spokes each using a different user for there processes.
Specifying in build-env a repo containing a a supervisor config file using a user not present in the spoke result in a broken wheel. It happen when two spokes meant to be running together each use a different user per process.

Let say container1 use user1 in his supervisor config file and container2 use user2 ; container1 has a build-env set to the container2 repo. Then when container1 is run in either mode, static or hybrid (I didn't tested the dynamic mode), it fail because it looks like supervisor read all the config files in the hub but the one from container2 specifying user2 make supervisrod to stop because he didn't know this specific user.

$ fig up # or  fig -f fig-hybrid-wheel.yml up
Creating wheelflexget_logs_1...
Creating wheelflexget_hub_1...
Creating wheelflexget_flexget_1...
Attaching to wheelflexget_logs_1, wheelflexget_hub_1, wheelflexget_flexget_1
logs_1    | Container will now idle.
hub_1     | ...file permissions successfully applied to /config.
hub_1     | ...file permissions successfully applied to /data.
hub_1     | ...file permissions successfully applied to /log.
hub_1     | Wheel repositories updated.
hub_1     | Container will now idle.
flexget_1 | Error: Invalid user name transmission
flexget_1 | For help, use /usr/bin/supervisord -h
wheelflexget_flexget_1 exited with code 2

I hope my explanation is not to fuzzy.

[clemtibs]

First let me say that the documentation is in great need of some updates, so I apologize if this is because of a gap there.

But to your questions. I had a look at your repository for this and know the problem. Supervisor is very, very dumb when it comes to serializing tasks. I see that you have to add the user "transmission" before running as it. But this has failed in so many ways for me. I tried so many hacks to try to get supervisor to run setup tasks before running my actual programs; all for not. So to do this, I've actually relied on very robust entrypoint.sh scripts. Check out my radial examples. To get yours to work, I suggest the following:

1. Move your user creation to your Spoke Dockerfile here.
2. Move all this to your entrypoint script here. There it will always accept your incoming env vars.
3. lastly, run your actual binary with exec so that it can accept incoming signals from the docker daemon and stop/restart correctly.

Let me know if this helps!

[bricewge]

So i tried what you suggested and I don't know yet if it work.
Because now I don't know where to put the stuff for files permissions (like chmod or chown), putting it in entrypoint.sh doesn't work as it's run as an user and not the root.

[clemtibs]

This would be file permissions for what exactly? The configuration files? or some other data? Configuration handled by the Hub container already has some sane defaults applied to it that you can check out here.

In general, the easiest thing I've found to do would be to actually run the entrypoint script as root after all (so keep user = root in your transmission.ini file) so you can setup all the permissions, but then later drop them when actually running the program using "su" or something similar. I used this method in my postgresql entrypoint that you can check out here.

[bricewge]

It's needed for the configuration files because some process need write access to it and sometimes for logs files to write in it. So the default don't work for me here.

I thought about using su in the entrypoint.sh and setting user = root in the supervisord config file as you say, but this feel like a very hacky way to me. And this is why I opened this issue, it would be great to have a nice way to do it.

[clemtibs]

I personally don't see an issue with using exec su, but I could be missing something of course and I'm open to discussing alternatives and security issues with that method.

I think the real way to fix this however is just to allow the user to specify the desired folder/file permissions via env vars being passed to the Hub container, as it really is it's job to mange all things configuration, not the Spoke. The spoke should really be plug-and-play. So I'll try to add that functionality later tonight to the radial/hub-base image.

[clemtibs]

@bricewge
I finally found a chance to implement this as a real feature. So you can now not only set different defaults using $PERMISSIONS_DEFAULT_DIR and $PERMISSIONS_DEFAULT_FILE, but you can specify special exceptions using $PERMISSIONS_EXCEPTIONS. Here is usage copied from the readme:

• $PERMISSIONS_DEFAULT_DIR: ["755"] Default (recursive) directory
  permissions for /config, /data, and /log.
• $PERMISSIONS_DEFAULT_FILE: ["644"] Default (recursive) file permissions
  for files contained in /config, /data, and /log.
• $PERMISSIONS_EXCEPTIONS: [empty] A single string, separated by spaces,
  containing a list of files/directories to chmod/chown.
  • The format for a single entry:
    {}{:}[:][:]
  • These values, separated by ':' are passed directly into chown and
    chmod so things like /config/* work for directory contents and numeric
    user and group ids work as well.
  • Some examples:
    • /config/supervisor/conf.d/*:700
    • /config/supervisor/supervisord.conf:700:root:root
    • /config/supervisor/myprogram.conf:777:myprogramuser

So in your case, you'd want to specify something like PERMISSIONS_EXCEPTIONS=/config/transmission:777 /config/transmission/*:777 as an env var for your Hub container. Note that if you want to change the owner of files to some custom user, you'll have to use the numeric id for that user (or what it will eventually be on ubuntu) as the command is run on busybox, which knows nothing of the new user in the Spoke container.

Let me know how this works out for you.