aporem.net

I decided to take the first version of my homepage offline. First, I just kept it out of sentimental reasons, the same sort you keep the first own ‘hello world’ program. Second, it didn’t work anymore. It is written in PHP3 in a style that is today considered highly insecure. And finally, it had one major deficit. It lacked content. Especially own content.

It’s been nice, but now it’s time to say good bye!

Bugs are great. The programmer gets paid to develop software, but what would life be if there were no errors one could fix in the next release? The security professionals, both the ‘black hat’ and the ‘white hat’ guys, make a living out of unforeseen application behaviour. And finally the small talk of users is nourished from the ‘funny things’ that happen using buggy software.

And since bugs are so great, they even get categorized and named like the real-life bugs (those small creatures with six legs). I just recently came across the denominations Heisenbug and Bohr bug. The origin of these names being Heisenberg and Bohr already indicates their meanings.

The Heisenbug is the kind of problem that vanishes if looked at more closely. Every measure taken to identify the bug makes the symtpoms go away.
In contrary, the Bohr bug is easily reproduced and nailed down. It’s the classsical sort of bug.

But what relevance have those names to the user reporting bugs? At first glance none, but since it is clear that programmers, especially those with a scarce time budget, prefer fixing Bohr bugs, each report of such a problem should include detailed instructions how to reproduce it. This means that the user is in his own interest responsible for passing all relevant information to the developer.
Although this seems to be a trivial fact, most users just don’t care. Ultimately this leads to frustration, since reports about being unhappy with an application without giving details usually go to /dev/null.

Somehow I feared that I wouldn’t be able to make a posting out of this topic, since it’s hard to give arguments for not doing something. In this case not hiding information.

Recently, I’ve heard someone asking how to hide the version numbers of the daemons he’d set up on his server. His fear was, that once the information about the software he deploys gets public, “malicious hackers” would be able to use special exploits (hand made) for these versions. I didn’t wanted to get intvolved in this discussion, but I’m nevertheless sure he missed the point of hiding those version informations.

Usually, if you don’t work for a high-profile company, your servers won’t be attacked on purpose. Hence the motivation is a general interst in exploiting a vulnerability (for whatever purpose it may be). But such assaults are too tedious to do them “by hand” on a bunch of machines which have to be found in the first place.
Therefore those attacks are all automated and for the sake of being effective (read: efficient) every implemented exploit is tested against every possible target. Again, the goal of those missions is to find an arbitrary exploitable system, not a special one.
And usually, the automated tests don’t give a whim on the version string returned from the applications. At best, the search order is adapted.

On the other hand, hiding the version strings just annoys your users. Especially, if they want something version-specific. So, either they have to ask you or they risk that they break something.

Don’t be ashamed to tell what software you’ve got!

SUN invented it, Apple wants it and FreeBSD already has a port…

Yesterday, Pawel Jakub Dawidek has announced that he will port the ZFS filesystem from SUN Solaris to FreeBSD. In his posting to the zfs mailing list, he already gives a “demo” where he creates a filesytem on top of a disk pool and make some simple FS operations.

But what’s all about this new filesystem? From the ZFS homepage:
ZFS presents a pooled storage model that completely eliminates the concept of volumes and the associated problems of partitions, provisioning, wasted bandwidth and stranded storage. Thousands of filesystems can draw from a common storage pool, each one consuming only as much space as it actually needs. The combined I/O bandwidth of all devices in the pool is available to all filesystems at all times.
All operations are copy-on-write transactions, so the on-disk state is always valid. There is no need to fsck a ZFS filesystem, ever. Every block is checksummed to prevent silent data corruption, and the data is self-healing in replicated (mirrored or RAID) configurations. If one copy is damaged, ZFS will detect it and use another copy to repair it.

Although this sounds quite promising and revolutionary, I’m not convinced that this will be THE new filesystem of FreeBSD and/or Mac OS X.
First, the porting of a filesystem is one of the hardest things to do: the tolerance in respect to errors or instabilities is near zero and you better get it right in the first attempt or the trust on the implementation is lost.
Then there is always the lack of testers: who is willing to loose all his data just to test the latest build? Even if it’s just a generic FreeBSD install, the time it takes to recover from a desaster is keeping off the masses. And if you managed to reach a sufficiently large audience, then the pain with the extreme usage scenarios begins. There is always someone bringing the filesystem to its knees and then complaining that you didn’t test this special case.
And finally, there is the SUN-factor. Big companies usually scare away little projects, considering the trouble you can get yourself in, if messing with them. (It took the FreeBSD project years to get a native JAVA port from them.) Even Apple will be careful including ZFS support into their next OS.

But then again, it’s fun to get something working, so if you can, help Pawel Jakub Dawidek with this project!

In my last post I laid out the disadvantages of the BSD naming convention of the developement branches. But if that’s too complicated for the public, how should one count the software releases and the bugfixes?

Linux Torvalds has conceived a simple but potent nomenclature: the first number is the major release number. the second number indicates if it’s a developement or a production branch (odd: developement, even: production) the rest is for keeping track of the patch levels.

The convention is easy to describe and somehow aides to imagine how software is being developed (“1.1 becomes 1.2 if it’s mature enough”) but it’s a bit too small-scaled for my liking. Everything, even the smallest commit, has it’s own full-blown name and number. And you run into trouble quite fast, if big commits are separated to several small ones but mixed with other unrelated bug-fixes or other stuff.
Finally, it’s simply an overkill for anything less complicated than a kernel or a whole OS.

If you want something simple, just use the build (a.k.a. commit) number or date of the release as a scheme to name your developement steps.

