posting announcement?
Sorry for the question but is it okay to post an announcement here? -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to get a core dump
Hi, Well, It's only 2 hours of on line testing, but seems that the recompilation and upgrade to apache-1.3.33 I did with "-g" to get debug info on coredumps solved the problem I used exactly the same configure options on apache,mod_ssl and mod_perl (I used the same shell script, in fact) Now I don't know what caused the problem first place, but now seems ok. I taked in account that first time I compiled all on a shell with "en_US" locale, and now I used one with "en_US.UTF8". May the locale used in the shell to compile apache+mod_perl affect the final executable in some way? The server has to deal with UTF8 info coming from/going to a SQLServer backend... On dv, 2004-11-05 at 17:46, Marc Gracia wrote: > Many Thanks Stass and Glenn, > I'll try all this anf will get back.. > > On dv, 2004-11-05 at 13:38, Marc Gracia wrote: > > Hi everybody. > > I have a problem on a production cluster with a somewhat big mod_perl > > app, and I just cannot get any clue of what is happening. > > > > The problem is that the servers just exit with Segmentation fault > > randomly. > > The problem is rare, hapens 10/20 times each day in each of the 6 > > frontends, which globaly processes about 1.000.000 daily hits. > > The global stats show about 30 Internal server errors daily, I don't > > know if a segfault can cause an Internal Server Error on the client (I > > suppose not, if the server dies, cannot send the 505), but the numbers > > don't match anyway. > > > > I think a coredump will help me understand why it segfaults, but I don't > > know how to make apache dump a coredump, I've tried a lot of recipes > > found on internet with any success. Making things more complicated, this > > problems only happens on the production systems, (Suppose only on some > > pages...) so I cannot reproduce it on my test system. > > > > So, my question is... There is any way to force apache to dump a > > coredump file? I suppose I'm forgotting something but I really > > desperate... > > > > A secondary question is, some of the servers transforms all UTF8 strings > > with "garbage" when some Segfault happens (Seems like double-encoded > > UTF8, the page shows 3 or 4 chars for every UTF8 char...). The only way > > to solve this is reboot the machine completely. > > Is that related to this same problem? Or is an obscure UTF8 perl/Apache > > problem? > > > > Many thanks, > > I'm using mod_perl 1.29 with apache 1.3.31. > > My perl conf: > > > > Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: > > Platform: > > osname=linux, osvers=2.4.20-2.48smp, > > archname=i386-linux-thread-multi > > uname='linux str' > > config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -g > > -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red > > Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux > > -Dvendorprefix=/usr -Dsiteprefix=/usr > > -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads > > -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db > > -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio > > -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less > > -isr' > > hint=recommended, useposix=true, d_sigaction=define > > usethreads=define use5005threads=undef' > > useithreads=define usemultiplicity= > > useperlio= d_sfio=undef uselargefiles=define usesocks=undef > > use64bitint=undef use64bitall=un uselongdouble= > > usemymalloc=, bincompat5005=undef > > Compiler: > > cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS > > -DDEBUGGING -fno-strict-aliasing -I/usr/local/include > > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', > > optimize='', > > cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING > > -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' > > ccversion='', gccversion='3.2.2 20030213 (Red Hat Linux 8.0 > > 3.2.2-1)', gccosandvers='' > > gccversion='3.2.2 200302' > > intsize=e, longsize= , ptrsize=p, doublesize=8, byteorder=1234 > > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > > ivtype='long' > > k', ivsize=4' > > ivtype='long' > > known_ext, nvtype='double' > > o_nonbl', nvsize=, Off_t='', lseeksize=8 > > alignbytes=4, prototype=define > > Linker and Libraries: > > ld='gcc' > > l', ldflags =' -L/usr/local/lib' > > ldf' > > libpth=/usr/local/lib /lib /usr/lib > > libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil > > perllibs= > > libc=/lib/libc-2.3.1.so, so=so, useshrplib=true, libperl=libper > > gnulibc_version='2.3.1' > > Dynamic Linking: > > dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef, ccdlflags='-rdynamic > > -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' > > cccdlflags='-fPIC' > > ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s > > Unicode/Normalize XS/A' > > > > > > Characteristics of this
Re[2]: [mp2] "Unrecognized character" error when running scripts inutf-8
Hi everybody,
I hope this message will find its way to the thread I started on the list.
Thanks a lot to all the participants of the discussion, the problem was indeed
in this BOM part of the scripts. Markus Wichitill <[EMAIL PROTECTED]> has
recommended to use popular shareware editor UltraEdit, which has two .ini
options that prevent the adding of UTF-8 BOMs.
To those interested I put a more detailed error report which appeared in the
log after I added
use Carp;
$SIG{__DIE__} = \&Carp::confess;
to my startup.pl file, as had been recommended by Stas Bekman <[EMAIL
PROTECTED]>
[error] 2092: ModPerl::PerlRun: Unrecognized character \xEF at
C:/shttps/CGI-FRLS/METSA/GET_LIST.PL line 1.
eval 'package
ModPerl::ROOT::ModPerl::PerlRun::C_3a_shttps_CGI_2dFRLS_METSA_GET_LIST_2ePL;sub
handler {local $0 = \'C:/shttps/CGI-FRLS/METSA/GET_LIST.PL\';
#line 1 C:/shttps/CGI-FRLS/METSA/GET_LIST.PL
use utf8;
binmode(STDOUT, ":raw:utf8");
print "Content-Type: text/html\\n\\n";
print "hello";
}
;' called at C:/Perl/site/lib/Apache2/ModPerl/RegistryCooker.pm line 665
ModPerl::RegistryCooker::compile('ModPerl::PerlRun=HASH(0x6c3384)',
'SCALAR(0x7c8388)') called at
C:/Perl/site/lib/Apache2/ModPerl/RegistryCooker.pm line 374
ModPerl::RegistryCooker::convert_script_to_compiled_handler('ModPerl::PerlRun=HASH(0x6c3384)')
called at C:/Perl/site/lib/Apache2/ModPerl/RegistryCooker.pm line 145
ModPerl::RegistryCooker::default_handler('ModPerl::PerlRun=HASH(0x6c3384)')
called at C:/Perl/site/lib/Apache2/ModPerl/PerlRun.pm line 16
ModPerl::PerlRun::handler('ModPerl::PerlRun',
'Apache::RequestRec=SCALAR(0x6c32b8)') called at
C:/shttps/CGI-FRLS/METSA/GET_LIST.PL line 1
eval {...} called at C:/shttps/CGI-FRLS/METSA/GET_LIST.PL line 1
Terminating on signal SIGTERM(15)
Attached please find a sample of a BOMed script.
Please feel free to report the error/fix suggestion to the developers of the
corresponding modules. I believe you will be able to do it much more
professionally than me ;-)
Thanks again for your help!
Igor K.
-Original Message-
From: Markus Wichitill <[EMAIL PROTECTED]>
To: Igor Kudashev<[EMAIL PROTECTED]>
Date: Sun, 07 Nov 2004 16:37:59 +0100
Subject: Re: [mp2] "Unrecognized character" error when running scripts inutf-8
>
> Igor Kudashev wrote:
> > I use the Windows' Notepad and save the file as utf-8. Everything works
> > fine while I run the script from the command line or through CGI without
> > mod_perl.
> > PROBLEM: When I try to run the script using mod_perl, I get the following
> > ERROR:
> >
> > [error] 3320: ModPerl::PerlRun: Unrecognized character \xEF at
> > .../CGI-FOO/TEST.PL line 1.
>
> Looks like the various ModPerl::RegistryCooker-based modules don't like a
> UTF-8 Byte Order Marker (BOM, "EF BB BF") at the start of the script
> (verified with 1.99_17). So until that can be fixed in a future version,
> you'll have to use an editor that can save files without a BOM, or remove
> those three bytes manually.
>
test.pl
Description: Binary data
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: posting announcement?
[EMAIL PROTECTED] wrote: Sorry for the question but is it okay to post an announcement here? If a modperl related-one? then yes. feel free to post it to me first if you aren't sure. there is also the announcement list, but it seems that most things never make it to the list, since the moderators aren't quick getting things approved. in any case, the list is: http://perl.apache.org/maillist/announce.html -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Protecting against Cookie copying
All, I'm looking into ways of uniquely identifying a computer. I've been reading around the web looking at different mechanisms, and so far I've drawn a fuzzy blank. Currently, I want to use SSL to let a user sign in and then I return a session cookie, which I then use to confirm the user is logged in when they come to non-ssl pages. What I wish to do is prevent another user copying the session cookie, from one computer to another, and then gaining access. Originally I wondered if I could get at the mac address of the connection, but that seems to be a dead end. After a little further reading It seems that there is a UUID generated at the handshake? stage of SSL, so therefore I wonder if I can use this, e.g. map my session_id to a UUID, and then when I check the session is valid I crosscheck this, however I'm not sure if I can get the UUID over a non-SSL connection. I'm sure I'm not the first person to want to uniquely identify a computer that comes to my site, without blindly trusting cookies, but I'm at a loss of how to find anything better than ipaddress to session cookie mapping. (which is kinda pointless for Natted addresses I know). Does anybody have any ideas, pointers...? Regards Marty ___ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to get a core dump
Well at last the core where produced. When called gdb with the httpd executable and the core file, gdb shows this: Core was generated by `/usr/eBD/bin/httpd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/tls/libpthread.so.0...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 .. .. .. Loaded symbols for /usr/eBD/perl//i386-linux-thread-multi/auto/DBD/ODBC/ODBC.so Reading symbols from /usr//lib/libodbc.so.1...done. Loaded symbols for /usr//lib/libodbc.so.1 Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so #0 0x4018de75 in Perl_hv_free_ent (my_perl=0x85ba6d8, hv=0xd103fd0, entry=0xcfdb698) at hv.c:1592 1592hv.c: No such file or directory. in hv.c (gdb) This hv.c error is because gdb didn't find this file? Or this is really the originator of the Segfault? On dv, 2004-11-05 at 13:38, Marc Gracia wrote: > Hi everybody. > I have a problem on a production cluster with a somewhat big mod_perl > app, and I just cannot get any clue of what is happening. > > The problem is that the servers just exit with Segmentation fault > randomly. > The problem is rare, hapens 10/20 times each day in each of the 6 > frontends, which globaly processes about 1.000.000 daily hits. > The global stats show about 30 Internal server errors daily, I don't > know if a segfault can cause an Internal Server Error on the client (I > suppose not, if the server dies, cannot send the 505), but the numbers > don't match anyway. > > I think a coredump will help me understand why it segfaults, but I don't > know how to make apache dump a coredump, I've tried a lot of recipes > found on internet with any success. Making things more complicated, this > problems only happens on the production systems, (Suppose only on some > pages...) so I cannot reproduce it on my test system. > > So, my question is... There is any way to force apache to dump a > coredump file? I suppose I'm forgotting something but I really > desperate... > > A secondary question is, some of the servers transforms all UTF8 strings > with "garbage" when some Segfault happens (Seems like double-encoded > UTF8, the page shows 3 or 4 chars for every UTF8 char...). The only way > to solve this is reboot the machine completely. > Is that related to this same problem? Or is an obscure UTF8 perl/Apache > problem? > > Many thanks, > I'm using mod_perl 1.29 with apache 1.3.31. > My perl conf: > > Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: > Platform: > osname=linux, osvers=2.4.20-2.48smp, > archname=i386-linux-thread-multi > uname='linux str' > config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -g > -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red > Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux > -Dvendorprefix=/usr -Dsiteprefix=/usr > -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads > -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db > -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio > -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less > -isr' > hint=recommended, useposix=true, d_sigaction=define > usethreads=define use5005threads=undef' > useithreads=define usemultiplicity= > useperlio= d_sfio=undef uselargefiles=define usesocks=undef > use64bitint=undef use64bitall=un uselongdouble= > usemymalloc=, bincompat5005=undef > Compiler: > cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS > -DDEBUGGING -fno-strict-aliasing -I/usr/local/include > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', > optimize='', > cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING > -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' > ccversion='', gccversion='3.2.2 20030213 (Red Hat Linux 8.0 > 3.2.2-1)', gccosandvers='' > gccversion='3.2.2 200302' > intsize=e, longsize= , ptrsize=p, doublesize=8, byteorder=1234 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > ivtype='long' > k', ivsize=4' > ivtype='long' > known_ext, nvtype='double' > o_nonbl', nvsize=, Off_t='', lseeksize=8 > alignbytes=4, prototype=define > Linker and Libraries: > ld='gcc' > l', ldflags =' -L/usr/local/lib' > ldf' > libpth=/usr/local/lib /lib /usr/lib > libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil > perllibs= > libc=/lib/libc-2.3.1.so, so=so, useshrplib=true, libperl=libper > gnulibc_version='2.3.1' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef, ccdlflags='-rdynamic > -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' > cccdlflags='-fPIC' > ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s > Unicode/Normalize XS/A' > > > Characteristics of this binary (from li
Re: How to get a core dump
Sorry, here the backtrace... #0 0x4018de75 in Perl_hv_free_ent (my_perl=0x85ba6d8, hv=0xd103fd0, entry=0xcfdb698) at hv.c:1592 #1 0x4018e11b in S_hfreeentries (my_perl=0x85ba6d8, hv=0x85ba6d8) at hv.c:1681 #2 0x4018e182 in Perl_hv_undef (my_perl=0x85ba6d8, hv=0xd103fd0) at hv.c:1707 #3 0x401a4367 in Perl_sv_clear (my_perl=0x85ba6d8, sv=0xd103fd0) at sv.c:5051 #4 0x401a49e4 in Perl_sv_free (my_perl=0x85ba6d8, sv=0xd103fd0) at sv.c:5226 #5 0x4019be83 in do_clean_all (my_perl=0x85ba6d8, sv=0xd103fd0) at sv.c:422 #6 0x4019bba2 in S_visit (my_perl=0x85ba6d8, f=0x4019be40 ) at sv.c:314 #7 0x4019bee3 in Perl_sv_clean_all (my_perl=0x85ba6d8) at sv.c:440 #8 0x4012fa04 in perl_destruct (my_perl=0x85ba6d8) at perl.c:796 #9 0x400be0f3 in perl_shutdown (s=0x809979c, p=0xa1d9fd4) at mod_perl.c:294 #10 0x400c0ca1 in perl_child_exit (s=0x809979c, p=0xa1d9fd4) at mod_perl.c:965 #11 0x400c0958 in perl_child_exit_cleanup (data=0xd103fd0) at mod_perl.c:933 #12 0x08051976 in run_cleanups (c=0xa1da164) at alloc.c:1936 #13 0x08050104 in ap_clear_pool (a=0xa1d9fd4) at alloc.c:650 #14 0x08050178 in ap_destroy_pool (a=0xa1d9fd4) at alloc.c:680 #15 0x0805ea10 in clean_child_exit (code=0) at http_main.c:519 #16 0x08061ef5 in child_main (child_num_arg=7) at http_main.c:4558 #17 0x08062659 in make_child (s=0x809979c, slot=7, now=1099922742) at http_main.c:5051 #18 0x080629bc in perform_idle_server_maintenance () at http_main.c:5236 #19 0x08063068 in standalone_main (argc=1, argv=0xb0c4) at http_main.c:5499 ---Type to continue, or q to quit--- #20 0x080636cf in main (argc=1, argv=0xb0c4) at http_main.c:5767 #21 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6 On dv, 2004-11-05 at 13:38, Marc Gracia wrote: > Hi everybody. > I have a problem on a production cluster with a somewhat big mod_perl > app, and I just cannot get any clue of what is happening. > > The problem is that the servers just exit with Segmentation fault > randomly. > The problem is rare, hapens 10/20 times each day in each of the 6 > frontends, which globaly processes about 1.000.000 daily hits. > The global stats show about 30 Internal server errors daily, I don't > know if a segfault can cause an Internal Server Error on the client (I > suppose not, if the server dies, cannot send the 505), but the numbers > don't match anyway. > > I think a coredump will help me understand why it segfaults, but I don't > know how to make apache dump a coredump, I've tried a lot of recipes > found on internet with any success. Making things more complicated, this > problems only happens on the production systems, (Suppose only on some > pages...) so I cannot reproduce it on my test system. > > So, my question is... There is any way to force apache to dump a > coredump file? I suppose I'm forgotting something but I really > desperate... > > A secondary question is, some of the servers transforms all UTF8 strings > with "garbage" when some Segfault happens (Seems like double-encoded > UTF8, the page shows 3 or 4 chars for every UTF8 char...). The only way > to solve this is reboot the machine completely. > Is that related to this same problem? Or is an obscure UTF8 perl/Apache > problem? > > Many thanks, > I'm using mod_perl 1.29 with apache 1.3.31. > My perl conf: > > Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: > Platform: > osname=linux, osvers=2.4.20-2.48smp, > archname=i386-linux-thread-multi > uname='linux str' > config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -g > -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red > Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux > -Dvendorprefix=/usr -Dsiteprefix=/usr > -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads > -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db > -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio > -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less > -isr' > hint=recommended, useposix=true, d_sigaction=define > usethreads=define use5005threads=undef' > useithreads=define usemultiplicity= > useperlio= d_sfio=undef uselargefiles=define usesocks=undef > use64bitint=undef use64bitall=un uselongdouble= > usemymalloc=, bincompat5005=undef > Compiler: > cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS > -DDEBUGGING -fno-strict-aliasing -I/usr/local/include > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', > optimize='', > cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING > -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' > ccversion='', gccversion='3.2.2 20030213 (Red Hat Linux 8.0 > 3.2.2-1)', gccosandvers='' > gccversion='3.2.2 200302' > intsize=e, longsize= , ptrsize=p, doublesize=8, byteorder=1234 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > ivtype='long' > k', ivsize=4' > ivtype='long'
Re: How to get a core dump
Yes, I've just taked in account that it happens at clean-up time, at perl shutdown. So I suppose that's nothing wrong with this. Don't know why, I supposed it was related to the GTopLimit automatic server kill. Now I see that it can be true. My intention was to try to find out if this coredumps where related to the sudden change of UTF8 codification, which is the main problem I have now. Once this happens the only solution is to reboot the entire machine. Some Segfault like that can lead to a glibc or iconv library corruption? The fact that a reboot is needed makes me suspect that glibc is involved. It's right this assumption? Many thanks again. On dl, 2004-11-08 at 15:48, David Hodgkinson wrote: > On 8 Nov 2004, at 14:39, Marc Gracia wrote: > >> So, my question is... There is any way to force apache to dump a > >> coredump file? I suppose I'm forgotting something but I really > >> desperate... > > Yes. > > As root, you need to do the ulimit magic and then start the server. > > My question is: do you *really* need to debug this? For sure, the > process > has got its knickers in a twist, but this is happening at cleanup time > anyway and not during any request. > > I'm sure you have better things to worry about. > > Cheers, > > Dave > -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Protecting against Cookie copying
Disclaimer: the following is all "to the best of my knowledge". Take it for what it's worth. On 8-Nov-04, at 9:27 AM, Martin Moss wrote: so therefore I wonder if I can use this, e.g. map my session_id to a UUID, and then when I check the session is valid I crosscheck this, however I'm not sure if I can get the UUID over a non-SSL connection. Assuming you're talking about the SSL session-id, that is only available over an SSL connection. Even with SSL connections, there is actually nothing stopping the client from opening more than one SSL connection and therefore having more than one SSL connection-id. So that seems to me like a dead end. I'm sure I'm not the first person to want to uniquely identify a computer that comes to my site, without blindly trusting cookies, but I'm at a loss of how to find anything better than ipaddress to session cookie mapping. (which is kinda pointless for Natted addresses I know). It is very hard to trust anything that comes in over a non-ssl connection. If you are concerned about security, I'd recommend using ssl consistently throughout the session. This will at least deal with the case where cookies are stolen by monitoring the connection (assuming you've taken adequate care to avoid man-in-the-middle attacks). Stealing a session cookie from the client's cookie jar is harder to protect against. On the other hand, it is perhaps not so easy to do. One might think that a security-conscious browser would not commit session cookies to disk, but I don't know which (if any) browsers do this (and in any event, it may be possible to snatch them out of memory, or through some XSS hack.) All the same, session cookies with SSL are a reasonably secure mechanism; "good enough" unless you are running a site which requires a very high degree of security. In the latter case, you probably want to investigate client SSL certificates and/or other high-grade security solutions. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
modperl@perl.apache.org
Hi, I have 2 modules Login.pm and Application.pm configured to handle 2 URLs /path/login and /path respectively through the directive. However, for some reason going to /path/login first invokes Application::handler, which in turn redirects the browser to /path/login (because a cookie is not set). Is there a way to have /path/login go directly to its handler (Login.pm) and just /path to Application.pm? On a different note, this is all done from within a frame and after the redirect from /path to /path/login the frameset dissappears. $r->headers_out->set(Location => '/path/login'); return Apache::REDIRECT; Should I be doing something differently? Thanks in advance. Arshavir P.S. I am using modperl 1.99_16. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: CGI_GATEWAY - modperl version 2
Thxs Stas for the right answer. I thought => I was right sorry :) I never knew that PerlHandler would work in mod_perl 2. Good to know, thxs Stas Bekman wrote: Cure wrote: PerlHandler is a mod_perl 1 directive. PerlResponseHnalder is a mod_perl 2 directive. Both work just fine under mp2, unless compiled with MP_COMPAT_1X=0 http://perl.apache.org/docs/2.0/user/install/install.html#MP_COMPAT_1X replace --> PerlHandler ModPerl::Registry with PerlResponseHandler ModPerl::Registry It won't make any difference to the asked question :) The link posted earlier: http://perl.apache.org/docs/2.0/user/porting/compat.html#C__ENV_GATEWAY_INTERFACE__ is the right answer... -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to get a core dump
On 8 Nov 2004, at 14:39, Marc Gracia wrote: So, my question is... There is any way to force apache to dump a coredump file? I suppose I'm forgotting something but I really desperate... Yes. As root, you need to do the ulimit magic and then start the server. My question is: do you *really* need to debug this? For sure, the process has got its knickers in a twist, but this is happening at cleanup time anyway and not during any request. I'm sure you have better things to worry about. Cheers, Dave -- Dave Hodgkinson CTO, Rockit Factory Ltd. http://www.rockitfactory.com/ Web sites for rock bands -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
What is the correct Apache, mod_perl, and Apache::ASP version combination?
We are trying out an application that worked in Apache 1 in Apache 2 and it's getting an "internal error or misconfiguration" and "200 OK" error. The message on the bottom of the error page shows Apache/2.0.52 (Win32) mod_perl/1.99_17 Perl/v5.8.4 mod_jk2/2.0.4 Server at csrstest Port 88 Do we have the correct version combination or Apache, mod_perl, and Apache::ASP (2.55) ? Please be patient with me -- newbie. Waldo Tumanut Database Analyst CONFIDENTIALITY NOTICE: This electronic transmission (including any accompanying attachments) is intended solely for its authorized recipient(s), and may contain confidential and/or legally privileged information. If you are not an intended recipient, or responsible for delivering some or all of this transmission to an intended recipient, be aware that any review, copying, printing, distribution, use or disclosure of the contents of this message is strictly prohibited. If you have received this electronic message in error, please contact us immediately by electronic mail at [EMAIL PROTECTED] or notify us immediately by telephone at 1-800-345-2021 or 816-531-5575 and destroy the original and all copies of this transmission (including any attachments). Thank you. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Protecting against Cookie copying
On Mon, 8 Nov 2004, Martin Moss wrote: > I'm looking into ways of uniquely identifying a > computer. Intel tried to implement this a while back with a unique ID in the CPU. The public was not ammused. If you do find a way, please tell us so we can find a workaround. > What I wish to do is prevent another user copying the > session cookie, from one computer to another, and then > gaining access. You can get close by using a very short session timeout, tying the IP to the cookie and putting a serial number on each form. I believe this is what my bank does. Sure, the IP can be spoofed or shared, and hackers can automate systems to defeat the timeouts and serial numbers, but it definitely raises the bar. As an added bonus, the serial numbers also help with the ubiquitous catastrophe which is the back button. -sam -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: What is the correct Apache, mod_perl, and Apache::ASP version combination?
Hi, To help you we have see at least the output of your error-log and the relevant parts of the httpd.conf. Tom [EMAIL PROTECTED] wrote: We are trying out an application that worked in Apache 1 in Apache 2 and it's getting an "internal error or misconfiguration" and "200 OK" error. The message on the bottom of the error page shows Apache/2.0.52 (Win32) mod_perl/1.99_17 Perl/v5.8.4 mod_jk2/2.0.4 Server at csrstest Port 88 Do we have the correct version combination or Apache, mod_perl, and Apache::ASP (2.55) ? Please be patient with me -- newbie. Waldo Tumanut Database Analyst CONFIDENTIALITY NOTICE: This electronic transmission (including any accompanying attachments) is intended solely for its authorized recipient(s), and may contain confidential and/or legally privileged information. If you are not an intended recipient, or responsible for delivering some or all of this transmission to an intended recipient, be aware that any review, copying, printing, distribution, use or disclosure of the contents of this message is strictly prohibited. If you have received this electronic message in error, please contact us immediately by electronic mail at [EMAIL PROTECTED] or notify us immediately by telephone at 1-800-345-2021 or 816-531-5575 and destroy the original and all copies of this transmission (including any attachments). Thank you. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Moving STDOUT to a new handle?
Hello everyone, I am currently workning on writing a CMS system, and as such I'd like to prevent user modules from outputting data directly instead of using the method supplied by the system. The way I would like to this is opening a new filehandle in the mian module (lexically scoped so noone else can get at it) and then retying STDOUT to a module that logs all attempts to use the filehandle. Now, having done my research I found that STDOUT is tied to the Apache class, and that simply duping STDOUT isn't sufficient (it doesn't conserve the tie). I also found that saying tie *NEWOUT, "Apache"; doesn't do the necessary magic to make the new handle work. So, is there a way I can move STDOUT to a new handle, or do I have no other choice than to say "please don't use direct output"? Thanks in advance, Arne :wq -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
SV: Moving STDOUT to a new handle?
> This might be a lame response, but I would first look at CGI::Application > and see how they go about doing this. It's a good idea, but having looked at the code on CPAN it seems that CGI::Application doesn't do anything with STDOUT, it only states (repeatedly) that at no point should anyone call print() on STDOUT. And, as I think of it, I don't think it'd be terribly useful as CGI::Application is intended for use with CGI scripts, not mod_perl handlers. Arne :wq -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: SV: Moving STDOUT to a new handle?
On Mon, Nov 08, 2004 at 07:17:21PM +0100, Arne Skjaerholt wrote: > And, as I think of it, I don't think it'd be terribly useful as > CGI::Application is intended for use with CGI scripts, not mod_perl > handlers. This is not true. Several folks on the C::A list, including myself, are using it in conjunction with mod_perl. In fact, Michael Peters has just released a plugin to make it even more mod_perl friendly (including the use of Apache::* modules rather than CGI.pm). However, I agree that it does not provide a technical solution to your problem. William -- Knowmad Services Inc. http://www.knowmad.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re:
On Mon, 2004-11-08 at 10:45, Arshavir Grigorian wrote: > Is there a way to have /path/login go directly to its handler (Login.pm) > and just /path to Application.pm? Make sure you define the most specific one, i.e. /path/login/, last. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Protecting against Cookie copying
On Mon, 2004-11-08 at 09:27, Martin Moss wrote: > What I wish to do is prevent another user copying the > session cookie, from one computer to another, and then > gaining access. If you're talking about packet sniffing attacks, use SSL and call it a day. If you're talking about a technically advanced user who has access to your site signing in with LWP or similar and then moving the cookie to another machine, forget it. There is nothing you can do to prevent this that won't cause problems for some segment of potential users. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re:
Perrin Harkins wrote: On Mon, 2004-11-08 at 10:45, Arshavir Grigorian wrote: Is there a way to have /path/login go directly to its handler (Login.pm) and just /path to Application.pm? Make sure you define the most specific one, i.e. /path/login/, last. - Perrin Thanks, Perrin. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
SV: SV: Moving STDOUT to a new handle?
> From: Rob Kinyon [EMAIL PROTECTED] > FYI: C::A has a plugin that will make it work (mostly) seamlessly with > mod_perl called CGI::Application::Apache. Hmm. I can't find CGI::Application::Apache on CPAN, only CGI::Application::Plugin::Apache, which, unfortunately for me, doesn't do any STDOUT magic either. Arne :wq -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Moving STDOUT to a new handle?
On Mon, 2004-11-08 at 12:15, Arne Skjaerholt wrote: > So, is there a way I can move STDOUT to a new handle Sounds like you're looking for Apache::Filter or Apache::OutputChain. There is also a discussion of this in the eagle book: http://perl.apache.org/docs/offsite/books.html#Writing_Apache_Modules_with_Perl_and_C - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: What is the correct Apache, mod_perl, and Apache::ASP version combination?
Tom Schindl wrote: Hi, To help you we have see at least the output of your error-log and the relevant parts of the httpd.conf. Better always point users to: http://perl.apache.org/bugs/ :) Thanks -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to get a core dump
Marc Gracia wrote: Sorry, here the backtrace... #0 0x4018de75 in Perl_hv_free_ent (my_perl=0x85ba6d8, hv=0xd103fd0, entry=0xcfdb698) at hv.c:1592 #1 0x4018e11b in S_hfreeentries (my_perl=0x85ba6d8, hv=0x85ba6d8) at hv.c:1681 #2 0x4018e182 in Perl_hv_undef (my_perl=0x85ba6d8, hv=0xd103fd0) at hv.c:1707 #3 0x401a4367 in Perl_sv_clear (my_perl=0x85ba6d8, sv=0xd103fd0) at sv.c:5051 #4 0x401a49e4 in Perl_sv_free (my_perl=0x85ba6d8, sv=0xd103fd0) at sv.c:5226 #5 0x4019be83 in do_clean_all (my_perl=0x85ba6d8, sv=0xd103fd0) at sv.c:422 #6 0x4019bba2 in S_visit (my_perl=0x85ba6d8, f=0x4019be40 ) at sv.c:314 #7 0x4019bee3 in Perl_sv_clean_all (my_perl=0x85ba6d8) at sv.c:440 #8 0x4012fa04 in perl_destruct (my_perl=0x85ba6d8) at perl.c:796 #9 0x400be0f3 in perl_shutdown (s=0x809979c, p=0xa1d9fd4) at mod_perl.c:294 #10 0x400c0ca1 in perl_child_exit (s=0x809979c, p=0xa1d9fd4) at mod_perl.c:965 #11 0x400c0958 in perl_child_exit_cleanup (data=0xd103fd0) at mod_perl.c:933 It's hard to tell whether this is a bug in perl or some module that you use. Shutdown bugs are really hard to deal with. If you could reproduce that at will, trying to eliminate modules, programs should help to find the guilty party. Since things happen at the server shutdown, you could set a low limit on the max number of requests served before retiring the process. Also could you try to upgrade to 5.8.5 just to check that may be it's some bug that was fixed in perl since 5.8.0? -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] "Unrecognized character" error when running scripts inutf-8
Игорь Кудашев wrote: Hi everybody, I hope this message will find its way to the thread I started on the list. Thanks a lot to all the participants of the discussion, the problem was indeed in this BOM part of the scripts. Markus Wichitill <[EMAIL PROTECTED]> has recommended to use popular shareware editor UltraEdit, which has two .ini options that prevent the adding of UTF-8 BOMs. It's now documented here: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#Registry_scripts_fail_to_load_with__Unrecognized_character__xEF_at Special thanks go to Markus :) __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: What is the correct Apache, mod_perl, and Apache::ASP version combination?
On Mon, 8 Nov 2004 [EMAIL PROTECTED] wrote: > We are trying out an application that worked in Apache 1 in Apache 2 and > it's getting an "internal error or misconfiguration" and "200 OK" error. > The message on the bottom of the error page shows > Apache/2.0.52 (Win32) mod_perl/1.99_17 Perl/v5.8.4 mod_jk2/2.0.4 Server at > csrstest Port 88 > > Do we have the correct version combination or Apache, mod_perl, and > Apache::ASP (2.55) ? Please be patient with me -- newbie. There's a mailing list for Apache::ASP, linked thru http://www.apache-asp.org/, for general quesions. However, this particular problem has come up on the mod_perl mailing list before - try upgrading Apache::ASP (we have it in our ppm repository at http://theoryx5.uwinnipeg.ca/ppms/), which should fix this problem. -- best regards, randy kobes -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Protecting against Cookie copying
Thanks everyone. You've done a good job of assuring me that I haven't missed the whole point of the way these things work. There's been some really useful ideas, suggested and I'm going to have a think about which, if any, are worth implementing. Ultimitely I'm upgrading our site from normal Basic authentication, which sends username and password unencrypted anyway, so compared to that the security upgrade is still a big increase! Marty --- Sam Tregar <[EMAIL PROTECTED]> wrote: > On Mon, 8 Nov 2004, Martin Moss wrote: > > > I'm looking into ways of uniquely identifying a > > computer. > > Intel tried to implement this a while back with a > unique ID in the > CPU. The public was not ammused. If you do find a > way, please tell > us so we can find a workaround. > > > What I wish to do is prevent another user copying > the > > session cookie, from one computer to another, and > then > > gaining access. > > You can get close by using a very short session > timeout, tying the IP > to the cookie and putting a serial number on each > form. I believe > this is what my bank does. Sure, the IP can be > spoofed or shared, and > hackers can automate systems to defeat the timeouts > and serial > numbers, but it definitely raises the bar. As an > added bonus, the > serial numbers also help with the ubiquitous > catastrophe which is the > back button. > > -sam > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: > http://perl.apache.org/maillist/modperl.html > List etiquette: > http://perl.apache.org/maillist/email-etiquette.html > > ___ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
ANNOUNCE Project XP 1.0.0.delta
[ANNOUNCE] Project XP v 1.0.0-delta has been released. This is a test release, a prototype. Release version: 1.0.0.delta Feel free to download from http://www.gh-webinteractive.com/Projectxp-1.0.0-delta.tar.gz http://www.gh-webinteractive.com FAQ: Q:What is Project XP? A:Project XP is a web based tool for extreme programmers, hence the name XP. It is the authors understanding and implementation of the eXtreme Programming (XP) development methodology. Q:For whom is Project XP? A:It is intended as a help tool for smallish teams of around 5-10 people, doing development according to the light weight eXtreme Programming ( XP ) development methodology. Q:Can Project XP be found at CPAN? A:No, not yet. The current development release can't be found there yet, but probably in the future. Q:What do I need to run Project XP? A:Perl+Apache+mod_perl+XML capable browser+MySQL database Q:Has Project XP been tested on various platforms and browsers? A:Project XP has only been tested on two plaforms, windows 2000 (TM) and Linux SuSE version 9.0. What concerns XML then there are some browser dependent issues, for example the Windows Explorer version 5.0 has difficulties showing links in a proper way when using XML, while it works fine on e.g. Konqueror. This is due to the poor implementation of XML in Explorer 5.0. Q:What licence does Project XP use? A:GPL Enjoy! Thank you. Best Regards, Greger Haga -- www.gh-webinteractive.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
