Before proceeding for change in config, you should confirm that ldap and authnz_ldap modules are there in Apache. You can check that using httpd -M command, following should be there in output:

$ httpd -M 
..
 ldap_module (shared)
 authnz_ldap_module (shared)
..

If this is not the case, then please install these modules and make sure you load them in your Apache config (usually /etc/httpd/conf/httpd.conf) like this:

LoadModule ldap_module modules/mod_ldap.so
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so

After having these modules to facilitate authentication, we need to remove or comment out following lines in our git config file /etc/httpd/conf.d/git.conf:

<Location />
    AuthType Basic
    AuthName "Private Git Access"
    Require valid-user
    AuthUserFile /var/www/gitweb/passfile
</Location>

After removing or commenting out above lines, put these lines in the file:

<Location "/">
    AuthType Basic
    AuthName "Git Authentication"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    AuthLDAPURL "ldap://<my ad server>:389/ou=xx,dc=xx,dc=xx,dc=com?sAMAccountName?sub?(objectClass=user)"
    AuthLDAPBindDN <user>@<mydomain>
    AuthLDAPBindPassword <user password>
    Require valid-user
</Location>

Here make sure to supply correct LDAP url and provide info of one user and its password so that Apache can contact LDAP to retrieve authentication information. You also needs to update gitolite.conf to manage authorization for git repositories for LDAP user.

Reload Apache to apply new settings and you should be able to access Git repository over http using LDAP user.

Common issues:
If authentication not working, put “Loglevel Debug” option in your Apache VirtualHost and check Apache error logs. In case you notice following error:

[Wed Apr 18 15:02:13 2012] [debug] mod_authnz_ldap.c(454): [client xx.xx.xx.xx] [25749] auth_ldap authenticate: accepting user.name
[Wed Apr 18 15:02:13 2012] [debug] mod_authnz_ldap.c(821): [client xx.xx.xx.xx] [25749] auth_ldap authorise: declining to authorise

Then make sure AuthzLDAPAuthoritative off entry is there in Apache git config file, I have already mentioned it above just in case if you missed it.

In case you notice “[User Not Found]” in error log, then check your user name again and make sure the user exist in correct OU/group specified in ldap url.

Related articles:
* Quickly setup Git server with gitolite, gitweb, ssh and http auth
* Configure password based subversion access via http
* Download, install and configure ViewVC for Subversion

Step 1: Download the required RPMs or install using source

Here are the RPMs I downloaded from source mentioned above (of course, download the latest version of these RPMs when you wants to do installation):

git-1.7.8.2-2.el5.rf.x86_64.rpm
gitolite-1.5.9.1-2.el5.noarch.rpm
gitweb-1.7.8.2-2.el5.rf.x86_64.rpm

You may also need to have some perl dependencies which you can install through CPAN or can also download the RPMs for them, I needed below ones:

perl-DBI-1.617-1.el5.rfx.x86_64.rpm
perl-Git-1.7.8.2-2.el5.rf.x86_64.rpm
perl-TermReadKey-2.30-3.el5.rf.x86_64.rpm (Optional)
perl-Error-0.17017-1.el5.rf.noarch.rpm (Optional)

Step 2: Install the RPMs:

$ rpm -ivh perl-DBI-1.617-1.el5.rfx.x86_64.rpm perl-TermReadKey-2.30-3.el5.rf.x86_64.rpm perl-Error-0.17017-1.el5.rf.noarch.rpm git-1.7.8.2-2.el5.rf.x86_64.rpm perl-Git-1.7.8.2-2.el5.rf.x86_64.rpm  gitolite-1.5.9.1-2.el5.noarch.rpm gitweb-1.7.8.2-2.el5.rf.x86_64.rpm

We have Git, Gitolite and Gitweb installed now.

Step 3: Configure Gitolite for authentication/authorization:

We need to configure Gitolite and the information for that is already described here so I am skipping that part.

Step 4: (Optional) Test Git with Gitolite:

Its worth a try to quickly test Git with Gitolite you just installed/configured. Jump to your pc and if you have Linux, generate public/private keys using ssh-keygen utility in case you already don’t have, for testing purposes, you can use following command:

