Trends are deceptive - but I haven't come back to this blogging in a while :)

I did my first Windows XP install for a while today for friends. Their machine had slowed to a crawl and _needed_ a disk format and reinstall. Three sets of media to find, three sets of 20 digit codes to type in. Printer software not found - so they'll have to go and download a huge program bundle from the manufacturer's site. [And it always takes an alleged 39 minutes from first reboot irrespective of the actual speed of the hardware :) ]

New hardware put in - a DVD writer to replace a CD writer which had lasted ten years and moved between at least two machines - that's spectacular in this day and age. The new drive is also 10% of the cost of the old one - 17 instead of about 200.

Total time to put on Windows XP, an AV product, get Firefox and to get part way through an Office 2007 install was about three hours. That's without setting up any accounts, shared directories (or network - the attached wireless router didn't need any changes).

I could do a Debian install onto the 40G disk in well under half that to include X windows, openoffice.org, iceweasel and a desktop environment. It would also run far better in 512M which is what this machine has.

Thankfully, they have data backups and an older laptop which has been the family workhorse - and a new netbook which attached to the network readily, has more disk than all other machines in the house combined, and cost less today than the "big machine" cost ten years ago at about 3 x the performance.

Intelligent questions were asked about Linux - I _wish_ I'd known about Ken Starks' radio advert or had it to hand at the time. See the Blog of Helios at http://linuxlock.blogspot.com for details - it's Free/Libre/Open Source under a CC Atttribute Share-alike 3.0 licence, and is available in a short version used in the radio advertisement .ogg or .mp3 or the longer version (.ogg .mp3 All in all, a balanced and a reasoned argument for switching based on nearly everybody's real life experience :(

[UPDATE] - The owner of the machine was up until 1 a.m - 11 hours total - because the machine decided to do a defrag. :(

After looking around the several settings Opera offers I found an interesting one: "Rendering Mode":

Set rendering mode to use at startup
0 = Normal
1 = SSR
2 = CSSR
3 = AMSR
4 = MSR
-1 = Fit to width

I first though "wow, I can make 'fit to width' mode the default, cool", but as I was intrigued by the meaning of the other rendering modes I did a little research and found the following information:

The rendering technologies that ERA utilizes are Medium Screen Rendering (MSR), Aggressive MSR (AMSR), Small Screen Rendering (SSR), Color SSR (CSSR), Television Rendering (TVR), and normal screen rendering.

MSR is generally suited to smaller computer monitors, AMSR is generally suited to PDAs, CSSR is suited to mobile phones and low-resolution PDAs, and SSR is suited to low-resolution mobile phones. Each of these applies more aggressive reformatting and scaling, restructuring pages to remove the minimum widths enforced by tables or fluid designs. TVR is suited to most televisions, where problems caused by small fonts, interlaced displays, and high contrasts can also be avoided.

After reading the documentation of "ERA" I wanted to give MSR mode a try.

So I made the change, restarted opera, opened my DDPO page which usually requires an ugly horizontal scroll bar and immediately noticed the difference: all the content was adjusted to fit in the screen.
Although the effect is quite similar (if not identical) to the "fit to width" option, it is a great improvement over normal web browsing in a "small" screen (1024x600).

I am not completely satisfied by the results, but at least happy. I hope this technology is going to be improved, and that even other browsers start developing such kind of technology.

If you ever wanted to support an open-source project but you are not a programmer, here's one (of many possible) ways to help: The Miro project (Internet TV / Video and Audio Podcast application for Linux, Windows, and Mac OS X) is seeking for pledges/donations that will be used to add subtitles support in Miro. To quote from the announcement:

We re hoping to build real subtitle support into Miro in the next couple months, but we need your help! So we ve started a Kickstarter project to raise $1,000 to develop this feature for Miro on all three platforms: Windows, Mac, and Linux. Can you pledge to help make it happen? One of the great things about the Kickstarter model is that unless we can reach $1,000, your pledge won t be charged.
[...]
(if you live in the United States, donations are tax deductible we are a 501c3 non-profit)

There are 11 days left to make a pledge.

please help out with gdebi - a history of why Short summary: if you are looking for a way to help Debian become a bit more user friendly, please take care of gdebi in Debian. I'm rather upset. So beware, rant ahead. The reason dates back to the beginning of this afternoon, when a friend of mine, GNU/Linux newbie, mailed me asking for help with his brand new (to my astonishment) Debian Lenny installation running the GNOME desktop environment. The request was simple and common to a lot of our users: "how can I see videos on YouTube and use Skype"? Surely, the first (brief) explanation I gave was why those pieces of software are not in Debian, because they are pieces of evil proprietary software. Fair enough, usual song and dance, that gets the message through. But than, given that I personally care about releasing a completely free operating system, but not necessarily in inhibiting the usage of any non-free bits of software, I wanted to actually solve my friend's problem. Regarding flashplugin-nonfree, unfortunately it is not in Lenny. Two solutions to that: either point him to http://www.backports.org and explain how to use them from synaptic (not particularly hard). Or give him a direct download link of the .deb coming from backports.org. It turns out that for Skype there is no such choice. Once there used to be an APT-gettable repository for their debs, but it seems to have vanished (or else I can't find it). Still, there is a page from which you can download Lenny .debs. Given that for Skype the choice is forced, I was tempted to simply reply to him with a couple of link to .debs and solve his problem rather easily. But wait. Once he has the two debs, how can he install them? First attempt: "just click on them in Nautilus" (my hope: "synaptic will do the right thing ). No way, it will fire up file-roller. Second attempt: "install gdebi (using synaptic), right-click on the deb, and choose ;open with gdebi'". Seems to work, but no, you will be hit by bug #493352. (BTW, the reason why you need the right click is bug #421096). What makes me upset is that both bugs were there way before the Lenny release and slipped through our QA knots. Nobody's fault, the maintainer apparently lost interest (or time) package and stopped caring about it. Happens all the time. But damn!, we will lose a user the moment I tell him "you know, you need to open up a root terminal". A few remarks: this rant is not about "we should invite user to use non-free software"; it is not even about "we should be more attractive to newbies"; it is just about the pity of losing users like this, dumbly. Concluding:

1. dear lazyweb, any idea of what can I suggest to my friend to install the debs I'll point him to, without needing the knowledge of a terminal?
2. gdebi in Ubuntu is ahead of lots of version wrt Debian, I'm convinced that it fixes most outstanding issues (given that upstream author is a Canonical employee). If you have some free Debian-time slots (I currently don't) and you care about newbie-accessibility, please consider helping out with gdebi. He needs you.

