Mixed Children on amd64

Hi,

I wrote a web application for case management (legal, insurance) with
mod_perl. The app is visible at :

http://marica.fr/

I recently purchased a
'dedibox' (http://www.online.net/serveur-dedie/offre-dedibox-v3.xhtml)
intended to host it, and configured it with Debian.

My setup is as follow :
Two instances of Apache2 sit on the server, one with mod_ssl enabled,
the other without. The former serves registered users on port 443, the
latter serves only the demo account which is visible on the home page.

After an initial connection to a common session database (using
Apache::Session and cookies for session management), each server
connects to a different PostgreSQL database for the data. This system
has been running fine for several months on various 32bit systems.

Problem description :
When I use this new machine (it is currently disabled), my registered
users on occasion will retrieve the data from the demo account instead
of their own, as if the children spawned by the two apache2 processes
got mixed up. This never happened before, so I'm guessing it is related
to the fact that this is a 64bit processor, which I never used before.

Could someone let me know from looking at the information below what I
might have done wrong in my installation?

Thank you.

Below are the commands used to compile Perl and the 2 instances
(without/with mod_ssl) of Apache2/mod_perl/libapreq. Then follows the
output of `cat /proc/cpuinfo` and `Perl -V`

# uname -a
Linux sd-21096 2.6.32-bpo.4-amd64 #1 SMP Thu Apr 8 10:20:24 UTC 2010
x86_64 GNU/Linux

#Apache2/mod_perl version
Apache/2.2.16 (Unix) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4
Perl/v5.12.1



#
#Perl
#
wget -c http://www.cpan.org/src/perl-5.12.1.tar.gz
tar -xzf perl-5.12.1.tar.gz

#./Configure -des -Dcc=gcc -Dprefix=/home/perl/5.12.1
-Dextras="Compress::Zlib Bundle::LWP ExtUtils::XSBuilder CGI::Cookie
URI::Escape"

#configure for 64bit platform
CFLAGS='-m64 -mtune=nocona' ./Configure -des -A ccflags=-fPIC -Dcc=gcc
-Dprefix=/home/perl/5.12.1 -Dextras="Compress::Zlib Bundle::LWP
ExtUtils::XSBuilder CGI::Cookie URI::Escape"

#
#Apache2
#

#source
wget -c http://apache.cict.fr/httpd/httpd-2.2.16.tar.gz
tar -xzf httpd-2.2.16.tar.gz
mkdir -p /home/httpd/2.2.16

cd /home/user1/src/httpd-2.2.16
../buildconf
../configure --prefix=/home/httpd/2.2.16 --enable-rewrite
make && make install

#
#mod_perl
#

wget -c http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz
/home/perl/5.12.1/bin/perl Makefile.PL MP_AP_PREFIX=/home/httpd/2.2.16
make && make test && make install


Test Summary Report
-------------------
t/hooks/authen_basic.t (Wstat: 0 Tests: 4 Failed: 1)
Failed test: 4
t/hooks/authz.t (Wstat: 0 Tests: 4 Failed: 1)
Failed test: 4
t/modules/apache_status.t (Wstat: 0 Tests: 15 Failed: 2)
Failed tests: 14-15
Files=238, Tests=2404, 163 wallclock secs ( 2.98 usr 1.48 sys + 122.83
cusr 15.66 csys = 142.95 CPU)
Result: FAIL
Failed 3/238 test programs. 4/2404 subtests failed.
[warning] server localhost:8529 shutdown
[ error] error running tests (please examine t/logs/error_log)
+--------------------------------------------------------+
| Please file a bug report: http://perl.apache.org/bugs/ |
+--------------------------------------------------------+

make[1]: *** [mod_perl.so] Erreur 1
make[1]: quittant le répertoire
« /home/user1/src/mod_perl-2.0.4/src/modules/perl »


For details on getting started with mod_perl 2, see: |
| |
| http://perl.apache.org/docs/2.0/user/intro/start_fast.html |
|

#
#Libapreq2
#

#source
wget -c
http://mirror.mkhelif.fr/apache/httpd/libapreq/libapreq2-2.1 2.tar.gz

/home/perl/5.12.1/bin/perl Makefile.PL
--with-apache2-apxs=/home/httpd/2.2.16/bin/apxs
--with-expat=/home/httpd/2.2.16/

make
make test
make install

Test Summary Report
-------------------
t/apreq/cgi.t (Wstat: 0 Tests: 71 Failed: 5)
Failed tests: 52, 56, 60, 64, 68
t/apreq/upload.t (Wstat: 0 Tests: 80 Failed: 10)
Failed tests: 41, 45, 49, 53, 57, 61, 65, 69, 73, 77
Files=11, Tests=287, 15 wallclock secs ( 2.00 usr 0.07 sys + 7.36 cusr
0.97 csys = 10.40 CPU)
Result: FAIL
Failed 2/11 test programs. 15/287 subtests failed.
[warning] server localhost:8529 shutdown
[ error] error running tests (please examine t/logs/error_log)
make[1]: *** [run_tests] Erreur 1
make[1]: quittant le répertoire
« /home/user1/src/libapreq2-2.12/glue/perl »
make: *** [perl_test] Erreur 2

#
#Apache2-ssl
#

mkdir -p /home/httpd/2.2.16-ssl
cd /home/user1/src/httpd-2.2.16
../buildconf
../configure --prefix=/home/httpd/2.2.16-ssl --enable-rewrite
--enable-ssl
make clean && make && make install
cd /home/user1/src/mod_perl-2.0.4
make clean
/home/perl/5.12.1/bin/perl Makefile.PL
MP_AP_PREFIX=/home/httpd/2.2.16-ssl
make && make install
cd /home/user1/src/libapreq2-2.12
make clean
/home/perl/5.12.1/bin/perl Makefile.PL
--with-apache2-apxs=/home/httpd/2.2.16-ssl/bin/apxs
--with-expat=/home/httpd/2.2.16-ssl/
make && make install


#
#System info
#

# cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 15
model name : VIA Nano processor U2250 (1.6GHz Capable)
stepping : 3
cpu MHz : 1596.084
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat clflush acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc
up rep_good pni monitor vmx est tm2 ssse3 cx16 xtpr rng rng_en ace
ace_en ace2 phe phe_en lahf_lm
bogomips : 3192.16
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:


# /home/perl/5.12.1/bin/perl -V
Summary of my perl5 (revision 5 version 12 subversion 1) configuration:

Platform:
osname=linux, osvers=2.6.32-bpo.4-amd64, archname=x86_64-linux
uname='linux sd-21096 2.6.32-bpo.4-amd64 #1 smp thu apr 8 10:20:24
utc 2010 x86_64 gnulinux '
config_args='-des -A ccflags=-fPIC -Dcc=gcc
-Dprefix=/home/perl/5.12.1 -Dextras=Compress::Zlib Bundle::LWP
ExtUtils::XSBuilder CGI::Cookie URI::Escape'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-fPIC -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fPIC -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include'
ccversion='', gccversion='4.3.2', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64
libs=-lnsl -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.7.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.7'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib
-fstack-protector'


Characteristics of this binary (from libperl):
Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
USE_64_BIT_ALL
USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO
USE_PERL_ATOF
Built under linux
Compiled at Aug 17 2010 03:30:11
@INC:
/home/perl/5.12.1/lib/site_perl/5.12.1/x86_64-linux
/home/perl/5.12.1/lib/site_perl/5.12.1
/home/perl/5.12.1/lib/5.12.1/x86_64-linux
/home/perl/5.12.1/lib/5.12.1

Re: Mixed Children on amd64

On Mon, Sep 20, 2010 at 7:00 PM, Vincent Veyron wrote:
> When I use this new machine (it is currently disabled), my registered
> users on occasion will retrieve the data from the demo account instead
> of their own, as if the children spawned by the two apache2 processes
> got mixed up.

Are these just two virtual servers running from the same httpd.conf
and server binaries? How does each one know which database to use?

It seems unlikely that this is related to your processor change.

- Perrin

Re: Mixed Children on amd64

Perrin Harkins wrote:
> On Mon, Sep 20, 2010 at 7:00 PM, Vincent Veyron wrote:
>> When I use this new machine (it is currently disabled), my registered
>> users on occasion will retrieve the data from the demo account instead
>> of their own, as if the children spawned by the two apache2 processes
>> got mixed up.
>
> Are these just two virtual servers running from the same httpd.conf
> and server binaries? How does each one know which database to use?
>
> It seems unlikely that this is related to your processor change.
>
I would be more nuanced.
Sometimes, a problem in the logic, which was there all the time but never caused any
actual problem because it was very unlikely, can become acute because of an apparently
unrelated change.
For example, events that almost never occurred "simultaneously" on a slower processor or
with less memory, now start to happen "simultaneously" because the processor is much
faster, or because there is more memory available to start more processes at the same time.
And never mind the fact that a modern 64-bit processor is likely to have several cores,
allowing it to actually run more than one process at the same time.
So something which before never happened, or happened only once or twice a year, and was
not reproducible and thus was ignored as a "cosmic ray hitting the CPU", now happens 2 or
3 times a day and cannot be ignored anymore.
The original description of the problem really makes me think of something like that.
I would bet my shirt that if you considered 2 instances of this application side by side,
and imagined that they do each step in parallel, there would be a point where you would
notice that something could go wrong.
And with a faster CPU, things that can go wrong, do go wrong faster.

Re: Mixed Children on amd64

Vincent Veyron wrote:
> Hi,
>
> I wrote a web application for case management (legal, insurance) with
> mod_perl. The app is visible at :
>
> http://marica.fr/
>
> I recently purchased a
> 'dedibox' (http://www.online.net/serveur-dedie/offre-dedibox-v3.xhtml)
> intended to host it, and configured it with Debian.
>
> My setup is as follow :
> Two instances of Apache2 sit on the server, one with mod_ssl enabled,
> the other without. The former serves registered users on port 443, the
> latter serves only the demo account which is visible on the home page.
>
Hi again.
First again a couple of personal opinions :
1) I do not think that anything that you did in terms of compiling Apache, could be the
origin of the problem which you describe.
2) It is extremely unlikely (I would say practically impossible) that two "Apache
children", if they are different processes, would get mixed up. The whole architecture of
CPUs and OS'es makes that very unlikely. You would have much bigger problems otherwise.

