Featured Posts

SciPy 2008 - Software & Tools STATUS: Day 1 - Thursday: Concluded. Day 2 - Friday: In progress. Astronomy: Enzo [ home ] yt (related to Enzo) [ home | scipy ] Books: Computational Modeling and Complexity Science...


An example of checking out a git tag using Qt 4.6.0... Clone the Qt repository: $ git clone git://gitorious.org/qt/qt.git Show available tags: $ git tag -l output: v4.5.1 v4.5.2 v4.5.3 v4.6.0 v4.6.0-beta1 v4.6.0-rc1 v4.6.0-tp1 Checkout v4.6.0: $...


Building 64-bit/32-bit Debug&Release Universal Build... See my directions on checking out Qt 4.6.0 from the git repository if you do not already have the source code. Launch a Terminal and cd to the source directory. Run configure w/ 64-bit & 32-bit...


  • Prev
  • Next

NX> 147 Server capacity: reached for user: – FIX

Posted on : 31-05-2012 | By : Brandon W. King | In : Computers/IT, Error Fixes, Linux, Mac OS X, Systems Administration



If you get this wonderful NX error message and are looking to fix things, I believe I have the solution:

NX> 203 NXSSH running with pid: 19955

NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: <ip address> on port: 22
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
HELLO NXSERVER – Version 3.2.0-73 OS (GPL, using backend: not detected)
NX> 105 hello NXCLIENT – Version 3.2.0
NX> 134 Accepted protocol: 3.2.0
NX> 105 login
NX> 101 User: <user>
NX> 102 Password:
NX> 103 Welcome to: <host> user: <user>
NX> 105 listsession –user=”<user>” –status=”suspended,running” –geometry=”2560x1024x24+render” –type=”unix-kde”
NX> 127 Sessions list of user ‘<user>’ for reconnect:
Display Type             Session ID                       Options  Depth Screen         Status      Session Name

——- —————- ——————————– ——– —– ————– ———– ——————————

NX> 147 Server capacity: reached for user: <user>
NX> 105 startsession  –link=”adsl” –backingstore=”1″ –encryption=”1″ –cache=”128M” –images=”512M” –shmem=”1″ –shpix=”1″ –strict=”0″ –composite=”1″ –media=”0″ –session=”<session>” –type=”unix-kde” –geometry=”2560×976″ –client=”linux” –keyboard=”pc105/us” –screeninfo=”2560x976x24+render”

NX> 599 Server capacity: reached for user: <user>
NX> 500 ERROR: Last operation failed.
NX> 105 NX> 280 Exiting on signal: 15


  1. ssh onto the system
  2. use top or ps to find nxagent (and maybe nx*) for your user
  3. kill those processes
  4. log in with nx

Building 64-bit/32-bit Debug&Release Universal Build of Qt 4.6.0 on Mac OS X 10.6 (Snow Leopard)

Posted on : 08-12-2009 | By : Brandon W. King | In : Compiling Code, Computers/IT, Mac OS X, Software Development/Engineering

Tags: , , , ,


See my directions on checking out Qt 4.6.0 from the git repository if you do not already have the source code.

Launch a Terminal and cd to the source directory.

Run configure w/ 64-bit & 32-bit + debug & release using cocoa and frameworks:

$ ./configure -arch “x86 x86_64″ -debug-and-release -opensource -framework -cocoa

Run make:

make -j <number_of_processor_cores>



Go away for a long time (many hours); watching a tea-pot boil many times over will be less painful than watching this process.


sudo make install

You should find the installed build in /usr/local/Trolltech/Qt-4.6.0/. I hope this is helpful.

Django App + mod_fcgid + Apache 2 Setup on Mac OS X & Debian/Ubuntu Linux

Posted on : 31-01-2008 | By : Brandon W. King | In : Computers/IT, Error Fixes, Mac OS X, Systems Administration

Tags: , , , , , , , , , ,


Update 2008Feb11:

From rather obscure comment from ‘apt-cache show python-flup’ on a Debian system, I discovered that flup has been superseded by http://www.modwsgi.org/. It is probably worth checking out mod_wsgi instead of mod_fcgid for Python web applications. Based on the documentation for mod_wsgi integration with Django, I am planning on switching. I will post my results in a future post.

Required Software


Download Source and Install

For reference, here is the mod_fcgid INSTALL.txt… see my Mac OS X notes below it for changes required to get it working on Mac OS X 10.5 (Leopard):

