odarriba/docker-timemachine

Multi-user support?

Closed this issue · 13 comments

ajarara commented

As it stands now, the instance only has the capability to interact with one client. Are users supposed to run multiple instances of this for each client who needs this?

It looks like afp.conf has the capability to handle multiple clients.

Implementing this would require a rather significant change to the UI, and might be best addressed in a fork. What do you think?

odarriba commented

As you said, afp allows for multi-user configuration. This container is single-user just because it uses configuration variables to create that afp.conf file.

In order to do this, I think the best option is to allow user to "mount" a custom afp.conf file. What do you think?

If you want to create a fork and develop this feature, please be welcome.

Thanks!

ajarara commented

I was hoping you'd say that. I agree that mounting an afp.conf file (either within the same directory as the Dockerfile, named afp.conf, as a default, or overridden by some -e flag pointing to the file) is the best solution.

Would you like the single user config to stay untouched?

odarriba commented

I think that we can modify the startup script: if there is a previous afp.conf, don't generate a new one.

With this change and a mountpoint, we can conserve both functionalities. What do you think?

If you finally do the PR, please update the README with these instructions and feel free to add yourself to contributors list. It's a great feature.

ajarara commented

Sorry for the lack of response, midterms rolled around last week.

Unfortunately, it looks like I won't have access to a machine running OS X until Thanksgiving. I have a couple of branches that I'd like to run tests on, but can't really provide a polished, tested PR, I can't tell if they work or not. If you're willing to wait that long, I'd be happy to hack on this over the coming break, but if anyone else in the meantime wants to do this, more power to them.

odarriba commented

Don't worry @Alphor, I'm pretty sure that this can wait a bit longer.
But, if any other is interested in this functionality, fell free to contribute as @Alphor said.

Thank you for your update and your work! It will be awesome!

  • 👍1
odarriba commented

Hello!

I have updated the image, so now users can be added executing a simple command (and the README file is updated too).

So now the container start with no user on it, and the users can be added as you wish.

I think this solves the issue, so I close it.

Thanks!

  • 🎉1
ajarara commented

This looks great! Well done.

Dids commented

@odarriba Users aren't persisted though, right?

odarriba commented

@Dids Users are persisted while the container isn't deleted and created again. They are persisted inside the cointainer, but not in the external volume, so they should persist while the container isn't deleted.

Dids commented

@odarriba I know, I just wouldn't call that persisting. ;)
In my case I have a systemd service that's recreating the container on boot/shutdown, but I went with an insecure hack for now, and simply added an extra "post startup" step for the service, which adds the users.

odarriba commented

@Dids As the configuration depends on having a user created inside the container, the configuration is really hard and insecure to store, as it would require storing the passwd file or the user's password directly.

I can recommend you two viable configurations:

  1. Create the container storing the sfpd configuration file and the container's passwd file in a volume mapped to your machine
  2. Start the container with the setting of autostart with the local machine, so you wouldn't need a systemd service, and you will ever have the same container running (which you only need to configure once).
  • 👍1
Dids commented

@odarriba Thank you, the first one sounds like it'd work better for my environment. :)

odarriba commented

Glad that helps! Only one thing: remember you should set the right permissions, as the passwd file is very sensitive :)

  • 🎉1