EOR (end of rant)

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.

Following zack's suggestions, I've been looking at RC bugs in my sparetime. In two days (well, two evenings really), I've been able to cope with a good number of bugs:

• #543063 - ann: FTBFS: /bin/sh: aclocal-1.10: not found (DELAYED/7 RFS!)
• #527823 - elisa-plugins-bad: FTBFS: rm: cannot remove
  /build/user-elisa-plugins-bad_0.3.5-1-amd64-0hSRfJ/elisa-plugins-ba
  d-0.3.5/debian/elisa-plugins-bad//usr/lib/python2.5/site-packages/*.
  pth': No such file or directory (DELAYED/2 RFS!)
• #536924 - gai: FTBFS: gai-private.h:66:35: error: libgnomeui/libgnomeui.h: No such file or directory (DELAYED/10)
• #537019 - gimp-dcraw: FTBFS: Unrecognized switch --build-strip (DELAYED/2)
• #536945 - hdate-applet: FTBFS: hdate_applet.c:21:35: error: libgnomeui/libgnomeui.h: No such file or directory (DELAYED/7)
• #519056 - im-sdk: FTBFS with glibc 2.8 (DELAYED/2 RFS!)
• #536964 - im-sdk: FTBFS: Package libglade-2.0 was not found (RFS! - see above)
• #543083 - libcsoap: FTBFS: aclocal-1.10: not found (DELAYED/7)
• #543036 - honeyd: FTBFS: configure: error: dumbnet-config not found (closed, unreproducible)
• #543045 - farpd: FTBFS: configure: error: libdumbnet not found (closed, unreproducible)
• #536967 - glunarclock: FTBFS: configure: error: Library requirements (libglade-2.0 >= 2.0.0 ) not met (0-day)
• #521942 - jabsorb: FTBFS: Missing Build-Depends on servlet-api and commons-httpclient (0-day)

I must admit that some of them (didn't count them, might also be the greatest part of them) already had patches, and I just prepared the NMU. For others, there were other FTBFS's other than the ones filed, and those were fixed too. It would be extra cool if some DD uploaded the remaining 3 NMUs! I also had time to release and package syslog-summary 1.14, but, not being DMUA yet, I'd need a sponsor for that too (but I'll probably ask my AM, since this upload sets DMUA). Happy RC-bug-squashing! Your friendly neighborhood hanska

