Notifications Of New Tickets Being Created & Closure Of Tickets

SenseiOfSong · 2024-02-13 23:58:33

I have installed GLPI on CentOS 8 and the GUI is working.
I am able to get emails when a new ticket is created, but only if I force the notifications on this page by selecting "Execute".
https://MYIPADDRESS:10005/front/crontask.form.php

I found a guide online that said to write a cron in /etc/crontab to have root execute cron.php every 1 minutes so that as soon as a new ticket is created you get the notification. But it never worked.
I selected Run Mode from GLPI to CLI like it stated as well. Still did not work.
I have searched this forum to see if anyone else has the same exact challenge. I am certain that this is correctable, just not figured it out yet.

This was an evaluation to see if this system would do exactly what I am describing and was worth paying for. And so far it is not allowing me to do what I intended to use it for. :-(

I also wanted to change the Subject in the emails that GLPI sends out, and have not found in the webpage-GUI where to do that (if that is even possible).

If I was able to do these two things, then I would move on to branding placing a different icon in the system.

If anyone can help me with the email auto-notification thing that would be great. Thanks!

Eon8D · 2024-02-14 10:35:46

glpi-user-documentation.readthedocs.io/fr/latest/modules/configuration/notifications/index.html
Should get you started.

SenseiOfSong · 2024-02-17 00:22:05

Appreciate the reply.

I have studied the link/guide you shared with me. I am still struggling to get the email messages to automatically trigger either every 1 minute or at every 5 minutes in either GLPI or CLI mode, with or without a cron-job that runs either at every 1 or every 5 minutes.

With queuednotification set to both GLPI and CLI mode, and restarting cron service both have failed to email.

nano /etc/crontab

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
#
# THIS LINE IS MEANT TO RUN THE FILE CRON.PHP EVERY 5 MINUTES.
# ACCORDING TO THIS URL htps : //forum.glpi-project.org/viewtopic.php?id=282396
# RUNNING THIS JOB EVERY 5 MINUTES WILL ALLOW NOTIFICATION OF A NEWLY CREATED TICKET TO
# GO TO THE EMAIL DISTRIBUTION LIST
#
*/5 * * * * root /var/www/html/glpi/front/cron.php>dev/null

Again, any perspective would be be appreciated. If we cannot get the system to do this important task, then it will not be much use to me.
Thanks in advance for any help or advice.

cconard96 · 2024-02-17 01:34:51

Don't run anything related to GLPI as root. It will break file permissions, particularly on the cache and log files under the " files" folder. Your cron should be configured to run as www-data or whatever user your web server uses. For simplicity, remove the cron entry from the system's crontab and add it to www-data's. Then, you don't need to specify the user.
crontb -u www-data -e

You should check the file permissions for your GLPI folder and subfolders are still correct.

SenseiOfSong · 2024-02-17 21:03:14

@cconard96
Btw...
OS: CentOS 8
Thanks. I have commented out my line in /etc/crontab and restarted the cron service while I try your appreciated suggestion.

Btw, I did check /var/www/html/glpi and /var/www/html/glpi/front/*
All directories and file appear to be owned by the user:group "apache:apache".
Here is the specific permission structures on our target file "/var/www/html/glpi/front/cron.php".
-rw-r--r--. 1 apache apache 3139 Feb 1 03:13 cron.php

Attempting to run you command: crontb -u www-data -e
....to see the outcome. I will post back here with results.

One question. IN the GLP- web-GUI under the queuenotifcations page, should I leave it as CLI and not GLPI?
I can't upload a screenshot apparently. Sorry.

cconard96 · 2024-02-17 22:22:42

CLI = Triggered by external scheduler like Cron or Window Task Scheduler.
GLPI = Triggered occasionally by GLPI page requests (it occasionally adds an invisible image in pages with the source set to the cron.php script to trigger the actions without blocking the page itself).

https://glpi-user-documentation.readthe … tasks.html

SenseiOfSong · 2024-02-18 03:39:08

I left it as CLI in the GLPI GUI.
Since the idea is to have a cron job force /var/www/html/gpli/front/cron.php to run every 60 seconds to ensure that any new tickets that get created sends an email to my ticket email distribution alerting to the fact there is a new ticket created.
I do not have a user php.I ran the job as user apache since that is the user that is both individual and group for the entire directory (apache:apache).
Like this:
nano /etc/crontab
--------------------------------
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
1 * * * * apache /var/www/html/glpi/front/cron.php &>/dev/null

--------------------------------------------------------------------------------------------

I am re-reading the link you sent: https : // glpi-user-documentation.readthedocs.io/fr/latest/modules/configuration/crontasks.html
I glanced at it in there seeing something about forcing mail.
Currently we are getting mail but only when I hit Execute on the page in the GUI for queuenotifications.https : // myipaddress:10005/front/crontask.form.php?id=22

Appreciate the help cconrad86. We really want to this work, so we can use it as a professional ticket system and then show justification for going with a support plan.

SenseiOfSong · 2024-02-18 03:57:09

I also read in another forum for folks that were having trouble getting cron-jobs to run on CentOS7/8 that you might have to call it like this:
*/1 * * * * apache /usr/bin/php /var/www/html/glpi/front/cron.php

Telling cron:
*All 1 minutes
*Run it as user apache
*Call the PHP executable
*Call the file-path.

the last thing that forum states is to reboot the server. This is not something I would think to do since this is CentOS 8 and not Windows. But I will try that as well. I will report back.

SenseiOfSong · 2024-02-18 18:23:22

So under the Automatic Actions: https://myipaddress:10005/front/crontask.form.php?id=22
I now see the Last Run and Next Run updating, but still no emails when a new test ticket is created.
Currently the /etc/crontab looks like this. Ever 1 minutes, run as user apached who owns the files, calling PHP, then pointing at the file.
*/1 * * * * apache /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/null

---------------------------------------------------------------------------------------

I also made the cron.php executable because I thought maybe that was an issue.
ls -al /var/www/html/glpi/front/cron.php
-rwxr-xr-x. 1 apache apache 3139 Feb 1 03:13 /var/www/html/glpi/front/cron.php

I thought about make it chmod 777 to eliminate any possibility that was an issue, at least for testing. But I have not tried that yet.

I have restarted crond.service and rebooted the VM.
I closed all previous tickets and created a new one. Still no notification via email.
Should I try to add the "--force mailgate" command at the end of the line in my crontab? Like this:
*/1 * * * * apache /usr/bin/php /var/www/html/glpi/front/cron.php --force mailgate &>/dev/null

Or, are there any other things I can try?

SenseiOfSong · 2024-02-20 04:52:58

OS: CentOS8 (el8)

I see under journalctl that both cron jobs are capable of running but still no email notification of a new ticket in the queue.

I have checked permissions to find the following are in place.
/var is owned by root:root
/var/www is owned by root:root
/var/www/html is owned by root:root
/var/www/html/glpi is owned by apache:apache
/var/www/html/glpi/front is owned by apache:apache
/var/www/html/glpi/front/*.* files are owned by apache:apache

I have restarted cron each time any change has been made to cron
systemctl restartcrond.service

Verified that other programs are capable of sending email off-system, like logwatch since there is a line in the /etc/crontab that executes nightly and send email.
1 1 * * * root logwatch --detail 10 --output mail --format html --mailto emailuser@company.com

Have even disabled selinux to ensure it is not getting in the way using the "setenforce 0" command.

I was about to run Wireshark and capture any packets leaving the Linux system, then filter for any packets leaving the IP address to see if any email ever leaves the system and then look in the captured packets to see if the payload was from GLPI.

I do not think that the GLPI system is ever initiating the email. I have spent about a week on this.

I am going to recommend that we not use the GLPI system for tickets since it does not seem to notify us when a new one is created.

cconard96 · 2024-02-20 13:08:32

Did you check the Logs tab for the queuednotification action? Does it look like it is being triggered on schedule?
What is the "Maximum number of automatic actions (run by CLI)" options under Setup > General > System tab set to? By default it is 5. If you have a lot of actions enabled that need triggered often, you may simply have this value too low.

Maybe not related, but you can also use the status checker script to check the health of your GLPI including checking if any Automatic Actions are "stuck" meaning they were started but didn't report finished within 2 hours or 2x their configured run frequency.
From the CLI:
bin/console glpi:system:status --private

With "private" information showing, it should show which actions are stuck so you can go to the correct form and reset them.

SenseiOfSong · 2024-02-20 19:46:40

I appreciate the help cconard96. I just have to move on to another project where I can make traction.

Still, I followed you instructions and post the output below:

URL: https : // 10.132.240.4:10005/front/crontask.form.php?id=22
The Logs Tab under QueuedNotifications, shows many entries 60 seconds apart:
2024-02-20 11:24 0.031 seconds    0 Action completed, no processing required
2024-02-20 11:23 0.028 seconds    0 Action completed, no processing required
2024-02-20 11:22 0.027 seconds    0 Action completed, no processing required
2024-02-20 11:21 0.030 seconds    0 Action completed, no processing required

Automatic Action under QueuedNotifications was set to 100. I increased it to 9999 to make hopefully make certain this could not be a choke-point.

I have run the command: bin/console glpi:system:status --private
[root@blarnelbtv003 bin]# pwd
/var/www/html/glpi/bin

[root@blarnelbtv003 bin]# ls -al
total 8
drwxr-xr-x. 2 apache apache 21 Feb 1 03:13 .
drwxr-xr-x. 24 apache apache 4096 Feb 1 03:16 ..
-rwxr-xr-x. 1 apache apache 3762 Feb 1 03:13 console

[root@blarnelbtv003 bin]# console glpi:system:status
console: gethostbyname(console): host lookup error

Not certain if this means something is missing or it just has nothing to report.

Again, appreciate your willingness to help. I just really have to place this on the back-burner, and report the troubles in testing.
Maybe it is REALLY clear what needs to happen, and it is right under my nose, and I am just missing it.
But the result is the same...currently, it's not working and we are not getting the email that alerts something like, "hey, you have a new ticket that requires some action".
I am more used to using systems like CA-Software's system Service Desk circa 2007/2015, where even SNMP traps like "LOS + Automatic Power Shutdown + Loss of Optical Service Channel" = a Fiberoptic Cable Cut (1 + 1 + 1 = 3/alert) and then the system then talks to a Ticketing system like Service Desk to create a Critical Ticket so that 24/7 humans in a NOC can then dispatch field crews to a specific network span. What we are trying to do is so much more simple here, just making it so anyone can request help on something that needs to be mocked up in a very small lab (rather than what we have today...email-requests with no data that is not manully prepared - aka: Excel).

Forum GLPI-Project

Announcement

#1 2024-02-13 23:58:33

Notifications Of New Tickets Being Created & Closure Of Tickets

#2 2024-02-14 10:35:46

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#3 2024-02-17 00:22:05

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#4 2024-02-17 01:34:51

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#5 2024-02-17 21:03:14

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#6 2024-02-17 22:22:42

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#7 2024-02-18 03:39:08

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#8 2024-02-18 03:57:09

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#9 2024-02-18 18:23:22

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#10 2024-02-20 04:52:58

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#11 2024-02-20 13:08:32

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

#12 2024-02-20 19:46:40

Re: Notifications Of New Tickets Being Created & Closure Of Tickets

Board footer