Friends,
Based on the conversations in our recent community call, I’d like to raise visitors’ awareness of this section of the forums as a space for those who maintain and support installations to discuss their issues, approaches, and lessons learned. We’re eager to hear about your successful strategies for managing your installations and keeping your systems rolling!
Take care,
Sharon
Dear maintainers,
I manage a small but growing number of Omeka S installations, one per customer, all of them being hosted by the same local provider on individual plans. The configs differ slightly by the set of modules in use but all of them need an image server (IIIF Server + Image Server at the time of writing).
My strategy until today has been to upgrade every component of the system as soon as a new release is available, after a validation phasis on a test environment. With the number of instances growing regularly, this task is becoming exhausting and boring, increasing the risk of quality loss over time.
I am also considering a way to pool the different services provided to my customers, like building a multisite Omeka server, installing a Cantaloupe server that would manage the images and a SolR server for the search. A POC of this architecture is currently a work in progress.
I’d be glad to learn from more experimented maintainers concerning the different ways to keep systems up to date and if the pooling strategy is a relevant approach in relation to potential security issues.
Thanks for reading 
One issue I have encountered is modules may not always be downgradable to an earlier version if the database structure of that module has been changed. This means that time consuming backups have to be made before updating the modules in case it is necessary to go back to an earlier version if problems arise.
Also, some platforms like Wordpress make it easier to perform updates with a simple update button on the backend, whereas in Omeka updating is a very manual process of downloading from the developer and replacing directories the terminal. Introducing a simple update button that does updates automatially would save time and reduce the chance of mistakes.
I totally get the annoying workflow to update modules and themes. A slightly more convenient way is using the CLI tool built by persons from the university of Ghent: GitHub - GhentCDH/Omeka-S-Cli: Omeka-s-CLI: a command line tool to manage Omeka S instances. · GitHub
At least I don’t have to download and upload anymore, but enter two terminal commands. Still not Wordpress flavored convenience though. But good enough to not ignore updates…
Thank you @evansad and @cutterkom for pointing these issues. Did both of you design an upgrade procedure (manual or automated)? What sort of indicators do you consider before deciding to upgrade a module or the entire platform?
I mainly use the Omeka-S-Cli tool to install and maintain Omeka S environments at Ghent University. I deliberately disable updating modules through the web interface. It’s convenient but it’s a security risk I’m not willing to take on production sites.
More generally, updating modules is always a bit of a gamble in Omeka S. Not all of these issues are Omeka’s fault — some come down to individual module developers’ practices — but together they make updates hard to trust. The main issues I run into:
Beyond module management, my biggest recurring headache is synchronizing configuration between a dev environment and production. Right now this has to be done entirely by hand. There are tools that let you export/import parts of the setting and site_setting tables, but these don’t cover the full scope of a site’s configuration.
Thank you @flamsens, your words capture perfectly the difficulties I am facing and your suggestions provide relevant ways to improve Omeka’s upgrading process 
In general, I want to address the issue of two factor authentification.
I am aware of the TwoFactorAuth module, but I prefer an SSO implementation based on OIDC (Open ID Connect). I deploy Omeka S with Cloudron. With Cloudron I can manage roles and users from a centralised point and force everyone to use MFA. At least theoretically…
I know of this module GitHub - Systemik-Solutions/OmekaS-OIDC · GitHub, but it produces a 500 server error after install. Also, it’s not in the Omeka module catalogue.
I would prefer that MFA as such a basic IT security measure to be part of Omeka S - or at least to be developed by the Omeka core team.
This brings me to Daniel Berthereau . He does so much excellent work. Nearly every module I install is built be him. So I am wondering: How does Digital Scholar manage the Bus factor - Wikipedia? The risk that Daniel for whatever reasons stops maintaining modules?
Hi, this is the question I asked the Omeka team during the last community call this summer:
Nearly 25% of Omeka S modules have the same author (Daniel-KM, an awesome dev and a really kind person), many of them being very popular and having become “systemic” components in numerous installations worldwide. How do the Omeka team manage this situation when planning future developments?
Sharon and John’s answer start at 46:34 in this video.
Thanks @cutterkom for the question, and @boregar for pointing to the segment from the last community call on managing the balance between core features and modules.
We really appreciate @Daniel_KM’s work and realize how important it is to the ways that so many projects deploy Omeka S. I hate the “bus” framing, so let’s go with something more positive like winning the lottery, or even retiring, should Daniel have reason to step away from maintaining his work 
Thankfully, we operate as an open source community, and all of the modules are licensed in a way that the community can, if need be, take on responsibility for forking and updating that code. With so many users, a good number of whom are skilled developers or work with individuals who are, I would hope that we would take on that challenge together.
The Omeka Team is a small one. We have three full-time developers, and two UI/UX designers, who are currently responsible for maintaining just over 200 repositories of code. (The rest of the team works on testing, support, documentation, and training.) So, we have to be careful about what we take on since that becomes a long term responsibility. As @jflatnes explained in the video segment, sometimes we incorporate features that make sense to include as part of the core software; other times we do our best to make it easy for module developers to create and maintain their work.
One example of our approach to this question arose with the shifting status of the Neatline packages for Omeka Classic (and the in-development elements for Omeka S). When the Scholar’s Lab stepped away from maintaining those popular plugins, we assessed their features and have working to incorporate as many of them as make sense into the Geolocation plugin for Classic (keep your eyes out for a new release coming soon) and the Mapping module for S. Of course this work must proceed along side our other responsibilities so it has taken some time, but our hope is that it is enabling end users to continue to do much of the work that they would have originally executed with Neatline.
Finally, we really encourage all of our module developers to register their work in our add-ons directory, so we can collectively understand the scope of what features are available to work with. If users have favorite modules that are not in the add-ons directory, please encourage their creators to add them!