Whither Samba?

"What's up with Samba?" ....  "Is Samba4 for real?" ... "Is Samba4 ever going to be released?"  These questions have been common for several years now. Now we have answers thanks to this excellent article/interview on LWN.

Streaming the BBC World Service

Every leap year the american public radio service becomes obsessed with providing non-stop glossy and shallow coverage of the various presidential candidates, campaigns, and caucases.  They report endlessly on various polling results [even though the validity of such polls is in question according to credible statisticians and demographers].  Fortunately there is the BBC World Service which offers an alternative for english speaking listeners exhausted by caucus mania.  The appropriate links are not easy to find - but they are there. The MP3 link under "World Service English (Internet Schedule)" works perfectly when added to Banshee's radio playlist.

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.