Return to Window Maker (on Xubuntu 15.10)

I’ve been running Xubuntu 15.10 (Wily) for a while now, having converted from Ubuntu using the repositories. I converted to lower the memory usage, especially considering that my two most often used applications are Firestorm (a third-party viewer for Second Life) and Google Chrome (not Chromium). Using these two apps then lead me to further reduce memory usage by using Window Maker once again. (Note that the name is two words: the project’s original name was objected to by a maker of software for makers of windows and doors.)

I talked about this before in this blog (back in 2011). Several things have changed since then, beyond faster and bigger hardware. The wmaker-crm fork is now the source for Ubuntu Window Maker and is in active development. Free(code) has 145 projects tagged as “Window Maker” projects. Distrowatch lists a couple dozen active distributions that use a Window Maker desktop. Window Maker now has a entry in the Free Software Directory. There’s even a live CD called Window Maker Live.

Others have written about Window Maker as well. Barnaby has a nice write up on their Window Maker setup and resources. Duncan McGreggor has a fantastic description of their use of Window Maker (thought from 2009). Also from 2009, the information from Joshua Price remains useful, as does this information from Rowan Rodrick. A wonderful comparison (with Part 1 and Part 2) of the memory usage of desktops over at the Layer 3 Networking Blog, including a beautiful graph: Window Maker comes in at 7Mb, 9wm at 0.4Mb, XFCE at 70Mb, and Unity at 192Mb. (That means I went from 192Mb usage – to 70Mb – down now to 7Mb. Wow!)

The Arch Linux Wiki describes Window Maker installation and configuration extremely well. However, in current Ubuntu installations, there’s no need to build from source: one of the most recent Window Maker versions will be available (0.95.7 currently). There’s also no need to install the menu package, as it is automatically installed. So to start, just:

apt-get install wmaker

In configuring Window Maker, you’ll want some dockapplets. (I just searched through the apt repositories for apps that had a “wm” prefix or had a “.app” suffix.) Right now I am running these:

  • wmdrawer
  • wmsystemtray
  • wmclockmon
  • wmcpuload
  • wmmemload
  • wmdiskmon
  • wmtemp
  • wmnd
  • wmwave
  • wmstickynotes

All should be in the apt repositories, except wmdrawer which you can activate from right-clicking on the Window Maker prefs dockapp and selecting “Add Drawer.”

apt-get install wmsystemtray wmclockmon wmcpuload wmmemload wmdiskmon wmtemp wmnd wmwave wmstickynotes

Then start them up:

wmsystemtray &
wmclockmon &
wmcpuload &
wmmemload -b -c &
wmdiskmon -p /dev/sdb1 -p /dev/sdb5 &
wmtemp &
wmnd &
wmwave &
wmstickynotes &

Once they are started, you will have to move them from the minimized icon shelf at the bottom, over to the dock on the right. Press Alt and drag the icon over to the dock. If it triggers something in the applet, find a sliver of border and Alt-drag using that. You should see a white block in the dock when there is a place to drop the applet.

The Ubuntu Window Maker experience is much more polished now: the menu package is required (negating the need for a special installation), and it comes with 9 workspaces. I configured mine to use “focus follows mouse” and “autoraise selected window” – which can simplify things a bit, but is very different from the modern “click to focus” method.

As someone noted in the previous article, there is no need to run wicd if you don’t want to. The standard Network Manager works just fine, and you can manipulate it from the system tray (the dockapp wmsystemtray) just by running its system tray applet:

nm-applet &

My system tray also includes input language changer (using ibus), copyq (copy buffer manager), kupfer (program launcher), clementine (a music player), veromix (a mixer), solaar (for Logitech wireless devices), and the Google Chrome access icon (good for operating Chrome only for Chrome application purposes). Except for Chrome, all are included in the Ubuntu repositories. (If you want to type in Japanese as I did, add anthy as well – also in the repositories.) To install the complete set:

