git archive -o ~/Desktop/project.zip HEAD

That will extract your most recent stuff in your current branch, zip it up, and drop it on your desktop. We do a lot of WordPress plugin development and with this single command we can get our plugin code ready for installation extremely quickly. Here is more information about git archive.

1) Set up an account where you want to host your subversion repositories, perhaps use a domain like subversion.mywebsite.com

2) SSH into your new account and create a directory that will contain all your subversion repositories. For example, you might have a path like /home/<username>/subversion where <username> is the username you used to log into your account.

3) Set up a subversion repository by changing directories into your subversion directory you just created and issuing the following commands.

cd /home/username/subversion
svnadmin create myproject
sudo chgrp -R nobody myproject
sudo chmod -R g+w myproject

Note that we changed the group to “nobody” which is the user that apache runs as. You need to do this so that when you access the repository through apache, apache has permission to write files to your repository. By default, cPanel runs apache with the user “nobody” but not always. So, just be sure that you set the correct group name for your repository.

4) Next you need to tell apache about your new subversion repository. To do that, log into your cPanel WHM account and go to Service Configuration -> Apache Configuration -> Include Editor and edit the Pre VirtualHost Include file. Enter in a block like this:

<Location /path/to/repository>
DAV svn
SVNPath /absolute/path/to/repository
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /absolute/path/to/password/file.txt
Require valid-user
</Location>

The first path in the block above is /path/to/repository in the Location tag. This is the path you want to use when accessing the repository through Apache.  For example, if you wanted to access your repository at http://subversion.mywebsite.com/myproject then you would simply write /myproject as the path in the Location tag.

The second path is the SVNPath which is the absolute path to your subversion repository. So in our example you would use /home/username/subversion/myproject

The third path is the absolute path to you htpasswd file. We haven’t created this yet but we will in the next step. You may choose to put this file in any directory you wish perhaps at /home/username/svnpasswords.txt This is the file that will contain the usernames and passwords for accessing your Subversion repository through Apache.

When you are all finished click the button to restart Apache.

5) Now we need to create the htpasswd file. Change directories into the directory where you want to store your password file and issue this command:

htpasswd -c svnpasswords.txt

If you want more than one user, run the same command again but leave off the -c. If you don’t leave off the -c then a new password file will be created and all your previous entries will be lost.

6) Finally, you will want to create the normal trunk, tags, and branches folders in your repository. You can issue these commands from your development machine if you like since you are now able to access your repository through apache.

svn mkdir http://subversion.mywebsite.com/myproject/trunk -m “creating trunk”
svn mkdir http://subversion.mywebsite.com/myproject/tags -m “creating tags”
svn mkdir http://subversion.mywebsite.com/myproject/branches -m “creating branches”

Now you have your repository all set up and ready to receive your source code. So, normally speaking you would checkout out your trunk, add some files, and commit your initial set of files to the repository.

tar -czf archive.tgz dirName

We are running Apache 2.0 and proxying to a Mongrel cluster for our latest e-commerce website QuietHeadphones.com which is scheduled to be launched at the end of June. Being an e-commerce site we needed to put the checkout functionality behind SSL. Since Apache is handling both the HTTPS/SSLfunctionality as well as the standard HTTP requests and proxying everything to the Mongrel cluster, the Mongrel cluster doesn’t know which requests are HTTPS and which are HTTP. To tell Rails which requests are HTTPS requests you can set up an environment variable in the Apache virtual host configuration in the httpd.conf file. The environement variable is:

RequestHeader set X_FORWARDED_PROTO ‘https’

In Rails, request.rb checks for that variable and pleasantly handles everything else for you.

Now if you are using ISPConfig to manage the virtual hosts on your web server, you will notice that there is no way to separate SSL vs non-SSL Apache directives using the web interface. Since most of our sites are Ruby on Rails sites and since the RequestHeader variable doesn’t hurt anything if you aren’t using rails, I revised the source code of ISPConfig to always include the RequestHeader set X_FORWARDED_PROTO line in all of the SSL virtual host configurations. That way, anytime you set up a site in ISPConfig and select the SSL option, ISPConfig faithfully inserts the RequestHeader line so that Mongrel knows what sort of requests it is getting.

To make this revision to ISPConfig, open up config.lib.php then edit the SSL-Web section at approximately line 1521 by adding RequestHeader set X_FORWARDED_PROTO ‘https’

file: /root/ispconfig/scripts/lib/config.lib.php

RequestHeader set X_FORWARDED_PROTO ‘https’

Once that is in place, all HTTPS requests will have that request header variable set and regular HTTP requests will not. Then you can use the standard web interface to configure the rest of the Apache directives for your Ruby on Rails application and the Mongrel cluster. Here’s an example of what the Apache Directives text box may look like in ISPConfig.