But a couple of things puzzle me in your setup.

1) if you are using Linux Debian, they why do you go through the trouble of compiling
Apache etc.. ? The Debian packagers have done a good job, and you can just install perl,
Apache and mod_perl with 3 commands :
apt-get install perl
apt-get install apache2
apt-get install libapache2-mod-perl2

The above takes about 2 minutes, and I do this on all our production servers, without any
problems until now. It also makes it much easier to keep the server up-to-date in terms of
security updates etc..

2) if you are running only 2 sites, of which only one is HTTPS, you could run it all in
one single Apache instance. It is no problem to run a single VirtualHost as a HTTPS host
on its own port 443, and other multiple HTTP VirtualHost's on port 80.
The problem is only when you want to run several HTTPS hosts.


I did try the first page of the demo site. I am using Firefox (with a HttpFox plugin,
usually very handly, but I did not need it here).
I can see that there was a cookie set, which in Firefox shows up as :
Host: marica.fr
name: session
path: /
secure: for any type of session
(so it is not marked secure)

I don't know of course how the cookie is set for the secure part of the site.
But if the parameters above are set the same way, then there would be a least a potential
for cookies to get mixed-up between the open and the secure part of the site.
The "https" versus "http", or the port (443 or 80), are /not/ part of that which, for a
browser, makes a cookie unique.

