Trac on CentOS 6.3, Part 3

Now for the exciting conclusion of our three-part series on installing Trac on a 64-bit server running CentOS 6.3. In part 1 I installed some prerequisite software and Trac itself. In part 2, I installed and configured Apache as a front end to Trac. In part 3, I will configure Trac to use an Active Directory domain for authentication.

First a few notes about the server we are targeting. The server already has Samba installed and has been joined to the Active Directory domain. Users can log into the machine using their Active Directory accounts.

With that out of the way, we are ready to install mod_auth_ntlm_winbind for authentication. A big hat tip to the folks at http://www.geeklab.info/ for doing a lot of the heqavy lifting for me. See http://www.geeklab.info/2011/08/install-mod_auth_ntlm_winbind-on-centos-6-0/ for their excellent write up.

We need a few prerequisites:

yum install httpd-devel gcc autoconf

Processes that wish to use Samba and winbind for authentication need access to the /var/lib/samba/winbindd_privileged/ directory. The simplest solution to allow that access, is to add user apache to the group wbpriv:

usermod -G wbpriv apache

Furthermore we need to let the SELinux security infrastructure know that Apache is allowed to authenticate via winbind:

setsebool -P allow_httpd_mod_auth_ntlm_winbind on

There are no prebuilt binaries for mod_aut_ntln_winbind so we will need to download and compile it ourselves:

svn co svn://svnanon.samba.org/lorikeet/trunk/mod_auth_ntlm_winbind mod_auth_ntlm_winbind cd mod_auth_ntlm_winbind/ autoconf ./configure apxs -DAPACHE2 -c -i mod_auth_ntlm_winbind.c

Now the interesting part, configuring Apache. Make the following changes to /etc/httpd/conf/httpd.conf:

LoadModule auth_ntlm_winbind_module /usr/lib64/httpd/modules/mod_auth_ntlm_winbind.so KeepAlive On MaxKeepAliveRequests 1000 KeepAliveTimeout 600

Also add the following to /etc/httpd/conf.d/myproject.mydomain.tld.conf (if you have forgotten, this is the configuration file we created in part 2 to configure the virtual server for Trac):

<Location /login> Options ExecCGI AllowOverride None Order allow,deny Allow from all AuthName "Change to something meaningful" AuthType NTLM Require valid-user NTLMAuth on NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp" NTLMBasicAuthoritative on </Location>

All that is left is to restart Apache and you are good to go.

Your server is now all set up with Trac and configured in a manner that will easily allow you to add additional instances:

1. Initialize another Trac instance.
2. Copy (and edit) the /etc/httpd/conf.d/myproject.mydomain.tld.conf file.
3. Make a new directory under /var/www for the new virtual server
4. Export Trac resources using trac-admin deploy and copy them to the new web root.

Trac on CentOS 6.3, Part 2

Recently I had the need to set up a Trac instance on a 64-bit machine running CentOS 6.3. In part 1 I installed some prerequisite software and Trac itself. In part 2, I will be installing Apache as a front end to Trac. In part 3, I will configure Trac to use an Active Directory domain for authentication.

First we need to install Apache. We will be using WSGI within Apache to execute Trac’s python code. We will also need to open the firewall for HTTP traffic. Warning: Don’t mess with your firewall unless you know what you are doing. If your server has a GUI, there are straightforward GUI tools for opening the firewall for HTTP, use those instead of command line configurations below.

yum install httpd mod_wsgi # Set Apache to start on boot chkconfig httpd on # Open HTTP port on firewall # Figure out the value for line below by using the highest line number # output from "iptables -t INPUT -L --line-numbers"> line=aNumber iptables --insert INPUT $line \ --match state \ --state NEW \ --protocol tcp \ --destination-port 80 \ --source 172.26.245.0/24 \ --jump ACCEPT # Check that the firewall state is as you want it before saving! iptables -t INPUT -L --line-numbers # If your firewall is screwed up use "service iptables restart" to restore it # instead of saving it service iptables save

Now we will configure Apache with a virtual server for our Trac instance. First, comment out the NameVirtualHost directive in /etc/httpd/conf/httpd.conf. Then create a new file in /etc/httpd/conf.d called myproject.mydomain.tld.conf, where myproject.mydomain.tld is the domain name you want to use for the trac server. (The name of the file isn’t important, except for the .conf sufix, but a good naming scheme will make your life easier.) The contents should like like this:

<VirtualHost *:80> DocumentRoot /var/www/myproject.mydomain.tld/html ServerName myproject.mydomain.tld ErrorLog logs/myproject.mydomain.tld-error_log CustomLog logs/myproject.mydomain.tld-access_log common </VirtualHost>

