mod_proxy_add_forward weirdness: is it me or is it the code?

2002-12-22 Thread George Valpak
Probably me, I know

I am working on settinig up a 2 server/proxy config. I have followed instructions at 
http://perl.apache.org/docs/1.0/guide on how to do that and so far it has gone pretty 
well. I now have both servers built from apache 1.3.27 and  mod_perl 1.27 for the 2nd 
server.

The issue is I am trying to add mod_proxy_add_forward so the originating IP address 
shows up in the MP server's logs. The thing that is strange to me is that it works 
fine if I put the machine's internal address, (which happens to be 192.168.1.201) in 
my startup.pl file:
---
#!/usr/bin/perl   
use Apache::Constants ();

sub My::ProxyRemoteAddr ($) {
my $r = shift;

# we'll only look at the X-Forwarded-For header if the requests
# comes from our proxy at localhost
#return OK unless ($r->connection->remote_ip eq "127.0.0.1");
return OK unless ($r->connection->remote_ip eq "192.168.1.201");

if (my ($ip) = $r->header_in('X-Forwarded-For') =~ /([^,\s]+)$/) {
  $r->connection->remote_ip($ip);
}

return OK;
  }

1;
---
but if I use 127.0.0.1, then 192.168.1.201 shows up in the MP server's logs.

some more info on my set up
- 127.0.0.1 is in the /etc/hosts file:
127.0.0.1   localhost

even if I change that to: (which doesn't strike me as a good idea (tm) anyway)
127.0.0.1   localhost development

it does not change things.

Can anyone help me out with what I am missing here?

I could live with the weirdness in startup pl but I would rather not because it is one 
more config to have to keep track of, and it will break if the machine's IP address 
changes.

Thanks and have some holiday egg nog on me!

GV




Re: [mp1] strange build problem with request_rec structure breaksAPI

2002-12-22 Thread Stas Bekman
[...]

I've tracked the difference down as to where it is in the structure: all
elements before and including "finfo" (type: struct stat) are in sync,
and all elements after and including "parsed_uri" (type: uri_components)
are 8 bytes off (extra 8 bytes in apache-mod_perl).

Either "finfo" is eight bytes longer in apache-mod_perl, or
apache-mod_perl has slipped some other element between "finfo" and
"parsed_uri".

Somehow apache-mod_perl and apache-vanilla have a different ideas of the
request_rec structure. Because I compile mod_ssl using apxs from
apache-vanilla it works with apace-vanilla but not apache-mod_perl.


it's the struct stat that's different, not the request_rec. And no, 
mod_perl doesn't mangle the Apache datastructures.

Check this out:

/* sizeof.c */
#include 
#include 

int main()
{
printf("size of struct stat is: %d\n", sizeof(struct stat));
return 0;
}

# sizeof.pl
use Inline C;

foo();

__END__
__C__

int foo()
{
printf("size of struct stat is: %d\n", sizeof(struct stat));
return 0;
}


% gcc -o sizeof sizeof.c ; ./sizeof
size of struct stat is: 88

% /home/stas/perl/5.6.0/bin/perl ./sizeof.pl
size of struct stat is: 96

tested with other perls on the same machine and the result is the same 
(beware to delete _Inline before each try, since it won't recompile the 
code if you use a different perl version, but the C code haven't changed)

So as you can see there is indeed 8 bytes difference. This is because 
some of the members of the struct stat aren't of the same size when 
compiled with perl and C. You may want to dig deeper and figure out the 
one that's different. But first compare perl -V of the older perl build 
under which things worked and the output of the newly built perl. I 
suspect that the latter has the USE_LARGE_FILES enabled, whereas the 
older doesn't. On my machine /usr/include/bits/stat.h uses a different 
struct stat when large files are enabled.

Ah, indeed that seems to be the issue:

gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o sizeof sizeof.c ; ./sizeof
size of struct stat is: 96

here you go -D_FILE_OFFSET_BITS=64 is the one that causes the prob.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com



Re: Install Problem: make test: modules/src.t

2002-12-22 Thread Stas Bekman
Mark Hawkes wrote:

When I 'make test' I'm getting failures relating to modules/src.t

[...]

$ make test TEST_VERBOSE=1
<--snip-->
dir=../src
ok 2
main=
not ok 3
module_magic_number = 0
not ok 4
httpd_version =
not ok 5
-I../src -I../src/modules/perl
ok 6
FAILED tests 3-5
Failed 3/6 tests, 50.00% okay
<--snip-->
Failed Test  Status Wstat Total Fail  Failed  List of failed
--- 

modules/src.t 63  50.00%  3-5
6 tests skipped.
httpd terminated
Failed 1/34 test scripts, 97.06% okay. 3/398 subtests failed, 99.25% okay.
make: *** [run_tests] Error 29

what t/logs/error_log has to say about that?
BTW, you can run just one test:

% make start_httpd
% t/TEST -v modules/src.t
% make stop_httpd

Please remember to follow the guidelines at:
http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
to get the issues resolved much faster.



--


__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com




Re: web link broken when access cgi-bin

2002-12-22 Thread Bill Moseley
On Sun, 22 Dec 2002, Richard Clarke wrote:

> > And sent messages about using Windows to a Linux list, and CGI questions
> to
> > mod_perl list and seems to ignore the many requests to read some basic CGI
> > tutorials.   I'd guess troll if he wasn't so clueless. ;)
> 
> Since when did mod_perl becomes Linux only?

oops, I meant to write:

"And sent messages about using Windows to a Linux list"


-- 
Bill Moseley [EMAIL PROTECTED]




Re: web link broken when access cgi-bin

2002-12-22 Thread Richard Clarke
> And sent messages about using Windows to a Linux list, and CGI questions
to
> mod_perl list and seems to ignore the many requests to read some basic CGI
> tutorials.   I'd guess troll if he wasn't so clueless. ;)

