Test FileSideload

[jimsafley]

@mebrett

This module adds the ability to add media files that are already on your server to items. You'll need to add a directory anywhere on your server and make that directory owned by the web server, something like:

$ cd /path/to/omeka-s/modules/FileSideload
$ mkdir files
$ sudo chown www-data files

Copy some files to that directory and install and configure the module. After your save the directory path, add a "Sideload" media to an item. This should save a media file as normal and delete the original file.

[mebrett]

To clarify: does the folder which will contain the media files need to be located within the File Sideload modules' folder, or could it be on the same file level as the installation of Omeka S?

[jimsafley]

You should be able to put the directory anywhere on the server, including outside the Omeka installation.

[mebrett]

I'll test both ways, just to be thorough.

[mebrett]

Running into problems setting the filepath.

1. how should the path be formatted in this instance (relative to the location of the Omeka S installation? To the module's folder?
2. I don't have sudo permissions on the dev server, so can't make that change.

[jimsafley]

1. The path should be absolute, from server root. For example:

/path/to/omeka-s/modules/FileSideload/files

or

/path/to/other/directory/sideload-files

I'll make that clear in the form.

1. You'll have to ask Roberto to make a directory somewhere and change it's owner to the web server. You also may need his help to copy files into that directory.

[zerocrates]

The thing where loadable files need to be owned by the server user is going to be a big problem, I think.

We should possibly just alter the core storage stuff to copy instead of move the files, which should remove any need to have any particular ownership of them, and would probably let us stop chmod-ing them as well.

Creating the directory will still involve either some higher-level access, being in the same group as the server user, or willingness to make an open-permissions directory, but that's a big difference from needing sudo to add any files ever.

[jimsafley]

By copying we leave the original files in place, which isn't such a big deal for the /tmp directory but does present a complication in this module. I suppose it's a choice between a) having sudo to add files to the directory and b) depending on FileSideload users to remove their files from the directory by hand.

[zerocrates]

We absolutely wouldn't want to leave files in /tmp either. We'd, in the normal upload/download case, delete the file from /tmp after we're done with it.

For sideload, we could do the same and copy then delete, which would still remove the need to own the file (you can delete a file by just having write and execute privs on the parent directory). I actually also think that having the possibility to configure the module to just leave the files there could be interesting, as it would allow users to use the module even without the ability to create even a server-writable directory.

[jimsafley]

What is the difference between a rename() and a copy() then unlink()? I'm not understanding the direction you're describing that we should go here.

[zerocrates]

Renaming means that the files maintain their original ownership, group and mode. A copy means you get a new file with the default permissions and that's automatically owned by the user that made the copy. Meaning: we wouldn't need to chmod within the FileStore (and if we did have to, we'd own the copy anyway), so we wouldn't need to care about whether we own the source file (as the Sideload module currently checks for because we need to own the file to chmod it).

[mebrett]

What are the intended use cases of this plugin? I mean, if we're imagining exclusive use by institutional installations of Omeka S, where the IT person setting things up can make changes, it might be feasible, but in any instance (like a Reclaim or Dreamhost user, or even some institutional servers) the people setting up these S installations may not have sudo permissions.

[jimsafley]

I recognize your concern and am working to fix it.

[sheilabrennan]

Thanks, Jim.

[jimsafley]

@mebrett Ok, checkout omeka-s develop branch and pull any new changes. Then, in this module, pull from master and reinstall. There's a new configuration there that lets you choose whether you want to delete a file in the sideload directory after its been sideloaded. The default is "No" (unchecked) which means the permission checks are much more lenient. Try it out.

[mebrett]

I've been able to attach image, text, sound, and video files from two different directories (one inside the module and one outside the S install). Delete works when checked and does not affect files when not checked. I even added the same file twice before clicking the "delete" option, and it didn't bork once.

[mebrett]

As far as I can tell, this works. Do we want someone else to poke at it or shall we close the issue?