can't locate object method "see" via package "Net::IMAP::Simple" - perl

I am trying to fetch unread emails from server and mark them as seen (read) after fetching. I'm using perl script and the package Net::IMAP::Simple. I'm writing this script for the office work.
Below is some code :
use strict;
use warnings;
use Net::IMAP::Simple;
use Email::Simple;
use HTTP::Date;
#some code....
# Create the object
my $server = Net::IMAP::Simple->new($imap_server) or die "Can't connect to server: $imap_server ";
# Log on
my $login = $server->login($imap_user,$imap_passwd) or die "Login failed (bad username or password)";
#some code.....
# set the message as seen
$server->see($i);
# i also used $server->add_flags($i,'\Seen'); but it throws same error.
The Irony is, this code works fine on my Gmail account , which i use for testing. but when i test it in office it throws error ;
can't locate object method "see" via package "Net::IMAP::Simple"
I don't know what's the issue here.

The methods see and unsee were added in Net::IMAP::Simple version 1.1899_05.
> 1.1899_05: Tue Jun 16 06:42:16 EDT 2009
> - I started working on ticket 45953,
> - created sub_flags() and add_flags()
> - taught delete() to use add_flags() -- adds \Deleted
> - providing see() and unsee() for ticket 45953
> - I started building tests for the flag manipulation stuff and
> put reselect stuff ... noticed a possible bug in
> Net::IMAP::Server
You likely have an older version on your production system. Update it, and include a minimum version in your Makefile.PL or cpanfile or whatever you use to track dependencies.

Related

Perl LWP::UserAgent request does not return using http1.1 but working fine using http1.0!? Why?

