Re: RSA_PKCS1_RSAref : That old question
On Sat, Dec 02, 2000 at 10:14:51PM -0500, [EMAIL PROTECTED] wrote: > Debian-2.2.17 > Perl-5.6.0 --prefix=/opt > apache_1.3.14 > mod_perl-1.24_01 > mod_ssl-2.7.1-1.3.14 > openssl-0.9.6 > rsaref-2.0 from ftp://www.spinnaker.com/pub/crypt/rsaref Don't use RSAREF. Support for RSAREF was removed from mod_ssl in version 2.7.0-1.3.14 because there is no reason to use it at all. Just rebuild your openssl without RSAREF. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Variable initialization in startup.pl
Hi,
I seem to have an odd problem with variable setup and use. The platform
is apache/mod_perl as per LinuxMandrake 7.1.
Here is the setup:
A) I have a configuration.pm with variable declarations and no "use
strict" similar to this:
...
@array=()
...
%hash=()
...
B) Then I have a library of common routines that make use of these
variables. These include routines to fill these variables with data.
sub fill_array();
sub fill_hash();
C) Now in startup.pl is "use" both packages and call the fill_xyz()
routines.
D) In the mod_perl scripts (the guts of these scripts is again in a
package that gets called by a wrapper .pl script) I "use" both packages
and make use of the data with $value=$configuration::array[] and
$value=$configuration::hash{} ... just reading their values.
The Problem:
The array is filled. The hash is empty.
Any ideas? Workarounds? Tests?
What would be the preferred structure to define static variables that
can be used for all modules and pre-initialized by startup.pl.
Cheers
Andreas
--
| Andreas Schiffler[EMAIL PROTECTED] |
| Senior Systems Engineer-Deskplayer Inc., Buffalo |
| 4707 Eastwood Cres., Niagara Falls, Ont L2E 1B4, Canada |
| +1-905-371-3652 (private) - +1-905-371-8834 (work/fax) |
Re: Apache::DBI problem and writting a perl module!!!
Edmar Edilton da Silva wrote: > I still didn't solve the problem of the Apache::DBI. It can not be > loaded into the apache's startup.pl file because happens a error during > the starting of the apache, the child processes are not created. For > using the Apache::DBI I had to add the "use Apache::DBI ()" code at the > beginning of each perl script. That will not work. You have to load Apache::DBI before DBI, as it says in the documentation. You need to solve the problem you're getting when putting Apache::DBI in your startup.pl. What's the error? Did you compile your Apache/mod_perl from source? Are you using DSO? - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Variable initialization in startup.pl
Andreas Schiffler wrote:
>
> Hi,
>
> I seem to have an odd problem with variable setup and use. The platform
> is apache/mod_perl as per LinuxMandrake 7.1.
>
> Here is the setup:
>
> A) I have a configuration.pm with variable declarations and no "use
> strict" similar to this:
>
> ...
> @array=()
> ...
> %hash=()
> ...
>
> B) Then I have a library of common routines that make use of these
> variables. These include routines to fill these variables with data.
>
> sub fill_array();
> sub fill_hash();
>
> C) Now in startup.pl is "use" both packages and call the fill_xyz()
> routines.
>
> D) In the mod_perl scripts (the guts of these scripts is again in a
> package that gets called by a wrapper .pl script) I "use" both packages
> and make use of the data with $value=$configuration::array[] and
> $value=$configuration::hash{} ... just reading their values.
>
> The Problem:
> The array is filled. The hash is empty.
>
> Any ideas? Workarounds? Tests?
You didn't include enough code here for me to see what you're doing
wrong, but your variable assignments look fishy. Here's a sample of how
to do it:
package SiteConfig;
%hash = (
'name' => 'value',
'name2' => 'value2',
);
# in startup.pl
use SiteConfig ();
# in your module
my $value2 = $SiteConfig::hash{'name2'};
my $entire_hash = %SiteConfig::hash;
my $hash_ref= \%SiteConfig::hash;
- Perrin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RSA_PKCS1_RSAref : That old question
Thanks all. I hadn't properly considered what the combination of "RSA is now free" "openssl-0.9.5a is now openssl-0.9.6" meant. The consequences, no doubt, of spending a couple months programming for the Palm. Thanks again!
Re: Changing a file's UID from within an Apache module?
From: "Tim Tompkins" <[EMAIL PROTECTED]> At 09:55 AM 12/1/00 -0700, you wrote: >I'd put it someplace that is only accessible to the web user if you're going >to do that. > > >From: "Jorge Godoy" <[EMAIL PROTECTED]> >On Wed, 29 Nov 2000, [EMAIL PROTECTED] wrote: >> >> Any ideas about the best way to change the permissions and UID? > >Create an external minimum perl script with the SUID bit set and with >root as it's owner. Use this script to change the file >permissions. > Prior to creating any file, the user would have been authenticated and an authorize module would have supplied the UID to be used for the request in an environment variable. The location of the user's files has to read by Apache so such that it can serve the files (HTML). The rational behind setting the UID of the files (and directories) is to allow each user to be able to create files that are protected from other users who may also be providing files. Each users files are confined to certain sub-directory stubs. >From a security stand point, I have to be careful about restricting access to any external routine that is owned by root which would be used to change the UID of files. Also, others would be very reluctant to install such an external routine. I'm not real keen about implementing an "external minimum" program. I would like to do the task from within the (Apache Perl) module so that it would be "more portable" and would not require any special considerations for installation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Apache::SSI 2.16
The URL http://forum.swarthmore.edu/~ken/modules/archive/Apache-SSI-2.16.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KW/KWILLIAMS/Apache-SSI-2.16.tar.gz size: 24483 bytes md5: 341d1a126296d1b65cb38c5c921ff3a9 --- Changes since 2.15: 2.16 Sun Dec 3 17:43:20 EST 2000 The 'Filter' directive is now properly recognized as case-insensitive. We now use POSIX::strftime() instead of Date::Format::strftime() to format dates. [[EMAIL PROTECTED] (Kent Covert)] The 'echo' directives are now filled in using methods instead of subroutines, so derived classes can change the behavior of 'echo' directives and add new variables by creating new methods. See docs. [[EMAIL PROTECTED] (Kent Covert)] DATE_GMT and DATE_LOCAL variables are now properly formatted according to the 'timefmt'. We behave properly under a HEAD request. --- Thanks to Kent for the help, and thanks to all who replied about using POSIX vs. Date::Format vs. Time::Object vs. Apache::Util. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP Mod_Perl mini-server
Perrin Harkins <[EMAIL PROTECTED]> writes: > On Fri, 3 Nov 2000, Vivek Khera wrote: > > Lately I've been getting very interested in using solid-state disks > > for high-performance issues. They're expensive, but if you need that > > much speed, they're worth it. > > Are they? I tried one once, and it wasn't any faster than my normal disk > because I had so much RAM it was all getting buffered already. If you > don't have enough RAM, it might help, but I suspect these are more > expensive than equivalent amounts of RAM. Solid state disks are very effective for particular applications like mail spools and database logs where the application waits for data to be flushed to disk before continuing. For most normal applications the same effect can be obtained by adding RAM and/or playing with tools like memfs. -- greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing a file's UID from within an Apache module?
>Prior to creating any file, the user would have been authenticated and an authorize module >would have supplied the UID to be used for the request in an environment variable. The location >of the user's files has to read by Apache so such that it can serve the files (HTML). > >The rational behind setting the UID of the files (and directories) is to allow each user to be able >to create files that are protected from other users who may also be providing files. Each users >files are confined to certain sub-directory stubs. Perhaps, I should use the GID instead of the PID to differentiate between users and leave the PID alone. Then perhaps setting the directory permission to 0770 and 0460 for files on creation, along with checking the GID of the files and dirs before any modifcation, could be used to achieve the same effect. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
apache configuration & error logging
hi. Here is situation: 1. I have written Auth, Authz and redirect handlers for user control. They take in information from httpd file via PerlSetVar statement for configuration purposes. They also log information into error logs via $r->log_error 2. I have integrated them to protect certain on the VirtualHost. ErrorLog was setup correctly, everything works fine. 3. I take all the stuff copy over and change approprite paths, and create new VirtualHost directive. ErrorLog is setup correctly. After I restart webserver, there is no messages from my modules into the appropriate error.log or any other error log. How do I fix this? It seems that as I add in the ModPerl authentication code into the new VirtualHost directive, errors stop coming into error log, regarding that particular VirtualHost, but other continue to work fine. Is that weird? The code in new VirtualHost functions correctly, besides inablity to append to the error.log of the virtual host... Pavel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP Mod_Perl mini-server
On 3 Dec 2000, Greg Stark wrote: > Perrin Harkins <[EMAIL PROTECTED]> writes: > > > On Fri, 3 Nov 2000, Vivek Khera wrote: > > > Lately I've been getting very interested in using solid-state disks > > > for high-performance issues. They're expensive, but if you need that > > > much speed, they're worth it. > > > > Are they? I tried one once, and it wasn't any faster than my normal disk > > because I had so much RAM it was all getting buffered already. If you > > don't have enough RAM, it might help, but I suspect these are more > > expensive than equivalent amounts of RAM. > Solid state disks are very effective for particular applications like mail > spools and database logs where the application waits for data to be flushed to > disk before continuing. For most normal applications the same effect can be > obtained by adding RAM and/or playing with tools like memfs. SCREW solid state disks. Get more ram. Depending on the size of your website it might be smart to make a ramdisk of a 200MB in size... would be lightning fast, and apache won't even know about it. For database application with limited growth and size it might be very good thing to do, like a dynamic website, from a content database, that is mirrored from harddrive to the ramdisk on regular basis. Content editing is done straight to the disk, but lock tables and dump the database, and go on like a happy camper... =) NO RAID will be faster than RAM, and if it is, it will cost a price of the new prosche and latency will never be anywhere near ram... so I'd just give it up right now. Raid is good for large amounts of data, but if your site is not over 500MB altogther, just get a linux(or BSD) box fit it with 1G of ram 8G IDE drive and you will be faster than amazon, provided, that you have enough processing power. That is all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