Then create the root directory:

mkdir -p /var/www/myproject.mydomain.tld/html

This is a good point to make a dummy file in the directory (say index.html) and test the server:

echo '<html><body>Hello!</body></html>' >/var/www/myproject.mydomain.tld/html/index.html service httpd start wget http://myproject.mydomain.tld/index.html

At this point we are ready to export scripts and static resources from Trac and set permissions for Apache:

trac-admin /var/trac/myproject deploy /tmp/deploy mv /tmp/deploy /var/trac/myproject/deploy chown -R apache:apache /var/trac/myproject

Now we copy in the Trac WSGI script into Apache’s cgilib directory:

cp /var/trac/myproject/deploy/cgi-bin/trac.wsgi /var/www/cgi-bin/myproject.trac.wsgi

Then edit /etc/httpd/conf.d/myproject.mydomain.tld.conf and add the following within the virtual server definition:

WSGIScriptAlias /trac /var/www/cgi-bin/myproject.trac.wsgi <Directory /var/www/cgi-bin> WSGIApplicationGroup %{GLOBAL} Order deny,allow Allow from all </Directory>

Now if you restart Apache (service httpd restart) and browse to http://myproject.mydomain.tld/trac/, you will get the following error:

TracError: No Trac environment found at /var/trac/myproject [Errno 13] Permission denied: /var/trac/myproject/VERSION

Now we are getting into some CentOS 6 specific territory. The problem is that CentOS includes SELinux, which adds a much more detailed and configurable security structure on top of the standard Linux security infrastructure inherited from Unix. Fortunately the fix is easy, when you know what to do:

chcon -R -t httpd_sys_content_t /var/trac/myproject chcon -R -t httpd_sys_script_rw_t /var/trac/myproject setsebool -P httpd_can_network_connect on

Now you should be able to connect to your Trac instance at http://myproject.mydomain.tld/trac/.

Finally, we can map the static resources we exported.

cp -r /var/trac/myproject/deploy/htdocs /var/www/myproject.mydomain.tld/trac/

Edit /etc/httpd/conf.d/myproject.mydomain.tld.conf adding the following before the WSGIScriptAlias directive:

Alias /chrome/common /var/www/myproject.mydomain.tld/trac/htdocs/common Alias /chrome/site /var/www/myproject.mydomain.tld/trac/htdocs/site

In part 3, I will configure Trac to use an Active Directory instance for authentication.

Trac on CentOS 6.3, Part 1

Recently I had the need to set up a Trac instance on a 64-bit machine running CentOS 6.3. For CentOS and Red Hat 5, someone has done the hard work already and set up RPM files (see the Trac documentation on RHEL 5 and Dag Wieers RPM repository for details) making installing Trac as easy as yum install trac. Unfortunately, our benefactors have not gotten to RHEL 6 yet so I needed to do it myself.

I am using PostgreSQL for the Trac database. I will assume you already have PostgreSQL up and running. If you are using a different database backend, you should be able to follow along anyway.

First, we need to install some prerequisites:

yum install python-setuptools python-genshi python-pygments \ subversion-1.6.11-7.el6.i686

Note that the last package in the list there is the 32-bit version of subversion. This is necessary for the python subversion bindings. It is fine if you install (or have already installed) the 64-bit version of subversion as well. If you are not planning on using Trac with a subversion repository you can leave this out. If it bugs you to install 32-bit software on your 64-bit server, you could try to compile the python subversion bindings yourself using SWIG. (If you do and you blog about, let me know and I’ll link to it here.)

Next there are a couple of PostgreSQL-specific prerequisites, specifically the software that allows Python to talk to PostgreSQL:

yum install python-psycopg2 python-psycopg2-doc

Now we can finally start installing Trac and the pieces that go with it. I hit an issue with the latest version of Genshi (as of this writing) and had to force it to use version 0.6.

easy_install Genshi==0.6 easy_install Trac

Next we create initialize a Trac project. You will be prompted for the name and the database connection string. For PostgreSQL, use postgres://username:password@server:5432/database?schema=schema, replacing the initialized values.

mkdir -p /var/trac/myproject chmod -R 775 /var/trac trac-admin /var/trac/myproject initenv

Finally we can connect Trac to our Subversion repository. Edit /var/trac/myproject/conf/trac.ini:

[components] tracopt.versioncontrol.svn.* = enabled [trac] repository_dir = /path/to/svn/repository

In part 2, we set up Apache as a front-end and handle some SELinux issues. In part 3, we configure Trac to authenticate against an Active Directory domain (assuming the server has Samba installed and configured to be part of the domain).

SVN: E200031: attempt to write a readonly database