I have a very simple script (on a SLES11 system) to send a http1.1 request to a server. This worked fine for a long time. Since a couple of days it stopped working. I have no idea why. After some investigation I found out forcing the script to use http1.0 it is working again. I have no idea why. And I want to know why it is not working in its default http1.1 mode.
I already enabled debugging as much as I know it (see code below). But I do not see anything - my script just hangs. There is no network activity. I neiter see that a socket will be openend (netstat -a), nor I see any incoming traffic form my client on the server. (A "telnet myserver myport" works fine.)
Can someone please help me how to track down this problem? How can I enable more debug to see where the real problem is?
#!/usr/bin/perl -w
use strict;
use warnings;
use Data::Dumper;
use HTTP::Request::Common;
use LWP::Debug qw(+);
use LWP::UserAgent;
# Workaround: forcing http1.0 instead of using http1.1, it works again!
use LWP::Protocol::https10 ();
LWP::Protocol::implementor('https', 'LWP::Protocol::https10');
# EO workaround
my $ua = LWP::UserAgent->new;
$ua->ssl_opts( verify_hostname => 0 );
my $response = $ua->request(
POST 'https://myuser:mypassword#myserver:8888/service/myservice',
Connection => 'close', # Edit: added, see comments below
Content_Type => 'text/xml',
Content => '... my content ...'
);
$ua->request() does not return! I need to kill/^C the script!
Edit: ok, no one seems to have an idea how to continue. So I startet debugging it using perl debugger.
LWP::UserAgent::post(/usr/lib/perl5/site_perl/5.10.0/LWP/UserAgent.pm:418):
418: return $self->request( HTTP::Request::Common::POST( #parameters ), #suff );
So I can see it is not returning from request().
Anyway, due to the fact that LWP::UserAgent calls HTTP::Request::Common I changed my example code above back to use HTTP::Request::Common to skip that step while debugging.
Ok... New result:
LWP::Protocol::implementor(/usr/lib/perl5/site_perl/5.10.0/Net/HTTPS.pm:26):
26: eval { require IO::Socket::SSL; };
Inside request() it hangs at IO::Socket::SSL. Means, this script it enough for further debug:
#!/usr/bin/perl
require IO::Socket::SSL;
This statement does not come back.
Further down, inside IO::Socket::SSL it hangs at:
IO::Socket::SSL::CODE(0x1274370)(/usr/lib/perl5/site_perl/5.10.0/IO/Socket/SSL.pm:92):
92: Net::SSLeay::SSLeay_add_ssl_algorithms();
Ahhhh! There is already a bugreport concerning this issue: Net-SSLeay hangs on Suse 11 P2 pointing to Bug #81575 that says:
I enountered this same issue on SLES 11 SP2, which has openssl-0.9.8j installed.
An upgrade to openssl-0.9.8r did resolve the problem. ...
The packages for 0.9.8r can be found in this repository:
http://download.opensuse.org/repositories/security:/fips/
Guess that's it!
There is already a bugreport concerning this issue: Net-SSLeay hangs on Suse 11 P2 pointing to Bug #81575 that says:
I enountered this same issue on SLES 11 SP2, which has openssl-0.9.8j installed. An upgrade to openssl-0.9.8r did resolve the problem. ... The packages for 0.9.8r can be found in this repository: http://download.opensuse.org/repositories/security:/fips/
Guess that's it!

Open2 Api failure while installing Mead software

I am running into some issues trying to install a software called MEAD . I would appreciate if someone could have alook .
I get the following error while installing
/mead/bin # ./mead.pl GA3
Using system rc-file: /home/karosh/mead/bin/../.meadrc
Warning: Can't find user rc-file
Cluster: /home/karosh/mead/bin/../data/GA3/GA3.cluster
open2: exec of /home/karosh/mead/bin/driver.pl failed at ./mead.pl line 230
THe mead software is not written by me so I have not changed any of the perl scrips . I line 230 in the driver.pl file is
sub run_mead {
my %options = #_;
my $reader = FileHandle->new();
my $writer = FileHandle->new();
unless ( open2($reader, $writer, "$FindBin::Bin/driver.pl") ) {
die "Unable to run MEAD.\n";
}
...
...
}
Does this error mean that open2 was not found . The mead folks have put the following line in the file:
use strict;
use File::Spec;
use FileHandle;
use IPC::Open2;
Or does it mean that i need to install the rpm that contains the API . I see that this API is a part of the core perl bundle http://perldoc.perl.org/IPC/Open2.html. So why was it not installed ? Do i need to install perl again .
Someone has earlier faced this problem - http://www.summarization.com/~radev/mead/email/0160.html but the solution is not working for me . I find no Perl files with the incorrect perl directives . The mead team has been dissolved and there is no one to ask questions but I need to use this software.
I think if some one can explain me the meaning of the error than I can do deeper. Anyone?
It probably means that .../driver.pl doesn't have execute permission. Change the file permissions or call it like
open2($reader, $writer, "perl $FindBin::Bin/driver.pl")
open2($reader, $writer, "$^X $FindBin::Bin/driver.pl")

DBD::Informix connection issues

I'm having somewhat weird problem with DBD::Informix. If I run a simple script like that:
use DBI;
my $dbh = DBI->connect_cached('dbi:Informix:database', '', '');
my $sth = $dbh->prepare('select foo from bar');
...
It works all right. But if I try to do exactly the same from a test script it fails with the following message:
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
The only difference I see is that test script is quite heavy on module usage; it is based on Test::More and loads a lot of submodules that are to be tested.
Turning on DBI trace does not provide anything useful (for me, at least). Simple script runs along just fine:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9685 pi 0) at test_ifx.pl line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9685 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0x1c8070)
!! warn: 0 CLEARED by call to connect method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms#cms_ol' - no user info
-->> DBD::Informix::dbd_ix_db_check_for_autocommit()
... and the only difference in trace of the problematic script I see is that it just fails:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9687 pi 0) at 22_report.t line 5 via 22_report.t line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect_cached(dbi:Informix:cms, , ****)
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9687 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0xb619bc)
!! warn: 0 CLEARED by call to connect_cached method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms' - no user info
***ERROR***
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
<<-- dbd_ix_db_connect (**ERROR-1**)
<<-- DBD::Informix::dbd_ix_db_connect()
I'm running custom Perl 5.8.9 build in Solaris 9, with latest DBI and DBD::Informix versions, against Informix IDS 9.40UC.
Update: If I try to be a smartass and put a block like that at the top of the heavy test script:
use DBI;
BEGIN { my $dbh = DBI->connect_cached( ... ); print "Connected!\n" if $dbh; }
... it prints like this:
Connected!
Out of memory!
Callback called exit.
END failed--call queue aborted at t/22_report.t line 20.
Callback called exit at t/22_report.t line 20.
BEGIN failed--compilation aborted at t/22_report.t line 24.
My guess is that DBD::Informix conflicts with some of the modules loaded after the connection is made. But which one? That's the question...
Another update: It appears that the above trick does something unwieldy. I tried to load all the modules explicitly by replacing 'use Module' with 'require Module; Module->import'. Pure Perl modules are OK but whenever XS module using XSLoader appears, Perl goes boom with friendly 'Out of memory' message. And if I move Informix connection below module initialization, it works all right - except DBD::Informix fails with the same -25588 error. Boomer. I'm at loss. :(
Another another update: I tried to run the same script with standard Perl 5.6.1 shipped with Solaris 9, using DBI 1.601 (the latest that would compile with Perl 5.6) and DBD::Informix 2011.0612. Same thing, so it's not custom Perl giving me trouble.
I can also add that the test module in question was prototyped using DBD::SQLite and fully works. It is the final test with DBD::Informix that is failing... As usual. :/
Workaround: following e-mail discussion with Jonathan, a workaround was found: addition of streams-based 'onipcstr' connection to Informix server allowed DBD::Informix to connect. Apparently, some XS modules interfere with default shmem-based connection method, although the culprit is unknown at the moment.
Further discussion
Custom-built Perl is, in my experience, easier than the system Perl. I never modify the system's Perl installation (I don't want to break it) so I always build my own.
You appear to have:
Solaris 9 (SPARC?)
Perl 5.8.9
DBI 1.616
DBD::Informix 2011.0612
ESQL/C (CSDK) 2.81
Informix Dynamic Server 9.40
We don't have the detailed sub-version of ESQL/C and IDS (2.81.UC2, 9.40.UC5, or whatever). There's a hint that you are using a 32-bit version of IDS, so probably everything is 32-bit. You are probably aware that 9.40 is no longer supported by IBM (and, indeed, its successor version 10.00 is also out of support). However, superficially, none of that should matter very much. The failing t91lvarchar.t is not a big issue.
Can you run the connect in working and non-working modes with DBI_TRACE=9 set in the environment.
If the trace for the connect operation is too voluminous to go into an update to the question, we'd better take this off-line to the DBD::Informix support channels (that's me, but by email).
The 'ISAM' error of 22 (Invalid argument) is puzzling. I'm curious about what is in your sqlhosts file for this server - the entry for cms_ol specifically. I'm not sure it will reveal anything, not least because you say the sample ESQL/C below (in the 'First hypothesis' section) works OK, and sometimes the Perl connects and sometimes it does not.
I wonder if there is a name conflict somewhere between functions in the shared libraries? That sort of thing will be hell to track.
First hypothesis
Further information received shows that this was not the crucial distinction.
The difference appears to be:
Works: CONNECT TO 'cms#cms_ol' - no user info
Fails: CONNECT TO 'cms' - no user info
The tricky part to explain is why the second fails, especially as the error goes on to mention cms_ol.
The workaround is to specify the server name in the connect string:
DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
DBI->connect_cached(dbi:Informix:cms, , ****)
The underlying problem is more likely at the ESQL/C level than anything to do with other Perl modules. That is, if you compiled and executed this ESQL/C program, it would fail on cms and work on cms#cms_ol:
int main(int argc, char **argv)
{
$ char *dbs = "cms";
if (argc > 1)
dbs = argv[1];
$ whenever error stop;
$ connect to :dbs;
return 0;
}
You could run it without an explicit database name (or with an explicit 'cms'), and I would expect it to fail. You could run it with 'cms#cms_ol' and I would expect it to pass. The program will say nothing if it passes; it will be obvious when it fails (though the messages will not be beautiful).
There is an outside chance it is something to do with connect_cached; that is a service provided by the DBI module and not by the DBD::Informix module. On the whole though, it is more likely something happening at the ESQL/C level.

