Mailing List Archive

Hello,

> On 22 Feb 2019, at 12:47, Hans Poo <hanspoo@gmail.com> wrote:
>
> I've been unable to compile 1.0 on ubuntu 12.04 or later. Anyone has been able to compile it or has a patched mod_perl source tree ?
>
> wget https://archive.apache.org/dist/httpd/apache_1.3.42.tar.gz
> wget http://apache.org/dist/perl/mod_perl-1.31.tar.gz

Are you aware that there are newer versions of these programs? Apache 1.3.42 is of 2010. Support has ended many years ago. Putting such an old release online would create immediately a security risk. Even when using it as an Intranet solution, why not using an up-to-date release? Ubuntu 12.04 is of 2014, support has ended 2017. Do you want to create a museum?

Best regards

Matthias Schmitt

Yes, I do. I'am aware of that, the software is built with mod_perl 1.0, and
I have been able to run it under 10.04, but there's no support for 10.4 in
the internet right now you know, so I'm looking for a way to compile it for
12.04.

El vie., 22 feb. 2019 11:34 a.m., Matthias Schmitt <freak002@mmp.lu>
escribió:

> Hello,
>
> > On 22 Feb 2019, at 12:47, Hans Poo <hanspoo@gmail.com> wrote:
> >
> > I've been unable to compile 1.0 on ubuntu 12.04 or later. Anyone has
> been able to compile it or has a patched mod_perl source tree ?
> >
> > wget https://archive.apache.org/dist/httpd/apache_1.3.42.tar.gz
> > wget http://apache.org/dist/perl/mod_perl-1.31.tar.gz
>
> Are you aware that there are newer versions of these programs? Apache
> 1.3.42 is of 2010. Support has ended many years ago. Putting such an old
> release online would create immediately a security risk. Even when using it
> as an Intranet solution, why not using an up-to-date release? Ubuntu 12.04
> is of 2014, support has ended 2017. Do you want to create a museum?
>
> Best regards
>
> Matthias Schmitt
>
>
>

Hello,

> On 22 Feb 2019, at 17:19, Hans Poo <hanspoo@gmail.com> wrote:
>
> Yes, I do. I'am aware of that, the software is built with mod_perl 1.0, and I have been able to run it under 10.04, but there's no support for 10.4 in the internet right now you know, so I'm looking for a way to compile it for 12.04.

I doubt that you will be able to compile mod_perl 1.x with newer compilers and operating systems.
If you have an existing application, have you tried to switch to mod_perl 2 using the compatibility layer?

https://perl.apache.org/docs/2.0/api/Apache2/compat.html

If this would be working, it would at least be more future proof solution.

Best regards

Matthias Schmitt

magic moving pixel s.a.
23, Avenue Grande-Duchesse Charlotte
L-3441 Dudelange
Luxembourg
Phone: +352 54 75 75
http://www.mmp.lu

On 2/22/19 10:54 AM, Matthias Schmitt wrote:
> I doubt that you will be able to compile mod_perl 1.x with newer compilers and operating systems.

Hold my beer :).

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"

$ which httpd
/home/mschout/perl5/perlbrew/perls/perl-5.10.1-apache-1.3/bin/httpd

$ httpd -v
Server version: Apache/1.3.41 (Unix)
Server built: Feb 24 2019 16:43:18

And, it passes the Apache::AuthCookie test suite (provided you install
Apache::Test and Test::More@0.94). It identifies in the log as:
[notice] Apache/1.3.41 (Unix) mod_perl/1.32-dev configured

I'm actually somewhat suprised that it compiled.

Its *possible* :). But given how long 1.3 has been EOL'd, I *STRONGLY*
discourage anyone from using it. At a minimum update to Apache 2.2,
which, although also EOL'd at this point, at least got security updates
within the past year or so. You really need to migrate to 2.4.

That being said, you can build it if you apply the attached patches, as
part of the perlbrew+mod_perl setup I made for testing various versions
of apache and mod_perl over the years. For the curious, the process I
used here was:

$ perlbrew install -Accflags=-fPIC -v --noman --notest -j9 \
--as perl-5.10.1-apache-1.3 5.10.1

I used 5.10 in order to avoid dealing with any incompatibilities with
newer perls against apache 1.3.

$ perlbrew use perl-5.10.1-apache-1.3
$ cpanm -q --notest LWP::UserAgent