apt-get install ibus copyq kupfer clementine veromix solaar anthy

You can activate shadows and transparency and faded windows (on losing focus) with compton:

apt-get compton
compton -bcCGf -i 0.8 -e 0.8 --no-fading-openclose --sw-opti

You might wish to use different options – see the man page for more:

man compton

Many sources for Window Maker themes are dated: Tower’s Window Maker Themes (1999), WindowMaker Themes from LonelyMachines (2006), and Window Maker themes from (1999).

However, over at, they have numerous Window Maker themes that appear to be fairly recent.

To set the background, use the wmsetbg command as before:

wmsetbg mybackground.jpg

Note that this will set all monitors and all workspaces to the same background. You can specify which workspace in the wmsetbg command, as well as update the default. I haven’t found a way to set individual monitors to different backgrounds yet.

Here is my current workspace (it uses the Lumen_Blue theme):

Screenshot 2016-07-11 12:18:52

(The background picture is from Second Life – I’m on the left.)

As long as you exit cleanly, all of your clip icons and dock applets and system tray applets will all return the next time you log in.

There are YouTube videos about Window Maker including FreeBSD 10.2 with Window Maker and GNUStep Base and an overview of Installing and Using Window Maker Live. There is an extensive overview of Window Maker Live in Japanese, a short overview of Window Maker (running on Calculate Linux) in Russian, an overview of Window Maker on FreeBSD and an overview (from 2011) of Window Maker on Mageia Linux.

Try Window Maker and have fun with it today!

The Nagios Ecosystem: Nagios, Shinken, and Icinga

Nagios has been a standard-bearer for a long time, being developed originally by Ethan Galstad and included in Debian and Ubuntu for quite some time. In 2007, Ethan created a company built around providing enhancements to Nagios called Nagios Enterprises. However, for several years now there have been competitors to the original Nagios.

The first to come along was Icinga. This was a direct fork of the Nagios code that happened in May of 2009; the story of what lead to the fork was admirably reported by Free Software Magazine in April of 2012. In short, many developers were unhappy with the way that Nagios was being developed and with what they perceived as its many shortcomings which Ethan could not or would not fix. From Ethan’s standpoint, it was more about the enforcement of the Nagios trademark. The article summed it up best at the end: it’s complicated.

The H-Online also had an interview with Ethan Galstad about the future of Nagios and some of the history of the project.

Icinga is now in Ubuntu Universe and has been since Natty. It is also available for Debian Squeeze (current stable release).

Another project is Shinken: rather than a fork, it is a compatible replacement for the core Nagios code. When the Python-based Shinken code was rejected (vigorously) in summer of 2010 as a possible Nagios 4, it became an independent project. This project is newer than Icinga, but shows serious promise. It too, is now available in Ubuntu Universe and in Debian Wheezy (current testing release).

It is unfortunate that such animosity seems to swirl about Nagios; however, Icinga and Shinken appear to be quite healthy projects that provide much needed enhancements to Nagios users – and both are available in Ubuntu Precise Pangolin, the most recent Ubuntu LTS release.

I don’t know if Icinga or Shinken still work with Nagios mobile applications. If it’s just the URL, then the web server could rewrite the URL; if there is no compatible page for the mobile applications, then they can’t be used. However, I’d be surprised if there was no way to get the mobile apps working.

I’m going to try running Shinken and/or Nagios on an installation somewhere; we’ll see how it goes. I’ll report my experiences at a later date.

OpenLDAP with SSL in Ubuntu Lucid Lynx

In researching configuration tasks for OpenLDAP, I found this article about using sudo with OpenLDAP. As I am going to implement SSL with OpenLDAP, problems with sudo and SSL could be fatal, so I decided to investigate further.

