3

I installed Bugzilla on my CentOS 7 web server VPS. The install went smoothly, however when I went to set up email, I received the following error:

Can't locate object method "quit" via package "Net::SMTP::SSL" at Bugzilla/Config/Common.pm line 365.

For help, please send mail to the webmaster (********), giving this error message and the time and date of the error.

I set the email configuration to connect to Office 365, which means:

SMTP Server: smtp.office365.com:587 smtp_ssl: on Username/password/mailfrom: that of the email address that I am using.

I viewed the source file, Config/Common.pm, in question:

344
345 sub check_smtp_server {
346     my $host = shift;
347     my $port;
348
349     if ($host =~ /:/) {
350         ($host, $port) = split(/:/, $host, 2);
351         unless ($port && detaint_natural($port)) {
352             return "Invalid port. It must be an integer (typically 25, 465 or 587)";
353         }
354     }
355     trick_taint($host);
356     # Let's first try to connect using SSL. If this fails, we fall back to
357     # an unencrypted connection.
358     foreach my $method (['Net::SMTP::SSL', 465], ['Net::SMTP', 25]) {
359         my ($class, $default_port) = @$method;
360         next if $class eq 'Net::SMTP::SSL' && !Bugzilla->feature('smtp_ssl');
361         eval "require $class";
362         my $smtp = $class->new($host, Port => $port || $default_port, Timeout => 5);
363         if ($smtp) {
364             # The connection works!
365             $smtp->quit;
366             return '';
367         }
368     }
369     return "Cannot connect to $host" . ($port ? " using port $port" : "");
370 }
371

What I deduced is that the connection information was a success and that Bugzilla was merely trying to quit the connection and return, no errors.

I found this article on the internet regarding this problem.

Mr. Thorsten Schoning said:

Then debug further: Check the version of your installed Net::SMTP::SSL, have a look at the source if a "quit" method is available etc. There should be a file Net/SMTP/SSL.pm somewhere in your perl installation or wherever and however you install packages. If you have used install-module.pl, empty the bugzilla/lib folder and install missing packages again using your package manager.

Additionally look at the mentioned line of the Bugzilla code to see what Bugzilla thinks: It thinks you have Net::SMTP::SSL available, expects an available method and that seems to be missing. You need to find the reason why because from my understanding it should be available.

Well, I did a locate for SSL.pm and came up with:

[root@tkts-wtsc /]# locate SSL.pm
/usr/lib64/perl5/vendor_perl/Net/SSL.pm
/usr/share/perl5/vendor_perl/HTTP/Daemon/SSL.pm
/usr/share/perl5/vendor_perl/IO/Socket/SSL.pm
/usr/share/perl5/vendor_perl/Net/MQTT/Simple/SSL.pm
/usr/share/perl5/vendor_perl/Net/SMTP/SSL.pm
/usr/share/perl5/vendor_perl/Net/Server/Proto/SSL.pm
/usr/share/perl5/vendor_perl/Software/License/OpenSSL.pm

I viewed the contents of Net/SMTP/SSL.pm, but that did not contain any subroutines. I then viewed the contents of /Net/SSL.pm and saw subroutines/methods, but none of them quit, but then quit is an SMTP command, so I am not surprised there. Not sure if Mr. Schoning's response means anything or not, but even HIS linked SSL.pm source does not contain a quit method.

I did a sudo yum install mod_ssl openssl as mentioned somewhere else and I get already installed and latest version, nothing to do.

I did a sudo yum install perl-Net-SMTP-SSL and got Package perl-Net-SMTP-SSL-1.01-13.el7.noarch already installed and latest version. I installed all packages and updated everything.

This question is a server setup issue, not a programming one, hence my placement of this question here and not on SO. I merely mention the source files, as the error mentioned it and I wanted to be complete and give all the details.

I set the permissions for key folders:

drwxr-x---  2 jmr-admin psacln   4096 Oct 17 08:33 Config
-rwxr-x---  1 jmr-admin psacln  13547 Oct 16 16:55 Config.pm

and all items in the Config folder are the same as:

-rwxr-x---  1 jmr-admin psacln 16836 Oct 16 16:55 Common.pm

Now that I am writing this question, I do not think the issue is permissions, as perl found the SMTP module, not to mention SSL module, successfully did a test and was attempting to quit the connection, when perl could not find the quit method.

I DID turn On the smtp_debug option, but I got no additional details.