Then extract apache and mod_perl dists (I'm using apache 1.3.41,
mod_perl 1.31) and apply the attached patches to apache+mod_perl.

For mod_perl, apply the mod_perl-1.32.patch, which IIRC, I pulled from
the mod_perl svn trunk years ago.

The other two patches need to be applied to apache (apache-getline.patch
and gcc-inline-fix.patch).

I built this way:

$ perl Makefile.PL \
APACHE_SRC=path/to/apache-src/src \
DO_HTTPD=1 \
USE_APACI=1 \
PREP_HTTPD=1 \
EVERYTHING=1
$ cd /path/to/apache-src
$ bash ./configure --prefix=$PERLBREW_ROOT/perls/$PERLBREW_PERL \
--with-layout=Apache \
--enable-module=all \
--disable-module=auth_db \
--disable-module=auth_dbm \
--enable-shared=max \
--activate-module=src/modules/perl/libperl.a \
--disable-shared=perl \
--disable-rule=EXPAT \
--disable-rule=WANTHSREGEX
$ cd /path/to/apache-src
$ make install
$ cd /path/to/modperl-src
$ make install

I have a Makefile that does all of this. I suppose I could publish it
on github or something, but given the age of apache 1.3, it seems
irresponsible to publish it at this point :).

Regards,
Michael Schout

> On 2/22/19 10:54 AM, Matthias Schmitt wrote:
> > I doubt that you will be able to compile mod_perl 1.x with newer compilers and operating systems.
>
> Hold my beer :).
[sNip]
> I have a Makefile that does all of this. I suppose I could publish
> it on github or something, but given the age of apache 1.3, it
> seems irresponsible to publish it at this point :).

Michael: You deserve to get two beers back for this -- it's
wonderful that anyone can get help to get older systems working.

I do agree with you overall though that the focus should be on
Apache HTTPd 2.4, and given that the older options are discontinued I
also encourage putting time and effort into upgrading Perl code
instead of trying to get the older Apache HTTPd 1.x working.

As long as one isn't relying on the client's dynamic TCP port number
from $r->connection->remote_addr->port for anything (as I've
discovered no longer works in the current release of mod_perl2),
updating to the newest mod_perl2 should ultimately be relatively
problem-free. (This client port number business has not been a high
priority for me to raise as an issue, but if it is something that
Hans or anyone else is needing I'll gladly chime in with my vote for
wanting it fixed.)

Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

On 2/24/2019 4:44 PM, Randolf Richardson wrote:
>> On 2/22/19 10:54 AM, Matthias Schmitt wrote:
>>> I doubt that you will be able to compile mod_perl 1.x with newer compilers and operating systems.
>>
>> Hold my beer :).
> [sNip]
>> I have a Makefile that does all of this. I suppose I could publish
>> it on github or something, but given the age of apache 1.3, it
>> seems irresponsible to publish it at this point :).
>
> Michael: You deserve to get two beers back for this -- it's
> wonderful that anyone can get help to get older systems working.
>
> I do agree with you overall though that the focus should be on
> Apache HTTPd 2.4, and given that the older options are discontinued I
> also encourage putting time and effort into upgrading Perl code
> instead of trying to get the older Apache HTTPd 1.x working.
>
> As long as one isn't relying on the client's dynamic TCP port number
> from $r->connection->remote_addr->port for anything (as I've
> discovered no longer works in the current release of mod_perl2),
> updating to the newest mod_perl2 should ultimately be relatively
> problem-free. (This client port number business has not been a high
> priority for me to raise as an issue, but if it is something that
> Hans or anyone else is needing I'll gladly chime in with my vote for
> wanting it fixed.)

Does this work for you?
$r->connection->client_addr->port;

The doc. states remote_addr returns an APR::SockAddr object but there's
no remote_addr in my Apache2::Connection. However, there's a client_addr
which does return an APR::SockAddr object.

>
> Randolf Richardson - randolf@inter-corporate.com
> Inter-Corporate Computer & Network Services, Inc.
> Beautiful British Columbia, Canada
> http://www.inter-corporate.com/
>
>
>