It turns out that the problem is embedded in GnuTLS, a GPL-licensed OpenSSL replacement. GnuTLS was used by Debian because of a licensing conflict between OpenSSL and OpenLDAP. A backend library used by GnuTLS (libgcrypt11) causes problems based on the way it is initialized and the way it handles the dropping of privilege (that is, it gets rid of its “root” access). This shows up as suid applications failing when run against LDAP users; Ubuntu bugs 926350 (GnuTLS) and 423252 (sudo) are this exact problem.

GnuTLS is replacing libgcrypt11 with the nettle backend as of 2.11.x, but Ubuntu Lucid Lynx continues to use GnuTLS with the original (flawed) backend. The “fix” espoused by some is to use nscd – but this is acknowledged to be a workaround.

There is a GnuTLS version compiled not against libgcrypt11 but libnettle which should the problem. I did not test this PPA; if you wish to stick with OpenLDAP and GnuTLS this might be the way to go.

However, there is also a version of OpenLDAP compiled against OpenSSL. Add the PPA to your APT configuration and then perform a system update (apt-get update && apt-get upgrade). This will upgrade your OpenLDAP and cause it to stop at least temporarily; thus, make sure you allow for some server downtime.

This version of OpenLDAP works except for a few initial problems that must be overcome. When you first install, it may refuse to run.

First, it seems to add an openldap user and group – and while this is good, it does not completely change appropriate files to give access to the openldap user. There are two locations that need to be fixed:

  • /var/lib/ldap (the location of the LDAP data store)
  • /etc/ssl (the location of the SSL certificates)

Fixing the first is simple:

chown -R openldap:openldap /var/lib/ldap

The second is not as straight-forward; in my case, I added the user openldap to the group ssl-cert which has access into the /etc/ssl directory and subdirectories. Use the vigr command to make this happen: add openldap to the end of the ssl-cert group line (your group id might be different):


