openinteract-help — For new and current users, we offer support, troubleshooting and assistance.

[Openinteract-help] Can't locate loadable object for HTML::Parser

[Matt O. <ma...@sh...>]

Hello all,

I've spent a frustrating couple of days trying to properly
install and configure OpenInteract, but at least I've been
making incremental progress.  My current issue is this
error, during install_sql:

OpenInteract::Startup::require_module (354) >>  --require error: OpenInteract::SPOPS::DBI                 (from base_user): Can't locate loadable object for module HTML::Parser in @INC (@INC contains: /var/www/infernus.net/oi_test /var/www/infernus.net/oi_test/tmplib /var/www/infernus.net/oi_test/tmplib /usr/libdata/perl/5.00503/mach /usr/libdata/perl/5.00503 /usr/local/lib/perl5/site_perl/5.005/i386-freebsd /usr/local/lib/perl5/site_perl/5.005 .) at /usr/local/lib/perl5/site_perl/5.005/i386-freebsd/HTML/Entities.pm line 79
BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.005/OpenInteract/SPOPS.pm line 8.
BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.005/OpenInteract/SPOPS/DBI.pm line 6.

OpenInteract::Startup::main_initialize (82) >> Some classes were not required!
Error inserting user/group link: DBD::Pg::st execute failed: ERROR:  Cannot insert a duplicate key into unique index sys_group_user_pkey at /usr/local/lib/perl5/site_perl/5.005/SPOPS/SQLInterface.pm line 284.

(Sorry about the long lines.)

What's bugging me is that, as far as I can tell, HTML::Parser
is properly installed.

I'm running Perl 5.005_03 on an x86 FreeBSD 4.5 box.

(Irritatingly, some of the dependencies for Bundle::SPOPS and
Bundle::OpenInteract want to install 5.6.1... so far, I've
told them not to.)

Thanks for any help.

Cheers,
    Matt

Re: [Openinteract-help] Undefined subroutine &OpenInteract::handler called.

[Magnus E. <ma...@he...>]

Hi!

I finally figured out what was wrong, thanks to your tips :-)

My problem was that I'm using Trustix (the redhat based distribution with
focus on security), for the first time in a year and a half, and had
forgotten how secure it really is.. problem was that both cpan and
oi_manage ran with a umask of 077. Took me a while to figure out that cpan
didn't change the umask. 

But now everything is working!
I have a little wish list though ;-)
- Could you make oi_manage change it's umask when we run it? Maybe it's
best to make it an option?
- ApacheStartup.pm or Startup.pm creates tmplib, it should check it's
uid/gid and umask. My apache runs as uid/gid=httpd but the tmplib dir
shows up with 700 root.root, and that doesn't work very well ;-) I just
hacked the module to change umask one line before it creates the
directory, but I reckon it should be done elsewhere and a little more
though-thru...

- Could you make oi_manage understand relative --website_dir (like
--website_dir=.)?


Bugs:
- Typo at line 15 in event-1.20/struct/event.sql (varchar not varcar)


Again, thanks for a great system!! :-)

Cheers!
Magnus Espeland


On 9 Mar 2002, Chris Winters wrote:

> On Fri, 2002-03-08 at 16:49, Magnus Espeland wrote:
> > On 8 Mar 2002, Chris Winters wrote:
> > 
> > > First, look at your error log ($WEBSITE_DIR/logs/error_log_modperl, by
> > > default) and see if anything jumps out at you there.
> > 
> > That's where I found the error ;-)
> 
> Of course :-) I wasn't sure if that was echoed to the browser or not.
> 
> > Ahh, seems like Apache/Session/Generate/ModUniqueId.pm didn't compile when
> > I used CPAN to install everything.. weird.. I fixed the compile error, and
> > CPAN could install it. Now I get a new error though :(
> > 
> > The browser get this:
> > 
> > Can't locate object method "throw" via package "OITest::ErrorObject"
> >    at /usr/lib/perl5/site_perl/5.005/OpenInteract/Error.pm line 94.
> > 
> > and in the error log for the mod_perl server:
> > 
> > Found item: Apache::DBI::db
> >  --EXITED WITH ERROR from main handler eval block
> > Error: 0
> 
> So the main Apache handler is executing check_database() but not getting
> any further...
> 
> The error you're getting comes when the SPOPS error object hasn't been
> created properly. I suspect that it might be on server startup that this
> happens.
> 
> What do you see in your main Apache server error log? That is, not the
> one that's the virtual host. On my system I have:
> 
>  /home/httpd/website/logs/error_log_modperl -- vhost errors
>  /usr/local/apache/logs/error_log_modperl   -- server errors
> 
> Normally you'll see something like the startup messages:
> 
> [Sun Mar  3 13:17:12 2002] [info] created shared memory segment
> #45187096
> [Sun Mar  3 13:17:12 2002] [notice] Apache/1.3.20 (Unix) mod_perl/1.26
> configured -- resuming normal operations
> [Sun Mar  3 13:17:12 2002] [info] Server built: Nov 14 2001 22:57:31
> 
> But this is where errors that get generated during server startup AND
> child initialization (when the SPOPS classes get created) get put.
> 
> Hope this helps,
> 
> Chris
>  
> 

MVH/Best regards
-- 
Magnus Espeland
ma...@in...
geek:m.e.

Re: [Openinteract-help] Undefined subroutine &OpenInteract::handler called.

[Chris W. <ch...@cw...>]

On Fri, 2002-03-08 at 16:49, Magnus Espeland wrote:
> On 8 Mar 2002, Chris Winters wrote:
> 
> > First, look at your error log ($WEBSITE_DIR/logs/error_log_modperl, by
> > default) and see if anything jumps out at you there.
> 
> That's where I found the error ;-)

Of course :-) I wasn't sure if that was echoed to the browser or not.