I was really happy a few years back, when Martin announced he'd start working on netconf. Not just because I agreed with his assessment that ifupdown needed replacement; also because I had been thinking about a good way to implement such a thing, and had been planning to start writing 'soon'. With Martin's announcement, I made a few suggestions to give him some input, and then put my plans away I had more important things to take care of, anyway. Unfortunately, netconf did not manage to reach the ambitious goals that Martin set out, mainly due to lack of contributors. I wanted to help out; I really did. But Martin's choice of python to implement a 'prototype' which then had to be reimplemented in C or C++ didn't get me very thrilled. Not just because I have a severe dislike of python; also because implementing something twice is, in my humble opinion, not quite the best way to do something like this. But hey, who am I, if I don't put my code out there. Never the less, I tried helping. I really did. During debconf8 at Mar del Plata, I approached Martin with the suggestion that I start reimplementing those bits that were unlikely to change anymore in C, as a first step toward something that could be in the base system. Unfortunately, that didn't happen. After trying for about two weeks, I just gave up. I thought I could read python code and reimplement that so that it would work the same way, but I couldn't. I thought I could implement python modules in C without knowing python, but as it turns out that's a laughable idea. For several months then, I didn't think about it anymore. In March of this year, however, I got a little bored. And what does one do when they get bored? Right, you find something to do. I my case, that was 'figure out how bison works'. I'd of course known about parser generators for quite a while, but just never had the time to dive in deep and figure out how they work. When I needed to do a config file for nbd, I instead hand-wrote my parser and used a lexer from libglib. But I wanted to learn how to do things properly, so I sat down. Long story short, when I had to choose something somewhat more complex to implement, I thought 'how about a hypothetical config file for a network configuration utility', and I started implementing that. It turned out to be fun, so I didn't stop after I knew enough about bison. And just last week, for the first time I successfully used it to bring up my wired interface using DHCP -- and bring it down again. It can also already manage static interfaces through netlink, though it isn't quite able to the equivalent of 'ip addr flush' yet. Fun. The system is quite flexible. It has a plugin interface (which needed some refinement that I did using some help on IRC just today), which should allow developers to implement extra functionality by just dropping a shared object in the right directory. In fact, I'm working on the wireless support (hence my blog post of last week) as a plugin. Obviously the code isn't remotely ready yet. The wireless code has a long way to go. The firewall module needs to be started. It will probably crash and burn if put to the test. But even so, it already has one feature that ifupdown, in its 10 years of existence, never acquired: it will not try to DHCP off an interface if it finds out that there is no cable connected to it unless you wrote a configuration that asks you to do so. I wanted things to be as simple as possible, and therefore the minimal valid configuration file that will do something useful is the following:

That's right, it's empty. This will cause the system to bring up the 'lo' interface at bootup, and do nothing else. If you say 'ifup eth0', where eth0 is a valid and existing interface, it will first check whether there is a link, and if so, DHCP off of it. There's much to do still, but I have now reached a point where I feel the system is ready to meet all challenges it should be able to meet (or so I hope), and where it might be nice if interested people check it out. The code is in a git repository that's mirrored on git.debian.org, github.com, and my own git.grep.be. The latter is my --mirror repository, but is not available for cloning to anyone else. If you're interested in checking it out, you may want to start with doc/tech.txt, and/or examples/ipcfg.cfg. I updated the former just yesterday, so it's quite up-to-date. On the other hand, while the latter shows the direction I would like the system to take, the code is a far cry from implementing everything shown there, and it has been a while since I last checked that file out, so the comments in there are, in some cases, somewhat outdated. But that's good, because I want to keep the file as a reference of the goals that I originally had, before I'd written this whole corpus of code, so that I can go back at some undefined point in the future and fix things. Comments are (more than) welcome.

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

During one of my project I need to interact with Java cryptographic extension. Some data has been encrypted using PBEWithMD5AndDES. I need to access it from OCaml. I take a look at available cryptographic extension in the Debian project for OCaml: cryptgps and cryptokit. I choose cryptokit, because its author is well known: Xavier Leroy. This article was my starting point. Of course, I keep in mind that the reference is there and that there is a good article covering it. Here is the result in OCaml:

 let decrypt passphrase salt ?(iterationCount=41) str =
   let key, iv =
     let rec hash_aux iter str =
       if iter > 0 then
         (* Rehash string *)
         hash_aux
           (iter - 1)
           (hash_string
              (Hash.md5 ())
              str)
       else
         (* Key = first 8 bytes of the MD5 hash *)
         String.sub str 0 8,
         (* IV = last 8 bytes of the MD5 hash *)
         String.sub str 8 8
     in
       (* Hash n times combination of passphrase and salt,
           return key and iv 
         *)
       hash_aux
         iterationCount
         (passphrase ^ salt)
   in
     transform_string
        (Cipher.des
           ~pad:Padding.length
           ~iv:iv
           key
           Cipher.Decrypt)
       str

