Am trying to use https://github.com/RallyTools/RallyRestToolkitForRuby to pull permissions of all users in my Rally Subscription. My authentication is through API Key. It fails with below error:
C:\Users\Administrator\Desktop\Rally-User-Management-master\Rally-User-Management-master>user_permissions_summary.rb
Connecting to Rally: https://rally1.rallydev.com/slm as ganra08#ca.com...
Running initial query of users...
Found a total of 12392 Enabled Users.
Summarizing users and writing permission summary output file...
C:/Users/Administrator/Desktop/Rally-User-Management-master/Rally-User-Management-master/lib/go_user_permissions_summary.rb:224:in block (2 levels) in go_user_permissions_summary'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_colle
ction.rb:36:ineach'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_collection.rb:36:in each'
C:/Users/Administrator/Desktop/Rally-User-Management-master/Rally-User-Management-master/lib/go_user_permissions_summary.rb:201:inblock in go_user_permissions_summary'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_query_result.rb:22:in block in each'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_query_result.rb:21:ineach'
C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/rally_api-1.2.1/lib/rally_api/rally_query_result.rb:21:in each'
C:/Users/Administrator/Desktop/Rally-User-Management-master/Rally-User-Management-master/lib/go_user_permissions_summary.rb:180:ingo_user_permissions_summary'
C:/Users/Administrator/Desktop/Rally-User-Management-master/Rally-User-Management-master/user_permissions_summary.rb:38:in <main>' undefined method[]' for nil:NilClass
How do i get over this error? The Readme.pdf in the GitHub page provides no info about this.
Agile Central (formerly Rally) support helped to resolve this.
The $wsapi_version variable is set in a couple of places. We need to ensure that it is set to '1.43', and not 'v2.0'. Then the error went away and the script runs as expected.
If using the my_vars.rb file, comment out both lines of the $wsapi_version and just let the one in the go_user_permissions_summary.rb (1.43) be used.
Related
I am trying to create a Bosh Microinstance on my Rackspace Server and am getting the following error:
E, [2013-10-29T15:17:25.113723 #30341] [0xc9c00c] ERROR -- : Unable to connect to the OpenStack Compute API. Check task debug log for details.
I, [2013-10-29T16:38:36.928221 #1754] [0x335004] INFO -- : No existing deployments found (will save to /root/bosh-deployments.yml)
I, [2013-10-29T16:39:14.636310 #1768] [0xfa9010] INFO -- : Loading existing deployment data from: /root/bosh-workspace/deployments/bosh-deployments.yml
I, [2013-10-29T16:39:20.766583 #1768] [0xfa9010] INFO -- : bosh-registry is ready on port 25889
I, [2013-10-29T16:39:26.731953 #1768] [0xfa9010] INFO -- : Loading yaml from /tmp/d20131029-1768-ewe5t0/sc-20131029-1768-ansv2l/stemcell.MF
E, [2013-10-29T16:39:28.626135 #1768] [0xfa9010] ERROR -- : Expected([200, 204]) <=> Actual(401 Unauthorized)
response => #<Excon::Response:0x0000000382cdc0 #data={:body=>"{\"unauthorized\":{\"code\":401,\"message\":\"Unable to authenticate user with credentials provided.\"}}", :headers=>{"Server"=>"nginx/0.8.55", "Date"=>"Tue, 29 Oct 2013 16:39:27 GMT", "Content-Type"=>"application/json", "Transfer-Encoding"=>"chunked", "Connection"=>"keep-alive", "vary"=>"Accept, Accept-Encoding, X-Auth-Token", "VIA"=>"1.0 Repose (Repose/2.3.5)"}, :status=>401, :remote_ip=>"72.3.138.129"}, #body="{\"unauthorized\":{\"code\":401,\"message\":\"Unable to authenticate user with credentials provided.\"}}", #headers={"Server"=>"nginx/0.8.55", "Date"=>"Tue, 29 Oct 2013 16:39:27 GMT", "Content-Type"=>"application/json", "Transfer-Encoding"=>"chunked", "Connection"=>"keep-alive", "vary"=>"Accept, Accept-Encoding, X-Auth-Token", "VIA"=>"1.0 Repose (Repose/2.3.5)"}, #status=401, #remote_ip="72.3.138.129"> (Excon::Errors::Unauthorized)
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/excon-0.25.3/lib/excon/middlewares/expects.rb:10:in `response_call'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/excon-0.25.3/lib/excon/middlewares/response_parser.rb:8:in `response_call'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/excon-0.25.3/lib/excon/connection.rb:349:in `response'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/excon-0.25.3/lib/excon/connection.rb:247:in `request'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/core/connection.rb:57:in `request'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/core/deprecated/connection.rb:20:in `request'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/openstack.rb:195:in `retrieve_tokens_v2'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/openstack.rb:88:in `authenticate_v2'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/openstack/compute.rb:392:in `authenticate'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/openstack/compute.rb:316:in `initialize'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/core/service.rb:68:in `new'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/core/service.rb:68:in `new'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/fog-1.14.0/lib/fog/compute.rb:44:in `new'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_openstack_cpi-1.5.0.pre.1181/lib/cloud/openstack/cloud.rb:55:in `initialize'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cpi-1.5.0.pre.1181/lib/cloud/provider.rb:11:in `new'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cpi-1.5.0.pre.1181/lib/cloud/provider.rb:11:in `create'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/configuration.rb:65:in `cloud'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:54:in `cloud'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:229:in `block (2 levels) in create_stemcell'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:79:in `step'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:228:in `block in create_stemcell'
/usr/local/rvm/rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:214:in `create_stemcell'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/bosh_cli_plugin_micro-1.5.0.pre.1181/lib/bosh/deployer/instance_manager.rb:118:in `create'
"microbosh-openstack/bosh_micro_deploy.log" 215L, 28192C
I have a .yml file set up which I can't really post for security reasons, but I've verified with my IAAS support that i have the correct credentials.
Has anyone seen an error like this on Openstack? Also I am getting a stack trace and half tempted to try debugging. Problem is I'm not well versed on debugging these large open projects. Does anyone know a good resource explaining how to begin debugging them?
The error that you're seeing is caused by OpenStack rejecting the credentials that you're providing. One possible pitfall: are you using your Rackspace account password for "PASSWORD" instead of an API key? You can find your API key by logging in to your account, clicking on your username in the upper-right, and choosing "account settings" from the drop-down. (I'm assuming you're using Rackspace because of the question tags.)
You mentioned that you've verified them with your provider -- perhaps they aren't being passed in correctly? According to the documentation, you should put them in a micro_bosh.yml file with the following form:
# ...
cloud:
plugin: openstack
properties:
openstack:
auth_url: http://<identity_server>:5000/v2.0
username: <username>
api_key: <password>
tenant: <tenant>
region: <region> # Optional
default_security_groups: ["ssh", "bosh"]
default_key_name: <microbosh_keypair>
private_key: <path_to_microbosh_keypar_private_key>
# ...
Remember that YAML is whitespace-sensitive.
As for debugging open-source projects, the best guidance I can give is to not be afraid of the source and to have some patience. The source code for bosh is available on GitHub, so you can easily browse around the source code up your stack trace to try to figure out what's going on. Work backwards from the actual exception or error message that you're seeing; try to determine what was put into an unexpected state, and trace callers to figure out how it could have ended up that way. Reading other people's source code is an incredibly useful skill, and it gets easier with practice, so have at it!
I got GitLab 5.4 using Bitnami Stack 5.4.0-0
After creating user, login and adding key, when pushing to new repository
git#gitlab.funshion.com:gitdemo1/gittest1.git: /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `initialize': getaddrinfo: Temporary failure in name resolution (SocketError)
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `open'
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `block in connect'
from /opt/bitnami/ruby/lib/ruby/1.9.1/timeout.rb:55:in `timeout'
from /opt/bitnami/ruby/lib/ruby/1.9.1/timeout.rb:100:in `timeout'
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `connect'
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:756:in `do_start'
from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:745:in `start'
from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_net.rb:62:in `get'
from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_net.rb:17:in `allowed?'
from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_shell.rb:60:in `validate_access'
from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_shell.rb:23:in `exec'
from /opt/bitnami/apps/gitlab/gitlab-shell/bin/gitlab-shell:16:in `<main>'
UPDATE:
Please help with starting GitLab server. We tried on 3 computers, no success.
UPDATE 2: gitlam.yml says relative_url_root is not supported, while Bitnami GitLab runs at server/gitlab/
# WARNING: This feature is no longer supported
UPDATE 3: A bit similar problem Gitlab 5.4 push connection refused was solved by changing the default URL to the root http://wiki.bitnami.com/Applications/BitNami_GitLab#How_to_change_the_default_URL_to_the_root.3f
However after executing all those steps, my GitLab is still running at /gitlab/ even after reboot.
accessing / , get message "Not Found: /" instead of default screen. So the transition is not full.
Server itself could not resolve the domain name. Solution is to add the domain in the /etc/hosts file.
127.0.0.1 gitlab.company.com
Also check the redis configuration in the gitlab/config/resque.yml. Could be pointing to redis.example.com.
I'm using the Rye ruby gem to SSH to a server and I'm having the problem where if I try to run any command from there I'm getting the following error:
rbox = Rye::Box.new(server, :user => "user", :password => "password")
rbox.ls
fingerprint d3:a1:15:ab:05:0d:4e:45:9f:b3:94:14:ca:11:d6:be does not match for "server,10.10.10.2"
Continue?
Net::SSH::HostKeyMismatch: Net::SSH::HostKeyMismatch
from C:/jruby-1.6.8/lib/ruby/gems/1.8/gems/rye-0.9.8/lib/rye/box.rb:678:in `connect'
from C:/jruby-1.6.8/lib/ruby/gems/1.8/gems/rye-0.9.8/lib/rye/box.rb:778:in `run_command'
from C:/jruby-1.6.8/lib/ruby/gems/1.8/gems/rye-0.9.8/lib/rye/cmd.rb:106:in `which'
from (irb):31:in `evaluate'
from org/jruby/RubyKernel.java:1112:in `eval'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:158:in `eval_input'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:271:in `signal_status'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:270:in `signal_status'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:155:in `eval_input'
from org/jruby/RubyKernel.java:1439:in `loop'
from org/jruby/RubyKernel.java:1212:in `catch'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:154:in `eval_input'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:71:in `start'
from org/jruby/RubyKernel.java:1212:in `catch'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:70:in `start'
from C:\jruby-1.6.8\bin\irb:13:in `(root)'
I've tried deleting the 'known_hosts' file from the current user home (~/.ssh/known_hosts) but still failing with the same issue.
I've tried connecting with a different user and same problem as well.
The strange thing is that that fingerprint is always displaying the same value, so not sure where it's coming from.
rbox.keys -> doesn't return anything, just []
rye keys -> NameError: undefined local variable or method `keys' for main:Object
rbox.host_key -> The process cannot access the file because it is being used by another process.
=> [, , 1, ]
Any idea what could be causing this issue and what else could I try to sort it out or work around it?
Many thanks!
This library is based on Ruby's Net::SSH and it is looking for cached host keys in ~/.ssh/known_hosts and /etc/ssh/knowh_hosts.
For more information see documentation on Net::SSH::KnownHosts.
It turns out that even though you connect from:
*Local_pc => *Middle_server => *Final_server
it doesn't matter in which of those 2 servers you are, it seems the 'known_hosts' file that's used is not that of any of those 2 servers, it's your LOCAL known_hosts file.
As such, you can either remove the entry for the specific host that's failing in your end or create the following .ssh/config file to ignore the host keys:
Host *
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
That config file is located in the following path in Windows:
C:\Users\<your_user>\.ssh\config
I have a script that reads lines one by one from a csv file and index the same to elasticsearch in the same order. My elasticsearch host is the same machine on which the script is running. Everything else works fine except for a few rows when I suddenly start getting the following error:
W, [2012-10-09T14:46:00.899876 #11567] WARN -- : Cannot assign requested address connect(2)
D, [2012-10-09T14:46:00.900037 #11567] DEBUG -- : ["/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/net/http.rb:644:in `initialize'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/net/http.rb:644:in `open'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/net/http.rb:644:in `block in connect'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/timeout.rb:44:in `timeout'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/timeout.rb:89:in `timeout'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/net/http.rb:644:in `connect'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/net/http.rb:637:in `do_start'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/net/http.rb:626:in `start'", "/home/azitabh/.rvm/gems/ruby-1.9.2-p320/gems/rest-client-1.6.7/lib/restclient/request.rb:172:in `transmit'", "/home/azitabh/.rvm/gems/ruby-1.9.2-p320/gems/rest-client-1.6.7/lib/restclient/request.rb:64:in `execute'", "/home/azitabh/.rvm/gems/ruby-1.9.2-p320/gems/tire-0.4.2/lib/tire/http/client.rb:11:in `get'", "/home/azitabh/.rvm/gems/ruby-1.9.2-p320/gems/tire-0.4.2/lib/tire/search.rb:94:in `perform'", "/home/azitabh/.rvm/gems/ruby-1.9.2-p320/gems/tire-0.4.2/lib/tire/search.rb:20:in `results'", "models/test.rb:31:in `get_details'", "models/test.rb:56:in `block in index_test'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/csv.rb:1768:in `each'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/csv.rb:1202:in `block in foreach'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/csv.rb:1340:in `open'", "/home/azitabh/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/csv.rb:1201:in `foreach'", "models/test.rb:40:in `index_test'", "models/test.rb:85:in `<main>'"]
And the errors are not related to the values at those rows in the csv. I get these errors at different locations at different times.
There is another error "WAIT_TIMEOUT" which I get some time. Couldn't put the trace here as I didn't get that error this time.
I am coding in ruby and using "Tire" gem to talk to elasticsearch. I don't feel these are responsible in any way though.
JAVA was using 8% of my system's memory at the time I got this error. This is much below the assigned value ES_MIN_MEM=2g.
Thanks in advance
-Azitabh
This is happening because tire doesn't close the tcp connection by itself. Once all the available ports gets engaged, no further connection is possible until system closes all connections in waiting state itself. This takes some time and any attempt to establish new connection results in wait_timeout.
I'm receiving a strange error when using DataMapper as the backend for Delayed Job. I am currently using the following gems:
delayed_job, 2.1.0.pre2
delayed_job_data_mapper, 1.0.0.rc
According to the instructions found here:
https://github.com/collectiveidea/delayed_job_data_mapper
I can successfully run
Delayed::Worker.backend = :data_mapper
Delayed::Worker.backend.auto_upgrade!
as well as enqueue objects into the database. However, when I try to run a rake task to run a worker, the workers starts successfully, but then when trying to decide what jobs to pull, gives the following error:
rake aborted!
expected a time or date, got Sun Feb 20 11:06:58 -0600 2011
It seems that this was previously reported as an issue on Github by someone else, but there's no solution, and the ticket is months old:
https://github.com/collectiveidea/delayed_job_data_mapper/issues#issue/1
[UPDATE] Someone posted an answer to the Github issue, which I have duplicated in my answer below this question.
So, my question is this: has anyone solved this error? Or is there a different way to do DataMapper + Delayed Job that I'm not aware of?
Full rake trace:
expected a time or date, got Sun Feb 20 11:08:56 -0600 2011
/Library/Ruby/Gems/1.8/gems/activesupport-3.0.3/lib/active_support/duration.rb:94:in `sum'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.0.pre2/lib/delayed/worker.rb:33:in `inject'
/Library/Ruby/Gems/1.8/gems/activesupport-3.0.3/lib/active_support/duration.rb:86:in `each'
/Library/Ruby/Gems/1.8/gems/activesupport-3.0.3/lib/active_support/duration.rb:86:in `inject'
/Library/Ruby/Gems/1.8/gems/activesupport-3.0.3/lib/active_support/duration.rb:86:in `sum'
/Library/Ruby/Gems/1.8/gems/activesupport-3.0.3/lib/active_support/duration.rb:69:in `until'
/Library/Ruby/Gems/1.8/gems/activesupport-3.0.3/lib/active_support/core_ext/time/calculations.rb:255:in `minus_without_coercion'
/Library/Ruby/Gems/1.8/gems/activesupport-3.0.3/lib/active_support/core_ext/time/calculations.rb:268:in `-'
/Library/Ruby/Gems/1.8/gems/delayed_job_data_mapper-1.0.0.rc/lib/delayed/backend/data_mapper.rb:35:in `find_available'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.0.pre2/lib/delayed/worker.rb:172:in `reserve_and_run_one_job'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.0.pre2/lib/delayed/worker.rb:101:in `work_off'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.0.pre2/lib/delayed/worker.rb:100:in `times'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.0.pre2/lib/delayed/worker.rb:100:in `work_off'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.0.pre2/lib/delayed/worker.rb:75:in `start'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.0.pre2/lib/delayed/worker.rb:74:in `start'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.0.pre2/lib/delayed/worker.rb:71:in `loop'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.0.pre2/lib/delayed/worker.rb:71:in `start'
Thanks!
stefanobernardi on Github gave this answer:
You need to require
"active_support/core_ext"
I haven't had a chance to try this out myself and see if it works since I ended up going with Resque instead, but I thought I would go ahead and post this answer in case anyone else comes across this question and actually wants a solution.