Since I had some time this weekend, I decided it was about time I rolled some RPM’s so I could run Rails. Of course, it being over two years since I was last rolling RPM’s for work at Pason, it took me a bit to get back in the swing of things.

I followed the guide found via the Ruby on Rails wiki, and modified it a bit for my server. The two main pieces of software that needed RPM’s were fastCGI and mod_fcgid (slightly different than mod_fastcgid).

Below you can download the RPM’s and the SRPM’s though I will be the first to acknowledge that I cheated a bit. I should have modified the Makefile on each of these programs to make use of an install_dir directive, but since I was building on a clean CentOS4.6 vmware OS, I decided not to go through the hassle. If someone really wants to do it properly, have at it – that’s what SRPMS are for.

RPMS:
mod_fcgid-1.09-1.i386.rpm
fcgi-2.4.0-1.i386.rpm

SRPMS:
mod_fcgid-1.09-1.src.rpm
fcgi-2.4.0-1.src.rpm

Instead, we will add subversion to xinetd. The benefit of this is that subversion is only running when we need access to the repository rather than running all the time. By default, subversion is not set up in xinetd, so the following is how I set it up:

First make sure that xinetd is installed.

# yum install xinetd

Next we want to add the following to our /etc/xinetd.d/svnserve

# default: off
# description: svnserve is the server part of Subversion.
service svn
{
  disable = no
  port = 3690
  socket_type = stream
  protocol = tcp
  wait = no
  user = root
  server = /usr/bin/svnserve
  server_args = -i -r /svn
}

Finally, lets restart xinetd:

/etc/init.d/xinetd restart

Now xinetd will start the subversion repository server every time a subversion request is made.

Here was my process.

# yum install subversion

Ok, that was pretty easy. I now have subversion installed on my system; both from a client and user’s perspective. Next I need to create a subversion repository location on my disk (/svn can be replaced with any location on your server).

# svnadmin create /svn

In /svn/conf/passwd add the following (it is in plaintext, but I am sure there is an encrypted solution):

[users]
achristopher = some secret, yet plaintext password

In the /svn/conf/svnserve.conf, you should set the following:

[general]
anon-access = read
auth-access = write

realm = Test Repo

There, our subversion repository has been set up. Now all we have to do is start the subversion daemon.

# svnserv -r /svn -d

We can test the subversion repo:

# mkdir /tmp/test

# svnlook tree /svn
/
svn/
test/

We have just added a directory to our subversion repository. Now lets checkout this project, and get to work:

# rm -Rf /tmp/test
# svn checkout svn://localhost/svn/test
Checked out revision 1.


I cheated a little there, because I had entered my password before I created this posting, so you can expect to see something like the following:

Authentication realm: Test Repo
Password for 'achristopher':

Just enter your password (the one entered in plain text above) and continue working.

To follow: How to set subversion to work with xinetd (it isnt that exciting, but definitely new post worthy).

While this may not seem like a huge deal to most users, what this means is that you can’t connect to any other mail server when attempting to send emails because Rogers has blocked access. Jenna can’t send emails using her McMaster email from a Rogers account.

When I initially looked at setting up Internet, this was the first question I asked Rogers. They assured me that traffic shaping was the only limitation they put on the account. The customer service agent assured me that their literature even mentions this. Their literature is wrong.

As a way around this problem, you are going to want to set up a SMARTHOST on a linux box within the home network which is attached to the Rogers connection.

I did some testing and determined that Rogers doesn’t block all traffic over port 25, but only traffic that isn’t going to a Rogers controlled mail server.


9:44 ash@galactica:[~]> telnet smtp.broadband.rogers.com 25
Trying 206.190.36.18...
Connected to smtp.broadband.rogers.com (206.190.36.18).
Escape character is '^]'.
220 smtp107.rog.mail.re2.yahoo.com ESMTP


What we can do now, is set up a SMARTHOST in sendmail to basically forward emails from the server to Rogers SMTP server, then on to it’s destination. The following assumes you are the root user.

In your /etc/mail/sendmail.mc file, we need to add the following:

define(`SMART_HOST',`smtp.broadband.rogers.com')


This defines what server we are going to use as a SMARTHOST. The other problem we are going to run into is that unlike other ISP’s which allow you to send via the SMARTHOST based on what your domain is (basically if you are connected on an ISP’s network, you can send using their server) Rogers requires that users authenticate.

To do this, we need to add the following to the /etc/mail/access file:


AuthInfo:smtp.broadband.rogers.com "U:<username>" "P:<password>" "M:PLAIN"


I then changed the permissions to the file since I had my plaintext password in it:

chmod 660 /etc/mail/access

Next, we will regenerate the sendmail.cf and access.db files.


m4 /etc/mail/sendmail.mc > /etc.mail/sendmail.cf
makemap hash /etc/mail/access < /etc/mail/access


Now, restart sendmail, and you should be ready to go.

What you can do now, is set up all of your mail clients to point to the linux server as your outgoing mail server and it will forward all of your emails to Rogers and then on to it’s destination.