aporem.net

Holiday time is the time for the senseless “out-of-office” or “seasons-greetings” mails. I don’t use the automatic answering mechanism and don’t answer to bulk mails (except invitations).

Nevertheless, I want to inform you, dear audience, that I’m not going to write articles for the next two weeks.

“Blessed are the toolmakers”: the original article focuses on the ability to build your own tools. The follow up praises the perl tool-smiths and their sense of play for creating tools for (almost) every problem that arises.

I fully agree. And hence, I should turn my little script from my past article into a tool. But isn’t it already one? — Both authors fail to give a definition of what a good tool is like.

A good tool serves one purpose. And it serves it well, even when used in unforeseen ways. So it has to be hardened against unpleasant working conditions and must be predictable under all circumstances. This is where most scripts and ad-hoc programs fail, my little script being no exception.

So blessed are the toolmakers who can craft usefull and efficient tools!

I’ve found a very interesting article “Configuration: the forgotten side of security” on linux.com.

The article confronts the ideas behind reactive measures and security architecture (i.e. security-aware configuration). While biased towards the proactive measures, the article makes a good point in showing up that every reactive measure has the inherent flaw that it can only catch already known problems. And it doesn’t stop there. The pitfalls of the proactive measures are discussed also, although in a somewhat too friendly manner.

Advocates of secure configuration need to make the users responsible for their system security. Either by educating them or by cutting their rights (not in a legal sense of course).
Herein grounds ultimately the optimism of these advocates. In order for the theory to work, users have to learn or adjust themselfs to fit the new security principles. And they have to do this at least with the same speed as the software they use evolves.

Unfortunately, the article is a bit short on this point.

The other day I’ve yanked out a little perl script to perform a dull maintenance task. It was perl programming at it’s best.
While designing this little script I deliberately ignored some good programming practices. No subroutines, nothing for the use(r) convenience was planned in. So the code now sports some doublets and some very inefficient functional parts.

Nevertheless, I’m very happy with this tool. First, it’s well documented. Both in the sense that the code is easy to read and with an extensive source code documentation (20% code/documentation ratio). Since such tools tend to live much longer than originally anticipated, they are much more often read than re-written, hence clarity is an essential design feature.
Second, the tool is a well of copy-and-paste opportunities. Leaving out all the fancy things makes the code highly portable across different versions or even different programming languages. Here again, duplication of code is meant to be a feature, not a flaw. With every part of the code being independent, many sources of errors are kept out: no subroutines can be forgotten, nothing implicitly hidden in other parts of the code.
Finally, the major benefit is that the tool is finished and complete in itself. All the requirements have been fulfilled without any overhead and the danger of feature creep is mitigated by the fact that almost any feature change comes at the cost of a complete rewrite. On the other hand, ease of maintenance is guaranteed by the simple layout paired with the emphasis on documentation. (And the fact that the parts that have been duplicated are just for housekeeping or linked directly to the core data structure.)

So for small tools, it’s fine to throw some programming principles overboard, if the time is spent on documentation.

There is an excellent article by Dru Lavigne on ONLamp.com about the more sublte parts of X11 configuration.

Starting with a short sketch on how to choose the right accelerated drivers for the video card, including the installation of the kernel modules, the author proceedes to explain the more advanced features of X11: nested X servers and distributed multihead configurations.
While nesting (as the name implies) allows you to run several X servers on one screen, distributed multihead goes the other way by sharing one desktop across multiple machines on the network.

Although I won’t use any of the features presented in the article, I nevertheless enjoyed reading and was really surprised how much potential there is in my X11.

A little while back, I’ve discovered the usefullness of cheat-sheets. The idea to summarize some commands or keyboard shortcuts is not new to me, though. I just missed the fact that I’m not alone with this habit and that usually someone already has put together a nice quick reference.

Therefore, here some starting points:

• Cheat Sheets from Smashingmagazine
• Cheat Sheets from Contentschmiede.de

Until now, I didn’t find a really big/exhaustive compilation of cheat sheets, but this is what search engines are for. (Although a website dedicated to cheat-sheets with a coherent layout/design would please the nerd in me.)

Are you searching for an alternative way to get your files from a remote server without the hassle of rsync’ing or copying? Do you have problems with UID mapping between your hosts?
Then take a look at fuse-sshfs (available for Linux and FreeBSD 6.x but not for MacOS X).

The syntax is comparably easy to grasp:
sudo sshfs {{user id}}@{{server hostname}}:{{desired remote share}} {{desired local mount point}} -o idmap=user -o allow_other -o uid={{local user id}} -o gid={{local group id}}

Although there is a (heavy) performance penalty, the enhanced security compared to a NFS mount and the lighter configuration footprint (there isn’t any on the server side) compared to AFS make it an ideal choice for any quick file operation you want to make remotely.
For example, think of sharing code trees between your build box and several production systems. With sshfs you can add without hassle remote sites connected without any VPN (although, I wouldn’t recommend this as a permanent solution).

“SSH is the HTTP of system administrators!”