Fwd: [users@httpd] Compiling HTTPD from Source

[Rob De Langhe]

Personally, I just compile the entire suite from source code, including the
compiler (GCC) itself, openSSL, anything related to what my web server
might need.
All dependencies and the correct versions of the different software
packages are stored in a rather bulky (but simple) Makefile. Once you have
that sorted out (and I did), rebuilding (= recompiling, not
re-investigating the building) is only necessary on another O/S or hardware
architecture.

- Forwarded message from Jeff Trawick  -
    Date: Mon, 27 Oct 2014 11:28:13 -0400
    From: Jeff Trawick 
Reply-To: users@httpd.apache.org
Subject: Re: [users@httpd] Compiling HTTPD from Source
      To: users@httpd.apache.org

  On Mon, Oct 27, 2014 at 11:10 AM, Lesley Kimmel
 wrote:


Thanks for your previous input.

I compiled HTTPD on RHEL5 and attempted to use on RHEL6 given the lowest
glibc and kernel version restrictions. However, I got an error on RHEL6
because libexpat was not found. It turns out that RHEL5 has libexpat by
default and RHEL6 does not. I think it supports python and yum. In any
case I was able to successfully build HTTPD on RHEL5 to run on RHEL6 by
using an 'undocumented' compile flag '--with-expat=builtin'.
 


 
If it were me I'd use the system expat.  Your Linux vendor would be
expected to fix any security issues within a short timeframe.  APR-Util
probably wouldn't have a new release so quickly for this library which it
bundles.
 


This brings up the question of what other issues one might run into when
compiling on one system to be used on another. Is there not a very
generic compile procedure or is it simply the best practice to compile
each package on the target system? I'm trying to avoid maintaining
several different build servers if possible.


 
I'd be very concerned about OpenSSL.  My experience is with scenarios
where the security library is part of the custom httpd package.
 
There are always issues of identifying required packages for deployment
when you run on different distros/versions, and disabling features in rare
cases when the build would find it on the build system but you don't want
to require its installation on the target machine.
 
 


Thanks again,
-Les


-
Date: Sat, 25 Oct 2014 09:32:35 -0400
From: traw...@gmail.com
To: users@httpd.apache.org
Subject: Re: [users@httpd] Compiling HTTPD from Source

 On Sat, Oct 25, 2014 at 9:16 AM, Lesley
Kimmel  wrote:


All;

I've had good success compiling HTTPD from source when compiling on
RHEL5 and running on RHEL5 or compiling on RHEL6 and running on RHEL6.
I see there are library compatibility issues when compiling on RHEL6,
for example, and trying to run on RHEL5. How can I compile in a more
generic way to to be distro independent?


  
 Generally: compile on the lowest glibc and kernel versions
on which you plan to run
  
 There's a recent discussion thread on dev@apr about working
around this, but it is an iterative process and might not work from
release to release.  Here's that thread:
  



http://mail-archives.apache.org/mod_mbox/apr-dev/201410.mbox/%3C20141022131350.GA2848%40unixarea.DDR.dd%3E[1]

  
  


Thanks in advance,

-Les

--_--_-
To unsubscribe, e-mail: users-unsubscribe@httpd._apache.org_
_For additional commands, e-mail: users-help@httpd.apache.org___
 


 
___-- ___
___Born in Roswell... married an alien...
http://emptyhammock.com/___  


    
___-- ___
   ___Born in Roswell... married an alien...
http://emptyhammock.com/___    

___- End forwarded message -___


Links:
--
[1]  
http://mail-archives.apache.org/mod_mbox/apr-dev/201410.mbox/%3c20141022131350.GA2848%40unixarea.DDR.dd%3e

Re: [users@httpd] Compiling HTTPD from Source

[Jeff Trawick]

On Mon, Oct 27, 2014 at 11:10 AM, Lesley Kimmel 
wrote:

> Thanks for your previous input.
>
> I compiled HTTPD on RHEL5 and attempted to use on RHEL6 given the lowest
> glibc and kernel version restrictions. However, I got an error on RHEL6
> because libexpat was not found. It turns out that RHEL5 has libexpat by
> default and RHEL6 does not. I think it supports python and yum. In any case
> I was able to successfully build HTTPD on RHEL5 to run on RHEL6 by using an
> 'undocumented' compile flag '--with-expat=builtin'.
>
>
If it were me I'd use the system expat.  Your Linux vendor would be
expected to fix any security issues within a short timeframe.  APR-Util
probably wouldn't have a new release so quickly for this library which it
bundles.


> This brings up the question of what other issues one might run into when
> compiling on one system to be used on another. Is there not a very generic
> compile procedure or is it simply the best practice to compile each package
> on the target system? I'm trying to avoid maintaining several different
> build servers if possible.
>

I'd be very concerned about OpenSSL.  My experience is with scenarios where
the security library is part of the custom httpd package.

There are always issues of identifying required packages for deployment
when you run on different distros/versions, and disabling features in rare
cases when the build would find it on the build system but you don't want
to require its installation on the target machine.



