Uncoloring ls

By default on every recent shell the output of ls is colorized. This is a great feature - but it makes using terminals that use a non-standard [not(background==black)] color-scheme awkward.  Things just disappear;  try reading directory name displayed in yellow on a yellow background.  It is difficult.
How this colorization gets setup in openSUSE is that that the ls command is aliased to "ls --color=auto".  You can see this aliasing using the alias command.

[fred@example ~]# alias
alias cp='cp -i'
alias l.='ls -d .* --color=auto'
alias ll='ls -l --color=auto'
alias ls='ls --color=auto'
alias mv='mv -i'
alias rm='rm -i'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

So a simple way to turn this off is: unlias ls
There you go - no more annoying colors!  But they will be back the next time you login. Is this alias created in ~/.bashrc  - nope. ~/.bash_profile - nope. /etc/bashrc - nope. /etc/profile - nope, errr.... well, sort of.  The script /etc/profile runs every script in /etc/profile.d which ends in .sh.  Within /etc/profile.d is ...drumroll... colorls.sh which indeed does alias ls='ls --color=auto'.
To disable colorization - the aliasing of ls upon login:

mv /etc/profile.d/colorls.sh /etc/profile.d/colorls.sh.x

Now that the script does not end in .sh /etc/profile will not run it.
When you start a new interactive login[*1] shell bash runs: /etc/profile, then ~/.bash_profile, ~/.bash_login, and then ~/.profile.   Generally ~/.bash_profile will run ~/.bashrc, and generally ~/.bashrc will run /etc/bashrc.  And, of course, when /etc/profile runs it runs each of the scripts which match /etc/profile.d/*.sh.  It is almost comical; who says UNIX can't dance?

[*1] The shell distinguishes between login and secondary shells - a secondary shell is invoked by an existing shell, whereas a login shell is the first shell.  It also distinguishes between interactive and non-interactive shells - like those running a script.

AIX Printer Migration

There are few things in IT more utterly and completely baffling than the AIX printer subsystem.  While powerful it accomplishes its task with more arcane syntax and scattered settings files than anything else I have encountered.
So the day inevitably comes when you face the daunting task of copying/recreating several hundred print queues from some tired old RS/6000 we'll refer to as OLDHOST to a shiny new pSeries known here as NEWHOST.  [Did you know the bar Stellas in downtown Grand Rapids has more than 200 varieties of whiskey on their menu?  If you've dealt with AIX's printing subsystem you will understand the relevance.]
To add to this Sisyphean task the configuration of those printers have been tweaked, twiddled and massaged individually for years - so that rules out the wonderful possibility of saying to some IT minion "make all these printers, set all the settings exactly the same" [thus convincing the poor sod to seek alternate employment, possibly as a bar-tender at the aforementioned Stellas].
Does IBM really truly not provide a migration technique?  No.  But I now present to you the following incantation [to use at your own risk]:

scp root@OLDHOST:/etc/qconfig /etc/qconfig
stopsrc -cg spooler
startsrc -g spooler
rsync --recursive --owner --group --perms \
  root@OLDHOST:/var/spool/lpd/pio/@local/custom/ \
  /var/spool/lpd/pio/@local/custom/
rsync --recursive --owner --group --perms  \
  root@OLDHOST:/var/spool/lpd/pio/@local/dev/ \
  /var/spool/lpd/pio/@local/dev/
rsync --recursive --owner --group --perms  \
  root@OLDHOST:/var/spool/lpd/pio/@local/ddi/ \
  /var/spool/lpd/pio/@local/ddi/
chmod 664 /var/spool/lpd/pio/@local/ddi/*
chmod 664 /var/spool/lpd/pio/@local/custom/*
enq -d
cd  /var/spool/lpd/pio/@local/custom
for FILE in `ls`
 do
   /usr/lib/lpd/pio/etc/piodigest $FILE
 done
chown root:printq /var/spool/lpd/pio/@local/custom/*
chown root:printq /var/spool/lpd/pio/@local/ddi/*
chmod 664 /var/spool/lpd/pio/@local/ddi/*
chmod 664 /var/spool/lpd/pio/@local/custom/*

Execute this sequence on NEWHOST and the print queues and their configurations will be "migrated". 
NOTE#1: This depends on all those print queues being network attached printers.  If the system has direct attached printers that correspond to devices such as concentrators, lion boxes, serial ports, SCSI buses,.... then please do not do this, you are on your own.   Don't call me, we never talked about this.
NOTE#2: This will work once.  If you've then made changes to printer configuration or added/removed printers do not do it again.  If you want to do it again first delete ALL the printers on NEWHOST.  Then reboot, just to be safe.  At least stop and start the spooler service after deleting ALL the printer queues.
NOTE#3: I do not endorse, warranty, or stand behind this method of printer queue migration.  It is probably a bad idea.  But the entire printing subsystem in AIX is a bad idea, sooo.... If this does not work do not call me; we never talked about this.

gedit's amazing External Tools

In a few recent conversations I have become aware of an unawareness - an unawareness of the awesome that is gedit's best feature: External Tools.  External Tools allow you to effortlessly link the power of the shell, Python, or whatever into an otherwise already excellent text editor yielding maximum awesome.  External Tools, unlike some similar features in many IDEs is drop-dead simple to use - you do not need to go somewhere and edit files, etc... you can create and use them without ever leaving the gedit UI.

Plugins tab of the Preferences dialog.

To enable External Tools [which is a plugin - as is nearly every feature in gedit] go to the Plugin tab of Preferences dialog and check the box for "External Tools".  External Tools is now active.  Close the dialog and proceed in defining the tools useful to you.
With External Tools enabled there will be a "Manage External Tools" option in the Tools menu.  When in the tools menu not there is also an "External Tools" submenu - every external tool you define will be available in the menu, automatically.  The list of defined tools in that submenu will also include whatever hot-key you may have bound to the tool - as you likely will not remember at first.

Manage External Tools Dialog

Within the Manage External Tools dialog you can start defining what tools are useful to you.  For myself the most useful feature is the ability to perform in-place transformations of the current document; to accomplish this set input to "Current Document" and Output to "Replace Current Document".  With that Input & Output the current document is streamed to your defined tool as standard input and the standard output from the tool replaces the document.  Don't worry - Undo [Ctrl-Z] still works if your tool did not do what you desired.
What are some useful External Tools?  That depends on what type of files and data you deal with on a regular basis.  I have previously written a post about turning a list of value into an set format - that is useful for cut-n-paste into either an SQL tool [for use as an IN clause] or into a Python editor [for x=set(....)].   That provides a simple way to take perhaps hundreds of rows and get them into data very simply. 
Otherwise some tools I find useful are:

Format JSON to be nicely indented

#!/bin/sh
python -m json.tool

Use input/output settings to replace current document.

Open a terminal in the directory of the document

#!/bin/sh
gnome-terminal --working-directory=$GEDIT_CURRENT_DOCUMENT_DIR &

Set the input/ouput for this action to "Nothing"

Remove leading spaces from lines

#!/bin/sh
sed 's/^[[:blank:]]*//'

