Problems Migrating OJS 2.4.8.0 from Windows Server to Linux Server

Software Support
1

We have performed a test migration of OJS but we are having some problems. Our production build was set up by staff no longer present, and we are rather new to OJS administration. For a more detailed look at the situation described below, please see my blog post at the link below (includes screenshots)

http://www.donniehardin.com/donnieIO/?p=687

###############################################

The UNCG university libraries hosts and instance of OJS 2.4.8.0 accessible at libjournal.uncg.edu.
It hosts 14 individual journals, each with numerous editors and contributors.

At the time of its implementation, the university libraries did not have the infrastructure to host the application on a Linux-based technology stack.
Instead, it is hosted on a Microsoft Windows Server 2012 virtual server.

Goal:

Now that the university libraries has a vibrant open source infrastructure in place, we have decided that we would like to move our existing instance of OJS from the Windows server to a RHEL 7 linux server.

Rough Project Plan:

– Create and configure a RHEL7 virtual server including the apache web server

– Install and configure the technology stack comparable to that which is present on the production instance (php5, mysql/mariadb, etc.
(
– Fresh installation of OJS 2.4.8.0 on the RHEL7 server
fun
– Copy and Export database dump from production OJS server to RHEL7-OJS build.

– Copy and Export files/uploads folder to RHEL7-OJS build.

– Copy and Export public folder (images, etc) into RHEL7 OJS.

– Validate all features as functional on RHEL7-OJS (with respect to production)

– Ask a volunteer group of end users to validate features and functionality on RHEL7-OJS (with respect to production)

– Upon signoff, designate OJS production freeze date, proceed to next phase of implementation.

####################################################################################################################################################################################################################

Steps Completed So Far:

Create and configure RHEL7 virtual server including apache web server.

  • Worked with VMware admin to create virtual RHEL7 server. Installed OS, created users.
  • Subscribed system to Red Hat Satellite Server
  • Installed php 5
  • Installed mariadb, created db user for OJS
  • Installed apache web server
  • Ran base OJS configuration
  • Imported Uploads folder from production
  • Imported public folder from production
  • Imported database from production

Results of initial setup:

Looks nearly identical minus a few style differences
Opened the Communication Center journal on both systems. All looking well functionally.

  • Did notice differences in URL format ( libjournal-dev includes “index.php” )

  • PROBLEM: Attempted to view the PDF of Vol 5 on each. PDF does not display on libjournal-dev

Same goes for journals with HTML entries. Attempted to open Vol 3 of Archival Practice Journal. Does not display on libjournal-dev

  • Suspected that Rewrite Rules need to be implemented in order to remove the “index.php” from the URL and complete the paths to the location of the HTML and PDF content

  • Set pathing in /var/www/html/ojs/config.inc.php

  • Set rewrite rule in /var/www/html/ojs/.htaccess

  • Restarted system

  • Attempted to open journal upon restart

  • Now no page displays at all

#################################################

Any advice would be most appreciated. Perhaps we are going about this all wrong and it is not practical to “copy and paste” an OJS database into a new instance and expect functionality? Maybe there are some plugins or further configurations we are not considering?

2

Hi @dchardin,

The rewrite rules have probably broken your installation – try stepping back the .htaccess changes you added to see if you return to the previous state. Your Apache/PHP error logs may be of help.

The problem with submission files is probably not related to the index.php part of the URL – double-check that your config.inc.php specifies the right files_dir where the PDFs are located, and that file permissions on that directory permit PHP to access files there.

Regards,
Alec Smecher
Public Knowledge Project Team

3

Hi Alec, Thanks for your reply back in August. I am just now getting back around to follow up troubleshooting.

I have put your suggestions into action. However we are still unable to determine why we are unable to view the PDF’s.

(you can see more detail at my updated blog post at UNCG University Libraries OJS migration – Donnie_IO )

Here is what happened:

  • Commented out entries in /var/www/html/ojs/.htaccess

  • Commented out the pathing in /var/www/html/ojs/config.inc.php and set restful rules to "Off"

Restarted System

RESULT: We are back to square one at least.
Journal page is viewable again, yet initial problem still remains: PDF's do not display on libdigital-dev.uncg.edu

Checking entry in config.inc.php specifying path for files_dir, looks correct.

Checking Permissions of files_dir concerning /opt/ojsfiles The /opt directory itself is owned by root. Readable by nongroup members but not writeable. This should be fine.

The /opt/ojsfiles directory is owned by the apache user/group. Readable and writeable by the apache user and readable by members of the apache group. This looks ok to me as well.

The subdirectories within /opt/ojsfiles are also owned by the apache user/group. Looks fine.

Checked httpd error logs at /var/log/httpd/error_log. Not very helpful since its mostly flooded with errors relateded to a time / date problem (I'll need to look into fixing that as well sometime.)

####################################################

Further help is greatly needed. We are getting far behind on this project. I can’t tell if I am overlooking something or not.

4

Hi @dchardin,

To double-check your file permissions, you could try writing a quick test script using any OJS file. For example, if you have a file in /opt/ojsfiles/journals/1/articles/20/submission/20-7-38-1-2-20201015.docx, create a file called e.g. test.php in your OJS installation directory with the following contents:

<?php

echo is_readable('/opt/ojsfiles/journals/1/articles/20/submission/20-7-38-1-2-20201015.docx') ?
    'Success' : 'Failure';

Try invoking this via the web browser – you might get misleading results if you call it from the command line.

Regards,
Alec Smecher
Public Knowledge Project Team

5

Hi Alec,

The test you suggested helped us to make some headway.

(you can see more detail at my updated blog post at UNCG University Libraries OJS migration – Donnie_IO )

Here is what happened:

Actions Taken

  • Decided to perform test on Vol 5, number 1 article in Communication Center Journal.
  • The path for that article is /opt/ojsfiles/uploads/journals/26/articles/1945/public/1945-8724-1-PB.pdf

RESULT

  • Page pulls up with text “Success”, thus there does not seem to be a permissions issue.

NEW OBSERVATION

  • While performing the recommended test, I noticed something in the example path that PKP mentioned in their last message:

(you could try writing a quick test script using any OJS file. For example, if you have a file in /opt/ojsfiles/journals/1/articles/20/submission/20-7-38-1-2-20201015.docx, create a file called…)

  • I noticed that their path does not include an “uploads” directory, whereas mine does: /opt/ojsfiles/uploads/journals/26/articles
  • This could mean that my directory structure for my uploaded files may be misconfigured.

Actions Taken

  • Navigated into my /opt/ojsfiles directory
  • deleted the scheduledTaskLogs directory and the usageStats directory
  • moved all contents and subcontents out of the uploads directory and into the ojsfiles directory
  • deleted the now-empty uploads directory
  • restarted apache
  • opened browser and navigated back to the article page in the Communication Center Journal

Result

  • pdf still does not display in the pdf window BUT!!! the pdf is now downloadable when clicking on the “download this pdf file” button!

Next Steps

  • This is certainly an improvement, but we still need to figure out why the pdf will not display in the embedded pdf window

  • I checked the network traffic using chrome devtools but I’m not seeing much of anything that is giving me clues. I could be overlooking though.

Any advice?

6

Hi @dchardin,

OJS 2.4.8 is pretty much obsolete and the method we used to use to embed PDFs in HTML views has changed (we now use the PDF.js viewer). I’d recommend prioritizing an upgrade to OJS 3.x before you invest too much more time into fixing up an old OJS 2.x installation.

I believe there’s a PDF.js viewer plugin in OJS 2.x – enabling this might help for now.

Regards,
Alec Smecher
Public Knowledge Project Team

7

Hi All,

We have decided that our current method of migration

(copying entire DB and all journal files, etc; from OJS2/Windows → OJS2/linux then running autoupdate to OJS3/linux , etc)

…is probably more trouble than it’s worth. We have decided to set up a clean OJS3 instance on a linux server. We will then work with journal owners and move each journal and content via a manual process. This way, journal owners can validate all of the new functionality and visual elements through the process.