this weekend while giving a bit of TLC to the php packages, i thought i'd finally get around to tackling #490023 and similar bugs, which meant learning about how to use the triggers feature provided by dpkg. unfortunately documentation for this feature was in fairly short supply, and after extensive searching (and by extensive searching i mean typing "dpkg triggers howto" into a google search) i had a couple short manpages (dpkg-trigger(1) and deb-triggers(5)) and an overly verbose and possibly out of date /usr/share/doc/dpkg/triggers.txt.gz. none of these documents really gave a clear "big-picture" for how to get going either. so, as is often the case, i got distracted from my intended task and ended up on a little side-project putting together a nice howto/tutorial for how to integrate dpkg triggers into a package. note that there may be misunderstandings or inaccuracies in the document, as it's based on an afternoon's worth of hacking and q&a directed at #debian-dpkg (thanks to Guillem and Rapha l for fielding those questions). so if i'm off on anything, please feel free to let me know! to get started:

git clone http://git.debian.org/git/users/seanius/dpkg-triggers-example.git

and for those who are too lazy even for that, the README follows: The debian package triggertest This package is a dead-simple "triggers in a nutshell". It shows a few different ways that triggers can be used in practice, to hopefully cover most of the general use cases for triggers. The purpose of triggers Triggers are used to ensure that during the standard package-management process certain operations always run, but not more than necessary. For example:

• during an upgrade many packages might provide updated texinfo(5) documentation, and triggers are used to ensure that update-info-dir(8) is run without having to be run several unnecessary times from the maintainer scripts of package in question.
• if a system has both apache2 and PHP's apache2 engine installed, apache2 will need to be restarted whenever new php extensions are installed or removed. Without triggers it would be very disruptive (and inefficient) to explicitly stop and start apache by each PHP extension.
• update-initramfs(8) should be run once and only once after kernels are updated or certain other packages are installed/upgraded that would want to have a new initramfs generated.
• other expensive operations that are desirable to be aggregated and consolidated during installs/upgrades, such as update-texmf(8) or scrollkeeper-update.

How triggers work in a nutshell Trigger-using packages can be classified in two behavioral categories:

• Consumers: packages which declare triggers and thus can be "triggered"
• Producers: packages which activate triggers (explicitly or implicitly)

When a consumer is triggered, its postinst script is run with the arguments:

postinst triggered "<trigger1> ... <triggerN>"

i.e. $2 contains an iterable list of activated triggers. Note that if a consumer is going to be normally configured (i.e. it is also being updated), then no triggering may occur and thus the standard control flow of the maintainer scripts should still take care to handle this. A "trigger" is declared for the consumer by shipping a file in DEBIAN/triggers (in the case of debhelper based packages, ./debian/consumer-package.triggers will JDTRT). Useful RTFM: deb-triggers(5). Example:

interest /path/to/a/directory
interest my-second-trigger

This declares that the package in question is interested in two triggers. The first trigger has a leading path separator in its name, which instructs dpkg that any filesystem modifications underneath this directory by other packages should cause the respective consumer(s) to be triggered. The second name is completely arbitrary (and also global, so you should probably pick something reasonably specific and identifiable), and will only cause a trigger to be activated when a producer

1. ships its own triggers file with a corresponding "activate my-second-trigger", or
2. invokes the trigger explicitly in a maintainer script by calling "dpkg-trigger my-second-trigger".

Another perhaps useful RTFM: dpkg-trigger(1). Examples contained in this source package This source package produces a single "consumer" package and a number of different "producer" packages. The consumer is triggered in various ways, such as:

• Filesystem updates to a given directory from any other package
• "activate foo" from a producer's triggers file
• Activation from a producer's explicit call to dpkg-triggers

In this case the triggers correspond to an "update-foo" and "update-bar" command, which do nothing other than echo to the console that they are being run. In practice they'd correspond to updating some kind of database or restarting a daemon. More information For more information about triggers, see /usr/share/doc/dpkg/triggers.txt.gz, which will make a lot more sense having a working example like this package as reference. Especially useful is "Transition hints for existing packages", which can be used if you need to gracefully handle migrating in support for triggers across other packages not directly under your control. Corrections, suggestions, etc Are appreciated and should be sent to the author, below. -- Sean Finney seanius@debian.org Sat, 19 Sep 2009 15:57:48 +0200

One of my professional duties in my past ten years was monitoring systems. Even my diploma thesis was dedicated to distributed monitoring (altough my professor sucked badly). Apart from a few custom-programmed scripts to analyze special situations (e.g. proxy clusters) I used tools that fellow administrators will find familiar: Nagios and Cacti. And another less famous text-configuration-based monitoring tool called Cricket. That worked well somehow but Cricket was hard to learn for my coworkers and Cacti seems unreliable and fundamentally broken in terms of SNMP checking. Besides why do I have to set up availability checking in Nagios and set up checking of the same parameters in another software to draw graphs? Just recently I came across an open-source software I hadn t heard of before: Zabbix. And although it has a few rough edges it seems way more professional than other common tools (the commercial tools I saw are even worse than the open-source variants). I tried it and after a lot of reading and trying it looks like it has a good potential to replace Nagios and Cacti. So I thought I d sum up my personal experiences with all of these tools. Nagios. Their makers claim that it s the industry-standard in IT infrastructure monitoring . Honestly it s a great tool but considering how many years it has been existing it barely evolved. During my diploma thesis I wrote an alternative software that I called MrNetwork that dealt with flaws that Nagios hasn t even fixed today. Still Nagios is a tool I have used for many years and it is very reliable. Advantages:

• open source
• large community
• many powerful plugins (and own plugins are easy to create: just write a program that prints a one-line string and set a certain return code)
• easy-to-use web frontend
• debugging plugins is moderately simple.
  
• many thought-out features like host groups or notification options that make your life easier
  
• dependencies (so that you don t get 100 alerts if a router between the Nagios server and other servers went down)
  
• nagvis plugin with a great interactive editor that draws nice management-suitable graphs (although I found the ndo2db interface hard to set up at first and a little flaky)
  

Annoyances:

• The focus is on availability checking you don t get fancy graphs on the values that are monitored (e.g how the CPU load was over time). So you ll need a second tool and set up the same checks there just to get graphs. But availability percentages are computed automatically.
• Textual configuration that has so many different settings that you need to look up the parameters often. A web-based configuration would probably be better (and is available as an add-on but I haven t tested it).
• Third-party plugins are often very badly programmed and barely documented that it appeared easier to reinvent the wheel. ( Look, ma, I can has plugins. )
• Some views on the web interface are not very obvious (e.g. clicking on the title of a host group gives a nice view of all hosts with all services).
• Many plugins don t have corresponding configuration entries so you have to find out how they work and write configuration entries yourself (and those which are preconfigured take some archeology to find out which parameters they expect). This is a huge time-waster for beginners. And in your services configuration you have to verify your checks configuration to understand the meaning of each parameter. Or do you remember what check_http 80!john!doe!10!30!body is supposed to check?
• Every set of parameters of a certain plugin requires a distinct configuration entry. The plugins have dozens of configuration switches that you may need one day. Want to set a timeout on HTTP checks? Write another check configuration. Want to check for a certain string in the HTTP response? Write another check configuration. And so on.
• Most checks are run from the Nagios server itself (the NRPE plugin to do the checks on the respective remote systems somehow refused to work properly here) which is suboptimal and puts a lot of load on the server.
• By default every alert triggers a notification. So if you can t define proper dependencies (e.g. if you want to check your web server in all 30 supported languages and there is some logical error) then you will get spammed with alerts.

Cricket. As Nagios does not support plotting graphs of the monitored values I was in need of another piece of software. Basically Cricket is a frontend to RRD (which stores data in a rotating/round-robin file that keeps data of the last X minutes/hours/days). It has a textual configuration that takes a lot of getting used to. It s main principle is inheritance of settings they call it configuration tree . Which means you have a master DEFAULTS file that contains general settings like how to query SNMP. In a subdirectory you define a certain class of devices that you want to monitor e.g. routers (the DEFAULTS are inherited to this level). Within the routers directory you can just define a list of routers you want to monitor. All settings are inherited from above (parent directories). It s more a geek tool for shell lovers. Advantages:

• very quick to monitor a large set of similar devices once the general device class is defined
• simple web interface
• very reliable
• can monitor SNMP values (it does this very well) or execute external scripts thus can be easily extended
• flexible graphing you can sum up values of two graphs into a new graph (aka mtargets multiple targets)
• different check frequencies can be configured for different subtrees through cron (by default values are collected every 5 minutes this can be set as low as one minute if needed)

Annoyances:

• the textual configuration is error-prone (leading to funny Perl errors that can be hard to debug)
• users may expect to see all parameters of a certain device instead of all devices having a certain parameters ( Give me the statistics of router42 instead of Let s see the temperature of all routers we have. )
• customizing the graphs (drawn by RRD tool) isn t trivial
• Frequency of checks is by default 5 minutes. Before RRD can draw the first value of a graph it needs three values. So you ll be waiting 15 minutes before you see any results.
• RRD rounds data by default. So the yearly graph doesn t show the peaks that the daily graphs do. (This can be fixed by not graphing the average values but the maximum values.) Long-time archiving of graphed data is not possible without throwing away the RRD files and manually customizing them. Changing the monitoring frequency (aka heartbeat ) is not possible either without throwing away the data and starting from scratch either.
• No proper built-in alerting in case certain thresholds are exceeded.

Cacti. Another frontend to RRD and a pretty sophisticated one. Nearly everything is configured through its web interface. And the result is beautiful. It s not entirely reliable though and SNMP support (at least in version 0.8.7b) is a big fail. I like Cacti for its user interface is much better than Cactis but it s less reliable and flexible. Advantages:

• Beautiful and (for most features) simple web interface. Nice features like graphs that can be zoomed using Javascript.
• Fine-grained permissions system. So a certain user may get read-only access to a certain subtree.
• The tree where graphs are placed can be configured freely so you get exactly the view you want.

Disadvantages:

• Doesn t hide the RRD magic very well. The user is easily confused by templates, data sources and the like.
• Graphing sometimes just stops working for no reason or values are missing although the server isn t overloaded and other software doesn t show such outages. According to a quick search on the lazyweb I m not the only one with such effects.
• Setting up many systems means a lot of clicking in the web interface. Setting up new kinds of checks (aka templates ) means even more clicking and is very error-prone.
• The quality of some third-party templates I tested was pretty bad. Creating new templates is tedious, error-prone, frustrating and close to black magic. Nothing for the casual user at least.
• Doesn t handle SNMP correctly (this is the biggest fail in my opinion and makes it unusable here). Although it knows how to query indexes (e.g. ifDescr to get the names of your network interfaces) it just seems to stored fixed OIDs. So once the SNMP tables change the order or number of items (which isn t unusual) then suddenly other parameters get graphed.
• Frequency of checks is by default 5 minutes. Increasing the frequency leads to missing data and wrong results.
• As it uses RRD and needs 3 valid values you won t see that your monitoring fails until you wait 3 5=15 minutes. Not suitable for impatient non-smokers like me.
• Debugging failed checks is close to impossible. If a check fails then I find myself clicking around randomly trying to find typos because the alternative is digging around in database entries.
• The web interface is sometimes confusing. A refresh of SNMP tables is done by clicking a unmeaning green circle icon. Adding new items to a list is done by clicking an inconspicious Add link that doesn t even look like a link.
• Another UI confusion: graphs are created from the devices view. But they are deleted from the graph management view.
• No alerting in case certain thresholds are exceeded. Another tool like Nagios would still be needed to notify you.
• Can t sum up multiple targets so monitoring failover clusters doesn t work well.
• RRD averages data when putting daily values into weekly values, weekly into monthly and monthly into yearly. So the yearly graph doesn t show the peaks that the daily graphs do. (This can be fixed by not graphing the average values but the maximum values.) Long-time archiving of detailed graphed data is not possible (RRD). Changing the monitoring frequency (aka heartbeat ) is not possible either without throwing away the data and startin from scratch.

Zenoss. People pointed me to Zenoss which is supposed to offer the same functionality as other monitoring systems but is much more integrated. So this short list is more a quick one-day-experimental expression than a thorough analysis. But in the end much of the fuss is just marketing. Advantages:

• Beautiful web interface
• Nice gimmicks like google maps integration to show you where your servers are down worldwide. Only makes sense when monitoring networks with several/many remote locations.
• Can partly discover parameters of systems automatically. That works for static routes (although I wonder why the heck I want to monitor static routes), file systems and network interfaces. On the other hand processes can t be discovered automatically and have to be set up manually.
• Does not come with a specific agent but plays rather well with plain old SNMP.
• Can monitor Windows through native WMI.
• Large fanbase.

Annoyances:

• Web interface feels slow (Zope is bloated)
• Opaque operation. It does not tell what s actually going on. You can add monitoring and check back later if anything worked they way you want.
• Questionable reliability. In a test here I was monitoring a running process. The process was said to be down and suddenly went to up after a while although nothing had changed on the system.
• Just one dashboard. Several dashboards similar to Zabbix screens would be nice.
• Configuration and data is spread across MySQL, the internal Zope database storage and RRD files on disk.
• The dependency graph is a nice Flash-based applet displaying how the systems are connected. But it does not show any details about the systems aside from whether they are up or down. And clicking on a host does not take you anywhere but center on the system. Beautiful but it could do so much more than just look beautiful.
• I dislike the way that things are configured. The context menu with the down arrow needs to be used. I d prefer simple add or delete actions instead of navigating the menu all the time. Looks like Javascript is used wrongly here.
• Limited open-source version. Full version needs to be paid for.

Zabbix. This is the tool I have been evaluating for the past two weeks and currently I m moving all checks away from Nagios and Cacti and put it into Zabbix. So the following list is more a first impression instead of a year-long experience. (I m using Zabbix 1.6.5 here. Debian Lenny s 1.4 version lacked some interesting features like proper SNMP handling so I backported the newer version to Lenny.) Zabbix seems very close to the perfect monitoring system I had always dreamt of. I would have designed it differently in some aspects though. Advantages:

• Availability Monitoring (like Nagios) and graphing (like Cacti) is combined into one tool.
• Highly configurable. User John may just get an SMS for problems of high severity during the weekend and on weekdays get a Jabber message. Even automatic actions like restarting services can be set up.
• The notifications actually help the person who gets the message. Low disk space on /var on web5 with an additional comment is pretty helpful even when sent via SMS.
• Very performant. The remote agent gathers the information on each system.
• Fast web interface.
• Sophisticated monitoring of web sites. Zabbix can follow a path of simulated mouse clicks on a web site and check for functionality and response time.
• Real-time graphs. Values are by default collected every 30 seconds. You quickly see where you are going.
• Permissions system. Certain users can be limited to certain views.
• Gathered data is stored in a database (MySQL, PostgreSQL, SQLite) instead of an RRD file. Storage periods (aka history ) can be configured freely. Backup up the database is all there is to be done.
• Agent for remote checks simply works (and is available on Debian Lenny) and can even call scripts or shell one-liners to gather information. The agent can gather a lot of information locally and send it to the Zabbix master server. Works on several operating systems and even on Windows (just set up monitoring of Windows services and processes successfully).
• Templates (that can even link to further templates) save time in setting up many checks.
• Graphs (plots of values over time) can be customized like which items are plotted and in what way. Even pie charts are possible.
• Even the parameters that don t get an explicit graph can be graphed at any time. E.g. the agent has tracked the CPU load on a system that you never cared about then you can graph that with one mouse-click.
• Screens and slide shows can be used for high-level views (aka dashboards ) or to be displayed on a big geeky display. They can combine textual display of the status as well as clocks, ad-hoc graphs or predefined graphs.
• Very flexible trigger expressions. For example you can tell a trigger to fire if the average system load over the last 15 minutes is above a certain value. As all measured parameters are stored in a backend database you can use all kinds of mathemical expressions. Like firing a trigger if the average number of running processes during the last half hour is above 50. All other software I tested just has access to the last value gathered.
• Customized alerting is simple through shell-based alert scripts.
• Remote monitoring made easy by using a Zabbix proxy.
• Paid support and paid custom programming available. But the software is completely open-sourced.
• 320 page PDF manual with screenshots and nice references. (Although I d personally prefer an online help. Currently the ? link within the web interface just points to the PDF that you can download.)

Annoyances:

• A lot of mouse moving and clicking is required to set up things. For example setting up an alert if the free space on a disk on a certain server is getting too low then you need to set up hosts, items, triggers and actions. Some of the clicking seems redundant. E.g. I didn t find a way to create triggers automtically for a set of checks. If I monitor how full the /home partition is then I d like to set a threshold in the same configuration step.
• Takes a little patience understanding the concepts although they make sense after half a day.
• The web interface is crammed full of features. For casual users it s confusing to navigate.
• The map editor is close to unusable. You can put icons and connections into the graph but have to define the X and Y coordinated manually. This feature is nice but desperately needs a good interactive map editor like nagvis uses.
• Does not detect the available assets in a monitored server automatically. Imagine that you want to monitor the space on all disk partitions on a system. You will have to copy over or create the check items manually or define all possible checks in a template and disable those you don t need. Cacti handles that better by offering you a list of partitions to monitor. Zenoss can do that partly. The zabbix agent should be able to handle such a service discover automatically. (The built-in Discovery feature rather seems to detect new servers in a given network range automatically. But that s something different.)

See also: Ben Rockwood s blog Further similar software I didn test thoroughly: Hyperic and Opsview (I ll surely update this blog post while I learn more about Zabbix.) All of the above tools are great. I m not meaning to say that Zenoss is total crap for example. The differences are subtle. And whether a piece of software suits your needs really depends on your expectations. I love that all this software is available as open-source. And a totally unscientific but fun analysis of the community is counting the number of active people in the respective channels on the Freenode IRC network:

• #nagios: 133 users
• #cacti: 58 users
• #cricket: 2 users
• #zenoss: 54 users
• #zabbix: 61 users

Either Nagios has the largest fanbase or perhaps that means that the majority of people needs help with it.