I found this reference, lot of good information, such as to include the port in the SMTP server field, which I originally forgot to do. Sadly, this reference did not resolve my problem. For what it is worth, I also tried my gmail account, as this article references Gmail. In that way, I could enter the information EXACTLY as on this page. I copied and pasted the information. I got the same error, immediately with no delay. That was a bit weird, as I would have expected a slight delay from either Gmail or Office 365, but whatever.

UPDATE

I am still looking and ran into this article. The result of sesstatus -b is SELinux status: disabled. That is possibly another problem, but not relating to my inability to send emails. If anything, it is a good thing for troubleshooting. Anyways, I discovered that there is such a thing as /var/log/httpd/error_log. The contents of this file are (keeps repeating for every attempt):

[Thu Oct 17 09:17:22 2019] editparams.cgi: *******************************************************************
[Thu Oct 17 09:17:22 2019] editparams.cgi:   at Bugzilla/Config/Common.pm line 362.
[Thu Oct 17 09:17:22 2019] editparams.cgi: Can't locate object method "quit" via package "Net::SMTP::SSL" at Bugzilla/Config/Common.pm line 365.
[Thu Oct 17 09:23:07 2019] editparams.cgi: Odd number of elements in hash assignment at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 336.
[Thu Oct 17 09:23:07 2019] editparams.cgi: *******************************************************************
[Thu Oct 17 09:23:07 2019] editparams.cgi:  Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
[Thu Oct 17 09:23:07 2019] editparams.cgi:  is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
[Thu Oct 17 09:23:07 2019] editparams.cgi:  possibly with SSL_ca_file|SSL_ca_path for verification.
[Thu Oct 17 09:23:07 2019] editparams.cgi:  If you really don't want to verify the certificate and keep the
[Thu Oct 17 09:23:07 2019] editparams.cgi:  connection open to Man-In-The-Middle attacks please set
[Thu Oct 17 09:23:07 2019] editparams.cgi:  SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
[Thu Oct 17 09:23:07 2019] editparams.cgi: *******************************************************************
[Thu Oct 17 09:23:07 2019] editparams.cgi:   at Bugzilla/Config/Common.pm line 362.
[Thu Oct 17 09:23:07 2019] editparams.cgi: Can't locate object method "quit" via package "Net::SMTP::SSL" at Bugzilla/Config/Common.pm line 365.
~

This log shows that I have another side task to fix a deprecated CentOS setting and limit a Main-In-The-Middle attack, but that does not appear to be germane to my quit method nonexistence issue. I have to research that a bit more.

The real error is line 362. That should have probably returned null / false to indicate an error. I bet that had line 362 really succeeded, then the quit method would exist. Sadly, I this environment is not under Visual Studio, where I can set a breakpoint and view contents. I am in server admin mode, so...

my $smtp = $class->new($host, Port => $port || $default_port, Timeout => 5);

Okay, I found this article, which helped me solve the SSL_VERIFY_NONE warnings. I opened up /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm did a vi command, :set number, and then issue the command, /DEFAULT_SSL_ARGS, which took me to line 35. I then changed on line 49 from SSL_verify_mode => SSL_VERIFY_NONE, to SSL_verify_mode => SSL_VERIFY_PEER,. I then saved my changes and quit. I tried my email settings again and much better.

[root@tkts-wtsc Config]# vi /var/log/httpd/error_log
[root@tkts-wtsc Config]#
[Thu Oct 17 09:23:07 2019] editparams.cgi:  possibly with SSL_ca_file|SSL_ca_path for verification.
[Thu Oct 17 09:23:07 2019] editparams.cgi:  If you really don't want to verify the certificate and keep the
[Thu Oct 17 09:23:07 2019] editparams.cgi:  connection open to Man-In-The-Middle attacks please set
[Thu Oct 17 09:23:07 2019] editparams.cgi:  SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
[Thu Oct 17 09:23:07 2019] editparams.cgi: *******************************************************************
[Thu Oct 17 09:23:07 2019] editparams.cgi:   at Bugzilla/Config/Common.pm line 362.
[Thu Oct 17 09:23:07 2019] editparams.cgi: Can't locate object method "quit" via package "Net::SMTP::SSL" at Bugzilla/Config/Common.pm line 365.
[Thu Oct 17 11:19:04 2019] editparams.cgi: Odd number of elements in hash assignment at /usr/share/perl5/vendor_perl/IO/Socket/IP.pm line 336.
[Thu Oct 17 11:19:04 2019] editparams.cgi: Can't locate object method "quit" via package "Net::SMTP::SSL" at Bugzilla/Config/Common.pm line 365.
~