[sNip]
> > As long as one isn't relying on the client's dynamic TCP port number
> > from $r->connection->remote_addr->port for anything (as I've
> > discovered no longer works in the current release of mod_perl2),
> > updating to the newest mod_perl2 should ultimately be relatively
> > problem-free. (This client port number business has not been a high
> > priority for me to raise as an issue, but if it is something that
> > Hans or anyone else is needing I'll gladly chime in with my vote for
> > wanting it fixed.)
>
> Does this work for you?
> $r->connection->client_addr->port;

Unfortunately, this does not work for me, and this error is appended
to the web server's error log:

Can't locate object method "port" via package "APR::SockAddr" at
/internet/com/example/www/test.pl line 42.

> The doc. states remote_addr returns an APR::SockAddr object but there's
> no remote_addr in my Apache2::Connection. However, there's a client_addr
> which does return an APR::SockAddr object.

In case you're interested, these are the relevant modules I'm using
(output filtered from "apt" on Ubuntu Linux 18.04 LTS on my laptop):

apache2/bionic-updates,now 2.4.29-1ubuntu4.5 amd64

apache2-bin/bionic-updates,now 2.4.29-1ubuntu4.5 amd64

apache2-data/bionic-updates,bionic-updates,now 2.4.29-1ubuntu4.5
all

apache2-dev/bionic-updates,now 2.4.29-1ubuntu4.5 amd64

libapache2-mod-apreq2/bionic,now 2.13-5build3 amd64

libapache2-mod-perl2/bionic-updates,bionic-security,now
2.0.10-2ubuntu3.18.04.1 amd64

libapache2-request-perl/bionic,now 2.13-5build3 amd64

perl/bionic-updates,bionic-security,now 5.26.1-6ubuntu0.3 amd64

perl-base/bionic-updates,bionic-security,now 5.26.1-6ubuntu0.3
amd64

Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

On 2/25/2019 2:28 PM, Randolf Richardson wrote:
> [sNip]
>>> As long as one isn't relying on the client's dynamic TCP port number
>>> from $r->connection->remote_addr->port for anything (as I've
>>> discovered no longer works in the current release of mod_perl2),
>>> updating to the newest mod_perl2 should ultimately be relatively
>>> problem-free. (This client port number business has not been a high
>>> priority for me to raise as an issue, but if it is something that
>>> Hans or anyone else is needing I'll gladly chime in with my vote for
>>> wanting it fixed.)
>>
>> Does this work for you?
>> $r->connection->client_addr->port;
>
> Unfortunately, this does not work for me, and this error is appended
> to the web server's error log:
>
> Can't locate object method "port" via package "APR::SockAddr" at
> /internet/com/example/www/test.pl line 42.

Does test.pl load APR::SockAddr?

use APR::SockAddr ();


>
>> The doc. states remote_addr returns an APR::SockAddr object but there's
>> no remote_addr in my Apache2::Connection. However, there's a client_addr
>> which does return an APR::SockAddr object.
>
> In case you're interested, these are the relevant modules I'm using
> (output filtered from "apt" on Ubuntu Linux 18.04 LTS on my laptop):
>
> apache2/bionic-updates,now 2.4.29-1ubuntu4.5 amd64
>
> apache2-bin/bionic-updates,now 2.4.29-1ubuntu4.5 amd64
>
> apache2-data/bionic-updates,bionic-updates,now 2.4.29-1ubuntu4.5
> all
>
> apache2-dev/bionic-updates,now 2.4.29-1ubuntu4.5 amd64
>
> libapache2-mod-apreq2/bionic,now 2.13-5build3 amd64
>
> libapache2-mod-perl2/bionic-updates,bionic-security,now
> 2.0.10-2ubuntu3.18.04.1 amd64
>
> libapache2-request-perl/bionic,now 2.13-5build3 amd64
>
> perl/bionic-updates,bionic-security,now 5.26.1-6ubuntu0.3 amd64
>
> perl-base/bionic-updates,bionic-security,now 5.26.1-6ubuntu0.3
> amd64
>
> Randolf Richardson - randolf@inter-corporate.com
> Inter-Corporate Computer & Network Services, Inc.
> Beautiful British Columbia, Canada
> http://www.inter-corporate.com/
>
>
>

Hi,

Thanks a lot it worked !!!
In the process i needed some tweaks, maybe they can help a little more to others.
The perlbrew install command was failing signaling download error, it was the inexistente folder, so i creted it:
mkdir -p ~/perl5/perlbrew/dists/
Then it worked fine:
perlbrew install -Accflags=-fPIC -v --noman --notest -j9 --as perl-5.10.1-apache-1.3 5.10.1
perlbrew use perl-5.10.1-apache-1.3