I do not know exactly how Apache::Session and your cookie-based authentication work, but I
suppose it is possible that some link somewhere in your application causes the users to
switch between the secure and non-secure part of the site, and that if they already have a
"session" cookie, the authentication mechanism would just accept it at face value and
direct the call to the wrong place.

Maybe one thing you could do, since these are two servers with a separate configuration,
is at least to change the name of the cookie in one of them (for example, name it
"secure-session" in the secure server). That would make them 2 separate cookies, and
maybe avoid the confusion (or show the problem right away, by popping up a login page as
soon as they click the "bad" link).

Re: Mixed Children on amd64

Le mardi 21 septembre 2010 à 17:59 +0200, André Warnier a écrit :

a couple of things puzzle me in your setup.
>
> 1) if you are using Linux Debian, they why do you go through the trouble of compiling
> Apache etc.. ? The Debian packagers have done a good job, and you can just install perl,
> Apache and mod_perl with 3 commands :
> apt-get install perl
> apt-get install apache2
> apt-get install libapache2-mod-perl2
>
> The above takes about 2 minutes, and I do this on all our production servers, without any
> problems until now. It also makes it much easier to keep the server up-to-date in terms of
> security updates etc..
>

I found it more reliable for installation over various machines, it also
makes it easier for me to use different versions of
apache/perl/postgres. Mod_ssl complicates matters a bit too, so I have
better control that way. I seem to remember that performance is also
better, according to ApacheBench.

I realized after the fact that updates _are_ a problem. I suppose one
has to recompile from source. I'm hoping to script the process,
eventually.


> 2) if you are running only 2 sites

I do have a couple other virtual hosts on the server, which is the
reason for the http only server.

