Cannot Get Checking of Pop Email to Work

krisdotca

Hi There. I have a brand new installation of osTicket. Everything is working beautifully except for the checking of email through pop. I tried the instructions on http://osticket.com/forums/showthread.php?t=3158(http://osticket.com/forums/showthread.php?t=3158) but still no luck.

Not sure if it's right, but my cron line is now:

wget -q -O /dev/null --user-agent=527C27522FE311B195E2F83F47FADB8A http://localhost/support/api/cron.php(http://localhost/support/api/cron.php)

And it's set to run every minute.

I was seeing error 77 messages on the dashboard. Those are gone now but the email is still not being pulled.

Any assistance would be greatly appreciated.

Cheers, Kris

krisdotca

To add a little more information:

Checking of e-mail is working as long as someone is logged into the osTicket interface.

Also, I inadvertently deleted the "siri!" entry from Setting-->API and can't seem to get it back. Posted a separate thread for that at: http://osticket.com/forums/showthread.php?t=4985(http://osticket.com/forums/showthread.php?t=4985)

Cheers, Kris

krisdotca

Out of Ideas

Ok, I tried everything I could find in the forums and Google but I still can't get automatic e-mail checking through pop to work.

Pretty sure my pop setting are correct because it works when "Enable cron call on staff's activity" is enabled.

I followed the instructions on http://osticket.com/forums/showthread.php?t=3308(http://osticket.com/forums/showthread.php?t=3308) and generated a key for 127.0.0.1 and entered that key in the wget call. The wget call is now:

wget -q -O /dev/null --user-agent=C9D2089675324498ACADB734A0EB2903 http://localhost/support/api/cron.php(http://localhost/support/api/cron.php)

I also tried setting the permissions on cron.php to 777 to see if that would work but still no dice.

If anyone out there has any suggestions for me, I'd really appreciate it.

Kelli

There's no need to access cron.php with wget. You should be able to run it from the command line, if the CLI is configured correctly. In your case, it sounds like it is not. The command line interpreter and the web interpreter often have different PHP.ini files. Check the CLI error logs, and you'll likely find the source of the problem is some ini setting that is different.

That said, what you have looks like it should work. Try logging messages to a file instead of running quietly, and outputting to a file instead of /dev/null and see if you get any errors.

Edit: Depending on how your server is set up, you may need to add an API key for : instead of 127.0.0.1

krisdotca

Thank you for the reply Kelli.

Where would I find the CLI logs?

I did try piping the output to a file but no messages appeared in the file. The cron line I used to do this was:

wget --user-agent=C9D2089675324498ACADB734A0EB2903 http://localhost/support/api/cron.php(http://localhost/support/api/cron.php) > cron_log

How do I add an API key for :? When I try to enter that, I get an error saying "Valid IP Required"

Cheers, Kris

Kelli

You may have to manually edit it in the database to add :...

Actually, the location of the log file depends largely on the settings in the ini file we're trying to set (bit circular there). See if there's an entry for it in /var/log or if it's in /var/syslog

From the command line, you can find the ini file by running 'locate php.ini' and looking for the one specific to the CLI. For me, it's /etc/php5/cli/php.ini

krisdotca

Finally got it working. What I needed to do was:

(a) Generate a new API key for the IP address of my website - not localhost as a number of the posts that I read indicated. I determined the IP address by pinging the main domain.

Note: As a side note, the IP for my website was also the one that was being referred to in the error message I was seeing on the dashboard: "Unknown remote host or invalid API key "

(b) Modify the cron to refer to my website url rather than localhost.

wget --user-agent= http:///support/api/cron.php

For (b) I left out a few of the parameters for wget (like -q -O /dev/null) that I had read about in other posts but it doesn't seem to have had any negative effect.