RVM - Ruby integration was extracted to a separate gem (`remove $LOAD_PATH.unshift`) - apache2

I was upgrading to Rails 3.2.6 (ruby 1.9.3-p194) and installing RVM on Debian and using Apache2 server (2.2.19).
I used these very nice instructions: http://dalibornasevic.com/posts/21-rvm-and-passenger-setup-for-rails-2-and-rails-3-apps/
The Apache server configuration /etc/apache2/apache2.conf includes:
LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.3-p194#rails326/gems/passenger-3.0.13/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/rvm/gems/ruby-1.9.3-p194#rails326/gems/passenger-3.0.13
PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.3-p194#rails326/ruby
When I have set everything up (and got rid of tons of errormessages :) the following error message from passenger appears:
RVM - Ruby integration was extracted to a separate gem, it should be installed by default with RVM, remove the $LOAD_PATH.unshift line and all should be fine again.
By commenting out $LOAD_PATH.unshift in MyApp/config/setup_load_paths.rb this error goes away and instead I get a 500 error, Internal Server Error.
/etc/log/apache2/error.log:
[ pid=5262 thr=3075372800 file=ext/apache2/Hooks.cpp:862 time=2012-07-10 12:33:41.475 ]: Unexpected error in mod_passenger: Cannot spawn application '/var/www/MyApp': The spawn server has exited unexpectedly.
Backtrace:
in 'virtual Passenger::SessionPtr Passenger::ApplicationPool::Client::get(const Passenger::PoolOptions&)' (Client.h:742)
in 'Passenger::SessionPtr Hooks::getSession(const Passenger::PoolOptions&)' (Hooks.cpp:294)
in 'int Hooks::handleRequest(request_rec*)' (Hooks.cpp:563)
I would be very pleased if anyone could give me a clue on this problem.
Thank you very much.
Íris

Related

SNMPv3 on OEL8 via Perl Net::SNMP

I'm trying to get SNMPv3 to work on an Oracle Linux 8 server using Net::SNMP and I'm getting the following error message:
SNMPv3 support is unavailable (Required module Crypt/DES.pm not found)
The SNMPv3 command and syntax is all correct (an snmpwalk from CLI works as expected). I'm sure I'm missing some package, but I can't seem to find what I need to get SNMPv3 DES support. The script works like a charm using SNMPv1 or 2 - no issue at all.
I have the following SNMP packages already installed:
net-snmp.x86_64 1:5.8-18.el8_3.1
net-snmp-agent-libs.x86_64 1:5.8-18.el8_3.1
net-snmp-devel.x86_64 1:5.8-18.el8_3.1
net-snmp-libs.x86_64 1:5.8-18.el8_3.1
net-snmp-utils.x86_64 1:5.8-18.el8_3.1
Solved - missing Perl modules:
Crypt::DES
Digest::SHA
Digest::SHA1

Starting jetty fail in ubuntu 14

I install the solr-jetty package in a Ubuntu 14 container running in a cloud9 workspace.
To install the package I run the following command:
sudo apt-get install solr-jetty
The installation doesn't return any error.
Then I try to start solr with the following command:
sudo service jetty start
But I receive the following error:
* Starting Jetty servlet engine. jetty
* Jetty servlet engine started, reachable on http://host-solr-3694477:8983/. jetty
...fail!
In the log file of jetty I get the following message:
failed setting default capabilities.
set_caps(CAPS) failed for user 'jetty'
Service exit with a return value of 4
How can I resolve this issue?
To resolve the problem I had to change the user that run jetty from jetty to root.
This can be configured by editing the /etc/default/jetty file.
I think it is not the more correct solution because it can add security problems. If anyone have a better solution ...
Docker user here, same problem, but - this worked for me (and this is as unadvised as changing the user to 'root', suggested above):
https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities
Set the following on your 'docker run' command when creating a container:
--privileged=true
I'm just using docker for development, so not overly concerned yet with the security implications of this.

Solr: 404 error with getting admin page

