Lab Notes: January 2013

January 27, 2013

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.

January 20, 2013

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).

January 13, 2013

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.

January 6, 2013

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.

Search