Email receiver hanging

[lexx015]

Hello!

I have found an issue with receiving email. This issue occurs only you have LDAP integration but by some reasons LDAP servers are not available.

In my case there are:

• My organization's DC which uses for technicians and for email receivers(exchange server) in same network with GLPI.
• Customer's DC via VPN.

Sometimes VPN became disconnected and customer's DC became unavailable. In this case GLPI hangs on ticket receiving.

I just made some research and got about 2 minutes for email receiver duration per 1 email for user from unavailable DC.

Date Total duration Number Description
19-04-2016 17:00 128.353 seconds 2 Action completed, fully processed (one email from local user(available DC) and one from customer(unavailable DC))
19-04-2016 16:51 128.010 seconds 1 Action completed, fully processed
19-04-2016 16:43 128.391 seconds 1 Action completed, fully processed
19-04-2016 16:33 0.372 seconds 0 Action completed, no processing required
19-04-2016 16:15 510.870 seconds 3 Action completed, fully processed(2 DC's are unavailable)
19-04-2016 16:07 110.165 seconds 0 Action completed, no processing required
19-04-2016 16:03 0.365 seconds 0 Action completed, no processing required

This issue occurs with 2 GLPI versions on different servers.

My configuration:
Test version:

GLPI 0.90.1-384-gefdec25 (/glpi => /usr/share/glpi)
Operating system: Linux ctld01 4.5.0-1-amd64 #1 SMP Debian 4.5.1-1 (2016-04-14) x86_64
PHP 7.0.5-3 apache2handler (Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apache2handler, calendar, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imap, json, ldap, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, pdo_mysql, pdo_pgsql, pgsql, posix, readline, session, shmop, sockets, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, zip, zlib)
Setup: max_execution_time="30" memory_limit="128M" post_max_size="8M" safe_mode="" session.save_handler="files" upload_max_filesize="2M"
Software: Apache/2.4.20 (Debian) (Apache/2.4.20 (Debian) Server at 10.0.250.11 Port 80)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Server Software: (Debian)
Server Version: 5.6.28-1-log
Server SQL Mode: NO_ENGINE_SUBSTITUTION
Parameters: root@localhost/glpi902
Host info: Localhost via UNIX socket

Stable server

GLPI 0.84.8 ( => /usr/share/glpi)
Operating system: Linux helpdesk 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03) x86_64
PHP 5.6.7-1 apache2handler (Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apache2handler, apc, apcu, bcmath, bz2, calendar, ctype, curl, date, dba, dom, ereg, exif, fileinfo, filter, ftp, gettext, hash, iconv, imap, json, ldap, libxml, mbstring, mcrypt, memcache, mhash, mysql, mysqli, openssl, pcre, pdo_mysql, posix, readline, session, shmop, soap, sockets, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlwriter, zip, zlib)
Setup: max_execution_time="30" memory_limit="128M" post_max_size="8M" safe_mode="" session.save_handler="files" upload_max_filesize="8M"
Software: Apache/2.4.10 (Debian) (Apache/2.4.10 (Debian) Server at helpdesk.ics.perm.ru Port 80)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
DBMS: Server Software: (Debian)
Server Version: 5.5.43-0+deb8u1-log
Parameters: glpi@localhost/glpi_new
Host info: Localhost via UNIX socket

[orthagh]

Hello @lexx015

Sorry for the long delay of this answer.
Your issue is pretty tricky to reproduce :)

By checking code, i think it can trigger only when the 'from' email address isn't known in glpi database.
The collector, first check in all the known addresses of referenced users and if not found, it triggers a full search on all ldap servers.

I think this behavior is the intended one and your usage with a ldap under vpn connection is a bit complex.
I suggest you to add to your crontab the auto import and update of the users by ldap connection.
You'll find in the scripts directory of glpi, a file name ldap_mass_sync.php to achieve this synchronisation.

After that, with all yours users regularly imported and updated, all customer's emails will be known and so, the synchronisation will not be triggered on email collect.

Otherwise, you can disable "Automatically add users from an external authentication source" in Setup > Authentication > Setup, but it will disable autoimport also on login

[orthagh]

I close this issue as it work as intended.
Feel free to re-open and comment

[lexx015]

Hello Alexandre!

Yep, this may happened because we receive email from another helpdesk system. And we do not have user in AD with this email address, only GLPI user.

In our case we have:
new ticket:
(Customer) --email--> (customer's support mailbox) --grabbing email--> (contractor's service desk system) --ticket via email--> (our GLPI)

resolve ticket: (our GLPI) --solution via email --> (customer's support mailbox) --grabbing email--> (contractor's service desk)

So maybe there are some AD user checking on email receiving, i don't know. But searching user from AD takes about 40 second. I think that this is reason.

Also i tried to disable "Automatically add users from an external authentication source". Nothing changed.

I updated users from ad only on testing server because too many users are disabled. But their account should be enabled in GLPI. A bit tricky in our case :)

I'll ask my colleagues to make some research to decrease AD search time.

Anyway, thank you so much!