I also wanted to minimize the cpu load and separate the demo account
from the main database for security reasons, which is why that account
is served from the http server, with a different database connection.

> , of which only one is HTTPS, you could run it all in
> one single Apache instance. It is no problem to run a single VirtualHost as a HTTPS host
> on its own port 443, and other multiple HTTP VirtualHost's on port 80.
> The problem is only when you want to run several HTTPS hosts.
>

This sounds like what I'm doing now? You do need two httpd processes,
one that listens on port 80, the other on port 443.

>
> I did try the first page of the demo site. I am using Firefox (with a HttpFox plugin,
> usually very handly, but I did not need it here).
> I can see that there was a cookie set, which in Firefox shows up as :
> Host: marica.fr
> name: session
> path: /
> secure: for any type of session
> (so it is not marked secure)
>
> I don't know of course how the cookie is set for the secure part of the site.
> But if the parameters above are set the same way,

They are set the same way, both processes use the same modules.

> then there would be a least a potential
> for cookies to get mixed-up between the open and the secure part of the site.
> The "https" versus "http", or the port (443 or 80), are /not/ part of that which, for a
> browser, makes a cookie unique.
>
> I do not know exactly how Apache::Session and your cookie-based authentication work, but I
> suppose it is possible that some link somewhere in your application causes the users to
> switch between the secure and non-secure part of the site, and that if they already have a
> "session" cookie, the authentication mechanism would just accept it at face value and
> direct the call to the wrong place.

Save for a couple exceptions (style sheets and images), I enforce
relative links in my code, so I doubt a switch happens.

In any case, demo and registered users can log in both ways, http or
https; this does not change the logic of the database connection (see my
other reply for the code).

Their cookie is unique in my session database, and that session is tied
to their account, so they shouldn't see the demo user's data, regardless
of whether they are using https or not.

See the relevant code in the HeaderParser below :

============================================================ =========