sudo apt install cpanminus
cpanm -q --notest LWP::UserAgent

I left all in a folder called src, and make some test runs, so i automate deleting perl and apache folders and uncompress again.
cd src/
rm -rf mod_perl-1.31 apache_1.3.42

tar xzvf apache_1.3.42.tar.gz
tar xzvf mod_perl-1.31.tar.gz

Patch aplying automation too:
cd mod_perl-1.31/
patch -p1 < ../mod_perl-1.32.patch

cd ..
cd apache_1.3.42/
patch -p1 < ../apache-getline.patch
patch -p1 < ../gcc-inline-fix.patch

Finally, in the environment created i used "cpan" clasic command. "cpanm" was not installing modules in the right path.
Dependencies: For avoid question on follow dependencies before invoking cpan invoke from shell:
export PERL_MM_USE_DEFAULT=1

Then, newer module versions where failing the tests all the time, so i installed them with force, i.e. for DBI module:
force install DBI

Thanks again,
Hans

On feb. 24 2019, at 8:07 pm, Michael Schout <mschout@gkg.net> wrote:
> On 2/22/19 10:54 AM, Matthias Schmitt wrote:
> > I doubt that you will be able to compile mod_perl 1.x with newer compilers and operating systems.
>
>
> Hold my beer :).
> $ cat /etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=18.04
> DISTRIB_CODENAME=bionic
> DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"
>
> $ which httpd
> /home/mschout/perl5/perlbrew/perls/perl-5.10.1-apache-1.3/bin/httpd
>
> $ httpd -v
> Server version: Apache/1.3.41 (Unix)
> Server built: Feb 24 2019 16:43:18
>
> And, it passes the Apache::AuthCookie test suite (provided you install
> Apache::Test and Test::More@0.94). It identifies in the log as:
> [notice] Apache/1.3.41 (Unix) mod_perl/1.32-dev configured
>
> I'm actually somewhat suprised that it compiled.
> Its *possible* :). But given how long 1.3 has been EOL'd, I *STRONGLY*
> discourage anyone from using it. At a minimum update to Apache 2.2,
> which, although also EOL'd at this point, at least got security updates
> within the past year or so. You really need to migrate to 2.4.
>
> That being said, you can build it if you apply the attached patches, as
> part of the perlbrew+mod_perl setup I made for testing various versions
> of apache and mod_perl over the years. For the curious, the process I
> used here was:
>
> $ perlbrew install -Accflags=-fPIC -v --noman --notest -j9 \
> --as perl-5.10.1-apache-1.3 5.10.1
>
> I used 5.10 in order to avoid dealing with any incompatibilities with
> newer perls against apache 1.3.
>
> $ perlbrew use perl-5.10.1-apache-1.3
> $ cpanm -q --notest LWP::UserAgent
>
> Then extract apache and mod_perl dists (I'm using apache 1.3.41,
> mod_perl 1.31) and apply the attached patches to apache+mod_perl.
>
> For mod_perl, apply the mod_perl-1.32.patch, which IIRC, I pulled from
> the mod_perl svn trunk years ago.
>
> The other two patches need to be applied to apache (apache-getline.patch
> and gcc-inline-fix.patch).
>
> I built this way:
> $ perl Makefile.PL \
> APACHE_SRC=path/to/apache-src/src \
> DO_HTTPD=1 \
> USE_APACI=1 \
> PREP_HTTPD=1 \
> EVERYTHING=1
> $ cd /path/to/apache-src
> $ bash ./configure --prefix=$PERLBREW_ROOT/perls/$PERLBREW_PERL \
> --with-layout=Apache \
> --enable-module=all \
> --disable-module=auth_db \
> --disable-module=auth_dbm \
> --enable-shared=max \
> --activate-module=src/modules/perl/libperl.a \
> --disable-shared=perl \
> --disable-rule=EXPAT \
> --disable-rule=WANTHSREGEX
> $ cd /path/to/apache-src
> $ make install
> $ cd /path/to/modperl-src
> $ make install
>
> I have a Makefile that does all of this. I suppose I could publish it
> on github or something, but given the age of apache 1.3, it seems
> irresponsible to publish it at this point :).
>
> Regards,
> Michael Schout
>