Fixing the cPanel SoftException writable by group

If you’ve been following these posts, we now have a lovely git push to deploy setup, and can ssh into our server without constantly needing to enter our password through the use of ssh keys.

However, if you’re running on cPanel, you will probably have bumped into this error:

SoftException in Application.cpp:256: File "/home/username/public_html/index.php" is writeable by group

This is clearly a permissions error, and so the obvious thought is to chmod it. However, we don’t want to ssh in and chmod every time we push! On the testing server, the permissions are fine, but they are different once the git push has done its post-update.

The reason for this is something to do with a thing called umask. Umask is a user mask which is created for processes that are performing tasks, and affects new files and folders.

The solution to this is to edit ~/.bash_profile, and insert the following command:

umask 022

From now on you shouldn’t have the problem. With newly created files.

To sort already existing files, Chmod -R 755 any folders affected, OR just log out and in, and git pull or git reset –hard HEAD^ in order to re-fetch the files. This time they should be created without any strange permission errors!

 

Setup SSH keys for login without password

Sick of being asked for your password? Set up SSH authorised keys and forget about it!

you@localmachine:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/a/.ssh/id_rsa): 
Created directory '/home/you/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/you/.ssh/id_rsa.
Your public key has been saved in /home/you/.ssh/id_rsa.pub.
The key fingerprint is:
3e:4f:05:79:3a:9f:96:7c:3b:ad:e9:58:37:bc:37:e4
you@localmachine

you@localmachine:~> chmod -R go-rwx ~/.ssh

Now copy the contents of /home/you/.ssh/id_rsa.pub, and SSH in for the last time with your password to your remote machine:

you@localmachine:~> ssh user@remote.com
Password:
Last login: Tue Jan 28 14:14:51 2014 from 83.86.250.39
CentOS release 6.3 (Final)

user@remote.com:~> cd .ssh
user@remote.com:.ssh> nano authorized_keys

Paste in the contents you copied from your public key file. Make sure it is all on ONE LINE. Save and exit.

user@remote.com:.ssh> cd ..
user@remote.com:~> chmod -R go-rwx ~/.ssh
user@remote.com:.ssh> exit
you@localmachine:.ssh> ssh user@remote.com
Last login: Tue Jan 28 15:28:51 2014 from 83.86.250.39
CentOS release 6.3 (Final)

Awesome!

Fixing Git Submodule Issues

If you’ve set up a Git ‘Push to Deploy’ setup for your site based on my earlier post, you may or may not have run into some anomalous behaviour! Namely, when you run git submodule init, you get a message similar to this:

No submodule mapping found in .gitmodules for path 'js/jquery-browser-fingerprint'

Or even :

fatal: reference is not a tree: 48d1407779fb1e8dc6d3c6c6fb87df4c1cbc65ed
Unable to checkout '48d1407779fb1e8dc6d3c6c6fb87df4c1cbc65ed' in submodule path 'cms/js/flipswitch'

Thankfully, these issues are easily fixed. modules should be listed in a file in your root .gitmodules, and look like this:

[submodule "jquery-browser-fingerprint"]
 path = /js/jquery-browser-fingerprint
 url = git://github.com/carlo/jquery-browser-fingerprint.git

Listing your submodules in here will fix your first problem. The second issue is caused by referencing a commit that hasn’t been pushed! Did you copy project files from somewhere else? Try pushing the commit from your other project.

A clearer way to sort these issues however, is to clear whatever cache git has for those submodules. Typing this clears it.

git rm --cached js/jquery-browser-fingerprint

This should allow you to run git submodule init, and git submodule update. One last point. You don’t remember ever having to create this .gitmodules file before, so why now? Basically it allows you to set custom folders etc for the submodule. If you’re happy with the defaults, you should theoretically be able to skip the submodules file, and  can combine both git commands into this:

git submodule update --init

This updates everything and initialises in one! So to sum up, try removing the cached stuff in git, then run the combined update init file! Happy pushing, pulling, and deploying!