migrating same version from 2008 to Fedora32

mikaibci

I am having a tough time trying to get this to work. It works now (partially) on the old system, but too many people get either an error loading the page, or are unable to login with the correct username and password that we literally just setup or just reset the password on. The logs show invalid CSRF token, even with cache/cookies cleared and the correct username and password we just set in the system. So with these issues, I figured I would move to a newer Fedora 32 virtual machine.

When I start a fresh setup, the initial start page all loads and displays properly with the same permissions as the imported files, so something is likely broken, and I suspect it is related to the file locations, since the Win server is located at C:\xampp\htdocs\helpdesk and Fedora server is at /var/www/html/helpdesk, but the issue is I do not know what files would be making references to these locations to correct it.

Current/old setup: Server 2008 R2, XAMPP handling the Apache and PHP (due to the old IIS not able to handle the newer requirements of Osticket), Mariadb 5.5 handling the SQL.
osTicket Version v1.14.2 (cba6035)— v1.14.3 is available
Web Server Software Apache/2.4.39 (Win64) OpenSSL/1.1.1b PHP/7.3.4
MySQL Version 5.5.37 (mariadb)
PHP Version 7.3.4

New setup: Fedora 32 in a virtual machine (with plenty of CPU and RAM).
Apache/2.4.46
PHP version: 7.4.9 (unable to go back to older version without compiling from source which I haven't done in years)
SQL Server version: 10.4.13-MariaDB (which is supposed to be backwards compatible with 5.5, unable to go back to older version without compiling from source which I haven't done in years)

I made a full backup of all current files, I made a full export of the SQL database. I setup the httpd.conf and php.ini properly. I have a index.html test file that is working properly from /var/www/html and able to browse and see this test page.

The problem is when I copy over the files in the exact same location, and imported the sql database with no errors, and then correct the permissions for all files, but when I attempt to browse to it, all I get is a blank page. The httpd log file shows error 500.

I cannot go back to PHP 7.3 since Fedora 32 does not offer it anymore, and same with mariadb. Even the Remi-32 repo only has 7.4 and 8.0.

ntozier

500 is an internal server error. So I would guess that that it could be one or more of the following:

a configuration issue in Apache
the wrong ownership or permissions on the files or folders
an .htaccess issue

Did you confirm that the new server was serving / processing PHP before you moved everything over?
You could create a php file (lets say test.php) in the web root and put something like:
<?php phpinfo(); ?> in it and then browse to it.

mikaibci

ntozier 500 is an internal server error. So I would guess that that it could be one or more of the following:
a configuration issue in Apache
the wrong ownership or permissions on the files or folders
an .htaccess issue

Did you confirm that the new server was serving / processing PHP before you moved everything over?
You could create a php file (lets say test.php) in the web root and put something like:
<?php phpinfo(); ?> in it and then browse to it.

There is no .htaccess file.
index.html works fine
index.php works fine and displays php info

If I copy over the fresh install files for osticket, everything loads properly and asks to setup a new site which goes through multiple steps no problem. It is only when I copy the currently working files and correct the permissions to the same as everything else, that it is failing. This is why I suspect there is some file somewhere referencing the old Windows location.

ntozier

Did you clear your browser cache?
Did you update the /include/ost-config.php to point to the new db?
If you are using the same domain/host name did you update DNS to point it to the new server?

mikaibci

ntozier Did you clear your browser cache?
Did you update the /include/ost-config.php to point to the new db?
If you are using the same domain/host name did you update DNS to point it to the new server?

Browser cache cleared, also tried refresh, force refresh, other browsers that had not been attempted yet, a test Chrome setup that I use for testing where it clears all data every time the browser is closed and has no persistence from one session to the next.
The new db is same name, access, login, and location as the previous db.
I am attempting to do this using the temporary server with a different IP (one number off) for now until I get it working. We cannot shut down the current system until I have this running 100%.

ntozier

As a side note running PHP 7.4 might cause some wonkiness and errors and/or warnings in your PHP error logs. It's not officially supported yet... but I have heard of people running it with out much problem.

Since you are using the same SQL server (IP) then you do not need to do the export/import part. As you would just be over writing the existing database. If you exported one day and then went and setup the new one and and then later did the import part you would have lost anything that occurred after the export and before the import. So I hope thats is not the case.

But you would have to make sure that the SQL user has access to the database from the new webserver.

note: some people do a blanket all privileges to the DB from anywhere which really isn't very secure. Not to mention your DB user doesn't really need all privileges.
You could do something like this:
GRANT ALL PRIVILEGES ON database_name.* TO 'username'@*;

For security sake you want to make sure that the second half of that reads: TO 'username'@'IP ADDRESS OF NEW SERVER'. Other wise the user wouldn't have access to the DB from the new server (location).

Isn't Fedora 32 intended to be a desktop OS? (I haven't' used it since it was called Red Hat but that was my understanding from trying to keep up with tech articles etc.) Does it come with any security software (SELinux) when you install Apache things like mod_security, or any other firewall software? If it does then you would need to make sure that it can get to the database server [to connect]. Unfortunately since I haven't used Red Hat in so long I'm not super familiar with what it installs by default. So you will have to do some research if you do not know the answer. Or you could try the empirical research route of trying to disable SELinux and seeing it it magically fixes the connection issue.

Regardless please let us know what you find (if only for my own curiosity and that sake of others trying to use the OS).

ramrajone

Is your rewite mod enabled?

mikaibci

ramrajone AllowOverride None

But even with "AllowOverride All" it is still acting the same way.

I still believe it has something to do with prior server being Windows Server and something is looking for files at the prior location.

Can I do a fresh setup, move over the ost-config and DB, and should it pick it up automatically?

ramrajone

mikaibci
You should be able to do a fresh install and do a backup of the current database and import into new,

When you get a blank page, mostly due to PHP version or not loading the correct version if you have more than one

The file ost-config has your database info, so you need to update to match with your new server

here is the official link to the migration process:
https://docs.osticket.com/en/latest/Getting%20Started/Upgrade%20and%20Migration.html

Here is a post I had written for an upgrade, it's older version, but the process is the same, Ubuntu server:
https://howtohelpdesk.com/how-to-upgrade-osticket-to-1-14-1/

For the PHP version checking at bottom of this post (Ubuntu, may work or find similar command for your flavor of Linux):
https://howtohelpdesk.com/how-to-upgrade-ubuntu-16-04-to-18-04/

mikaibci

Issue is resolved.

The problem was the database password... With the Server 2008 setup it accepted the password that started with a symbol (like #12PsWd34 for example), but despite using the same password on the new setup, mysql on the new setup was showing:

GRANT ALL PRIVILEGES ON . TO user@localhost IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket WITH GRANT OPTION

Instead of the hash, it is showing "invalid". So something in the process, or possibly a linux/newer mysql issue does not allow the password that starts with the symbol (as mentioned above), so I created a new and different login for it, added permissions to the DB, modified the info in the ost-config file, and it is now working properly.