I've installed Solr on my Ubuntu to this path
/opt/solr/solr-4.10.2
After installing I started Solr:
sudo bin/solr start from /opt/solr/solr-4.10.2 directory
As I can understand it started successfully
Waiting to see Solr listening on port 8983 [/]
Started Solr server on port 8983 (pid=8385). Happy searching!
But when I try to get to admin page
http://localhost:8983/solr
I got 404 error:
HTTP ERROR: 404
Problem accessing /solr. Reason:
Not Found
Powered by Jetty://
Do you have any suggestion what's going wrong and where to look in order to fix this problem?
Since this error can be caused by a lot of things, you need to access the log file and debug the execution.
First of all, open your Node log file, located in /opt/solr/solr-4.10.2/node1/log and look for something weird (Shift+F for Errors).
Generally, this error occurs when you have a mismatch between the Solr required Java JDK and your current Java JDK.
When I had this problem, I found in the log file the following error message java.lang.UnsupportedClassVersionError: org/apache/solr/servlet/SolrDispatchFilter : Unsupported major.minor version 51.0 and realized the problem was the java version.
To solve this, try to change the current JDK, using the command sudo update-alternatives --config javac.
If the error still occurs, try to uninstall all unused JDK's, because Solr is getting the wrong path.
The final solution to this issue is to open the file /opt/solr/solr-4.10.2/solar.in.sh and edit the SOLR_JAVA_HOME, writing the right JDK path (e.g /usr/lib/jvm/java-1.7.0)
Disclosure: the secret is look in the log file and figure out what is causing the issue.
Cheers.
try:
http://localhost:8983/solr/index.html
[solr's web.xml]
<servlet>
<servlet-name>LoadAdminUI</servlet-name>
<servlet-class>org.apache.solr.servlet.LoadAdminUiServlet</servlet-class>

Capistrano / ubuntu

I'm attempting to set up a staging server in my rails 4 app. When i run 'cap staging deploy', the command aborts with the following error:
The deploy has failed with an error: #<SSHKit::Command::Failed: bundle exit status: 7
bundle stdout: Nothing written
bundle stderr: Nothing written
The 'cap abort' follows:
Could not find font-awesome-sass-4.0.2 in any of the sources
Any ideas for how to find what this means? Font awesome sass 4.0.2 is definitely in my gemfile and installed.
I don't know the root cause of this but I had the same issue with paper_trail, updating to a later version and then redeploying did the trick for me.

Solr + Jetty Gives HTTP 503 on Debian

(This is a cross-post from servefault. I'm posting it here because no one answered my post there, and I feel that this sort of hits an awkward space half-way between both stackoverflow and serverfault.)
I have modified the example project included with Solr for my needs (removing things like the example stopwords and defining my own schema). Running this project on my mac, everything works fine: I can start Jetty and run search queries. But when I push the project out to a Debian system, I get this error when I try to do search queries:
HTTP ERROR: 503
SERVICE_UNAVAILABLE RequestURI=/solr
Powered by jetty://
The request log shows that a request was made:
10.10.124.14 - - [22/06/2010:22:34:52 +0000] "GET /solr
HTTP/1.1" 503 1311
No error log is produced (at least not on in the ./logs directory).
I have tried to run this project both on openjdk and the Sun JRE. Both started jetty fine, but produced the same error when searching. I am running Debian 9.0.4.
The issue is probably that the datastore in Debian is /var/lib/solr/data and you need to set that line in your version solrconfig.xml instead of the default which is in the base directory /usr/share/solr/ which could be a read only file system.
I've packaged the last solr version in Debian Testing. It seems, that there is some error in the solr configuration so that jetty starts, but it can't start the solr servlet. You must look in the jetty error log to find the reason.
There's lack of manpower in Java Packaging for Debian, so it may well be that there is an error in the solr-jetty package.
The solr-jetty package in Debian stable doesn't work as I recall. Please try from Debian testing!
If you indeed find an error, please don't use random forums but post a bug on bugs.debian.org!
Success!

Resources