Re: __floatdisf: error Compling mod_perl 1.27,apache 1.3.26 on Solaris 8 with gcc 2.95.2
[EMAIL PROTECTED] wrote: Hello, I'm not having a great day here! :-( For me, it was a few weeks ago, when I posted the same question. :) Trying to install mod_perl 1.27 with apache 1.3.26 and perl 5.8.0 on Solaris 8 using gcc 2.95.2. Same versions as me, except gcc is 2.95.3. :) I keep getting the following error when I run make test in the mod_perl source tree: internal/http-get.Internal Server Error internal/http-postInternal Server Error Same errors I get. My main concern is the first error though. I've tried many options and settings and browsed the archives but I'm still not able to get this working. :-( I treied everything I could think of too. I finally got it to work by adding this to the Apache Configure command: --disable-shared=perl This will build a static mod_perl into your httpd binary, but keep everything else DSO, since you have --enable-shared=max . I know it sucks, so that is why I am sticking with perl 5.6.1 for the time being, as a mod_perl with that works as a DSO on Solaris 8. :( -- David McCabe Network and Communications Services, McGill University Montreal, Quebec, Canada [EMAIL PROTECTED] In theory there is no difference between theory and practice. In practice there is. -Yogi Berra
Re: -Wl,-E
Ihor Bilyy wrote: After applying that patches error message is the same. ld -V: ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.275 This is OK. The Configure script for perl looks for ld: Software Generation Utilities, so it should find it. btw gcc --version 2.95.2, maybe problem is with gcc ? I use 2.95.3, from the package at sunfreeware.com. What does perl -V show? It should show you a bunch of info, with a section that looks something like this: Linker and Libraries: ld='gcc', ldflags ='-R/opt/BerkeleyDB/lib:/opt/lib -L/opt/BerkeleyDB/lib ' libpth=/opt/BerkeleyDB/lib /usr/lib /usr/ccs/lib /usr/local/lib libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Anything you try to build to add to your perl which has C code (like mod_perl) will try to use the same compiler and linker options that were used to build perl. So if you used the Gnu ld, (which you would see in the ldflags of the Linker section above), then mod_perl will try to build with that linker. (FYI, the ldflags that I use above are so I do not ever have to set LD_LIBRARY_PATH in the environment) Did you build perl on the same box, with the same compiler?? If it was built somewhere else, and transfered over, you will have to either rebuild perl from source, or build mod_perl with the original perl, and then transfer it over, made much easier if you use a prefix to build and install perl into one dir. I do this with a prefix of /opt/perl5. Then I can just xfer that whole sub-dir (using rsync and ssh) to any other box with the same OS version. -- David McCabe Network and Communications Services, McGill University Montreal, Quebec, Canada [EMAIL PROTECTED] In theory there is no difference between theory and practice. In practice there is. -Yogi Berra
Re: -Wl,-E
Ihor Bilyy wrote:
Hello!
I can't build apache 1.3.26 with mod_perl 1.27 on Solaris 2.8
I use:
/usr/ccs/bin/ld: illegal option -- E
usage: ld [-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:] file(s)
Sun put out a patch to their linker (ld) that breaks the Configure script for
perl. It checks for a specific info string output from the ld command, and
decides from that if you are using Sun's ld, or the Gnu ld. Since that patch
changes the output of the ld command's info string, Configure thinks you are
using Gnu's ld, and hence sets up the Gnu ld options to pass to Sun's ld.
Obviously, this doesn't work. Sun has since fixed it, by another patch that puts
back the old info string in their ld.
The patch to ld that broke this is 109147-14. The 109147-16 patch fixes it
again.
Update these Solaris patches and your problem should go away. :)
--
David McCabe Network and Communications Services, McGill University
Montreal, Quebec, Canada [EMAIL PROTECTED]
In theory there is no difference between theory and practice.
In practice there is. -Yogi Berra
*** perl-5.6.1/hints/solaris_2.sh Thu Jan 31 13:55:18 2002
--- perl-5.6.1/hints/solaris_2.sh.orig Fri Jan 25 19:56:05 2002
***
*** 199,209
# egcs-1.0.3, GNU as 2.9.1 and GNU ld 2.9.1
# --Andy Dougherty [EMAIL PROTECTED]
# Tue Apr 13 17:19:43 EDT 1999
- # Patch 109147-14 for Solaris 8 (and probably same patch on other
- # versions, the Link Patch) changes a string that is output by ld and
- # checked for here. I added another elsif block to test for the new string.
- # David McCabe [EMAIL PROTECTED]
- # Friday Jan 25 20:02:00 EDT 2002
# Get gcc to share its secrets.
echo 'main() { return 0; }' try.c
--- 199,204
***
*** 244,252
# All Solaris versions of ld I've seen contain the magic
# string used in the grep.
:
- # NEW BLOCK FOR SOLARIS LINK PATCH - exception to above comment :)
- elif echo $verbose | grep ld: Solaris Link Editors: /dev/null 21; then
- :
else
# No evidence yet of /usr/ccs/bin/ld. Some versions
# of egcs's ld wrapper call /usr/ccs/bin/ld in turn but
--- 239,244
Mod Perl build problem with perl 5.8.0
I am having a problem building mod_perl with the new perl 5.8.0. This does not occur with perl 5.6.1. (All DSO, BTW) I build using the CPAN module, with a .makepl_args.mod_perl file in my $HOME dir. This has worked just fine for years, through multiple versions of perl, mod_perl, Apache, and Solaris. Now, when the make test of mod_perl is run, I see this: internal/http-get.Internal Server Error internal/http-get.dubious Test returned status 29 (wstat 7424, 0x1d00) DIED. FAILED tests 1-16 Failed 16/16 tests, 0.00% okay internal/http-postInternal Server Error internal/http-postdubious Test returned status 29 (wstat 7424, 0x1d00) DIED. FAILED tests 1-7 Failed 7/7 tests, 0.00% okay All other tests pass just fine, And in the error_log, I see these: (besides the 'expected' errors) [Tue Jul 23 10:48:15 2002] [error] Undefined subroutine Apache::exit called at /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/test line 129, fh1b chunk 1. print() on closed filehandle FH at /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/hooks.pl line 15, fh1b line 1. print() on closed filehandle FH at /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/hooks.pl line 26, fh1b line 1. [Tue Jul 23 10:48:16 2002] [error] can't open /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/docs/.htaccess at /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/hooks.pl line 51, fh1b line 1. [Tue Jul 23 10:48:18 2002] [error] END block was not run for /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/test [Tue Jul 23 10:48:20 2002] [error] END block was not run for /opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/test This is with perl 5.8.0, mod_perl 1.27, Apache 1.26, and Solaris 8. I build all this from source, (except Solaris!!:), using gcc 2.95. Apache is compiled with these options passed to Configure by the .makepl_args.mod_perl file: ( as well as some site-specific options, like --prefix=, etc) --enable-module=all --enable-shared=max --disable-module=example --disable-module=auth_db --verbose --server-uid=httpd --server-gid=www (the auth_db module will not build with Berkeley DB 4.x, which is what I have to use for other apps on the same machine. Fortunately, I do not use that module, so I don't care. :) perl -V: Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris uname='sunos rapier 5.8 generic_108528-14 sun4u sparc sunw,sun-blade-100 ' config_args='-Dcc=gcc -Ubincompat5005 -Uuselargefiles -Uusemymalloc -Dloclibpth=/opt/BerkeleyDB/lib -Uinstallusrbinperl -Dprefix=/opt/perl5.8.0-mod-perl-Apache-1.3.26 -Dscriptdir=/opt/perl5.8.0-mod-perl-Apache-1.3.26/scripts [EMAIL PROTECTED] -Dldflags=-R/opt/BerkeleyDB/lib:/opt/lib -Dmydomain=.mcgill.ca -Dmyhostname=rapier [EMAIL PROTECTED] -Dlocincpth=/opt/BerkeleyDB/include -Dcf_by=David McCabe -d' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/opt/BerkeleyDB/include', optimize='-O', cppflags='-fno-strict-aliasing -I/opt/BerkeleyDB/include' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='solaris2.8' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags ='-R/opt/BerkeleyDB/lib:/opt/lib -L/opt/BerkeleyDB/lib' libpth=/opt/BerkeleyDB/lib /usr/lib /usr/ccs/lib /usr/local/lib libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -R/opt/BerkeleyDB/lib:/opt/lib -L/opt/BerkeleyDB/lib' Characteristics of this binary (from libperl): Compile-time options: Built under solaris Compiled at Jul 22 2002 12:12:58 @INC: /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/McGill/sun4-solaris /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/McGill /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/5.8.0/sun4-solaris /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/5.8.0 /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/site_perl/5.8.0/sun4-solaris /opt/perl5.8.0-mod-perl-Apache-1.3.26/lib
Re: Apache.pm location on installation
From: "Sinclair, Alan (CORP, GEAccess)" [EMAIL PROTECTED] Date: Wed, 24 Jan 2001 11:10:21 -0700 Subject: Apache.pm location on installation All, I have successfully installed mod_perl on Solaris. The mod_perl installation process has installed the Apache.pm module in the perl lib directory. Is that normal? I was expecting the Apache perl stuff to be installed under APACHE_PREFIX. Normal. The perl stuff (even related to Apache) has to be installed in the perl lib dir for perl to find it. The perl that is embedded into your Apache is the same perl that is on your system, so it needs the same libs, and uses the same lib paths. The binaries, config files, man pages, libs, etc, for Apache are installed in APACHE_PREFIX. David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 How can we (men) possibly use sex to get what we want?? Sex _is_ what we want!!! Dr Frasier Crane
Re: Upgrading mod_perl on production machine (again)
From: Steve Reppucci [EMAIL PROTECTED] Date: Tue, 16 Jan 2001 11:02:44 -0500 (EST) Subject: Re: Upgrading mod_perl on production machine (again) I've always handled the support of multiple perl versions by installing new versions of perl using a prefix like /usr/local/perl/5.6.0, etc., (I also place CPAN's build directory under that tree.) This makes it easy to install and test new versions of perl without affecting running applications that have been built against a previous perl version, as well as making it possible to test with specific versions just by referencing the appropriate version in the script's shebang line (or by setting my PATH appropriately when building mod_perl.) That is what I do as well. Plus, I use the prefix arg to build Apache as well, so a new mod_perl/Apache gets installed in a different dir than the current one when I run make install. I then copy over my config files to the new dir, and set up the new Apache to listen on a different port, then test it. Once tested, I point the sym-links for both Apache and perl to the new locations. This is whole process is scripted for me, for both Solaris and AIX, and works great on both. (There are differences in the scripts, though, because of differences in the OS) BTW, for making sure you get all the modules your old perl had, look at the CPAN module, which has a "autobundle" command to create a Bundle file from your old perl installation, that you can then use with your new perl, by doing a "install Bundle::BundleName". David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 How can we (men) possibly use sex to get what we want?? Sex _is_ what we want!!! Dr Frasier Crane
Re: Finding out what has been enabled on a mod perl server
From: Kevin Beckford [EMAIL PROTECTED] Date: Tue, 16 Jan 2001 13:19:16 -0500 Subject: Finding out what has been enabled on a mod perl server Hello all, I need to find out what has been enabled on my production server. I want to use method handlers, but I am unsure if that has been compiled in. How would I do this? I don't have the access to install mod-status - so the easy way is not for me... Apachedir/bin/httpd -l David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 How can we (men) possibly use sex to get what we want?? Sex _is_ what we want!!! Dr Frasier Crane
Re: mod-perl on Solaris 2.6
From: Jeff Beard [EMAIL PROTECTED] Date: Mon, 08 Jan 2001 12:48:58 -0700 (MST) Subject: Re: mod-perl on Solaris 2.6 Check out the mailing list archive for something I posted a while back. It boiled down to not using GNU binutils for anything. Including GCC. Partly, I agree. Gcc is fine for Solaris 2.5, 7 and 8, if you use the package from sunfreeware.com, and install all relevant patches. Don't use any other gnu bintools though, especially not the linker. (Well, at least not with a "stock" Solaris system. :) I have been building perl for years with that combo, and mod_perl/Apache for just over a year, and while it does require that you know what you are doing, (and it certainly sounds like Siddhartha does), it always works fine for me. Siddhartha, have you tried the $HOME/.makepl_args.mod_perl file-method to build mod_perl/Apache?? If you set this file up properly, you can build/install mod_perl/Apache with the standard: perl Makefile.pl make make test make install all from within the mod_perl distribution dir. This is documented in the INSTALL document of the mod_perl distribution, and there is a commented sample/template in eg/makepl_args.mod_perl (note there is no leading . here) of the distribution. (And once Doug relases another version of mod_perl with no _ in the version number, you will be able to do "install mod_perl" from the CPAN shell, which downloads and builds the latest versions of everything, hopefully:) Also, make sure your LD_LIBRARY_PATH and PATH vars are set properly. (I have never had to use the LD_PRELOAD var, and I build a lot of software for Solaris from C source) If you use tcsh, (or any shell that supports it) try "which perl" and "which gcc", and "whereis perl" and "whereis gcc", and make sure that you are really getting what you think. And make sure that any sym-links/links (like maybe /usr/bin/perl) point to where you want them. I always try to make sure that my build environments can only see what I want them to see, and no other versions of anything. One other thing, look at the output of perl -V, and see if the flags to gcc for building perl are the same as what are being passed to gcc for building mod_perl/Apache. They should be, but something might be screwing them up in your enviornment, so check anyway. :) David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 "We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the works of Shakespeare. Now, thanks to the Internet, we know this is not true." - Robert Wilensky UCB
Re: Apache Version 1.3.0 required, aborting...
From: Joshua Gerth [EMAIL PROTECTED] Date: Wed, 27 Dec 2000 14:05:14 -0800 (PST) Subject: Apache Version 1.3.0 required, aborting... I am doing a 100% fresh install. I just downloaded mod_perl-1.24.tar.gz apache_1.3.14.tar.gz Am I doing something wrong? Am I not using the correct version of something? Yes, and yes. :):) You need mod_perl-1.24_01.tar.gz. You can get it by going to search.cpan.org, and enter "mod_perl" as the search term. Or, use this URL with a perl/LWP script, or wget, or something similiar: http://www.cpan.org/authors/id/DOUGM/mod_perl-1.24_01.tar.gz David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 "We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the works of Shakespeare. Now, thanks to the Internet, we know this is not true." - Robert Wilensky UCB
Re: How to use gcc to build mod_perl
From: Jason Liu [EMAIL PROTECTED] Date: Fri, 20 Oct 2000 04:30:14 -0700 Subject: How to use gcc to build mod_perl Hi, I was trying to build mod_perl 1.24_01 and apache 1.3.14. I used the following command: perl Makefile.PL make test make install The Makefile wants to use the "cc" compiler. Can I use "gcc" instead? It probably wants to use cc because your perl was built with cc. Is this on Solaris 8, with Sun's perl?? If so, rebuild perl yourself with gcc, and use that perl instead. (Unless you have the Sun cc, in which case you can use that for all your modules) If you use different compilers for different modules, you are asking for problems. Beleive me, I have tried. :):) David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 "Serving children is our specialty. Approximate time to prepare: 45 minutes." Sign in Jack Astors resto/pub
Exiting a module
OK, I can't find the answer to this in the docs, so I will try here.
Relevant info:
Solaris 8
(the following were all built with gcc 2.95.2 from sunfreeware.com)
perl 5.6.0
mod_perl 1.24
Apache 1.3.12
In my Module, I have an error-displaying sub, as I trap all the errors myself. My
current code looks something like this:
(this is in a sub called from the handler() sub)
if (! ($sth = $dbh-prepare_cached($sql)))
{
my_error_prnt(...);
return;
}
This works fine. The my_error_prnt() sub is using the CGI module to output a nice
HTML page, with some error messages passed to it. I then return to this sub, then
return to the handler(), which then "falls out" through my code.
However, if I try to put an Apache::exit() at the end of my_error_prnt, I get a
server error, and the error log only says "error at line 202" line 202 has the
Apache::exit call. I want to do this so I can code all my error traps like this:
my_error_prnt() unless ($sth = $dbh-prepare_cached($sql));
And get rid of all the loops that need to exist just for a "return;" statement
I have also tried with Apache::exit(Apache::Constants::OK), but no difference.
Any ideas on how I can do this??
David McCabe Unix System Administrator
Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433
"Serving children is our specialty. Approximate time to
prepare: 45 minutes."
Sign in Jack Astors resto/pub
Re: Exiting a module
From: Bill Moseley [EMAIL PROTECTED] Date: Thu, 19 Oct 2000 11:24:23 -0700 Subject: Re: Exiting a module To: [EMAIL PROTECTED] (David McCabe), [EMAIL PROTECTED] At 02:19 PM 10/19/00 -0400, David McCabe wrote: However, if I try to put an Apache::exit() at the end of my_error_prnt, I get a server error, and the error log only says "error at line 202" line 202 has the Apache::exit call. This was fixed in 1.24_01, I believe. Hope so, I started downloading the new mod_perl just before sending that last email, and I will try it out later. Thanx. David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 "Serving children is our specialty. Approximate time to prepare: 45 minutes." Sign in Jack Astors resto/pub
Re: Exiting a module
From: [EMAIL PROTECTED] (David McCabe) Subject: Re: Exiting a module From: Bill Moseley [EMAIL PROTECTED] Subject: Re: Exiting a module At 02:19 PM 10/19/00 -0400, David McCabe wrote: However, if I try to put an Apache::exit() at the end of my_error_prnt, I get a server error, and the error log only says "error at line 202" line 202 has the Apache::exit call. This was fixed in 1.24_01, I believe. Hope so, I started downloading the new mod_perl just before sending that last email, and I will try it out later. Thanx. OK, I got the new mod_perl, and at the same time upgraded to Apache 1.3.14, and all is well again. Thanx. :) David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 "Serving children is our specialty. Approximate time to prepare: 45 minutes." Sign in Jack Astors resto/pub
Re: FreeBSD: semwai state Help..
From: Jeff Gleixner [EMAIL PROTECTED] Date: Tue, 27 Jun 2000 14:23:20 -0500 Subject: FreeBSD: semwai state Help.. To: [EMAIL PROTECTED] Hi All, I'm having a very strange problem and am hoping someone on here can help. I'm running a typical Apache(1.3.6), mod_perl(1.21), Mason(0.81), mySQL set-up on 4 big RAM machines (database is on other machines). I start up the servers and after a few minutes the state of the processes ends up as "semwai" and the apache processes just stop taking requests. Here's a quick glance at some output from top: 50201 www -4 0 15544K 10352K semwai 0:00 0.00% 0.00% apache 50249 www -4 0 15432K 10280K semwai 0:00 0.00% 0.00% apache 50227 www -4 0 15428K 9808K semwai 0:00 0.00% 0.00% apache I am not familiar with that state from top, but it looks like it is waiting for a semaphore. I would suggest reading up on shared memory segments and semaphores, in whatever kernel manuals you have for your OS. I know that on Solaris, I have to up the default values quite a bit to get things to work with Oracle properly. This makes sense too, as an OS should not be tuned for db access unless necessary, so the default config is fine for non-db access apps. :):) David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. Programming Perl, Chapter 8, Programming with Style
Re: perl use of malloc()
From: Doug MacEachern [EMAIL PROTECTED] Date: Thu, 20 Apr 2000 14:04:09 -0700 (PDT) Subject: Re: shrinking memory (was Re: Modperl/Apache deficiencies... Memory usage.) On Tue, 18 Apr 2000, Stas Bekman wrote: What do you say? 1003520 bytes are returned to OS when @x goes out of scope. Note that this doesn't happen if you use a global @x instead. because under linux Perl defaults to system malloc: % perl -V:usemymalloc usemymalloc='n'; This implies that on another OS, the system malloc() might be different? Right?? if usemymalloc='y', then Perl uses Perl's malloc, in which case memory is not returned to the os. Now, does this mean that if usemyalloc='y', memory is not returned to the OS, no matter what the OS is, or is this OS dependent as well?? David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 "PHP is training wheels ... without the bike." Randal Schwartz, on comp.lang.perl.misc
Re: RE: does ssl encrypt basic auth?
From: [EMAIL PROTECTED] Date: Sun, 06 Feb 2000 11:11:37 +0100 Subject: RE: does ssl encrypt basic auth? To: [EMAIL PROTECTED] Ed Loehr wrote: Is a basic authentication password, entered via a connection to an https/SSL server, encrypted or plain text across the wire? Encrypted - but that question really doesn't belong here. It has nothing to do with modperl. Yes, it is off-topic, but I am replying anyway, because you are slightly wrong. :) If the first connection to a web site causes the authentication to be activated, the password is _NOT_ encrypted. A successfull connection has to be established with a secure web site before the encryption is turned on. After the first connection, every other connection is then encrypted. The best way to ensure the password is encrypted is to have one unprotected page to go to, with links to the protected parts. Client connects to that page, encryption is on. Click on a link to a protected area, authentication goes on, but everything is now encrypted, including username/password given for authentication. David McCabe Unix SysAdmin/Peon Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 Who were the beta testers for Preparations A through G?
Re: does ssl encrypt basic auth?
From: "Jeffrey W. Baker" [EMAIL PROTECTED] Date: Sun, 06 Feb 2000 09:55:06 -0800 Subject: Re: does ssl encrypt basic auth? Do you have some documentation on that? I say you are smoking crack. When I set up my first secure site four years ago, the bank involved, (a major national bank in Canada) insisted their tests proved what I said, and they had concerns about the Cybercash admin pages for the store owners to admin their databases. I set it up the way I said, and we passed their tests. Maybe things are different with webservers now, but then, with the software we used (true, it was not a Netscape server), the authentication was activated before the ssl. :( You are right, I should do some tests now, and see what webservers do what now. I hope ssl first, like you quoted. We use a lot of SecurID authentication here, even for web, so encryption of the password is not really an issue anymore. :) Now we are really off-topic. Lets kill it. David McCabe Unix SysAdmin/Peon Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 Who were the beta testers for Preparations A through G?
Re: .makepl_args.mod_perl
From: Bakki Kudva [EMAIL PROTECTED]
Date: Fri, 04 Feb 2000 11:52:43 -0500
Subject: Re: .makepl_args.mod_perl
To: modperl-list [EMAIL PROTECTED]
Thank you, Eric. Looks like the Eagle book has an error then. Is there an
errata for it some where? I don't see it on their home page.
It's makepl_args.mod_perl, not .makepl_args.mod_perl (no leading dot)
From the eg/makepl_args.mod_perl file, included in the mod_perl 1.21 distribution:
#example makepl_args.mod_perl files
#copy this file to $ENV{HOME}/.makepl_args.mod_perl and edit to taste
#mod_perl's Makefile.PL will also look for this file in ./ ../ relative
#to the mod_perl-x.xx source tree
So both work, depending on where the file is. I use the .makepl... form, in my $HOME
dir, so that I don't have to edit a new one for every new version. :)
David McCabe Unix SysAdmin/Peon
Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433
Hard work pays off in the future. Laziness pays off now.
Steven Wright
Re: module/sandwich kills otherwise nice make test
From: [EMAIL PROTECTED] Date: Fri, 04 Feb 2000 16:30:13 -0500 (EST) Subject: module/sandwich kills otherwise nice make test To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hello, I searched the mod_perl archive and couldn't find any instances where module/sandwich (which I don't need or want) was the one test which failed in the installation of mod_perl. Then remove the Apache::Sandwich module from your system, and reconfigure/rebuild/retest mod_perl. Try a "make uninstall" in the source dir of Apache::Sandwich, after you run a perl Makefile.pl there. Without the module, mod_perl will skip that test too, like some of the others. David McCabe Unix SysAdmin/Peon Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 Who were the beta testers for Preparations A through G?
