When creating a Openshift gear for a GNU Social deployment I found that the files could not be uploaded. I needed
to create writable folder for the webserver to place the files. Openshift allows you to update the code via a git repository, but I did not want to
upload the files directly into the git repository on the server, because that would introduce problems everytime I updated the code. Openshift
also offers a separate dir for user data files and preferably the files are stored there. After some tinkering I found a solution.
There are some specific notes for Windows users at the end of the post.
The GNU social package has two folders which it uses for storing uploaded files /avatar and /file. I will be explaining how to perform this for
both folders, but you can execute this for any type of package you’d like, not only GNU social. The principle is the same.
The solution involves two separate steps: preparation and scripting. Some of the paths in the explanation start with /var/lib/openshift/[your app id]/, in this
case you need to replace the value [your app id] with the identifier of your app. You can find the value, if you don’t know it, by executing the following
command when signed into the console on the server:
echo $OPENSHIFT_DATA_DIR
Preparation
Make sure that the folder(s) you want to make world-writable for the uploads are not in version control (if they are, you might run into problems because then you are
basically updating version controlled folders when running the scripts. There is probably a way around that, but I tried to stay away from such a solution).
First, ssh into your server and execute the commands below, this will create the upload folders in the data part where the files can be uploaded:
mkdir $OPENSHIFT_DATA_DIR/avatar
mkdir $OPENSHIFT_DATA_DIR/file
Second, create the links into the repository and make them world-writable. The ln command does not really support environment variables, this is why
we are using the absolute paths here.
ln -s /var/lib/openshift/[your app id]/app-root/data/avatar /var/lib/openshift/[your app id]/app-root/runtime/repo/avatar
ln -s /var/lib/openshift/[your app id]/app-root/data/file /var/lib/openshift/[your app id]/app-root/runtime/repo/file
chmod -R o+rw $OPENSHIFT_REPO_DIR/avatar
chmod -R o+rw $OPENSHIFT_REPO_DIR/file
This completes the manual preparation.
Scripts
When performing a code update via git push we need to temporarily remove the link and recreate it again. Openshift offers the possibility to have scripts
executed in the different steps of deploying the code. In the folder in your local cloned git repository there is a folder .openshift/action_hooks. Two
files must be created here, pre_build and post_deploy. For more background information read the manual.
On Linux, execute chmod x .openshift/action_hooks/* to make the scripts executable. For Windows, see the special note at the end of the post.
pre_build
Remove the links:
#!/bin/bash
rm -f $OPENSHIFT_REPO_DIR/avatar
rm -f $OPENSHIFT_REPO_DIR/file
post_deploy
Re-create the links and make sure that they are world-writable:
#!/bin/bash
ln -s /var/lib/openshift/[your app id]/app-root/data/avatar /var/lib/openshift/[your app id]/app-root/runtime/repo/avatar
ln -s /var/lib/openshift/[your app id]/app-root/data/file /var/lib/openshift/[your app id]/app-root/runtime/repo/file
chmod -R o+rw $OPENSHIFT_REPO_DIR/avatar
chmod -R o+rw $OPENSHIFT_REPO_DIR/file
Notes for Windows
The scripts in the repository need to have the correct line endings and have the execution bit set. The manual
explains how to do this for Windows. In short execute in the root of your local clone of the git repository after creating the build hooks:
git config core.autocrlf input # use `true` on Windows
git config core.safecrlf true
git update-index --chmod=+x .openshift/action_hooks/pre_build
git update-index --chmod=+x .openshift/action_hooks/post_deploy
Message error: .openshift/action_hooks/*: does not exist and —remove not passed
.openshift/action_hooks/*: does not exist and --remove not passed
I got this message when attempting to execute the update-index command on a wildcard. When providing the individual filenames it worked.