Use input/output settings to replace current document. 

Remove trailing spaces from lines

#!/bin/sh
sed 's/[[:blank:]]*$//'

Use input/output settings to replace current document.

Keep only unique lines of the file

#!/bin/sh
sort | uniq

Use input/output settings to replace current document. 

Format an XML file with nice indentation

#!/bin/sh
xmllint --format - -

Use input/output settings to replace current document.

Installation & Initialization of PostGIS

Distribution: CentOS 6.x / RHEL 6.x

If you already have a current version of PostgreSQL server installed on your server from the PGDG repository you should skip these first two steps.

Enable PGDG repository

curl -O http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/pgdg-centos93-9.3-1.noarch.rpm rpm -ivh pgdg-centos93-9.3-1.noarch.rpm

Disable all PostgreSQL packages from the distribution repositories. This involves editing the /etc/yum.repos.d/CentOS-Base.repo file. Add the line "exclude=postgresql*" to both the "[base]" and "[updates]" stanzas. If you skip this step everything will appear to work - but in the future a yum update may break your system.

Install PostrgreSQL Server

yum install postgresql93-server

Once installed you need to initialize and start the PostgreSQL instance

service postgresql-9.3 initdb service postgresql-9.3 start

If you wish the PostgreSQL instance to start with the system at book use chkconfig to enable it for the current runlevel.