/usr/bin/ssh-keygen -N '' -t rsa -f /root/.ssh/id_rsa

In case you are using Windows (which unfortunately I am using as of now), you can use puttygen utility and can refer a good tutorial here for exact process.

Copy your public key file to Git server, rename it to yourname.pub and put it in this directory so that Gitolite can refer/read them when needed: /var/lib/gitolite/.gitolite/keydir/

Time to clone gitolite-admin repository now, for Linux, just use:

$ git clone git@serverip:gitolite-admin

For Windows, you can install msysgit and optionally you can install a cool Git client like TortoiseGit from here. To Clone the gitolite-admin repository now, browse any directory, right click, choose Git Clone… and put required information. A sample screenshot is below:

Clone should get successful and you will get gitolite-admin repository in your pc. Go inside and update gitolite.conf to add new repositories/users. This process is described here if you want to continue testing.

Step 5: Configure Gitweb, http access of Git

This process is also documented by original author here but that is for OpenSuSE and while following that, I ran in some issues, so here posting information to setup this in RHEL machine which is working for me. You may want to refer that documentation in case things are not very clear reading my instructions because I am not diving in details and focus is more on practical execution.

Add following line in /var/lib/gitolite/.gitolite.rc file:

$GL_GITCONFIG_KEYS = "gitweb.url receive.denyNonFastforwards receive.denyDeletes";

Add some config entries in gitolite.conf file along with entry for daemon user. My gitolite.conf looks like below:

$ cat /var/lib/gitolite/.gitolite/conf/gitolite.conf
repo    gitolite-admin
RW+     =   git daemon
 
repo    tproject
RW      = git jagbir daemon
R       = @all
config  gitweb.url = git@serverip:tproject
config  receive.denyNonFastforwards = true
config  receive.denyDeletes         = true
 
repo    @all
R       =   daemon gitweb

Don’t forget to add daemon in all repositories, whether for Read write or just read to enabling browsing through http.

Step 6: Configure Apache under SuExec:
Apache runs under Apache user while our Git repositories are under Gitolite user. We have to use SuExec module in Apache so that it will also run under Gitolite user and be able to update information in repositories. Confirm that SuExec module is there in you Apache by running: $ httpd –M command and you should have suexec_module (shared) line in output.

Update permissions of suexec program. We also needs to have a wrapper script and to know where to put it check options of suexec, here are commands:

$ chgrp apache /usr/sbin/suexec
$ chmod 4750 /usr/sbin/suexec
$ /usr/sbin/suexec -V
-D AP_DOC_ROOT="/var/www"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="apache"
-D AP_LOG_EXEC="/var/log/httpd/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=500
-D AP_USERDIR_SUFFIX="public_html"

So path for our wrapper script and Gitweb is /var/www as shown above in AP_DOC_ROOT value. Create a wrapper script in /var/www/bin/ directory (create bin directory first). My script looks like below which you can copy as is:

$ cat /var/www/bin/gitolite-suexec-wrapper.sh
#!/bin/bash
 
USER=$1
 
export GIT_PROJECT_ROOT="/var/lib/gitolite/repositories"
export GITOLITE_HTTP_HOME="/var/lib/gitolite"
 
exec /usr/bin/gl-auth-command $USER

Because Gitweb will also runs under gitolite user, copy all of its files to /var/www directory and make sure the owner of /var/www directory (along with all subdirectories/files should be gitolite user), here are commands:

$ cp -r /usr/share/gitweb /var/www
$ chown –R gitolite.gitolite /var/www

Update gitweb.conf file to point to gitolite directory where all repositories are there, below line should be there in /etc/gitweb.conf file:

our $projectroot = "/var/lib/gitolite";

Step 7: Configure Virtualhost in Apache:
Here is my apache virtual host file, which you can copy as is (of course, change ServerName, Alias etc as per your values):

$  cat /etc/httpd/conf.d/git.conf
 
<VirtualHost *:80>
 
ServerName  git.mydomain.com
ServerAlias git
 
DocumentRoot /var/www/gitweb
 
SuexecUserGroup gitolite gitolite
 
SetEnv GIT_PROJECT_ROOT /var/lib/gitolite/projects
SetEnv GIT_HTTP_EXPORT_ALL
 