Just a quick and dirty note to solving the following error from Subversion:

SVN: E200031: attempt to write a readonly database.

I found the answer on Tor Henning Uelands blog under the post http://h3x.no/2010/12/04/svn-gives-attempt-to-write-a-readonly-database-error. The solution was to fix the permissions on the db/rep-cache.db file in the subversion repository. See his blog if you need more details. Thanks Tor.

Nvidia Overscan in Ubuntu 12.10

A few weeks ago I upgraded my HTPC to Ubuntu 12.10 and was treated to a nasty surprise: the overscan settings for the nvidia driver were no longer recognized. The HTPC is connected to my television (naturally) which is a 40" LG LCD HDTV. If you have ever tried to connect your PC to an HDTV before, you probably encountered the problem of that the visible portion of the screen is smaller than the drawable portion of the screen. The result is that the edges of the screen are not visible. In my case that meant the dash and the universal menu of Unity could not be seen. That makes for a less than usable experience.

In the past nvidia included an overscan setting slider in the GUI configuration tool (nvidia-settings). When I opened it up however, the setting was nowhere to be found. A short time on google confirmed the worst: nvidia had removed the setting.

The good news is that the setting can be twiddled via the command line. Then, once you find the magic numbers that work with your particular graphics card and monitor, you can put them in your .nvidia-settings-rc file to automatically apply them on login. Also, the command is safe: if you try something that would push the screen too far, the driver simply ignores it.

The first step is to run the command with a bunch of values until you find the values that work best:

nvidia-settings --assign 0/CurrentMetaMode="DFP-0: 1280x720 { ViewPortIn=12 80x720, ViewPortOut=1190x680+44+20 }"

The first set of numbers, the ViewPortIn and the value before that, are determined by the native resolution of your HDTV. Mine is a 720p, so the native resolution is 1280x720. The next set of numbers, the ViewPortOut, are the ones you will want to experiment with. They are telling the driver how to transform the viewport so the screen ends up in the visible area of the HDTV. The first part, the 1190x680, indicates how much to scale the viewport. The second part, +44+20, indicates how much to shift the image.

Once you have the values you want, edit your ~/.nvidia-settings-rc file adding the following at the end:

0/CurrentMetaMode=DFP-0: 1280x720 { ViewPortIn=1280x720, ViewPortOut=1190x680+44+20 }

Obviously you will want to use the correct values for your system.

Ubuntu 12.10: Connect to Microsoft VPN

I recently upgraded to Ubuntu 12.10 on my main desktop machine from scratch, which means a number of things which had been installed and configured need to be re-done. One of those things is my VPN connection to work, which runs Windows 2008 Server for VPN.

If you have ever tried to configure a linux machine to connect to a Microsoft-based VPN, you know that it is not as straightforward as it could be. It is more of a voodoo ritual than a science. I figured it would be a good idea to capture the steps for future reference.

This first part is adapted from the Ubuntu Wiki for posterity. You can check out the original at https://wiki.ubuntu.com/VPN under the heading VPN setup in Ubuntu 9.10. Apparently this originates from a Ubuntu forums post by user sweisler at http://ubuntuforums.org/showpost.php?p=8261958&postcount=6. Thanks sweisler, wherever you are.

First, there was no need to install any additional packages, apparently everything needed is included by default.

• Open VPN configuration screen:
  • Click on the network icon in the upper right of the desktop
  • Go to the VPN Connections menu
  • Select Configure VPN…
• Add a new PPTP connection
• On the VPN tab, set the following:
  • Connection name (whatever you want)
  • Uncheck Connect automatically (you can change this later)
  • Gateway (this is the VPN server)
  • User name (for domain-based user accounts, use domain\username)
  • Do not set Password; do change the pulldown to Always Ask
  • Do not set NT Domain
  • Uncheck Available to all users (this works either way, but I am assuming you don’t really want your kid to have access to the VPN)
• PPTP Advanced Options (Advanced button from the VPN tab)
  • Uncheck all authentication methods except MSCHAPv2
  • Check Use Point-to-Point encryption (MPPE)
  • Leave Security set at All Available (Default)
  • Check Allow stateful inspection
  • Uncheck Allow BSD data compression
  • Uncheck Allow Deflate data compression
  • Uncheck Use TCP header compression
  • Uncheck Send PPP echo packets (this setting works either way, check it for debugging purposes)

At this point save it and test it. Once the VPN connection is working you may want to try to tweak it further as described below.

One problem with the VPN I connect to is that all traffic ends up using the VPN when I am connected. This is less than ideal if you are connecting to servers on the internet while the VPN is connected since the traffic goes through the VPN server before coming to you. The following describes the settings for routing only the proper traffic to the VPN. (Read them all the way through first to make sure you have all the necessary information.)

