48 Hours with Joel and Jeff..
Joel Spolsky of FogCreek Software
and Jeff Atwood of nothing
have joined forces to push out StackOverflow. To generate hype and the all
important critical mass, they record a weekly podcast. There are now 48
one hour long podcasts in the wild and I've listened to all of them
while driving to Sweet Peppers so
I can work on RoR-izing FollowMeIP.
At some point a conversation was had
about how cool it would be to have a website that would cater to the
asking and answering of programming questions - Stackoverflow was
born. Atwood is project manager over a couple of .net programmers and
Joel simply tells his readers about how cool it is. It's a great
situation really, Atwood does all the work, spends the money, takes
the risks and Joel sits back and waits for success or failure. Either
way, Joel will have tons of new material to write about.
Atwood seems to be in control of the
technology stack and server infrastructure. It's rather amusing at
times to listen to his rationale on why he did certain things.
Stackoverflow is using ASP.NET MVC, microsoft's answer to ruby on
rails. He opted to use this stack which was in beta over the actual
RoR stack. He's definitely a microsoft centric developer and every
time he denies it, take a drink. It's also amusing listening to hardware issues he's having trying to
run his own server. In podcast 48, Atwood said software raid is better
than hardware raid. Having dealt with both - extensively - software
raid is one big slow steaming pile of crap. With drive sizes in the
2tb now, a nice hardware pci-e raid 1 solution is what you want. It's
clear Atwood hasn't had much experience with hardware and really
should move his project to some sort of cloud before he runs out of
money playing with different raid settings.
After listening to 48 hours of rambling
a few things become clear:
The only reason to listen is to hear
what Joel says.
Atwood mostly just says "right"
or "I agree" randomly.
Joel is not a Linux fan.
Atwood doesn't understand FOSS.
Atwood hasn't "been around"
as much as he'd like to think he has.
Atwood should stick to writing.
The stackoverflow podcast is no longer
about stackoverflow.
So how is stackoverflow doing? Fine I
suppose. People seem to be using it, but it doesn't matter because
Atwood made one fatal mistake - not open sourcing it. After the
initial release, people started asking the same question: can I spawn
a stackoverflow for xzy? Why not a stackoverflow for automotive
questions? Atwood has repeatedly said the site just can't be switched
from programming questions to some other type of question. That means
poor design or lack of vision - most likely a little of both. If
you've been in computers your entire life it's rather hard to see
value in anything else. They missed the boat and the flood gates are
about to be opened.
CNProg.com has
replicated stackoverflow and released it under the apache license. The
motivation was to enable Chinese programmers the ability to use a
site like stackoverflow which doesn't support anything but English. Once again
the podcast provided a smile on my face when Joel started talking
about copyright violation. Sure, it's copyright infringement if China
followed U.S. copyright laws - and they don't. When the Chinese government owns
and operates a Disney Land clone, I seriously doubt they're going to
mind a stackoverflow clone.
I'm reasonably sure CNProg didn't take
nearly as long to write and I'm guessing a decent ruby on rails
developer could rewrite stackoverflow within a week. Considering
Atwood's poor choice in technology stacks, my prediction is someone
will clone stackoverflow using ruby on rails and release it under an
open source license. This will enable people to create their own
niche sites without debating with Atwood about what's possible.
Git server setup using gitosis for Centos 5.2
This is a step by step HOWTO to host
git repositories using gitosis on a Centos 5.2 box. I'm currently
working on a ruby on rails project with
Ryan. The need for a source management solution
was apparent and I've been using subversion for while. Of course I could make a
new subversion repo in no time, my server is already setup, backups
being done, and it just works - but according to Linus I was ugly and stupid. Ryan wants me to use
git and I really didn't want to be ugly and
stupid.
I go about searching the web for a git
server howto and found that git wasn't really meant to used in a server/client
situation, but more of a peer to peer environment. Gitosis was
written to emulate that server/client environment I'm after. I also
didn't see anything useful on google that was CentOS specific with
setting up gitosis.
Here's how I did it..
Step 1 - (On your server)
Install python-setuptools on your
server, you'll need it to install gitosis.
As root:
yum -y install python-setuptools
Step 2 - (On your server)
Install git. You'll need the DAG RPM
repository for this one.
As root:
- Red Hat Enterprise Linux 5 / i386:
rpm -Uhv
http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
- Red Hat Enterprise Linux 5 / x86_64:
rpm -Uhv
http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS//rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm
yum -y install git
Step 3 - (On your server)
Install
gitosis.
As
root:
git
clone git://eagain.net/gitosis.git
(it should download stuff and create a
gitosis directory)
cd gitosis
python setup.py install
Step 4 - (On your server)
Make a user called git.
adduser git
Give your new user git a password.
passwd git
Step 5 - (On your client)
The whole point of gitosis is to
transfer files via ssh using a shared key process (ie: no password
required to login to user git on your server). Now before you go and
start doing it the manual way - don't. Gitosis must create and maintain the authorized_keys file.
As your normal user on your
client/development box:
ssh-keygen -t rsa (take the defaults)
There is now a new file called id_rsa.pub in ~/.ssh/
Copy the id_rsa.pub file to the server:
scp ~/.ssh/id_rsa.pub git@someServer.com:/home/git/
Step 6 - (On your server)
I'm assuming you're still root on the
server.
Change to the git user.
su git
cd /home/git
gitosis-init < id_rsa.pub
It should reply with Initialized empty
Git repository in ./ - twice..
We can now remove id_rsa.pub as we
don't need it anymore.
rm id_rsa.pub
Now we must set some directory and file
permissions to let sshd see the new authorized_keys file.
chmod 755 /home/git
chmod 700 /home/git/.ssh
chmod 644 /home/git/.ssh/authorized_keys
Step 7 - (On your client)
We're pretty much done server side. Now we're going to configure
the server via the client.
Although I assume this is obvious, you need to install git on your
client machine.
git clone git@someServer.com:gitosis-admin.git
cd gitosis-admin
You should see a gitosis.conf file and
keydir directory. Here's the thing, anything you need to configure
on the server, you actually configure here and commit the changes to
the server. Open up gitosis.conf in your favorite text editor
Make a new group name for your project. It really doesn't matter what you name this group. Add users to the member section who will need push access.
[group myTeam]
members = (copy and paste the user from
the members = line in the [group gitosis-admin] section)
writable = myNewProject
Save the file. Why did we use that
members=user@someServer.com? If you look in the keydir directory,
you'll see your public key with the filename
user@someServer.com.pub. These are your users (minus the .pub).
Step 8 - (On your client)
You've just made a configuration
change. You want the server to allow user@someServer.com to have
write access to a project called myNewProject. You must commit this
change to the server.
git commit -a -m "Allow the
machine I am on right now write access to myNewProject"
git push
Now it's time to make the directory
that will contain your project files. Move up out of the
gitosis-admin directory.
cd ..
mkdir myNewProject
cd myNewProject
git init
git remote add origin
git@someServer.com:myNewProject.git
Add your files, move some files, create
some files. Put some files in the myNewProject directory.
Now we can commit the initial push to
the server.
git add .
git commit -a -m "This is my
initial commit for myNewProject"
git push origin
master:refs/heads/master
Git will do some neat things and push
things to the server. Now to delete the directory you just created..
Yeah, I said it.
cd ..
rm -fr myNewProject
And now to pull myNewProject from the
server using clone..
git clone
git@someServer.com:myNewProject
Now you have a version of your code you
can actually use, make changes and commit to the server using normal
git commands.
As of now, you have a fully functioning
git server with a project and a client that can make changes. But
what about other people?
Step 9 - (On your client)
So your friend Bob wants to help you
out with myNewProject. Have Bob generate his own id_rsa.pub and send
it you. When you have it:
cd gitosis-admin
Assuming Bob's
id_rsa.pub is in your home directory, move it to the key directory renaming it at the same time:
mv ~/id_rsa.pub keydir/bob.pub
Tell git about the new file:
git add keydir/bob.pub
Edit your gitosis.conf file again. Look
for the members line in myNewProject and add Bob to it:
members = user@someServer.com bob
Now you could add bob to be in the
gitosis-admin group if you wanted him to be able to do what you're
doing now. How much do you trust Bob?
Save the file and quit. It's time to
tell your server about Bob and send Bob's public key.
git commit -a -m "Added commit
rights to Bob on myNewProject"
git push
The server will automatically add Bob's
public key to authorized_keys. Do not attempt to add him manually.
Step 10 -
Do a little dance, you're done.
SSH without password HOWTO for CentOS 5.2
This one is short and sweet and is for CentOS 5.2 installs.
On the client machine generate a public key. Do this command as the user you normally run under:
ssh-keygen -t rsa (take the defaults)
There is now a new file called id_rsa.pub in ~/.ssh/
Copy the id_rsa.pub file to the server:
scp ~/.ssh/id_rsa.pub someUser@someServer.com:/home/someUser/
Log into the server:
ssh someUser@someServer.com
Append your client public key to authorized_keys:
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
Remove the client public key on the server, you don't need it anymore:
rm ~/id_rsa.pub
Set permissions on the server so sshd can see authorized_keys:
chmod 755 /home/someUser
chmod 700 /home/someUser/.ssh
chmod 644 /home/someUser/.ssh/authorized_keys
That's it, the next time you login to the server via the client it shouldn't ask for a password.