> Ahh, seems like Apache/Session/Generate/ModUniqueId.pm didn't compile when
> I used CPAN to install everything.. weird.. I fixed the compile error, and
> CPAN could install it. Now I get a new error though :(
> 
> The browser get this:
> 
> Can't locate object method "throw" via package "OITest::ErrorObject"
>    at /usr/lib/perl5/site_perl/5.005/OpenInteract/Error.pm line 94.
> 
> and in the error log for the mod_perl server:
> 
> Found item: Apache::DBI::db
>  --EXITED WITH ERROR from main handler eval block
> Error: 0

So the main Apache handler is executing check_database() but not getting
any further...

The error you're getting comes when the SPOPS error object hasn't been
created properly. I suspect that it might be on server startup that this
happens.

What do you see in your main Apache server error log? That is, not the
one that's the virtual host. On my system I have:

 /home/httpd/website/logs/error_log_modperl -- vhost errors
 /usr/local/apache/logs/error_log_modperl   -- server errors

Normally you'll see something like the startup messages:

[Sun Mar  3 13:17:12 2002] [info] created shared memory segment
#45187096
[Sun Mar  3 13:17:12 2002] [notice] Apache/1.3.20 (Unix) mod_perl/1.26
configured -- resuming normal operations
[Sun Mar  3 13:17:12 2002] [info] Server built: Nov 14 2001 22:57:31

But this is where errors that get generated during server startup AND
child initialization (when the SPOPS classes get created) get put.

Hope this helps,

Chris
 
-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-help] Undefined subroutine &OpenInteract::handler called.

[Magnus E. <ma...@he...>]

On 8 Mar 2002, Chris Winters wrote:

> First, look at your error log ($WEBSITE_DIR/logs/error_log_modperl, by
> default) and see if anything jumps out at you there.

That's where I found the error ;-)

> One debugging tip is to set DEBUG to a positive value in
> OpenInteract::ApacheStartup. When you start Apache you should get some
> useful feedback letting you know what's up.

Ahh, seems like Apache/Session/Generate/ModUniqueId.pm didn't compile when
I used CPAN to install everything.. weird.. I fixed the compile error, and
CPAN could install it. Now I get a new error though :(

The browser get this:

Can't locate object method "throw" via package "OITest::ErrorObject"
   at /usr/lib/perl5/site_perl/5.005/OpenInteract/Error.pm line 94.

and in the error log for the mod_perl server:

Found item: Apache::DBI::db
 --EXITED WITH ERROR from main handler eval block
Error: 0

Any tips?

I'm idling on #openinteract at both slashnet and irc.openprojects.net,
would be cool to see you there ;-)

MVH/Best regards
-- 
Magnus Espeland
ma...@in...

Re: [Openinteract-help] Undefined subroutine &OpenInteract::handler called.

[Chris W. <ch...@cw...>]

On Fri, 2002-03-08 at 04:10, Magnus Espeland wrote:
> Thanks for a promising system ;-)
> 
> I have some problems getting it to work though, I get the error in the
> subject. I read Victor Piterbarg's mail about it, but my 
> conf/package_repository.perl file is pretty large

