search

crashsystems / gitlab-docker

Automated buld of GitLab with Docker.io
195 stars 56 forks source link

sudo :: Could not resolve host #1

Closed robinkruyt closed 10 years ago

robinkruyt commented 11 years ago

When running sudo -u in install.sh the error "could not resolve host XXX" gets returned instead of actually running the command.

This could be caused because of the lack of an /etc/hosts file.

crashsystems commented 11 years ago

When I run this, it spits out that error, but the commands still run. Are you sure that its not that they are running, but the specific commands in question just don't have any output on the terminal?

robinkruyt commented 11 years ago

It does not seem to run for me.

crashsystems commented 11 years ago

Is there a specific comments it seems to fall on, or is it just the first one?

robinkruyt commented 11 years ago

The first one

robinkruyt commented 11 years ago

Running it again, you seem to be right in your first comment, and the fact that the install does not finish might be unrelated..

I am building the dockerfile as we speak, and I will return with a log of its output.

robinkruyt commented 11 years ago

You can find my log here: http://tny.cz/0817bd77 It hangs on fetching.

crashsystems commented 11 years ago

I'm traveling currently, and can't view the file very well on my phone. I can tell it at least gets to the point of downloading the ruby source. Can you figure out specifically what download it hangs on?

robinkruyt commented 11 years ago

The last three lines are: sudo: unable to resolve host 80655c8d1f87 Fetching source index from https://rubygems.org/ Fetching https://github.com/gitlabhq/raphael-rails.git

I (wrongly) assumed this would be a sudo issue, however it seems to be more of an bundler issue

zshannon commented 11 years ago

Have you all figured this out? I'm encountering the same error running on a DigitalOcean 1 GB instance.

robinkruyt commented 11 years ago

Yeah. As it turns out, the sudo issue is more of a warning and does not appear to break anything. While the program appeared to hang on the three lines I commented earlier, I discovered that letting it run for about 4 hours will finish the setup.

zshannon commented 11 years ago

@robinkruyt thanks. How are you handling persistent storage?

crashsystems commented 11 years ago

Storage in a Docker container is persistent by default. On Sep 22, 2013 11:20 PM, "Zane Shannon" notifications@github.com wrote:

@robinkruyt https://github.com/robinkruyt thanks. How are you handling persistent storage?

— Reply to this email directly or view it on GitHubhttps://github.com/crashsystems/gitlab-docker/issues/1#issuecomment-24900731 .

zshannon commented 11 years ago

@crashsystems when I run docker run ..., make some changes in the web app, run docker stop $IMAGE_ID, then run docker run ... again, the changes are lost. Can you predict what I could be doing wrong?

robinkruyt commented 11 years ago

If I am not mistaken you have to run the id you get from the first run command instead of the same as the first command.

robinkruyt commented 11 years ago

However, there might be a more elegant way I do not know about ?

crashsystems commented 11 years ago

IMHO the run command could be better named. Run creates a new instance of an image (instance == container), then starts it. That short hex string docker prints out is the container ID. When you stop that, then run docker start ID, it starts that instance back up. On Sep 22, 2013 11:25 PM, "Zane Shannon" notifications@github.com wrote:

@crashsystems https://github.com/crashsystems when I run docker run ..., make some changes in the web app, run docker stop $IMAGE_ID, then run docker run ... again, the changes are lost. Can you predict what I could be doing wrong?

— Reply to this email directly or view it on GitHubhttps://github.com/crashsystems/gitlab-docker/issues/1#issuecomment-24900832 .