NOTE: This module is for Apache2 ONLY

UNIXIt's tested on my RedHat8 and Solaris. But it should work on other *NIX platform.NOTE: This module MUST run on share memory supported system

1. If your Apache2 installation isn't in /usr/local/apache2, please edit Makefile and correct it2. cd $mod_fcgid_dir3. make   //in Mac you need Xcode tools, optional install on Install CD4. make install5. add the following line in httpd.conf

LoadModule fcgid_module modules/mod_fcgid.so

MAC OS X Notes

  • In Mac OS X Leopard, the Makefile needs to be changed from /usr/local/apache2 to /usr/share/httpd, then steps 3 and 4 above should work.
  • Step 4 requires: sudo make install
  • Step 5, you need to add the following to /etc/apache2/httpd.conf: LoadModule fcgid_module libexec/apache2/mod_fcgid.so
  • IMPORTANT: apache 2 on Mac OS X Leopard is 64-bit and by default, the make file does not build the 64-bit module. To do this, you need to add the following to the Makefile after the EXTRA_CFLAGS option (too far above that will cause it not to work apparently):
CFLAGS = -arch ppc -arch ppc64 -arch i386 -arch x86_64

The above will make a universal binary for all Mac OS X.

If at some point, you get this message either in the error_log or by running ‘apachectl configtest’

httpd: Syntax error on line 117 of /private/etc/apache2/httpd.conf: Cannot load/usr/libexec/apache2/mod_fcgid.so into server:dlopen(/usr/libexec/apache2/mod_fcgid.so, 10): no suitable image found.Did find: /usr/libexec/apache2/mod_fcgid.so: mach-o, but wrong architecture

Then your mod_fcgid.so module probably was not built with x86_64 architecture… To check, type

file /usr/libexec/apache2/mod_fcgid.so

And it should list the architectures that the mod_fcgid.so was built for.

Enable mod_fcgid


At least with Debian/Ubuntu you can enable fcgid by typing (as root):

a2enmod fcgid

Mac OS X Leopard (10.5)

Add the following to /etc/apache2/httpd.conf:

AddHandler    fcgid-script .fcgiSocketPath    /tmp/fcgid_sockSharememPath  /tmp/fcgid_shmIPCConnectTimeout 20


We need to tell apache for what urls it should pass off the request to the fcgi script. This is accomplished with mod_rewrite which is normally turned on by default w/ apache 2 (at least the installations I have seen).

We’ll start with the full setup required for gaworkflow.frontend, but test it with a “Hello World” style dispatch.fcgi script.

gaworkflow.frontend apache2 mod_rewrite setup


Add the following to your apache2 /etc/apache2/sites-available/default or other vhost specific file:

# Enable access to the django admin mediaAlias /media /usr/lib/python2.5/site-packages/django/contrib/admin/media

# Turn on the rewrite engineRewriteEngine on

# Enable http:///admin/ and related urlsRewriteRule ^/admin(.*)$ /usr/lib/cgi-bin/dispatch.fcgi/admin$1 [QSA,L]RewriteRule ^/logout(.*)$ /usr/lib/cgi-bin/dispatch.fcgi/logout$1 [QSA,L]RewriteRule ^/login(.*)$ /usr/lib/cgi-bin/dispatch.fcgi/login$1 [QSA,L]

Mac OS X Leopard

Add the following to your apache2 /etc/httpd.conf:

# Enable access to the django admin media# NOTE: the following did not work for me... I had to copy the media directory to#    /Library/WebServer/Documents/media#Alias /media /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/admin/media/

# Turn on the rewrite engineRewriteEngine on

# Enable http:///admin urlsRewriteRule ^/eland_config(.*)$ /Library/WebServer/CGI-Executables/dispatch.fcgi/eland_config$1 [QSA,L]RewriteRule ^/admin(.*)$ /Library/WebServer/CGI-Executables/dispatch.fcgi/admin$1 [QSA,L]RewriteRule ^/logout(.*)$ /Library/WebServer/CGI-Executables/dispatch.fcgi/logout$1 [QSA,L]RewriteRule ^/login(.*)$ /Library/WebServer/CGI-Executables/dispatch.fcgi/login$1 [QSA,L]

Restart Apache 2

Linux (Debian/Ubuntu)

sudo /etc/init.d/apache2 restart

Mac OS X Leopard

sudo apachectl restart


Hello World Test

Now to test that we have the mod_fcgid setup properly, create a file called dispatch.fcgi:


