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
Related
I have very bad internet, so I want to download the api(mongodb, react, nodejs) I need to work on a project on a local computer, tell me if this can be done?
You could probably play with "npm cache add some-package.tar.bz2" or with npm-proxy but it will probably require too much effort (or will not resolve all issues).
Alternative way would be to setup proxy server(for example squid) to keep once downloaded files localy at your server/computer.
This way you configure your system (and tools) to use yours proxy server.
So when vagrant, apt, npm, grunt or some other tool need some file from internet during the build it will download it only once and get it out of the cache of proxy server during subsequent requests.
majority of tools favour environment variables HTTP_PROXY and HTTPS_PROXY.
So you could setup docker container, virtual machine or just service (squid has windows binaries as well) and configure your system to use proxy server, i.e. add environment variables either globaly or in bash file for build process only.
Lets suppose you configured your squid at docker container with IP address 172.17.0.34. then your build script would look like:
#!/bin/bash
export HTTP_PROXY=172.17.0.34:3128
export HTTPS_PROXY=172.17.0.34:3128
npm install
For it to take global effect you could place these two lines into your /etc/environment file:
HTTP_PROXY=172.17.0.34:3128
HTTPS_PROXY=172.17.0.34:3128
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 have a bash script that I want to be executed before apache starts or restarts.
I want my bash script to be executed when apache starts during the bootup process and when I manually run "/etc/init.d/apache2 restart/start".
There is an init.d script "/etc/init.d/apache2" but I rather not touch that file.
Google is not very helpful :)
Because of the way /etc/init.d/apache2 is written, you can't hijack it by putting your script ahead of apache2ctl in the PATH and modifying or renaming /usr/sbin/apache2ctl would be more likely to get undone during an update. So that leaves you with a choice of modifying /etc/init.d/apache2 or magic.
It may be that the magic comes in the form of creating a symlink to your script in the appropriate /etc/rc?.d directories with an appropriate prefix that would cause it to run before Apache. On my system, the name might be S88scriptname, for example. You can make these links individually for each runlevel and manage them manually or, on systems such as Debian and Ubuntu that support it, you can model your script after /etc/init.d/skeleton and set the options in the LSB header appropriately (particularly the X-Start-Before keyword, perhaps) and use update-rc.d to manage the rc?.d symlinks for you.
When I am in my dept's server, I cannot use commands such as "apt-get install nethack". I have to build the nethack from Binary files to get it working, at least so I have been told. I cannot understand the reason. Why do I need to build things from binaries? Why is the use of the commands, such as "apt-get", forbidden? Why do I not need Root access to build from binaries?
apt-get is a system-level command that installs packages for all users.
If you download and compile, you are only creating local "copies" of the binaries, not system-wide. If you tried to complete the install process with make install this would most likely fail because you do not have sufficient privileges to install the program for all users' access (same reason you can't run apt-get install)
When you compile a program from source, you can give it the '--prefix=~/'. This causes it to install relative to your own home directory (so binary programs typically end up in '~/bin', man pages in '~/man' etc). This poses no problems because you already have permission to write here.
Apt-get on the other hand installs the packages in the global filesystem ('/bin/', '/usr/bin/', etc), which can impact other users and so, quite rightly, require administrative access.
If you want to install some program you can use the command
apt-get source app-name
This will work even if you are not root since it only fetch the source code to the app-name and put it in the current directory, which is easier than having to track down the source and there is a better chance to get it work, since you download the version that should work on your system.
Alternatively you should bug your sysadmin to install the programs you need, since it is his job (and if you need them, chances are that the rest of your team does too).
Because apt-get will install a program system wide.
The locations to which apt-get writes installed files (/bin, /usr/bin, ...) are restricted to root access. I imagine that when you build from source you're not executing the install step of the bulid. You're going to need to set a prefix for the installation such that the packages end up somewhere you can write. This thread talks a bit about setting prefixes for apt-get and you'll probably want to set your prefix to something like
~/software/
and then add the resulting bin directories to your PATH.
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.