SetEnv GITOLITE_HTTP_HOME /var/lib/gitolite
 
ScriptAliasMatch \
"(?x)^/(.*/(HEAD | \
info/refs | \
objects/(info/[^/]+ | \
[0-9a-f]{2}/[0-9a-f]{38} | \
pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
git-(upload|receive)-pack))$" \
/var/www/bin/gitolite-suexec-wrapper.sh/$1
 
<Directory "/var/www/gitweb">
Options ExecCGI
AllowOverride None
AddHandler cgi-script .cgi
DirectoryIndex gitweb.cgi
Order allow,deny
Allow from all
</Directory>
 
<Directory "/var/www/bin">
<Files "gitolite-suexec-wrapper.sh">
Order allow,deny
Allow from all
</Files>
</Directory>
 
<Location />
AuthType Basic
AuthName "Git Access"
Require valid-user
AuthUserFile /var/www/gitweb/authfile
</Location>
 
</VirtualHost>

As you can see we are using basic authentication here and for that, you need to create file which will have auth information, create file and sample user (gitolite) to test it:

$ htpasswd -cmd /var/lib/gitolite/authfile gitolite
New password:
Re-type new password:
Adding password for user gitolite
 
$ cat /var/lib/gitolite/authfile
gitolite:wG7/EAcl9kdvU

Make sure you have initialize the repository to enable its access via http, let’s prepare testing repository for this purpose:

$ cd /var/lib/gitolite/repositories/testing.git
$ sudo -u gitolite git --bare init
$ sudo -u gitolite git update-server-info
$ mv hooks/post-update.sample hooks/post-update
$ chmod +x hooks/post-update

The above steps are needed for http access otherwise you will get error like below in your apache error logs when trying to clone:

[Tue Apr 10 15:34:16 2012] [error] [client 10.100.xx.xx] Repository not exported: '/var/lib/gitolite/repositories/testing'

All files under /var/www should have gitolite as owner, let’s update permissions once more:

$  chown -R gitolite:gitolite /var/www

Step 7: Test it out:
Restart apache and try to browse your server now: http://serverip. It should ask username/password and after supply correct, you should be able to see gitweb interface showing your repositories where you can traverse in them.

In case you see a blank page, then it might be issue with SuExec. Check suexec log file:  /var/log/httpd/suexec.log. You may see a message like:

[2012-03-30 04:14:26]: cannot run as forbidden uid (100/gitweb.cgi)

This means suexec won’t execute under user/group have userid/groupid less than 500 (system). In this case you can change this id for our gitolite user as per below:

$ usermod -u 650 gitolite
$ groupmod -g 650 gitolite

650 is just an example here, you can use any value above 500 in case 650 is already used by existing user/group. As user/group id get changed, you need to set permissions again for your directories:

$ chown –R gitolite:gitolite /var/www

Try now and you should be able to browse smoothly. Please put a comment below if you are still facing any issues, I would try to help you out.

Update: If you want to perform authentication using LDAP for git which I have described in next article, you can access it using below link:

* Setup Git auth using LDAP

In earlier article I mentioned using a php script to dynamically create/remove virtualhost entry in Apache (httpd) config file and then reload it using cron.

Here I would describe how to manage DNS to dynamically recognize newly created virtualhosts. Again, this might not be the best or efficient way to implement this but this is what worked for me. After creating virtualhosts in Apache, you need to update DNS so that new virtualhosts start working. To update DNS dynamically, your DNS provider should have some way (like API) which enable you to manipulate its records. There are few providers offering this facility. For this experiment, I selected DNSMadeEasy which provides APIs to add/remove/update records on fly using scripts.

You can see the script below written in php:

<?php
date_default_timezone_set("GMT");
$reqDate = date("D, d M Y H:i:s T",mktime(date("H"),date("i"),date("s")-45,date("m"),date("d"),date("y")));
$apiKey = "my-api-key";
$secretKey = 'my-secret-key';
$secretKey2 = hash_hmac('sha1', $reqDate, $secretKey);
 
$URL = "http://api.dnsmadeeasy.com/V1.2/domains/example.com/records";
echo "<b>Endpoint :</b> ".$URL;
 
