Proxy Settings pushed by GPO not applying to Windows 7 and Internet Explorer 9

I support a Windows 2003 Active Directory Domain, until today only Windows XP clients and Internet Explorer 8.

We use a proxy server to filter and monitor the internet and we push the configuration for that proxy server via Group Policy. Our current GPO works perfectly with Windows XP and Internet Explorer 8.

Today we got our first Windows 7 client and I noticed the proxy settings from our Windows 2003 Active Directory Domain were not applying top the Windows 7 machine running Internet Explorer 9.

It turned out there were two reasons the settings were not applying. The first is a no brainer. I hadn’t updated my Internet Explorer Group Policy Administrative Template to support Internet Explorer 9. That was easy enough to fix by going here and updating my Administrative Template.

After updating the Administrative Template I figured I’d be done. Turns out I was wrong. I ran ‘rsop.msc’ and ‘gpresult /r’ and both showed the proxy settings were being applied but Internet Explorer wasn’t using our proxy server.

Turns out there was a second problem and it was FAR more difficult to figure out. I did some research and found others complaining about this problem. Removing proxy settings for ‘GOPHER’ from their Internet Explorer GPO resolved the problem for the majority of these users. To remove GOPHER settings open up your group policy and make the following tweak:

User Configuration
  Windows Settings
    Internet Explorer Maintenance
        Proxy Settings
          Uncheck 'Use the same proxy server for all addresses'
          Delete any settings for Gopher and SOCKS

This didn’t solve the problem for me but it may have had a hand in it.

The second thing I had to do in my case was to disable caching of auto-proxy scripts and disable changing automatic configuration settings. My understanding from the post I read was that the cache can become corrupt and cause a bunch of problems. To make this change open up your Internet Explorer GPO again and make the following changes:

User Configuration
  Administrative Templates
    Windows Components
      Internet Explorer
        Disable caching of Auto-Proxy scripts: ENABLED
        Disable changing Automatic Configuration settings: ENABLED

Once I’d made both of those tweaks I ran a quick ‘gpupdate /force’ and that was it! Things started working properly.

There seems to be a bug in Internet Explorer 9, or at least the version I’m running, where if you go into the proxy settings under ‘Internet Options’ you won’t actually see your proxy servers name in the ‘Address:’ box. I’ll see if that clears up once I get Windows Updates working on these Windows 7 machines or when we get to Internet Explorer 10.


How to upgrade Gitlab 5.1 to 5.2 on CentOS 6 or RHEL6

Last modified: [last-modified]

This document assumes you’ve followed my previous post for deploying Gitlab on CentOS 6/RHEL6 and have already upgraded that deployment from 5.0 to 5.1.

If you haven’t already switched from the default version (1.7.1) of git that comes with CentOS 6 / RHEL6 to git please follow this post first before continuing with these instructions. Even if you don’t care about that error message follow the instructions so you’re using git instead of 1.7.1.

Now then. Lets get to it.

1. Stop gitlab and switch to sa_gitlab

[[email protected] ~] service gitlab stop
[[email protected] ~] ps aux |grep git
[[email protected] ~] su - sa_gitlab


2. Get the latest code for Gitlab and Gitlab-shell

[[email protected] ~] cd gitlab
[[email protected] gitlab] git fetch

# If you get an error about schema.rb run these two commands and then re-run 'git checkout 5-2-stable'. Otherwise skip these two commands (it won't hurt anything if you run them though)
[[email protected] gitlab] cp db/schema.rb db/schema.rb.current
[[email protected] gitlab] git stash

[[email protected] gitlab] git checkout 5-2-stable
[[email protected] gitlab] cd ..
[[email protected] ~] cd gitlab-shell/
[[email protected] gitlab-shell] git fetch
[[email protected] gitlab-shell] git checkout v1.4.0


3. Install libs, migrations, etc? (I stole this from the Gitlab guys)

[[email protected] gitlab-shell] cd ..
[[email protected] ~] cd gitlab
[[email protected] gitlab] bundle install --without development test postgres --deployment
[[email protected] gitlab] bundle exec rake db:migrate RAILS_ENV=production


4. Switch back to root and update the init script

[[email protected] gitlab] exit
[[email protected] ~] mv /etc/init.d/gitlab /etc/init.d/gitlab.51
[[email protected] ~] wget "" -O /etc/init.d/gitlab
[[email protected] ~] vim /etc/init.d/gitlab

# -------- Make the following edits --------


# -------- Save and close the file --------

[[email protected] ~] chmod 755 /etc/init.d/gitlab


5. Start up Gitlab

[[email protected] ~] service gitlab start


You should be good to go at this point. The first load took a while for me after the update.



Commit comments not appearing in Gitlab on CentOS

Last modified: [last-modified]

If you followed my earlier documentation, or simply installed Gitlab yourself on CentOS 6 you might run into this problem:

When you go to the ‘Files’ view of one of your repositories it won’t load any of the commit comments. It just appears to perpetually load.

If you look in your ‘production.log’ you’ll see an error like this:

Processing by RefsController#logs_tree as JS
  Parameters: {"_"=>"1369162443960", "project_id"=>"USERNAME/geoip-lookup", "id"=>"master"}
  Rendered refs/logs_tree.js.haml (57.2ms)
Completed 500 Internal Server Error in 98ms