I am down to only 2 lines. What is interesting is that i do not get the complaint anymore about line 362. Hmm.

If anyone is curious, here is the code to IP.pm at line 336:

[root@tkts-wtsc Config]# vi /usr/share/perl5/vendor_perl/IO/Socket/IP.pm
[root@tkts-wtsc Config]#
325
326 As a special case, if the constructor is passed a single argument (as
327 opposed to an even-sized list of key/value pairs), it is taken to be the value
328 of the C<PeerAddr> parameter. This is parsed in the same way, according to the
329 behaviour given in the C<PeerHost> AND C<LocalHost> PARSING section below.
330
331 =cut
332
333 sub new
334 {
335    my $class = shift;
336    my %arg = (@_ == 1) ? (PeerHost => $_[0]) : @_;
337    return $class->SUPER::new(%arg);
338 }
339

(Sorry about the long question, more like me keeping notes, but I am hoping that others might benefit from all this information and the methodology that I used. There is virtually nothing out there, and if I ran into this bug, others will too.)

Anyways, so how do I fix the problem?

0

This question has made its way to the support mailing list, so I'm adding my answer here for completeness, but suggest discussing everything else there:

https://groups.google.com/d/msg/mozilla.support.bugzilla/ctvU6urNN0s/oj90IeduEAAJ

Can't locate object method "quit" via package "Net::SMTP::SSL" at Bugzilla/Config/Common.pm line 365.

In my opinion you have two different problems, this one and Office365. Look at the thread from the past you linked on StackExchange already:

https://support-bugzilla.mozilla.narkive.com/ULqK5oBb/error-while-smtp-setup

Multiple writers answered that there problem was gone after reinstalling the Perl-module. And from my experience your first problem really comes from missing dependencies, like openssl-dev or such.

So if you used install-module.pl to install Perl-dependencies, empty the lib-folder of Bugzilla and reinstall the dependencies using the package manager of your distribution. Those provide SSL-related additional dependencies most likely. install-module.pl is only the last step if things are really only available by CPAN to you. In that case, you might need to fulfill additional dependencies like openssl-dev using your package manager manually.

I viewed the contents of Net/SMTP/SSL.pm, but that did not contain any subroutines.

Because things are imported automatically during compilation time, so you won't find the name itself. But I'm somewhat sure that in a working setup you really end up with "quit" being available. I should have made that more clear in the past of course. The following code is the important thing:

no strict 'refs';
foreach ( keys %Net::SMTP:: ) {
    next unless (ref(\$Net::SMTP::{$_}) eq "GLOB" && defined(*{$Net::SMTP::{$_}}{CODE}))
              || ref(\$Net::SMTP::{$_}) eq "REF";
    *{$_} = \&{"Net::SMTP::$_"};
}

https://fastapi.metacpan.org/source/RJBS/Net-SMTP-SSL-1.03/lib/Net/SMTP/SSL.pm

I then viewed the contents of /Net/SSL.pm and saw subroutines/methods, but none of them quit, but then quit is an SMTP command, so I am not surprised there.

Net::SMTP contains "quit", not Net::SSL and that is imported by the above code:

quit () Send the QUIT command to the remote SMTP server and close the socket connection.

https://perldoc.perl.org/Net/SMTP.html

I set the email configuration to connect to Office 365, which means:

Office 365 doesn't work OOB currently, the support mailing list is full of threads regarding this topic:

https://bugzilla.mozilla.org/show_bug.cgi?id=1182445 https://groups.google.com/d/msg/mozilla.support.bugzilla/xFqK7S3h25g/6KI4Fg1NAAAJ https://groups.google.com/d/msg/mozilla.support.bugzilla/xFqK7S3h25g/JF52kHGWEQAJ

You can only choose which of the many workarounds you prefer or simply not use Office 365 at all. I do prefer not customizing Bugzilla as much as possible and would therefore prefer some local sendmail or such taking care of forwarding mails to Office 365. But that's up to you in the end.

SMTP Server: smtp.office365.com:587 smtp_ssl: on

I'm somewhat sure that smtp_ssl is really SSL, not TLS as required by Office 365 anyway, so this config most likely wouldn't work even if Bugzilla supported 365.

I contacted my web hosting provider, Media Temple, and they were very unprofessional and refused to even consider helping.

Besides the SSL-dependencies of your first error message, they can't really help anyway. Support for Office 365 needs to be implemented by Bugzilla or worked around using some other local MTA.

