GitHub was down
status.github.com
status.github.com
I'm having a difficult time reasoning as to the motivation behind all the DDOS attacks. Why would anyone want to disrupt a tool for open, public collaboration used by many free and open-source technologies.
Anyone have any insight?
Tools gonna tool.
Not trying to be a buzkill, but I fail to see how it's funny. So you can break an old - undoubtedly unpatched - win xp box that people use to print boarding passes. Congrats.
Possibilities are: 1) Extortion of some sort i.e. We want your money, or we'll DDoS you every week 2) Content i.e. Remove repositories a, b, and c with content we don't like, or we'll DDoS you every week 3) Weapons demonstration i.e. We want to show off what l33t hax0rs we are, so we'll DDoS Github.com every week
and a lot of closed source commercial projects.
GitLab is basically a GUI that fronts this (I'm not sure about their user access implementation though; doubt it is gitolite). There are other tools like Gerrit [1], Gitweb [2], and cgit [3], that you can use to front your git repos though. GitLab is just a really slick one!
[1] http://code.google.com/p/gerrit/
AFAIK, git-daemon is to allow the specific use case of anonymous, public access to git repositories [1].
You don't need it to have a "central git server", though: If you have an ssh account on yourhost.com and a git repo in /home/you/yourproject on that machine, you can simply git clone git+ssh://yourhost.com/home/you/yourproject. Give out multiple ssh keys to that account, and it's a minimal but functional "central git server"!
Of course, doing the above the easiest, quickest way, with a single UNIX user account, results in (A) giving git client users access to a shell and (B) giving git client users read/write access to each others' repos. Gitolite uses authorized_keys restrictions to avoid (A) and a clever SSH_ORIGINAL_COMMAND hack to avoid (B).
> doubt it is gitolite
Gitlab in fact did use Gitolite for actually serving the git client until quite recently. The largest change in 5.0 was reimplementing a subset of Gitolite's functionality and losing the dependency [2]; the project's major version number is still at 5, although 6.0 is promised soon [3].
[1] http://git-scm.com/book/en/Git-on-the-Server-Git-Daemon
[2] http://blog.gitlab.org/gitlab-5-dot-0-has-been-released/
Managing SSH keys and repo permissions from the command line was just enough of a learning curve for users (internal developers) that they really didn't like it and tended not to use it unless forced. Gitlab has had much less pushback.
Really, it depends on whether your users are more comfortable with the command line or web interface.
Also, I found Gitolite to be a bit easier to administer than Gitlab. Gitlab is a Rails web app, with lots of moving parts. Gitolite is essentially a bunch of Perl scripts which use authorized_keys and SSH_ORIGINAL_COMMAND hackery to convince ssh to do the actual authenticating.
If you already know and love deploying Rails web apps (I don't), then you might find Gitlab easier.