def myapp(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return ['Hello World!\n']

if __name__ == '__main__': from flup.server.fcgi import WSGIServer WSGIServer(myapp).run()

And move it to your cgi-bin directory:

Linux cgi-bin

sudo mv dispatch.fcgi /usr/lib/cgi-bin/

Mac OS X Leopard cgi-bin

sudo mv dispatch.fcgi /Library/WebServer/CGI-Executables/

Linux/Mac OS X File Permissions

sudo chmod a+x /dispatch.fcgi

Mac OS X 10.5 users will need to update the Options for to include +ExecCGI… by default it is set to “Options None”. The updated entry should look like:

 AllowOverride None Options +ExecCGI Order allow,deny Allow from all

WARNING: You will get a message saying “Forbidden” in the web browser if you do not update the directive above.

Web Browser Test

Point your web browser to http://localhost/admin/ and you should see if it prints “Hello World!”. If you see “Hello World!” continue to the next section.

Installing the Django App dispatch.fcgi script

copy of mydjangoapp code

Make a copy of the mydjangoapp code and database and put it in a location that will be the “live” version of the code/database. On Mac OS X, I choose /Library/WebServer/mydjangoapp. Initialize the database like your normally would, but you will need to update the settings.py module so that DATABASE_NAME is an absolute path, otherwise you will get errors in the apache 2 error_log saying that the python code could not connect to the database. Assuming you also choose /Library/WebServer/mydjangoapp, your DATABASE_NAME variable in settings.py should be:

DATABASE_NAME = '/Library/WebServer/mydjangoapp/mydjangoapp.db'

You will also need to update the settings.py TEMPLATE_DIRS to be an absolute path (relative paths don’t work for some reason) of “/Library/WebServer/gaworkflow/templates”… so the update version should look like:

TEMPLATE_DIRS = ( "/Library/WebServer/mydjangoapp/templates",)

Also, you will need to make a link to the admin templates in our /Library/WebServer/mydjangoapp/templates directory by typing:

Mac OS X 10.5:

ln -s /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/admin/templates/admin /Library/WebServer/mydjangoapp/templates/adminln -s /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/admin/templates/admin_doc /Library/WebServer/mydjangoapp/templates/admin_docln -s /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/admin/templates/widget /Library/WebServer/mydjangoapp/templates/widgetln -s /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/admin/templates/registration /Library/WebServer/mydjangoapp/templates/registration

Warning: The following directions will tell you how to get past the db read/access errors but may not be the best choice for security… you consider the possible security issues before following the following instructions.

To get the dispatch.fcgi to work properly, I needed to change ownership of /Library/WebServer/mydjangoapp to be owned by the apache2 user, which is _www on Mac OS X 10.5 and www-data on Debian/Ubuntu systems. The the apache user also needs access to the mydjangoapp.db as well. I ran the following commands on Mac OS X 10.5 when placing the files in /Library/WebServer/gaworkflow:

sudo chown _www:_www /Library/WebServer/mydjangoappsudo chown _www:_www /Library/WebServer/mydjangoapp/mydjangoapp.dbsudo chmod o-rwx /Library/WebServer/mydjangoapp/mydjangoapp.dbsudo chmod ug+rwx /Library/WebServer/mydjangoapp/mydjangoapp.db

new dispatch.fcgi

Replace the hello world dispatch.fcgi with the following script:

#!/usr/bin/python                                                            import syssys.path += ['/Library/WebServer/mydjangoapp']from flup.server.fcgi import WSGIServerfrom django.core.handlers.wsgi import WSGIHandlerimport osos.environ['DJANGO_SETTINGS_MODULE'] = 'mydjangoapp.settings'WSGIServer(WSGIHandler()).run()

You will need to update these two rows:

  • sys.path += [‘/Library/WebServer/mydjangoapp’]
  • os.environ[‘DJANGO_SETTINGS_MODULE’] = ‘mydjangoapp.settings’

Where ‘/Library/WebServer/gaworkflow should be replaced by PYTHONPATH that would allow your Django package to be imported… one directory level below the directory containing init.py.

NOTE: Make sure you dispatch.fcgi is executable:

sudo chmod a+x dispatch.fcgi

If everything worked out properly, you should have a working installation of gaworkflow.frontend using mod_fcgid.

Trouble Shooting

  • Check apache error logs.
  • run: sudo apachectl configtest
  • Check that dispatch.fcgi has #!/usr/bin/python and not #!/usr/bin/env python as that will screw up the environment variables at least w/ Apache 2 that ships on Mac OS 10.5.
  • run ‘python dispatch.fcgi’ to see if you get any standard Python errors.

Apache2 – error_log — [warn] mod_fcgid: stderr: OperationalError: unable to open database file

This means the database is not accessible by the user that is running apache. On Mac OS X 10.5, the user is _www. On Debian/Ubuntu Linux the user is www-data. See the “copy of gaworkflow code” section above for directions on changing file permissions for the database.

Tri-boot WinXP / Windows Vista / Ubuntu Linux

Posted on : 22-11-2006 | By : Brandon W. King | In : Computers/IT, Error Fixes, Linux, Mac OS X, Windows

Tags: , , ,


I now have WinXP, Windows Vista RC1, and Ubuntu/Kubuntu Linux tri-booting on my laptop. A key to success if you are going to attempt this is the order of installation:

  1. Windows XP
  2. Windows Vista
  3. Linux

If you install Windows Vista first, Windows XP’s boot loader won’t find Vista, and if you try to do a repair on Vista, WinXP won’t be found. There may be a way to fix this, but it’s easier just to install in the order listed above.

When Linux installs grub, at least with Ubuntu, it automatically finds the Vista boot loader. When you select the Vista option from grub, the Vista boot loader should have two options “Run previous version of windows” (i.e. WinXP) or “Run Vista”.

I hope this saves you some time.

Open Source Network Backup Software: Bacula

Posted on : 29-08-2006 | By : Brandon W. King | In : Computers/IT, Linux, Mac OS X, Software Endorsements, Systems Administration, Windows

Tags: ,


After getting tired of maintaining and updating a custom Python based backup network script that used smbclient to backing up WinXP machines using samba, I decided to look into open source solutions. I found two high-end open source network based backup solutions that handle WinXP, Mac OS X, and Linux machines:

AMANDA has it’s advantages, including paid enterprise support through Zmanda, which maybe be important to people in the business world.

The main reason why I choose bacula is because AMANDA uses samba for connecting to WinXP clients and I have one pesky WinXP box which came with some high-end biology equipment and therefore the company we bought it from decided to mangle WinXP enough that samba from Linux won’t connect to it. And for the fear of bringing down an important piece of biology equipment, I have decided to not mess with that machine more than I need to. Bacula runs a file daemon (a.k.a. ‘service’ for you Windows users) which gets me past the samba problem. So, if you were looking here for me to tell you which one is better, I really don’t know. I haven’t tried AMANDA yet.

The other feature that really sold me is the Python scripting ability built into Bacula for extending the backup process.

Bacula seems to work great… Although the big test will be coming in next day to three months. I just finished setting up a bacula server and 7 clients… 6 WinXP clients and 1 Kubuntu client.

Quick overview:
Bacula consists of three daemons:

  1. director (runs the show)
  2. storage (manages storage pools & volumes: disk, tape, DVD, etc.)
  3. file (client side backup daemon/service)

What’s confusing about bacula at first is it’s concept of ‘pools’ and ‘volumes’. My original thought was that ‘pools’ and ‘volumes’ were meant for tape drives and that I would only need one pool with one volume since I wanted to use file based storage on a raid-5 hard drive setup. As it turns out, it is convenient to use different pools for full, incremental, and differential backups. Also, within a pool, by putting multiple volumes (i.e. multiple disk files for it to write the backups to), you can set it up to recycle used volumes after a set amount of time! What does this mean for me… If I have enough hard drive space, it will just reuse the space over and over again. If everything is going well, I won’t have to worry about backups. Automation is wonderful! Oh, and it does e-mail me when something goes wrong and there is this ‘bconsole’ which allows you to trigger backups, check backup status, create new pools/volumes and much much more!

Here is my pool/volume setup:

3 Volumes
28 Day Use
56 Day Expire

12 Volumes
7 Day Use
28 Day Expire

4 Volumes
13 Day Use
28 Day Expire

Note that I only need a full backup to last a month and I have three volumes, so I should always have two full backups and the third will be recycled.

Here is the key schedule I use in the bacula-dir.conf:

Schedule {
Name = “WeeklyCycle”
Run = Level=Full Pool=FullBackupPool 1st sun at 23:05
Run = Level=Differential Pool=DiffPool 3rd-5th sun at 23:05
Run = Level=Incremental Pool=IncPool mon-sat at 23:05

Let me know if you would like me to post additional information.