>
> Thanks again,
> -Les
>
> --
> Date: Sat, 25 Oct 2014 09:32:35 -0400
> From: traw...@gmail.com
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] Compiling HTTPD from Source
>
>
> On Sat, Oct 25, 2014 at 9:16 AM, Lesley Kimmel 
> wrote:
>
> All;
>
> I've had good success compiling HTTPD from source when compiling on RHEL5
> and running on RHEL5 or compiling on RHEL6 and running on RHEL6. I see
> there are library compatibility issues when compiling on RHEL6, for
> example, and trying to run on RHEL5. How can I compile in a more generic
> way to to be distro independent?
>
>
> Generally: compile on the lowest glibc and kernel versions on which you
> plan to run
>
> There's a recent discussion thread on dev@apr about working around this,
> but it is an iterative process and might not work from release to release.
> Here's that thread:
>
>
> http://mail-archives.apache.org/mod_mbox/apr-dev/201410.mbox/%3C20141022131350.GA2848%40unixarea.DDR.dd%3E
> 
>
>
>
> Thanks in advance,
>
> -Les
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

RE: [users@httpd] Compiling HTTPD from Source

[Lesley Kimmel]

Thanks for your previous input.

I compiled HTTPD on RHEL5 and attempted to use on RHEL6 given the lowest glibc 
and kernel version restrictions. However, I got an error on RHEL6 because 
libexpat was not found. It turns out that RHEL5 has libexpat by default and 
RHEL6 does not. I think it supports python and yum. In any case I was able to 
successfully build HTTPD on RHEL5 to run on RHEL6 by using an 'undocumented' 
compile flag '--with-expat=builtin'.

This brings up the question of what other issues one might run into when 
compiling on one system to be used on another. Is there not a very generic 
compile procedure or is it simply the best practice to compile each package on 
the target system? I'm trying to avoid maintaining several different build 
servers if possible.

Thanks again,
-Les

Date: Sat, 25 Oct 2014 09:32:35 -0400
From: traw...@gmail.com
To: users@httpd.apache.org
Subject: Re: [users@httpd] Compiling HTTPD from Source

On Sat, Oct 25, 2014 at 9:16 AM, Lesley Kimmel  wrote:
All;



I've had good success compiling HTTPD from source when compiling on RHEL5 and 
running on RHEL5 or compiling on RHEL6 and running on RHEL6. I see there are 
library compatibility issues when compiling on RHEL6, for example, and trying 
to run on RHEL5. How can I compile in a more generic way to to be distro 
independent?

Generally: compile on the lowest glibc and kernel versions on which you plan to 
run
There's a recent discussion thread on dev@apr about working around this, but it 
is an iterative process and might not work from release to release.  Here's 
that thread:
http://mail-archives.apache.org/mod_mbox/apr-dev/201410.mbox/%3C20141022131350.GA2848%40unixarea.DDR.dd%3E





Thanks in advance,



-Les 



-

To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org

For additional commands, e-mail: users-h...@httpd.apache.org





-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

  

[users@httpd] DirectoryIndex and mod_rewrite

[Julien Etter]

Hello,

I am trying to get my head around a behaviour I have seen on 2.4, but not
affecting 2.2.

Has anyone seen this?

 

I am using a DirectoryIndex:

DirectoryIndex index.php

 

As well as a rewrite rule in a .htaccess file:

RewriteRule  ^$ index_download.php [L]

 

If I access the folder, the RewriteRule is not triggered because the
DirectoryIndex is now part of the URL-path, which was not the case in 2.2,
where the URL would trigger the rule.

Which change is responsible for this?

 

Furthermore, if I change it to:

RewriteRule  ^(?:|index\.php)$ index_download.php [L]

 

and enable log level2, I see the following logs, if I access the URL:

 

[Mon Oct 27 10:57:35.042219 2014] [rewrite:trace2] [pid 5960]: rewrite '' ->
'index_download.php'

[Mon Oct 27 10:57:35.042266 2014] [rewrite:trace2] [pid 5960]: strip
document_root prefix: /var/www/html/htdocs/index_download.php ->
/index_download.php

[Mon Oct 27 10:57:35.042272 2014] [rewrite:trace1] [pid 5960]: internal
redirect with /index_download.php [INTERNAL REDIRECT]

 

[Mon Oct 27 10:57:35.042601 2014] [rewrite:trace2] [pid 5960]: rewrite
'index.php' -> 'index_download.php'

[Mon Oct 27 10:57:35.042615 2014] [rewrite:trace2] [pid 5960]: strip
document_root prefix: /var/www/html/htdocs/index_download.php ->
/index_download.php

[Mon Oct 27 10:57:35.042619 2014] [rewrite:trace1] [pid 5960]: internal
redirect with /index_download.php [INTERNAL REDIRECT]

 

[Mon Oct 27 10:57:35.042981 2014] [rewrite:trace1] [pid 5960]: pass through
/var/www/html/htdocs/index_download.php

 

Why are they 2 blocks, one for '', one for 'index.php'? I would expect only
one... 

Also, it seems the one for '' does not result in any rewrite, only the
second one does.

Is this expected?

Julien Etter