First, look at your error log ($WEBSITE_DIR/logs/error_log_modperl, by
default) and see if anything jumps out at you there.

One debugging tip is to set DEBUG to a positive value in
OpenInteract::ApacheStartup. When you start Apache you should get some
useful feedback letting you know what's up.

If the output of either of these seems fishy but doesn't make sense to
you, forward it to the list if it's fairly small, or me if it's large.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

[Openinteract-help] Undefined subroutine &OpenInteract::handler called.

[Magnus E. <ma...@he...>]

Hi!

Thanks for a promising system ;-)

I have some problems getting it to work though, I get the error in the
subject. I read Victor Piterbarg's mail about it, but my 
conf/package_repository.perl file is pretty large


any other ideas? :-)

MVH/Best regards
-- 
Magnus Espeland
ma...@in...

Re: [Openinteract-help] Progress

[Chris W. <ch...@cw...>]

On Thu, 2002-03-07 at 18:22, Bernie Ledwick wrote:
> Many thanks for your forebearance.

No problem. I should have picked up on the issue earlier -- it's going
in the FAQ right now :-)
 
> Setting Apache::Session::Postgres makes all the difference - I missed that 
> bit of the documentation. Any chance of this being included in the 
> "change_spops_driver" bit or am I being optimistic?

Optimistic :-) I'm wary of rewriting the server configuration file
because it's so large. The SPOPS driver issue shouldn't be so large in
the future since I'll probably make it a property of the datasource --
drivers won't have to specify SPOPS::DBI::Pg, MySQL, or whatever.

> I think I'm going to really enjoy this product.

Excellent! If you have any more questions please post them: you not only
never know how they'll end up, you never know how many people you'll
help out from the archived version.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-help] Progress

[Bernie L. <Ber...@nt...>]

Chris,

Many thanks for your forebearance.

Setting Apache::Session::Postgres makes all the difference - I missed that 
bit of the documentation. Any chance of this being included in the 
"change_spops_driver" bit or am I being optimistic?

I think I'm going to really enjoy this product.

Regards,

Bernie.

Re: [Openinteract-help] Progress

[Chris W. <ch...@cw...>]

On Thu, 2002-03-07 at 04:11, Bernie Ledwick wrote:
> Chris,
> 
> Looking at the log file there seems to be still some mysql in there. Any 
> ideas:
> 
> OpenInteract::Error::System::cannot_create_session (334) >> Cannot create 
> session -- someone is probably using a  defunct key or something.
> >> Error with code 310 thrown. Info: DBD::Pg::st execute failed: ERROR:  
> Function 'get_lock(unknown, int4)' does not exist at 
> /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 54.
>         (in cleanup) DBD::Pg::st execute failed: ERROR:  Function 
> 'get_lock(unknown, int4)' does not exist at 
> /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 54.
>         
> OpenInteract::Error::System::log_and_return('bltest::ErrorObject=HASH(0x8d07080)') 
> called at /usr/lib/perl5/site_perl/5.6.1/OpenInteract/Error/System.pm line 341
>         
> OpenInteract::Error::System::cannot_create_session('bltest::ErrorObject=HASH(0x8d07080)') 
> called at /usr/lib/perl5/site_perl/5.6.1/OpenInteract/Error/Main.pm line 38

Ah! This is in your server configuration. See the 'session_info' key and
change 'class' to 'Apache::Session::Postgres', then restart (stop, then
start) your server. 

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-help] Progress

[Bernie L. <Ber...@nt...>]

Chris,

Looking at the log file there seems to be still some mysql in there. Any 
ideas:

OpenInteract::Error::System::cannot_create_session (334) >> Cannot create 
session -- someone is probably using a  defunct key or something.
>> Error with code 310 thrown. Info: DBD::Pg::st execute failed: ERROR:  
Function 'get_lock(unknown, int4)' does not exist at 
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 54.
        (in cleanup) DBD::Pg::st execute failed: ERROR:  Function 
'get_lock(unknown, int4)' does not exist at 
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 54.
        
OpenInteract::Error::System::log_and_return('bltest::ErrorObject=HASH(0x8d07080)') 
called at /usr/lib/perl5/site_perl/5.6.1/OpenInteract/Error/System.pm line 341
        
OpenInteract::Error::System::cannot_create_session('bltest::ErrorObject=HASH(0x8d07080)') 
called at /usr/lib/perl5/site_perl/5.6.1/OpenInteract/Error/Main.pm line 38


Bernie.

Re: [Openinteract-help] Progress

[Bernie L. <Ber...@nt...>]

