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.

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

Enable public user #2

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Enable public user #2

wants to merge 4 commits into from

Conversation

dpwrussell
Copy link
Member

Enables the public user if the same settings that are required for the web are specified to the server.

I gave some thought to making this non-public-user specific, but this did not make much sense to me given its limited capabilities. I believe for that to be useful it would be necessary to build something much more complicated that takes configurations of users, groups and user-group memberships.

Even for this simple case, if it was generic it would not be logical to me (imagining myself an end user) that the server docker would also take one username and one groupname and that the given username would be in the given group.

No problem if you don't want to merge this in favour of a more powerful mechanism for adding users and groups, thanks to the modularised run scripts I can provide this in my package instead easily until that exists.

Depends on #1 I will rebase as that is merged.

@manics
Copy link
Member

manics commented Jun 14, 2017

I've checked the IDR where we've decoupled server and web, and omero.web.* properties are only needed in OMERO.web, they're not used by the server. On one hand using the properties CONFIG_omero_web_public_user and CONFIG_omero_web_public_password means you'll be able to use the same env-vars when running the server and web images, on the other it means you're setting unnecessary properties. Anyone else have thoughts?

@dpwrussell
Copy link
Member Author

Yes, normally that is the case because web settings are only applicable to web, but as there is a server prerequisite explicitly for web in this case, it seemed to make sense to use the same setting key.

@dpwrussell dpwrussell closed this Jun 14, 2017
@dpwrussell dpwrussell reopened this Jun 14, 2017
@manics
Copy link
Member

manics commented Jul 13, 2017

@dpwrussell Could you rebase this please?

@openmicroscopy/devops How does everyone feel about auto-creating a public user if CONFIG_omero_web_public_enabled=true but no other params are passed? Do you think this should be part of the main omero-server image, or a separate omero-server-public image which we maintain?

@joshmoore
Copy link
Member

I'm happy for public user config to be part "omero-server-docker 5.4" since that's currently recommended practice. It might be that with the true read-only work it'll look different in 5.5 or later, but so be it.

@dpwrussell
Copy link
Member Author

Rebased and tested.

@joshmoore
Copy link
Member

Note: currently looking at this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants