Thursday, December 27, 2012

GLPI -- Awesome IT Ticketing (if you speak french)

Despite Chrome's admittedly fantastic automatic translations for other languages, software written in other language is still tough to grasp.

Let me restart -- GLPI is an open-source ticketing tool created for IT Ticketing. And it's not bad. There's tons of customizations you can make, and (of course) - the code is published and available, so you can break down how pages are displayed and how data is processed.

Some issues I've seen:

1. Time-stamps on the platform OS is correct, but php/apache's time is wrong.

GLPI used to have an interface where you could update the time and time-zone of php's embedded time-keeping mechanism. I haven't been able to find it. To fix this issue, I searched and found a post by Nokia390  here:
Open the php.ini configuration file
   vi /etc/php5/php.ini
Update the following line. Note: You can find all supported syntax for time-zones here.
   date.timezone = Europe/Lisbon
Restart the apache service to reload the php.ini file
   service httpd restart

2. GLPI receivers just will NOT pull email from email inbox

Our Exchange version: 2010
There are some pre-reqs for our Exchange version - 2010.
* You need to start either the IMAP4 or POP3 service on Exchange. These are the only supported way to pull email from an inbox.
* Verify the user inbox you're utilizing allows email to be pulled with your chosen protocol -- we made sure IMAP4 was enabled (the default on our system)

Reading through the GLPI wiki, you'd think setting up an email scrape would be really easy. And it was... once I found my way around the completely undocumented problem I hit.

Here are our example values:
Name (email address): help@(ourdomain).com
Server: (IP of our email server)
Connection Options: IMAP // (BLANK) // TLS // NO-VALIDATE-CERT
Login: help
password: (password for our help user).

I played for hours with different configurations, looked over the (very, very thin) logs, set up different receive connectors with different options, recreated the user account, etc. In short, I drove myself crazy.

Here are the logs I saw:

12-27-2012 23:14
Warning(2): imap_open(): Couldn't open stream {(server IP)/ssl}INBOX
Backtrace :
/var/www/html/glpi/inc/mailcollector.class.php:833 imap_open()
/var/www/html/glpi/inc/mailcollector.class.php:403 MailCollector->connect()
/var/www/html/glpi/front/mailcollector.form.php:72 MailCollector->collect()

The final, tiny, gotcha? I needed to use the FQDN ahead of the user name. For example,
I used this: help
I should have used this:\help

After that update, it immediately synced. *sigh*.
Hope it helps all of you!


  1. Is that your full config? No port? No Email Domain? Can you post a screenshot?

    1. Sorry SkyTech, I have changed jobs and don't have access to the full config anymore. If the config item exists, update it. If it doesn't exist, add it.

    2. Hi,

      I've been having the same problem ..

      Have you been able to resolve yours ? If so, can you post a screenshot of your receiver config ?
      Have you configured anything else on the Exchange Server ?

    3. Aqui resolvemos da seguinte maneira:
      Estas são as minhas configurações no Receiver com uma conta do Office 365, ele funciona dessa maneira
      Opções de conexão: IMAP | SSL | NO-TLS | NO-VALIDATE-CERT
      Pasta de Correio de Entrada
      : Porta da Caixa de Entrada : 993

    4. Hey Portuguese Anon,

      Office 365 may not support SSL - try variations of TLS with and without SSL.

      Also look to see if is correct for IMAP. I think it is or for server.

      Good luck!

  2. Out of the blue but if anyone else is looking for this on a self hosted Exchange 2016 (2019 is likely the same) it's: IMAP // SSL // NO-TLS // NO-VALIDATE-CERT | and then your user is: <-- that worked for me!