Chris,

I see, said the blindman - or at least I'm starting to! 

1. I didn't realise you had private apache log files.

2. Your documentation needs to specify to chown the error directory to 
"nobody" as well as all the others (html/cache/overflow/uploads). 
(Incidentally on my platform - Mandrake - the user is apache.)

3. I don't seem to have the superuser.pm you mention:
bash-2.05$ pwd
/home/oi/bltest
bash-2.05$ find . -name "*ser.pm"
./pkg/base_user-1.49/bltest/Handler/User.pm
./pkg/base_user-1.49/bltest/Handler/NewUser.pm
./tmplib/bltest/Handler/User.pm
./tmplib/bltest/Handler/NewUser.pm
./tmplib/OpenInteract/User.pm
./tmplib/OpenInteract/Error/User.pm
./tmplib/OpenInteract/SQLInstall/User.pm
./tmplib/OpenInteract/Handler/User.pm
./tmplib/OpenInteract/Handler/NewUser.pm
bash-2.05$

4. I changed the Handler as you suggested, but still only get:
superuser_id: 1
Level: [8]

However, know I know about the log files, I'll do some more digging and let 
you know what I find.

Regards,

Bernie.

On Thursday 07 March 2002 5:12 am, Chris Winters wrote:
> On Wed, 2002-03-06 at 17:49, Bernie Ledwick wrote:
> > Chris,
> >
> > Tried your perl debug, but not sure what it means.
> >
> > Output is below.
> >
> > Regards,
> >
> > Bernie.
> >
> > bash-2.05$ perl /tmp/bl.pl
> > Using (/home/oi/bltest) for 'website_dir'.
> > superuser_id: 1
> > Level: [8]
> > #bash-2.05$ cat /tmp/bl/pl
> > #!/usr/bin/perl
> >
> > use strict;
> > use OpenInteract::Startup;
> >
> > my $HANDLER = 'bltest::Handler::superuser';
>
> Is this handler name correct? That is, is there a handler class in your
> site in a file called 'superuser.pm'? The handler should be set to a
> class in your site which acts as a handler. In your case, the following
> should work:
>
> my $HANDLER = 'bltest::Handler::User';
>
> The reason being that if you set $HANDLER to something not in the system
> then it's not so instructive when you change the user ID we're fetching
> to something that is not the superuser.
>
> Anyway, the only other thing I can think of is to ensure in the website
> you're actually logged in as the superuser. You should be able to see a
> line in your error log like:
>
>  OpenInteract::Auth::user (33) >> User found: superuser
>
> near the top of the entries for a particular request. Make sure you
> check the log for the exact request you're having problems with. This
> could be an issue where your cookie isn't set properly, is expiring or
> is somehow corrupt. I've had the corrupted cookie problem when running
> OI on Win2000 with the Apache::Cookie module and either Netscape or IE
> (can't remember which). Using CGI::Cookie fixed it right up.
>
> Chris

Re: [Openinteract-help] Progress

[Chris W. <ch...@cw...>]

On Wed, 2002-03-06 at 17:49, Bernie Ledwick wrote:
> Chris,
> 
> Tried your perl debug, but not sure what it means.
> 
> Output is below.
> 
> Regards,
> 
> Bernie.
> 
> bash-2.05$ perl /tmp/bl.pl
> Using (/home/oi/bltest) for 'website_dir'.
> superuser_id: 1
> Level: [8]
> #bash-2.05$ cat /tmp/bl/pl
> #!/usr/bin/perl
>
> use strict;
> use OpenInteract::Startup;
>
> my $HANDLER = 'bltest::Handler::superuser';

Is this handler name correct? That is, is there a handler class in your
site in a file called 'superuser.pm'? The handler should be set to a
class in your site which acts as a handler. In your case, the following
should work:

my $HANDLER = 'bltest::Handler::User';

The reason being that if you set $HANDLER to something not in the system
then it's not so instructive when you change the user ID we're fetching
to something that is not the superuser.

Anyway, the only other thing I can think of is to ensure in the website
you're actually logged in as the superuser. You should be able to see a
line in your error log like:

 OpenInteract::Auth::user (33) >> User found: superuser

near the top of the entries for a particular request. Make sure you
check the log for the exact request you're having problems with. This
could be an issue where your cookie isn't set properly, is expiring or
is somehow corrupt. I've had the corrupted cookie problem when running
OI on Win2000 with the Apache::Cookie module and either Netscape or IE
(can't remember which). Using CGI::Cookie fixed it right up.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-help] Progress

[Bernie L. <Ber...@nt...>]

Chris,

Tried your perl debug, but not sure what it means.

Output is below.

Regards,

Bernie.

bash-2.05$ perl /tmp/bl.pl
Using (/home/oi/bltest) for 'website_dir'.
superuser_id: 1
Level: [8]
bash-2.05$ cat /tmp/bl/pl
#!/usr/bin/perl

use strict;
use OpenInteract::Startup;

my $HANDLER = 'bltest::Handler::superuser';

{
    my $R = OpenInteract::Startup->setup_static_environment_options(
                    undef, {}, { temp_lib => 'lazy' } );

                    # my $superuser_id = 
$R->CONFIG->{default_objects}{superuser};
    my $superuser_id = 1;

    print "superuser_id: $superuser_id\n";
    # Play with the next two lines to experiment
    my $superuser = $R->user->fetch( $superuser_id,
                                     { skip_security => 1 });
    $R->{auth}{user} = $superuser;

    $R->CONFIG->{DEBUG} = 2;
    my $level        = $R->user->check_security({
                              class                 => $HANDLER,
                              object_id             => '0' });
    print "Level: [$level]\n";
}

Re: [Openinteract-help] Progress

[Chris W. <ch...@cw...>]

On Tue, 2002-03-05 at 02:14, Bernie Ledwick wrote:
> Chris,
> 
> I think there is another virtual host defined on port 80. I'll investigate 
> that later!
> 
> I have already changed the driver as suggested. I guess nothing would work if 
> I hadn't.

Actually, everything should still work except for creating new objects.
Thanks to DBI, the database-specific drivers don't have much code in
them at all -- mostly just the various auto-increment schemes.

> The sql output is below. 
>
> bltest=#  SELECT class, scope, scope_id, security_level
> bltest-#    FROM sys_security WHERE class like '%Handler%';
>               class              | scope | scope_id | security_level
> ---------------------------------+-------+----------+----------------
>  bltest::Handler::Package        | g     | 3        | 8
>  bltest::Handler::Error          | w     | world    | 4
> ....
> bltest=# SELECT user_id FROM sys_user WHERE login_name = 'superuser';
>  user_id
> ---------
>        1
> (1 row)

This all looks ok. So it's time for more debugging. Try running the
following script:

----------
#!/usr/bin/perl

use strict;
use OpenInteract::Startup;

my $HANDLER = 'MySite::Handler::User';

{
    my $R = OpenInteract::Startup->setup_static_environment_options(
                    undef, {}, { temp_lib => 'lazy' } );

    my $superuser_id = $R->CONFIG->{default_objects}{superuser};

    # Play with the next two lines to experiment
    my $superuser = $R->user->fetch( $superuser_id,
                                     { skip_security => 1 });
    $R->{auth}{user} = $superuser;

    $R->CONFIG->{DEBUG} = 2;
    my $level        = $R->user->check_security({
                              class                 => $HANDLER,
                              object_id             => '0' });
    print "Level: [$level]\n";
}
----------

Subtitute whatever you want for $HANDLER, and modify the user fetched or
don't fetch a user at all. See what comes up for the level and if any
helpful debugging messages pop up.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-help] Progress

[Chris W. <ch...@cw...>]

On Mon, 2002-03-04 at 19:26, Bernie Ledwick wrote:
> Many thanks for your prompt responses regarding my problems yesterday. The 
> new release seems to have done the trick.

Good news!

> However, I have now reached another stumbling block. The web site is up 
> (using  defaults -except see below - and template web site) and I can login 
> as the superuser and/or create a new user (using "create one" in the Login 
> box).
> 
> The "user - new" link gives me (as superuser)
> 
> Error 
> 
> Sorry, you do not have access to create a new user object. Returning to 
> listing. 
> 
> Anything that should allow me to do anything interesting, e.g. Page actions, 
> results in a "Task is Forbidden" message (as superuser). 

Interesting. What happens if you run the following query in psql:

 SELECT class, scope, scope_id, security_level 
   FROM sys_security WHERE class like '%Handler%'

Also, see what uid the superuser is:

 SELECT user_id FROM sys_user WHERE login_name = 'superuser'

It could be that the superuser doesn't have the ID that OI expects,
normally '1'. If not, you can change this in the server configuration
under the 'default_objects.superuser' key.

> The only changes I have made to the defaults are:
> 
> . 	use postgresql instead of mysql

Did you modify the various SPOPS definitions to use SPOPS::DBI::Pg
rather than SPOPS::DBI::MySQL? You should be able to accomplish this all
at once by doing:

 $ oi_manage change_spops_driver \
             --website_dir=/path/to/mysite \
             --driver=SPOPS::DBI::Pg

> .	change the Apache listener to 81/8081, because if I leave them at the 			
> default of 80/8080 httpd-perl runs, but httpd doesn't run, with errors saying 
> it can't start because port 80 is already in use.

Sounds like you've got another webserver running somewhere. This isn't a
big deal.

See how the security stuff above pans out. Hopefully one of those items
will get a hit.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

[Openinteract-help] Progress

[Bernie L. <Ber...@nt...>]

Many thanks for your prompt responses regarding my problems yesterday. The 
new release seems to have done the trick.

However, I have now reached another stumbling block. The web site is up 
(using  defaults -except see below - and template web site) and I can login 
as the superuser and/or create a new user (using "create one" in the Login 
box).

The "user - new" link gives me (as superuser)

Error 

Sorry, you do not have access to create a new user object. Returning to 
listing. 

Anything that should allow me to do anything interesting, e.g. Page actions, 
results in a "Task is Forbidden" message (as superuser). 

The only changes I have made to the defaults are:

. 	use postgresql instead of mysql

.	change the Apache listener to 81/8081, because if I leave them at the 			
default of 80/8080 httpd-perl runs, but httpd doesn't run, with errors saying 
it can't start because port 80 is already in use.

Any ideas where I should start to look?

Regards,

Bernie.

Re: [Openinteract-help] fetch_group DEBUG flag?

[Chris W. <ch...@cw...>]

On Sun, 2002-03-03 at 15:08, John Sequeira wrote:
> Can you pass a DEBUG=>1 flag into $object->fetch_group to see what SQL is
> being run?
> 
> The docs say you can do this for fetch,  but it doesn't appear to have any
> effect on fetch_group.

It works ok for me. Using the 0.57 release, I setup the testing tables
in eg/ for SQLite (which I recommend everyone install since it's so easy
to set things up and tear them down) like this:

 ... edit eg/My/Common.pm to have the relevant SQLite info ...
 1. $ cd eg/
 2. $ perl users_groups_sqlite.pl
 3. $ perl stock_user_group.pl
 4. edit eg/fetch_all.pl to pass a DEBUG => 1 to the 
    fetch_group call for My::User so that line 14 change from:

my $users    = My::User->fetch_group({ skip_security => 1 });

to:

my $users    = My::User->fetch_group({ skip_security => 1,
                                       DEBUG => 1 });

 5. $ perl fetch_all.pl

And got:

--------------------
SPOPS::SQLInterface::db_select (91) >> No SQL passed in to execute
directly; building.
SPOPS::SQLInterface::db_select (112) >> SQL for select: 
           SELECT  spops_user.user_id, spops_user.login_name,
spops_user.password, spops_user.first_name, spops_user.last_name,
spops_user.email, spops_user.notes
             FROM spops_user
                    
SPOPS::SQLInterface::db_select (124) >> Values bound:  
SPOPS::SQLInterface::db_select (134) >> Returning statement handle
(after prepare/execute)
SPOPS::DBI::_fetch_assign_row (449) >> Setting data from row into
My::User
SPOPS::DBI::_fetch_assign_row (452) >>  user_id              -->
-202991066
SPOPS::DBI::_fetch_assign_row (452) >>  login_name           -->
superuser
SPOPS::DBI::_fetch_assign_row (452) >>  password             -->
password
SPOPS::DBI::_fetch_assign_row (452) >>  first_name           --> super
SPOPS::DBI::_fetch_assign_row (452) >>  last_name            --> user
SPOPS::DBI::_fetch_assign_row (452) >>  email                -->
superuser@
SPOPS::DBI::_fetch_assign_row (452) >>  notes                --> 
SPOPS::DBI::_fetch_post_process (486) >> My::User ( -2029910665 ) :
cache set (if available), post_fetch_action() done, change flag cleared
and save  flag set. Security: 8
--------------------
 
> Also, is there another way to get this info for debugging?

Not right now. Did you have an idea about another way to get it?
Debugging has always kind of been a PITA, so ideas are welcome.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

[Openinteract-help] fetch_group DEBUG flag?

[John S. <js...@me...>]

Can you pass a DEBUG=>1 flag into $object->fetch_group to see what SQL is
being run?

The docs say you can do this for fetch,  but it doesn't appear to have any
effect on fetch_group.

Also, is there another way to get this info for debugging?

Thanks,

JS

Re: [Openinteract-help] Errors

[Chris W. <ch...@cw...>]

On Sun, 2002-03-03 at 13:20, Bernie Ledwick wrote:
> I am running  OpenInteract-1.38 and get errors when running oi_manage
> and httpd. There seems to be a problem with the OpenInteract.pm module
> at line 348.

This is fixed in CVS now -- as you saw from Andreas's email his
eagle-eyed team already picked out the error. I'll probably release a
new version with this silly oversight fixed shortly.
 
> I am using Postgresql and am also getting some errors during the
> install_sql phase regarding length of character variables.

One of the data records being inserted to the content_type table has too
much information in the 'extensions' field. I've updated the table
definition in CVS and put out the updated package to the sourceforge
site.

Thanks for the report.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

AW: [Openinteract-help] Errors

[<And...@Be...>]

Hy Bernie,

you are right: replace the "elsif" with "if" and all is well ;-) You =
also
need to replace the occurences of INPUT in
$OISITE/pkg/base_box.x.xx/template/login_box.tmpl with PROCESS.

