Cloudfoundry Deploy Micro Bosh Fails - ruby

I am trying to follow this guide here: http://kendrickcoleman.com/index.php/Tech-Blog/from-zero-to-cloud-foundry-on-vsphere-part-1-how-to-install-microbosh.html
I am up to step 13.
I get a error in the log:
I, [2014-10-08T15:57:11.460375 #30531] [attach_disk(vm-3bfd53b7-1bac-44e1-b6a9-87454f9d0f88, disk-e1e99cad-1c98-4096-a78c-4b81ee1509ee)] INFO -- : Updating agent env to: {"vm"=>{"name"=>"vm-3bfd53b7-1bac-44e1-b6a9-87454f9d0f88", "id"=>"vm-8857"},
"agent_id"=>"bm-913097b0-3865-4f87-b5b1-9608e66b34c9",
"networks"=>
{"bosh"=>
{"cloud_properties"=>{"name"=>"Network Private"},
"netmask"=>"mynetmask",
"gateway"=>"mygateway",
"ip"=>"myip",
"dns"=>["mydns"],
"type"=>nil,
"default"=>["dns", "gateway"],
"mac"=>"00:50:56:93:17:23"}},
"disks"=>
{"system"=>"0",
"ephemeral"=>"1",
"persistent"=>{"disk-e1e99cad-1c98-4096-a78c-4b81ee1509ee"=>"2"}},
"ntp"=>["ntp.example.com.au"],
"blobstore"=>
{"provider"=>"local",
"options"=>{"blobstore_path"=>"/var/vcap/micro_bosh/data/cache"}},
"mbus"=>"https://vcap:b00tstrap#0.0.0.0:6868",
"env"=>{"bosh"=>{"password"=>nil}}}
I, [2014-10-08T15:57:18.350121 #30531] [attach_disk(vm-3bfd53b7-1bac-44e1-b6a9-87454f9d0f88, disk-e1e99cad-1c98-4096-a78c-4b81ee1509ee)] INFO -- : Attaching disk
I, [2014-10-08T15:57:20.381994 #30531] [attach_disk(vm-3bfd53b7-1bac-44e1-b6a9-87454f9d0f88, disk-e1e99cad-1c98-4096-a78c-4b81ee1509ee)] INFO -- : Finished attaching disk
This is what my console says:
Started deploy micro bosh > Mount disk. Done (00:00:07)
Done deploy micro bosh > Updating persistent disk (00:00:17)
Started deploy micro bosh > Stopping agent services. Done (00:00:01)
Started deploy micro bosh > Applying micro BOSH spec/usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/deployer/instance_manager/vsphere.rb:32:in `[]': no implicit conversion of String into Integer (TypeError)
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/deployer/instance_manager/vsphere.rb:32:in `update_spec'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/deployer/instance_manager.rb:380:in `block in apply'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/deployer/instance_manager.rb:85:in `step'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/deployer/instance_manager.rb:378:in `apply'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/deployer/instance_manager.rb:146:in `create'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/deployer/instance_manager.rb:98:in `block in create_deployment'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/deployer/instance_manager.rb:92:in `with_lifecycle'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/deployer/instance_manager.rb:98:in `create_deployment'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli_plugin_micro-1.2732.0/lib/bosh/cli/commands/micro.rb:179:in `perform'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli-1.2732.0/lib/cli/command_handler.rb:57:in `run'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli-1.2732.0/lib/cli/runner.rb:56:in `run'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli-1.2732.0/lib/cli/runner.rb:16:in `run'
from /usr/local/rvm/gems/ruby-2.0.0-p576/gems/bosh_cli-1.2732.0/bin/bosh:7:in `<top (required)>'
from /usr/local/rvm/gems/ruby-2.0.0-p576/bin/bosh:23:in `load'
from /usr/local/rvm/gems/ruby-2.0.0-p576/bin/bosh:23:in `<main>'
from /usr/local/rvm/gems/ruby-2.0.0-p576/bin/ruby_executable_hooks:15:in `eval'
from /usr/local/rvm/gems/ruby-2.0.0-p576/bin/ruby_executable_hooks:15:in `<main>'
root#vmt-cf-01:/bosh/deployments#
I am not getting enough info to help my googleing. Any ideas?
thanks

Confirmed, this from Amit fixed my issue.
... In particular I'd guess that your apply_spec.properties.vcenter looks like an array instead of a hash. It's confusing because under cloud.properties.vcenters it looks the same, but there it should be an array. The difference is whether the appropriate line says - host: some_address or host: some_address (without the - to indicate array).

Related

Viewport not connecting in Ubuntu Server VM

I am migrating a Redmine plugin that implements user authentication via EWS. The plugin was tested on Redmine v4.x running on an Ubuntu Desktop VM and was working correctly (could tell if the given credentials were valid or not).
The main part of the plugin is:
require 'viewpoint'
include Viewpoint::EWS
defaultServer = 'https://company.mail.server/ews/exchange.asmx'
defaultEmailDomain = '#domain.com'
emailAddress = "username" + defaultEmailDomain
password = "password"
client = Viewpoint::EWSClient.new(defaultServer, emailAddress, password)
result = client
begin
client.folders
rescue
result = 'nope'
end
puts result
This code works on both the previous VM and my Windows machine, but on my new Ubuntu Server 22.04 VM returns 'nope'.
I also tried to write a version in Python using exchangelib, which worked on the new VM. IMO that indicates that the problem is not related to any network constrictions Ubuntu Server might have.
Any suggestions?
Update:
Following Richard's suggestion I saved the error message captured by rescue. After changing the error type to EwsError, I got the following:
/usr/lib/ruby/3.0.0/openssl/digest.rb:35:in `initialize': Digest initialization failed: initialization error (OpenSSL::Digest::DigestError)
from /usr/lib/ruby/3.0.0/openssl/digest.rb:35:in `block (3 levels) in <class:Digest>'
from /usr/lib/ruby/3.0.0/openssl/digest.rb:41:in `new'
from /usr/lib/ruby/3.0.0/openssl/digest.rb:41:in `block (3 levels) in <class:Digest>'
from /var/lib/gems/3.0.0/gems/rubyntlm-0.6.3/lib/net/ntlm.rb:149:in `ntlm_hash'
from /var/lib/gems/3.0.0/gems/rubyntlm-0.6.3/lib/net/ntlm.rb:162:in `ntlmv2_hash'
from /var/lib/gems/3.0.0/gems/rubyntlm-0.6.3/lib/net/ntlm/message/type2.rb:73:in `response'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient/auth.rb:563:in `block in get'
from /usr/lib/ruby/3.0.0/mutex_m.rb:78:in `synchronize'
from /usr/lib/ruby/3.0.0/mutex_m.rb:78:in `mu_synchronize'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient/auth.rb:537:in `get'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient/auth.rb:97:in `block in filter_request'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient/auth.rb:95:in `each'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient/auth.rb:95:in `filter_request'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient.rb:1231:in `block in do_get_block'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient.rb:1230:in `each'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient.rb:1230:in `do_get_block'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient.rb:1019:in `block in do_request'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient.rb:1133:in `protect_keep_alive_disconnected'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient.rb:1014:in `do_request'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient.rb:856:in `request'
from /var/lib/gems/3.0.0/gems/httpclient-2.8.3/lib/httpclient.rb:765:in `post'
from /var/lib/gems/3.0.0/gems/viewpoint-1.1.1/lib/ews/connection.rb:103:in `post'
from /var/lib/gems/3.0.0/gems/viewpoint-1.1.1/lib/ews/connection.rb:81:in `dispatch'
from /var/lib/gems/3.0.0/gems/viewpoint-1.1.1/lib/ews/soap/exchange_web_service.rb:212:in `do_soap_request'
from /var/lib/gems/3.0.0/gems/viewpoint-1.1.1/lib/ews/soap/exchange_data_services.rb:503:in `find_folder'
from /var/lib/gems/3.0.0/gems/viewpoint-1.1.1/lib/ews/folder_accessors.rb:45:in `folders'
from /home/jdredd/auth_source_ews/app/models/test.rb:27:in `<main>'
Additional info: the Windows test machine, where the user authentication runs succesfully, has the same gem versions as above. The only difference is the verion of Ruby itself (3.0.2p107 on Ubuntu, 3.1.2p20 on Windows).
Update:
After modifying openssl.cnf according to this diff enabling loading legacy providers, the plugin works now.
Try investigating the error message.
begin
client.folders
rescue StandardError => err
puts err
result = 'nope'
end
https://thoughtbot.com/blog/rescue-standarderror-not-exception

How to run Prometheus Ruby Client

I want to run the Prometheus Ruby Client, to gather statistics values and to save in the Prometheus database.
I've followed the instructions here : Rack middleware
https://github.com/prometheus/client_ruby#rack-middleware
I've installed two gems, prometheus and prometheus-client.
The exporter.rb (https://github.com/prometheus/client_ruby/blob/master/lib/prometheus/middleware/exporter.rb) and the collector.rb (https://github.com/prometheus/client_ruby/blob/master/lib/prometheus/middleware/collector.rb) is saved in the location: prometheus/middleware
I've saved the config.ru (https://github.com/prometheus/client_ruby#rack-middleware) in the local folder.
Then I've started the rack web server with: rackup -d config.ru -I /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/prometheus-client-0.6.0/lib -I /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/quantile-0.2.0/lib
The -I include statement is necessary to let find the required files.
Then I got this error :
/home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/prometheus-client-0.6.0/lib -I /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/quantile-0.2.0/lib
nil
Exception `ArgumentError' at /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:86 - wrong number of arguments (given 2, expected 1)
Exception `ArgumentError' at /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:49 - wrong number of arguments (given 2, expected 1)
Exception `ArgumentError' at /home/sven/.rbenv/versions/2.3.3/bin/rackup:22 - wrong number of arguments (given 2, expected 1)
/home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/deflater.rb:20:in `initialize': wrong number of arguments (given 2, expected 1) (ArgumentError)
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:86:in `new'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:86:in `block in use'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:134:in `block in to_app'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:134:in `each'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:134:in `inject'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:134:in `to_app'
from /home/sven/StarPerfMonitor_v2.0.0/config.ru:13:in `<main>'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:49:in `eval'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:49:in `new_from_string'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:40:in `parse_file'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:277:in `build_app_and_options_from_config'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:199:in `app'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:314:in `wrapped_app'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:242:in `start'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:141:in `start'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/bin/rackup:4:in `<top (required)>'
from /home/sven/.rbenv/versions/2.3.3/bin/rackup:22:in `load'
from /home/sven/.rbenv/versions/2.3.3/bin/rackup:22:in `<main>'
It seems you are using client_ruby 0.6.0 whereas Prometheus::Middleware is available only for client_ruby 0.7.0.
Check https://github.com/prometheus/client_ruby/tree/v0.6.0
This issue was too tricky, and I decided to switch over to InfluxDB.
And I was able to run the Ruby Client within minutes. It seems to be much more better for me, than Prometheus. Sorry.

AWS Codedeploy failed during Install: UnknownError "\xCC" from ASCII-8BIT to UTF-8

I have tried to troubleshoot an UnknownError returned by the CodeDeploy Agent on an Amazon Linux EC2 instance. I push files from my local git repo on my Mac to a S3 bucket, and deploy from there to the EC2 instance.
I have edited the /etc/codedeploy-agent/conf/codedeployagent.yml and set :verbose: to true on a EC2 instance. I tried to deploy again and open codedeploy-agent.log at /var/log/aws/codedeploy-agent.
The last lines in log before failing shows that the agent installs ELB scripts provided by AWS.
2015-06-19 08:09:13 DEBUG [codedeploy-agent(7637)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandBuilder: Copying /opt/codedeploy-agent/deployment-root/c6b25857-8911-4f61-8b30-b39f0c34c395/d-6UZ0VFID9/deployment-archive/scripts/stop_server.sh to /var/www/html/scripts/stop_server.sh
2015-06-19 08:09:13 DEBUG [codedeploy-agent(7637)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandBuilder: Copying /opt/codedeploy-agent/deployment-root/c6b25857-8911-4f61-8b30-b39f0c34c395/d-6UZ0VFID9/deployment-archive/scripts/register_with_elb.sh to /var/www/html/scripts/register_with_elb.sh
2015-06-19 08:09:13 DEBUG [codedeploy-agent(7637)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Calling PutHostCommandComplete: "Code Error"
2015-06-19 08:09:13 INFO [codedeploy-agent(7637)]: [Aws::CodeDeployCommand::Client 200 0.084236 0 retries] put_host_command_complete(command_status:"Failed",diagnostics:{format:"JSON",payload:"{\"error_code\":5,\"script_name\":\"\",\"message\":\"\\\"\\\\xCC\\\" from ASCII-8BIT to UTF-8\",\"log\":\"\"}"},host_command_identifier:"WyJjb20uYW1hem9uLmFwb2xsby5kZXBsb3ljb250cm9sLmRvbWFpbi5Ib3N0Q29tbWFuZElkZW50aWZpZXIiLHsiZGVwbG95bWVudElkIjoiQ29kZURlcGxveS9ldS13ZXN0LTEvUHJvZC9hcm46YXdzOnNkczpldS13ZXN0LTE6NzMzNTE3MzY5MDAyOmRlcGxveW1lbnQvZC02VVowVkZJRDkiLCJob3N0SWQiOiJhcm46YXdzOmVjMjpldS13ZXN0LTE6NzMzNTE3MzY5MDAyOmluc3RhbmNlL2ktZWRjYTkzNDciLCJjb21tYW5kTmFtZSI6Ikluc3RhbGwiLCJjb21tYW5kUG9zaXRpb24iOjQsImNvbW1hbmRBdHRlbXB0IjoxfV0=")
The last files installed are not related. Since I also have tried to remove the scripts I mention above. The error seems to be upstream and Ruby related.
2015-06-19 08:09:13 ERROR [codedeploy-agent(7637)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Error during perform: Encoding::UndefinedConversionError - "\xCC" from ASCII-8BIT to UTF-8 - /opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/install_instruction.rb:165:in `encode'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/install_instruction.rb:165:in `to_json'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/install_instruction.rb:165:in `to_json'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:38:in `block in install'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:37:in `open'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:37:in `install'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_executor.rb:103:in `block in <class:CommandExecutor>'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_executor.rb:51:in `execute_command'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_poller.rb:123:in `process_command'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_poller.rb:56:in `perform'
/opt/codedeploy-agent/lib/instance_agent/agent/base.rb:28:in `run'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:38:in `block in run'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:55:in `with_error_handling'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:37:in `run'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:70:in `block in run_with_error_handling'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:55:in `with_error_handling'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:69:in `run_with_error_handling'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:33:in `block in start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:22:in `loop'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:22:in `start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:198:in `block in spawn_child'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:196:in `fork'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:196:in `spawn_child'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:188:in `block in spawn_children'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:187:in `times'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:187:in `spawn_children'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:133:in `start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:36:in `block in start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:35:in `fork'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:35:in `start'
/opt/codedeploy-agent/bin/codedeploy-agent:37:in `block (2 levels) in <main>'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/command_support.rb:130:in `call'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/command_support.rb:130:in `execute'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:262:in `block in call_command'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:275:in `call'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:275:in `call_command'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:69:in `run'
/opt/codedeploy-agent/bin/codedeploy-agent:84:in `<main>'
I have tried $ grep --color -in -r '\xCC' /my/folder/ which returns something like
Binary file /my/folder/a.png matches
But also returned /my/folder/wp-content/plugins/wordpress-seo/admin/class-metabox.php:348:'Ì'
So I removed the plugin and tried to convert the filenames from ASCII to UTF-8 with convmv (it didn't convert anything). But without success.
I have also updated several gems according to a couple of StackOverflow threads.
How could I mitigate this error? I find the error message from Amazon CodeDeploy vaugue and hard to troubleshoot and I've run out of ideas.
Issue looks to be LANG env has not been set when Installing / Starting CodeDeploy.
I found that if I were to restart CodeDeploy via the CLI then the app would deploy without issue.
You can check the LANG env of the codedploy process by running
ps auxe |grep codede
We deploy CodeDeploy via puppet and have to set (environment => 'LANG=en_US.UTF-8') when running the install script.
Try updating codedeploy-agent. It worked for me.
SSH into your instance and run this command:
sudo /opt/codedeploy-agent/bin/install auto
The LANG environment variable must be defined when the deployment starts or else the CodeDeploy install event fails.
You can ensure that CodeDeploy has it by editing the CodeDeploy agent service configuration:
sudo vim /etc/init.d/codedeploy-agent
You can export the variable when the service first starts with this line: export LANG="en_US.UTF-8".
So the start block will look like this:
start() {
echo -n $"Starting $prog:"
export LANG="en_US.UTF-8"
cd $AGENT_ROOT
nohup $BIN start >/dev/null </dev/null 2>&1 # Try to start the server
exit $?
}
Some additional notes
For me the problem was only occurring during an auto scale event. In other words I could manually launch the instance and then deploy just fine, but not right when a new instance was launched. This indicates a race condition in the sense that the environment is not ready as soon as the service starts. I tried changing the upstart timing by running:
update-rc.d -f codedeploy-agent remove
update-rc.d codedeploy-agent start 99 2 3 4 5 . stop 20 0 1 6 .
but this did not work. Setting the variable in the start block guaranteed that it was available in time.
To ensure you have all required environment variables available to CodeDeploy as soon as it starts it's probably wise to follow Amazon's advice:
we recommend that you keep the agent service in a stopped state and use the launch scripts to start the agent service

watir-webdriver with firefox 6.0 see following error Errno::ECONNREFUSED

Currently run 150 plus scenarios nightly approximately 5000 steps. I see the following error occur around 10 times in the 5000 steps. Not a lot, nor on the same step, however don't know what to do to fix. Currently wrapping in a rescue block and retrying to work around error.
Any suggestions would be great.
Thanks,
Jim
Environment:
Windows 2003 Server 32 bit
FireFox 6.0.2
Ruby 1.8.7
watir-webdriver 0.3.4
selenium-webdriver 2.7.0
watir-page-helper 0.3.0
Errno::ECONNREFUSED: No connection could be made because the target machine actively refused it. - connect(2)
Stack trace:
G:/Ruby187/lib/ruby/1.8/net/http.rb:560:in `initialize'
G:/Ruby187/lib/ruby/1.8/net/http.rb:560:in `open'
G:/Ruby187/lib/ruby/1.8/net/http.rb:560:in `connect'
G:/Ruby187/lib/ruby/1.8/timeout.rb:53:in `timeout'
G:/Ruby187/lib/ruby/1.8/timeout.rb:101:in `timeout'
G:/Ruby187/lib/ruby/1.8/net/http.rb:560:in `connect'
G:/Ruby187/lib/ruby/1.8/net/http.rb:553:in `do_start'
G:/Ruby187/lib/ruby/1.8/net/http.rb:542:in `start'
G:/Ruby187/lib/ruby/1.8/net/http.rb:1035:in `request'
./features/support/../../lib/pages/base_page_class.rb:37:in `initialize'
./features/support/env.rb:147:in `new'
./features/support/env.rb:147:in `on'
./features/support/env.rb:143:in `visit'
./features/step_definitions/login_steps.rb:32:in `/^A user logs into Connect using (new|existing) rid using correct environment dictated by environment variable$/'
features\ReservationDailyView.feature:6:in `And A user logs into Connect using existing rid using correct environment dictated by environment variable'
One thing to note, I am closing the browser after each scenario and opening it up again at start of the next scenario.
If I leave the browser open instead I get this error and my firefox instance is totally running out of memory 600,000+ K VM Size 700,000+ K
Timeout::Error: execution expired
Stack trace:
G:/Ruby187/lib/ruby/1.8/timeout.rb:64:in `rbuf_fill'
G:/Ruby187/lib/ruby/1.8/net/protocol.rb:134:in `rbuf_fill'
G:/Ruby187/lib/ruby/1.8/net/protocol.rb:116:in `readuntil'
G:/Ruby187/lib/ruby/1.8/net/protocol.rb:126:in `readline'
G:/Ruby187/lib/ruby/1.8/net/http.rb:2028:in `read_status_line'
G:/Ruby187/lib/ruby/1.8/net/http.rb:2017:in `read_new'
G:/Ruby187/lib/ruby/1.8/net/http.rb:1051:in `request'
G:/Ruby187/lib/ruby/1.8/net/http.rb:1037:in `request'
G:/Ruby187/lib/ruby/1.8/net/http.rb:543:in `start'
G:/Ruby187/lib/ruby/1.8/net/http.rb:1035:in `request'
./features/support/env.rb:148:in `call'
./features/support/env.rb:148:in `on'
Looks like you are running out of ephemeral ports. You might want to change settings in the registry to use more ports. Refer below
http://msdn.microsoft.com/en-us/library/aa560610(v=bts.20).aspx

Soap4r : the requested address is not valid in the its context

I was wondering if somebody has seen this error before?
C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient/session.rb:675:in `initialize': The requested address is not valid in its context. - connect(2) (://:0) (Errno::EADDRNOTAVAIL)
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient/session.rb:675:in `new'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient/session.rb:675:in `create_socket'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient/session.rb:632:in `connect'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient/timeout.rb:128:in `timeout'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient/session.rb:631:in `connect'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient/session.rb:522:in `query'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient/session.rb:147:in `query'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient.rb:953:in `do_get_block'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient.rb:765:in `do_request'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient.rb:848:in `protect_keep_alive_disconnected'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient.rb:764:in `do_request'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient.rb:666:in `request'
from C:/Ruby/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient.rb:596:in `post'
from C:/Ruby/lib/ruby/gems/1.8/gems/soap4r-1.5.8/lib/soap/streamHandler.rb:238:in `send_post'
from C:/Ruby/lib/ruby/gems/1.8/gems/soap4r-1.5.8/lib/soap/streamHandler.rb:172:in `send'
from C:/Ruby/lib/ruby/gems/1.8/gems/soap4r-1.5.8/lib/soap/rpc/proxy.rb:179:in `route'
from C:/Ruby/lib/ruby/gems/1.8/gems/soap4r-1.5.8/lib/soap/rpc/proxy.rb:143:in `call'
from C:/Ruby/lib/ruby/gems/1.8/gems/soap4r-1.5.8/lib/soap/rpc/driver.rb:181:in `call'
from (eval):6:in `preRepairAuthorizationQA'
from C:/documents and settings/ngorbikoff/Desktop/GMW/WSDL/ProcessMessageClient.rb:21
I'm trying to connect to a service, I just generated this soap client from wsdl2ruby. Everything went fine. So I have no idea why this error is happening. This is a fresh install of ruby 1.8.7 on Windows, but I tested this on another Windows machine with Ruby 1.8.6 and on a Debian server with REE 1.8.7 - same error. My gut feeling is that it has to do with the httpclient lib - but I can't find anything on google - regarding this err, other than some references to Pythong and tcl - which seem to be unrelated. Also I'm trying to connect to wsdl service that is on httpS - but I didn't have this problem before and there were no changes on the server.
Does anyone have any insight?
OK nevermind people. For anyone else looking into this cryptic message if you are using wsdl2ruby - make sure that you define your endpoint_url in the WhateverServiceClient.rb file generated by the wsdl3ruby.

Resources