In , I have described setting up git server with gitolite, gitweb, ssh and http auth using passwd file. Here as an extension of that article, I am describing how to do authentication using LDAP so that authentication become more seamless and avoid any sort of manual work for managing access when you have LDAP for authenticating users.
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:
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:
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:
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:
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.
Often times, there is need for web-accessible folders to be set up so all web-developers have write access.
Along with setgid option, ACL can be used so anyone in the group "web-developers "
would have write privileges to anything under web-accessible document root.
So unless the acl privileges is revoked specifically, it would just continue to work.
To enable ACL, add «acl» option to /etc/fstab file for the corresponding partition and remount.
Now anyone needing write access can be put in the «developers» group.
# usermod -G developers {username}
If you need the webserver to have write access to certain folders, then chown the location to be owned by the webserver, instead of giving write permissions to all.
As per the official definition, is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency. I am describing here steps which I followed to setup a Git server along with Gitolite, Gitweb, ssh and http auth in RHEL5 machine. I have done the installations using RPMs (lazy men’s method) which I got from here:
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):
Step 3: Configure Gitolite for authentication/authorization:
We need to configure Gitolite and the information for that is already described 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 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 and optionally you can install a cool Git client like TortoiseGit from . 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 if you want to continue testing.
Step 5: Configure Gitweb, http access of Git
This process is also documented by original author 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:
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:
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:
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:
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):
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:
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 1015:34:162012][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: . 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:
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:
One of the handiest tools in the OpenSSL toolbox is s_client. You can quickly view lots of details about the SSL certificates installed on a particular server and diagnose problems. For example, use this command to look at Google's SSL certificates:
You'll see the chain of certificates back to the original certificate authority where Google bought its certificate at the top, a copy of their SSL certificate in plain text in the middle, and a bunch of session-related information at the bottom.
This works really well when a site has one SSL certificate installed per IP address (this used to be a hard requirement). With (SNI), a web server can have multiple SSL certificates installed on the same IP address. SNI-capable browsers will specify the hostname of the server they're trying to reach during the initial handshake process. This allows the web server to determine the correct SSL certificate to use for the connection.
If you try to connect to rackerhacker.com with s_client, you'll find that you receive the default SSL certificate installed on my server and not the one for this site:
$ openssl s_client -connect rackerhacker.com:443
Certificate chain
0 s:/C=US/ST=Texas/L=San Antonio/O=MHTX Enterprises/CN=*.mhtx.net
i:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
1 s:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
i:/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority
Add on the -servername argument and s_client will do the additional SNI negotiation step for you:
$ openssl s_client -connect rackerhacker.com:443 -servername rackerhacker.com
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=rackerhacker.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA
i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
2 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
You may be asking yourself this question:
Why doesn't the web server just use the Host: header that my browser sends already to figure out which SSL certificate to use?
Keep in mind that the SSL negotiation must occur prior to sending the HTTP request through to the remote server. That means that the browser and the server have to do the certificate exchange earlier in the process and the browser wouldn't get the opportunity to specify which site it's trying to reach. SNI fixes that by allowing a Host: header type of exchange during the SSL negotiation process.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
I sometimes enjoy living on the edge occasionally and that sometimes means I keep up with OpenStack changes commit by commit. If you're in the same boat as I am, you may save some time by using my repository of bleeding-edge Python packages from the OpenStack projects:
Python packages are updated moments after the commit is merged into the repositories under .
Although the packages will contain the latest code available, rest assured that the code has passed an initial code review (by humans), unit tests, and varying levels of functional or integrated testing. There may still be a bug or two cropping up after that, so be aware of that as you utilize these packages.
Regular users of Python's package tools like or are probably familiar with the repository. It's a one-stop-shop to learn more about available Python packages and get them installed on your server.
However, certain folks may find the need to host a local PyPi repository for their own packages. You may need it to store Python code which you don't plan to release publicly or you may need to add proprietary patches to upstream Python packages. Regardless of the reason to have it, a local PyPi repository is relatively easy to configure.
You'll need to start with a base directory for your PyPi repository. For this example, I chose /var/pypi. The directory structure should look something like this:
/var/pypi/simple/[package_name]/[package_tarball]
For a package like pip, you'd make a structure like this:
/var/pypi/simple/pip/pip-1.0.2.tar.gz
Once you have at least one package stored locally, it's time to configure apache. Here's a snippet from the virtual host I configured:
The last set of rewrite directives check to see if the request refers to an existing file or directory under your document root. If it does, your server will reply with a directory listing or with the actual file to download. If the directory or file doesn't exist, apache will send the client a redirection to the main PyPi site.
Reload your apache configuration to bring in your new changes. Let's try to download the pip tarball from our local server in the example I mentioned above:
$ curl -I http://pypi.example.com/simple/pip/
HTTP/1.1 200 OK
$ curl -I http://pypi.example.com/simple/pip/pip-1.0.2.tar.gz
HTTP/1.1 200 OK
I've obviously snipped a bit of the response above, but you can see that apache is responding with 200's since it has the directories and files that I was trying to retrieve via curl. Let's try to get something we don't have locally, like kombu:
$ curl -I http://pypi.example.com/simple/kombu/
HTTP/1.1 302 Found
Location: http://pypi.python.org/simple/kombu/
Our local PyPi repository doesn't have kombu so it will refer our Python tools over to the official PyPi repository to get the listing of available package versions for kombu.
Now we need to tell pip to use our local repository. Edit ~/.pip/pip.conf and add:
Once your tools are configured, try installing a package you have locally and try to install one that you know you won't have locally. You can add -v to pip install to watch it retrieve different URL's to get the packages it needs. If you spot any peculiar behavior or unexpected redirections, double-check your mod_rewrite rules in your apache configuration and check the spelling of your directories under your document root.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
This is second part of article to describe how to dynamically manage Apache Virtual host. You can read first article here. 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 [...]
I'm using SELinux more often now on my Fedora 15 installations and I came up against a peculiar issue today on a new server. My PHP installation is configured to store its sessions in memcached and I brought over some working configurations from another server. However, each time I accessed a page which tried to initiate a session, the page load would hang for about a minute and I'd find this in my apache error logs:
[Thu Sep 08 03:23:40 2011] [error] [client 11.22.33.44] PHP Warning:
Unknown: Failed to write session data (memcached). Please verify that
the current setting of session.save_path is correct (127.0.0.1:11211)
in Unknown on line 0
I ran through my usual list of checks:
netstat showed memcached bound to the correct ports/interfaces
memcached was running and I could reach it via telnet
memcached-tool could connect and pull stats from memcached
double-checked my php.ini
tested memcached connectivity via a PHP and ruby script — they worked
Even after all that, I still couldn't figure out what was wrong. I ran strace on memcached while I ran a curl against the page which creates a session and I found something significant — memcached wasn't seeing any connections whatsoever at that time. A quick check of the lo interface with tcpdump showed the same result. Just before I threw a chair, I remembered one thing:
I'm far from being a guru on SELinux, so I leaned on audit2allow for help:
# grep memcache /var/log/audit/audit.log | audit2allow
#============= httpd_t ==============
#!!!! This avc can be allowed using one of the these booleans:
# httpd_can_network_relay, httpd_can_network_memcache, httpd_can_network_connect
allow httpd_t memcache_port_t:tcp_socket name_connect;
The boolean we're looking for is httpd_can_network_memcache. Flipping the boolean can be done in a snap:
After adjusting the boolean, apache was able to make connections to memcached without a hitch. My page which created sessions loaded quickly and I could see data being stored in memcached. If you want to check the status of all of the apache-related SELinux booleans, just use getsebool:
# getsebool -a | grep httpd | grep off$
allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_can_check_spam --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> off
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_read_user_content --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_tmp_exec --> off
httpd_unified --> off
httpd_use_cifs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off
If you're interested in SELinux, a good way to get your feet wet is to head over to the CentOS Wiki and review their
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
Звонит техподдержка, говорит что на одном из вебсерверов лежит апач. Ну дело не хитрое, рестарт и смотрим error_log. Тишина... всмысле вообще тишина ничего нет в логе. Ну делаем Loglevel debug и снова рестарт и снова в логе тишина и пара warn-ов не относящихся к делу.
Опытным путем выяснил что апач мрет на загрузке конфига с виртуалхостами, виртуалхостов на сервере чуть больше 3000, какой косячит? Как его найти если в логах ничего нет? strace ни на какие мысли не на талкивает.
Но специфика сервера такова что каждый вхост в отдельном конфиге, потом эти конфиги парсятся, правятся и сливаются в один файл. Вобщем переношу все конфиги вхостов в /root/tmp и по 100 штук начинаю возвращать на место и рестартить апач. Таким образом нахожу ОДНУ паршивую овцу. Лезу в конфиг и падаю со стула.
Для одного домена прописано 530 алиасов, у того же клиента смотрю другие домены, на втором прописано еще 370 алиасов. Судя по всему лимит у апача 512 алиасов, потом смерть.
И блять молчаливая смерть, ни строчки в логи!!
Вобщем так можно хостерам гадить, регаешься на самый дешевый тариф и набиваешь 600 алиасов. Всё апачу пездос.