regards,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Bernie Ledwick [mailto:Ber...@nt...]
Gesendet: Sonntag, 3. M=E4rz 2002 19:21
An: ope...@li...
Betreff: [Openinteract-help] Errors


I am running  OpenInteract-1.38 and get errors when running oi_manage
and httpd. There seems to be a problem with the OpenInteract.pm module
at line 348.

I am using Postgresql and am also getting some errors during the
install_sql phase regarding length of character variables.

Any ideas?

Regards,

Bernie


 oi_manage --website_dir=3D/home/oi/bltest --package=3DINITIAL =
install_sql
Running install_sql...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
'sessions_pkey' for table 'sessions'

<snip>=20

'object_track_pkey' for table 'object_track'
NOTICE:  CREATE TABLE / UNIQUE will create implicit index
'object_track_class_key' for table 'object_track'
OpenInteract::Startup::require_module (344) >>  --require error:
OpenInteract
                         : syntax error at
/usr/lib/perl5/site_perl/5.6.1/OpenInteract.pm line 348, near "elsif"
Compilation failed in require at (eval 29) line 3, <MOD> line 9.

Status of the packages requested for SQL install:

base (1.63)
  OK:

<snip>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
base_page (0.89)
  OK:

      Structure:
        * Created table from (page.sql): ok
        * Created table from (page_content.sql): ok
        * Created table from (content_type.sql): ok
        * Created table from (page_directory.sql): ok
      Data:
        * Error: Cannot create SPOPS object!
      Basic: DBD::Pg::st execute failed: ERROR:  value too
      long for type character varying(20) at
      /usr/lib/perl5/site_perl/5.6.1/SPOPS/SQLInterface.pm
      line 284.

      Error: DBD::Pg::st execute failed: ERROR:  value too
      long for type character varying(20) at
      /usr/lib/perl5/site_perl/5.6.1/SPOPS/SQLInterface.pm
      line 284.


        * Created (1) SPOPS objects (from page.dat): ok
        * Created (1) SPOPS objects (from
      page_directory.dat): ok