chkconfig postgresql-9.3 on

The default data directory for this instance of PostgreSQL will be "/var/lib/pgsql/9.3/data". Note: that this path is versioned - this prevents the installation of a downlevel or uplevel PostgreSQL package destroying your database if you do so accidentally or forget to follow the appropriate version migration procedures. Most documentation will assume a data directory like "/var/lib/postgresql" [notably unversioned]; simply keep in mind that you always need to contextualize the paths used in documentation to your site's packaging and provisioning.

Enable EPEL Repository

The EPEL repository provides a variety of the dependencies of the PostGIS packages provided by the PGDG repository.

curl -O http://epel.mirror.freedomvoice.com/6/x86_64/epel-release-6-8.noarch.rpm rpm -Uvh epel-release-6-8.noarch.rpm

Installing PostGIS

The PGDG package form PostGIS should now install without errors.

yum install postgis2_93

If you do not have EPEL successfully enables when you attempt to install the PGDG PostGIS packages you will see dependency errors.

---> Package postgis2_93-client.x86_64 0:2.1.1-1.rhel6 will be installed --> Processing Dependency: libjson.so.0()(64bit) for package: postgis2_93-client-2.1.1-1.rhel6.x86_64 --> Finished Dependency Resolution Error: Package: gdal-libs-1.9.2-4.el6.x86_64 (pgdg93)            Requires: libcfitsio.so.0()(64bit) Error: Package: gdal-libs-1.9.2-4.el6.x86_64 (pgdg93)            Requires: libspatialite.so.2()(64bit) Error: Package: gdal-libs-1.9.2-4.el6.x86_64 (pgdg93) ...

Initializing PostGIS

The template database "template_postgis" is expected to exist by many PostGIS applications; but this database is not created automatically.

su - postgres createdb -E UTF8 -T template0 template_postgis -- ... See the following note about enabling plpgsql ... psql template_postgis psql -d template_postgis -f /usr/pgsql-9.3/share/contrib/postgis-2.1/postgis.sql psql -d template_postgis -f /usr/pgsql-9.3/share/contrib/postgis-2.1/spatial_ref_sys.sql

Using the PGDG packages the PostgreSQL plpgsql embedded language, frequently used to develop stored procedures, is enabled in the template0 database from which the template_postgis database is derived. If you are attempting to use other PostgreSQL packages, or have built PostgreSQL from source [are you crazy?], you will need to ensure that this language is enabled in your template_postgis database before importing the scheme - to do so run the following command immediately after the "createdb" command. If you see the error stating the language is already enabled you are good to go, otherwise you should see a message stating the language was enabled. If creating the language fails for any other reason than already being enabled you must resolve that issue before proceeding to install your GIS applications.

$ createlang -d template_postgis plpgsql createlang: language "plpgsql" is already installed in database "template_postgis"

Celebrate
PostGIS is now enabled in your PostgreSQL instance and you can use and/or develop exciting new GIS & geographic applications.

Please No 169.254/16

When you bring up at new LINUX OS installation it will typically [at least in the case of CentOS] have a route of 169.254/16 on every interface.  These routes are used to support the good and virtuous feature known as "zeroconf".  Sometimes however you do not want that route noise - especially if the host is going to be operating as a router or firewall.  Fortunately disabling this feature for this specific use-case is easy.