Why does my Perl CGI program fail with "Software error: ..."?

When I try to run my Perl CGI program, the returned web page tells me:
Software error: For help, please send mail to the webmaster (root#localhost), giving this error message and the time and date of the error.
Here is my code in one of the file:
#!/usr/bin/perl
use lib "/home/ecoopr/ecoopr.com/CPAN";
use CGI;
use CGI::FormBuilder;
use CGI::Session;
use CGI::Carp (fatalsToBrowser);
use CGI::Session;
use HTML::Template;
use MIME::Base64 ();
use strict;
require "./db_lib.pl";
require "./config.pl";
my $query = CGI->new;
my $url = $query->url();
my $hostname = $query->url(-base => 1);
my $login_url = $hostname . '/login.pl';
my $redir_url = $login_url . '?d=' . $url;
my $domain_name = get_domain_name();
my $helpful_msg = $query->param('m');
my $new_trusted_user_fname = $query->param('u');
my $action = $query->param('a');
$new_trusted_user_fname = MIME::Base64::decode($new_trusted_user_fname);
####### Colin: Added July 12, 2009 #######
my $view = $query->param('view');
my $offset = $query->param('offset');
####### Colin: Added July , 2009 #######
#print $session->header;
#print $new_trusted_user;
my $helpful_msg_txt = qq[];
my $helpful_msg_div = qq[];
if ($helpful_msg)
The "please send mail to the webmaster" message you see is a generic message that the web server gives you when anything goes wrong and nothing handles it. It's not at all interesting in terms of solving the actual problem. Check the error log to find possible relevant error output from your program.
And, go through my How do I troubleshoot my Perl CGI script? advice on finding the problem.
My guess is that you have a syntax error with that dangling if(). What you have posted isn't a valid Perl program.
Good luck,
is that something related to suexec module
Improper configuration of suExec can cause permission errors
The suEXEC feature provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.
apache recommends that you not consider using suEXEC.
http://httpd.apache.org/docs/2.2/suexec.html
From the StackOverflow page: How to trap program crashes with HTTP error code 500
I see that your include: use CGI::Carp (fatalsToBrowser);
... stifles the HTTP 500 error. Simply removing this will allow the programs to crash "properly".

Why can't I connect to my CAS server with Perl's AuthCAS?

I'm attempting to use an existing CAS server to authenticate login for a Perl CGI web script and am using the AuthCAS Perl module (v 1.3.1). I can connect to the CAS server to get the service ticket but when I try to connect to validate the ticket my script returns with the following error from the IO::Socket::SSL module:
500 Can't connect to [CAS Server]:443 (Bad hostname '[CAS Server]')
([CAS Server] substituted for real server name)
Symptoms/Tests:
If I type the generated URL for the authentication into the web browser's location bar it returns just fine with the expected XML snippet. So it is not a bad host name.
If I generate a script without using the AuthCAS module but using the IO::Socket::SSL module directly to query the CAS server for validation on the generated service ticket the Perl script will run fine from the command line but not in the browser.
If I add the AuthCAS module into the script in item 2, the script no longer works on the command line and still doesn't work in the browser.
Here is the bare-bones script that produces the error:
#!/usr/bin/perl
use strict;
use warnings;
use CGI;
use AuthCAS;
use CGI::Carp qw( fatalsToBrowser );
my $id = $ENV{QUERY_STRING};
my $q = new CGI;
my $target = "http://localhost/cgi-bin/testCAS.cgi";
my $cas = new AuthCAS(casUrl => 'https://cas_server/cas');
if ($id eq ""){
my $login_url = $cas->getServerLoginURL($target);
printf "Location: $login_url\n\n";
exit 0;
} else {
print $q->header();
print "CAS TEST<br>\n";
## When coming back from the CAS server a ticket is provided in the QUERY_STRING
print "QUERY_STRING = " . $id . "</br>\n";
## $ST should contain the received Service Ticket
my $ST = $q->param('ticket');
my $user = $cas->validateST($target, $ST); #### This is what fails
printf "Error: %s\n", &AuthCAS::get_errors() unless (defined $user);
}
Any ideas on where the conflict might be?
The error is coming from the line directly above the snippet Cebjyre quoted namely
$ssl_socket = new IO::Socket::SSL(%ssl_options);
namely the socket creation. All of the input parameters are correct. I had edited the module to put in debug statements and print out all the parameters just before that call and they are all fine. Looks like I'm going to have to dive deeper into the IO::Socket::SSL module.
As usually happens when I post questions like this, I found the problem. It turns out the Crypt::SSLeay module was not installed or at least not up to date. Of course the error messages didn't give me any clues. Updating it and all the problems go away and things are working fine now.
Well, from the module source it looks like that IO::Socket error is coming from get_https2
[...]
unless ($ssl_socket) {
$errors = sprintf "error %s unable to connect https://%s:%s/\n",&IO::Socket::SSL::errstr,$host,$port;
return undef;
}
[...]
which is called by callCAS, which is called by validateST.
One option is to temporarily edit the module file to put some debug statements in if you can, but if I had to guess, I'd say the casUrl you are supplying isn't matching up to the _parse_url regex properly - maybe you have three slashes after the https?