sub handler {

my $r = shift ;

#on suppose que la session n'est pas valide, jusqu'à preuve du contraire
my $redirect_to_login = 1 ;

my $j = Apache2::Cookie::Jar->new($r) ;

#get cookie from request headers
my $cookie = $j->cookies('session') ;

if (defined $cookie) {

#cookie string : session=151b733d5b92679da9177ad9c9dd7d7c
my ($key,$session_id) = split (/=/,$cookie) ;

my %session=() ;

#ne continuer que si on a une clé de session
if ( $session_id ) {
#create session
eval {

tie %session, 'Apache::Session::Postgres', $session_id, {
DataSource => 'dbi:Pg:dbname=marica_sessions',
UserName => $r->dir_config('db_user'),
Password => undef,
Commit => 1
}

} ;

#erreur avec la clé de session
if ($@) {

if ($@ =~ /^Object does not exist in the data store/) {

#session supprimée, rediriger vers login

} else {

warn $@ ;

return Apache2::Const::SERVER_ERROR

}

} else { #on a une session ; valider son time_to_live

#vérifier si la session n'a pas expiré
if ( $session{time_to_live} >= time() ) {

[...]



============================================================ =========

> Maybe one thing you could do, since these are two servers with a separate configuration,
> is at least to change the name of the cookie in one of them (for example, name it
> "secure-session" in the secure server). That would make them 2 separate cookies, and
> maybe avoid the confusion (or show the problem right away, by popping up a login page as
> soon as they click the "bad" link).
>
Even supposing a bad link exists, the browser always sends the same cookie, regardless of whether it's using http or https.

Re: Mixed Children on amd64

Hi,

Replying here to both of you for convenience

Le mardi 21 septembre 2010 à 16:51 +0200, André Warnier a écrit :
> Perrin Harkins wrote:
> >
> > Are these just two virtual servers running from the same httpd.conf
> > and server binaries? How does each one know which database to use?

Each server has its own httpd.conf and binaries, compiled in different
directories. Both processes use the same perl modules.

After login, a headerParser validates the session; demo users have a
'demo_' prefix appended to their name, and in that case the cached
database connection used is the demo one.

Below is the relevant code in the headerparser:
============================================================ ==========
#list of database names (demo, main)
my @databases = $r->dir_config->get('db_name');

#identity of demo user
my $demo_username = $r->dir_config('demo_username');

#demo user connects to demo db
my ($db_type,
$db_name,
$db_user,
$db_pwd,
%attributes ) =
( $r->dir_config('db_type'),
( $r->pnotes('session')->{username} =~ /$demo_username/ ) ?
$databases[1] : $databases[0],
$r->dir_config('db_user'),
$r->dir_config('db_pwd'),
$r->dir_config->get('attributes') );

eval {

$dbh = DBI->connect_cached( "DBI:$db_type:dbname=$db_name",
$db_user, $db_pwd, \%attributes );

}
============================================================ =========

> Sometimes, a problem in the logic, which was there all the time but never caused any
> actual problem because it was very unlikely, can become acute because of an apparently
> unrelated change.
> For example, events that almost never occurred "simultaneously" on a slower processor or
> with less memory, now start to happen "simultaneously" because the processor is much
> faster, or because there is more memory available to start more processes at the same time.
> And never mind the fact that a modern 64-bit processor is likely to have several cores,
> allowing it to actually run more than one process at the same time.
> So something which before never happened, or happened only once or twice a year, and was
> not reproducible and thus was ignored as a "cosmic ray hitting the CPU", now happens 2 or
> 3 times a day and cannot be ignored anymore.
> The original description of the problem really makes me think of something like that.
> I would bet my shirt that if you considered 2 instances of this application side by side,
> and imagined that they do each step in parallel, there would be a point where you would
> notice that something could go wrong.
> And with a faster CPU, things that can go wrong, do go wrong faster.
>

Indeed, this machine has more memory and a faster processor than the
previous ones, but I have very low traffic. Below is the result of `top`
(the machine was facing the internet until yesterday). As you can see,
it's not stressed by any means.
============================================================ =========
top - 21:19:18 up 35 days, 13:24, 1 user, load average: 0.00, 0.00,
0.00
Tasks: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 2028176k total, 1544980k used, 483196k free, 274400k buffers
Swap: 1044216k total, 0k used, 1044216k free, 1031144k cached
============================================================ =========

The previous machines had similar statistics, but users noticed the
problem as soon as I put this one up.

Re: Mixed Children on amd64

Vincent Veyron wrote:
....

>
>> , of which only one is HTTPS, you could run it all in
>> one single Apache instance. It is no problem to run a single VirtualHost as a HTTPS host
>> on its own port 443, and other multiple HTTP VirtualHost's on port 80.
>> The problem is only when you want to run several HTTPS hosts.
>>
>
> This sounds like what I'm doing now? You do need two httpd processes,
> one that listens on port 80, the other on port 443.
>

No you don't. If in one Apache you say
Listen 80
Listen 443

and it will listen to both ports.
And then you can say

NameVirtualHost *:80

ServerName A
...


ServerName B
...

....
NameVirtualHost *:443

ServerName C
...

(but only once, for HTTPS; the reason for that is longer to explain).

...
Sorry, really analysing the code is a bit beyond my commitment. I am just trying to give
you ideas of what to look for.
And to discourage you from looking in the wrong direction, because the idea that 2 Apache
processes could be mixing their data sounds really far-fetched to me.

>
>> Maybe one thing you could do, since these are two servers with a separate configuration,
>> is at least to change the name of the cookie in one of them (for example, name it
>> "secure-session" in the secure server). That would make them 2 separate cookies, and
>> maybe avoid the confusion (or show the problem right away, by popping up a login page as
>> soon as they click the "bad" link).
>>
> Even supposing a bad link exists, the browser always sends the same cookie, regardless of whether it's using http or https.
>
Yes, and that is what I mean. Whether users stray through the secure or non-secure site,
there is only ever one cookie. And if it is not marked secure, the browser will send that
same cookie, no matter which site the users link to. And the server receiving the cookie,
at least in the authentication part of the code, will not see the diference, and will let
them in as long as for the session referenced in the cookie, there is a valid record in
the database. So IF users would go from one server to the other, you would probably never
know, because they will not be stopped from doing that.
And that could certainly be a good reason why some users see demo data some time, instead
of theirs.

I am not saying that it /is/ the problem. What I am saying is that if you had a different
cookie name for each site (which should be easy to do), then for sure the above could not
happen, and you could eliminate one area from your search.

Be humble. On one side, there is Apache code, which is extensively tested and running on
hundreds of thousands of sites. On the other side, there is your code, which runs on just
a few sites. If there is a problem somewhere, where is it most likely to be ?

Re: Mixed Children on amd64

On Tue, Sep 21, 2010 at 4:57 PM, Vincent Veyron wrote=
:
> I realized after the fact that updates _are_ a problem. I suppose one
> has to recompile from source. I'm hoping to script the process,
> eventually.

Off-topic: will gentoo ports work with debian? "emerge mod_perl" ==
"script the process"

--=20
l'égalité des droits pour les ambidextres

Re: Mixed Children on amd64

> No you don't. If in one Apache you say
> Listen 80
> Listen 443
>
> and it will listen to both ports.

That I didn't know. I will try it, thanks

> ..
>
> (but only once, for HTTPS; the reason for that is longer to explain).
>

Well, if I'm not mistaken it's simply because the request being crypted,
Apache can't know which VirtualHost to use? So it will default to the
first one under https.


> ...
> Sorry, really analysing the code is a bit beyond my commitment

Hey, no problem, I can see why ;-)


> Be humble. On one side, there is Apache code, which is extensively tested and running on
> hundreds of thousands of sites. On the other side, there is your code, which runs on just
> a few sites. If there is a problem somewhere, where is it most likely to be ?
>

Don't worry, I am. In fact, I did not consider for a second that it was
an Apache problem, because as mentionned already, the system runs fine
on several other machines.

I tought rather of a compilation problem, in libapreq maybe, some flag
pertaining to 64 bit systems that I forgot?

Re: Mixed Children on amd64

Vincent Veyron wrote:
>> No you don't. If in one Apache you say
>> Listen 80
>> Listen 443
>>
>> and it will listen to both ports.
>
> That I didn't know. I will try it, thanks
>
>> ..
>>
>> (but only once, for HTTPS; the reason for that is longer to explain).
>>
>
> Well, if I'm not mistaken it's simply because the request being crypted,
> Apache can't know which VirtualHost to use? So it will default to the
> first one under https.
>
Élève Vincent, vous aurez 10.

>
>> ...
>> Sorry, really analysing the code is a bit beyond my commitment
>
> Hey, no problem, I can see why ;-)
>
>
>> Be humble. On one side, there is Apache code, which is extensively tested and running on
>> hundreds of thousands of sites. On the other side, there is your code, which runs on just
>> a few sites. If there is a problem somewhere, where is it most likely to be ?
>>
>
> Don't worry, I am. In fact, I did not consider for a second that it was
> an Apache problem, because as mentionned already, the system runs fine
> on several other machines.
>
> I tought rather of a compilation problem, in libapreq maybe, some flag
> pertaining to 64 bit systems that I forgot?
>
I would say that in order of increasing probabilities, there is Apache code, something
done when compiling it, mod_perl itself and then your code.

One other idea : Apache generates (or can generate) an access log, and you can configure
what is logged in each line (see CustomLog and CustomLogFormat, I think).
You can log the "referer", which is the URL of the page which was loaded in the browser
when the user clicked on the link which triggers the current request.
So if you look in the access log of your demo site, and see any request which, as a
referer, has a page from the secure site, it would be suspect, unless this is a link that
you specifically planned that way.

More in detail :
A user starts on the secure site, with page /A.
This gets logged in the access log of the secure site as :
current URL : /A
referer : (whatever page the user was on before, e.g. http://www.google.fr/)

In page /A, there is a link to /B which the user clicks.
In the log, there is now a line with :
current URL: /A
referer: https://secure-site/A

In page /B, there is a link to /C which the user clicks.
In the log, there is now a line with :
current URL: /C
referer: https://secure-site/B

and so on.
Now suppose the user, in page C, finds a link which for some reason links to the
non-secure website /something and clicks it.
Of course in that case the logfile of the secure site will show nothing.
But the logfile of the non-secure site will show a line out of the blue :
current URL: /something
referer: https://secure-site/C

That is what you would be looking for.


And another suggestion:
In the code which you showed before, you could add

use Apache2::Log;

and a bunch of
$r->warn("this is what happens here");

and whatever you print there will appear in that server's error.log

That is a time-honored way of debugging code.

Re: Mixed Children on amd64

Le mercredi 22 septembre 2010 à 18:52 +0200, André Warnier a écrit :
> One other idea : Apache generates (or can generate) an access log, and you can configure
> what is logged in each line
[...]
> and a bunch of
> $r->warn("this is what happens here");

Sure, but I'm leery of upsetting my users, and I can't seem to reproduce
the bug on a test machine, as it's rather infrequent.

I finally went with your earlier advice : install the Debian packages,
and use just one Apache process that listens on ports 80 and 443. It
simplifies my setup nicely. We'll see if the problem disappears.

Correcting what I wrote in my OP : there is no speed difference between
the stack from the Debian packages and the one compiled on my machine.

Regards,

--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des dossiers de contentieux et d'assurance pour le service juridique