• On the IPv4 Settings tab
  • Set Additional DNS servers using the IP address of the DNS server for the VPN. (You may need to ask your IT guy for this; there should be a way to discover it when connecting as above but it escapes me.)
  • Set Additional search domains. Set this to the domain suffix of the machines on the VPN. For example, if the machines like dbserver.example.com then set it to example.com.
• Click the Routes button.
  • Check Use this connection only for resources on its network
  • Add a route:
    • For Address, use the internal IP address of the VPN server applied against the netmask below, e.g. if the VPN server is 10.0.0.10 and the netmask is 255.255.255.0, use 10.0.0.0 (this is different in 14.04, in the past one could just use the IP of the VPN server). Again, this should be the internal IP address for getting to the machine in the intranet, not the external IP address for getting to the machine from the internet.
    • For Netmask, use the netmask of your intranet. (If you are confused, ask your IT guy what to use for both this and the Address.) For most networks this will be 255.255.255.0, but for many it will be different.
    • For Gateway, use the external IP address of the VPN server. This should match the Gateway defined on the VPN tab. (I’m not sure what happens if you are using a server name there. I suspect you should match the names, but you may need to experiment.)
    • Do not set the Metric unless you know what you are doing.

OK, so now when you connect you should see regular traffic going directly to the internet and intranet traffic directed to the VPN server. You can test this out with traceroute (which you may need to install). You should also be able to refer to machines on the intranet using their short names (e.g. dbserver instead of dbserver.example.com).

Let me know how these instructions work for you and what type of systems you’ve been able to connect.

Ubuntu 12.10: Minidlna on Boot

A big hat tip to Asaf Shahar for this one.

I recently upgraded to Ubuntu 12.10 on my main desktop machine from scratch, which means a number of things which had been installed and configured need to be re-done. One of those things is minidlna, a lightweight DLNA server.

If you don’t know, DLNA is a protocol for sharing media to devices. In my case, I use it to stream music, video and pictures from my desktop to my Blu-Ray player. It’s not perfect, at least in that the interface on the Blu-Ray player leaves much to be desired, but it works.

Minidlna does not come standard with Ubuntu, but it is in the repositories and installation is as easy as sudo apt-get install minidlna. Afterwards you configure /etc/minidlna.conf and you are good to go. The comments inside /etc/minidlna.conf are good enough that you won’t need further guidance from me here.

While all that was relatively painless, I soon discovered that minidlna was not starting on reboot. I checked the script in /etc/init.d and the symlinks in the various /etc/rc#.d/ directories and everything was correct. It started no problem by hand after boot using sudo service minidlna start. It was time to take the fight to google.

I quickly discovered a bug report that seemed appropriate. Apparently minidlna is attempting to start before networking is up and that causes it to error out. (If you have changed to Ubuntu 12.10 you may have noticed that networking does not start until after the login screen is displayed — a curious decision.)

If you have taken a look at the bug report, you’ll see a work-around posted by Asaf Shahar. He created a script using upstart to transform minidlna into a service managed by that tool.

I wasn’t quite convinced that was the answer for me, because that solution would skip whatever set up occurs in the /etc/init.d/minidlna script. At first I thought I could change his upstart script to simply invoke the minidlna script instead of the executable, but upstart was not created with that use in mind. (When creating an upstart service, upstart expects the executable to fork 1 or 2 times; a script will fork a great number of times and there is no way to tell upstart which process is actually the server process.)

The next natural solution would be to integrate the /etc/init.d/minidlna script into Shahar’s upstart script. But that would mean keeping the script up to date whenever the /etc/init.d/minidlna script changed. That’s not really something I want to have to do; after all I might even miss the fact that minidlna was updated. So another solution was needed.

In the process of researching upstart I discovered that one can use it for more than just servers. It can also execute a task (i.e. a short-lived process expected to finish on its own). I decided to have upstart run the minidlna script once the machine booted and networking was enabled. Now this is not perfect in that minidlna is still trying to start and failing on the normal boot process, but I can live with that.

To do this, create a file called /etc/init/start-minidlna.conf with the following contents:

# Task to start Minidlna - lightweight DLNA/UPNP media server # Minidlna is not starting correctly on boot, see bug # https://bugs.launchpad.net/ubuntu/+source/minidlna/+bug/1053173 # description "Task to start minidlna" start on (local-filesystems and net-device-up IFACE!=lo) task exec service minidlna start

That’s all there is to it. Now minidlna starts on boot. Once again I want to thank Asaf Shahar for his help.