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

Install vim in the zulip image so that files can be easily edited #128

Open
gioragutt opened this issue Jun 25, 2018 · 11 comments
Open

Install vim in the zulip image so that files can be easily edited #128

gioragutt opened this issue Jun 25, 2018 · 11 comments

Comments

@gioragutt
Copy link
Contributor

Hi, consider I'm accessing the zulip container with something like

sudo docker-compose exec zulip /bin/bash

And I want to f.e edit /etc/zulip/settings.py, currently the two methods I had were:

  1. Add a working debian souce and apt-get it myself - takes a bit more, easily overriden
  2. docker cp out -> edit the file -> docker cp in.

Not really comfortable, the second one is more reliable, but the best thing would be to easily edit the files with vim when you have an open bash in the container.

@timabbott
Copy link
Member

Yeah, we should include this; it won't add much to the container image size and make life a lot easier for manual inspection/debugging.

@timabbott
Copy link
Member

@galexrt do you have thoughts on what folks normally do for editors in an image like this? They're pretty small in disk size compared to the rest of the image, so possibly we should just include them, but I'm curious whether folks try to do it under an option or something.

@galexrt
Copy link
Collaborator

galexrt commented Jul 10, 2018

@timabbott Normally the configs would not be edited inside the container, that is what the /data/settings directory is for, see https://github.com/zulip/docker-zulip/blob/master/entrypoint.sh#L79-L91.

I'm against installing any editor, as the config can already be edited from outside the container when LINK_SETTINGS_TO_DATA is set to True, https://github.com/zulip/docker-zulip/blob/master/entrypoint.sh#L49.
i think the LINK_SETTINGS_TO_DATA is just not documented yet.

@gioragutt
Copy link
Contributor Author

@galexrt definitely not document. I would much rather have it linked outside and edit it how I like than having to vim inside the container. But compared to not being able to edit without docker cping, then vim is a better solution.

Can you elaborate on the env var here a it?

@galexrt
Copy link
Collaborator

galexrt commented Jul 10, 2018

@gioragutt If you set LINK_SETTINGS_TO_DATA: "True", your data dir on the host will have a settings directory in which you can edit the settings.py.

@gioragutt
Copy link
Contributor Author

Amazing. BTW, using docker-compose, what's your suggested method of restarting the server after changing env vars, without losing data? I do it every now and then, always hope mother gets ruined, and yesterday I fucked my server up and lost some data trying to make it work again.

@galexrt
Copy link
Collaborator

galexrt commented Jul 10, 2018

Just use docker-compose stop && docker-compose rm and to start again docker-compose up -d.

The container is currently for being started and "on stop" being deleted and recreated.

Are you talking about the Zulip server?

@gioragutt
Copy link
Contributor Author

Yes. So the step I'm not doing is the rm.

@gioragutt
Copy link
Contributor Author

This should be added to the docs maybe. "How to restart the server after environment variables changes". Just to be sure, the rm does not delete the volume data, right?

@timabbott
Copy link
Member

Agreed, I'm reopening this as a documentation issue for covering that.

@timabbott timabbott reopened this Jul 25, 2018
@galexrt
Copy link
Collaborator

galexrt commented Sep 16, 2018

@gioragutt docker-compose rm only removes the containers, as long as you have specified volumes for the data in the docker-compose.yml you are good.

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

No branches or pull requests

3 participants