Note that if the SSL certificates aren’t set up right, then running the new OpenLDAP will not work – even if LDAPS is not enabled at startup. (There is a fantastic message showing how to make sure your certificates match from You also need to make sure that the certificates are not expired; it is reported that OpenLDAP will also fail to start with expired certificates.

As the final step, change the /etc/default/slapd file to start LDAPS:

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

Eventually, the best thing to do is to remove LDAP support entirely (and use LDAPS completely):

SLAPD_SERVICES="ldapi:/// ldaps:///"

Log Rotation for MySQL using logrotate

The logrotate utility is a powerful and underrated utility used to rotate logs. It is one of Red Hat’s lesser known utilities; even so, it is available for a number of platforms, including Ubuntu.

However, its set up for MySQL is missing on Red Hat and incomplete on Ubuntu.

For Ubuntu, there is no rotation of the slow query logs. To rotate these logs, just add them to the standard Ubuntu logrotate file for MySQL – that is, /etc/logrotate.d/mysql-server. Add the logs to rotate to the beginning of the file, adding to the list of files already present there.

For Red Hat, a complete MySQL log rotation file is needed as there is none at all. The MySQL logrotation script was removed as part of a security update to Fedora Core 4 back on 17 May 2006, and later removed from Red Hat Enterprise Linux 4 Update 4. The reasoning was detailed in Bug #180639 (not available?) and Bug #182025. Since then, this missing logrotate file has been the subject of several bugs (such as Bug #547007) and also of message threads like this one from Red Hat’s rhelv5-list in July of 2007.

The response to all these queries is that the MySQL logrotate script is broken and it’s up to MySQL to fix it. However, this does not seem to take into account the new FLUSH LOGS command, and admins everywhere are creating their own scripts.

Over at Question Defense, Alex has a fabulous description of the entire process – from enabling logging through implementing log rotation. However, this process uses ~/.my.cnf to automatically log in; better is to use a file like /etc/mysql/maint.cnf the way that Debian (and Ubuntu) does it. In that case, Debian creates a special user and a password to go with it, and puts these into a file /detc/mysql/debian.cnf; here is a sample debian.cnf:

# Automatically generated for Debian scripts. DO NOT TOUCH!
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

For most purposes, only the [client] section is needed, along with the first three entries (host, user, and password). You could also specify the section as [mysqladmin] instead, which would limit the username and password to being used for mysqladmin only – which is the tool used during log rotation.

The critical command is this one:

/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf

…where logrotate.cnf contains username and password details as described above. All the rest of the logrotate file is settings and script-bulletproofing:

# Modified Ubuntu logrotate script for MySQL server
# Untested under Red Hat, but should work: filenames will have to be changed
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
        rotate 7
        create 640 mysql adm
                test -x /usr/bin/mysqladmin || exit 0
                MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf"
                if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
                  if killall -q -s0 -umysql mysqld; then
                    exit 1
                  $MYADMIN flush-logs

The Current State of Window Maker

I’ve always liked the Window Maker window manager. However, the current state of Window Maker is in some turmoil.

Development on the original Window Maker window manager has ceased, and new development has been taken up by wmaker-crm (a fork). Nightly builds of wmaker-crm had been available for Debian from a user-created repository, but no new builds have been put up since 29 April 2011 – and the repository information hasn’t been rebuilt since 26 May 2011. Building a Debian package seems to be problematical in any case. According to this mailing list thread, Andreas Metzler and Martin Dietze are responsible for changes therein, but the changelog hasn’t reflected any changes in wmaker-crm.

It was recommended to the Debian Window Maker package maintainer, John H. Robinson IV, to use the wmaker-crm sources for the package; he was receptive but nothing has happened since. As of 6 July 2011, he stepped down as maintainer of the package, leaving the Debian package orphaned. This event did not go unnoticed; a thread was taken up on the wmaker-crm development list.

The person behind wmaker-crm, Carlos R. Mafra, also created a git repository for numerous Window Maker dockapps that are no longer maintained.

The standard Window Maker display manager, the WINGs Display Manager, apparently is much less desired than Window Maker itself: according to the popularity contest statistics, at a peak during January 2011, 2000+ people had Window Maker installed while less than 200 currently have WDM installed.

Statistics about the installed base (and user base) of Window Maker and other packages can be seen over at; these statistics come from people who have installed the popularity-contest package.

Over at ArchLinux, their wiki has an excellent write-up on Window Maker (including basic technical details and information on wmaker-crm) which certainly makes one think that Window Maker is vibrant in that community. Both Window Maker and wmaker-crm are packaged (as windowmaker and windowmaker-crm-git respectively) and available to ArchLinux users from the Extra Repository as well.

If you want to see Window Maker in action (more or less – it does show a lot of Tux Commander too…) you can check out this video showing Window Maker on a Duron 850MHz system with 256Mb.

I may post a short video of my own Window Maker desktop; having forced myself to run with Window Maker as my default desktop has made me a complete convert – and helped me to force myself to research and resolve problems with making Window Maker a default desktop. Recently, I wrote about just what it took to make Window Maker fully capable and up-to-date.

If GNOME or KDE are finally just too much – and XFCE isn’t quite what you want – try Window Maker instead.


The Wheel Group: Updated

Working with Ubuntu Server (Lucid Lynx) the wheel group has been changed slightly.

Firstly, there doesn’t seem to be any wheel group at all – not by name. The group is now called root by default, and is enabled the same as before: uncomment the appropriate line in /etc/pam.d/su so it looks like this:

auth required

The system uses the root group because that is the group name for group 0, and because there is no group named wheel. However, if you want to maintain the original standard – make the entry look like this instead:

auth required group=wheel

Then rename (or duplicate) the group in /etc/group with id 0:


This maintains the highest level of compatibility: the group root remains as before, but the name wheel is also available. Having two groups with the same group ID is not typically recommended, but it doesn’t necessarily break anything either as long as the two groups are seen as completely equivalent. The first group in the list will normally be used when names are given for GIDs, but both names will be recognized from the user.

According to the documentation, this is overkill – but it does force the issue and make su work with the actual wheel group rather than a renamed one.

What pam_wheel actually does is search for group wheel first, then if it can’t find that, searches for group 0 (zero) next. It is this configuration that allows the renaming of the wheel group.

Apparently Debian or Ubuntu named the group sudo at one point, now root. The best thing to do – when there is no distinct advantage to change – is to go with the status quo: in doing so, any administrator that comes along will be able to learn and adapt to the system rapidly, leading to quicker completion of administration tasks, simple and complex.

Putting Debian packages on hold

When administering a Debian (or Ubuntu) system, putting packages on hold can be very useful. For example, if a critical part of the system is used by developers, and is continually updated, the developers will want to be aware of updates and will want to check their code in the new environment. Programs like Tomcat, Cocoon, MySQL will be in this category.

Similarly, if a critical portion of the system is to be updated, you wouldn’t want it to be part of the automatic updates – though you really shouldn’t automatically update, since you don’t know what can break until you test it.

To hold a package or packages, you should use dpkg --set-selections. If you run the command dpkg --get-selections you can see what is set already:

# dpkg --get-selections | head
acct                                            install
adduser                                         install
apparmor                                        install
apparmor-utils                                  install
apt                                             install
apt-transport-https                             install
apt-utils                                       install
aptitude                                        install
at                                              install
auditd                                          install

As an example, let’s consider the package dnsutils. Let’s see what would happen before we do anything:

# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  bind9-host dnsutils libbind9-60 libdns64 libisc60 libisccc60 libisccfg60 liblwres60
8 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,257kB of archives.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]? n