<snip>



_______________________________________________
openinteract-help mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-help

[Openinteract-help] Errors

[Bernie L. <Ber...@nt...>]

I am running  OpenInteract-1.38 and get errors when running oi_manage
and httpd. There seems to be a problem with the OpenInteract.pm module
at line 348.

I am using Postgresql and am also getting some errors during the
install_sql phase regarding length of character variables.

Any ideas?

Regards,

Bernie


 oi_manage --website_dir=/home/oi/bltest --package=INITIAL install_sql
Running install_sql...
=========================

NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
'sessions_pkey' for table 'sessions'

<snip> 

'object_track_pkey' for table 'object_track'
NOTICE:  CREATE TABLE / UNIQUE will create implicit index
'object_track_class_key' for table 'object_track'
OpenInteract::Startup::require_module (344) >>  --require error:
OpenInteract
                         : syntax error at
/usr/lib/perl5/site_perl/5.6.1/OpenInteract.pm line 348, near "elsif"
Compilation failed in require at (eval 29) line 3, <MOD> line 9.

Status of the packages requested for SQL install:

base (1.63)
  OK:

<snip>

=========================
base_page (0.89)
  OK:

      Structure:
        * Created table from (page.sql): ok
        * Created table from (page_content.sql): ok
        * Created table from (content_type.sql): ok
        * Created table from (page_directory.sql): ok
      Data:
        * Error: Cannot create SPOPS object!
      Basic: DBD::Pg::st execute failed: ERROR:  value too
      long for type character varying(20) at
      /usr/lib/perl5/site_perl/5.6.1/SPOPS/SQLInterface.pm
      line 284.

      Error: DBD::Pg::st execute failed: ERROR:  value too
      long for type character varying(20) at
      /usr/lib/perl5/site_perl/5.6.1/SPOPS/SQLInterface.pm
      line 284.


        * Created (1) SPOPS objects (from page.dat): ok
        * Created (1) SPOPS objects (from
      page_directory.dat): ok

