When following the tutorial to install openAM, one of the steps is to create a web agent using the command
agentadmin.exe --i
But I get stuck on the second step:
Configuration file [c:\Apache\conf\httpd.conf]: c:\xampp\apache\conf\httpd.conf
init_ssl(): ssleay32.dll is not available (error: 193)
init_ssl(): libeay32.dll is not available (error: 193)
I've tried downloading openssl from gnuwin32, also from slproweb, with or without placing those files inside \web_agents\apache24_agent\lib. Even looking on another web I found that I should replace ssleay32.dll, libeay32.dll and openssl.exe from \xampp\apache\bin and I did that.
The "Troubleshooting" section of openAM asks for installing KB2533623 , but when I try to install it from the .msu my system says that this is already installed.
All without success.
Any suggestion?
Try patching KB2758857 since it replaces KB2533623. Also, just to ensure it isn't a PATH issue with the user you're logged in as, find those two OpenSSL dll's and copy them to your system folder (c:\windows\system32) [https://msdn.microsoft.com/en-us/library/7d83bc18.aspx]. Last, I would be sure you're using the latest OpenAM Web Policy Agent [4.0.0].
I'm trying to push a gem to hosted Artifactory and am encountering problems every step of the way.
My environment is:
Operating System: Windows 7 x64 Professional
Ruby: ruby 1.9.3p545
I had to do a trick with cacert.pem to add the artifactory url to my list of sources, but that part is working now. The next step in Artifactory documentation is to get an api key and pipe it to ~/.gem/credentials.
When I do that the api key downloads successfully, but gem completely breaks.
gem
C:/ruby193/lib/ruby/1.9.1/psych.rb:203:in `parse': (<unknown>): control characters are not allowed at line 1 column 1 (Psych::SyntaxError)
from C:/ruby193/lib/ruby/1.9.1/psych.rb:203:in `parse_stream'
from C:/ruby193/lib/ruby/1.9.1/psych.rb:151:in `parse'
from C:/ruby193/lib/ruby/1.9.1/psych.rb:127:in `load'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:253:in `load_file'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:223:in `load_api_keys'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:208:in `initialize'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:78:in `new'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:78:in `do_configuration'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:51:in `run'
I can't even use gem as long as the credentials file is there, so I have to remove it.
If I try to push without the credentials file and using the --host option, gem seems to ignore the --host options.
gem push .\my_gem-0.0.1.0.beta.gem --host $artifactory.source
Enter your RubyGems.org credentials.
Don't have an account yet? Create one at http://rubygems.org/sign_up
Email:
Password:
Pushing gem to https://rubygems.org...
HTTP Basic: Access denied.
This is a proprietary gem, so publishing to rubygems.org is NOT an option. There definitely seems to be a problem with my environment, but I've been unable to figure out what it is--and none of the other documentation of SO questions seem to be on point.
I know that I'm going to need to get gem to read the credentials file to push successfully, but it seems like a more basic issue that gem is ignoring the --host parameter.
It took a lot of effort, but I think I've resolved my issues. It was a problem in 2 parts.
Solution Part 1
With respect to the issue of gem ignoring the --host option, this is resolved by updating gem.
Apparently the version of gem that ships with ruby 1.9.3v545 on Windows is broken. After updating gem it acted like it was trying to upload to the correct url.
Solution Part 2
The second issue involves a corrupted credentials file. What's happening here is that when piping the output from the curl command into the credentials file, the credentials file is being encoded with Unicode. To resolve this I used a slightly different curl command (in powershell)
curl $url | Out-File ~/.gem/credentials -Encoding "ASCII"
Now I'm able to upload the gem successfully.
If the SSL_CERT_FILE environment variable trick doesn't work, you can also try editing your .gemrc file as follows:
:ssl_ca_cert: C:\\path\\to\\cacert.pem
How would one install a Ruby VM (JRuby, Ruby MRI, etc.) on a machine that doesn't have internet access?
I'd like to just drop the tar.gz file somewhere that RVM is able to see (or checks before it goes out and tries to retrieve the package itself). Any ideas?
This blog post explains that you can drop the source archive in your $HOME/.rvm/archives directory.
cp ruby-enterprise-1.8.7-2010.02.tar.gz /home/minhajuddin/.rvm/archives
rvm install ree-1.8.7
Or the docs say that you can specify the archives directory from the command line:
--archives - directory for downladed files (~/.rvm/archives/)
Question 828421 asked similar question, but received only one real answer (update rubygems) and that attempt results in the same error.
Ruby version 1.9.1.p243 on Windows. Included Gem, version 1.3.5.
Never installed any gems before; never did any special config for this Ruby.
Ruby itself works, as does irb, and "gem" operates but can't do install (and maybe other ops).
Tried this (from a book):
gem install rspec
Got this:
ERROR: http://gems.rubyforge.org/ does
not appear to be a repository
ERROR: While executing gem ...
(Gem::RemoteFetcher::FetchError)
SocketError: getaddrinfo: The storage control blocks were destroyed.
(http://gems.rubyforge.org/yaml)
When I go to that URL (without "yaml") using MSIE7, I get a page titled "Gemcutter | awesome gem hosting" and have no problem wandering around that site. So I don't -think- it's a proxy problem (though this is all from inside corporate firewall/proxies/etc).
When I go to that URL -with- "yaml", it goes to "http://production.s3.rubygems.org/yaml" and shows what I assume is an update specification page, starting with this:
--- !ruby/object:Gem::SourceIndex
I didn't destroy any "storage control blocks". So what is preventing gem from installing a gem?
Web search shows MANY people having this same problem over a long span of time, but I have yet to see anyone say "It's because of THIS, so do THIS to fix it." Well, someone suggested updating "gem", but trying that gets same error.
Help please?
Your browser might be using system-wide proxy settings or some sort of automatic configuration. The gem command probably doesn't. I'm behind an university proxy and I can't install/update any gems normally, but can access everything with my browser. To install gems, I normally create a tunnel to my server so I can bypass the proxy server.
This might help you to configure the proxy settings for the gem command: How do I update Ruby Gems from behind a Proxy (ISA-NTLM)
Sample:
sudo gem install nifty-generators -p http://proxy:port
It works well.
If your proxy requires authentication, then use:
gem install --http-proxy http://USERNAME:PASS#HOST:PORT gem_name
This can "at times" mean that for some reason rubygems.org is down currently, and so your local "invisible proxy" is returning you a 404 or what not.
#Tomas Markauskas didn't work for me because i'm not behind a proxy. And I didn't find a solution anywhere, I tried disable my AV and firewall, didn't
This was the solution for me:
gem install rails -r -w -p
Hope this will help people with the same problem.
EDIT: I have Windows 7 64bit.
I'm trying to install some Ruby Gems so I can use Ruby to notify me when I get twitter messages. However, after doing a gem update --system, I now get a zlib error every time I try and do a gem install of anything. below is the console output I get when trying to install ruby gems. (along with the output from gem environment).
C:\data\ruby>gem install twitter
ERROR: While executing gem ... (Zlib::BufError)
buffer error
C:\data\ruby>gem update --system
Updating RubyGems
ERROR: While executing gem ... (Zlib::BufError)
buffer error
C:\data\ruby>gem environment
RubyGems Environment:
- RUBYGEMS VERSION: 1.2.0
- RUBY VERSION: 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
- INSTALLATION DIRECTORY: c:/ruby/lib/ruby/gems/1.8
- RUBY EXECUTABLE: c:/ruby/bin/ruby.exe
- EXECUTABLE DIRECTORY: c:/ruby/bin
- RUBYGEMS PLATFORMS:
- ruby
- x86-mswin32-60
- GEM PATHS:
- c:/ruby/lib/ruby/gems/1.8
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- REMOTE SOURCES:
- http://gems.rubyforge.org/
Found it! I had the same problem on windows (it appeared suddenly without me doing an update, but whatever):
It has something to do with multiple conflicting zlib versions (I think).
In ruby/lib/ruby/1.8/i386-msvcrt, make sure that there exists a zlib.so file. In my case, it was already there. If not, you may try to install ruby-zlib.
Then go to ruby/lib/ruby/site_ruby/1.8./i386-msvcrt and delete the zlib.so file there.
In ruby/bin, there should be a zlib1.dll. For some reason my Ruby version did not use this dll. I downloaded the most recent version (1.2.3) and installed it there. I had to rename it to zlib.dll for it to be used.
And tada! Rubygems worked again.
Hope this helps.
Firstly, I thank the person, who came up with the solution to the missing zlib problem. (It wasn't me. :-)
Unfortunately I lost the link to the original posting, but the essence of the solution on Linux is to compile the Ruby while zlib header files are available to the Ruby configure script. On Debian it means that zlib development packages have to be installed before one starts to compile the Ruby.
The rest of my text here does not contain anything new and it is encouraged to omit it, if You feel comfortable at customizing Your execution environment at UNIX-like operating systems. The following is a combination of a brief intro to some basics and step by step instructions.
------The-start-of-the-HOW-TO-------------------------
If one wants to execute a program, let's say, irb, from a console, then the file named irb is searched from folders in an order that is described by an environment variable called PATH. It's possible to see the value of the PATH by typing to a bash shell (and pressing Enter key):
echo $PATH
For example, if there are 2 versions of irb in the system, one installed by the "official" package management system, let's say, yum or apt-get, to /usr/bin/irb and the other one that is compiled by the user named scoobydoo and resides in /home/scoobydoo/ourcompiledruby/bin then the question arises, which one of the two irb-s gets executed.
If one writes to the
/home/scoobydoo/.bashrc
a line like:
export PATH="/home/scoobydoo/ourcompiledruby/bin:/usr/bin"
and restarts the bash shell by closing the terminal window and opening a new one, then by typing irb to the console, the
/home/scoobydoo/ourcompiledruby/bin/irb gets executed. If one wrote
export PATH="/usr/bin:/home/scoobydoo/ourcompiledruby/bin"
to the
/home/scoobydoo/.bashrc
,then the /usr/bin/irb would get executed.
In practice one wants to write
export PATH="/home/scoobydoo/ourcompiledruby/bin:$PATH"
because this prepends all of the values that the PATH had prior to this assignment to the /home/scoobydoo/ourcompiledruby/bin. Otherwise there will be problems, because not all common tools reside in the /usr/bin and one probably wants to have multiple custom-built applications in use.
The same logic applies to libraries, except that the name of the environment variable is LD_LIBRARY_PATH
The use of the LD_LIBRARY_PATH and PATH allow ordinary users, who do not have root access or who want to experiment with not-that-trusted software, to build them and use them without needing any root privileges.
The rest of this mini-how-to assumes that we'll be building our own version of ruby and use our own version of it almost regardless of what is installed on the system by the distribution's official package management software.
1)=============================
First, one creates a few folders and set the environment variables, so that the folders are "useful".
mkdir /home/scoobydoo/ourcompiledruby
mkdir -p /home/scoobydoo/lib/our_gems
One adds the following 2 lines to the
/home/scoobydoo/.bashrc
export PATH="/home/scoobydoo/ourcompiledruby/bin:$PATH"
export GEM_HOME="/home/scoobydoo/lib/our_gems"
Restart the bash shell by closing the current terminal window and opening a new one or by typing
bash
on the command line of the currently open window.
The changes to the /home/scoobydoo/.bashrc do not have any effect on terminal windows/sessions that were started prior to the saving of the modified version of the /home/scoobydoo/.bashrc
The idea is that the /home/scoobydoo/.bashrc is executed automatically at the start of a session, even if one logs on over ssh.
2)=============================
Now one makes sure that the zlib development packages are available on the system. As of April 2011 I haven't sorted the details of it out, but
apt-get install zlibc zlib1g-dev zlib1g
seems to be sufficient on a Debian system. The idea is that both, the library file and header files, are available in the system's "official" search path. Usually apt-get and alike place the header files to the /usr/include and library files to the /usr/lib
3)=============================
Download and unpack the source tar.gz from the http://www.ruby-lang.org
./configure --prefix=/home/scoobydoo/ourcompiledruby
make
make install
4)=============================
If a console command like
which ruby
prints to the console
/home/scoobydoo/ourcompiledruby/bin/ruby
then the newly compiled version is the one that gets executed on the command
ruby --help
5)=============================
The rest of the programs, gem, irb, etc., can be properly executed by using commands like:
ruby `which gem` install rake
ruby `which irb`
It shouldn't be like that but as of April 2011 I haven't figured out any more elegant ways of doing it. If the
ruby `which gem` install rake
gives the zlib missing error again, then one should just try to figure out, how to make the zlib include files and library available to the Ruby configure script and recompile. (Sorry, currently I don't have a better solution to offer.)
May be a dirty solution might be to add the following lines to the
/home/scoobydoo/.bashrc
alias gem="`which ruby` `which gem` "
alias irb="`which ruby` `which irb` "
Actually, I usually use
alias irb="`which ruby` -KU "
but the gem should be executed without giving the ruby the "-KU" args, because otherwise there will be errors.
------The-end-of-the-HOW-TO------------------------
I just started getting this tonight as well. Googling turned up a bunch of suggestions that didn't deliver results
gem update --system
and some paste in code from jamis that is supposed to replace a function in package.rb but the original it is supposed to replace is nowhere to be found.
Reinstalling rubygems didn't help. I'm reinstalling ruby right now.........and it is fixed. Pain though.
How about cd into rubysrc/ext/zlib, then ruby extendconf.rb, then make, make install.
After do that, reinstall ruby.
I did this on ubuntu 10.04 and was successful.
A reinstall of Ruby sorted this issue out. It's not what I wanted; I wanted to know why I was getting the issue, but it's all sorted out.
It most often shows up when your download failed -- i.e. you have a corrupt gem, due to network timeout, faulty manual download, or whatever. Just try again, or download gems manually and point gem at the files.
if gem update --system not works and rename ruby/bin/zlib1.dll to zlib.dll not helps try:
Open file RUBY_DIR\lib\ruby\site_ruby\1.8\rubygems.rb
And replace existed def self.gunzip(data) by this:
def self.gunzip(data)
require 'stringio'
require 'zlib'
data = StringIO.new data
# Zlib::GzipReader.new(data).read
data.read(10) # skip the gzip header
zis = Zlib::Inflate.new(-Zlib::MAX_WBITS)
is = StringIO.new(zis.inflate(data.read))
end
Try updating ZLib before you do anything else. I had a similar problem on OS X and updating Compress::Zlib (a Perl interface to ZLib) cured it - so I think an old version of ZLib (is now 1.2.3) may be where your problem lies...
install pure ruby zlib if all else fails