$headers = array(
'x-dnsme-requestId: '.time(),
'x-dnsme-apiKey: '.$apiKey,
'x-dnsme-requestDate: '.$reqDate,
'x-dnsme-hmac: '.$secretKey2,
'accept:application/xml',
'content-type:application/xml'
);
 
echo "<br><br><b>Request Headers</b><br>";
echo 'x-dnsme-requestId: '.time()."<br>".
'x-dnsme-apiKey: '.$apiKey."<br>".
'x-dnsme-requestDate: '.$reqDate."<br>".
'x-dnsme-hmac: '.$secretKey2."<br>".
'accept:application/xml'."<br>".
'content-type:application/xml';
 
$body = '
<record>
<data>xx.xx.xx.xx</data>
<gtdLocation>Default</gtdLocation>
<id>123456</id>
<name>dummy</name>
<ttl>1800</ttl>
<type>A</type>
</record>
';
 
echo "<br><br>".$body;
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $URL);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 0);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
//curl_setopt($ch, CURLOPT_PUT, 1);
//curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'DELETE');
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $body);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, true);
$ResponseStr = curl_exec($ch);
curl_close ($ch);
echo "<pre>";
echo $ResponseStr;
?>

You need to have Api key and Secret key which you will get upon registration on DNSMadeEasy. This is very basic script to update DNS record dynamically. You can extend it further to incorporate more functions.

So basically to manage Apache virtalhosts dynamically, you need following functionality:
* Script to create/update/remove them from Apache (httpd) config file.
* Reload Apache to apply new settings which can be done through a simple cron entry.
* Script to update DNS records to reflect changes.

Let me know if you have some other way/idea to implement this.

Helpful related articles:
* PHP script to dynamically add/remove/update virtualhosts in Apache
* Upgrade Apache in Linux quickly
* Upgrade to latest PHP using yum upgrade
* 5 Steps to secure your Linux Server
* Disable weak ssl ciphers in lighttpd in Linux
* Disable SSL ver 2 in Apache for security and PCI Compliance

Create script to update Apache config file to create/remove subdomains/virtual hosts, here’s the script which I called here as subdmanager.php:

<?php
 
$templateStr = '##-- Entry start for <usersubdomain> --
<VirtualHost x.x.x.x:80>
    ServerAdmin webmaster@<usersubdomain>.exampledomain.com
    ServerName <usersubdomain>.exampledomain.com
    ServerAlias www.<usersubdomain>.exampledomain.com
    UseCanonicalName Off
    DirectoryIndex index.php 
    DocumentRoot /var/www/maindomains/exampledomain.com/subdomains/<usersubdomain>/
        ErrorLog /var/www/logsvhosts/exampledomain.com/users-error-log
        LogLevel error
 
        <IfModule mod_ssl.c>
                SSLEngine off
        </IfModule>
        <Directory /var/www/maindomains/exampledomain.com/subdomains/<usersubdomain>.com>
                Options -Includes -ExecCGI
        </Directory>
</VirtualHost>
##-- Entry End for <usersubdomain> --';
 
foreach($argv as $k=>$v)
{
	$argvStr .= $v."<----->";
}
$argvStr = trim($argvStr,"<----->");
$argvArr = @explode("<----->",$argvStr);
$case = $argvArr[1];//"create";
$subdomain_name = $argvArr[2];

Here we are making a template for virtualhost entry. the string

 <usersubdomain>

will be replaced by actual subdomain selected by user. exampledomain.com is the main website. No need to mention that all path, IP address (denoted by x.x.x.x here) are used as an example here, please replace them with your own actual values.

Then we are checking the command line option (create or remove), subdomain name and store values in respective variable.

