OJS 2.4.8.5
Just migrated this installation to a new server and one of the 8 journals now have its home page points to the current issue page. How do I point it back to the journal landing page?
Note: I checked setup and had a situation where everything after 5.2 was missing. So I deleted the cover image above it and the rest of the 5.x setup page loaded. This may or may not be related.
Thank you!
I have tracked this down to the logo file that is being stored for the Journal Thumbnail If we add an image file, the balance of the page goes away.
Is this a permissions problem? Where do these get written to? Are Journal logo and Journal thumbnail stored in the same place or different? Thanks!
If the page only partially renders, this almost certainly points to a PHP error which stopped delivering the HTML template part way through. Check your PHP error log for additional details.
Both the Journal Logo and the Journal Thumbnail will be uploaded to the public files directory, under a directory “journals”, then under the id number of the journal. For example:
ojs/public/journals/1/journalThumbnail_en_US.png
or
ojs/public/journals/5/homeHeaderImage_es_ES.png
Thanks. It looks like the folders were not writeable even though the install/upgrade page reported they were writeable. This brings me to the permissions issues. I have read every post on permissions and there is not one complete treatise on the subject and this is critical to the proper running and security of the system.
We need to determine permissions and ownership and access for the user access, the system access and the webuser access.
This is complicated by the installation type, eg share hosting, VPS or dedicated server install.
So, is there some document that covers this in total? As I asked Alec several years ago, is there a tool we can run against and check permissions and paths?
THANK YOU!
radjr
The big concern here is that it seems that when the page only partially renders, any movement off the page gets committed to the database. In this case, all the URLS on the links lower in the 5.x setup page were overwritten with blank data. No, I did not click save OR cancel! Scary!
there is not one complete treatise on the subject and this is critical to the proper running and security of the system.
Have you looked at my treatise here?
This seems very odd. You are accessing the Setup, Step 5, correct? Is this access coming from a GET link (where the previous page is just pointing a link to this one), or a POST request (for example, completing the submission of Step 4)?
Yes sir. Excellent. Some of the issues that were unclear to me are:
You note: “Your webserver should have read-only access to all other files and directories distributed in the package.” What is that webserver user? On VPS/Shared environments with control panels, the control panel user owns the folders where OJS is running. You reference myuser:www-data but that is not a user on many of these system. Does Apache run under the root user? There is a level of abstraction that is not clear here. How do you determine which users exists and who is running apache, the local user, web users, etc.
From a system architecture standpoint you want OJS data files outside the public_html (web facing) folders so that data is protected. That said, who should have rights to that folder? The user for that hosting account? A web user (and how is that different from the hosting user?) Root? So how do you set those so that you can ensure the OJS program can read/write that but webusers cannot?
Then we have the issue surrounding uploads and walling off that folder…where ever it is so that bad files can’t get shoved onto the server and/or executed in any means. It seems that wants to be write but not read and not execute? But who has access to that folder? Only OJS?
Thanks for helping clarify this!!
Is this problem compounded by tools like the crossref tool that wants write access to its folder?
What is that webserver user? On VPS/Shared environments with control panels, the control panel user owns the folders where OJS is running. You reference myuser:www-data but that is not a user on many of these system. Does Apache run under the root user? There is a level of abstraction that is not clear here. How do you determine which users exists and who is running apache, the local user, web users, etc.
In a dedicated environment, your web process is typically spawned by the root user, but then runs as a daemon user. For example, in RHEL environments, this will be the user “apache”; in Debian environments, it will be the user “nobody”. Files written by (and writable to the webserver) will typically be owned by “apache:apache” or “nobody:nobody”. In a shared VPS environment, with the webserver “running as setuid”, the user will probably be the control panel user, e.g.: “user1234:user1234”. In each case, the user probably has a group dedicated to the user, with the same name, hence the duplication after the colon in the ownership. The best way to identify the user and group is to check an existing file you know was written by the webserver, or by asking your system administrator or hosting provider.
From a system architecture standpoint you want OJS data files outside the public_html (web facing) folders so that data is protected. That said, who should have rights to that folder? The user for that hosting account? A web user (and how is that different from the hosting user?) Root? So how do you set those so that you can ensure the OJS program can read/write that but webusers cannot?
The webserver user should have read and write permissions to the OJS data files (files_dir). What you want to prevent is direct access to this files via a URL. The distinction is that the webserver can read and write the files outside of the webroot, but because the files are outside of the webroot, no one can directly access them.
Then we have the issue surrounding uploads and walling off that folder…where ever it is so that bad files can’t get shoved onto the server and/or executed in any means. It seems that wants to be write but not read and not execute? But who has access to that folder? Only OJS.
You could leave the files in the webroot and be technically secure if you prevent the webserver from executing the files. This is complicated and you really need to know what your are doing in this case, because “execution” can take many forms, beyond just PHP execution. Files left within the webroot, but not executable, would also be exposed publicly on the internet, which means that people could access your submissions, published or unpublished, if they knew the right URL. This is another reason that placing OJS data files in webroot is not recommended.
Is this problem compounded by tools like the crossref tool that wants write access to its folder?
Processes like Usage Statistics and CrossRef should also run as your webserver user. This will happen automatically if you use the acron plugin. If you setup a cron job, be sure to setup the cron job under the same user which runs the webserver process.
Excellent. So last followups. When setting permissions into the database, who should be the permissions in the statement below? Which username?
GRANT ALL PRIVILEGES ON database_name.* TO ‘username’@‘localhost’;
And does the “setuid” directive in the config.inc.php override all other settings for user:group for your responses and in the GRANT above?
Thanks!! This is great!
The database username is independent of the operating system users. The database username will be whatever user is created within your database management system, with full control of the OJS database. This user and password is then specified in the config.inc.php.
I’m not familiar with a setuid directive in config.inc.php. The setuid configuration of your webserver will happen at the system level. This is extremely common in shared server environments, and you will have no control over it; it is less common in dedicated server environments, but if you have root access to the server, you can configure it within the webserver configuration.
So this will be identical to what is detailed below from the config.inc.php which is also what is on the setup screen. Correct?
;;;;;;;;;;;;;;;;;;;;;
; Database Settings ;
;;;;;;;;;;;;;;;;;;;;;
[database]
driver = mysqli
host = localhost
username = username
password = 12345678
name = ojs
Yes, this section of config.inc.php, which is filled out in the setup screen, references the database user and password, which unrelated to your operating system user which runs the webserver.
From your comment above" This seems very odd. You are accessing the Setup, Step 5, correct? Is this access coming from a GET link (where the previous page is just pointing a link to this one), or a POST request (for example, completing the submission of Step 4)?"
Yes, this is very odd. It seems that the read of the graphics file is failing and the code below is not loaded. Any move off the page writes the data to the database which is very scary. The only way we could get around this was to delete the image file that was listed but that was not displayed. Then the full page loaded on screen. VERY SCARY as this would write to the database blank data for all settings below the image selections boxes. We detected it because all the menu items vanished. When I went to look at the setup page under 5.x, they were gone!
Can you share the PHP errors from your error log which are associated with this page load?
Also, what steps do you take to get to the point where the page fails? Please share in detail, like:
Unfortunately, errors where not being logged for some reason (Still undetermined).
Step 1-4 where executed above. On entering that 5.2 config page, “journal logo” pointed to a file…actually the same logo as “journal title image”. The journal title image displayed, the journal logo did not and nothing else below that browse box was visible on the screen! Cancelling the page, wrote data to the database. When we came back to that page, deleted the journal logo image, they balance of the page displayed. All the menu items and details below were gone or defaulted.
Hope that helps.
If you have SQL access to your database, we can determine exactly when this database write is actually happening. Unless you have modified code, it is unlikely to be possible during the page display.
The following SQL will display the settings in the database that are part of Setup, Step 5:
SELECT *
FROM journal_settings
WHERE setting_name IN ('additionalHomeContent', 'authorInformation', 'description', 'displayCurrentIssue', 'homeHeaderLogoImageAltText', 'homeHeaderTitle', 'homeHeaderTitleImageAltText', 'homeHeaderTitleType', 'homepageImageAltText', 'itemsPerPage', 'journalPageFooter', 'journalPageHeader', 'journalTheme', 'journalThumbnailAltText', 'librarianInformation', 'navItems', 'numPageLinks', 'pageHeaderLogoImageAltText', 'pageHeaderTitle', 'pageHeaderTitleImageAltText', 'pageHeaderTitleType', 'readerInformation')
AND journal_id = ?
The ? will need to be replaced by your journal’s numeric identifier (find this in the journals table by the path). If you only have a single journal install, it will probably be 1.
Run this SQL at before clicking on “5 The Look”, and then again when you get the failed page load. Returning to the page after deleting the image, run the SQL again.
Based on unmodified code, the most likely scenario is that the load of the page after deleting the image is somehow being interpreted as a form locale resubmission, without localized input, and thus the page loads nothing from the database. The existing content is likely present in the database, but not displayed on the page, forcing you to reenter it.