# netstat -rn
Kernel IP routing table
Destination     Gateway    Genmask      Flags  MSS Window irtt Iface
169.254.0.0     0.0.0.0    255.255.0.0  U        0 0         0 eth0
Text 1: The 169.254/16 route for zeroconf in the routing table.

Edit the /etc/sysconfig/network file and add a line reading "NOZEROCONF=yes".  Then either restart the networking stack or reboot the host.  No more zeroconf routes.

Concerning Decorators

Decorators are a powerful as well as arcanely constructed feature of Python.  Over at is BLOG Graham Dumpleton has written a series of [8 so far] articles covering Python decorator's in-depth.  Lots of information here along with abundant examples.

• How you implemented your Python decorator is wrong. 
• Implementing a factory for creating decorators
• The interaction between decorators and descriptors.
• Implementing a universal decorator. 
• Decorators which accept arguments.
• Maintaining decorator state using a class.
• The missing @synchronized decorator.
• The @synchronized decorator as context manager.

The Quest For The Lost Pointer

On the screen you have a pointer - it points at thing!  It is used to point at, select [highlight], drag, and numerous other things.  The mouse pointer has been there and looked more-or-less the same for decades now;  my pointer in GNOME Shell looks and works almost identically to the pointer I had on my GEOS desktop (1986).  It has stayed the same because it works.

But the pointer has a few new challenges - (1) displays are getting bigger and bigger, big displays are aggregated together [you would have to have been very wealthy in 1986 to do that] and (2) the DPI/resolution of displays are now soaring to ridiculous and pointless values [not that the pointlessness suppresses the squeals of geeker joy from tech fanboys and fangirls].   These two trends raise the problem - "where the @*&# is the pointer?!".  You look away from your vast panorama of high-DPI displays for just a moment... and then you have to find it again.

GNOME Shell provides two features that assist in the quest for the missing pointer.

The first is "Show location of pointer".  This is most easily accessed via the GNOME Tweak Tool and is located in the "Keyboard and Mouse" section.  Simply toggle the feature on.  Once the feature is enabled tapping either Ctrl key [alone, by itself, not in combination with any other key] will cause the pointer to strobe;  the location will immediately be apparent. 

As with any setting you can also manage it using the GSettings API or using the gsettings command line tool.  The path to the relevant key for "Show location of pointer" is "org.gnome.settings-daemon.peripherals.mouse/locate-pointer".  To enable this feature from the command line:

$ gsettings set org.gnome.settings-daemon.peripherals.mouse locate-pointer true
$ gsettings get org.gnome.settings-daemon.peripherals.mouse locate-pointer
true

The second setting is not available for modification in GNOME Tweak Tool or the standard control center.  This is probably due the fact that you can render your desktop almost useless via senseless modification of this value.  This second feature is the ability to adjust the size of the pointer - so for very high DPI displays you can increase the size of the pointer.  You can also scale it down to where you cannot see the pointer at all [and if you do that, no, the software is not "broken"; the correct way to describe that condition is to say that the operator is "careless"].  The relevant setting is "org.gnome.desktop.interface/cursor-size".

$ gsettings get org.gnome.desktop.interface cursor-size
24
$ gsettings set org.gnome.desktop.interface cursor-size 36
$ gsettings get org.gnome.desktop.interface cursor-size
36

The appropriate value is an integer - so look at the current value and tweak it up or down until you find a comfortable pointer size.  You will notice that the change to a gsetting is immediate; there is not need to log-out or restart GNOME Shell.

If the command line is too intimidating for you - you can also adjust either of these configuration parameters, and a myriad of others, using the excellent dconf-editor GUI.  For most parameters dconf-editor even provides a bit of documentation, the range of appropriate values, and the general-purpose default.

Now you never need to hunt for the pointer; you can spend more time hunting the whumpus.