if($case != '')
{
	switch($case)
	{
		case 'create':
 
		$domainStr2 = str_replace("<usersubdomain>",$subdomain_name,$templateStr);
 
		$filename = "/etc/apache2/sites-enabled/user-sites";
		$mainStr1 = file_get_contents($filename);
 
		$fp = fopen($filename,"a");
		fwrite($fp,($mainStr1!=''?"\n".$domainStr2:$domainStr2));
		fclose($fp);
 
		break;
 
		case 'remove':
 
		$filename = "/etc/apache2/sites-enabled/user-sites";
 
		$contents = file($filename);
 
		foreach ($contents as $key => $line)
		{
			if(strpos($line,"Entry start for ".$subdomain_name." --") == TRUE)
			{
				$myStartKey = $key;
			}
 
			if(strpos($line,"Entry End for ".$subdomain_name." --") == TRUE)
			{
				$myLastKey = $key;
			}
		}
 
		for($i=$myStartKey; $i<=$myLastKey; $i++)
		{
			unset($contents[$i]);
		}
 
		$newContents = implode("",$contents);
 
		$fp = fopen($filename,"w");
		fwrite($fp,$newContents);
		fclose($fp);
 
		break;
 
		default:
	}
 
	exec("/usr/sbin/apache2 -t", $output2, $retval2);
	if($retval2 == 0)	// 0 == Syntax OK; 1 = Syntax Wrong
	{
		exec("touch /tmp/.reapache");
		echo "OK";
	}
	else
	{
		echo "Syntax Error";
	}
}

Here, if user is supplied ‘create’ as command line argument, we are create a new virtual host and saving it in a file which is stored in Apache directory and read by Apache. This file (/etc/httpd/conf.d/user-sites) is readable by PHP. We are removing the subdomain if user supply ‘remove’ as command line option. After this we are checking the Apache syntax and if its OK then we are creating/touching a simple file in tmp directory. Why? Its because PHP can not reload Apache (as initial apache process is started by root and we can’t let php to reload/restart it), so what we are doing here is that a cron is running every minute in Server and check existing of this file (/tmp/.reapache), if its exist then reload Apache else do nothing. So every minute settings get applied. Of course, this will add a delay of maximum 1 minute for you to create or remove subdomains but initially I guess its acceptable.

You also needs to make sure to create directory (which hold subdomains files) etc. before executing script or update this script itself to create required directories/files for you.

You can see that this is pretty simple script and needs a lots of enhancements before deploying it in production environment but still its giving an idea as how can we achieve that functionality.

As an example, you can run this script like this:

$ php subdmanager.php --create mynewsubdomain
 
or 
 
$ php subdmanager.php --remove myoldsubdomain

or call this script from your website php files using syntax mentioned above.

Here’s the contents of simple cron file (bash script) which you can set to run every minute which will reload Apache in case /tmp/.reapache is present:

#!/bin/bash
if [ -a /tmp/.reapache ]; 
then 
	`/etc/init.d/apache2 reload`; 
	`rm -f /tmp/.reapache`;
fi

Hah, pretty simple, isn’t it? yah but don’t rush and put it in production. I guess it needs to be fine tuned/needs better exception handling etc.

So things from Server side is completed but what about DNS? To make new subdomian work, you need to update DNS as well, right? Let me cover up that part in next article which I will post here after 2-3 days as the process is still in testing phase.

Normally, you get message like this for this issue:

Synopsis : The remote service supports the use of medium strength SSL ciphers. Description : The remote host supports the use of SSL ciphers that offer medium strength encryption, which we currently regard as those with key lengths at least 56 bits and less than 112 bits.
 
Note: This is considerably easier to exploit if the attacker is on the same physical network. Solution: Reconfigure the affected application if possible to avoid use of medium strength ciphers. Risk Factor: Medium / CVSS Base Score : 4.3 (CVSS2#AV:N/AC:M/Au:N/C/I:N/A:N)

Let’s disable these weak cipher’s now:

Update config file to add or modify following lines. After addition/editing, lines should look like this:

$ vi /etc/lighttpd/lighttpd.conf
ssl.use-sslv2 = "disable"
ssl.cipher-list = "TLSv1+HIGH !SSLv2 RC4+MEDIUM !aNULL !eNULL !3DES @STRENGTH"

make sure that you have to put these lines in any blocks/vhosts etc. also because these are global options and if you not put these in vhosts blocks, then they will not be effective.

Time to verify things, you can check whether ssl2 is disabled first:

$ openssl s_client -connect localhost:443 -ssl2

you should get error while connecting.

Now check whether weak ciphers are disabled:

$ openssl s_client -connect localhost:443 -cipher EXP:LOW

here as well, you should get error while connecting.