0

Mr. Schoning's answer is not wrong and did lead me to the solution. Basically, for the specific error I just did not see (understand more than likely) that very last response in the following link, where the author said that he had to run the following command. I executed the command and presto, instant success with emails.

Link to other Customer with Problem

thanks solved using 'cpan upgrade Net::SMTP::SSL' command

For others, and for that matter a possible future me, I will explain things.

Before that, however, even though Bugzilla works (UI is fine, ability to add users, projects, etc. are all fine), the ./testserver.pl script still fails with being able to read padlock.png.

Feature Requests

  1. There is no "theme" support. The gray is drab. Also, upgrades should be simpler.
  2. I can imagine either an automatic update or a button that when pressed updates the software, much like Plesk.

Write-up

There is a misunderstanding on how things went down and even if I followed the official Bugzilla docs originally, which I later did, the docs was still incomplete and not applicable to my environment. Also the local configuration file, ./localconfig, is missing a field for the user, not just the group to use.

Before continuing, here is my environment:

  • CentOS 7 running Plesk Obsidian in a VPS (what Media Temple calls "DV")

The HTTPD configuration file, /etc/httpd/httpd.conf, showed that the user and group for HTTPD are both "apache". That is what the Bugzilla documents said to use in the ./localconfig file too! Sadly, that is wrong. The correct answer is "psacln" for the group. The best way to figure that out is to create a new temporary subdomain and look at the owner and group of the default files. In my case the answer is "jmr-admin:psacln". Placing psacln in the Bugzilla configuration file took care of the group policy. That means the two changes for apache are:

 # If you set this to anything other than "", you will need to run checksetup.pl
 # as root or as a user who is a member of the specified group.
 $webservergroup = 'psacln';

 # If set to 1, checksetup.pl will set file permissions so that Bugzilla
 # works in a SuexecUserGroup environment.
 $use_suexec = 1;

I had to manually change the user from "root" to "jmr-admin" after I reran ./checksetup.pl.

There are NO direct changes to /etc/httpd/httpd.conf. Nobody on any platform should make changes there, as that file gets overridden. If anything create a custom configuration file and place in the /etc/httpd/conf.d/ directory. The httpd configuration file, httpd.conf, automatically reads this directory. For my case adding something there IS WRONG and messed things up. The correct thing to do is one of two things:

1) (best way): Add a .htaccess file and set the contents to:

#CGI
DirectoryIndex index.cgi
AddHandler cgi-script .cgi
AddHandler cgi-script .pl
Options +ExecCGI
#

2) Inside Plesk edit for the domain (or subdomain as in my case) environment, namely: [domain] > Apache & nginx Settings >

  • Handlers: Enter custom values

    cgi-script .cgi cgi-script .pl

  • Index files: Enter custom value (leave default ones)

Note: Using this leaves out the "Options +ExecCGI", though that does not seem necessary.

The best way to verify CGI is to create a brand new test subdomain and place a cgi script in the root directory, such as my testcgi2.cgi.

#!/usr/bin/perl

print "Content-type:text/html\r\n\r\n";
print '<html>';
print '<head>';
print '<title>Hello Word - First CGI Program</title>';
print '</head>';
print '<body>';
print '<h2>Hello Word! This is my first CGI program</h2>';
print '</body>';
print '</html>';

1;

If changes to Apache are fine, then the script will show this formatted text with no code:

Hello Word! This is my first CGI program

I then copied the files from the downloaded compressed file to the subdomain. You might have to set permissions to 755 on extra key files.

I did have to run the yum command as indicated in the CentOS 7 and Bugzilla docs.

I had to run that extra script to get SMTP working, so that I do not get that annoying lack of a quit method.

I did look at the original Bugzilla docs and at first thought that Chinese would be easier to read. At least I once saw the mini series Shogun on TV, though that was Japanese. I contacted my web host provider, who gave me the link to the Bugzilla CentOS 7 guide.

That was incomplete as that did not discuss permissions or Plesk or any of the changes that I said need doing. The Bugzilla docs, which now is less Chinese like and more English like after days of suffering would still not have gotten the job done. Letting my web host provider initially make changes was maybe good, so that I saw that the site could come up, but with a lack of explaining and the lack of my current knowledge everything was bound to quickly not work the next time that I ran the ./checksetup.pl script.

I think that covers everything. I am still not an expert by any stretch, but hopefully my write-up helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.