I met Irma and Bob from Calyx yesterday. They're fellow Koha service providers from Sydney, Australia who are over in Europe visiting various people. It was nice to see them (first time I've met Bob) and have a bit of a chat about where we're each going with Koha. One interesting difference is that they have several private-sector clients, while I don't think my cooperative has yet done a private-sector Koha, but there seemed to be more similarities than differences, including adding more robust project management and ticketing as we deliver Koha 3 to people. We went for lunch at The Cliffs Tea Rooms at the other end of Kewstoke Toll Road, which has great views towards Wales, but I forgot to take any pictures. Ooops.

(This post is mostly as a reminder to myself on how I've set up my backup system. It should probably go on a wiki instead so I can keep it up to date.) After the recent OpenSSL debacle in Debian and Ubuntu, I found that all my backups were encrypted with something amounting to a well-known secret key. Ouch. I was not entirely happy with how my old backup system worked either (it was based on boxbackup). In particular, the on-disk format was opaque, the tools needed to access it were not particularly user-friendly and I had to run Yet Another CA for managing the keys for it. After looking around a little, I settled on rdup which is a tool very much written in the unix tradition of "do one thing and do it well". As it reads on the home page:

The only backup program that doesn't make backups!

(which is almost true). It keeps a list of information about which files have been backed up locally on the machine to be backed up, including some meta-information such as file size and permissions, so it can take a new backup if any of those changes. For more details, read the web page and the source. rdup is more of a framework for making your own backup system than a complete system in its own right, so this post is really about how I have customised it. First, I want my backups to be encrypted, and rdup supports encryption (both GPG and mcrypt). I'm lazy, so I settled on what rdup-simple gives me, which is mcrypt. Key generation is easy enough: head -c 56 /dev/random > /root/backup-$(hostname).crypt.key and then a chmod 600 to avoid it being world-readable. In /root/.ssh/config, I put

Host backup-$hostname
Hostname $backupserver.err.no
User backup-$hostname
IdentityFile /root/.ssh/id_rsa_rdup
ProxyCommand pv -L 40k -q   nc %h %p

so as to make it fairly easy to move stuff around and to make it pick up the right identity. The last bit is a trick to rate limit it so it doesn't saturate my DSL. pv has a wonderful -R switch which lets me change the arguments to an already-running pv, if I want to do that. ssh-keygen -t rsa -f /root/.ssh/id_rsa_rdup to generate an ssh key. It got put into /home/backup-$hostname/.ssh/authorized_keys on the backup server, so the line reads like:

command="/usr/local/bin/rdup-ssh-wrapper",no-pty,no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa AAAAB3N

The /usr/local/bin/rdup-ssh-wrapper is a small perl wrapper which only allows the rdup commands and sanitises the command line somewhat. Since I don't want to make a backup of all bits on my machines, I have an exclude file, which lives in /root/rdup-exclude. It is just a list of regexes of files to ignore. To actually make a backup, I run something like for p in /etc /home /var; do rdup-simple -v -a -z -E /root/rdup-exclude -k /root/backup-$(hostname).crypt.key $p ssh://backup-$(hostname)/srv/backup/$(hostname)/$p ; done which then goes on for a while. It gives me nice structures with hard-linked files to avoid using more disk space than needed. I can then just have a small find(1) script prunes old backups as I don't need them.

My girlfriend Lisa has been running Hardy for a good while now, some things are a pain for her, like Wine not managing to run Excel 2003 and OpenOffice having corners of bad usability (”Grraagh, why can’t I ….”), but sometimes she loves it. Today she’s been working and playing CDs on her laptop, and she said - ‘look at this, it’s really clever! It shows the CD covers and knows what the tracks are! And it even does it for really old CDs!”. Its the little things that make her happy. Well done Rhythmbox team

With my server migration I switched from PostgreSQL 8.2 to 8.3. However, I've installed MediaWiki for the awesome wiki on 8.2, but dumping from 8.2 and restoring to 8.3 just failed because of the tsearch2 extension, which is now part of PostgreSQL 8.3. With the help of my friend Dimitri, the pgloader author, I managed to migrate the database from PostgreSQL 8.2 to 8.3. Here is how I did. This was done with MediaWiki 1.12, and I doubt that older version supports PostgreSQL 8.3. Dump the database schema First, you need to dump the database schema, and then, the database data. We need to do it in two steps because we need to change the schema a bit. I assume that MediaWiki is installed in the mediawiki schema:

% pg_dump -s -n mediawiki wikidb > wikidb-schema.sql

Convert the schema Then, edit your wikidb-schema.sql. When you installed tsearch2, you probably did it in the public schema like I did. So it created two or three data types used by MediaWiki wich are named public.datatype. These tsearch2 datatypes are now part of PostgreSQL, so they're in the pg_catalog schema. You just need to replace a few lines with public.datatype with pg_catalog.datatype. For example public.tsvector is now pg_catalog.tsvector. For your information gin_tsvector_ops is now pg_catalog.tsvector_ops. Finished? Good, but that's not all. You need to split up the file in two parts: one with the tables creation, and another one with the constraints creation. Why? Because otherwise the data insertion will fail because of these constraints. That's not so hard, just split your files in wikidb-schema.sql with all CREATE TABLE and so one, and then you see that the SQL file begins to do some ADD CONSTRAINTS, just put this in another file, named wikidb-constraints-schema.sql. You'll also need to set the namespace before executing command in your second file, so do not forget to add a SET search_path = mediawiki, pg_catalog; line at the beginning. Dump the database data That's easy:

% pg_dump -a -n mediawiki wikidb > wikidb-data.sql

Create your new database That's easy too:

% createuser -S -D -R -P -E wikiuser #(then enter the password)
% createdb -O wikiuser wikidb
% createlang plpgsql wikidb

Restore the database That's even easier, but you need to respect this order, otherwise it will fail:

# Restore schema first
% psql wikidb < wikidb-schema.sql
# Then restore dat
% psql wikidb < wikidb-data.sql
# Then restore constraints
% psql wikidb < wikidb-constraints-schema.sql

Run update.php Just go the the maintenance directory. Then you can try to run update.php, but it'll fail.

% php update.php
[...]
Could not open "/var/www/awesome.naquadah.org/wiki/maintenance/postgres/archives/patch-tsearch2funcs.sql".

Well it seems that MediaWiki people just forgot this file in the 1.12 archive.. You can grab it on the SVN repository here. When you've put it in the good directory, really run:

% php update.php
[...]

You should see no error. And now it works. Give us some kudos This is the last and hardest part of this tutorial. Since everything works, you should give kudos to Dimitri and me.

Can a Panasonic EUR7615KTO remote control for a NV-VP30 video player use its TV mode to control a Goodmans 257NS TV? I've tried every setting listed in the instruction book and I still can't get it to work. Neither the book nor the stuff on Panasonic's web site has a compatibility list. Search engine results are full of people selling replacement controls and no compatibility lists. I guess it doesn't work, but it's a bit irritating not to know for sure. Why doesn't anyone produce proper hardware compatibility lists for these devices? Video players are worse than Linux...

It has recently been announced that Debian had a serious bug in the OpenSSL code [1], the most visible affect of this is compromising SSH keys - but it can also affect VPN and HTTPS keys. Erich Schubert was one of the first people to point out the true horror of the problem, only 2^15 different keys can be created [2]. It should not be difficult for an attacker to generate 2^15 host keys to try all combinations for decrypting a login session. It should also be possible to make up to 2^15 attempts to login to a session remotely if an attacker believes that an authorized key was being used - that would take less than an hour at a rate of 10 attempts per second (which is possible with modern net connections) and could be done in a day if the server was connected to the net by a modem. John Goerzen has some insightful thoughts about the issue [3]. I recommend reading his post. One point he makes is that the person who made the mistake in question should not be lynched. One thing I think we should keep in mind is the fact that people tend to be more careful after they have made mistakes, I expect that anyone who makes a mistake in such a public way which impacts so many people will be very careful for a long time… Steinar H. Gunderson analyses the maths in relation to DSA keys, it seems that if a DSA key is ever used with a bad RNG then it can be cracked by someone who sniffs the network [4]. It seems that it is safest to just not use DSA to avoid this risk. Another issue is that if a client supports multiple host keys (ssh version 2 can use three different key types, one for the ssh1 protocol, one for ssh2 with RSA, and one for ssh2 with DSA) then a man in the middle attack can be implemented by forcing a client to use a different key type - see Stealth’s article in Phrack for the details [5]. So it seems that we should remove support for anything other than SSHv2 with RSA keys. To remove such support from the ssh server edit /etc/ssh/sshd_config and make sure it has a line with “Protocol 2“, and that the only HostKey line references an RSA key. To remove it from the ssh client (the important thing) edit /etc/ssh/ssh_config and make sure that it has something like the following: Host *
Protocol 2
HostKeyAlgorithms ssh-rsa
ForwardX11 no
ForwardX11Trusted no You can override this for different machines. So if you have a machine that uses DSA only then it would be easy to add a section: Host strange-machine
Protocol 2
HostKeyAlgorithms ssh-dsa So making the default configuration of the ssh client on all machines you manage has the potential to dramatically reduce the incidence of MITM attacks from the less knowledgable users. When skilled users who do not have root access need to change things they can always edit the file ~/.ssh/config (which has the same syntax as /etc/ssh/ssh_config) or they can use command-line options to override it. The command ssh -o “HostKeyAlgorithms ssh-dsa” user@server will force the use of DSA encryption even if the configuration file requests RSA. Enrico Zini describes how to use ssh-keygen to get the fingerprint of the host key [6]. One thing I have learned from comments on this post is how to get a fingerprint from a known hosts file. A common situation is that machine A has a known hosts file with an entry for machine B. I want to get the right key in machine C and there is no way of directly communicating between machine A and machine C (EG they are in different locations with no network access). In that situation the command “ssh-keygen -l -f ~/.ssh/known_hosts” can be used to display all the fingerprints of hosts that you have connected to in the past, then it’s a simple matter of grepping the output. Docunext has an interesting post about ways of mitigating such problems [7]. One thing that they suggest is using fail2ban to block IP addresses that appear to be trying to do brute-force attacks. It’s unfortunate that the version of fail2ban in Debian uses /tmp/fail2ban.sock for it’s Unix domain socket for talking to the server (the version in Unstable uses /var/run/fail2ban/fail2ban.sock). They also mention patching network drivers to add entropy to the kernel random number generator. One thing that seems interesting is the package randomsound (currently in Debian/Unstable) which takes ALSA sound input as a source of entropy, note that you don’t need to have any sound input device connected. When considering fail2ban and similar things, it’s probably best to start by restricting the number of machines which can connect to your SSH server. Firstly if you put it on a non-default port then it’ll take some brute-force to find it. This will waste some of the attacker’s time and also make the less persistent attackers go elsewhere. One thing that I am considering is having a few unused ports configured such that any IP address which connects to them gets added to my NetFilter configuration - if you connect to such ports then you can’t connect to any other ports for a week (or until the list becomes too full). So if for example I had port N configured in such a manner and port N+100 used for ssh listening then it’s likely that someone who port-scans my server would be blocked before they even discovered the SSH server. Does anyone know of free software to do this? The next thing to consider is which IP addresses may connect. If you were to allow all the IP addresses from all the major ISPs in your country to connect to your server then it would still be a small fraction of the IP address space. Sure attackers could use machines that they already cracked in your country to launch their attacks, but they would have to guess that you had such a defense in place, and even so it would be an inconvenience for them. You don’t necessarily need to have a perfect defense, you only need to make the effort to reward ratio be worse for attacking you than for attacking someone else. Note that I am not advocating taking a minimalist approach to security, merely noting that even a small increment in the strength of your defenses can make a significant difference to the risk you face. Update: based on comments I’m now considering knockd to open ports on demand. The upstream site for knockd is here [8], and some documentation on setting it up in Debian is here [9]. The concept of knockd is that you make connections to a series of ports which act as a password for changing the firewall rules. An attacker who doesn’t know those port numbers won’t be able to connect. Of course anyone who can sniff your network will discover the ports soon enough, but I guess you can always login and change the port numbers once knockd has let you in. Also thanks to Helmut for advice on ssh-keygen.

• [1] http://www.debian.org/security/2008/dsa-1571


• [2] http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html


• [3] http://changelog.complete.org/posts/714-Thoughtfulness-on-the-OpenSSL-bug.html


• [4] http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html


• [5] http://www.phrack.org/issues.html?id=11&issue=59


• [6] http://www.enricozini.org/2008/tips/ssh-host-key-fingerprint.html


• [7] http://www.docunext.com/blog/2008/05/14/my-security/


• [8] http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki


• [9] http://www.ducea.com/2006/07/05/how-to-safely-connect-from-anywhere-to-your-closed-linux-firewall/

Share This

There is an article on TechCrunch on Windows on the OLPC. This article started out as a comment below lots of comments that were missing the point, but eventually grew too large. The entire discussion circles around the question whether it would be beneficial to give the users the same view and behaviour that is on 90% of machines worldwide, so they can start out prospective jobs with a minimum of training. Learning your way around the UI is only a significant part of training if that actual work you will do is trivial — so this argument basically boils down to "I don't expect the African kids to do anything but grunt work during their lifetime anyway, so we better start training them early", which is the wrong approach not only to education. To make a bad car analogy, roads are usually made of several layers, from the foundation providing the stability up to the paint defining lanes. Operating systems are similarly layered, with a core that applications (cars) never touch directly, and several other layers on top of that that are not really required for basic functionality, but that add safety (process separation) or comfort (standard functions). The minimum standard of things is a "platform definition", which all car (or application) makers can expect — all roads have a minimum width and there are no dangerous spikes (if that is not true, you can get a steamroller or respectively format your harddisk). Railways use the same kind of foundation (operating system), but the platform (heh) is quite different. You cannot drive a car on a railway, or a train on a road, just as you cannot run a Windows application on a Linux system or vice versa (there are special wagons you can place your car on, and special trucks with rails on them if you feel like it, but these are heavier and need more energy to pull). Now in this discussion, people have been comparing Windows (the platform) to Linux (the operating system). That doesn't work. On Linux, there are several platforms available, the most prominent being GNOME and KDE for the desktop and POSIX utilities on the command line, but there are lots of others as well. Part of most platform definitions is an user interface, which abstracts what is really happening to something comprehensible to the user, using analogies (a tachometer displays our speed as an angle usually, but other representations are possible). The "desktop" idiom happened to be the first graphical UI some thirty years back, and was perpetuated into today's computers (just like the width of roads hasn't changed from the days of the Roman empire, where it was "two horses and then some"), however this doesn't mean it is the best choice available — it's just what we are used to. If you look at the screen contents on the day traders' computers (lots of that on the TV right now thanks to the market crisis), you will notice the vast majority does not use overlapping windows or standardized "rising-edge" buttons to click on, but rather, they have a tightly-packed grid layout with high-contrast information displays that also color-code certain messages. I think that is the most important point here: to achieve optimal results, the presentation idiom needs to be chosen in a task specific way. With children as the target audience, we lose one of the key requirements behind the adoption of the windowed view: the need for side-by-side presentation of data from multiple unrelated sources (which is also a problem given the lack of screen space). With the introduction of ad-hoc mesh networking and collaborative applications, the "desktop" analogy begins to break down. The project's mission also defines requirements on the platform. If we want to keep the requirement "users should be able to build and share their own stuff", then we want a framework where it is hard to make mistakes, especially those that can be spotted only after an interesting failure, and more importantly impossible to write code that makes unrelated components fail, because these components might be your way back out of the situation. Windows has an excellent event model with fairly good isolation of components (to the point where a problem in an event handler can be handled by the event loop rather than terminating the program, so for example Internet Explorer can shut down broken plugins rather than crashing), but the detail knowledge required to really work with the API (how to build a message loop that also runs queued I/O completion handlers correctly) leads to a fairly steep learning curve, and would teach implementation details rather than concepts. The normal "linuxy" approach of going low level whenever higher-level approaches fail is not the answer either as we want to truly empower people rather than just training them to be a cheap replacement for the tech support Indians (no offence), so it is vital that the "real" applications use the same framework that people implementing new things would use, and thus all the complexity that we want in our "official" applications needs to be taken care of by the platform, with all the safety features in place too. So no existing platform provides what we want. — hence Sugar. And that is the problem for Windows advocates: Sugar replaces those bits that make Windows a platform and not just a kernel, so porting Sugar to Windows doesn't make sense from a technical point of view, since we already replaced the bits that we didn't have free software for before. Other than that, the "Linux vs. Windows" kernel choice is secondary; in fact both kernels are very similar in design and function, the various advantages and disadvantages of either aren't that relevant really. The only technical reason in favour of Linux is the virtual memory management — the Windows VMM behaves erratically in the absence of a swap device, but I believe that is not something that cannot be fixed. The reason why I believe Linux is the better choice here is long-term support. Since these devices will be used in basic education (which hasn't changed that much in the past years as 1 plus 1 still equals 2), there is hardly any need for radical changes after the initial rollout — why add instability when you don't have to? With Microsoft as a for-profit company, there needs to be a business model sustaining that behind it, and I believe it will be very hard to find one. "Subscription" falls down in that it is a long-term recurring expense, which governments tend to be pretty wary of. The alternative is to upgrade several million computers' OS every few years. Lots of companies are skipping entire Windows releases because of the migration cost, and even with the "console bonus" (all hardware is the same) and bootloader support for software upgrades over a mesh network, this is still a massive endeavour. That each machine would have to reserve enough memory for the entire "upgrade pack" so it can transition "in one go" also makes this model unworkable. To summarize, using Windows on the OLPC does not make sense at all. If you use just the kernel, you don't gain anything over Linux, and if you use the entire platform (and by extension, the UI), you add unnecessary complexity that is not only not required for the actual task, but also distracting. If you add restrictions and extensions to make it work, you invent a new platform, which is precisely what Sugar did. The argument that it is important for pupils to use the same thing that the rest of the world is using to ease their entry into the workforce is bogus at best, and racist at worst.

This post is to some extent a fall-out of the recent discovery of a serious flaw in Debian's openssl and openssh packages. However, as Raghavan will confirm, a weaker version of what is said below was part of our discussion two weeks ago. Moreover, there are earlier posts on this topic in this blog.There are times when I wonder why I am so involved with computers ... this is clearly one of those times.

कर्मण्यैवाधिकरस्ते मा फलेशु कदाचनkarmaNyaivaadhikaraste maa faleshu kadaachana

This is a phrase from the भगवद गीत (bhagavad giit) which has been stuck in my head for the last 30 odd years. It roughly paraphrases into

Do something because you think it is worth doing not because of what you hope to achieve by doing it.¹

The above maxim is a good one but is sometimes a cop-out. Moreover, it provides no basis for actually making ethical choices.Ethics comes from one's interactions with the communities one is a part of. There are (roughly) two communities that I am a part of in the context of computers:

• the FOSS community; specifically, the Debian community.
• the IMSc computer community

I take these in turn below.

Debian and FOSS communitiesBy its own standards, the Debian community has suffered a massive failure ... and by these same standards it has reacted extremely well to this failure.I feel shame and blame. Why have I been ignoring RFH#332498 all these days when it shows up in the output of wnpp-alert? Here I am, a mathematician with some understanding of the issues, not helping out! Three years ago I even gave a short course of lectures on implementations of crypto; the source of openssl and openssh were used as examples. Excuses like, "I don't know anything about library packaging" and "I need more time!" (who doesn't) seem too weak now.At the same time, I feel a sense of solidarity with the Debian (and more widely FOSS) community as it tries to pull out of the resulting mess. The resilience that allows us to laugh wryly at ourselves is IMHO admirable.As Steve Kemp wrote: "[When we look back we will see that] we did good".

IMSc computer communityThe IMSc computer setup was built by volunteers and was genuinely a community when I joined this institute in 1996. It has since then broken into users, system administrators and the computer committee. As Indira Gandhi would have said: "This is a world-wide phenomenon", and as was the case when she said it, my response is: "That doesn't make it a good thing!"

When I speak about this fractured IMSc community below it is in generalities. There are certainly individuals who rise above the shards.

I have been promoting the use of FOSS and more specifically Debian at IMSc ever since I got here. While explaining the pragmatic aspects like cost and security, I have also tried to emphasize the freedom and community aspects of FOSS use. When the latter are not understood or accepted, the former are easily blown away.This year I made an attempt to get the Computer Committee to invite users to choose² their own computers and the software that ran on it, but it turned out that no one really wanted this. Users just wanted to buy "fancy toys", the administrators just wanted to make their life simple and CC members just wanted the power to dictate what people bought.³I also made an attempt to get our users to educate each other on the use of computers for their work --- first through the establishment of a wiki and then through the "No-Excuse" mailing list.⁴Unfortunately, the fractured IMSc computer community sees computers and software as expensive commodities --- with some combination of fear, greed and irritation. In any case, there is no feeling of being part of a larger community that is trying to solve (certain types of) problems.

A wise man once said:

With great freedom comes even greater responsibility.

This may explain why we prefer being dictated to by proprietary vendors and computer committees that "buy stuff for us". We are afraid of the responsibility that comes with freedom.Another much quoted quote is:

If you are not part of the solution then you are part of the problem.

The FOSS community (actively) invites people to join-in in solving problems. This participation (which can be at a level of one's own choosing) is the source of one's freedom in free software. The IMSc community just wants मा-बाप सर्कार (maa-baap sarkaar) to fix their toys.

A decisionThe IMSc computer community was tied to Debian and FOSS after the break-ins into our system in the early 2000's. At that point, I was instrumental in installing a security infrastructure based mainly on Debian. This led to my greater involvement with FOSS and Debian and also to the greater "infiltration" of Debian and FOSS into IMSc computers.From the "commodity" point of view at IMSc we have come a full circle since most users will have to "do a lot" so that the IMSc computer LAN emerges unscathed from the crisis created by the Debian openssl flaw.From the "community" point of view at Debian we have spiralled out and even this major whirlpool will not drag us back in.It is no longer possible (for me) to straddle the circle and the spiral in an attempt to widen the former; I'm taking the "outward radial vector"!

---

1. To this sentiment I have often added "do it because it's fun". ↩
2. ... and be willing to justify their choices of course.[WGFCEGR] ↩
3. OK! I'm exaggerating a bit! ↩
4. No-Excuse is an acronym for Novice and Expert Computer Users. The blurb says:

   Now that this list exists there is "no-excuse" for novices to remain in-experienced or for experienced users to claim that something is "too hard to explain to a novice"!

   ↩