Failed to `sudo bundle install` in vagrant
kennetham opened this issue · comments
I managed to run vagrant ssh and bundle install but sudo bundle install will result in this following log below. Furthermore, if I try to start bundle exec rake warden:start as instructed, I get a different error saying that I need to Operation not permitted - setrlimit and if I sudo bundle exec rake warden:start... I will get an error that I need to bundle install first, which even if I had already done so.
I am able to wget https and http without any issue, git clone the respective links has no issue either. It seemed only concerning warden start.
Please advise.
Fetching https://github.com/cloudfoundry/common.git
fatal: unable to access 'https://github.com/cloudfoundry/common.git/': Failed to connect to github.com port 443: Connection timed out
Retrying git clone 'https://github.com/cloudfoundry/common.git' "/opt/rubies/ruby-2.1.6/lib/ruby/gems/2.1.0/cache/bundler/git/common-4cd969274bc7dedaa8c10ef1f1a48c5e72eb21ad" --bare --no-hardlinks --quiet due to error (2/4): Bundler::Source::Git::GitCommandError Git error: command `git clone 'https://github.com/cloudfoundry/common.git' "/opt/rubies/ruby-2.1.6/lib/ruby/gems/2.1.0/cache/bundler/git/common-4cd969274bc7dedaa8c10ef1f1a48c5e72eb21ad" --bare --no-hardlinks --quiet` in directory /warden/warden has failed.
We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/96160270.
Hi @kennetham,
Our documentation specifies that you must bundle install as root (via sudo) since the rake warden:start task needs to be executed as a privileged user. Since gems are installed per user in order to run bundle exec as root successfully you must have first bundle installed as root.
That being said I'm not sure what is causing your issue. It looks like a network or DNS error. I'd recommend destroying your vagrant box and restarting per the instructions in the readme. I'd also attempt to correlate any github outages with the timing of your attempts to run these tests.
Please keep us informed
@zaksoup and @wendorf CF Runtime Team
Hi @zaksoup @wendorf
Yes I did followed the documentation very closely and did the following but it did not work inside vagrant. Besides, I am already on root privileges.
I have also destroyed the vagrant box this morning and have run it once more, I am assuming it could be likely due to company's proxy settings or so. I am going to run that on my personal machine and see if it works, it sounds like it could be an internal security block.
Thank you for the quick response.
Could you please advise me why DEA is unreachable?
12:38:58 directory_server.1 | started with pid 4304
12:38:58 nats.1 | started with pid 4306
12:39:01 directory_server.1 | {"timestamp":1433475541.769407511,"process_id":4329,"source":"directory_server","log_level":"info","message":"Starting HTTP server at host: 10.232.217.111 on port: 80","data":null}
12:39:35 directory_server.1 | {"timestamp":1433475575.044678211,"process_id":4329,"source":"directory_server","log_level":"info","message":"Sending HTTP request to DEA: http://127.0.0.1:1234/","data":null}
12:39:35 directory_server.1 | {"timestamp":1433475575.045011759,"process_id":4329,"source":"directory_server","log_level":"warn","message":"Error in LookupPath: DEA is unreachable","data":null}
12:39:35 directory_server.1 | {"timestamp":1433475575.062807560,"process_id":4329,"source":"directory_server","log_level":"info","message":"Sending HTTP request to DEA: http://127.0.0.1:1234/favicon.ico","data":null}
12:39:35 directory_server.1 | {"timestamp":1433475575.062947273,"process_id":4329,"source":"directory_server","log_level":"warn","message":"Error in LookupPath: DEA is unreachable","data":null}
12:41:04 directory_server.1 | {"timestamp":1433475664.435126305,"process_id":4329,"source":"directory_server","log_level":"info","message":"Sending HTTP request to DEA: http://127.0.0.1:1234/","data":null}
12:41:04 directory_server.1 | {"timestamp":1433475664.435354471,"process_id":4329,"source":"directory_server","log_level":"warn","message":"Error in LookupPath: DEA is unreachable","data":null}
12:41:04 directory_server.1 | {"timestamp":1433475664.448570013,"process_id":4329,"source":"directory_server","log_level":"info","message":"Sending HTTP request to DEA: http://127.0.0.1:1234/favicon.ico","data":null}
12:41:04 directory_server.1 | {"timestamp":1433475664.448713779,"process_id":4329,"source":"directory_server","log_level":"warn","message":"Error in LookupPath: DEA is unreachable","data":null}
Hi @kennetham
Where are you seeing these messages? It would be helpful to understand what you're trying to achieve. I'm not sure why the url .../favicon.ico is trying to be reached.
Thanks,
@zaksoup + @DanLavine CF Runtime Team
Hi @zaksoup
These messages are within DEA when I run the command for foreman to start. I tried to create a container and reach the server but this was the message that was thrown.
Running DEA itself, how would you recommend to connect and create a container to test it's integration?
Thanks!
It looks like you are trying to access the directory server from a browser? The directory server does not provide a web interface, it is an http api for getting a file from a container using a signed url.
To get a valid signed url, the normal way is to send a message over the nats message bus to ask for it.
We're not quite sure what you are trying to accomplish. There are many pieces the DEA uses to create a container for a process. Are you trying to test the full integration of sending a start command to the DEA, having it fetch a droplet and then execute that droplet in a container?
@jpalermo Ah I get you. Yes I was trying to test DEA component as it is and understand the flow. I realized that Cloud Foundry's documentation may look complete but there aren't good examples to reference to, and to understand better. For instance, deploy BOSH on OpenStack, the information are provided as is, and the challenge is figuring out what next. I have tried mailing list, but seems like I didn't get any response as well.
IRC Channels are quiet too. Any recommendations to who and how I should get help from especially with Cloud Foundry?
Please advise.
The lists are probably your best bet. Due to the move recently, we've had a period where it was not being watched as closely as it should have been, but it is better now.
It may be difficult to get a response from the dev team or the community on DEA and Warden issues though. Since both are slated to be replaced by Diego and Garden, there are no developers working on them full time. Both are also complex enough that there has never been much community involvement in either of them.