RE: [ANNOUNCE] Apache2-AuthenNTLM-0.01
>Try the new version that was just uploaded: Apache2-AuthenNTLM-0.02. I >tested the download, and it worked. I'm not sure what happened with the >previous version, as I had successfully installed and used the module, >and all of the files that it complained about were there... Shannon, You're great. It's working fine now, I'm very be satisfied with your software. It looks very good and we want use your software for production Cordys software. Thanks for your help!! Best Regards, Gert Jan Schipper http://www.cordys.com ** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. **
Re: [mp2] aborted() method doesn't work in RC5
Nick Wellnhofer wrote: I get the following error message if I try to call the method aborted() using the new RC5: Can't locate object method "aborted" via package "Apache2::Connection" RC4 worked fine. Add: use Apache2::Connection (); before calling aborted(). -- __ 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
changing permissions in order to write a file in Mod_perl
I'm sending this question to the beginners perl list and the mod_perl list as I'm not sure where it belongs. In short: I'm trying to work out how to create a directory/file under a specific user. This is running on MP2 on Apache2 with suexec enabled. The vhost has: SuexecUserGroup myuser myuser When trying to create the file I get a permissions error. I'm trying to create folders and files in the public_html folder who's perms are: drwxr-x--- 4 myuser apache 512 Apr 29 11:31 public_html The uid and gid for the folder: public_html: uid = 1009, gid = 1003 the perl scripts (module that's a handler in fact) uid and gid: Real: uid = 1004, gid = 1003 1003 1003 Effective: uid = 1004, gid = 674124656 1003 1003 The control Panel (Direct Admin) created the public_html folder under group apache, so I assume all sites will be created with that folder under group apache. Other files/folders created via ftp/file upload are user and group myuser. So I'd like to be able to create folders and files under user/group myuser and not havae to create them under group apache. so that site's don't have access to each others files. So it seems my mod_perl modules are running under a different user than the suexec setting in httpd.conf Do I have to open up the permissions (ie make group apache writeable for the folder) or is there some way I can temoprarily switch to uid 1009, make my files, and then switch back to 1004. Or would this be a really bad (crossing the beams kind of bad). TIA
Apache::Session::Store::Postgres FOR UPDATE problems
Honored MPs!
I've taken over maintenance of AxKit::XSP::BasicSession from Mike
Nachbaur, but Mike still contributes and we've been discussing some
problems with it over the past few days.
A:X:BS lets Apache::Session do most of its hard work. However, it seems
like no users have ever gotten it to work with a PostgreSQL backend.
I'm trying to address that now.
On the surface, the symptom is that for certain pages, it will just sit
and spin at the $self->{materialize_sth}->execute; call in
Apache::Session::Store::Postgres for exactly two minutes, then time
out, and that makes the rest of the app confused, so most things go
boom...
We've been banging our heads against this problem in #axkit-dahut for a
couple of days now, and I created the following Pg log:
http://paste.husk.org/3133
Then, I realized at had to read up on what "FOR UPDATE" means. It means
that it'll lock and wait around for a subsequent UPDATE.
So, I'm guessing that what happens is that it sits and waits for a
UPDATE that never happens. I tried to remove the FOR UPDATE from the
SQL statement, and it solves the immediate problem. But FOR UPDATE is
something that is used for transactional integrity, and so, it is
probably a Good Thing and there is probably a good reason why it is
there... So, I'm turning to you with the hope that you can clue me in
to how I can live with it. :-)
A:X:BS is now on CPAN, the latest version is 0.23_3 and previous
versions has had some problems, so this is the one I'm working on. I
realized the Pg store would need different defaults than the others,
and I have also been experimenting with the Commit stuff, in case that
meant something. I've been testing with stuff like
# When using Postgres, a different default is needed.
if ($flex_options{'Store'} eq 'Postgres') {
$flex_options{'Commit'} = 1;
$flex_options{'AutoCommit'} = 1;
$flex_options{'Serialize'} = $r->dir_config( $prefix . 'Serialize' ) ||
'Base64'
}
with no effect
I guess it could be that the use we make of Apache::Session is flawed,
that we should call an update somewhere, but it works (apparently) with
the other data stores. It feels like there is something in the
direction of transactions but I can't figure out what... Or, if it
could be somebody else's bug, relieve me of the feeling of being
stupid... :-)
Clues are most welcome!
Cheers,
Kjetil
--
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
Re: Apache::Session::Store::Postgres FOR UPDATE problems
Kjetil Kjernsmo wrote:
On the surface, the symptom is that for certain pages, it will just sit
and spin at the $self->{materialize_sth}->execute; call in
Apache::Session::Store::Postgres for exactly two minutes, then time
out, and that makes the rest of the app confused, so most things go
boom...
This probably means that in a previous request you never let the session
object go out of scope so it kept the exclusive lock open.
So, I'm guessing that what happens is that it sits and waits for a
UPDATE that never happens. I tried to remove the FOR UPDATE from the
SQL statement, and it solves the immediate problem. But FOR UPDATE is
something that is used for transactional integrity, and so, it is
probably a Good Thing and there is probably a good reason why it is
there...
It creates an exclusive lock on that row. This may or may not be
necessary, depending on how you use sessions in your application.
I guess it could be that the use we make of Apache::Session is flawed,
that we should call an update somewhere
You just have to let the object get destroyed so it can release the lock.
- Perrin
Re: changing permissions in order to write a file in Mod_perl
Does suexec work under MP2? http://perl.apache.org/docs/2.0/user/intro/overview.html#What_s_new_in _Apache_2_0 On 29 Apr 2005 at 14:48, angie ahl wrote: > I'm sending this question to the beginners perl list and the mod_perl > list as I'm not sure where it belongs. > > In short: I'm trying to work out how to create a directory/file under > a specific user. > > This is running on MP2 on Apache2 with suexec enabled. The vhost has: > > SuexecUserGroup myuser myuser > > When trying to create the file I get a permissions error. > > I'm trying to create folders and files in the public_html folder who's > perms are: drwxr-x--- 4 myuser apache 512 Apr 29 11:31 public_html > > > The uid and gid for the folder: > public_html: uid = 1009, gid = 1003 > > the perl scripts (module that's a handler in fact) uid and gid: > Real: uid = 1004, gid = 1003 1003 1003 > Effective: uid = 1004, gid = 674124656 1003 1003 > > > The control Panel (Direct Admin) created the public_html folder under > group apache, so I assume all sites will be created with that folder > under group apache. > > Other files/folders created via ftp/file upload are user and group > myuser. > > So I'd like to be able to create folders and files under user/group > myuser and not havae to create them under group apache. so that site's > don't have access to each others files. > > So it seems my mod_perl modules are running under a different user > than the suexec setting in httpd.conf > > Do I have to open up the permissions (ie make group apache writeable > for the folder) or is there some way I can temoprarily switch to uid > 1009, make my files, and then switch back to 1004. Or would this be a > really bad (crossing the beams kind of bad). > > TIA > ~~ Dermot Paikkos * [EMAIL PROTECTED] Network Administrator @ Science Photo Library Phone: 0207 432 1100 * Fax: 0207 286 8668
Re: [ANNOUNCE] Apache2-AuthenNTLM-0.01
Shannon, You're great. It's working fine now, I'm very be satisfied with your software. It looks very good and we want use your software for production Cordys software. Thanks for your help!! I'm glad to help :) -- Shannon Eric Peevey President - EriKin Corporation [EMAIL PROTECTED] (940) 391-6777 http://www.erikin.com
for a background process and return
Hi
I am try to run something like this in my cgi.
-
system ("sleep 3000 &");
---
Since, it is time-consuming task, I let it run in background and
immediately return to user. I tested this script. It was no problem for
a standalone perl script. However, once I had this script in a perl cgi.
The script seemed not to have this system command run in background. It
waited there for the child process to finish.
Any clue for why it behaved like that? How can I for a child process in
background and return immediately to the web user?
Help is really appreciated!
jason zhang
Re: changing permissions in order to write a file in Mod_perl
So the scripts running under user apache and group apache, and the site's files are suexec user/group myuser/myuser how do you write files without permissions errors. Am I right in saying that if suexec were working right then the uid and gid in the handler should be returning those for the user/group that's in the suexec. If so then I guess it's not working. Really annoying as it's the final hurdle in well over a years work. :( Cheers Angie
Re: changing permissions in order to write a file in Mod_perl
I really don't know but I was just trying to set up something similar here and noticed that under MP1 you certainly couldn't, see this article: http://perl.apache.org/docs/1.0/guide/install.html#Is_it_possible_to_r un_mod_perl_enabled_Apache_as_suExec_ And then I saw this on changes on MP2: "perchild The perchild MPM is similar to the worker MPM, but is extended with a mechanism which allows mapping of requests to virtual hosts to a process running under the user id and group configured for that host. This provides a robust replacement for the suexec mechanism. META: as of this writing this mpm is not working" It looks like suexec is not an option. There maybe an alternitive in the future though. Perhaps someone else with more knowledge on MP could answer your question better than I can. Dp. On 29 Apr 2005 at 17:38, angie ahl wrote: > So the scripts running under user apache and group apache, and the > site's files are suexec user/group myuser/myuser how do you write > files without permissions errors. > > Am I right in saying that if suexec were working right then the uid > and gid in the handler should be returning those for the user/group > that's in the suexec. > > If so then I guess it's not working. > > Really annoying as it's the final hurdle in well over a years work. :( > > Cheers > > Angie >
Apache2::Status bug?
Hello, I have finished (I hope) installing mod_perl rc5 under Windows 2000, and I have tried the server using http://localhost/perl-status. I was able to use it very well, until I have tried to see the following links in order: Loaded Modules - Apache::Const - Apache::Const::OK - Syntax Tree Dump (execution order) After the last link, the server gave a 404 Not found error. The error log told that 0 worker threads exited, and that 250 worker threads were started successfully. (Why there were no worker threads running?) I have restarted the server using "apache -k restart" and I have tried again to access http://localhost/perl-status/ but the page was still "Not found". (The error log was showing again that 0 threads exited and 250 worker threads started.) So I have restarted the server using "apache -k stop" and "apache -k start". Well, this time I was able to use /perl-status again, and I have navigated directly to that link with problems, but it gave the following error: 200 OK Syntax Tree Dump (execution) for Apache2::Const::OK Apache2::Const::OK: OK The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.0.53 (Win32) PHP/5.0.0 mod_perl/1.999.22 Perl/v5.8.6 Server at localhost Port 80 --- In the error log, the only error was: [Fri Apr 29 19:17:00 2005] [error] [client 127.0.0.1] err: coderef has no START\n, referer: http://localhost/perl-status/Apache2::Const::OK/FUNCTION?cv_dump --- I have also tried the following links in order: Loaded Modules - Apache::Const - Apache::Const::OK - - Syntax Tree Dump (syntax order) But it gave me the following error in the log file: [Fri Apr 29 19:42:20 2005] [error] [client 127.0.0.1] err: unknown function (main::slow)\n, referer: http://localhost/perl-status/Apache2::Const::OK/FUNCTION?cv_dump --- Could this be a bug, or I need to change something in the script to make it compatible with Windows? Thank you. Teddy
Re: changing permissions in order to write a file in Mod_perl
There are 2 options of course: 1) change the apache UID and GIU 2) install mod_cgi; that does allow suexec from what I have read. I don't know if the performance is the same though. On 29 Apr 2005 at 17:48, angie ahl wrote: > Thanks for trying though. The last hurdle's always the toughest one. Yeap that final 10% is a killer. Dp. > > > On 4/29/05, Dermot Paikkos <[EMAIL PROTECTED]> wrote: > > I really don't know but I was just trying to set up something > > similar here and noticed that under MP1 you certainly couldn't, see > > this article: > > http://perl.apache.org/docs/1.0/guide/install.html#Is_it_possible_to > > _r un_mod_perl_enabled_Apache_as_suExec_ > > > > And then I saw this on changes on MP2: > > > > "perchild > > > > The perchild MPM is similar to the worker MPM, but is extended with > > a mechanism which allows mapping of requests to virtual hosts to a > > process running under the user id and group configured for that > > host. This provides a robust replacement for the suexec mechanism. > > > > META: as of this writing this mpm is not working" > > > > It looks like suexec is not an option. There maybe an alternitive in > > the future though. Perhaps someone else with more knowledge on MP > > could answer your question better than I can. Dp. > > > > > > > > On 29 Apr 2005 at 17:38, angie ahl wrote: > > > > > So the scripts running under user apache and group apache, and the > > > site's files are suexec user/group myuser/myuser how do you write > > > files without permissions errors. > > > > > > Am I right in saying that if suexec were working right then the > > > uid and gid in the handler should be returning those for the > > > user/group that's in the suexec. > > > > > > If so then I guess it's not working. > > > > > > Really annoying as it's the final hurdle in well over a years > > > work. :( > > > > >
[mp2] Problems with Apache::Request
I've been having problems with the Apache::Request module (from
libapreq2) and mod_perl2 for a while now and I've not come up with a
decent solution. I am using the Debian packages but I didn't get a
response from the maintainer so I hope someone here can enlighten me.
This is with libapreq2-2.04_03-dev and mod_perl2 1.999.21-1 but I've
had similar problems with earlier versions.
I have a very simple mod_perl handler:
package Jadevine::Hello;
use Apache2;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::Request ();
use Apache::Const -compile => qw(OK);
sub handler {
my $r = shift;
$r->content_type('text/plain');
print "mod_perl 2.0 rocks!\n";
return Apache::OK;
}
1;
This is loaded in the Apache config with:
SetHandler perl-script
PerlResponseHandler Jadevine::Hello
If I remove the "use Apache::Request" line everything works
fine. Leaving it there, or actually trying to use the methods provided
by the module give the error:
[error] [client 127.0.0.1] failed to resolve handler `Jadevine::Hello':
Apache::Request: httpd must load mod_apreq.so first at
/usr/lib/perl5/Apache2/Apache/Request.pm line 31.\nCompilation failed in
require at /usr/local/lib/site_perl/Jadevine/Hello.pm line 5.\nBEGIN
failed--compilation aborted at /usr/local/lib/site_perl/Jadevine/Hello.pm line
5.\nCompilation failed in require at (eval 3) line 3.\n
I have tried putting the "use" statements in every order imaginable
without any joy so I'm not sure what the error is trying to get me to
do to correct the problem.
I can see where the error comes from in the Apache::Request code:
my $env = __PACKAGE__->env || '';
if ($mod_perl::VERSION > 1.99) {
die __PACKAGE__ . ": httpd must load mod_apreq.so first"
if $env ne "Apache::RequestRec";
}
For the record $env contains 'APR::Pool', not sure if this is what
should be there or not.
Any help would be much appreciated, thanks in advance,
Stephen Quinney
Re: [mp2] Problems with Apache::Request
> [error] [client 127.0.0.1] failed to resolve handler `Jadevine::Hello': > Apache::Request: httpd must load mod_apreq.so first try adding LoadModule apreq_module modules/mod_apreq.so in your httpd.conf. --Geoff
Re: [mp2] Problems with Apache::Request
Stephen Quinney <[EMAIL PROTECTED]> writes: > I have tried putting the "use" statements in every order imaginable > without any joy so I'm not sure what the error is trying to get me to > do to correct the problem. It's a server-config issue. You need to add a LoadModule apreq_module modules/mod_apreq.so where "modules/mod_apreq.so" is the actual path to mod_apreq.so on your box. I don't know how debian has broken up our tarball, so you may need to install some other package that provides mod_apreq.so. I should point out that apreq-dev@ is in the process of releasing a newer version, and the module name has changed to "mod_apreq2.so". So you'll probably have to deal with this problem again once debian picks up 2.05-dev. -- Joe Schaefer
Re: [mp2] modperl2 compile error
Stas, I forgot to mention that apache usually runs under a different account than nobody (I use - apache), in case that matters. Also, I apologize for not cc'ing the list on the last message but I normally use the mail client from my desktop machine instead of this Ximian client on red hat and I am not used to the client not doing the cc for me. Thanks, Tom
Re: Problems with Apache::Request
I'd get upgraded to MP2 1999.22 if I were you. Stas told me I should
as things changed between your version and it, this whole use Apache2
thing has gone:
http://perl.apache.org/docs/2.0/rename.html
I figured I'd have to do it eventually and things are now running smoother.
of course, if you can't you can't.
HTH
Angie
On 4/29/05, Stephen Quinney <[EMAIL PROTECTED]> wrote:
> I've been having problems with the Apache::Request module (from
> libapreq2) and mod_perl2 for a while now and I've not come up with a
> decent solution. I am using the Debian packages but I didn't get a
> response from the maintainer so I hope someone here can enlighten me.
>
> This is with libapreq2-2.04_03-dev and mod_perl2 1.999.21-1 but I've
> had similar problems with earlier versions.
>
> I have a very simple mod_perl handler:
>
> package Jadevine::Hello;
>
> use Apache2;
> use Apache::RequestRec ();
> use Apache::RequestIO ();
> use Apache::Request ();
> use Apache::Const -compile => qw(OK);
>
> sub handler {
> my $r = shift;
> $r->content_type('text/plain');
> print "mod_perl 2.0 rocks!\n";
> return Apache::OK;
> }
> 1;
>
> This is loaded in the Apache config with:
>
>
> SetHandler perl-script
> PerlResponseHandler Jadevine::Hello
>
>
> If I remove the "use Apache::Request" line everything works
> fine. Leaving it there, or actually trying to use the methods provided
> by the module give the error:
>
> [error] [client 127.0.0.1] failed to resolve handler `Jadevine::Hello':
> Apache::Request: httpd must load mod_apreq.so first at
> /usr/lib/perl5/Apache2/Apache/Request.pm line 31.\nCompilation failed in
> require at /usr/local/lib/site_perl/Jadevine/Hello.pm line 5.\nBEGIN
> failed--compilation aborted at /usr/local/lib/site_perl/Jadevine/Hello.pm
> line 5.\nCompilation failed in require at (eval 3) line 3.\n
>
> I have tried putting the "use" statements in every order imaginable
> without any joy so I'm not sure what the error is trying to get me to
> do to correct the problem.
>
> I can see where the error comes from in the Apache::Request code:
>
> my $env = __PACKAGE__->env || '';
> if ($mod_perl::VERSION > 1.99) {
>die __PACKAGE__ . ": httpd must load mod_apreq.so first"
> if $env ne "Apache::RequestRec";
> }
>
> For the record $env contains 'APR::Pool', not sure if this is what
> should be there or not.
>
> Any help would be much appreciated, thanks in advance,
>
> Stephen Quinney
>
>
>
Re: [mp2] Problems with Apache::Request
On Fri, Apr 29, 2005 at 01:56:20PM -0400, Geoffrey Young wrote: > > > [error] [client 127.0.0.1] failed to resolve handler `Jadevine::Hello': > > Apache::Request: httpd must load mod_apreq.so first > > try adding > > LoadModule apreq_module modules/mod_apreq.so > > in your httpd.conf. Ah, brilliant, thanks a lot, I was wondering if I was missing something obvious. I guess I was just expecting the module to work the way it did in mod_perl1. For the record, in Debian a file is provided to make the Apache2 config very simple: /etc/apache2/mods-available/apreq.load, I just needed to symlink this into /etc/apache2/mods-enabled/, restart Apache2 and it all works. Stephen
[ANNOUNCE] Apache2::AuthCookieDBI available
With the help of Lance P Cleveland there is now an Apache2:: version of AuthCookieDBI. Apache2::AuthCookieDBI premiered at version 2.03 and is essentially the same as Apache::AuthCookieDBI 2.02 but works with mod_perl2. --- Matisse Enzer <[EMAIL PROTECTED]> http://www.matisse.net/ - http://www.eigenstate.net/
mod_perl2 + Apache::AuthenNTLM 2.10 + mod_dav_svn
I'm seeing curious behavior on a webserver that hosts several virtual sites. All the sites use Apache::AuthenNTLM very successfully except one that hosts a subversion repository under mod_dav_svn. It appears that all all operations, including ls, co, update, stat, etc operate as expected. all except svn commit. This operation causes the svn command line to pause and ask for a password. examination of the logs shows this: [Fri Apr 29 15:42:07 2005] [error] SMB Server connection not open in state 3 for /repos/!svn/act/9de53425-eaf5-0310-8ecf-f017e7be5f7d [Fri Apr 29 15:42:07 2005] [error] SMB Server connection not open in state 3 for /repos/!svn/act/9de53425-eaf5-0310-8ecf-f017e7be5f7d [Fri Apr 29 15:42:07 2005] [error] SMB Server connection not open in state 3 for /repos/!svn/act/9de53425-eaf5-0310-8ecf-f017e7be5f7d [Fri Apr 29 15:42:13 2005] [error] SMB Server connection not open in state 3 for /repos/!svn/act/9de53425-eaf5-0310-8ecf-f017e7be5f7d It appears that this occurs because of some fancy subrequest behavior that svn commit implements. Am I the first to see this? Is there a known solution? thanks -- Chris Fedde
Re: [mp2] modperl2 compile error
Tom Caldwell wrote: Stas, I forgot to mention that apache usually runs under a different account than nobody (I use - apache), in case that matters. Of course. In which case you need to check 'apache' instead of 'nobody'. Also, I apologize for not cc'ing the list on the last message but I normally use the mail client from my desktop machine instead of this Ximian client on red hat and I am not used to the client not doing the cc for me. No worries. > Yes, I noticed that nobody was having trouble finding libperl.so, but it > seemed very strange that none of the other tests failed. > > Anyway, I tried to > su - nobody > which failed because the shell was set to /sbin/nologin. su - apache > So I fixed that (set shell to bash) and set the .bashrc file to set the > LD_LIBRARY_PATH to > /opt/perl/lib/5.8.6/x86_64-linux/CORE:/opt/apache2/server/lib/:/usr/lib64 > so it can find libperl.so > /opt/perl/bin/perl -V then ran correctly from the nobody account. > > Then I reran the tests and got the same failures here is the test report > (see below). > > Also, I was able to run the 4 scripts in t/htdocs/util - argv.pl > env.pl in_err.pl in_out.pl > > They seemed to work fine except env.pl did not print anything. > > Thanks for looking into this, > > Tom > > P.S. Here is the other info you asked for. > > First line of t/TEST is > #!/opt/perl/bin/perl > > ldd /opt/perl/bin/perl > libperl.so => /opt/perl/lib/5.8.6/x86_64-linux/CORE/libperl.so > (0x002a9566d000) is it possible that this path it not readable by user 'apache'? I doubt so, since all other tests run just fine. what if you change one of these scripts (.e.g. t/htdocs/argv.pl) to be: #!/bin/sh printenv > /tmp/dump ldd /opt/perl/bin/perl >> /tmp/dump and run the subprocess test? This will show what the environment this subprocess script is running under. -- __ 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
