Silencing the Nagios Plugin check_ntp_peer

in

The Nagios plugin "check_ntp_peer" from Debian package "nagios-plugins-basic" is not very nice. It shouts at you about LI_ALARM bit and negative jitter all the time after a machine reboots despite everything actually being fine.

#!/bin/bash

result=$(/usr/lib/nagios/plugins/check_ntp_peer $@)
status=$?

if echo "$result" | egrep 'jitter=-1.00000|has the LI_ALARM' >/dev/null; then
	echo "Unknown state after reboot."
	exit 0
fi

echo $result
exit $status

Using above wrapper you get rid of the warnings.

How to Get TinyTinyRSS Categories

in

If you are using TinyTinyRSS and want a hierarchic subscription list you need to explicitely enable categories from the preferences! Ensure to enable the "Enables feed categories" check box. Then save and open the "Feeds" tab which now allows you to add categories. All existing feeds are presented in category "Uncategorized".

Preferences Screenshot

Missing Roles in "knife node show" Output

Sometimes the knife output can be really confusing:

$ knife node show myserver
Node Name:   myserver1
Environment: _default
FQDN:        myserver1
IP:          
Run List:    role[base], role[mysql], role[apache]
Roles:       base, nrpe, mysql
Recipes:     [...]
Platform:    ubuntu 12.04
Tags:        

Noticed the difference in "Run List" and "Roles"? The run list says "role[apache]", but the list of "Roles" has no Apache. This is because of the role not yet being run on the server. So a

ssh root@myserver chef-client

Solves the issue and Apache appears in the roles list.

The learning: do not use "knife node show" to get the list of configured roles!

How To Debug PgBouncer

When you use Postgres with pgbouncer when you have database problems you want to have a look at pgbouncer too. To inspect pgbouncer operation ensure to add at least one user you defined in the user credentials file (e.g. on Debian per-default /etc/pgbouncer/userlist.txt) to the "stats_users" key in pgbouncer.ini:

stats_users = myuser

Now reload pgbouner and use this user "myuser" to connect to pgbouncer with psql by requesting the special "pgbouncer" database:

psql -p 6432 -U myuser -W pgbouncer

At the psql prompt list the supported pgbouncer commands with

SHOW HELP;

PgBouncer will present all statistics and configuration options:

pgbouncer=# SHOW HELP;
NOTICE:  Console usage
DETAIL:  
	SHOW HELP|CONFIG|DATABASES|POOLS|CLIENTS|SERVERS|VERSION
	SHOW STATS|FDS|SOCKETS|ACTIVE_SOCKETS|LISTS|MEM
	SET key = arg
	RELOAD
	PAUSE []
	SUSPEND
	RESUME []
	SHUTDOWN

The "SHOW" commands are all self-explanatory. Very useful are the "SUSPEND" and "RESUME" commands when you use pools.

MySQL Dump Skip Event Table

If your MySQL backup tool or self-written script complains about an event table than you have run into an issue caused by newer MySQL versions (>5.5.30) that introduced a new table "events" in the internal schema.

If you run into this you need to decide wether you want to include or exclude the new events table when dumping your database.

To skip: Due to a MySQL bug #68376 you have two choices. You can check documentation and add the logical option

--skip-events

which will cause the event table not to be exported. But the warning won't go away. To also get rid of the warning you need to use this instead:

--events --ignore-table=mysql.events

And of course you can also choose just to dump the events table: Add the option

--events

to your "mysqldump" invocation. If you use a tool that invokes "mysqldump" indirectly check if the tool allows to inject additional parameters.

/etc/sudoers.d Pitfalls

From the sudoers manpage:

[...] sudo will read each file in /etc/sudoers.d, skipping file names 
that end in ~ or contain a . character to avoid causing problems with 
package manager or editor temporary/backup files. [...]

This mean if you have a Unix user like "lars.windolf" you do not want to create a file

/etc/sudoers.d/lars.windolf

The evil thing is neither sudo nor visudo warns you about the mistake and the rules just do not work. And if you have some other definition files with the same rule and just a file name without a dot you might wonder about your sanity :-)

How to Get Flash Working with WebkitGTK3

With the switch to GTK3 all Webkit using applications like Epiphany, Liferea, devhelp, yelp and others lost Flash support. The reason is that Linux-Flash is GTK2 only! And of course there won't be new releases from Adobe ever. So we have the following compatibility situation for Liferea

Release
Line
Uses Flash Status
1.6
1.8
GTK2 + WebkitGTK2 any native Flash Works
1.10 GTK3 + WebkitGTK3 v1.8 32bit native Flash Broken
1.10 GTK3 + WebkitGTK3 v1.8 64bit native Flash Broken
1.10 GTK3 + WebkitGTK3 v1.8 32bit Flash + nspluginwrapper Works
1.10 GTK3 + WebkitGTK3 v2.0 any native Flash Works

The WebkitGTK+ solution for the Flash problem was implemented in version 2.0 by having a second process linked against GTK2 to run browser plugins while Webkit itself is linked to GTK3. This makes Flash work again.

But the currently widely distributed WebkitGTK3 v1.8 does not have this feature yet and fails to use the native flash.