<snip>

Re: [Openinteract-help] scan_for_new broken?

[Chris W. <ch...@cw...>]

On Thu, 2002-02-28 at 20:27, John Sequeira wrote:
> A-ha.  I just found this in your base_page changelog:
> 
> 0.84  Wed Jan 23 16:48:37 EST 2002
> 
>       Fix script/scan_for_new.pl to bring in the PageScan module at
>       the right time.
> 
> Can I upgrade base_page without upgrading the rest of OI?
> or should I bring everything up to 1.38	?

Oh sure, I don't think there should be a problem. That's the whole idea
behind packages :-)

> My objective is to get OI to recognize my filesystem html files,  with as
> little stress possible (mmeaning: I'd rather avoid a major oi upgrade if
> possible).  If you could suggest an approach to get there I'd appreciate
> that.

If you already have the base_page package installed, then upgrading it
alone should be a snap and get you to where you want to be. (Be sure to
read the Changelog, though :-) The scan_for_new.pl script has worked
well -- it helped immensely with a sizeable upgrade from a 1.1 to a 1.35
system a little while ago.

There is also in the new base_page package a new action where you can
scan for new files using a web interface, which can be handy.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

[Openinteract-help] scan_for_new broken?

[John S. <js...@me...>]

A-ha.  I just found this in your base_page changelog:

