I am currently migrating to Puppet 4.x. I am running Ubuntu Server 14.04 with Puppet 4.2.3 and Puppetserver 2.1.2. I must add some additional gems to the server and to some agents. Both commands hang indefinitely.
/opt/puppetlabs/bin/puppetserver gem install -V --no-rdoc --no-ri -p http://myproxy.com:8080 rest-client
/opt/puppetlabs/puppet/bin/gem install -V --no-rdoc --no-ri -p http://myproxy.com:8080 rest-client
I get the same behavior when I omit the proxy settings.
When I run the gem installcommand on the same machine from the installed Ruby 1.9.3 environment. Everything works perfectly, so the proxy is working fine:
gem install -V --no-rdoc --no-ri rest-client -p http://myproxy.com:8080
GET http://rubygems.org/latest_specs.4.8.gz
302 Found
GET http://rubygems.global.ssl.fastly.net/latest_specs.4.8.gz
200 OK
GET http://rubygems.org/quick/Marshal.4.8/rest-client-1.8.0.gemspec.rz
302 Found
GET http://rubygems.global.ssl.fastly.net/quick/Marshal.4.8/rest-client-1.8.0.gemspec.rz
200 OK
...
Has anybody an idea how to solve the problem. It becomes a hard blocker for my right now.
I have found the issue... jstack gave me the following trace:
"main" prio=10 tid=0x00007fce4400a000 nid=0x2f89 runnable [0x00007fce4d709000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:272)
at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:551)
at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:139)
at sun.security.provider.SecureRandom$SeederHolder.<clinit>(SecureRandom.java:197)
at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:214)
- locked <0x00000000c34ba1e8> (a sun.security.provider.SecureRandom)
at java.security.SecureRandom.nextBytes(SecureRandom.java:466)
- locked <0x00000000c34ba190> (a java.security.SecureRandom)
at org.jruby.ext.securerandom.SecureRandomLibrary.nextBytes(SecureRandomLibrary.java:49)
at org.jruby.ext.securerandom.SecureRandomLibrary.nextBytes(SecureRandomLibrary.java:42)
at org.jruby.ext.securerandom.SecureRandomLibrary.random_bytes(SecureRandomLibrary.java:21)
at org.jruby.ext.securerandom.SecureRandomLibrary$INVOKER$s$random_bytes.call(SecureRandomLibrary$INVOKER$s$random_bytes.gen)
The problem can be fixed by adding -Djava.security.egd=file:/dev/./urandom to /opt/puppetlabs/server/apps/puppetserver/cli/apps/gem.
Update
A much better solution is to install another tool like havaged that remedies low-entropy conditions. A Puppet module can be found here: https://forge.puppetlabs.com/stm/haveged
Related
I'm on Windows 10 x64 and I've installed JRuby 1.7.8 (I tried the files for x64 and 32bits with the same problem) and JRE 7.
I was trying to have my Cucumber Test Framework running on a different machine. I downloaded my current branch (which is working fine in other computers, with all the settings: env.rb, Gemfile, etc) and then I installed successfully these 2 gems:
gem install bundler
gem install cucumber
The Gemfile I have contains loads of gems, similar to:
source 'https://rubygems.org'
gem "httpclient"
gem "watir-webdriver"
but when I execute:
bundle install
I just get this line and nothing gets installed, it finishes almost immediately. No Gemfile.lock is created, etc.
D:\project>bundle install
io/console not supported; tty will not be manipulated
D:\project>
Any idea what could be wrong and what I could try please?
Not quite sure if the issue has anything to do with the line above (which I had never seen in the other machines that are working). If it's not related and you've got an idea about both problems, please let me know and I'll have a look as well...
I've been trying for a few more hours and still not success, adding further info in case someone can spot something pls. Even 'bundle -v' doesn't work on this machine?!
D:\project>gem list
io/console not supported; tty will not be manipulated
*** LOCAL GEMS ***
builder (3.2.2)
bundler (1.13.2)
cucumber (2.4.0)
cucumber-core (1.5.0)
cucumber-wire (0.0.1)
diff-lcs (1.2.5)
gherkin (4.0.0)
jruby-win32ole (0.8.5)
multi_json (1.12.1)
multi_test (0.1.2)
rake (10.1.0)
D:\project>bundle -v
io/console not supported; tty will not be manipulated
D:\project>
Cheers!!
You have the latest version of bundler 1.13.2 installed and I have seen it cause different types of issues depending on the jruby version and some other gems. Bundler 1.10.6 works everytime for my Jruby 1.7.x.
Try these:
gem uninstall bundler
and
gem install bundler -v 1.10.6
Although I am not particularly familiar with jruby, it appears to be a bug, which is resolved in JRuby 1.7.24.
I would verify that the other computers this is working on are still on that version of jruby (assuming they are windows boxes).
Okay so i just made a fresh install of nodejs package on archlinux using pacman. Command for the same was
sudo pacman -S nodejs npm . Now when i tried to run the same i am getting error as
node: error while loading shared libraries: libicui18n.so.57: Which pretty much means that libicu is either not there or not the correct version. The problem that i am facing is that it is not there in pacman. I tried
sudo pacman -S libicu, which returned not able to find the package. What is the right way to resolve this issue. FYI : just a note, i would prefer not to install from source and prefer using pacman for the same. If there is any other output that you need to know please comment below and will let you know about the same.
I am currently on manjaro i3 fresh install.
Just found out, The name for package in arch linux is icu and not libicu. Once that is installed node will start working fine.
Update
After using node for quite sometime i realised that a better way to install node is using NVM. It would install both node and npm locally and you get the option to manage multiple version.Installation is as simple as
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.32.1/install.sh | bash
This error is caused by installing node js and npm package modules with missing packages that are unsupported by your system how about you try this:
$ sudo pacman -Rsc -n nodejs
$ sudo pacman -Sy nodejs
$ sudo pacman -Sy npm
did you use testing repo?
If you enabled testing repositories, but later on decided to disable them, you should:
Remove/Comment them from /etc/pacman.conf
pacman -Syuu to "rollback" your updates from these repositories.
The second item is optional, but keep it in mind if you notice any problems.
Also you can install stable ver : pacman -S core/icu
You just need to update arch
sudo pacman -Syu
I am attempting to upgrade Docker on CentOS 7 from 1.9 to 1.10. I am using the script provided on the Docker website:
https://docs.docker.com/engine/installation/linux/centos/
I am running the script:
curl -fsSL https://get.docker.com/ | sh
Eventually, the script executes the following command:
sudo -E sh -c 'sleep 3; yum -y -q install docker-engine'
This command is failing with the following message:
Error: docker-engine-selinux conflicts with docker-selinux-1.9.1-25.el7.centos.x86_64
Error: docker-engine conflicts with docker-1.9.1-25.el7.centos.x86_64
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
I have isolated this failure to the yum command, and attempted to run it using the --skip-broken. This doesn't do much, though:
$ sudo yum -y -q --skip-broken install docker-engine
Packages skipped because of dependency problems:
docker-engine-1.10.3-1.el7.centos.x86_64 from docker-main-repo
docker-engine-selinux-1.10.3-1.el7.centos.noarch from docker-main-repo
Trying the rpm command does nothing. Running the referenced rpm command seems to do something, but whatever it does it has no effect on the install. The failure persists.
Internet searches have revealed that others have seen similar problems, but usually their problems come because some dependency, referenced in the failure, was missing. There don't appear to be any missing dependencies on my system.
I even tried removing version 1.9. That does not change anything either.
Following the instructions for a manual install provided on the docker site hasn't changed anything, either.
There is also nothing in the Docker documentation that describes this particular problem.
Has anyone seen this exact problem before? Does anyone know some way to fix it???
Please advise.
From this message:
docker-engine-selinux conflicts with docker-selinux
I suspect you previously had the Red Hat distributed version of Docker installed, which installs docker-selinux. The official Docker packages also install a similar package (docker-engine-selinux) and that conflicts with the package you already have installed.
The best approach would be to uninstall the existing docker version (including the docker-selinux package), and then install docker-engine, following the instructions in the documentation; https://docs.docker.com/engine/installation/linux/centos/
go to run jenkins after doing an upgrade, and get the following:
start jenkins
start: Job failed to start
That's it...nothing shows up in jenkin's log...so it is difficult to debug to say the least.
(and it isn't running already, or anything like that).
Is there another log somewhere that I should be looking at that would be helpful?
(I am assuming answer to this problem will be somewhat iterative, so hopefully someone can start me on a path to debug this)
So, knowing it was a pre-start error allowed me to investigate more deeply.
Further digging allowed me to figure out that the exact line in the /etc/init/jenkins.conf file was one pointing to the /usr/share/jenkins/bin/maintain-plugins.sh
Looking at this location, I found it was not present (ie. no bin directory). This means that jenkins-common was no longer installed for some reason...odd indeed...going into apt-get and doing an install of this component again led to the error:
dpkg error processing /var/cache/apt/archives/jenkins-common_1.409.1-0ubuntu4.2_all.deb ...
having seen this error before and refreshing my memory via google gave the following solution:
dpkg -i --force-overwrite /var/cache/apt/archives/jenkins-common_1.409.1-0ubuntu4.2_all.deb
This allowed the installation of common to proceed as normal. After this, all I had to do was replace the /usr/share/jenkins/jenkins.war with my backed up copy (because ubuntu is far behind the latest release version), and I was able to start the server again.
I am not exactly sure what caused the problem to begin with, but it was likely during an apt-get upgrade/clean process...and because of the weirdness with jenkins conflicting with jenkins-common, it did not repopulate the /usr/share/jenkins directory properly.
regardless, am glad it is working again. :)
Instead, you can run the following before the install to properly clean up any conffiles left by the distro version:
sudo apt-get purge jenkins
Then install the correct version.
Ubuntu 18.04 LTS use Java 9 as default java
Jenkins 2.107.2 still use Java 8
[Solution]
Install Java 8 before install Jenkins
sudo add-apt-repository ppa:webupd8team/java
sudo apt install oracle-java8-installer
wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -
sudo apt-add-repository "deb https://pkg.jenkins.io/debian-stable binary/"
sudo apt install jenkins
See https://stackoverflow.com/a/49937744/900684
I went to see the jenkins logs
tail -f /var/log/jenkins/jenkins.log
In my case it didn't start because I used incompatible java version.
Update and make sure it sees correct java (In my case it should have been opened using JRE 1.7. To check, please use java -version command) and all should work
The following worked for me:
sudo rm /etc/init/jenkins.conf
sudo update-rc.d jenkins defaults
sudo service jenkins start
Then....
root#core:/# service jenkins start
* Starting Jenkins Continuous Integration Server jenkins [ OK ]
Borrowed from: https://groups.google.com/forum/#!msg/jenkinsci-users/eW_yEWLojFc/tFhb8DKoRHUJ
I got from this link: https://serverfault.com/questions/710680/jenkins-not-starting-in-ubuntu
It might be caused by a full disk.
To be really sure, try running it manually. Like this:
/usr/bin/java -Djava.awt.headless=true -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=-1
The console output pretty much speaks for itself:
$ java -jar jruby-complete-1.6.4.jar -S gem install nokogiri --no-rdoc --no-ri
Fetching: nokogiri-1.5.0-java.gem (100%)
Successfully installed nokogiri-1.5.0-java
1 gem installed
11:17:04|dkowis#racktop jruby
$ java -jar jruby-complete-1.6.4.jar -S gem install cucumber --no-rdoc --no-ri
ERROR: While executing gem ... (ArgumentError)
undefined class/module YAML::Syck::DefaultKey
11:18:24|dkowis#racktop jruby
$ java -jar jruby-complete-1.6.4.jar -S gem install cuke4duke --version=0.4.4 --no-rdoc --no-ri
ERROR: While executing gem ... (ArgumentError)
undefined class/module YAML::Syck::DefaultKey
There's a couple gems I can install, but the ones I need, I cannot. Is it a problem with the gem itself? Is it a problem with rubygems? I'm not able to puzzle this one out.
This apparently is a known issue with Rubygems reported here on the JRuby Forum.
There is a pull request to fix this Rubygems error, but you could try build the gems you want locally and correct the dependency statements in the gemspec file yourself. I had ran into the same problem with the i18n-js gem.
Hope this helps.