[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EP-tech] Re: Temporarily Disabling Deposits/Edits during migration/upgrade.
Both are very good answers, and yes the access table will continue to grow. We'll have to determine if the access table growth will be a concern as obviously it will affect our IRstats install.
From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of John Salter
Sent: Thursday, September 03, 2015 2:23 PM
To: eprints-tech at ecs.soton.ac.uk
Subject: [EP-tech] Re: Temporarily Disabling Deposits/Edits during migration/upgrade.
In the past I've been advised to alter the user_login method to return 0 (so no one can log in), and then to remove the login tickets (so current sessions aren't valid).
This approach obviously depends on what login methods you've got configured for your repository.
Also worth noting that the access table will continue to grow even if people can't do stuff...
From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> <eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk>> on behalf of Brian D. Gregg <bdgregg at pitt.edu<mailto:bdgregg at pitt.edu>>
Sent: 03 September 2015 17:27
To: 'eprints-tech at ecs.soton.ac.uk'
Subject: [EP-tech] Temporarily Disabling Deposits/Edits during migration/upgrade.
Sorry if this may be repeat question to the list but I'm not finding what I believe I'm looking for in the archives.
We will be migrating our EPrints system from one system to another and performing and upgrade in the process. We'd like to keep the initial system up while we do so. However, we want to disable any additional deposits/changes to the system while the migration is happening but want to keep the system up for viewing, searching, etc. Due to the amount of content and the upgrade we'll also be doing this will take at a minimum of 4 hours. My initial thought is to comment out the permissions in the user_roles.pl file that apply and restart the web server to "lockout" any user updates. If this approach is used what is minimum permissions needed to allow basic use/functionality by the user? Is it just "general"?
Is this the correct approach or is there something simpler that we can do to achieve the same functionality?
Or would it be highly recommended to block the whole site while the migration is happening?
Brian D. Gregg
Solutions Architect | Manager Systems Development
University of Pittsburgh | University Library System
Address: 7500 Thomas Blvd. Room 129 Pittsburgh, PA 15208<https://maps.google.com/maps?q=7500+Thomas+Blvd,+Pittsburgh,+PA&hl=en&sll=41.117935,-77.604698&sspn=7.662465,13.73291&oq=7500+Tho&t=h&hnear=7500+Thomas+Blvd,+Pittsburgh,+Pennsylvania+15208&z=17>
Tel: (412) 648-3264 | Email: bdgregg at pitt.edu<mailto:bdgregg at pitt.edu> | Fax: (412) 648-3585
-------------- next part --------------
An HTML attachment was scrubbed...