Every now and then a major discussion breaks loose in the FreeBSD community about the naming convention of the developement branches. Actually, it’s more like a flame-war than a discussion but luckily with not much effect whatsoever.
First, let us recall that the bleeding edge is called HEAD, the products are called RELEASE and the “thing in-between” is called STABLE. And here lies the root of the problem: it’s a naming convention invented/used by software engineers, not by marketing or sales people.
For engineers, the head of developement is where new things go in, get stable and finally go out as releases.

While everyone seems to agree with HEAD and RELEASE as names, the term stable is heavily disputed. This too arises from what is considered stable by a developement team vs. what it means in common (technical) language. For FreeBSD developers, the suffix STABLE marks that the ABI (resp. API) is not going to be changed anymore. Most administrators on the other hand have a completely different view of what should be considered stable: it simply has to work (better than before).
This fundamental disagreement causes much traffic on forums and mailing lists because no one wants to step down from his point of view. (Although there always are some postings which point out that the developement branches could also be called “foo” or “bar”.) And no one wants to let the other side have the last word.

The solution from my point of view is quiet easy: keep the nomenclature as it is for the contributors and introduce some fancy code names for the rest of the world.

For all those who have their machines beneath of their desks (either at work or at home) the amount of noise the boxes generate does make a difference. First I never considered this to be a major issue since in the starting days of my IT experience the computer was just powered on if I worked on it. But by the time the box beneath my desk has become a network server and it couldn’t be turned off just like that.
Since then I’ve been looking for a less noisy solution. My last home server was the loudest machine I ever had, due to the poor design (when I bought it, I had to get a replacement machine quite quickly since my only box died suddenly). Finally I was able to replace that infamous machine by two very quiet ones.
But then summer arrived and the noise level rose again! I tracked down the problem to a very small temperature spectrum, where these machines operate very quietly. If it’s hotter, they generate a noise level of a vacuum cleaner.
I then recalled that the most effective way to reduce noise is to reduce heat. And the hottest part of the computer is the CPU. Luckily the chip manufacturers have implemented frequency throttling mechanisms besides the power consuming features (which are usually unused).

Now to the fun part of cooling down:

1. Put the following line into your kernel configuration:
   device cpufreq
   And recompile your kernel.
2. Make sure you have the ACPI module loaded at boottime. Put
   acpi_load="YES"
   in /boot/loader.conf.
3. Reboot to use the new kernel.
4. Put powerd_enable="YES" into /etc/rc.conf and start powerd.

If you want to see the power changes, use powerd -v. The daemon will run in the foreground and write every change to the standard output.
The default values are that powerd will decrease the cpu-frequency, if the CPU is idle 90% and increase again if it’s idle 65% or less.

With this setup I managed to keep my two boxes quiet even on the hottest summer days!

This is the last step of the “multiple machines running from one USV” set up. So we have configured the master and the slave(s) and they are nicely talking to each other.

But the software can do more than just monitor the state of the batteries and initiationg a shut down if necessary. apcupsd is able to display the (power) status informations of several computers on one central website.

To enable this feature, one has to set up the Network Information Service in apcupsd. This is done via the NETSERVER and the NISPORT directives. The standard (IANA assigned) port is 3551, so it’s a good idea to leave it at that value.
Next, make sure that apcupsd is running on the web server (probably one of the servers protected by the USV anyway).
Then you have to tell the web server that the cgi directory contains CGI scripts (use the ScriptAlias directive for Apache’s httpd) and that it’s safe to execute them.
Finally, you create one line per host you want to monitor in the hosts.conf file in the directory containing the other config files in the following form:

MONITOR 10.64.1.1 "Finance department"

You have to modify the entries for your purposes, of course.

After restarting the apcupsd daemon and the web server you should get a similar result calling the multimon.cgi script with your browser:

Enjoy your newly won independence from the power lines!

This is a sort of errata post for Connecting more than one computer to the USV (I), the first part of this series:

I’ve found a better suited network port (the NETPORT directive) for the communication between master and slaves. It’s the port number 3493, declared as “Network UPS Tools” port in FreeBSD.

Choosing the network port for an application can be picky in some situations. One has to weight the inconvenience for choosing a non-default port (this would be a just to big burden for http servers) against the security implications (e.g. secure shell server not running on port 22 is a good idea) and the possibility that the port may be used by other (or future) applications.
In this case it’s a sure bet, since the port is reserved (by IANA?) for this kind of use. And it’s not very likely that one machine is connected to two different USVs (for such power-users I would suggest getting one of those network enabled USVs).

All in all it doesn’t make any difference in the network communication, so you can ignore this entire posting, but one of the administration maxims I love, is to keep things simple and using a network port dedicated to such purposes fulfills this principle.

To complete the master/slave set up of the apcupsd daemon, we have to configure the slaves.

For the slave configuration we start out with a new file, since there are a bunch of changes to be considered:
## apcupsd.conf v1.1 ##
UPSCABLE ether
UPSTYPE smartups
LOCKFILE /var/spool/lock
#EVENTSFILE /var/log/apcupsd.events
#EVENTSFILEMAX 10
UPSCLASS netslave
UPSMODE net
NETPORT 6666
MASTER master


• The UPSCABLE directive tells the apcupsd that there is no USV-cable attached to this machine.
• Although otherwise stated in the documentation, always use UPSTYPE smartups as the protocol type for the communication.
• The port number in the NETPORT directive has to be the same as in the configuration file of the master!
• Analogously to the SLAVE directive in the master configuration, you have to tell the slave his MASTER

After restarting the apcupsd daemons on both the master and the slaves the changes take effect and the eventfile of the master should log the successful connections of the slaves.