Now let’s change this. We’ll put the package dnsutils on hold using dpkg --set-selections:

# echo dnsutils hold | dpkg --set-selections

Let us check the results:

# dpkg --get-selections | grep dnsutils
dnsutils                                        hold

Now, when we try the system update again, things have changed:

# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  bind9-host dnsutils libbind9-60 libdns64 libisc60 libisccfg60 liblwres60
The following packages will be upgraded:
1 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
Need to get 29.9kB of archives.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]? n

Now, dnsutils – and its related packages – are being held back, just as we wanted. The other packages are being held back because they are only required by dnsutils; without upgrading dnsutils, they won’t be upgraded either.

Linux Mint new version: Debian Edition

Linux Mint announced that there is a new version, released today, called Linux Mint Debian Edition (LMDE).

According to the documentation, LMDE is based on Debian Testing, which becomes the next Debian release (currently Debian Squeeze). Testing is the version of Debian where “release testing” occurs, prior to a cutover to an actual release.

However, testing does not receive security updates the way the current release does. When Debian 5.0 (Lenny) was released, the Security Team stopped providing security updates to testing to better allocate their resources. From all indications, this “temporary” suspension continues two years later.

Linux Mint also comes in versions with various desktops, including KDE, GNOME, LXDE, and Fluxbox. Too bad there isn’t a good distribution with Window Maker as the main windowing environment – I use Window Maker when I want a low-memory environment (and GNOME or KDE is too much).

Oracle’s Plans for OpenSolaris Murkier than Ever

The controversy around the future of OpenSolaris has been building to a fever pitch these last few weeks, most recently leading to the creation of Illumos, a new open source kernel tree based on the open source portions of OpenSolaris.

Way back in July of 2009, Steven Vaughn-Nichols suggested that OpenSolaris would wither on the vine through deliberate neglect by Oracle – and this seems to be happening (whereas his prediction of the same treatment for MySQL and VirtualBox seems to be misplaced). Then in February of 2010, Ben Rockwood wrote an open letter to Oracle about the future of Solaris and OpenSolaris.

Oracle’s most recent response (during an interview with ServerWatch) has been to state that development on Solaris continues apace, and that Solaris 11 is due out by the end of 2011. Most notable was the lack of any discussion on the future of OpenSolaris.

