To get Nesta to be served from Apache with Passenger.

Summary

About a couple months ago, I came across Nesta which is really awesome and really simple CMS built off the Sinatra framework. But I could not figure out how to host the application with Apache. Fast forward to this evening and I finally found a solution. If you have any suggestions on how it could be done different, please post a comment as I would like to hear about it.

Build

So! you want to build it. Ok, here are the steps I did:

1. Install RVM and Ruby (I ended up with the single user install as you will notice)
2. curl -L get.rvm.io | bash -s stable
3. rvm requirements
4. (install necessary stuff to compile ruby and gems)
5. rvm install 1.9.2
6. rvm use –default 1.9.2
7. Install Nesta
8. gem install nesta
9. Create your site home and site itself
10. mkdir /apps
11. cd /apps
12. nesta new mysite
13. (take note that all additional steps use “/apps/mysite” as the nesta directory)
14. Install Passenger
15. gem install passenger
16. passenger-install-apache2-module
17. Apache config
18. mkdir /etc/httpd/sites-available /etc/httpd/sites-enabled /etc/httpd/mods-available /etc/httpd/mods-enabled
19. Create the file /etc/httpd/mods-available/passenger.conf (see git gist below)
20. Create the file /etc/httpd/sites-available/mysite (see git gist below)
21. cd /etc/httpd/sites-enabled
22. ln -s ../sites-available/mysite mysite
23. cd /etc/httpd/mods-enabled
24. ln -s ../mods-available/passenger.conf passenger.conf
25. turn on NameVirtualHosts feature
26. sudo /etc/init.d/httpd restart
27. goto your new site!

Source: FrugalDad.com

Starting the RedMine console (WARNING! Be careful!)

To start the RedMine console, change directories to your application base:

cd /usr/share/redmine-1.2

Now run the following command to get into the console:

RAILS_ENV=production ./script/console

This will get you into the Production side of your environment. If you want to use development area:

RAILS_ENV=development ./script/console

Running some queries:

Find all issues by their description only:

Issue.find(:all, :conditions => "description LIKE '%your_pattern%'")

Find all issues by their description only limited by project id:

Issue.find(:all, :conditions => "description LIKE '%your_pattern%' AND project_id = '5'")

Find spent hours by looking for a custom value in a issue:

hours = []
CustomValue.find(:all, :conditions => "custom_field_id = 35 AND value LIKE '%your_pattern%'").each do |c|
hours << Issue.find(c.customized_id).spent_hours
end

Find all issues that a specific user has commented on:

user_2 = []
Project.find(5).issues.each do |issue|
issue.journals.each do |journal|
if journal.user_id == 2
user_id << issue.id
end
end

Find list of users who contributed to an issue for a specific project:

results = Hash.new
Project.find(5).issues.find(:all).each do |issue|
people = []
issue.journals.each do |j|
people << user
end
results["#{issue}"] = people unless people.empty?
end

y results

• ruby-1.9.2-p318
• passenger-3.0.11
• rails 3.2.2
• Apache 2.2

In short, the following steps are necessary:

1. Install RVM with the multi user instructions
2. Check requirements

   rvm requirements

3. Install ruby 1.9.2

   rvm install 1.9.2

4. Install passenger

   gem install passenger

5. Load passenger into apache with passenger.conf
6. Add a new user called ‘cap-deploy’
7. Create a dir of /webapps and owned by the user and group of the apache process
8. Create a dir of /webapps/yourrailsapp and the user and group of cap-deploy with perms of 775 (might be able to get away with less perms)
9. Cap your rails application on your dev environment
10. Add your rails app to a version management (I went with github) that is accessible by your hosting server
11. Configure your version management to ignore the following files gitignore
12. Add the following to your Cap file: Capfile
13. Configure your /config/deploy.rb file with db support so that version control system does not share our db config: deploy.rb
14. Run the cap and have fun!
15. cap deploy:setup
16. do first push
17. cap deploy:cold
18. do updates
19. cap deploy

While working on my Ubuntu server with the Gitosis default setup, I ran into some problems along the way when trying to commit some changes:

1. Lost ability to update the gitosis-admin repository
2. Various python errors
3. Expected changes to gitosis.conf file but they were not being applied

