Author Topic: 1.9 AMaViS issues (Read 8986 times)

emilyf · October 18, 2007, 07:13:02 am

I'm on Fedora Core 7, php 5.2.2, Zend 2.2.0. Per 1.9 upgrade instructions, I am trying to get my AMaViS to comply with 1.9.

I've got it all down to one entry in /etc/amavisd/amavisd.conf. At the
end of that file the CiviMail install calls for, among other things,
this line:

$civicrm_soap_proxy =
'http://localhost/modules/civicrm/extern/soap.php';

Whenever I enable that line, amavisd crashes on startup with this error:

TROUBLE in pre_loop_hook: Can't call method "fault" on an undefined
value at (eval 43) line 134

If I comment out the civicrm_soap_proxy line, everything seems to work
fine.

Any insight would be appreciated! Thanks!

Piotr Szotkowski · October 18, 2007, 07:32:47 am

Do you get an XML file when you go to http://localhost/modules/civicrm/extern/soap.php with your browser?

Note: if you put CiviCRM under sites/all/modules, this should most probably be more to the point of http://localhost/sites/all/modules/civicrm/extern/soap.php

emilyf · October 18, 2007, 11:45:18 am

No, I get a PHP error:
Fatal error: Class 'SoapServer' not found in /var/www/html/modules/civicrm/extern/soap.php on line 33

hmmm. What have I done?

Piotr Szotkowski · October 18, 2007, 10:34:19 pm

You most probably don’t have SOAP support in your PHP 5 install (check phpinfo() output to be sure).

I have no idea how PHP is packaged in Fedora, so if you’re using packages, you need to track down the one that provides SOAP. If you compiled PHP yourself, you should have done it with the --enable-soap flag.

emilyf · October 22, 2007, 07:45:57 am

I see, thank you. CiviMail still sends out mailings OK with this line commented out. Can you tell me if I'm going to run into trouble if I don't deal with it and instead leave it commented out? Thanks!

Piotr Szotkowski · October 23, 2007, 03:16:29 am

It means you don’t have support for the return channel – un-, re- and subscribes, etc. – over SMTP (in 1.9, you can replace this with HTTP actions, i.e., clickable links).

You also don’t have bounce handling, i.e., you don’t know how many of your target addresses bounce and you keep sending to them, even if these are permanent errors (without AMaViS, you can handle this using the community-created and -supported imap2soap).

ChrisStanleyCCTV · November 07, 2007, 07:39:35 am

I've been working with Emily on this issue and we've made some progress but we're still having problems. I got SOAP installed into PHP successfully and I can now enable the $civicrm_soap_proxy entry in amavisd.conf without it crashing on startup. But when I do, any time messages try to go out I get this error in the mail log from postfix:

conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting

So it looks like when SOAP is enabled, amavisd stops responding to requests from postfix. I'm guessing amavisd is trying to talk to SOAP and getting hung up, but I couldn't squeeze an error message out of amavisd, even with turning the logging all the way up. The last message I get from amavisd when SOAP is enabled is this:

amavis[13900]: CiviCRM: initializing

Unfortunately, SOAP doesn't feature any sort of logging, so I can't tell what its view of things is.

Also, when I load http://localhost/modules/civicrm/extern/soap.php, I get nothing at all. No errors, but also no content.

I'm afraid I'm a bit stumped at this point. Does anyone have any suggestions?

Thanks!

Piotr Szotkowski · November 08, 2007, 01:47:49 am

Quote from: ChrisStanleyCCTV on November 07, 2007, 07:39:35 am

I get this error in the mail log from postfix:

conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting

What do you get when you telnet localhost 10024 (or whatever port AMaViS is listening on)?

Quote from: ChrisStanleyCCTV on November 07, 2007, 07:39:35 am

I couldn't squeeze an error message out of amavisd, even with turning the logging all the way up.

AMaViS is most chatty when ran in debug mode, but I assume that’s how you’re running it already.

Quote from: ChrisStanleyCCTV on November 07, 2007, 07:39:35 am

Also, when I load http://localhost/modules/civicrm/extern/soap.php, I get nothing at all. No errors, but also no content.

Are you sure the file’s placed in /modules/civicrm/extern (and not, say, /sites/all/modules/civicrm/extern)?

ChrisStanleyCCTV · November 08, 2007, 07:53:53 am

Quote from: Piotr Szotkowski on November 08, 2007, 01:47:49 am

What do you get when you telnet localhost 10024 (or whatever port AMaViS is listening on)?

Without $civicrm_soap_proxy, I get:

220 [127.0.0.1] ESMTP amavisd-new service ready

With $civicrm_soap_proxy, I connect but there is nothing returned.

Quote from: Piotr Szotkowski on November 08, 2007, 01:47:49 am

AMaViS is most chatty when ran in debug mode, but I assume that’s how you’re running it already.

I'm using "$log_level = 5" in amavisd.conf, which is the most detail I know how to get. Is that considered debug or is there another method I'm missing?

Quote from: Piotr Szotkowski on November 08, 2007, 01:47:49 am

