[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] 2.3.13 -> 3.3.14



Depending on the system you are using, you might need to check the file
permissions using:

ls -alZ

If there's a mismatch there, you'll have to talk to your local friendly IT
support people, because SELinux is beyond my powers.

On 11 Oct. 2017 00:55, "Adam Field" <adam at adamfield.net> wrote:

> Check your file permissions:
>
>
>
>                 ls -l /usr/share/eprints3/archives/
> mims3/documents/disk0/00/00/00/01/01/03PA0357.pdf
>
>
>
> Check that the user and group are set to something sane.  You can check
> your apache configuration to see what user / group apache is running as.
> The quick and simple way to do this is to make sure the files are owned by
> eprints, and that apache is running as eprints.
>
>
>
> --
>
> Adam
>
>
>
>
>
> *From: *<eprints-tech-bounces at ecs.soton.ac.uk> on behalf of Mark Muldoon <
> mark.muldoon at manchester.ac.uk>
> *Reply-To: *<eprints-tech at ecs.soton.ac.uk>
> *Date: *Tuesday, 10 October 2017 15:41
> *To: *"eprints-tech at ecs.soton.ac.uk" <eprints-tech at ecs.soton.ac.uk>
> *Subject: *[EP-tech] 2.3.13 -> 3.3.14
>
>
>
> Dear EP-techers,
>
>
>
> I?m upgrading an ancient server to the current version of the software.
> Following advice I found on this list, I?ve been using  the following
> strategy
>
>
>
> Do the export of the 2.x version including archive, user, subjects and
> subscriptions (if possible - there was a patch back in the day for this I
> believe - may or not be worth it now) in ep3xml format. Copy the
> documents/disk0 folder over to the new system (use the same folder location
> or you'll have to munge your XML as the 'eprints' import actually looks for
> the file to exist in the location indicated in the XML) and import into the
> 3.x version of EPrints. Don't kill off your old server until you are done
> as this is a rinse and repeat process until you get everything perfect on
> your new 3.x server.
>
>
>
> This has worked to some extent, though I did, in the end, have to faff
> with the XML to get the rid of a field, <replacedby>, that no longer exists
> and to make the paths point to the correct locations on the new server.
> Unfortunately, the actual files, though present, don?t seem to be entirely
> visible to the server. For example, although I have a PDF whose full path
> is
>
>
>
>             /usr/share/eprints3/archives/mims3/documents/disk0/00/00/
> 00/01/01/03PA0357.pdf
>
>
>
> and an associated eprint that has, in its revisions document 1.xml, a
> <file> with child node
>
>
>
>             <url>http://eprints.maths.manchester.ac.uk/1/1/03PA0357.
> pdf</url>
>
>
>
> the corresponding abstract page lists the PDF as being 0 Mb in size and,
> when I try to retrieve it I get
>
>
>
>             Error in file retrieval: failed to get file contents
>
>
>
> It feels as though I?m within inches of having the import working fully
> and don?t really want to have to study the code to figure out how to fix
> the issue described above. I?d be grateful for any suggestions.
>
>
>
> Thanks,
>
> Mark
>
>
>
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
>
> *** Archive: http://www.eprints.org/tech.php/
>
> *** EPrints community wiki: http://wiki.eprints.org/
>
> *** EPrints developers Forum: http://forum.eprints.org/
>
>
>
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: http://www.eprints.org/tech.php/
> *** EPrints community wiki: http://wiki.eprints.org/
> *** EPrints developers Forum: http://forum.eprints.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20171011/a0237515/attachment.html