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.
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 set up a local Perl web environment on my Windows machine. The application I'm working on is originally from a Linux server, and so the shebang for source .pl files look like so:
#!/usr/bin/perl
This causes the following error on my Windows dev machine:
(OS 2)The system cannot find the file specified.
Is it possible to change my Apache 2 conf so that the shebang is ignored on my Windows machine? Of course I could set the shebang to #!c:\perl\bin\perl.exe, that much is obvious; but the problem comes to deploying the updated files. Clearly it would be very inconvenient to change this back on each deploy. I am using ActivePerl on Windows 7.
Update:
I should have mentioned that I need to keep the shebang so that the scripts will work on our shared hosting Linux production server. If I did not have this constraint and I didn't have to use the shebang, the obvious answer would be to just not use it.
I use #!/usr/bin/perl in my scripts and configure Apache on Windows to ignore the shebang line. Add
ScriptInterpreterSource Registry-Strict
to your httpd.conf and set up the Windows Registry key as explained in the Apache docs.
Here is what I get when I export the key:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command]
#="c:\\opt\\perl\\bin\\perl.exe"
I have been using this setup with Apache and ActiveState Perl on my Windows laptop and the Apache and Perl distributions that come with ArchLinux on my server.
The Apache docs (to which I linked above) state:
The option Registry-Strict which is new in Apache 2.0 does the same thing as Registry but uses only the subkey Shell\ExecCGI\Command. The ExecCGI key is not a common one. It must be configured manually in the windows registry and hence prevents accidental program calls on your system. (emphasis mine)
There is no portable shebang line. Even on the same platform and architecture, someone might have installed perl is a different location.
The trick is to not install modules and scripts by hand. When you package everything as distributions and use the module toolchain, the shebang lines are modified automatically to point to the perl you used to install everything. You shouldn't have to think about these details. :)
I use #! /usr/bin/env perl as the shebang on all of my perl, whether on *nix or Windows. Windows just ignores it, and the Unixen follow env to the chosen perl disto.
The way I had this working was to copy perl.exe to c:/usr/bin/ and rename it to perl (strip the .exe)
In win7 and up you can also do this with the "dos" command mklink.
Start a cmd shell as administrator and do something like the following:
mklink /d c:\usr c:\Perl # Activestate perl in c:\Perl\bin\perl.exe
mklink /d c:\usr c:\xampp\perl # Xampp perl in c:\xampp\perl\bin\perl.exe
Install any Windows Bash flavor (such as Cygwin, MSYS2 or GnuWin32);
Create a trivial redirecting shell script:
exec "#"
Create a registry entry:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command]
#="<path-to-sh> <path-to-script>"
[HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command]
#="<path-to-sh> <path-to-script>"
[HKEY_CLASSES_ROOT\.py\Shell\ExecCGI\Command]
#="<path-to-sh> <path-to-script>"
(...and so on.)
Jot in your httpd.conf file:
ScriptInterpreterSource Registry
Apache will now resolve Unix shebangs relative to the interpretation given by your choosen Bash flavor. This gives much more flexibility than hardcoding interpreter paths in the registry.
I don't have Windows handy, but perlcritic says:
my $desc = q{Found platform-specific perl shebang line};
my $expl = q{Perl source in parrot should use the platform-independent shebang line: #! perl};
So, I guess #! perl should work.
Edit: doesn't work on linux; apparently works in parrot, although I don't see how they manage that.
How to use Linux shebang (#!/usr/bin/perl) when running Perl based web-site with {site-name} on localhost in Windows 10?
This works for me:
XAMPP on localhost\{site-name} (C:\xampp\htdocs\{site-name})
independently installed Strawberry Perl (C:\Perl\perl\bin) because Perl included in XAMPP package is not satisfactory
In default configuration you must use this shebang:
#!C:\perl\perl\bin\perl.exe -IC:\xampp\htdocs\{site-name}
Is it possible to include directory (after -I switch) permanently to #INC?
Yes, you can do it by setting the PERLLIB or PERL5LIB environment variables. This works when running perl script from command line, but surprisingly it is ignored by apache server in XAMPP. However one of #INC directories (C:/Perl/perl/site/lib) is usually empty so you can make symbolic link to your web-site directory:
mklink /D c:\perl\perl\site\lib C:\xampp\htdocs\{site-name}
Now, you can use this shebang:
#!C:\perl\perl\bin\perl.exe
Moreover, you can create directory c:\usr\bin
md c:\usr\bin
and copy perl.exe from C:\perl\perl\bin\
copy C:\perl\perl\bin\perl.exe c:\usr\bin\perl.exe
(Another mklink trick is not working here from some reasons.)
Finally, you can use Unix-styled shebang on Windows:
#!/usr/bin/perl
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
I get the following error in Terminal when I try to install mod_perl:
Please tell me where I can find your apache src
[../apache_x.x/src]
I've tried using cpan > install mod_perl(even forcing v. 2) AND I've tried just downloading it, and doing $ perl Makefile but they both lead to the same error.
I'm trying to follow steps from http://bulknews.net/lib/mod_perl_guide/install.html or Oreilly's CGI Programming with Perl but the site says:
The first thing first is to download the Apache source code and unpack it into a directory -- the name of which you will need very soon
Mac comes with Apache, which is why I don't want to download it. But how can I find the apache src???
Update: Haven't checked, but did find apache2 folder in ~/private/var/log
Additional Info --- separate locations of mod_perl files:
I have an unzipped folder: mod_perl-1.31 in my ~/Downloads folder. (for manual install)
I found tar.gz files of mod_perl -1 and -2 in ~/G/GO/GOZER/mod_perl-1.31.tar.gz (or 2.04) (for cpan)
Should I delete these?
Let me know if there is any other info required to solve this, or if I somehow missed a post with this same question. Thanks a lot.
It's quite possible that Mac OS X doesn't ship with the apache source code (I'll be damned if I can find it.) I can find no references to it online or on my machine.
I am going to ignore the built-in Apache installation and install my own. This article discusses PHP and Apache on Mac OS X but I'll also be using mod_perl on my system and will adjust as necessary: http://www.phpied.com/installing-php-and-apache-on-mac-osx-that-was-pretty-easy/
Install it dynamically as a dso.
https://perl.apache.org/docs/2.0/user/install/install.html#Dynamic_mod_perl
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.