Users can push and pull from other users or from a central repository.

The first thing you need to do is install git on both your clients and server. I am using Ubuntu, so you will have to figure out the equivalent commands and package names.

(client)$ sudo apt-get install git git-core

(server)$ sudo apt-get install git git-core

Now that we have git on our server and client, we can start creating the git repository we want under source control.

The first thing we will do is create a git project. This can either be an existing code base you are already working on, or you can start a project from scratch. For the purposes of this example, we will start a new project.

(client)$ mkdir project
(client)$ cd project
(client)$ git init

Git should reply with the message ‘Initialized empty Git repository in .git/‘. Make a note of the .git directory created in our project – we will need it shortly.

I ran into my first issue here – the version of git I am using doesn’t seem to like to clone empty repositories. In order to allow me to clone (as you will see further down the page), we must have an initial commit.

(client)$ touch README
(client)$ git add README
(client)$ git commit -m "Initial commit." README

We want this new project to be available on a central Git repository (centralized decentralized version control system – the irony is not lost on me). The easiest way is to just scp the .git directory to the server and place them in the directory you plan on containing your repositories. In my case, I created a git directory off of / on the server.

(server)$ sudo mkdir /git

(client)$ git clone --bare project project.git
(client)$ scp -r project.git user@server:/git/

Essentially, we are finished adding the repository to the central server. We can now access the git repo from all clients so long as those users have ssh access to the central server. By default, we can access the repo from the clients using the ssh interface.

(client)$ git pull user@server:/git/project.git master

And we can push changes to the repo in a similar fashion.

(client)$ git push user@server:/git/project.git master

This is about as simple a set up as you can have. The Git server is really quite dumb. The real magic happens on the client side (which is left for another post when I have done a bit more research).

By default, this git server is private. Only users that have shell access to the server have access to push and pull changes. Push access requires private access, but for projects which you want public access, you can set up a git-daemon to serve git clone requests from the public. Rather than run it as a persistent process, you can quite simply tie it into xinetd with this simple configuration (remember, I am using Ubuntu).

(server)$ touch /git/project.git/git-daemon-export-ok
(server)$ sudo apt-get install xinetd
(server)$ sudo vi /etc/xinetd.d/git

service git
{
    disable = no
    type = UNLISTED
    port = 9418
    socket_type = stream
    wait = no
    user = nobody
    server = /usr/bin/git-daemon
    server_args = --inetd --export-all --base-path=/git
}

(server)$ sudo /etc/init.d/xinetd restart

This now gives us a public git repository url we can distribute to others.

(client)$ git clone git://server/project.git

Just remember that you still need to push changes to the repo via ssh.

UPDATE

Talked to one of the guys in #git on irc.freenode.net and he informed me that the usual practice is to create the git repo on the central server first, then clone it to the client and push changes from the client.

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.

Now, I know not everyone has a Linux machine just lying around, but I do, and maybe in the future it might be enough to convince you to build your own file-server for your home (for media perhaps?).

Before starting, you need to make sure you have the ffmpeg binary installed on your Linux box. As of this posting, I have ffmpeg-0.4.9-0.3.20051207.2.el4.rf installed on my CentOS4 machine. I will leave it as an exercise to you to figure out how to install it if you don’t have it.

ash@galactica:[/tmp]> ffmpeg -vcodec xvid -b 500 -qmin 1 -qmax 7 -bufsize 4096 -g 300 -acodec aac -ab 96 -i doctor.who.102.the.end.of.the.world.avi -s 320×240 -aspect 16:9 doctor.who.102.the.end.of.the.world.mp4

Here is a run down of what the switches mean and how they affect your converted video:

-vcodec — this is the video codec you want the converted video to use. For iPod use, I suggest xvid. It is basically the same codec as mpeg4 (except open source) and you don’t run into buffer-underflow problems as often.

-b — this is the video bitrate in kbit/s (higher bitrate means higher quality).

-qmin & -qmax — this controls the quality when dealing with VBR (variable bit rate). Basically a range to keep the quality between.

-acodec — the audio codec to use. When converting to iPod video, this must be aac since that is the only format the iPod supports.

-ab — this is the audio bitrate in kbit/s. 96 kbit/s offers decent audio quality for iPod use.

-i — input file (obviously?).

-s — size of the output video. The iPod supports 320×240, 480×480 and with the newest firmware, now supports 640×480. If you want to retain the source aspect ratio, make sure you calculate the new size to follow the sources aspect ratio.

-aspect — aspect ratio for the converted video. This is especially important if your input video is 16:9 and you want to keep the ratio and replace the extra space with black bars. The aspect ratio is usually 4:3 or 16:9.

Now,after you have run this command, your video should begin to be converted. The time it takes to convert depends greatly on the hardware being used. I often offload this task to a P-III 800 machine, and it seems to be able to encode a video in the same time it would take to watch it. Again, the nice thing about offloading this task is that you can now use your main system for other fun tasks.

Might I suggest maybe using your main machine to whip up a quick script to encode a list of videos, perhaps at night when spare cpu cycles are pleniful? The nice thing about batching up video conversions like this, is that it is also compatible with mac’s running OSX. Sure, you could use the mac-GUI program to do it, but that is going to require a whole lot more human interaction to convert 10 shows.

For mor information of supported codecs, see the FFMPEG Documentation