Currently i have DirectAdmin installed on Apache.
I want to install OpenLiteSpeed with CustomBuild 2.0 by DirectAdmin.
./build update
./build set webserver openlitespeed
./build set mod_ruid2 no
./build set php1_mode lsphp
./build openlitespeed
./build php n
./build rewrite_confs
If i install it, my apache will stopped automatically?
and all files httpd in DirectAdmin in File Editor was deleted or useless?
If I unistall Apache, DirectAdmin will was crash?
You're on the right track.
If you install Openlitespeed, Apache will be stopped and removed automatically. All configurations are also directly converted and no other step is needed other than what you mentioned in your post. Do not try to uninstall Apache directly.
You can safely run these commands, but there are a few important points:
After converting apache to openlitespeed it will no longer be possible to return to Apache safely.
You cannot change any settings using WebAdmin in DirectAdmin. The settings need to be made manually via the configuration file in the shell.
When you access WebAdmin from Openlitespeed with DirectAdmin you will notice that it is not possible to change any settings there. (read-only). To modify the OLS settings you need to modify the files that are informed in the link
https://openlitespeed.org/kb/directadmin-configuration-files/
Related
The installation guide of Stackify states that we have to modify the catalina.sh of tomcat file to add the java agent. But in a spring-boot app, where can I find the tomcat location to modify the file.
I changed the application.properties file to set the custom location for tomcat by setting server.tomcat.basedir.
How can I change the catalina.sh file now?
Should be able to do the command cd $CATALINA_HOME/bin to get to the folder that contains the catalina.sh. After that you can add CATALINA_OPTS="$CATALINA_OPTS -javaagent:enter_path_stackify_apm_jar" to it.
I have a scala application that needs to perform sys.process operations with sudo and these operations are failing for me. From my google searching, it appears that I may be able to resolve this by running intellij with sudo. However, when I do this, I'm prompted to import settings and need would need to re-import my project. This seems less than ideal. Is there a way to set up a run configuration in intellij to have sudo privileges or at least run idea.sh with sudo but use my original workspace, so that all changes and configurations are shared between the sudo and non-sudo profiles?
Presumably this is down to Intellij reading its settings from a directory under the current user directory, eg C:\Users\matt.IntelliJIdea13 on my Windows PC. When you sudo, it will try and read its setting from a different directory.
I would check with directory it is trying to save its config to when you run it with sudo. Then set up a soft link from this directory back to your normal user directory. IntelliJ should then read the same set of files whether or not you are using sudo.
eg ln -s /home/matt/.IntellijIdea13 /home/root/.IntelliJIdea13
I haven't got IntelliJ installed on Linux so can't check this.
I have a project with several sub-directories. Everything works just fine, except if I try to access files inside the /root/javascript directory, I get a 404. The files do in fact exist, and I am in fact typing the path correctly. If I simply rename the directory I can then access the files. Rename it back, and I get the 404 again. VHost file works fine. No .htaccess files involved.
Apache version: 2.4.9
OS: Ubuntu 13.10
After much searching and trying different things, here's what the problem came down to:
By default, Apache 2.4 on Ubuntu enables a config file called javascript-common, which redirects any requests to files inside /javascript (that is, a directory at the root of your project called 'javascript') to /usr/share/javascript.
Solution 1
Use the following command to disable the javascript-common configuration file:
a2disconfig javascript-common
Solution 2
Add your JavaScript files inside that /usr/share/javascript directory. That way Apache will actually find those files and no 404 will be returned. One benefit of doing things this way is that you won't need multiple copies of the same files (jquery.js, etc.js) that multiple projects use...
Solution 3
Delete the directory /usr/share/javascript, and create a symbolic link that points to your project's /javascript directory. Keep in mind that if you have more than one project (vhost file), they will all serve from the same JavaScript file from the original project. In other words, this is probably not the best solution...
The a2disconfig solution didn't work for me, but then through some searching, I realized that the javascript-common is something that can be uninstalled.
So I fixed the problem by removing javascript-common:
sudo apt-get remove javascript-common
I'm not sure the point of this package, or why it would be installed automatically, but I'm glad that my javascript files are loading again!
I am running Ubuntu 14.04.1 LTS with the lamp-server bundle
Encountering the same problem, I found a similar answer resolved it.
sudo a2disconf javascript-common
sudo service apache2 restart
After the a2disconf (and note it is apparently now a2disconf and not a2disconfig)
I did get a message to execute "sudo service apache2 reload"
the reload did not resolve the issue... thus the restart
as an aside -- I cannot imagine what the developers were thinking when they loaded this little gem -- some of my javascript files might be viable across domains... but certainly not all !
You could just override /javascript alias in your .conf to reflect what you want:
Alias /javascript /my_custom_dir
I installed apache httpd on my linux vm and wanted to start it's service. BUt I'm getting error (13)Permission denied. Error retrieving pid file run/httpd.pid I realised that I do not have this file. Not even a var directory. Any solutions for this? Pardon me, this is my first time touching servers.
I installed the apache like this:
gzip -d httpd-2.2.21.tar.gz
tar xvf httpd-2.2.21.tar
./configure --prefix=/home/Hend/Desktop/Server
make
make install
You have several alternatives for this:
Install apache in user directory, run as non-root user
This is the way you started doing that. But then you'll have to:
Add some customizations to the start script, or at least pass it enough environment variables to tell him where configuration / pidfile / etc. are
Modify the whole apache configuration, since the default uses directories to which you don't have access. For example, you should put your DocumentRoot somewhere else thant /var/www
Run the server on a non-standard port. Since unprivileged users cannot run services on ports lower than 1024, you must run apache on another port, such as 8000 instead of 80. But this way, all your URLs will look like http://example.com:8000 instead of http://example.com.
Install apache from sources, into /usr/local
You can install apache in the default path for non-part-of-distro stuff, that is /usr/local instead of /usr/. That is, use --prefix=/usr/local/ when running configure.
This way, things should be much simpler. In any case, you'll have to run the webserver from root, and configure it to change user only after socket is opened.
Install apache from sources, into /usr/
You can also install apache in its default location, usint --prefix=/usr/. This way things should be much simpler, it should install init scripts in the usual location /etc/init.d/apache2 or /etc/init.d/httpd, configuration in /etc/apache2 etc.
Beware that doing this all the apache installed files will conflict with the ones of the version provided by your linux distribution!
Install apache from your distribution package manager
A part from the case in which you want particular setups (for example with non-standard patches), particular non-packaged versions (not recommended, since usually versions packaged with distros are guaranteed to be stable, others are not).
Benefits of doing this:
Avoid huge setup + configuration process to make it work
Versions from your distro should be "guaranteed" to be stable and tested with all the other programs shipped with it. Not always the latest version is better.
Each time a new release is updated (or more importantly, there is a security update), you can upgrade it semi-automatically by running a single upgrade command, without worrying about things going wrong during update.
This way the whole installation is just matter of a couple commands.
For example, on debian:
apt-get install apache2
On fedora:
yum install httpd
etc.
Then, if the service is not already started by package manager, you can start it with
/etc/init.d/apache2 start
or
/etc/init.d/httpd start
Job done. Now just put stuff in /var/www/ (or equivalent directory, depends on distro) and see it through you web server.
You have to start apache as root
Have you read the docs in the source distribution?
ie INSTALL
less INSTALL
For complete installation documentation, see [ht]docs/manual/install.html or
http://httpd.apache.org/docs/2.2/install.html
$ ./configure --prefix=PREFIX
$ make
$ make install
$ PREFIX/bin/apachectl start
As part of our product release we ship Apache HTTP Server binaries that we have compiled on our (UNIX) development machine.
We tell our clients to install the binaries (on their UNIX servers) under the same directory structure that we compiled it under. For some clients this is not appropriate, e.g. where there are restrictions on where they can install software on their servers and they don't want to compile Apache themselves.
Is there a way of compiling Apache HTTP Server so its installation location(s) can be specified dynamically using environment variables ?
I spent a few days trying to sort this out and couldn't find a way to do it. It led me to believe that the Apache binaries were hard coding some directory paths at compilation preventing the portability we require.
Has anyone managed to do this ?
I think the way to do(get around) this problem is to develop a "./configure && make" script that your client uses to install, specify and compile the binaries. That would offcourse require that the client has all the source-code installed on his server or you can make it available on an NFS share.
If you are compiling Apache2 for a particular location but want your clients to be able to install it somewhere else (and I'm assuming they have the same architecture and OS as your build machine) then you can do it but the apachectl script will need some after-market hacking.
I just tested these steps:
Unpacked the Apache2 source (this should work with Apache 1.3 as well though) and ran ./configure --prefix=/opt/apache2
Ran make then sudo make install to install on the build machine.
Switch to the install directory (/opt/apache2) and tar and gzip up the binaries and config files. I used cd /opt/apache2; sudo tar cf - apache2 | gzip -c > ~/apache2.tar.gz
Move the tar file to the target machine. I decided to install in /opt/mynewdir/dan/apache2 to test. So basically, your clients can't use rpm or anything like that -- unless you know how to make that relocatable (I don't :-) ).
Anyway, your client's conf/httpd.conf file will be full of hard-coded absolute paths -- they can just change these to whatever they need. The apachectl script also has hard coded paths. It's just a shell script so you can hack it or give them a sed script to convert the old paths from your build machine to the new path on your clients.
I skipped all that hackery and just ran ./bin/httpd -f /opt/mynewdir/dan/conf/httpd.conf :-)
Hope that helps. Let us know any error messages you get if it's not working for you.
I think the way to do(get around) this problem is to develop a "./configure && make" script that your client uses to install, specify and compile the binaries. That would offcourse require that the client has all the source-code installed on his server or you can make it available on an NFS share.
Not to mention a complete build toolchain. These days, GCC doesn't come default with most major distributions. Wouldn't it be sane to force the client to install it to /opt/my_apache2/ or something like that?
#Hissohathair
I suggest 1 change to #Hissohathair's answer.
6). ./bin/httpd -d <server path> (although it can be overridden in the config file)
In apacheclt there is a variable for HTTPD where you could override to use it.