ActionView::Template::Error (undefined method `committed_date' for nil:NilClass):
    5:   :plain
    6:     var row = $("table.table_#{@hex_path} tr.file_#{hexdigest(file_name)}");
    7:     row.find("td.tree_time_ago").html('#{escape_javascript time_ago_in_words(commit.committed_date)} ago');
    8:     row.find("td.tree_commit").html('#{escape_javascript render("tree/tree_commit_column", commit: commit)}');
  app/views/refs/logs_tree.js.haml:7:in `block in _app_views_refs_logs_tree_js_haml__4074553552003765415_53128340'
  app/views/refs/logs_tree.js.haml:1:in `each'
  app/views/refs/logs_tree.js.haml:1:in `_app_views_refs_logs_tree_js_haml__4074553552003765415_53128340'

It looks like this is a bug with git itself and not Gitlab.

There is a patch you can manually apply to your Gitlab deployment OR you could just upgrade git to the latest and greatest version. I chose to upgrade git. The below guide assumes you followed my original “How to install Gitlab 5.0 on CentOS 6 or RHEL6” guide. I’ve updated that guide to reflect these new steps.

1. Get logged in to your server and become ‘sa_gitlab’

[[email protected] ~] su - sa_gitlab
[[email protected]~]


2. Create a temp directory if you don’t have one and move into it

[[email protected]~] mkdir temp
[[email protected]~] cd temp


3. Download the latest source for git from As of this writing is the latest version

[[email protected]~] wget -c
[[email protected]~] tar -xf git-
[[email protected]~] cd git-


4. Configure, compile and install git

[[email protected]~] ./configure --prefix=/data/apps/sa_gitlab/git
[[email protected]~] make
[[email protected]~] make install


5. Configure your environment so the new version of git overrides the default CentOS version

[[email protected]~] vim ~/.bashrc

# -------- Make the following edits --------

# Change the PATH line to look like this:

# -------- Save and close the file --------

[[email protected]~] vim ~/.bash_profile

# -------- Make the following edits --------

# Change the PATH line to look like this:

# -------- Save and close the file --------


6. Re-export your path and verify which git is being used and it’s version

[[email protected]~] PATH=$HOME/git/bin:$HOME/ruby/bin:$PATH:$HOME/bin;

[[email protected]~] which git

[[email protected] ~] git --version
git version


7. Update your gitlab.yml configuration file

[[email protected] ~] cd gitlab
[[email protected] gitlab] vim config/gitlab.yml

# -------- Make the following edits --------

    bin_path: /data/apps/sa_gitlab/git/bin/git

# -------- Save and close the file --------


8. Restart Gitlab

[[email protected] gitlab] exit

[[email protected] ~] service gitlab stop

# Wait 1-2 minutes for everything to exit

[[email protected] ~] service gitlab start


That’s it!

Update May 22nd, 2013 – Added step 7. Didn’t realise you had to edit the gitlab.yml file to point to the new git binary location. I assumed Gitlab used the git binary it found via PATH.

How to configure Mediawiki to authenticate against Active Directory on CentOS

Last modified: [last-modified]

This assumes you’ve got a working install of MediaWiki already and just need to tie it into Active Directory.

1. Make sure php-ldap is installed

yum install php-ldap.x86_64

2. Configure OpenLDAP on CentOS to ignore your domain controllers certificate validity. We all trust our own domain controllers don’t we?

vim /etc/openldap/ldap.conf

# -------- Make the following edits --------

 TLS_REQCERT     never

# -------- Save and close the file --------

3. Download and extract the latest LDAPAuthentication extension into your ‘mediawiki/extensions’ directory. I’m going to assume you’ve named the extension directory ‘ldapauthentication’ for the remainder of this documentation.

4. Edit your ‘LocalSettings.php’ found in the root of your MediaWiki directory and add the following substituting the values for your own domains information. Make sure you consistently use the same value for “<YOURDOMAINNAME>” at the start of each “array (” line.

vim LocalSettings.php

# -------- Make the following edits --------
require_once( "$IP/extensions/ldapauthentication/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array( "<YOURDOMAINNAME>" );

# I recommend using a Global Catalog server for this.

$wgLDAPSearchStrings = array( "<YOURDOMAINNAME>" => "<YOURDOMAINNAME>\\USER-NAME" );
$wgLDAPEncryptionType = array( "<YOURDOMAINNAME>" => "tls" );
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;

$wgLDAPBaseDNs = array( "<YOURDOMAINNAME>" => "dc=<YOURDOMAIN>,dc=<SOMEPLACE>,dc=<COM>" );
# Example: If your domain is then you want to put in "dc=mydomain,dc=internet,dc=ca".

$wgLDAPSearchAttributes = array( "<YOURDOMAINNAME>" => "sAMAccountName" );
$wgLDAPRetrievePrefs = array( "<YOURDOMAINNAME>" => "true" );

$wgLDAPPreferences = array('<YOURDOMAINNAME>' => array( 'email' => 'mail','realname' => 'displayname'));
# This will automatically map the users e-mail address and full name from Active Directory to their account in MediaWiki

$wgLDAPDebug = 3; //for debugging LDAP
$wgShowExceptionDetails = true; //for debugging MediaWiki

# -------- Save and close the file --------

That should be it! If it’s not working check your log files.