Docker setup issues on macos
Closed this issue · 6 comments
A user (@yanamal) reported the following issues when trying to get a new Docker setup running on macOS.
- usermod:
on line 541 of docker_tools.py, there is a usermod shell command, but it seems that usermod is not a command that natively exists on mac. Instead, I manually had to do some combination of the following:
sudo dscl . create /Groups/www-data
sudo dseditgroup -o edit -a $USER -t user www-data
sudo dscl . append /Groups/www-data GroupMembership $USER
(I think that I somehow ended up needing both dscl and dseditgroup, because mac's group membership logic seemed weird and the 'groups' command didn't always reflect the new membership until I did both)
2. Xvfb:
I was building with --single-dev since I wanted to have RunestoneComponents and BookServer built from source, since I will probably end up making changes in at least one of those.
docker_tools.py tried to set up VNC access using Xvfb around line 817.
While Xvfb does exist, it didn't like the options that the script gave it. It failed with:
Unrecognized option: /private/tmp/com.apple.launchd.mkm3ilvZCX/org.xquartz:0
(I think the xquartz location was correct, but Xvfb didn't know what to do with that)
This particular failure didn't cause the script to crash, so I ended up just letting it happen because I still wasn't sure what options my Xvfb did understand.
-
chgrp with bad symlinks (?):
on line 888, docker_tools.py tries to run chgrp to recursively change permissions. I consistently got the following error:
chgrp: changing group of '/srv/web2py/applications/runestone/.venv/bin/python3': No such file or directory
(plus a few more for other versions of python)
the most likely cause seems to be that these are symlinks that aren't pointing to anything (or pointing to something chgrp can't deal with?). I'm not sure why they are there, since this is already inside the (fresh) docker image as far as I can tell. I tried a couple of options to convince chgrp to not follow symlinks, but it didn't seem to help. In the end I just forced the QUICK_START option to avoid this logic. -
When restarting the script after various failures, I had a couple of issues with the logic starting on line 402:
first, I tried to re-run the script right after manually fixing the group permissions stuff; line 402 correctly detected that I wasn't yet inside the RunestonServer folder, but then it incorrectly said "Didn't find the runestone repo. Cloning...", and failed, because in fact the RunestoneServer folder already existed, because the previous run of the script failed after cloning the RunestoneServer repo.
Then, at a later point, the script was already running from inside RunestoneServer; but there was no nginx directory in it, since that gets set up separately, and that part had failed somehow. The logic on line 402 looked for the nginx directory and incorrectly decided that this was outside the RunestoneServer directory and tried to re-initalize everything while nested inside RunestoneServer.
- We should detect that we are in macos and do the right thing. Plus in both cases mac and linux one needs to logout and login for the group change to take effect.
- I would like to make all of this optional and only added if the user asks for it.
- I have nvever run into this, so I'm not sure what is going on.
- Again I have not seen this
Tagging @bjones1 in case he has run into any of the above and has thoughts.
This confuses me -- if it runs on your Mac, what's different here? I don't understand why running Xvfb would need different flags, since this is running in the container. ???
One thing that may different overall is that this was a totally fresh "bootstrap" install on a computer that hasn't ever run or set up any previous versions of Runestone. So, for example, if I was running it on a computer where the group settings were already correct for some other reason, it may never have run into the usermod/chgrp stuff.
For Xvfb specifically, it seems that the flag in question comes from my computer's environment variable $DISPLAY. Or at least when I do echo $DISPLAY in my terminal (NOT in the container), it is exactly the same as that flag. It also seems that $DISPLAY is set if XQuartz is installed on the computer. On my mac it is. Maybe on other macs it was not, and the flag defaulted to :0.
I think that for me I added myself to the right group the first time I ran into the problem and then promptly forgot about fixing it in the script. 😬
I do not have XQuartz on my machine and don't have any DISPLAY variable set up.
I have never tried to use vnc or X (I think this should be an option or a separate docker-tools command to start) but wouldn't our docker config have to expose a port to connect to in order for this to work?