Wow, I'm having a hell of a time with it too. I compiled it directly into
Apache. I don't get segfaults but I don't get compression either. After all
the time I've put into it (it's late, and now I'm drunk) I could compose a
lovely rant on this, but I'll keep that to myself.
No love. I get no
Hi gang,
After a few months of outrageous instability, I am now moving WYPUG on
to a Linux server (redhat 7.2). Using ApacheToolbox
(http://www.apachetoolbox.com) I have managed to get Apache, mod_perl
and MySQL up and running, along with a few Apache modules. At this
point everything is
On Fri, 15 Feb 2002, Jonathan M. Hollin wrote:
Hi gang,
After a few months of outrageous instability, I am now moving WYPUG on
to a Linux server (redhat 7.2). Using ApacheToolbox
Good idea ;))
(no i don't like redhat, but i like linux)
I now need to install some Perl modules
:: what's the best
:: way to install modules? In short, what do I need to know?
:: just type
:: perl -MCPAN -eshell
:: this will ask you some simple questions, about the nearest
:: mirror to you, and so on, if you are on the command-prompt,
:: type install Your::Module and it will fetch the
I now need to install some Perl modules (DBD-MySql, Image-Magick, etc).
Under ActivePerl on WYPUG's current Win2K box, I would simply use the
Perl Package Manager (PPM) to download and install these modules. Is
there an equivalent under Unix? If not, what's the best way to install
modules?
On Fri, 15 Feb 2002, Jonathan M. Hollin wrote:
I now need to install some Perl modules (DBD-MySql, Image-Magick, etc).
Under ActivePerl on WYPUG's current Win2K box, I would simply use the
Perl Package Manager (PPM) to download and install these modules. Is
there an equivalent under Unix?
Hi there,
On Thu, 14 Feb 2002, OCNS Consulting wrote:
I Unzip/Untar the Apache tarball and change to the Apache top level
distribution directory. I then Unzip/Untar the module dists and one by one
prep each module for a static build and then finally build mod_perl as per
my previous
Jonathan M. Hollin wrote:
I now need to install some Perl modules (DBD-MySql, Image-Magick, etc).
Under ActivePerl on WYPUG's current Win2K box, I would simply use the
Perl Package Manager (PPM) to download and install these modules. Is
there an equivalent under Unix? If not, what's the
On Thu, 14 Feb 2002 11:35:14 -0500
Perrin Harkins [EMAIL PROTECTED] wrote:
It's really a good idea to do this even when the cookie is nothing but a
session ID. A standard module for this like the one Jay mentioned would
definitely be nice.
Apache::Cookie::Encrypted seems to be the one.
sub new {
my ($class, $r) = @_;
return bless { r = Apache::Request-new($r),
}, $class;
}
or
sub new {
my ($class,$r) = @_;
my $self = $class-SUPER::new($r);
# do your own init ...
return $self
}
TMTOWTDI, aaron
--
aaron
Paul Lindner wrote:
If you look you'll see that the new() method is written in C. It
should be blessing itself into the passed in class, not using
Apache::Request.
You're right- except that this is exactly how the Apache class,
from which Apache::Request is derived, expects to be
I have a mysterious mistaken identity problem that I have not been
able to solve.
There are two common sources of this problem. One is an ID generation
system that is not unique enough. Another is a bug in your code with
globals (see the section of the Guide about debugging with httpd -X).
At 7:44 AM -0500 2/15/02, fliptop wrote:
the version of makerpm.pl you find may not work with rpm version 4.0
or higher, this will fix that:
572c572
} elsif ($rpm_version =~ /rpm\s+version\s+3\.+/i) {
---
} elsif ($rpm_version =~ /rpm\s+version\s+3|4\.+/i) {
Actually I
Although all your cookies will be probably be going to the same proxy for
those requests from the same isp, the tcp-ip session will remain the same
and it is most likely that you'll still be connected to the same ip which
made the initial proxy connection. My thought is possibly that you're
Hi again!
No one got a clue to my problem? A hunch or just a feeling would do just
fine :-)
/Anders
Anders Knuts skrev:
Hi!
I have a board script to which users can post (of course)
One IP-address has sometimes problems posting to that script, though.
Look at the log's below.
Hi there,
On Fri, 15 Feb 2002, Anders Knuts wrote:
Hi again!
No one got a clue to my problem? A hunch or just a feeling would do just
fine :-)
Didn't you get my reply?
73,
Ged.
--
From [EMAIL PROTECTED] Fri Feb 15 17:39:58
Dear mod_perl experts:
Collectively, we've been at this for more than two weeks and have searched
various mod_perl archives, all to no avail.
Symptom:
===
SIGSEGV after fork(). Very reproducible. Memory corruption gets moved
around if the codebase changes.
[ SNIP ]
The above
The only other way I can think of to solve this is to send my module list
to this audience. Please find it, attached, with home-grown modules
deleted.
Have you tried debugging the old-fashioned way, i.e. remove things until it
works? That's your best bet. I suspect you will find that you
At 11:44 AM -0600 2/15/02, Fister, Mark wrote:
Dear mod_perl experts:
Collectively, we've been at this for more than two weeks and have searched
various mod_perl archives, all to no avail.
Symptom:
===
SIGSEGV after fork(). Very reproducible. Memory corruption gets moved
around if
Perrin Harkins wrote:
002801c1b63b$2563aea0$18020c0a@PerriHar">
I have a mysterious "mistaken identity" problem that I have not beenable to solve.
There are two common sources of this problem. One is an ID generationsystem that is not unique enough. Another is a bug in your
2. I don't think it's a global vairable issue. Basically, I just grab
the cookie by $r-header_in('Cookie')
and decrypt it.
It's what you do after that that matters.
Besides, if it's global then the mistaken ID's should
be from anywhere randomly.
True, but random may not always look
small operations. I'm pretty convinced that the problem is on their
end. My theory is that these proxies may have cached the cookie
with an IP address which they provide their clients.
Have you tried capturing all ethernet packets and seeing if the raw
data supports this conclusion.
On Fri, Feb 15, 2002 at 11:44:03AM -0600, Fister, Mark wrote:
Dear mod_perl experts:
Collectively, we've been at this for more than two weeks and have searched
various mod_perl archives, all to no avail.
Symptom:
===
SIGSEGV after fork(). Very reproducible. Memory
The only other way I can think of to solve this is to send my module
list
to this audience. Please find it, attached, with home-grown modules
deleted.
Have you tried debugging the old-fashioned way, i.e. remove things until
it
works? That's your best bet. I suspect you will find that
On Fri, Feb 15, 2002 at 12:17:07PM -0800, Paul Lindner wrote:
On Fri, Feb 15, 2002 at 11:44:03AM -0600, Fister, Mark wrote:
Dear mod_perl experts:
Collectively, we've been at this for more than two weeks and have
searched
various mod_perl archives, all to no avail.
Yes, of course i did, sorry.
I don't think I'm experienced enough to know how to use tcpdump in this case,
though...
Any hints?
/Anders
Ged Haywood skrev:
Hi there,
On Fri, 15 Feb 2002, Anders Knuts wrote:
Hi again!
No one got a clue to my problem? A hunch or just a feeling would do
Perrin Harkins wrote:
009001c1b65b$068df3d0$18020c0a@PerriHar">
2. I don't think it's a global vairable issue. Basically, I just grabthe cookie by $r-header_in('Cookie')and decrypt it.
It's what you do after that that matters.
All it does is get the user login info and
On Fri, 15 Feb 2002, Rob Nagler wrote:
small operations. I'm pretty convinced that the problem is on their
end. My theory is that these proxies may have cached the cookie
with an IP address which they provide their clients.
Have you tried capturing all ethernet packets and seeing if
Hello again,
On Fri, 15 Feb 2002, Anders Knuts wrote:
[snip,snip]
to use tcpdump in this case, Any hints?
You can use tcpdump to record the entire conversation between the
browser and the server. To find out how to use it you can just type
'man tcpdump'. If it's a problem specific to one IP
On Fri, 2002-02-15 at 16:07, Ged Haywood wrote:
[snip,snip]
to use tcpdump in this case, Any hints?
You can use tcpdump to record the entire conversation between the
browser and the server. To find out how to use it you can just type
'man tcpdump'.
although tcpdump output isn't very
On Fri, 2002-02-15 at 16:20, jon schatz hit the send button to quickly:
runs on *nix and win32. using something like this makes it easier t
meant to say makes it easier to see the actual HTTP conversation, not
just the tcp traffic. oops.
-jon
--
[EMAIL PROTECTED] || www.divisionbyzero.com
On Tue, 12 Feb 2002 20:03:22 +0100
Anders Knuts [EMAIL PROTECTED] wrote:
xxx.xxx.25.50 - - [10/Feb/2002:21:15:33 +0100] POST
/cgi-bin/mboard/message.pl HTTP/1.1
200 88 - Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
xxx.xxx.25.50 - - [10/Feb/2002:21:15:36 +0100] POST
Dzuy Nguyen wrote:
I have been getting many reports from our users that they have been
mistakenly identified as someone else.
I have tried to login as that user and just can't re-create the problem
and I can't be at their computer to
diagnose it. One thing I'm pretty sure about is that
Yes of course it is referer, my mistake thanx
The _referer_ should be my own server, since it is from where the POST
originate, but in this particular case, from this IP-adress, the referer
disapears sometimes...
/Anders
Tatsuhiko Miyagawa skrev:
On Tue, 12 Feb 2002 20:03:22 +0100
Anders
34 matches
Mail list logo