The only missing information was the pad algorithm to use (Padding.length). For this piece of information, I need to browse the RSA documentation and test a little bit. Rewriting PBEWithMD5andDES is quite straightforward with cryptokit and OCaml. It takes 25 lines with C# and OCaml (only counting LoC, no comment, no empty constructor or declaration in C#). I was thinking that this task will require 2 or 3 days, but it has been done in 4 hours... Many thanks to cryptokit ;-)

I ve done a bit of investigating ethical Free Software T-Shirts here in the past. Even when they re available, it seems a bit odd to buy a fairtrade t-shirt and then get it in plastic wrap and/or on a plastic hanger in a plastic bag. I also wonder about why and how it s fairtrade, a sort of look behind the label desire. Now Boxes of Fairtrade t-shirts are to be trialled in Midcounties Co-op stores - will it succeed and will we start to see more of this sort of packaging for ethical products? A cardboard comeback?

Two things that have been annoying me for a long time have been fixed recently, and I discovered those two new features the same day (rainy week-ends are good for you).

• OpenSSH s problem with networks with large bandwidth-delay product has been fixed in OpenSSH 5.1. The problem was that OpenSSH has its own windowing system over TCP s, and that its buffer were two small to be able to maximise the bandwidth on, say, a 1 Gbps link with 10ms latency, so you would get a ridiculous bandwidth because of that, even if TCP was correctly tuned. A patch (hpn-ssh) has been existing for a long time, but strangely, people don t like patching their SSH servers and clients.
  That means I can now get decent bandwidth using scp or rsync over long distance links.
• The radeon driver now supports TV out for R600 cards (including my X1250). I can now stop using the proprietary fglrx driver, and make the computer under the TV completely free!

OK, both changes have been there for a long time, but I m sure I m not the only one who didn t notice them at the time. Big Thank You to both groups of developers (especially to the ati/radeon developers, who have been very helpful on IRC to troubleshoot my setup).

(aside: I have a number of blog posts in draft don't worry they won't spam the various planets but this was timely so I pushed it out first) The most recent version of Firefox 3.x will also prompt you to update your Flash plugin if it is out of date. According to Ken Kovash, the response has been phenomenal. Almost 10,000,000 click through. That is 10,000,000 failures. Like a lot of people, I provide technical support for my Windows using family (and some friends). So I get to see how badly Windows is in the 'update' space. It is pretty common to have: Windows, Anti-virus, Java and one / two other applications (e.g. Google apps, Skype, Yahoo IM, etc.) prompt you with little annoying notification bubbles. Most of them have trained themselves to not look in the bottom right of the screen and to ignore requests to update. Which means that whenever I see a big, important update, like the Firefox one I end up having to remotely take over their machine and do it on their behalf. The user experience was:

1. Update Firefox.So far, so good.
2. It prompts and say Flash is out of date.Excellent. Click on link.
3. Adobe site says "click to upgrade".Great. It also includes, checked by default, a download of McCafe's anti-virus tool something or other.
4. Realise that pointless download of McCafe is about to happen. Cancel. Uncheck. Download again.Why is Adobe offering me more than just an upgrade of the product I am after? Apparently this is very common in the Windows world (think Safari included with iTunes, etc.)
5. Adobe figures out I am using Firefox and sends, instead of Flash, a 'Download manager' plugin.It includes instructions on how to enable things so that this plugin is updated by Adobe all the time. I, rather pointlessly, ponder why Flash does not do this itself.
6. Once installed, you need to restart Firefox. I do so.
7. This time the "Your Flash is out of date page" does not appear.At this point a normal person would think that they are now secure. Nothing could be further from the truth. Adobe has stupidly decided that first you need to have their update plugin. Then you need to actually do the update. FAIL.
8. I manually go the the '3.5.3' release note page, where it detects, again, that Flash is out of date.I click through to Adobe's site (again), this time, it figures out that it needs to update Flash. It autoinvokes the autoupdate plugin and does the update.
9. Prompted to restart Firefox, again. I do so.
10. Everything is now perfectly fine.

That was a total user experience failure. Not Mozilla's fault but Adobe's. But Mozilla can make a difference in this area. And work around the stupidity of Adobe.

1. All plugins MUST register a https URL where their version can be checked.
2. Periodically Firefox does the version checky thing (like with Add-Ons) and ensures they are up to date

That implies that there is a, separate "Your plugins are out of date page" distinct from "You've installed an upgraded version of Firefox"