Are you sure the file’s placed in /modules/civicrm/extern (and not, say, /sites/all/modules/civicrm/extern)?

Yes, the file is located at /var/www/html/modules/civicrm/extern/soap.php, which maps to http://localhost/modules/civicrm/extern/soap.php. The httpd access log shows a successful page load, there's just no output.

Thanks!

Piotr Szotkowski · November 09, 2007, 02:53:42 am

Quote from: ChrisStanleyCCTV on November 08, 2007, 07:53:53 am

With $civicrm_soap_proxy, I connect but there is nothing returned.

You do specify $civicrm_soap_login and $civicrm_soap_pass as well, right?

Quote from: ChrisStanleyCCTV on November 08, 2007, 07:53:53 am

I'm using "$log_level = 5" in amavisd.conf, which is the most detail I know how to get. Is that considered debug or is there another method I'm missing?

When you start AMaViS with /etc/init.d/amavis start, you can start it with /etc/init.d/amavis debug instead – it won’t detach from the console and it’ll show you what’s going on ‘live’.

ChrisStanleyCCTV · November 12, 2007, 12:45:50 pm

Quote from: Piotr Szotkowski on November 09, 2007, 02:53:42 am

You do specify $civicrm_soap_login and $civicrm_soap_pass as well, right?

Yes, the end of my amavisd.conf is this:

Code: [Select]

# CiviMail integration

use strict;

# CiviCRM configs
$civicrm_soap_proxy =
    'http://localhost/modules/civicrm/extern/soap.php';

$civicrm_soap_login = '*****';
$civicrm_soap_pass  = '*****';

# If you configure a civicrm_sql_dsn, the proxy, login and pass information is
# retrieved from the database, and the $civicrm_soap_proxy, $civicrm_soap_login
# and $civicrm_soap_pass are ignored.  You must configure civicrm_sql_dsn if
# you want to support multiple CiviMail installations on a shared server.
#
# @civicrm_sql_dsn =
#   ( ['DBI:mysql:database=mail;host=127.0.0.1;port=3306', 'user1', 'passwd1'],
#     ['DBI:mysql:database=mail;host=host2', 'username2', 'password2'] );

# unset antivirus scanners
@av_scanners = ();
@av_scanners_backup = ();

1;  # insure a defined return

Quote from: Piotr Szotkowski on November 09, 2007, 02:53:42 am

When you start AMaViS with /etc/init.d/amavis start, you can start it with /etc/init.d/amavis debug instead – it won’t detach from the console and it’ll show you what’s going on ‘live’.

Fedora doesn't like /etc/init.d/amavis debug, but I sorted out /usr/sbin/amavisd -c /etc/amavisd/amavisd.conf debug, which seems to accomplish the same thing. Unfortunately, I get the same thing on the console as I did in the log. CiviCRM: initializing is the last thing it reports, and then silence. All postfix connections time out.

Piotr Szotkowski · November 13, 2007, 02:43:15 am

Quote from: ChrisStanleyCCTV on November 12, 2007, 12:45:50 pm

Unfortunately, I get the same thing on the console as I did in the log. CiviCRM: initializing is the last thing it reports, and then silence. All postfix connections time out.

Hm, I’m a bit stuck. Your best bet would be to edit the /usr/sbin/amavisd ‘binary’ by hand and see what exactly makes it not work (i.e., find where we log CiviCRM: initializing and work your way down until you see which line breaks it). :|

ChrisStanleyCCTV · November 13, 2007, 07:52:04 am

Quote from: Piotr Szotkowski on November 13, 2007, 02:43:15 am

Hm, I’m a bit stuck. Your best bet would be to edit the /usr/sbin/amavisd ‘binary’ by hand and see what exactly makes it not work (i.e., find where we log CiviCRM: initializing and work your way down until you see which line breaks it). :|

I've dug through the code and found the offending bit. In /usr/sbin/amavisd, right after CiviCRM: initializing is logged, sub authenticate($) (line 14857) is called:

Code: [Select]

sub init() {
    do_log(1, "CiviCRM: initializing");
    
    # If we're not configuring via the database then we set up the soapClient 
    # once, so we do it while initializing CiviCRM.  If we are configuring via
    # the database, then we set up the soapClient each time we process a CiviCRM
    # mail.
    if (!@civicrm_sql_dsn) {
      $soapClient = SOAP::Lite
          -> proxy($civicrm_soap_proxy, 
              cookie_jar => HTTP::Cookies->new(ignore_discard => 1))
          -> uri('urn:civicrm');

      authenticate(0);
    }
    
    do_log(1, "CiviCRM: done");
}

Which is:

Code: [Select]