A few months ago, the OpenSolaris Governing Board – in effect, the people in charge of the details of operating the OpenSolaris community and its resources – are willing to resign en masse if Oracle does not talk to them; Peter Tribble (a member of the OpenSolaris Governing Board) talks about this action in his blog.

I agree with those that say that Oracle can do what it likes, and the threat made by the board is empty – not because of the threat itself, but because it will accomplish nothing, and has no effect on Oracle. If Oracle wants OpenSolaris to go away, it doesn’t matter what the OpenSolaris community thinks. The Governing Board simply has no leverage with Oracle.

No word on how this action will affect Belenix; while Nexenta is basically the OpenSolaris kernel plus a Debian/GNU userland, Belenix is an OpenSolaris kernel plus a mostly Solaris userland. The primary founder of Belenix (Moinak Ghosh) is on the OpenSolaris board; one of the other developers (Sriram Narayanan?) blogged about the board’s action shortly after it was taken in July. Perhaps Belenix would use the Illumos kernel as well?

However, the prospect of OpenSolaris living on in the form of Illumos is promising, and technologies that are part of the open source OpenSolaris will not be lost. Nexenta has already stated its interest in Illumos; this is perhaps because Nexenta relies on OpenSolaris (with its now doubtful future) for its kernel. Thus, it is perhaps no surprise that a Nexenta engineer is the driving force behind Illumos, and neither is it a surprise that Illumos is currently a kernel only.

So now – how long before we see a Debian/Illumos project? Or is that Nexenta now?

Unattended Ubuntu Installations

Michael Reed wrote a nice tutorial for Linux User and Developer about unattended Ubuntu installations. Ubuntu aso has excellent documentation on the booting process.

Unattended installations are a boon to system administrators, or anyone who needs to install systems several times a month or so.

When an installation is preconfigured – especially using the network – an administrator can start the installation then go do something else. Productivity increases dramatically. If you have many systems to install – you can start all of them and leave them to finish on their own while you complete other tasks.

An unattended installation also leads into systems being identically configured, providing for easier administration and easier debugging. If systems are hand-crafted, then replicating the system (such as hardware upgrades or restores) will be harder – or more likely, impossible.

Since Ubuntu is based on Debian, the original preseed configuration tool is available; however, the excellent kickstart (and anaconda) program from Red Hat was adapted to Ubuntu. Preseed handles more options, but kickstart offers its own advantages as well. They can be used together for installations.

A whitepaper from Canonical (Automated Deployments of Ubuntu, by Nick Barcet in September 2008) describes in easy-to-read detail all the possibilities of unattended installations with preseed and kickstart. While the whitepaper discusses these things in context of Ubuntu 8.04, it is still a valuable resource in concert with the official Ubuntu install documentation.

The files required for booting from the network are available from Ubuntu mirrors; be sure to get the right one for your architecture and Ubuntu version (this discussion assumes ix86 and Ubuntu Lucid Lynx).

An abbreviated description of the process to set up for kickstart is this:

  • Set up an HTTP server (web server).
  • Set up a DHCP server.
  • Set up a TFTP server.
  • Set up a NFS server.

Once these three servers are up, you are more than half-way there. The kickstart file will be placed on the web server for the unattended installations.

Configure the DHCP server to use the pxelinux.0 file for the boot loader, and from the appropriate TFTP server. The boot files have to be located on the TFTP server in the appropriate locations.

Make sure, too, that all of the files necessary for installation – the entire distribution – is available via NFS or via the Internet. Once the boot loader is started, and the Linux kernel is loaded, all of the packages will be downloaded from this source.

Best thing to do is to test the autoinstalls on a virtual machine if possible, a scratch machine if not – and test until the installs are clean and unattended. Do this before your boss says you need to get that install done pronto!

Check the documentation for details; I’m currently setting up Lucid Lynx and will provide complete details later.