nspluginwrapper Workaround

The only workaround is to use nspluginwrapper to run the 32bit version of Flash. This is guaranteed to work on 64bit platforms. It might not work on 32bit hardware, sometimes also because nspluginwrapper is not available there. The steps to install it are:

  1. Install nspluginwrapper. On Debian
    apt-get install nspluginwrapper
  2. Download 32bit Flash .tar.gz from Adobe
  3. Extract /usr files according to the Adobe instructions
  4. In the tarball directory run
    nspluginwrapper -i -a -v -n libflashplayer.so

    to install the plugin

Now all WebkitGTK3 using applications should be able to run Flash. Ensure to restart them and check command line output for any plugin errors.

Upgrading to WebkitGTK3 2.0

If you can try upgrading to WebkitGTK3 2.0 (e.g. Debian Experimental).

Liferea Sync Support Status (TinyTinyRSS, TheOldReader, Feedly, AOL Reader, Digg Reader)

There is slow progress in the world of news aggregation services. Since the last post on possible sync implementations I was able to submit API access requests for AOL Reader and Feedly. There is a chance that the request for AOL Reader will be successful. The unexpected thing with AOL is that they require OAuth2 authentication which Liferea does not yet support. Still it will be possible to add it.

My clear favourites are still AOL and Digg. With two 3rd party hosters and one self-hosted solution (TinyTinyRSS) Liferea would provide a reasonable set of choices.

Name API Status Implementation Status
Google Reader Deprecated Implemented, Now Useless
TinyTinyRSS Published. Implemented, Stable
TheOldReader Published. Implemented, Experimental
AOL Reader Published API Key Requested
Digg Reader Planned 1) %
NewsBlur Published Not Planned.
Feedly Secret 2) API Access Requested

1) Digg has announced they will be implementing Google Reader API and hope is they open it up
2) Feedly has announced there will be a public API with v17

TheOldReader Sync Implemented

I originally intended to make AOL Reader work, but failed due to the undocumented and propably not yet published authentication API. I'll ask AOL about it, but if anyone knows please drop me a mail.

So I could not work on AOL Reader, so I choose to work on TheOldReader (http://theoldreader.com) which I found very pleasant and stable. The API is close to Google Reader with the only limitation that it sometimes only has JSON support and no XML. As we use JSON already for TinyTinyRSS synching I could build on existing code.

So git master now has working experimental TheOldReader support!

This will be released soon with the initial 1.10 release.

So Liferea now has the following online synchronization support:

Name Status Import Google Reader
Google Reader Deprecated %
TinyTinyRSS Implemented, Stable No
TheOldReader Implemented, Experimental No
AOL Reader Planned, API not complete Yes
Digg Reader Planned, API not public Yes
NewsBlur Not Planned, API too different Yes
Feedly I registered Liferea as interested Client Yes

On the long term I'd like to support to new Google Reader clones to give Liferea users some choice along with TinyTinyRSS for the self-hosting choice.

Detecting a Dark Theme in GTK

When implementing an improved unread news counter rendering for Liferea if found it necessary to detect wether there is a light or dark GTK theme active. The reason for this was that I didn't want to use the foreground and background colors which are often black and something very bright. So instead from the GtkStyle struct which looks like this

typedef struct {
  GdkColor fg[5];
  GdkColor bg[5];
  GdkColor light[5];
  GdkColor dark[5];
  GdkColor mid[5];
  GdkColor text[5];
  GdkColor base[5];
  GdkColor text_aa[5];          /* Halfway between text/base */
[...]

I decided to use the "dark" and "bg" colors with "dark" for background and "bg" for the number text. For a light standard theme this results mostly to a white number on some shaded background. This is how it looks (e.g. the number "4" behind the feed "Boing Boing"):

Inverse Colors For Dark Theme Are Hard!

The problem is when you use for example the "High Contrast Inverse" dark theme. Then "dark" suddenly is undistinguishable from "bg" which makes sense of course. So we need to choose different colors with dark themes. Actually the implementation uses "bg" as foreground and "light" for background.

How to Detect Dark Themes

To do the color switching I first googled for a official GTK solution but found none. If you know of one please let me know! For the meantime I implemented the following simple logic:

	gint		textAvg, bgAvg;

	textAvg = style->text[GTK_STATE_NORMAL].red / 256 +
	        style->text[GTK_STATE_NORMAL].green / 256 +
	        style->text[GTK_STATE_NORMAL].blue / 256;

	bgAvg = style->bg[GTK_STATE_NORMAL].red / 256 +
	        style->bg[GTK_STATE_NORMAL].green / 256 +
	        style->bg[GTK_STATE_NORMAL].blue / 256;

	if (textAvg > bgAvg)
		darkTheme = TRUE;

As "text" color and "background" color should always be contrasting colors the comparison of the sum of their RGB components should produce a useful result. If the theme is a colorful one (e.g. a very saturated red theme) it might sometimes cause the opposite result than intended, but still background and foreground will be contrasting enough that the results stays readable, only the number background will not contrast well to the widget background.

For light or dark themes the comparison should always work well and produce optimal contrast. Now it is up to the Liferea users to decide wether they like it or not.

Syndicate content Syndicate content