Below is a description of what I did to trace down the error(s) and try to fix them.

Gitosis debug

Setting the debug into the gitosis.conf file really helped me out. To achieve this, you must have the following in your gitosis.conf file:

[gitosis]
loglevel = DEBUG

After this has been setup, you can run your push command to get a better idea of what is going wrong. Some of the problems I got are listed below with a explanation of what I did to try and resolve the issue:

gitosis.conf not updated after a push

This was a mystery. I cloned off the files from the gitosis-admin repo and then made some changes to the gitosis.conf file. Then after pushing them to the origin master, I noticed my changes did not take effect when looking at the file:

cat /srv/gitosis/.gitosis.conf

I noticed that there is a hook file in the directory of

/srv/gitosis/repositories/gitosis-admin.git/hooks/

with the filename of:

/usr/share/pyshared/gitosis/templates/admin/hooks/post-update

(Small note here, take note of the directory of where this file is because the part of /usr/share/pyshared is what you need for setting your PYTHONPATH) Running the above script occurs after applying a push to the gitosis-admin repository. I figured this was where the hold up was. After running this script manually, I got more errors (which I don’t have any more) and here is what you need to do to run this script:

sudo su
su gitosis
export set GIT_DIR="/srv/gitosis/repositories/gitosis-admin.git"
export set PYTHONPATH="/usr/share/pyshared"
/usr/share/pyshared/gitosis/templates/admin/hooks/post-update

That is, goto root account with sudo. Change users to gitosis. Set some variables (GIT_DIR, and PYTHONPATH). Then run script. This might give you more insight of to why the gitosis.conf file is not being updated.

Lost access to gitosis.conf file

This happened to me. Any commit I made to the gitosis-admin repo resulted in a permissions denied. So I logged on to my server, changed directories over to /srv/gitosis and edited the

.gitosis.conf

file and all was okay.

PERMISSION problems

Most of the time this was because the files in /srv/gitosis were not group writeable by the group of ‘gitosis’, or my account did not belong to the group ‘gitosis’, or that the ssh configuration file did not allow my account to login via ssh.

conclusion

Most of the time gitosis worked great. But sometimes, it did not work out. I hope this document will save me in the future as well as others. A really nice resource for gitosis can be found at http://ao2.it/wiki/How_to_setup_a_GIT_server_with_gitosis_and_gitweb

Cheers,

Aaron

readlink

which prints the full path of the file that the link is point at. So I came up with some bash shell code to do the job:

 Bash Script checking permissions

for f in `cat /etc/shells`
do
	#echo "checking $f"
	if [ -e $f ]; then

	if [ -L $f ]; then
		f=`readlink -f $f`
		results=`stat -c "%a" $f`
	else
		results=`stat -c "%a" $f`
	fi

	if [[ "$results" -le "755"  ]]; then
		echo "--- passed => $results - $f"
	else
		echo "-X- Failed => $results - $f"
	fi

	else
	echo "missing"
	fi
done

Explanation of bash script checking permissions

For all the text lines returned from “cat /etc/shells”, process a loop while setting each line from the text file /etc/shells as a variable of “f”. The first if statement checks to see if the file exists. The second if statement checks if the file in “f” is a link and if so, reassign the variable “f” to the returned value from running “readlink -f $f” then process the file with stat to get the octal value of permissions. If the file is not a link, try to process the file with stat to get the octal value. The next if statement checks to see the file in $f is less than or equal to 755. If the octal value is less than or equal to 755, a line will be printed indicating the file has passed the test. If the octal value is more than 755, a line will be printed indicating the file has not passed the test.

Here is a sample output from one of my servers:

--- passed => 755 - /bin/bash
--- passed => 755 - /bin/bash
--- passed => 755 - /sbin/nologin
--- passed => 755 - /bin/ash
--- passed => 755 - /bin/ash
--- passed => 755 - /bin/ksh
--- passed => 755 - /bin/ksh
--- passed => 755 - /bin/ksh
--- passed => 755 - /bin/tcsh
--- passed => 755 - /bin/tcsh
--- passed => 755 - /bin/zsh

Redmine-due-date-offset