sub authenticate($) {

    my($domain_id) = shift(@_);
    my($proxy, $login, $pass);

    if (@civicrm_sql_dsn) {
...
    }
    else {
      $login = $civicrm_soap_login;
      $pass = $civicrm_soap_pass;
    }

    my $result = 
        $soapClient->authenticate($login, $pass);
...

It locks up at that last line, my $result = $soapClient->authenticate($login, $pass);. I'm guessing it's meant to call the other authenticate sub (line 11488), which is:

Code: [Select]

sub authenticate($$$) {
  my($state,$auth_mech,$auth_resp) = @_;
  my($result,$newchallenge);
  if ($auth_mech eq 'ANONYMOUS') {   # rfc2245
    $result = [$auth_resp,undef];
  } elsif ($auth_mech eq 'PLAIN') {  # rfc2595, "user\0authname\0pass"
    if (!defined($auth_resp)) { $newchallenge = '' }
    else { $result = [ (split(/\000/,$auth_resp,-1))[0,2] ] }
  } elsif ($auth_mech eq 'LOGIN' && !defined $state) {
    $newchallenge = 'Username:'; $state = [];
  } elsif ($auth_mech eq 'LOGIN' && @$state==0) {
    push(@$state, $auth_resp); $newchallenge = 'Password:';
  } elsif ($auth_mech eq 'LOGIN' && @$state==1) {
    push(@$state, $auth_resp); $result = $state;
  } # CRAM-MD5:rfc2195,  DIGEST-MD5:rfc2831
  ($state,$result,$newchallenge);
}

I don't know perl, but isn't having two subs named "authenticate" generally a bad idea? In fact, I can comment out the non-CiviCRM authenticate sub (line 11488) and it fails in the exact same manner, so I don't think it's ever being called. It seems like maybe it's getting to my $result = $soapClient->authenticate($login, $pass); in the CiviCRM authenticate sub (line 14857) and then it's caught in a recursive loop calling itself and locks up. But since every single CiviCRM installation isn't broken, I feel like I must be missing something. Also, I tried renaming the CiviCRM authenticate sub to CiviCRMauthenticate and similarly changing all single-parameter calls (assuming the multi-parameter calls were intended for the other one), and it still fails in the same manner. So I guess that's not it.

But if the CiviCRM authenticate sub is neither recursing to itself nor calling the other authenticate sub, then what's happening at my $result = $soapClient->authenticate($login, $pass); that causes it to fail?

Piotr Szotkowski · November 14, 2007, 01:08:46 am

Quote from: ChrisStanleyCCTV on November 13, 2007, 07:52:04 am

It locks up at that last line, my $result = $soapClient->authenticate($login, $pass);. I'm guessing it's meant to call the other authenticate sub (line 11488)

No, it’s a call to $soapClient’s authenticate() – $soapClient is an instance of SOAP::Lite; also, as you can see, this authenticate() is a two-param method.

Quote from: ChrisStanleyCCTV on November 13, 2007, 07:52:04 am

I don't know perl, but isn't having two subs named "authenticate" generally a bad idea?

No when they’re methods of different classes. The first authenticate() called (the one-param one) is Amavis::CiviCRM’s, the second one you found (the three-param one) is Amavis::In::SMTP’s, and the one that hangs AMaViS (the two-param one) is SOAP::Lite’s.

Quote from: ChrisStanleyCCTV on November 13, 2007, 07:52:04 am

But if the CiviCRM authenticate sub is neither recursing to itself nor calling the other authenticate sub, then what's happening at my $result = $soapClient->authenticate($login, $pass); that causes it to fail?

You’ve nailed this here.

This is SOAP::Lite’s authenticate(), so my first two thoughts are that either AMaViS can’t connect to your CiviCRM instance (because the URL is wrong, for example) or you don’t have the SOAP::Lite Perl module installed.

Do you have the SOAP::Lite Perl module on that server?

ChrisStanleyCCTV · November 15, 2007, 07:10:54 am

Quote from: Piotr Szotkowski on November 14, 2007, 01:08:46 am

You’ve nailed this here. This is SOAP::Lite’s authenticate(), so my first two thoughts are that either AMaViS can’t connect to your CiviCRM instance (because the URL is wrong, for example) or you don’t have the SOAP::Lite Perl module installed.

Do you have the SOAP::Lite Perl module on that server?

Yes, I have perl-SOAP-Lite 0.68-2.fc6 installed. And the URL loads without error, so I don't think that's it. Could it be the user/pass? I've got it set for the local CiviMail account, is that correct?

CiviCRM Community Forums (archive)

News:

Author Topic: 1.9 AMaViS issues (Read 8986 times)

emilyf

1.9 AMaViS issues

Piotr Szotkowski

Re: 1.9 AMaViS issues

emilyf

Re: 1.9 AMaViS issues

Piotr Szotkowski

Re: 1.9 AMaViS issues

emilyf

Re: 1.9 AMaViS issues

Piotr Szotkowski

Re: 1.9 AMaViS issues

ChrisStanleyCCTV

Re: 1.9 AMaViS issues

Piotr Szotkowski

Re: 1.9 AMaViS issues

ChrisStanleyCCTV

Re: 1.9 AMaViS issues

Piotr Szotkowski

Re: 1.9 AMaViS issues

ChrisStanleyCCTV

Re: 1.9 AMaViS issues

Piotr Szotkowski

Re: 1.9 AMaViS issues

ChrisStanleyCCTV

Re: 1.9 AMaViS issues

Piotr Szotkowski

Re: 1.9 AMaViS issues

ChrisStanleyCCTV

Re: 1.9 AMaViS issues