It has been a while since I upgraded our local Girder. I just upgraded from 3.05 to 3.17 and am looking for the page where I can change plugin settings.
For example, I installed the google-oauth plugin and the plugin appears on the plugin configuration page on the Girder.
However, I cannot access any google-oauth settings within the Girder itself. Since I had previously registered with google, I just need to copy my existing settings into the new girder/plugin, but I cannot determine how to do so.
Of those plugins I do have installed, while they appear on the Girder plugin page, clicking any of them there simply takes me to the Plugin documentation page on readthedocs.
For other reasons, I am already rebuilding with “girder build”. Is there some other initialization step I am missing in the instructions that would let me get at the settings for the plugins?
Addendum: I checked an old 2.3.0 Girder, and compared to that server, I seem to be missing On/Off toggles on the plugin page as well as ‘Rebuild’. I would need to spin up my 3.0.5 version to see if those buttons were there.
John.
Did you run girder build after installing plugins? It builds the web client for all registered plugins (note that it requires node <=14.x). Once done, you should see a gear icon next to each plugin that has client adjustable settings.
– David
Thanks. I am using the Docker Girder image as a starting point. I pip install the desired plugins prior to running the “girder build --dev” command.
One thing is not completely clear to me regarding the docker image and that is whether I need to do anything post build. I know the default girder setup in the docker image has a girder in /usr/local/bin/girder, but the source seems to be in /girder. After building, is there a step necessary to replace the installed version?
John.
You shouldn’t need to do anything to replace the girder instance. Installing new plugins inside the docker container (or a derivative image), then running “girder build” or “girder build --dev” after the pip install should be sufficient, and then running “girder serve” as usual.
Yeah, that’s not working. The plugins show up as rows on the plugin page, but without any “gears” to change settings. Hence, I can’t set up the oauth secrets.
I know my pip install of the plugins is working because the base docker image has no plugins running and they only show up after I pip install them and girder build. But, still no gears for changing settings.
I don’t see any errors in the javascript developer console or in the Girder logs.
Is there older documentation somewhere for spinning up Girder? The latest documentation (going back several versions on readthedocs) only describes the ansible launch. There’s not much detail about either a git installation or the docker approach.
Thanks,
John.
Hmm – It works when I do this (with a mongo instance running on the host computer):
docker pull girder/girder
docker run --net=host --rm --entrypoint bash -it girder/girder
And then inside the docker container
pip install girder-oauth
girder build --dev
girder serve
Ok. Then we are getting into the details of the docker build.
I believe the image as built expects to run the container internally as root.
I modify my image to run as a limited user and then pip install the libraries as that user during the image creation. I also make the internal /girder folder and subfolders all read/writable by that user.
There may be some part of the pip install process or girder build that expects to be able to write to the main system folders (ex. the python tree below /usr/). I know I seem to have to run girder build itself as root, rather than my limited user.
I am also modifying the URL on the front end to serve up from a subfolder via the public_path (I am going from memory) setting in the cfg file. I suppose that might mess up the URL addressing the gear element that should appear in on the individual plugin settings.
John.
I can confirm that if I start with a fresh installation of mongo and girder using docker images on a new machine, I can eventually get to the plugins settings pages. A gear appears.
However, I am unable to upgrade an existing mongo/girder pair with the same result. The girder shows its version as being updated on the web page and lets my existing admin user log in, but the plugins page is missing any gears to change settings on plugins.
I am wondering if my older girder.cfg file is perhaps missing something that the newer version expects. I’m going to check against the newest distribution of girder to see if I am missing something.
I also ran the above successful test without a proxy by connecting the mongo and girder containers directly to the host network and accessing them over 127.0.0.1. It is possible that the reverse proxy that I am using for my older setup is somehow interfering.
John.
I checked my girder.cfg file and it was not significantly different from the current distribution.
I am leaning toward my problems arising from the reverse proxy I am running the Girder behind. Additionally, I am not running at the top level, but proxying to a suburl. I noted above that I could see the gears when I ran the Girder free-standing without the proxy.
In the girder.cfg I have settings for informing the Girder about the reverse proxy and sub-url. When running at the suburl /girder (ex. http://my.site.com/girder/):
api_root = "/girder/api/v1"
static_public_path = "/girder/static"
static_root = "/girder/static"
static_root_dir = "/girder/static"
I believe some may have been deprecated over the years.
Are there any other settings I need to fix when running Girder between a reverse proxy at a sub-url?
Thanks,
John.
Thanks. Those are the settings I have and which worked for my older girder (I could see the plugin settings), but not for the latest Girder (docker image).
I am going to chalk the problem up to one of the following:
- I am starting with the Docker image which, in my experience, was built to run Girder as root. I attempt to make some modifications to let it run internally as non-root. This causes problems when having to rebuild since some of the initial infrastructure was installed/built as root and is not writeable by non-root. The solution here will likely mean building my own Docker image starting with Girder source.
- I am also running the Girder internally with SSL turned on. I suppose that means the CherryPy server? I do this with further settings in the cfg file as well as generating certificates for the Girder to use. That may or may not be interfering in the current case, depending on how well I’ve configured the Girder to run in SSL mode.
Thanks for the help and pointers. I probably will not tackle building my own Girder Docker image from source in the near future. If and when I do manage to get the plugins back into a working state, I will post back here.
John.
Or it could be something as simple as changing browsers.
As long as I install the plugins and build at root, I seem to be fine running girder serve as non-root.
In Chrome, the gears appear. In Vivaldi, they are invisible but if I click in the region where they should be, I am taken to the plugin menu.
John.