Config Omeka-S with Nginx


#1

Is there anyone here using Nginx with Omeka-S?

I am working on a new install with Omeka-S and the systems group says they’re switching everything over to Nginx. However, I’ve only managed to get the main site to load and install. The Admin page says “file not found” I’m not sure how to troubleshoot this in Nginx.


#2

The big problem with using nginx will be that it won’t use the .htaccess rules we ship with Omeka S.

The basic rules to just get things working on Nginx you could take from Zend’s skeleton application, just pointing at the index.php of the Omeka S installation. Keep in mind though, that the normal htaccess does some additional and important things that the basic nginx rules given there won’t account for (like blocking access to .ini files and .php files).


#3

Cool. I’ll try to use this to get the to make an exception for me in our Omeka instances.
I have always used Apache, and that’s what I’m used to…and Omeka works out of the box instantly with Apache.


#4

On nginx, I use (improvable):

# Deny all dot files, except for Let‘s Encrypt.
location ~ /\.(?!well-known).* {
    return 403;
}
# Block access to all .ini and .sh files.
location ~* \.(ini|sh)$ {
    return 403;
}
# Serve any file that exists as raw file, else use root index.php.
location / {
    try_files $uri $uri/ /index.php$is_args$args;
}

#5

Awesome! This worked for me. Thanks a bunch!


#6

I’m wondering, would it make sense to move index.php to a /public directory in future versions and then point nginx or apache to use this as the root directory? This would prevent unauthorized access to the config and other files.


#7

There are a couple of problems with using the “public” pattern:

First, you can’t “drop in” and install the way you currently can with Omeka, as the benefits of that system only work if you’re controlling where the DocumentRoot is (speaking in Apache terms).

Second, we need more than just index.php to be served, in particular static assets must also be served. For the core we could move the assets directory under that same public/ tree, but modules have their own static assets: there would have to be a system were that stuff is copied under public/ when installing or updating a module. A similar situation applies for themes.

I’m not opposed to the idea on principle but it does raise some issues.


#8

Sorry to jump on an old thread, but looking to do something similar and found this recipe on nginx.com although I think its for classic version, it might help.

https://www.nginx.com/resources/wiki/start/topics/recipes/omeka/