Querying Connectivity

You're application almost always needs to know if there is a working network connection.  This is typically handled by placing the connection attempt in a try...catch block.  That works, but can be slow, and it means the UI can't really adapt to the level of current connectivity.  A much better solution is to query the NetworkManager [used by every mainstream distribution] via the System D-Bus for the current connectivity.  This method is used by many applications from GNOME's Evolution to Mozilla's Firefox - but it doesn't seem to get much press coverage.  So here is a simple example to query connectivity via Python [assuming NetworkManager 0.9 or later]:

#!/usr/bin/env python
import dbus

NM_BUS_NAME       = 'org.freedesktop.NetworkManager'
NM_OBJECT_PATH    = '/org/freedesktop/NetworkManager'
NM_INTERFACE_NAME = 'org.freedesktop.NetworkManager'
NM_STATE_INDEX = {  0: 'Unknown',
                   10: 'Asleep', 
                   20: 'Disconnected',
                   30: 'Disconnecting',
                   40: 'Connecting',
                   50: 'Connected (Local)',
                   60: 'Connected (Site)',
                   70: 'Connected (Global)' }

if __name__ == "__main__":
    bus = dbus.SystemBus()
    manager   = bus.get_object(NM_BUS_NAME, NM_OBJECT_PATH)
    interface = dbus.Interface(manager, NM_INTERFACE_NAME)

    state = interface.state()
    if state in NM_STATE_INDEX:
        print('Current Network State: {0}'.format(NM_STATE_INDEX[state]))
    else:
        print('Network Manager state not recognized.')

FYI: if you search the interwebz for the NetworkManager API specification ... every search engine will send you to the wrong place; either just wrong or to the documentation of an older version of the API. The current API specification is here.

GNOME3 Journal Extension

Now that's what I'm talking about!  A new extension just showed up on extensions.gnome.org that adds a "Journal" tab to the already awesome GNOME3 overview.  It integrates with Zeitgeist to provide access to recently or heavily used categories of items - sort of like "Recent" but all grown up and with college smarts.  And installing it is as easy as clicking "On" [assuming you have Zeitgeist already installed].

Journal tab in Overview

 A very handy addition that adds to the same concept provided by the gnome-activity-journal [which is packaged for openSUSE, BTW].

Really? A SHMMAX of 36MB

I was running some tests on OpenGroupware Coils on my new HP workstation - and PostgresSQL seemed to be huffing-and-puffing like an overweight guy trying to run up stairs.  Huh.  What is the first thing a PostgreSQL administraor always checks? The shared_buffers parameter [in /var/lib/pgsql/data/postgresql.conf]; the default package typically sets this value to some absurdly small value resulting in dreadful performance.  This default value is the principal reason the absurd notion that "MySQL is faster than PostgreSQL" got traction.  Sure enough - the default value is 24MB! Yikes.  So I changed that setting to a more reasonable 512MB.

shared_buffers = 512MB

Then I tried to restart PostgreSQL, and it flopped.

$ service postgresql start
redirecting to systemctl
Job failed. See system logs and 'systemctl status' for details.

Looking in /var/log/messages I see:

Dec  9 19:27:23 workstation postgresql[7288]: Starting PostgreSQL2011-12-09 19:27:23 EST   FATAL:  could not create shared memory segment: Invalid argument
Dec  9 19:27:23 workstation postgresql[7288]: 2011-12-09 19:27:23 EST   DETAIL:  Failed system call was shmget(key=5432001, size=76685312, 03600).

Huh.  I remember an error message like that from the RedHat 6.x & 7.x days when the kernel's default settings regarding System V IPC resources where really low.  Back then you possibly had to go look at defines in header files for these values. Fortunately we now have sysctl.  And what does sysctl tell us?

$ sysctl kernel.shmmax
kernel.shmmax = 33554432

What?!?!  That value is in bytes - so the limit is ~32MB?!  This is on a 64-bit installation with 8GB of RAM. That makes no sense at all.  Time to change that to something reasonable:

$ sysctl -w kernel.shmmax=1000000000

And now "service postgresql start" succeeds.  The ipcs command which reports System V IPC resources allocated in the system shows that the PostgreSQL engine has allocated the expected buffer pool:

$ ipcs
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x0052e2c1 1212416    postgres   600        572383232  4   

Once you change a sysctl setting in a helpful way the change has to be added to the /etc/sysctl.d/ so that it gets re-applied when the machine reboots;  otherwise our PostgreSQL instance is going to fail to start next time.  Create a file in that directory with a name such as postgresql.conf containing a single line of -

kernel.shmmax = 1000000000

The files in /etc/sysctl.d/ are processed after distribution and package defaults are applied.  It is also possible to edit /etc/sysctl.conf; however manual changes to that file may get overwritten by system management tools.  So use the /etc/sysctl.d/ strategy to override distribution defaults.
Now, back to work.

"Secret" extensions.gnome.org links

The new extensions.gnome.org is a fabulous idea and well-executed concept. But one issue is that is it isn't easy to visualize what is new; and the content of the site is growing rapidly.  As it turns out there is a secret link to sort extensions by the order they were added: https://extensions.gnome.org/?sort=recent For all the RSS user's out there the site also provides an RSS feed: https://extensions.gnome.org/rss/ Enjoy!

Note: Seriously people - this site is barely two weeks old.  Have some patience. It seems doubtless that the obviously inspired developers will add the "obviously" needed features in due time

