I recently installed Apache/2.4.6 from source. At present the MPM module enabled is mpm_event_module. I want to enable the prefork mpm, but not sure from where to do that.
I am aware of changing the mpm module from /etc/sysconfig/httpd in case of the apache installed using yum. But in my case as the installinon is from source, I could not not do the same.
I tried recompiling apche using './configure --prefix=/usr/local/apache --enable-module=prefork' , but the mpm is still mpm_event_module. Clearly the issue is with defining prefork as the mpm.
I could also see that the installation directory has the prefork.c module. There must be a way to define it as the mpm.
Could someone please help.
In versions prior to 2.4, you cannot change the MPM of the binary Apache2 installation at run-time.
You have to compile Apache with the desired MPM using the --with-mpm=MODULE NAME command line option to the config script. To change MPM, the binary must be rebuilt.
You can determine which MPM Apache2 is currently built with by executing apache2 -l or httpd -l on the command line.
Brief but very clear documentation on this:
http://httpd.apache.org/docs/2.2/mpm.html
In version 2.4, you can also build MPMs as dynamic modules which allows changing the MPM at run-time.
http://httpd.apache.org/docs/2.4/mpm.html#dynamic
Related
I am trying to build the C driver of MongoDB afetr I have build MongoDB and started it.
On github, I have found that I need root privileges to build it (I need to run it with sudo).
Is it possible to do it without sudo ?
The instructions there state
make
sudo make install
So you ARE building as a normal user, but of course, installing it will require root privileges.
On a side note: using DESTDIR will install with a prefix the binaries don't know about. Software installed with DESTDIR is typically not runnable from the place it is installed. If you want to install in a non-standard location, do it at build-time (e.g. if the project uses autotools, pass a --prefix=/home/foo/mytree to ./configure).
DESTDIR is only useful for creating packages. I use my own little package manager implemented in perl for managing installations in the /usr/local tree. It works by setting DESTDIR to /usr/local/pkg/<product_name> with make install and then symlinking everything to its correct location.
I have just now realised that I can change the installation directory while installing using DESTDIR as a destination directory.
In my case it would look like this: make DESTDIR=new_path install
I am trying to install CKAN on my local computer using Ubuntu 14.04 LTS.
I followed the instructions for installing from source found here and I try to check if solr is running by visiting http://localhost:8983/solr/.
I can see that Jetty is running because when I visit http://localhost:8983 I see that it is up.
I added the jdk as follows:
JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk-amd64
I am getting a 500 error when i try to open the solr page:
HTTP ERROR 500
Problem accessing /solr/index.jsp. Reason:
JSP support not configured
Powered by Jetty://
Any ideas? Should I redo the whole thing from the start?
Edit/Update
I just couldn't do anything with this installation. The bigger problem was that installation files were meshed up! I tried to install tomcat/solr instead of jetty/solr and things went sour. So I just created a VM and did a fresh install there. For anyone interested I did a tomcat/solr installation following this and a CKAN installation following this (with out of course the solr instructions). Also, for some reason the CKAN installation has commented out the solr URL, so even if it is right, I had to delete the comment.
A fix has been documented by #mstantoncook here [2939] & [1651] How to solr-jetty JSP support
Note the last comment, sudo service jetty restart
It's a Jetty BUG on Ubuntu 14.04!
There is nothing wrong with Ckan itself.
Actually, there is a bug in the libjetty-extra-java package (version 6.1.26 and newer) in Ubuntu 14.04. The bug was introduced after Jetty (in Ubuntu) has changed it's dependences from libtomcat6-java to libtomcat7-java.
You can get more info about this bug in Ubuntu Launchpad: Bug #1508562 "Broken symlinks for JSP support in libjetty-extra-java version 6.1.26-1ubuntu1.1".
The bug is already fixed on Debian, and I'm hope it will be solved in Ubuntu 14.04 soon.
There are workarounds that may work for your case
I proposed some workarounds in this bug report, and since they can be useful for the Ckan users, I'll also replicate them here.
All of them consist on use both jetty and libtomcat7-java, but adding/replacing some classes (code ported from libtomcat6, in put in the jsp-2.1-6.0.2.jar file) to the Jetty classpath.
I don't know if they have some problem. Use them at your own risk!
Workaround 1 - Install the fix package proposed by vshn
I found this workaround here: https://github.com/ckan/ckan/pull/2966
In short:
wget https://launchpad.net/~vshn/+archive/ubuntu/solr/+files/solr-jetty-jsp-fix_1.0.2_all.deb
dpkg -i solr-jetty-jsp-fix_1.0.2_all.deb
service jetty restart
This will install a JSP jar that works (the file will be named jsp-2.1-6.0.2.jar, but it contains classes ported from libtomcat6).
Workaround 2 - Manually install the JSP jar
Download the same JAR file that the DEB package above would install.
wget https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/1508562/+attachment/4785985/+files/jsp-2.1-6.0.2.jar
Now, move it to a proper location inside the Jetty config dir. I did it this way:
mkdir /etc/jetty/extra-jars
mv jsp-2.1-6.0.2.jar /etc/jetty/extra-jars
And add a line like this one in the Jetty start.config file:
echo "/etc/jetty/extra-jars/jsp-2.1-6.0.2.jar" >> /etc/jetty/start.config
And:
service jetty restart
Correct solution
The correct solution is to wait for the Ubuntu Team solution. However, while waiting for this fix, you can use any of the previous workarounds (I prefer the last one).
I hope they help you!
Try this steps:
sudo mv jsp-2.1-6.0.2.jar /usr/share/jetty/lib/.
change own:
sudo chown root:root /usr/share/jetty/lib/jsp-2.1-6.0.2.jar
finally restart jetty:
sudo service jetty restart
I followed this steps and now I can see localhost:8983/solr and localhost/solr/admin
In Ubuntu 14.04 this can be fixed with:
cd /tmp
wget https://launchpad.net/~vshn/+archive/ubuntu/solr/+files/solr-jetty-jsp-fix_1.0.2_all.deb
sudo dpkg -i solr-jetty-jsp-fix_1.0.2_all.deb
sudo service jetty restart
Following http://docs.ckan.org/en/ckan-1.6/solr-setup.html#single-solr-instance
(this one a bit old, but worked perfect for me )
You will have to edit /etc/profile and add this line to the end such as this to the end (adjusting the path for your machine’s jdk install:
JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64/ (or other version)
then
export JAVA_HOME
sudo service jetty start
I am following this tutorial: https://wiki.opendaylight.org/view/Getting_started
I am trying to use the following code in opendaylight using karaf
ovs-vsctl show
But the command window says Command not found: ovs-vsctl
I have installed all the necessary libraries and the local host server (http://localhost:8181/dlux/index.html) is running fine. But somehow odl can't find ovs.
Can anyone tell me what's the error? I am running win 8.
Thank you
You need to run this command outside of karaf terminal.
Firstly, you should have ovs(Open Virtual Switch) or Mininet installed, and then create one or two open switches.
Basically, you started the SDN controller in karaf, and now in the step you are encountering problem, the switches need to be assigned ODL controller as their manager.
You must check also that ovsdb is already installed in karaf.
For that, try to execute the next command:
feature:list | grep ovsdb
That command will display all the ovsdb components/features that are available in your karaf distribution. The third column will indicate you if a given component is already installed or not (if you see an X, that means that the component is installed). If you want to install a component/feature:
feature:install <name_of_the_feature>
After that, try to execute it outside of karaf, as Sidhant01 has indicated you before.
Try to do it with sudo:
sudo ovs-vsctl show.
If you want to configure ovsdb in an active mode:
tools-vm:~$ sudo ovs-vsctl set-manager tcp:127.0.0.1:6640
tools-vm:~$ sudo ovs-vsctl show
98d8cf7a-44b1-4b02-a60c-7d832409d06f
Manager "tcp:127.0.0.1:6640"
is_connected: true
ovs_version: "2.0.2"
Cheers
Here is the problem:
I have packaged my Java application into a single jar using the Maven plugin One-Jar.
Now I want to run the application as a Unix Daemon using JSVC, i.e. Apache Commons Daemon.
I am using JSVC as follows (which works for Jars made with the Maven assembly plugin, etc):
jsvc -user $USER -home $HOME -pidfile $PID_PATH -cp $PATH_TO_ONE_JAR my.package.MyClass
The error is this:
jsvc.exec error: Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader
jsvc.exec error: Service exit with a return value of 1
Does anyone know if it is even possible to use JSVC and One-Jar together, since One-Jar uses a custom class loader? The jar runs just fine when I run java -jar my-one-jar.jar.
What can be done?
Thank you for any insight!
I had to add all jars dependencies to the classpath option from jsvc. It seems jsvc doesn't use the jars inside another jar
If you use the (poorly-documented) Maven Shade Plugin instead of One-jar (they can achieve similar results as each other), it should solve your problems. It unpacks the dependent jars and stores the class files directly in the fat Jar (rather than having jars within the jar). I have used it to create an executable jar for running under JSVC with some success.
Of course, things are seldom as simple as they sound. With the Shade plugin, you may have to do some work to relocate classes when there are conflicts in your dependency tree, or use resource transformers to handle your non-Java resource files. But hopefully not.
(Of course Mkyong.com has a guide on this)
I am manually building httpd-2.2.17 from the source. Just to make sure I have the configuration options right, I checked the latest CENTOS apache srpm (which is for httpd-2.2.3). In the httpd.spec I find this line:
# forcibly prevent use of bundled apr, apr-util, pcre
rm -rf srclib/{apr,apr-util,pcre}
I was wondering why this is required ? What's wrong with using the apr included within the default httpd source ?
Was wondering why this is required ?
To prevent the bundled apr/pcre libraries to be used and possibly installed. RedHat/CentOS would rather want to ship a standalone package of the apr and pcre libraries.
Whats wrong with using the apr included within apache ?
You might get out of sync regarding the apr/apr-util/pcre versions that apache bundleds vs the apr/apr-utl/pcre libraries that CentoS/RHEL packages. I.e. you want to ship one particular release of pcre from http://www.pcre.org/ (+ perhaps custom patches) that several packages can use , not just apache, and you want apache to build against that library instead of the one apache bundle.
Removing those directories, and it's a safe bet building apache won't pick up any of the bundled headers/libraries.