I've installed Openshift Origin as described in the comprehensive guide on a single box (all in one setup). The problem is, that I can't add my node to a district, therefore it's not possible to use Openshift on that machine.
When I type
oo-admin-ctl-district -c add-node -n Default -i node.example.com
I get
/usr/sbin/oo-admin-ctl-district:215:in 'block in <main>': undefined method 'casecmp' f or nil:NilClass (NoMethodError)
from /usr/sbin/oo-admin-ctl-district:178:in `block in collate_errors'
from /usr/sbin/oo-admin-ctl-district:176:in `each'
from /usr/sbin/oo-admin-ctl-district:176:in `collate_errors'
from /usr/sbin/oo-admin-ctl-district:213:in `<main>'
I tried to pin the problem down, an I think it's because the node doesn't connect to the message queue correctly as oo-mco ping gives me
broker.example.com time=94.30 ms
---- ping statistics ----
1 replies max: 94.30 min: 94.30 avg: 94.30
I checked my config with the comprehensive guide several times, but couldn't find any problem yet. Any help or tipps on this would be greatly appreciated.
Don't know what I am actually doing, but this post did solve my problem so far
http://lists.openshift.redhat.com/openshift-archives/dev/2014-September/msg00087.html
Seems that I had the same issue, and that Openshift Origin comprehensive Depoyment guide needs an update.
Related
I'm suddenly having issues deploying my apps to AWS ECS using the Convox CLI. When I am trying as of Friday, this is what happens:
$ convox deploy -a my-app -r test
Packaging source... OK
Uploading source... OK
Starting build... ERROR: response status 502
This is regardless of rack, and other operations such as "env" and "logs" seem to work. I don't know how to go about trouble shooting this. Is there some switch I can use to get more debug info from the CLI? I am assuming the "502" is an HTTP error code, but I do not know where it is coming from. I've looked around in AWS, but can not seem to find any errors there (however, is not sure where to look).
Any help would be appreciated.
Had the same problem on a rack running a version from 2019. Solved this updating the rack to version 20211019100155 as Brian suggested.
I found this repo with a systemtap script for letting me use QWERTY ctrl-shortcuts on my dvorak layout. Unfortunately, I can't get it to work, but I don't think it has to do with the script itself. I'm running Pop OS and I think that it's because the linux-image I need with all the debug symbols doesn't exist.
The script says I need to install linux-headers-$(uname -r) linux-image-$(uname -r)-dbg
For me, this turns into linux-headers-5.11.0-7620-generic linux-image-5.11.0-7620-generic-dbg
linux-headers-5.11.0-7620-generic exists and I'm able to download it using apt-get.
linux-image-5.11.0-7620-generic-dbg can't be installed using apt-get. I can install
linux-image-5.11.0-7620-generic, but that's not the same thing. I've spent time looking online for it and adding different keys to apt-get, but I haven't been able to find anything with that name. If the problem is not having the correct linux-image package installed, I need help being pointed in the right direction as to where I can get it.
I tried following the directions here, and I've also searched this to no avail. I tried downloading and installing linux-image-4.4.0-142-generic-dbgsym_4.4.0-142.168_amd64.ddeb but that also didn't work.
If this isn't the problem, I've provided the output of the script. Any help is appreciated.
peyton#pop-os:~/scripts$ sudo stap -g -v dvorak-qwerty.stp
Pass 1: parsed user script and 477 library scripts using 116428virt/91336res/7612shr/83628data kb, in 140usr/30sys/168real ms.
semantic error: resolution failed in DWARF builder
semantic error: resolution failed in DWARF builder
semantic error: while resolving probe point: identifier 'module' at dvorak-qwerty.stp:152:7
source: probe module("evdev").function("evdev_events") {
^
semantic error: no match
semantic error: resolution failed in DWARF builder
Pass 2: analyzed script: 2 probes, 0 functions, 1 embed, 0 globals using 119016virt/94812res/8680shr/86216data kb, in 10usr/0sys/7real ms.
Pass 2: analysis failed. [man error::pass2]
Tip: /usr/share/doc/systemtap/README.Debian should help you get started.
Yes, debuginfo downloading has been a pain on many distros. However, if you're running Debian kernels, see: https://wiki.debian.org/Debuginfod for instructions on using a new automated system. Generally: https://sourceware.org/elfutils/Debuginfod.html .
This error arose while I was trying to deploy to aws. It turns out this is an issue on my machine that others are no experiencing.
jkazil#jlk:~/Projects/code/geoq-chef-repo [git master] $ vagrant up --provider=aws
Bringing machine 'default' up with 'aws' provider...
[default] Box 'ubuntu_aws' was not found. Fetching box from specified URL for
the provider 'aws'. Note that if the URL does not have
a box for this provider, you should interrupt Vagrant now and add
the box yourself. Otherwise Vagrant will attempt to download the
full box prior to discovering this error.
Downloading or copying the box...
An error occurred while executing multiple actions in parallel.
Any errors that occurred are shown below.
An error occurred while executing the action on the 'default'
machine. Please handle this error then try again:
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
jlk:~/Projects/code/geoq-chef-repo [git master] $
I found a couple of things on the internets that said I should look at my version of openssl. At first, it was 0.9.8, but I had 1.0.1f in homebrew. So I found this: Update OpenSSL on OS X with Homebrew and followed it. And I was was able to update OpenSSL.
jkazil#jlk:~/Projects/code/geoq-chef-repo [git master] $ openssl version
OpenSSL 1.0.1f 6 Jan 2014
jlk:~/Projects/code/geoq-chef-repo [git master] $
But that didn't fix the issue. Just to clarify, this is not an aws issue, but an me issue. Here is me trying to pull a machine down locally. I am using the insecure flag to try to push it through, but it didn't work with or without.
jkazil#jlk:~/Projects/code/geoq-chef-repo [git master] $ vagrant box add dummy https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box --insecure
Downloading or copying the box...
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
jlk:~/Projects/code/geoq-chef-repo [git master] $
Lastly, I wanted to share my PATH, just in case someone had that question.
jlk:~/Projects/code/geoq-chef-repo [git master] $ echo $PATH
/usr/local/Cellar/ruby/2.0.0-p247/bin:/Users/jkazil/bin:/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
jlk:~/Projects/code/geoq-chef-repo [git master] $
Any suggestions?
This is going to be sad answer, but the resolution to this was to update to 10.9. Then the problem went away. I know that this is not the answer that people want to here, but I thought I would try after banging my head against the wall for awhile.
Thank you everyone for your help!
P.S. VAGRANT_LOG=info was help also in getting set up.
I found a couple of things on the internets that said I should look at my version
of openssl. At first, it was 0.9.8, but I had 1.0.1f in homebrew. So I found this:
OpenSSL Version MacOSX Homebrew and followed it. And I was was able to update OpenSSL.
Mac OS X will do as much as it can to load 0.9.8 in /usr/lib:
$ find /usr/ -iname libssl*
/usr//lib/libssl.0.9.7.dylib
/usr//lib/libssl.0.9.8.dylib
/usr//lib/libssl.dylib
You will need to ensure you are loading the expected version of OpenSSL. If you can get it under gdb, issue info shared and see what version of OpenSSL actually loaded.
A few things about OS X and its linker: (1) it ignores rpath's; (2) it ignores requests like -Bstatic; (3) more generally, it always links to the shared object if available (even on iOS where the only thing you are suppose to use is an archive); (4) LD_PRELOAD is not honored.
You might have some luck with using DYLD_LIBRARY_PATH.
If you can't get OS X to use 1.0.1f, then you will have to re-build the components in question. But instead of specifying -L/usr/local/ssl -lssl -lcrypto, you will need to omit the flags and specify the full archive like /usr/local/ssl/lib/libssl.a (without the -l).
Don't buy into the claims you don't have to do these things on OS X (claims like "use -L and -lssl because that's what your suppose to use"). I suffered them for years on Apple's gear, and I know for certain it does not work (and the people making the claims apparently don't use OS X). OS X is a real bastard at times.
One cause for this error could be an old version of OpenSSL trying to connect to a server which uses HTTPS with SNI:
http://sourceforge.net/p/curl/bugs/1037/?limit=10&page=1#aa7f
Try setting the log level higher (e.g. VAGRANT_LOG=debug vagrant up – see the Vagrant debugging guide) to see the URL in question and test it by hand using curl to confirm the failure.
I have an application running in OpenShift Origin. It has been running for some time and now I have an update for the cartridge it uses.
When I try to update cartridge, script fails.
[root#broker ~]# oo-admin-upgrade --upgrade-node node1 --login admin --app-name app1 --version 1.0 --upgrade-gear 52231466a6577a242f00015d
/usr/sbin/oo-admin-upgrade:76:in `rescue in upgrade_gear': Can only supply discovery data if direct_addressing is enabled (RuntimeError)
["/opt/rh/ruby193/root/usr/share/ruby/mcollective/rpc/client.rb:438:in `discover'", "/opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-msg-broker-mcollective-1.13.0.1/lib/openshift/mcollective_application_container_proxy.rb:2173:in `rpc_exec'", "/usr/sbin/oo-admin-upgrade:49:in `block in upgrade_gear'", "/opt/rh/ruby193/root/usr/share/ruby/timeout.rb:69:in `timeout'", "/usr/sbin/oo-admin-upgrade:41:in `upgrade_gear'", "/usr/sbin/oo-admin-upgrade:611:in `<main>'"]
Output:
Migrating gear on node with: /usr/sbin/oo-admin-upgrade --login 'admin' --upgrade-gear '52231466a6577a242f00015d' --app-name 'app1' --version '1.0'
Upgrading on node...
from /usr/sbin/oo-admin-upgrade:24:in `upgrade_gear'
from /usr/sbin/oo-admin-upgrade:611:in `<main>'
Do I do something wrong or it is a bug in the script?
I believe you're probably one of the first people attempting to use oo-admin-upgrade in their origin installation. This looks like the mcollective command to the node to upgrade the gear timed out. Please make sure mcollective is correctly configured by running 'mco ping' - you should see responses from all nodes in your cluster.
That said, the upgrade-node option is not designed to be used by end-users. Please use:
oo-admin-upgrade --version 1.0
This should apply upgrades for all apps in your cluster.
I am working my way through the RhoMobile tutorial http://docs.rhomobile.com/rhoconnect/command-line#generate-an-application and I at the point of entering
rake redis:install
I get the following error.
WARNING: using the built-in Timeout class which is known to have issues when use
d for opening connections. Install the SystemTimer gem if you want to make sure
the Redis client will not hang.
See http://redis.io/ for information about redis.
Installing redis to C:\RhoStudio\redis-2.4.0;C:\dropbox\code\InstantRhodes\redis
-1.2.6-windows.
rake aborted!
Zip end of central directory signature not found
Tasks: TOP => redis:install => redis:download
(See full trace by running task with --trace)
D:\Dropbox\code\rhodes-apps\storeserver>
I am working on a Whindows machine, primarily using RhoStudio.
It ended up being an environmental variables issue. Also, it seems the main support forum for Rhodes is the Google Group. Question answered here:
https://groups.google.com/d/topic/rhomobile/b-Adx2FDMT8/discussion
If you are using Rhostudio in windows then redis is automatically installed with Rhostudio.
So no need of installing it again.