Over on Planet Ubuntu there is a VRMS meme winding down. Usually I tend to think web log aggregator memes are an abomination, however, this one is a little more interesting, especially if Debian folk pick it up. It seems like many Planet Ubuntu posters require some non-free stuff, examples include; graphics and other drivers/firmware, Flash (Gnash/Swfdec aren't there yet), Sun Java (despite OpenJDK), RAR 3.0 archives, LHZ archives (despite jlha), Microsoft fonts (despite ttf-liberation), icon themes, ICC profiles, mind mapping, support for codec DLLs from Windows, VirtualBox drivers for Windows, the Opera web browser, games and other things. For Debian users, the popcon information pretty much confirms the above issues. Some other stuff Debian users use that isn't in Debian include; patented codecs, skype, acroread, the non-free version of VirtualBox and more. Next, lets get in on the getting your meme on part. On my Dell Inspiron 6400 laptop I have following Debian non-free/contrib stuff installed; firmware-iwlwifi, gcc-doc, gcc-doc-base, gcc-4.3-doc, autoconf-doc, gdb-doc, make-doc. On my OpenMoko FreeRunner phone I have nothing installed from Debian non-free/contrib. My wireless router and ADSL modem don't run Debian. The wireless router is a MIPS-based Netgear WGR614L (that is marketed as supporting DD-WRT, OpenWRT and Tomato) so I could conceivably install OpenWRT etc or Debian on it, but I haven't gotten around to that yet. The ADSL modem is a MIPS-based Siemens SpeedStream 4200, but it looks like that would require a significant amount of effort to get running FLOSS. Lets ponder my laptop freeness a bit more. The docs are all FSF-free, but not DFSG-free. It appears they are not DFSG-free because the FSF will not allow 28 words of FSF/GNU advertising to be removed (I'm not sure if Debian or the FSF is more pedantic). I'm not aware of any DFSG-free alternatives to them and I don't particularly care about the restrictions. My wireless card is an Intel 3945ABG mini PCI card that requires the kernel to upload the iwlwifi firmware before it works. Intel refuse to release firmware source code under a free license, citing FCC requirements. I'm not aware of any free firmware (or firmware reverse engineering efforts) for this device so the only alternative is to use wired Ethernet or buy another wireless card. Ethernet wires everywhere would be very inconvenient, so I've been thinking about trying to replace the card or laptop as soon as I am able. Since Atheros has released GPLv2 firmware for its AR9170 802.11n USB chipset I'll probably get something released by Atheros. I wonder why the FCC didn't prevent Atheros from releasing modifiable firmware, perhaps Intel will change their position too. So, what other software is on my laptop apart from Debian? Lets see, nothing on the HD apart from GRUB 2, /boot containing a Linux image/initrd from Debian and the LUKS partition containing swap and the Debian ext3 rootfs. Coreboot laptop support seems to be in the very early stages so I have no alternative to the supplied Dell BIOS at the moment. There is also the CPU microcode and other firmware installed in the various devices on the system, at least the HD, Ethernet, Bluetooth, GPU, DVD drive etc. have some kind of firmware in them. Some of this firmware is updatable using software from the Dell Linux repositories. Lets ponder my phone freeness a bit more. On it I have two copies of the u-boot bootloader (one in the protected NOR flash), u-boot is free. The NAND flash has an old Qt Extended Improved (QTEI) install that I need to copy stuff off and wipe. I also have a 4GB microSD card containing QTEI, Debian, FDOM and SHR. Now that QtMoko has brought QTEI to Debian packages I can probably ditch the QTEI install. I read that OM2009 is being merged into SHR so I can get rid of FDOM. That leaves SHR and Debian/QtMoko (nothing non-free). IIRC SHR does contain some firmware for devices that the OpenMoko FreeRunner doesn't contain, but that will get removed as Linux upstream moves more and more of that into linux-firmware.git. Nothing more on the main flash or microSD storage, so what else? The OpenMoko contains lots of hardware, but the main problematic devices here are the AR6000 Wi-Fi chip and the TI Calypso GSM device. The AR6000 is an issue because the firmware embedded in the chip is non-free and FullMAC so it is hard to add new features like AP mode or improve the connection quality/etc. In addition the firmware currently on the device is a development version of a 2.0 version (1.x was apparently broken) and further development does not seem to be happening yet. Since Atheros GPLed the AR9170 firmware I idly wonder if they could be convinced to release the source and GPL the AR6000 firmware. Perhaps a life-size gold statue of RMS would help there. The GSM device is problematic because of various bugs in the firmware. It apparently is an ARM chip with Nucleos, so perhaps uCLinux or something could be ported to it or written for it. There has been at least one discussion about hacking the GSM firmware (thar be dragons). Searching for some keywords extracted from the end of the first mail in that thread lead to some interesting results indeed. Lets ponder my network freeness a bit more. I should allocate some time to investigate putting Debian on my wireless router and ADSL modem. These generally just work except the ADSL modem reboots itself a lot during the summer. The just-works status of these devices means that messing with them is problematic in case I brick them (luckily I have a spare for the ADSL modem though). I presume OpenWRT and similar have replacements for all the software on my wireless router, drivers may be an issue though. I use gmail for reading email lists, mainly because of intertia, cheapness and because the interface has no GUI FLOSS peers yet (sup-mail exists for console use). TangoGPS, OpenStreetMap and other tools are slowly replacing my use of Google Maps, although I imagine routing will remain an issue for many years yet. One of the tech groups I'm involved in uses Plesk as a hosting control panel, mainly out of intertia, I'm not familiar with any FLOSS replacement though. Some of the upstream FLOSS projects I'm involved with use sourceforge as a hosting platform. There is a certain level of lock-in with SF.net, most of the data is easily exportable though. Lets ponder my software freeness in comparison to Planet Ubuntu posters. I have no freeness issues with drivers at the moment, however firmware seems likely to have freeness issues for a long time to come. I've avoided the need for the Adobe Flash Player by using swfdec and clive for downloading videos for some sites. swfdec works OK for some sites, some that I care about where it doesn't work and clive cannot download video include Vimeo, abc.net.au and sbs.com.au. For Vimeo you can download raw video if you have a login, but I do not, bugmenot is unreliable and Vimeo doesn't seem to be accepting new registrations. SBS I watch on television and ABC I get no reception so I just don't watch it. Java isn't an issue now that OpenJDK exists. I sometimes need to extract RAR 3.0 archives, which I do by copying the files to a friend's Windows machine or using a RAR extractor website. There is no free implementation of a RAR 3.0 extractor yet. I seem to remember that there is source code for a non-free extractor so presumably a clean-room documentation and reimplementation effort could fix this. I don't encounter LHZ files, but jlha-utils is available for if I do. I feel no need to install Microsoft fonts since the Liberation fonts and DejaVu meet my general font needs and Debian contains fonts covering all the scripts of Unicode (except for about half the huge amount of Han characters). In my music collection, only the Voxware audio codec and DigiTrakker MDL files are not supported by Rhythmbox, but I don't really miss those few tracks. I rarely have audio/video codec issues with video from the Internet. I don't have a use for Opera. Thanks in part to the efforts of the Debian games team, games from Debian main (such as warzone2100) satisfy my gaming needs. I just don't use Skype. Overall, I'm generally happy with my level of software freedom. My main strategy for preventing regressions in my software freedom is to just avoid doing things that require non-free software. The most problematic FLOSS issues for me are Flash support (adoption of the HTML5 video tag will resolve this for me), RAR 3.0 support and firmware. Please feel free to contact me with any comments or questions. Happy Software Freedom Day everyone!

Modern daemon implementations can be run in a variety of ways, in a range of contexts. The daemon software itself can be a useful tool in environments where the associated traditional system service is neither needed nor desired. Unfortunately, common debian packaging practice has a tendency to conflate the two ideas, leading to some potentially nasty problems where only the tool itself is needed, but the system service is set up anyway. How would i fix it? i'd suggest that we make a distinction between packages that provide tools and packages that provide system services. A package that provides the system service foo would need to depend on a package that provides the tool foo. But the tool foo should be available through the package manager without setting up a system service automatically. Bad Examples Here are some examples of this class of problem i've seen recently:

akonadi-server depends on mysql-server

akonadi is a project to provide extensible, cross-desktop storage for PIM data. It is a dependency of many pieces of the modern KDE4 desktop. Its current implementation relies on a private instantiation of mysqld, executed directly by the end user whose desktop is running. This means that a sysadmin who installs a graphical calendar application suddenly now has (in addition to the user-instantiated local mysqld running as the akonadi backend) a full-blown system RDBMS service running and potentially consuming resources on her machine.Wouldn't it be better if the /usr/sbin/mysqld tool itself was distinct from the system service?

puppetmaster depends on puppet

Puppet is a powerful framework for configuration management. A managed host installs the puppet package, which invokes a puppetd service to reconfigure the managed host by talking to a centralized server on the network. The central host installs the the puppetmaster package, which sets up a system puppetmasterd service. puppetmaster depends on puppet to make use of some of the functionality available in the package. But this means that the central host now has puppetd running, and is being configured through the system itself! While some people may prefer to configure their all-powerful central host through the same configuration management system, this presents a nasty potential failure mode: if the configuration management goes awry and makes the managed nodes inaccessible, it could potentially take itself out too. Shouldn't the puppet tools be distinct from the puppetd system service?

monkeysphere Build-Depends: openssh-server

The Monkeysphere is a framework for managing SSH authentication through the OpenPGP Web-of-Trust (i'm one of the authors). To ensure that the package interacts properly with the OpenSSH implementation, the monkeysphere source ships with a series of test suites that exercise both sshd and ssh.This means that anyone trying to build the monkeysphere package must pull in openssh-server to satisfy the build-depends, thereby inadvertently starting up a potentially powerful network service on their build machine and maybe exposing it to remote access that they didn't intend. Wouldn't it be better if the /usr/sbin/sshd tool was available without starting up the ssh system service?

Good ExamplesHere are some examples of debian packaging that already understand and implement this distinction in some way:

apache2.2-bin is distinct from apache2-mpm-foo

Debian's apache packaging recently transitioned to split the apache tool into a separate package (apache2.2-bin) from the packages that provide an apache system service (apache2-mpm-foo). So apache can now be run by a regular user, for example as part of gnome-user-share.

git-core is distinct from git-daemon-run

git-core provides the git daemon subcommand, which is a tool capable of providing network access to a git repo. However, it does not set up a system service by default. The git-daemon-run package provides a way for an admin to quickly set up a "typical" system service to offer networked git access.

vblade is distinct from vblade-persist

vblade offers a simple, powerful utility to export a single file or block device as an AoE device. vblade-persist (disclosure: i wrote vblade-persist) provides a system service to configure exported devices, supervise them, keep them in service across system reboots, etc.

Tools are not Services: a ProposalLet's consider an existing foo package which currently provides:

• the tool itself (say, /usr/sbin/foo) and
• sets up a system service running foo, including stock foo daemon configuration in /etc/foo/*, startup scripts at /etc/init.d/foo, service configs at /etc/default/foo, etc.

I suggest that this should be split into two packages. foo-bin would contain the tool itself, and foo (which Depends: foo-bin) would contain the service configuration information, postinst scripts to set it up and start it, etc. This would mean that every instance of apt-get install foo in someone's notes would retain identical semantics to the past, but packages which need the tool (but not the service) can now depend on foo-bin instead, leaving the system with fewer resources consumed, and fewer unmanaged services running. For brand new packages (which don't have to account for a legacy of documentation which says apt-get install foo), i prefer the naming convention that the foo package includes the tool itself (after all, it does provide /usr/sbin/foo), and foo-service sets up a standard system service configured and running (and depends on foo). Side Effects This proposal would fix the problems noted above, but it would also offer some nice additional benefits. For example, it would make it easier to introduce an alternate system initialization process by creating alternate service packages (while leaving the tool package alone). Things like runit-services could become actual contenders for managing the running services, without colliding with the "stock" services installed by the bundled tool+service package. The ability to create alternate service packages would also mean that maintainers who prefer radically different configuration defaults could offer their service instantiations as distinct packages. For example, one system-wide foo daemon (foo-service) versus a separate instance of the foo daemon per user (foo-peruser-service) or triggering a daemon via inetd (foo-inetd-service). One negative side effect is that it adds some level of increased load on the package maintainers if the service package and the tool package both come from the same source package, then some work needs to be done to figure out how to split them. If the tool and service packages have separate sources (like vblade and vblade-persist) then some coordinating footwork needs to be done between the two packages when any incompatible changes happen. Questions? Disagreements? Next Steps? Do you disagree with this proposal? If so, why? Unfortunately (to my mind), Debian has a long history of packages which conflate tools with services. Policy section 9.3.2 can even be read as deliberately blurring the line (though i'd argue that a cautious reading suggests that my proposal is not in opposition to policy):

Packages that include daemons for system services should place scripts in /etc/init.d to start or stop services at boot time or during a change of runlevel.

I feel like this particular conflict must have been hashed out before at some level are there links to definitive discussion that i'm missing? Is there any reason we shouldn't push in general for this kind of distinction in debian daemon packages? Tags: daemons, packaging, policy

[So much for at-least-one-post-a-week : I'm now back online, courtesy of a new router]. In the this week is another announcement from the CoRoT group: CoRoT-7 is the first star (outside our own) known to host two Super-Earths. Two planets of 1.6 and (max.) 21 times Earths' mass, and the smaller one at least is rocky (the outer planet has not been seen in transit, so we can't tell yet). Its not the first Earth-sized planets to be discovered: as my supervisor points out, <http:>PSR 1257+12 holds that record, as well as the one for the first exoplanet to be found. As usual, Exoplanet.eu gives the details: CoRoT-7b has a flurry of papers to its credit already. CoRoT-7b transits its star and is the first Super-Earth with a clear radius measurement. Together with a mass calculated from a radial-velocity measurement by the HARPS spectrometer, they calculate a density of 5.5 g/cm3, and so its shown to be a rocky world. CsoRoT is a hot A-class star, and CoRoT-7b orbits only 2.5 million km from it. Because of this, it is unlikely that it has retained an atmosphere (it'll be way too hot), and is expected to be tidally locked: with one face permanently pointing at the star, one in permanent darkness, the two sides will be both too hot and too cold for life. (Is there a Goldilocks, twilight zone? unlikely: the tidal forces will be too high, and with no atmosphere to moderate matters, there can be little hope for life). Still, while it may not support life, it could help answer important questions, such as how many terrestrial planets are there out there. Most of the planets discovered to date have been gas giants, which are easier to discover. But are there lots of rocky planets hiding between the giants ? One way of answering this might involve the disks from which the planets evolved. One trend we've seen is that (gas giant) planets are more likely to be found around stars with high metallicity (astronomers are strange in calling all elements heavier than helium a metal). But our Sun is strange in being comparatively depleted in 'refractory' elements such as iron or silicon. Is this important for the story of terrestrial planets? Melenendez et al. have a paper on arxiv.org on this topic. They find that most stars similar to our sun found not to have giant planets have elemental abundances similar to our Sun: perhaps they have undiscovered rocky planets instead ? Tags astronomy, exoplanets, planet-of-the-week

Email on a desktop Unix system is apparently a hard topic. At least, so far nobody seems to have solved it to my satisfaction... That's where the Pony Express comes in: a sensible /usr/bin/sendmail implementation for desktop sysstems:

• No queue, no running processes.
• pass users' email to a mail hub
• support per user outgoing mail hub and SMTP authentication + TLS.
• still allow local mail delivery, so stuff like cron will deliver to local mailboxes.

Mercurial repository is available; Pony Express is written in Python 3. I'll not upload a Debian package right now since as far as I've seen Python 3 is not supported by the usual Python helper scripts. Status: Lots of missing features and probably lots of bugs, but I use it from kmail to deliver mail, and the commandline "mail" also works. But that's the extent of the testing it has received so far, and in addition it's also one of the first things I've ever done in Python, so consider yourself warned. Still, feedback and patches welcome. Update: Daniel, no, I can't. I missed msmtp when I looked for a solution after I saw that nullmailer and ssmtp wouldn't do what I wanted. Update: cate / simon: my apt-cache search skills obviously suck, I didn't find esmtp either. Oh, well... I wanted to learn Python anyway, and since Pony Express is basically a frontend to Python's smtp library, it was not that much work. lamson sounds interesting for other projects, I'll have to look at it. From the description it's not what I want here, though. Marius: kmail does its own queueing, so I usually use the send later option and send non-local email from the commandline only while connected. I'll have to think about a non-daemon, non-cron queue style that suits my need (event-triggered from if-up.d perhaps), but as soon as I start to accept mail that I can't immediately get out of the system complexity goes up quite a bit. Developing PX into a full MTA would still be a fun project and I've got a few other ideas that I could incorporate. Not tonight, though ;-)

Over the last few years, I've been pretty immersed in the world of wikis. A wiki is like a collaborative web site; it lets several people view and edit a web page and link to other pages, maybe new pages that they themselves create. Wikis let tech-savvy people all over the world collaborate on a single web page, a single document. That's a pretty powerful idea, really. The obvious thing to do once an idea like wikis appears is to attempt to cram all of humanity's knowledge into it. Well that's just crazy enough to work. Wikipedia is the gold standard of wikis. It's a collaborative encyclopedia with lots and lots of articles. As the gold standard, it influences people's thinking about wikis in ways that might not be quite true. If Wikipedia were the only wiki you'd ever heard of, you might think that wikis are used to create encyclopedias. If that were true, you'd really only need one of them. If Wikipedia were the only wiki you'd ever heard of, you might be under the false impression that all wikis everywhere are editable by anyone. So if you create a wiki page, it's no longer yours. Other people can scribble on it. Well, some kinds of documents perhaps just aren't suitable for being edited by anyone, and the good news is that you can build a wiki for you and your classmates, or you and your coworkers, and you can decide who gets to edit what. I want to think about a few distinct uses for wikis in different contexts. The most common use is of course to create a knowledge repository; a collection of information written by people who know what they're talking about. That's what Wikipedia is, mostly. That's what the Haskell Prime wiki (which I run) is. And the excellent wiki about the game of Go, Sensei's Library, is also a knowledge repository. But there are other uses for wikis that are pretty cool. I often have to work on proposals with my coworkers. One (horrible) way to do this is to write the first draft in MS Word, email it to everyone, who might edit it and email it back. Of course, only one person can actually edit it at a time, otherwise I have to figure out what everyone did and merge their changes by hand. That's what we, in the computer industry, call teh suck. A better way to do this is to use a version control system, which lets multiple people work on a document at one time. Of course, if you're editing evil document formats like Word, still only one person can edit it at a time, but at least you cut out email, so things are a bit better organized. But wikis are actually a really great way to work on a document with another person. Two or more people can each collaborate on the document using the wiki software over the web. What becomes of the document at that point depends on its ultimate use. Maybe you have to convert it to MS Word or PDF at the end. That's a bit of a bummer. So there are two uses of wikis that I've mentioned: building a knowledge repository, and collaborative writing. Google started a service for collaborating on documents called Google Docs & Spreadsheets, which is probably useful for collaborative writing, but not knowledge repositories. They also acquired a wiki startup a few days ago, so they are clearly trying to get all over this space. There's another very interesting use of wikis that I'll call situation awareness. You can get a really vivid picture of this use of wikis if you take a look at the wikipedia article on the July 2005 London bombings. By the way, I didn't discover this excellent example of situation awareness using wikis. I saw it in the slides for a talk, but I don't know the original source at this point. If you go to that link, you'll see an excellent and up-to-date encyclopedia article about the London bombings. It's not a news article. Go to Google News and try to find a news article from a major news source which is this detailed, up-to-date, and well organized. Most articles you'll find are a snapshot, taken at a particular point in time (when the article was published) that most likely contains an account of the latest developments, and usually brief background in case you missed previous stories. The wikipedia article isn't a snapshot, it's an article that explains things in a logical order, which isn't necessarily chronological. Each wikipedia article contains a link to its own history. You can look back over time and see the article evolve. If you look at the early edit history of that London bombing article, you'll notice something fascinating. The article was created shortly after the bombing, with an account of the information that was known at that time. Within an hour, many people had edited the article, adding information they know about. If you were refreshing that wikipedia entry over & over (or if you were subscribed to it using RSS), you'd see not an account of just the latest developments, but an evolving, logical understanding of the attacks. The article started evolving right away, and it continues to evolve to this moment. That's what I'm calling situation awareness. Don't get me wrong, the mainstream news media is quite good at situation awareness. They do it a bit differently, and their articles or TV stories don't become integrated into a knowledge repository like wikipedia. I've enumerated three somewhat overlapping uses for wikis that I think are pretty interesting to examine:

Knowledge Repositories, which are a lot like encyclopedias,

Collaborative writing, which is a bit like a more elegant version of emailing word documents, and

Situation awareness, which isn't so different from the news; it draws from the news as a source, it can also be authored by the eye-witnesses themselves, and each story becomes an integral part of a knowledge repository. I don't claim that these are an exhaustive, nor are they a partition: Wikis are also used for bug tracking and as web discussion forums, for instance. What other categories can you think of? Email me if you have ideas.

Over the weekend I updated a small app I wrote for my local bushfire brigade from Rails 1.2 to Rails 2.3. Given it's small size, all-encompassing test suite, and general lack of mission criticality, I decided to bite the bullet and just kick up straight to Rails 2.3.2, and fix whatever broke. I was expecting quite a bit of fun and games. Well, there was fun, and there were games, but it was all relatively painless. I had to run rake rails:unpdate, add a couple of session config lines to my environment.rb, and get rid of a bunch of testing plugins that had been superceded by functionality in core (which involved me rewriting an awful lot of XPath into CSS selectors -- a massive net win, I have to say), but the core code of the application was completely unchanged (not a single line changed in the app directory). Given the number of major releases I leapt, and the fairly haphazard way in which I did it, I am quite pleasantly surprised at the outcome. Kudos to all the Rails hackers who made it possible.

When the first thing I thought of when I saw this baby outfit was "What sort of cretin wrote that code?", rather than anything more "paternal"?

Yesterday I had one of the more stressful and eventful 40 minutes of my life... events basicly initiated by the fact that I arrived at Schiphol airport 40 minutes before my plane was scheduled to take off. The first thing I noticed was that the queue for security extended beyond the check-in desks next to it, so just that bit would probably take more than fourty minutes. Oops. What are all those people doing flying out on friday noons? Second thing I couldn't help to notice is that the check-in desk was actually already closed, double-oops. Well, the lady that was sitting there anyone concluded after a phonecall that my bag was fine as hand luggage and so that I could still make it. She also queue-jumped me straight to the security X-ray machine and ordered me to run from there on. Well, not so fast, running through security isn't appreciated. Actually, since I planned to check-in this bag, I kind of violated this whole anti-liquor^Wliquid silliness with no less than 7 items. The guy that unpacked my luggage let me keep my lenses fluid, and forgot to notice 3 of the items, so damage was limited, and I proceeded with my explosives, I mean, toothpaste and such, to the gate. In my hurry to run to the gate, I put my boarding pass in my pocket... and upon arrival at the gate, I noticed my boarding pass was gone, so I went ask some lady at the desk there about it... and overheard the guy next to her, who was on the phone, mention my last name. "Someone found your passport". Turns out they also had my boarding pass, but I appreciated knowing where my passport was anyway, since obviously I didn't have it on me anymore either. So within a minute I was running off again to a different gate to pick up those two sort-of-important items. You'd say that after having once seen my plane taxi away from an empty gate upon returning there from picking up my boarding pass from lost&found for the second time that very morning would've taught me a lesson... But apparantly not. Back at the gate I was getting past the boarding pass checkpoint, and the person over there saw my pass, and said "Hey, so you're that guy that a bit ago lost this and that at the security checkpoint?" Since that happened at the other end of the airport, gossip must be going pretty fast at Schiphol... At least I've never showed up at the airport at the wrong date (unlike two of my friends I'm meeting over here managed to do each independently)... Yet.

For a while now, the last four or five months at least, I have been using planetplanet for RSS and Atom aggregation, or in english, reading a bunch of websites on one page. Planet is a bit of a hog, mainly in the disk acresses. This is a bit of a problem on hades, whose disk's aren't wonderful. Dan has been nagging me to use rawdog for a while, so this morning it floated to the top of the todo list, and stealing his config and one line of shell gave me a sorta working instance with the same feeds:

grep "^\[h" ~/usr/planet/lupin/config.ini   sed "s/\[//"   sed "s/\]//"
  awk ' printf("feed 1h %s\n", $1) ' >> .rawdog/config

I'm going to leave it for a bit to see if I like it, and to sort how I want it laid out, but its now in cronand planet isn't, so the worse abuser of hades should be gone.

I was reading xkcd by clicking on the random link when I noticed that the same cartoons were coming up again and again. I was wondering if this was Confirmation bias on my part or a duff random number generator on the server's part. Randall Munroe is a science geek, and I figured what he would do is test this idea... One python script and 12,000 (approx) requests later, I had a file full of numbers and started trying to remember some statisics. I threw together a quick bit of python to work out the mean and standard deviation (its here). The mean value is 97.4155602788 and the standard deviation is 171.040683155. If they are uniformly distributed from 1 to 361, the expected mean would be 104.211323761 and the standard deviation would be 181.0. So I was lost in thought for a while. However, the following quick check threw some light on the difference.

>>> data = [int(x) for x in open('numbers.data')]
>>> for x in xrange(0, 361):
...   if x not in data:
...     print x
... 
0
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360

So comics numbered about 338 don't appear. And recomputing the mean and standard deviation for 1 to 337 gives a mean of 97.2830920561 and a standard deviation of 169.0, which is about the mean and standard deviation the data gives. I'm now waiting for someone who actually knows stats correcting me in where I went wrong. The conclusion? I suffer from confirmation bias :-(. For those who like pretty pictures, here is one, courtesy of the Google charts API and pygooglechart: code here

For some time now I'm using a dual monitor setup with my Radeon 9200 SE (RV280). Basically this works quite well, except that I need to enter these commands manually:



Without these settings krandr is unable as well to detect both monitors properly. And it's not remembering the settings when I close/save the session by logging out. I tried to add the above code lines in ~/xinitrc as well as in /etc/X11/xinit/xinitrc, but they are not executed as after a restart of X I end up with the wrong monitor being the primary instead of the DVI display.

My xorg.conf is this:



So, dear lazyweb, what's wrong with this setup and how can I fix it?

Hi lazyweb, I m wondering if there a lot of demand for such a feature, being to be able to install 2 (or more) major releases of iceweasel on the same computer. If there is a strong demand, I may consider allowing it. Please reply in the comments on this blog with your feelings, for or against the implementation of this co-installability. Thanks. PS: you may also forward this query to other sites and send people back here to leave their opinion.

There will be an EU crackdown on websites selling consumer electronic goods which is entirely understandable when 203 out of 369 sites appeared to break the law. (first seen on BBC News) If you re a shop owner, the good site and bad site examples are pretty good, while local trading standards offices advise on selling online. If you re a buyer, see my guide on How to Check Web Shops for Basic Security. Why is it so bad? Do companies not understand the law? Do they not bother to check the law? Do they deliberately decide to ignore it? Don t customers prefer law-abiding web shops, or are low prices attractive enough to overcome that?

I maintain several xen machines. Most servers that i maintain use serial consoles (i should probably write another post in more detail about why serial consoles are the One True Way to manage a server). Trouble is, the way that xen works with the serial console has changed between etch and lenny. So what's changed? From what i can tell:

• The way that the dom0 Linux kernel interacts with the hypervisor's console has changed between Linux 2.6.18 (etch) and 2.6.26 (lenny), and
• the Xen hypervisor's method of specifying the console itself has changed between Xen 3.0.3 (etch) and 3.2.1 (lenny)

In etch systems, i had a standard GRUB specification like this (as noted earlier):

title           Xen 3.0.3-1-i386-pae / Debian GNU/Linux, kernel 2.6.18-4-xen-686
root            (hd0,0)
kernel          /xen-3.0.3-1-i386-pae.gz dom0_mem=131072 com1=115200,8n1
module          /vmlinuz-2.6.18-4-xen-686 root=/dev/mapper/vg_monkey0-dom0 ro console=ttyS0,115200n8 
module          /initrd.img-2.6.18-4-xen-686
savedefault

but in lenny, i find it necessary to do this:

title           Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-2-xen-686
root            (hd0,0)
kernel          /xen-3.2-1-i386.gz dom0_mem=131072 com1=115200,8n1 console=com1
module          /vmlinuz-2.6.26-2-xen-686 root=/dev/mapper/vg_monkey0-dom0 ro console=hvc0
module          /initrd.img-2.6.26-2-xen-686

In particular, the hypervisor itself needs an additional console=com1 argument to make sure that it uses the serial console (i suppose the com1=... argument simply specifies how to use the serial console should you need it, instead of a requirement to use the console). And the Linux kernel itself for the dom0 needs to adopt hvc0 as its console, which i believe is an acronym for something like the "hypervisor virtual console" -- this way, the dom0 kernel will come out multiplexed over the hypervisor's console, no matter where that hypervisor's console is directed (you might not even need to specify this explicitly -- it might be set up by default). When i tried to use the etch settings for the console with the lenny hypervisor and kernel, i saw the hypervisor try to come out on the video card, and a dom0 crash!Tags: serial, serial console, xen

RCBW - week #2 The RC squashing game has apparently worked fine for me also this week, and it has been as fun as the first . This week summary follows.

• 07/09/2009 bug #543128 - ipython - rename (build) deps: python-zope -,. interface
• 08/09/2009 bug #543111 - oprofile - fix the build-dep on automake to automake1.10
• 09/09/2009 bug #527792 - apertium-en-es - fix build w apertium 3.1, thanks tv for the patch
• 10/09/2009 bug #468624 - discover-data - get rid of python-xml, porting some scripts (part of the patch from Ben Hutchings)
• 11/09/2009 bug #527799 - apertium-eo-ca - fix build w apertium 3.1 (build-deps and configure.ac)
• 12/09/2009 bug #527788 - apertium-eo-es - same patch as above
• 13/09/2009 bug #534077 - artha - FTBFS due to (back then) broken wordnet (now fixed)

PS the horrible acronym in the title stands for "Release Critical Bugs of the Week"; it is part of my shameless marketing campaign to make the initiative spread.

Low-bandwidth versions of the recorded talks are now available. There are currently two exceptions:

• Some of the music for 'Welcome to DebConf 9' is licenced as CC BY-NC-ND, which unfortunately doesn't allow use in a video. I'm discussing this with Marga and hope to upload a new version soon.
• 'Debian por dentro' has a piece missing which should be restored from tape.

While the master versions of all these talks have been checked, not all the generated low-bandwidth versions have. Please let us know on debconf-video@lists.debconf.org if there is something wrong with them other than the following:

• A few of the recordings were unfortunately incomplete; this is indicated by a fade-in or fade-out
• Some of the recordings are in two pieces
• There were a few drop-outs where you will see a black screen and no sound for up to a second
• The text on some slides is unreadable; in this case, refer to the file provided by the speaker or wait for the high-bandwidth version

The high-bandwidth versions will be uploaded over the next week (slow connection is slow).