search

teltek / Galicaster

The Galicaster Project is an open initiative to provide flexible, state-of-the-art solutions for recording educational multimedia contents like lectures and conferences
galicaster.teltek.es
Other
35 stars 31 forks source link

Galicaster does not work properly when run from a directory where the user has no write permissions #127

Closed sinhote closed 9 years ago

sinhote commented 9 years ago

There may be other side effects, but this is the one I observed:

I wrote an init script for Galicaster, so that I can run it as a service. It runs Galicaster with the proper, configured user by using su (but I have tried using sudo and the result is the same).

At first, we saw that the process Galicaster had the right permissions and worked apparently without issues, but then we observed that ingests failed immediately. After a little bit of investigation we realized that Galicaster does not switch the current working directory when it runs, so if the user that runs Galicaster has no write permission in the directory from which the program was called, then the zip file cannot be written. Since the init script is always run as root, the CWD is either /root or / (when it's run automatically on startup, for instance), where the user "galicaster" has no write permissions.

The worst part is that not only does the .zip generation fail, but Galicaster still tries to ingest an empty zip file, resulting in an exception in the ingest service in Matt... uhm, Opencast.

A workaround for that is using the flag "-l" with su or "-i" with sudo, which tries to replicate the same environment as one can find after logging in. This makes sure that the CWD is changed to the "galicaster" user's home.

Not a very noticeable issue, but since most of the paths relevant to Galicaster are absolute (or relative to the user running Galicaster), I believe that Galicaster should not be sensitive to the directory from which it is run.

smarquard commented 9 years ago

I would perhaps describe this differently as "Galicaster creates the zip file for ingest in the current working directory rather than in a specific location".

There are other problems that this could cause, e.g. if the current working directory or galicaster home is on a filesystem with not much space.

So the fix for this should be to write the zip file in a known location (e.g. the same place where the mediapackage is located) rather than in the CWD, as that will avoid other possible problems.

bleedinge commented 9 years ago

Related to #15.

It will be fixed for the next release.

sinhote commented 9 years ago

I agree with Steve. I was just mentioning my workaround, but indeed the operations should run in a fixed directory.

I see that this task is perhaps a duplicate of #15. Sorry for not checking the current issues first.

hcaloto commented 9 years ago

Thanks for the report, fixed in commit d345d4981bced44e4820ed3fda5c7808512a92bd