Since when did mod_perl becomes Linux only?

Richard.




Re: web link broken when access cgi-bin

2002-12-22 Thread Bill Moseley
On Sunday 22 December 2002 03:49, Ged Haywood wrote:
> Hi there,
> 
> On Sat, 21 Dec 2002, eric lin wrote:
> 
> > The image "file:///home/enduser/mytest.jpg" cannot be displayed, because 
> > it contains errors
> 
> I think I understand your question but I am not sure of it.
> 
> It seems that you have sent a request to Apache, received a response,

And sent messages about using Windows to a Linux list, and CGI questions to 
mod_perl list and seems to ignore the many requests to read some basic CGI 
tutorials.   I'd guess troll if he wasn't so clueless. ;)



Re: web link broken when access cgi-bin

2002-12-22 Thread Ged Haywood
Hi there,

On Sat, 21 Dec 2002, eric lin wrote:

> The image "file:///home/enduser/mytest.jpg" cannot be displayed, because 
> it contains errors

I think I understand your question but I am not sure of it.

It seems that you have sent a request to Apache, received a response,
and saved the response to a file in the hope that it was an image.
When you used Netscape to try to view the image it failed to appear.

It seems unlikely that anything there did what you thought, you will
need to find out what is happening by thinking about it and testing.

One way to test what you get from Apache is to use 'telnet' to make
the requests.  It's documented in the mod_perl Guide which is at

http://perl.apache.org/docs/1.0/guide

Normally when you want to send an image file to the client you don't
use mod_perl to do it.  Either mod_perl never gets involved (because
of the Apache configuration in httpd.conf) or you tell mod_perl to let
Apache send the file for you (the mod_perl handler can return DECLINED
to Apache when it sees the request).

> I am using apache 1.3.26 and perl 5.8

We need more information than this.  Please read the documentation
about getting help which you will find in the mod_perl source tree in
a file called SUPPORT and also in the mod_perl Guide.

There is a lot of reading to do.  Unfortunately it is almost all in
English and unfortunately your English is not good, so you will need
to work hard at it.  Try to make your questions clearer.  If you have
a friend who speaks better English, let him see the questions first.

If I have not understood your question please try again. :)

73,
Ged.




RE: Install Problem: make test: modules/src.t

2002-12-22 Thread Ged Haywood
Hi there,

On Sun, 22 Dec 2002, Mark Hawkes wrote:

> Thanks Beau, but that didn't solve anything :-( 'make test' needs to run as 
> root or it can't write to the Apache directory.

[snip]

> >-Original Message-
> >From: Mark Hawkes [mailto:[EMAIL PROTECTED]]
> >Sent: Saturday, December 21, 2002 12:00 PM
> >To: [EMAIL PROTECTED]
> >Subject: Install Problem: make test: modules/src.t
> >
> >
> >When I 'make test' I'm getting failures relating to modules/src.t
> >Can anyone help?
> >
> >-- PLATFORM --
> >
> >OS: Slackware Linux 2.2.16
> >Perl:   5.6.0
> >mod_perl:   1.27
> >Apache: Apache/1.3.12 (Unix) PHP/4.2.3
> >
> >Apache root:/var/lib/apache
> >mod_perl build dir: /var/lib/apache/mod_perl-1.27


Firstly I think you should upgrade your Apache to the latest.  You'll
probably then need to sort out (in your head:) the changes in the
default installation directory structure, as Apache uses /usr/local
nowadays instead of /var/lib.  Sigh.

If I were you I'd upgrade that kernel too, but I'm not sure it would be
very helpful at this stage unless you're very familiar with kernels as
you'd need to upgrade a bunch of tools as well for the upgrade to work.

You say that 'make test' won't run unless you're root.  That's bad.
You should really be building Apache and mod_perl (and just about
everything else) as a normal user in a directory to which you have
write access, for example I tend to use

/home/ged/src/apache_1.3.xx
/home/ged/src/mod_perl-1.xx

and if I'm going to need SSL, a database, whatever...

/home/ged/src/openssl-0.9.6g
/home/ged/src/mod_ssl-2.8.11-1.3.27
/home/ged/src/mysql-3.23.46

and so on.  The only time you need to be root is when you "make
install".  The instructions are usually fairly clear in the INSTALL
doc's but I'll grant you it can be a tad confusing at first because
there's such a lot of it.

I think you need to clean out those source directories (with care:) and
start again.  It's all in the Guide.

73,
Ged.