EPrints Technical Mailing List Archive

Message: #04645

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Re: Temporarily Disabling Deposits/Edits during migration/upgrade.

Peter, John,

 

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.

 

Thanks again.

 

-Brian.

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of John Salter
Sent: Thursday, September 03, 2015 2:23 PM
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Re: Temporarily Disabling Deposits/Edits during migration/upgrade.

 

Hi Brian,

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...

 

Cheers,

John

 

From: eprints-tech-bounces@ecs.soton.ac.uk <eprints-tech-bounces@ecs.soton.ac.uk> on behalf of Brian D. Gregg <bdgregg@pitt.edu>
Sent: 03 September 2015 17:27
To: 'eprints-tech@ecs.soton.ac.uk'
Subject: [EP-tech] Temporarily Disabling Deposits/Edits during migration/upgrade.

 

All,

 

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?

 

Thoughts, experiences?

 

Thanks,

Brian.

 

Brian D. Gregg

Solutions Architect | Manager Systems Development

University of Pittsburgh | University Library System

Address: 7500 Thomas Blvd.  Room 129 Pittsburgh, PA 15208

Tel: (412) 648-3264 | Email: bdgregg@pitt.edu | Fax: (412) 648-3585