0.84  Wed Jan 23 16:48:37 EST 2002

      Fix script/scan_for_new.pl to bring in the PageScan module at
      the right time.

Can I upgrade base_page without upgrading the rest of OI?
or should I bring everything up to 1.38	?

...
My objective is to get OI to recognize my filesystem html files,  with as
little stress possible (mmeaning: I'd rather avoid a major oi upgrade if
possible).  If you could suggest an approach to get there I'd appreciate
that.

[Openinteract-help] scan_for_new broken?

[John S. <js...@me...>]

Any thoughts on the trace below?

> ./oi/pkg/base_page-0.77/script/scan_for_new.pl --base_dir
/home/johnseq/oi --w
Can't locate OpenInteract/PageScan.pm in @INC (@INC contains: ..
/usr/libdata/pe
rl/5.00503/mach /usr/libdata/perl/5.00503
/usr/local/lib/perl5/site_perl/5.005/i
386-freebsd /usr/local/lib/perl5/site_perl/5.005 .) at
./oi/pkg/base_page-0.77/s
cript/scan_for_new.pl line 11.
BEGIN failed--compilation aborted at
./oi/pkg/base_page-0.77/script/scan_for_new
.pl line 11.

I can't seem to find the PageScan.pm library referenced above.

Re: [Openinteract-help] server load - help!

[Chris W. <ch...@cw...>]

On Wed, 2002-02-27 at 16:37, Chris McDaniel wrote:
> I have a particular action within a package I wrote that tends to drive
> server load up (quite a bit) every time it is run.  Just wondering about the
> best way to determine what exactly is going on.  I have DEBUG => 5 in all my
> queries, but I don't see anything out of the ordinary.
> 
> Note that I am using iterators wherever possible and also that the ping_log
> table referenced below has > 70000 records.
> 
> This is the log of a single run of the procedure - 
> ...

What happens when you take these queries and run them in a separate
script? They don't seem very unusual, so the only thing I can think of
database-wise is to ensure the fields you're searching (customer_id in
monitored_hosts and monitored_host_id in ping_log) are indexed by
themselves, as opposed to being part of an index with more fields.

Also, if you're using the CommonHandler routine and/or getting paged
results back, you might want to check the overflow directory
($WEBSITE_DIR/overflow) to see if you've got a bazillion files in there.
Many filesystems suffer dramatic slowdowns when you stick a few thousand
files in a single directory. If that's your problem, there's a script
pkg/results_manage-x.xx/script/clean_results.pl that you can run which
will cleanup any results older than 30 minutes.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.