<Proxy *>
Order allow,deny
Allow from all
</Proxy>

ProxyRequests Off
ProxyPassReverse / http://www.mydomain.com:9001/
ProxyPassReverse / http://www.mydomain.com:9002/
ProxyPassReverse / http://www.mydomain.com:9003/
ProxyPreserveHost On
RewriteEngine On
RewriteMap servers rnd:/var/www/webX/rails/map.txt
RewriteRule ^/(images|stylesheets|javascripts)/?(.*) $0 [L]
RewriteRule ^/(.*)$ http://www.mydomain.com:${servers:ports}/$1 [P,L]
Alias /images /var/www/webX/web/images
Alias /stylesheets /var/www/webX/web/stylesheets
Alias /javascripts /var/www/webX/web/javascripts
SSLCertificateChainFile /var/www/webX/ssl/gd_intermediate_bundle.crt

There are a couple things to note in this example. At the time of this writing, we are using Apache 2.0 and, therefore, don’t have access to the mod_proxy_balancer that many people are enjoying with Apache 2.2. Nevertheless, we wanted to run a Mongrel cluster so we are using a randomized proxy balancer by taking advantage of the RewriteMap feature of Apache 2.0. We created a text file that contains the port numbers that each of our Mongrel instances are using separated by pipes as follows:

file: map.txt

ports 9001|9002|9003

Then on each request, Apache randomly selects on of the three ports from the map.txt file and rewrites the request for one of our mongrel instances.

RewriteRule ^/(.*)$ http://www.mydomain.com:${servers:ports}/$1 [P,L]

Lastly, if you buy an SSL certificate from godaddy.com, you will need to add the SSLCertificateChainFile directive to your Apache configuration. Otherwise, most – perhaps all – browsers will complain about the ssl certificate not being trusted. Once you know about that, it’s an easy adjustment to make. Simply give Apache the path to the gd_intermediate_bundle.crt that you will get when you buy your ssl certificate at GoDaddy.com

Page six of the Perfect Setup tutorial says that you should add the following lines to your proftpd.conf file.

vi /etc/proftpd/proftpd.conf
…
DefaultRoot ~
IdentLookups off
ServerIdent on “FTP Server ready.”
…

I found that if I include those lines inside of <Global>…</Global> tags the delay goes away and I am instantly logged into the server. So, instead of the above format, add those lines inside the Global tags like this.

vi /etc/proftpd/proftpd.conf
…
<Global>
DefaultRoot ~
IdentLookups off
ServerIdent on “FTP Server ready.”
</Global>
…

File: /etc/ssh/ssh_config
…
  HashKnownHosts yes
# GSSAPIAuthentication yes
  GSSAPIDelegateCredentials no
…

GSSAPIAuthentication specifies whether user authentication based on GSSAPI is allowed. Connections with GSSAPIAuthentication option enabled on non-kerberos SSH servers are very slow. If you run ssh in verbose mode you may get a “Miscellaneous failure” error message.

ssh -v -l example.com
…
debug1: Miscellaneous failure
No credentials cache found
…

After disabling GSSAPIAuthentication, you probably won’t have to wait as long to get your login in prompt.

May 8 05:46:07 hostname postfix/smtp: 23E507C950: to=, relay=mx1.hotmail.com[65.54.244.136]:25, delay=0.6, delays=0.26/0.01/0.15/0.18, dsn=2.0.0, status=sent (250 <20070508054607.23E507C950@hostname.com> Queued mail for delivery)

Mail was successfully leaving my server and Hotmail was reporting back that the mail was successfully sent yet the mail was not ever getting delivered to my hotmail inbox. The solution is to make sure you have a valid SPF record for your domain. Microsoft has an online wizard to help you create the SPF record.

When you are creating the record, make sure not to include a “ptr” lookup. I got this email from Microsoft when trying to figure all this out.

We reviewed your SPF record and note that it includes the “ptr” or reverse DNS lookup mechanism. The specification for SPF records (RFC 4408) discourages use of “ptr” for performance and reliability reasons. This is especially important for Windows Live Mail, Hotmail and other large ISPs as a result of the very high volume of mail we receive each day. We highly recommend you remove the “ptr” mechanism from your SPF record and, if necessary, replace it with other SPF mechanisms that do not require a reverse DNS lookup, such as “a”, “mx”, “ip4” and “include.” This will help ensure that Sender ID validation is performed as accurately as possible, maximizing your email deliverability while protecting your domain from spoofing.

Finally, you need to create a TXT DNS entry. Allow about 24 hours or so, and Hotmail and MSN will start accepting your mail. Note, however, they may be sending it to your Junk Mail folder.