Bugzilla error: Can't locate object method quit via package “Net::SMTP::SSL” line 365

[Sarah Weinberger]

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 posted a detailed write-up in the Stack Exchange forum, no answers, hence here on a dedicated bugzilla forum, so if the above is not enough details, then...

https://unix.stackexchange.com/questions/547324/bugzilla-error-cant-locate-object-method-quit-via-package-netsmtpssl-lin

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

Any thoughts?

[Thorsten Schöning]

Guten Tag Sarah Weinberger,
am Mittwoch, 23. Oktober 2019 um 02:24 schrieben Sie:

> 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 list is full of threads
regarding thic 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.

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail: Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[Sarah Weinberger]

Fixed:

I missed the last response from the customer, when he wrote:

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

That command resolved the issue. The original post is at:
https://support-bugzilla.mozilla.narkive.com/ULqK5oBb/error-while-smtp-setup

My email is now working fine. This command should have been in the installation instructions.

[Thorsten Schöning]

Guten Tag Sarah Weinberger,
am Freitag, 25. Oktober 2019 um 03:07 schrieben Sie:

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

[...]

> My email is now working fine. This command should have been in the installation instructions.

No one can know that and how and where you have installed old versions
of Perl-libs and how you make those available to Bugzilla or not etc.
That's why people should prefer the package manager of their
distribution in favor of using CPAN directly and Net::SMTP::SSL is
mentioned for that e.g. for Fedora and RedHat:

> perl(Net::SMTP::SSL)

https://bugzilla.readthedocs.io/en/5.0/installing/linux.html#fedora-and-red-hat

[Sarah Weinberger]

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.

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

----

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.

[Thorsten Schöning]

Guten Tag Sarah Weinberger,
am Freitag, 25. Oktober 2019 um 17:14 schrieben Sie:

> ./testserver.pl script still fails with being able to read padlock.png.

Then your setup most likely still isn't correct:

> TEST-OK Webserver is running under group id in $webservergroup.
> TEST-OK Got padlock picture.
> TEST-OK Webserver is executing CGIs via mod_cgi.
> TEST-OK Webserver is preventing fetch of http://[...]/localconfig.
> TEST-OK GD version 2.53, libgd version 2.1.1; Major versions match.
> TEST-OK GD library generated a good PNG image.
> TEST-OK Chart library generated a good PNG image.
> TEST-OK Template::Plugin::GD is installed.

> There is no "theme" support. The gray is drab.

There is and you might even adopt the one used by Mozilla itself, it's
published at GitHub:

https://bugzilla.readthedocs.io/en/5.0/integrating/skins.html
https://wiki.mozilla.org/Bugzilla:Addons#Skins
https://github.com/mozilla-bteam/bmo/tree/master/skins

> Also, upgrades
> should be simpler. I can imagine either an automatic update or a
> button that when pressed updates the software, much like Plesk.

Pulling using GIT and running checksetup.pl is pretty simple.
Everything else requires permissions Bugzilla itself simply shouldn't
have, additional daemons or complex stuff like that.

> 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.

One can't expect to get docs for every possible environment out there.

> Also the local configuration file, ./localconfig, is missing a field
> for the user, not just the group to use.

It's not, the owning user of the files of Bugzilla should be different
from the user executing the web server for security purposes, because
the owning user is root or some admin. Bugzilla simply assumes that
the owner to use is the one executing checksetup.pl and that makes a
lot of sense.

https://github.com/bugzilla/bugzilla/blob/release-5.0-stable/Bugzilla/Install/Filesystem.pm#L912

> 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.

That's a pretty weird system setup then and doesn't make much sense to
me. You might want to have a look a the group membership of "psacln"
or "apache", one of both might be a member of the other.

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

You should have better ran checksetup.pl as "jmr-admin" instead,
that's what the user seems to be for. If it's only used for
web-admin-stuff, the setup of your system sounds a bit weird again in
my opinion.

> 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.

If "httpd.conf" get overridden at all and if so which of its
statements, is totally system-dependent. My Ubuntu doesn't even
provide "conf.d" and instead documents another directory layout in
"httpd.conf", so mentioned that file as a starting point to look at
totally makes sense.

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

That's not the best way, because if ".htaccess" is recognized at all
and which statements in there are accepted is highly setup specific.
Additionally, reeading ".htaccess" is slow and Bugzilla maintains one
in its own root directory already, which one doesn't want to
customize.

> * Handlers: Enter custom values
> cgi-script .cgi
> cgi-script .pl

There's a reason why the official docs only assign .cgi to be executed
by the web server, .pl-files are nto designed to be. So don't
configure both file extensions, only .cgi instead. .pl-files are
helpers for the shell only and most likely won't work if requested by
a browser.

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

It is, it might simply come from other parts of your config already.

> 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.

Instead of copying manually one should use GIT and no, changing
permissions manually shouldn't be necessary in a correct setup.
Especially not execute permissions on image files.

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

Which means that either your package manager doesn't provide all
depoendencies or those are incompatible old for some reason. Besides
that, mixing CPAN and package manager is a very bad idea, things will
most likely break if your package manager upgrades Perl and makes it
binary incompatible with currently installed packages by CPAN and
stuff.

If CPAN is really needed, you should prefer using install-module.pl,
because that puts everything in the lib-folde rof Bugzilla. That
doesn't affect your system and can easily be wiped out in case of
problems.

> I did look at the original Bugzilla docs and at first thought that
> Chinese would be easier to read.

You simply need to do what's said there and I guarantee you you would
have run into fewer problems.

> 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.

Which wasn't the best idea, because preferring WGET and TAR makes your
upgrades PITA.

> That was incomplete as that did not discuss permissions or Plesk or
> any of the changes that I said need doing.

Which is pretty often the case with unofficial, outdated "I installed
Bugzilla ones"-blogs.

> 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.

You can't tell that because you didn't try. You would need to get the
reason why you need to upgrade Net::SMTP::SSL using CPAN manually,
which shouldn't be the case normally.

> Letting my web host provider initially make changes was maybe good,

It wasn't.

> 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.

Because you didn't follow the official docs, which explicitly say that
you need to care about localconfig and that Bugzilla resets
permissions.