TortoiseHg Packages

It turns out some kind fellow has packaged TortoiseHg for openSUSE 12.1;  you can find the packages in the home:tzotsos:vcs repo.  The repo provides not just the Tortoise GUI but the nautilus extensions as well. The only item the packages seem not to provide is a .desktop file for starting the thg application - without a .desktop file GNOME3 doesn't know the application exists.  You can either create the required file using alacarte or by hand; if by hand open the [new] file at ~/.local/share/applications/tortoise.desktop and paste in:

#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Icon[en_US]=/usr/share/pixmaps/tortoisehg/icons/thg_logo_92x50.png
Exec=/usr/bin/thg
Name[en_US]=Tortoise Hg
Comment[en_US]=Mercurial Client
Name=Tortoise Hg
Comment=Mercurial Client
Icon=/usr/share/pixmaps/tortoisehg/icons/thg_logo_92x50.png

Now GNOME3 will know about the thg application and you can launch it via the application search as well as add it to your launcher.

Enabling the RabbitMQ Management Plugin

Prior to 2.7.x version of RabbitMQ it was necessary to manually install the plug-ins that provided the management interface [as well as their dependencies]. Now in the 2.7.x series the management interface plug-in and related dependencies are included - but not enabled by default.  The management plug-in must be toggled into the enabled state using the new rabbitmq-plugins command.  Enabling a plug-in will automatically enable any other plug-ins that the specified plug-in depends on Whenever you enable or disable a plug-in you must restart the sever.
If you have a brand new 2.7.x instance installed, turn on the plug-in with:

service rabbitmq-server stop
rabbitmq-plugins enable rabbitmq_management
service rabbitmq-server restart

When you performed the rabbitmq-plugins command you should have seen the following output:

The following plugins have been enabled:
  mochiweb
  webmachine
  rabbitmq_mochiweb
  amqp_client
  rabbitmq_management_agent
  rabbitmq_management

You management interface at TCP/55672 should be available.  The initial login and password are "guest" and "guest".  You want to change those.

Idjit's Guide To Installing RabbitMQ on openSUSE 12.1

The RabbitMQ team provides a generic SUSE RPM which works on openSUSE 11.x, openSUSE 12.1, and I presume on the pay-to-play versions of SuSE Enterprise Server. About the only real dependency for RabbitMQ is the erlang platform which is packages in the erlang language repo. So the only real trick is getting the RabbitMQ package itself [from this page].  Then install and start is as simple as:

zypper ar http://download.opensuse.org/repositories/devel:/languages:/erlang/openSUSE_12.1 erlang
zypper in erlang
wget http://www.rabbitmq.com/releases/rabbitmq-server/v2.8.1/rabbitmq-server-2.8.1-1.suse.noarch.rpm
rpm -Uvh rabbitmq-server-2.8.1-1.suse.noarch.rpm
service rabbitmq-server start

Now you probably want to do some configuration and provisioning using the rabbitmqctl command; but your RabbitMQ instance is up and running.

Update 2012-04-10: Updated these instructions to install RabbitMQ 2.8.1.  The later 2.7.x series have start-up script issues as those scripts use the "runuser" command which is not present on openSUSE.  Running the latest RabbitMQ is generally a good idea in any case,  recent versions have corrected several memory leaks and manage resources more efficiently.

Using gedit to make a list of values into a set.

gedit is awesome;  the flexibility of the tool continues to impress me.  One problem I'm frequently faced with is a list of id values from some query, or utility, or e-mail message... and I want to do something with them.  So, for example I have:

10731
10732
10733
10734
10735
10736
10737
10738
10739

but what I need is those id values as a sequence such as for use in an SQL IN expression or to assign to a Python set or list.  What I want is:

(10731,'10732', '10733', '10734', '10735', '10736', '10737',
'10738', '10739')

Reformatting a few numbers by hand isn't too hard - but what if I have a list of hundreds of id values? The answer, of course, is provided by gedit.  Under Tools -> Manage External Tools the user can build filters that can be applied to documents and have the results returned to gedit.  If I create a new external tool that accepts as input the "Current document" and as output has "Replace current document" then gedit will replace the contents of the current document with the results of the filter [pretty obvious;  and if it doesn't work I can always Ctrl-Z].  The body of the filter can be any script - a Python script is perfectly valid. Like this hack:

#!/usr/bin/env python
import sys

iteration = 0
line_length = 0
text = sys.stdin.readline()
while (text !=  ''):
  text = text.strip()
  if (len(text) > 0):
    if (iteration == 0):
      sys.stdout.write('(')
    else:
      sys.stdout.write(', ') 
    if (line_length > 74):
      sys.stdout.write('\n ')
      line_length = 0
    if (len(text) > 0):
      sys.stdout.write('\'{0}\''.format(text))
    line_length = line_length + len(text) + 4
    iteration = iteration + 1
  text = sys.stdin.readline()
sys.stdout.write(')')  
sys.stdout.flush()

The current document becomes the standard-input for the script and the standard-output of the script will replace the current document. The above hack reads in a list of lines and returns them as a set enumeration nicely wrapped to 80 characters per line. External tools are saved under names; for this one I saved it as "IN-Clause-Filter".
Now that I've setup the external tool every time I paste a list of id values into gedit I can simply select Tools -> External Tools -> IN-Clause-Filter and my list is instantly turned into a set enumeration.