osTicket 1.10.1 / Apache 2.4 / php7.0-fpm

esajokinen

I'm having problems getting my osTicket to work using PHP7-fpm.

I had an old osTicket 1.9.8 installation on Debian6/PHP5.4, and used intermediate Debian8/PHP5.6 to perform an upgrade for 1.10 in order to gain PHP7 support. The updated version 1.10.1 works fine on that intermediate PHP 5.6 FPM server.

I copied both files and SQL database on the new server. At least all the AJAX queries aren't working and I get strange PHP and SQL errors.

Environment:

osTicket Version	v1.10.1 (9ae093d) —  Up to date
Web Server Software	Apache/2.4.25 (Debian)
MySQL Version	10.1.26
PHP Version	7.0.19-1

and every PHP extension and settings check under this shows checkbox for OK.

However, 

• all the AJAX tooltips & tools are empty.
• every ticket gives error when trying to write reply/comment:
  Unable to lock the ticket.
  Someone else could be working on the same ticket.
• Apache error.log shows this kind of messages:
  [Wed Dec 13 17:56:33.343052 2017] [proxy_fcgi:error] [pid 18088:tid 139734630242048] [client XXXXX] AH01071: Got error 'PHP message: PHP Warning:  Declaration of AssignmentForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /home/srotiketti/public_html/include/class.forms.php on line 4367\nPHP message: PHP Warning:  Declaration of TransferForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /home/<user>/public_html/include/class.forms.php on line 4487\n'

The php7.0-fpm is using exactly the same kind of proxy_fcgi setup, only the location of the unix socket is different:

• ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/var/run/php5-fpm-user.sock|fcgi://localhost/home/user/public_html
  
• ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php/user.sock|fcgi://localhost/home/user/public_html
  

KevinTheJedi

At this time osTicket does not fully support PHP 7...it's coming though. In the meantime, I would recommend using PHP 5.6 as we fully support this and it worked for you before. If you don't want to (or can't) downgrade PHP, you'll have to look into each error individually and go from there. It seems for the "Unable to lock the ticket." messages your timezone isn't correct on either the server, PHP, or MySQL. For the Tooltips that's AJAX, you need to configure Apache to handle the AJAX requests correctly. For the "Should be compatible" error you need to look at this pull request: https://github.com/osTicket/osTicket/pull/3349

I would make every change in that pull request except for the following, as it is not approved and don't know what it could break:

I hope this helps. Cheers.

esajokinen

SOLVED:

• PHP version: It seems easier to use osTicket with PHP 5.6 a little longer. It's possible to have both 5.6 and 7.0 fpm-pools on Debian 9 using the repository from deb.sury.org. That stops error in apache2/error.log.
  

UNSOLVED:

• Tickets shows the "Unable to lock" message. TimeZones:
  
• System: Current default time zone: 'Europe/Helsinki'
• MySQL @@global.time_zone=SYSTEM; @@session.time_zone = system;
• osTicket settings: Default Time Zone: 'Europe/Helsinki'
  
• PHP date_default_timezone_get(); = Europe/Helsinki
  
• Dasboard > Information also Shows Europe/Helsinki
• On the intermediate server these don't match and it's doesn't seem a problem.
• AJAX not working on the Debian 9 server, although it has the very same ProxyPassMatch to call for php-fpm, and it's working on the Debian 8 server:
  
  ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php/osticket.sock|fcgi://localhost/home/osticket/public_html
  
  

esajokinen

Ok, all the problems seems definitely to be caused by the AJAX URL:s, as the ticket lock also uses them.:

"POST /scp/ajax.php/lock/ticket/4709 HTTP/1.1" 400 511

They are all giving error "URL not supported". I can't figure out how it keeps on working on the intermediate Debian 8 server with the same configuration, even when it's also giving this "URL not supported" error. However, if someone has a working Apache configuration to get these AJAX urls working, it would be much appreciated.

esajokinen

Ok, the problem is not with the support for these .php/something urls in general: I made /test.php and I'm still completely able to use /test.php/something/something and it runs /test.php. 

However:

• the /scp/ajax.php/tickets/4724/preview is giving me "URL not supported" 
  
• non-existing /scp/foo.php gives "file not found" on /scp/foo.php/tickets/4724/preview
  
• on the intermediate server I get the "URL not supported" when I give /scp/ajax.php/something
  

I added to the ajax.php some debug lines:

echo "<pre>";

var_dump($_SERVER, $ost->get_path_info());

print $dispatcher->resolve($ost->get_path_info());

echo "</pre>";

And I see a difference in two parameters...

On the working configuration:

  ["SCRIPT_NAME"]=>

  string(13) "/scp/ajax.php"

  ["ORIG_SCRIPT_NAME"]=>

  string(34) "/scp/ajax.php/tickets/4724/preview"

  ["PATH_INFO"]=>

  string(21) "/tickets/4724/preview"

  ["ORIG_SCRIPT_FILENAME"]=>

  string(62) "/home/osticket/public_html/scp/ajax.php/tickets/4724/preview"

  ["PATH_TRANSLATED"]=>

  string(49) "/home/osticket/public_html/tickets/4724/preview"

While on the server having problems:

  ["SCRIPT_NAME"]=>

  string(34) "/scp/ajax.php/tickets/4724/preview"

  ["ORIG_SCRIPT_FILENAME"]=>

  string(62) "/home/osticket/public_html/scp/ajax.php/tickets/4724/preview"

  ["PATH_TRANSLATED"]=>

  string(28) "/home/osticket/public_html"

Now, what could be causing this?

esajokinen

Ok. The error itseld clearly comes from ../include/class.dispatcher.php line 41, proving the path is working.

    function resolve($url, $args=null) {

        if ($this->file) { $this->lazy_load(); }

        # Support HTTP method emulation with the _method GET argument

        if (isset($_GET['_method'])) {

            $_SERVER['REQUEST_METHOD'] = strtoupper($_GET['_method']);

            unset($_GET['_method']);

        }

        foreach ($this->urls as $matcher) {

            if ($matcher->matches($url)) {

                return $matcher->dispatch($url, $args);

            }

        }

        Http::response(400, __("URL not supported"));

    }

And it's certainly related to the lack of PATH_INFO and the incorrect PATH_TRANSLATED as the matcher is parsing these variables to determine the location.

However, the php.ini has cgi.fix_pathinfo=1 and it's also forced separately for the fpm-pool, (and the value 0 causes more problems):

php_admin_value[cgi.fix_pathinfo] = 1

esajokinen

FINALLY SOLVED THIS

The lack of PATH_INFO was caused by how the mod_proxy_fcgi was used.

I used examples from mod_proxy_fcgi documentation. I replaced

ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php/user.sock|fcgi://localhost/home/user/public_html

with

        <FilesMatch "\.php$">

                # Note: The only part that varies is /run/php/username.sock

                SetHandler  "proxy:unix:/run/php/user.sock|fcgi://localhost"

        </FilesMatch>

        <Proxy "fcgi://localhost/" enablereuse=on max=10>

        </Proxy>

Now everything is working as supposed.

Good luck in getting the full PHP 7.0 support ready!