Some time ago I wrote a small shell script that counted the number of dependencies of each package. It used to take lots of time to perform such a simple operation, so today I decided to rewrite it from scratch in perl and even made it able to sort the packages according to the number of pre-/dependencies.

---

So, here are 20 packages from sid, which are in the top 20 of most number of pre-/dependencies:

texlive-full:103
libjifty-perl:82
brdesktop-gnome:74
rhythmbox:72
evolution:66
xorg-dev:65
epiphany-gecko:58
gnome-control-center:55
epiphany-webkit:55
iceweasel-l10n-all:55
anjuta:53
gnucash:52
gnome-core-devel:52
brdesktop-common:52
gnome-desktop-environment:51
mplayer:51
beagle:50
dtc-common:49
totem-gstreamer:49
gnome-power-manager:49

Note that ORed dependencies are, correctly, counted once only.

Here's a usertagged list of bugs I filed when I computed the values with the shell version of the script to see what was the reaction of the maintainers. Here's the list of the 20 packages with the more dependencies on sid as of ~2008-05-02.

103 texlive-full
79 brdesktop-gnome
68 rhythmbox
65 xorg-dev
60 evolution
57 epiphany-gecko
54 gnome-control-center
53 epiphany-webkit
51 screenkast
51 iceweasel-l10n-all
51 beagle
50 vlc-nox
50 python-gnome2-extras
50 brdesktop-common
50 anjuta
49 dtc-common
48 totem-gstreamer
47 python-gnome2-desktop
47 awn-applets-c-core
46 gnome-main-menu

So, it looks like we are only going up but not down :(

Ever thought that there should be an automated way to handle ssh keys? Do you know the administrators of your servers, and wish that SSH could verify new host keys from them automatically, based on your personal connections to the web-of-trust? Do you wish you could revoke and/or rotate your old SSH authentication keys without having to log into every single machine you have an account on?Do you administer servers, and wish you could re-key them without sowing massive confusion among your users (or worse, encouraging bad security habits among them)? Do you wish you could grant access to your users by name, instead of by opaque string? Do you wish you could rapidly revoke access to a user (or compromised key) across a group of machines by disabling authentication for that user?A group of us have been working on a public key infrastructure for SSH. Monkeysphere makes use of the existing OpenPGP web-of-trust to fetch and cryptographically validate (and revoke!) keys. This works in both direction: authorized_keys and known_hosts are handled. Monkeysphere gives users and admins tools to deal with SSH keys by thinking about the people and machines to whom the keys belong, instead of requiring humans to do tedious (and error-prone) manual key verification.We have debian packages available which should install against lenny (for i386, amd64, powerpc, and arm architectures at the moment), a mailing list, and open ears for good questions, suggestions and criticism.If you have a chance to give it a try (as a user or as an admin), it would be great to get feedback.

I finally got around to releasing eweouz 0.2 tonight. It is still a bridge between emacs and Evolution Data Server, now with both gnus and wanderlust support. Changes include:

• Actually works now, sans stupid typo
• A bit more documentation
• Now handles non-ASCII names, thanks to setlocale.
• Be a bit more paranoid and fail if opening addressbooks and such fails.

eweouz now also has a mailing list and a git and gitweb repositories.

As I start this blog post, I'm on the train between Amersfoort and Osnabr ck, on my way to Kiel, where there'll be a meeting of the m68k porters, kindly organized by m68k kernel maintainer Christian Steigies. I took the 8:40 train in Mechelen this morning, and if all goes well, I'll be arriving in Kiel at 17:22 tonight. Some train trip... but I certainly prefer that to any flight. Anyway. The days of Debconf were very nice. Debconf is a lot of things to me. Travel. Hacking. Mao, evolving into a drinking game. Beer. Attending talks. Giving talks. Meeting people. Face-to-face non-flaming. Gesturing for an extra knife at luunch. Hangover. Whiskey. Talking to the person next to you—over IRC. Getting killed before knowing what the rules of the assassins game are. Filing bugreports in person. Pictures. Kilts. Streaming video. Not being sick, hopefully. Name badges. Flying. Sleeping. Yes, sleeping. Most of all, though, this year, Debconf was just great. Thanks. You know who you are. After debconf, I flew to Buenos Aires, where I slept for one night in a Youth Hostel somewhere downtown. They were affordable, but the bed wasn't great—the mattress sorely needed replacement. Since I had a day in BA, and since there were apparently not enough people on the schedule, I'd agreed to hold a talk, and came up with the idea of a 'debian secrets' talk—about Debian-specific commands, such as dpkg-divert and update-alternatives etc—so that people could learn how to use their Debian system more efficiently. As I was sitting in Andreas' talk, who was right before me on the schedule, suddenly Dag walked up to me and said hi. This was unexpected; Dag is a fellow Belgian, who's involved with the CentOS project, and who maintains a positively huge RPM repository at his site—if you maintain an RPM-based system somewhere, you'll probably know about that site. So while I recognized him, I immediately wondered what he was doing there. Turned out he was invited to hold a talk at the Free Software event to which Debianday was attached (and which would not start for another day or two), and that when he saw my name on the schedule, he decided to attend. Fun. He learned a thing or two from my talk, and was talking later about writing some tools for RPM-based systems that would perform the same or similar functionality implemented by some of the Debian tools I talked about. Great. We had a picture together (in front of the DebConf banner—hah) that I still should upload, and then went out for lunch together with some other CentOS guys. The talk itself seems to have been well-received, and I'm glad about that; I only gave it because there was a need for more talks, not because I felt confident I was very knowledgeable about that subject. In fact, I did have to ask on the debconf-discuss mailinglist for some input (which I received) so that I could make sure the talk would actually be useful to people. That helped a lot, I guess. After that, we played some mao in the lobby of the DebianDay venue. While doing so, I overheard Dag talking about CentOS, advocating it to some of the people there, which I must say felt pretty weird on a Debian event. Not that there's anything wrong with it, of course. Except that Dag was supposed to be writing his talk slides. How did that work out, Dag? ;-) Eventually, I got in a cab to the EZE airport, and flew home. That wasn't fully without issue, but I did get there. And now, I've been, eh, overloaded. Still have to follow up on a question a customer asked me, but I've barely been home or at the office, just enough to sleep really. Should do something about that, I guess... Two days ago, I also managed to forget my camera somewhere. For 12 hours, I was worried, even though I had a pretty good idea of where it was; but since I'm getting quite good at taking pictures now, and since I really like doing so as well, I really didn't want to lose my camera. Fortunately, when I called this morning to the place where I thought I'd lost it, they told me it'd been found, and where to get it. In other words, it's safe, it's taken care of, Philip went to get it, and I just need to arrange to get it when I get back. Which is a relief. Let's not be so stupid anymore in the future... Finishing up now, a day later, and I'm at Christian's office, playing with his and my coldfire board. As it happens, it appears that Freescale has brought out a new BSP for these boards, so that's nice. Let's see whether we can get those to boot again...

I’d been having problems connecting my laptop to my router to the Phone Coop using a new network cable that I laid under the floor just after the new heating system was installed. It’s a 1970s building - cat-5 wasn’t installed with the original wiring and mains homeplug networking is tricky on this wiring layout. The growing number of people with WiFi and video senders on my hillside (70% of UK users “never or rarely switch off their broadband wireless routers”) seems to be causing more interference and slow-downs, so it seemed worth installing a wired connection while the floors were up. The connection seemed to work fine, but then kept stopping for 20 seconds at a time - that’s just long enough to break network connections, but barely long enough to start up debugging tools, let alone get useful output. I was pretty sure the cable wasn’t at fault - Paul tested it with his fancy test gear when he completed the wiring for me. That left the hardware: my much-hated Belkin F5D7630 and the Realtek 8139 in the bizarre Compaq Evo N1015v. I’ve still not got around to replacing that Belkin and it’s been behaving itself well enough recently, while the Compaq has run smoothly once I actually got Linux onto it. I found the end of this Ubuntu Forums thread which pointed to this archlinux bulletin board thread which suggested pnpbios=off pnpacpi=off in the boot options. After adding that, the 20-second network pauses have stopped. But why? The ACPI and BIOS in this laptop are generally troublesome (and it looks like this also happens on some Presarios), but what in particular is going wrong this time? Will I suffer ill effects from switching off PNP options? Time will tell, I guess.

I took a note of the various talks I attended at DebConf, with the aim of writing a few notes about each so that I could try to explain to my work mates exactly what I get out of going. However I think a lot of the benefit is about general face to face contact with fellow DDs and random conversations that happen. Having worked from home for over 3 years I'm finding it quite nice to be back in an office with people working on the same things as me; there are conversations that you will have over a quick cup of coffee or in the corridor that you wouldn't bother typing on IRC or email or picking up the phone for. Debian is a lot like a large organisation full of telecommuters and DebConf provides a vital opportunity for us to have those "minor" conversations that prove quite useful and to remind each other what we're actually like in person. I didn't end up writing a lot of notes during the talks so these are just snippets after the fact. If I'd been more organised I'd have done a write up on a daily basis rather than leaving it all until the week after. A lot of the below is fragmented thoughts, but the longer I leave it the less relevant it gets and the more chance I forget something. It'd have been up faster if I hadn't been fighting Movable Type to try and get some sort of headings. Sunday
Introduction, Marga The "Welcome to DebConf" bit. Marga got up and talked about how at DebConf4 (Brazil) she hadn't been a DD and now she was and how it had been a life changing event. She'd thought she was to blame for DebConf8 in Argentina, but trawling mail archives had shown it was originally Mart n's idea. She hadn't realised at the start quite how much work it would be. Steve's DPL talk, Steve McIntyre The DPL welcomes us to DebConf and talks about Debian's achievements, some of the results of his team survey (the teams largely say they need more manpower. Not really a huge surprise.). NM/User Survey BOF, Paul Wise Paul emailed debian-user, debian-newmaint and various other places (I think) asking about people's experiences as a Debian user or applicant to New Maint. His final results aren't yet published and I got the impression a disappointing number of our users had replied. The NM problems these days seem to be largely down to a lack of AMs, at least according to the stats on nm.debian.org. Meet SPI board - bdale, maulkin, jimmy, michael, others A chance to meet those of the SPI board who were present. The usual "If you're involved with Debian you should seriously consider joining SPI". Some discussion about the fact that although SPI was originally mostly Debian these days other projects are making more and more use of it - OFTC, PostgreSQL and Madwifi for example. Not a huge amount of new information for me. I've been an SPI member for some time and I think they perform a vital role for Debian. They've had issues in the past but it's really good to see them overcome and more projects on board. Monday
http://hp.com/go/debian, bdale Bdale talks about the history of Debian and HP. And makes the point that HP aren't doing any of this to be "nice"; their primary responsibility is to their shareholders. Not surprising, but it's good that even with that criteria at the fore front Debian ends up a good idea for a large multinational. Managing 666 packages, Mart n Ferrari Mostly centered around the pkg-perl experience and the tools/workflow they have to help manage things. Impressive web tool (DEHS) to help track packages with new upstreams, issues or pending uploads. Quality Assurance in Lenny + 1 I can't remember a lot of this, which is a bit bad. I remember a discussion about whether we should release with orphaned packages, or if they should be removed. The argument for not removing them seemed to revolve around a theory that if they weren't buggy then what was the harm, the argument for was that if they were unmaintained and not really used than how did we actually know they weren't buggy, and was it reasonable that they potentially held up library transitions etc? Bugs in large packages Don Armstrong and ways in which the BTS can help people with lots of bugs. This (thankfully) doesn't affect me, but it was interesting to hear Don talk about his work on the BTS and his various ideas. I was sorry I'd missed his talk on SOAP access to it; I shall have to find time to watch the video. Tuesday
Debian and Ubuntu, Mark Shuttleworth The usual interaction with Debian stuff, including how we interact with our upstreams. If a bug is raised with an Ubuntu package then it might well be appropriate to raise it with Debian and upstream as well, but each set of people should be able to use their own bug reporting systems rather than having to go to a foreign system. I don't think it was actually said, but I guess the idea is that launchpad is the thing that will do this gluing together. He also talked about Ubuntu as an "experiment" rather than a fork of Debian; something that has potentially different ideas about how to do things but that these ideas may lead to things that should be fed back into Debian. The point was made that even if you consider Ubuntu a fork they've forked 9 times now; it hasn't been a case of forking once and diverging wildly since thast point. I have a few thoughts on all the whole Debian/Ubuntu stuff which I should really try to form into something coherant and post. I think it's important to take Mark's talk in the context of bdale's "Shareholders come first" point. Derivatives round table Didn't stay for most of this. Ubuntu, Debian-EDU (which I hadn't realised was a derivative rather than a team within Debian, but apparently there are various things it was much easier for them just to patch now and try to work towards a generic solution later), someone from Extramadura and someone from the Munich government Linux stuff. I'm sure I've missed someone off. tdebs/i18n This was a useful BOF. It helped that we said no to the usual video team requirement that if you want to speak you had to wait for the microphone. This works fine for a normal talk, but really impedes the flow of conversation in something like a BOF. tdebs are something that have partly come from a need of Emdebian to reduce installed package size and partly from the desire of the i18n team to be able to update package translations without having to do a full binary NMU of a package. We had some of the FTP team, the release team, the i18n team and Emdebian there and I think some progress has been made. There'd been various conversations had before this meeting which I think helped people think about the issues and objections so that we had answers by the time we all sat down together - an excellent example of the use of DebConf. DebConf9 C ceres Various bits of discussion about next year's DebConf in Extramadura. Temperature is likely to be an issue for me as they reckon it could easily get up to 40C! I'll melt! Venue sounds good; some queries regarding late night hacklabs and net connections to same, but I'm sure the networking team will sort it all out as usual. ;) DebConf10 bids Venezela and New York were both pitching. Lots of people don't want to travel to the US or think they'll have problems doing so (I hadn't realised there was such an issue for people from South America). I suspect various people will have issues with Venezela as well; I heard expressions of doubt over their political stability expressed. However I'd be happy to go to either (and preferably both! DebConf10 + 12 perhaps?) Speaking of which, what ever happened to the Sarajevo bid? If they're reading, have you considered DebConf11? Wednesday
A day trip to an Argentinian ranch and lunch was an asido. Fantastic food and a pleasant afternoon spent sitting in the sun chatting to people. That evening was the formal, but thanks to having stayed up until after 4 on Tuesday I had to wimp out and go to bed fairly early. Not until I'd seen the DPL dance though. :) Thursday
Internationalization in Debian I forget most of this other than pretty graphs from Christian regarding what's translated and what other languages we might have; e.g. you can consider South America to be covered largely by Spanish and Portuguese, or you can consider it to not be covered very much at all by the local indigenous languages. dh-make-webapp: yeah right! Mainly what I took away from this was "It'll never happen thanks to the fact that every web app author uses a different system" and that more work needs to be done on the web apps best practices document. I don't really do web apps, but having them easily installable on my systems is a good thing so I hope some standardisation within Debian comes from this. Best practises in team-maintaining packages Various team members got up to talk about work flow in their teams. Not unsurprisingly different things seem to work for different people. Predictable PRNG in the Vulnerable Debian OpenSSL Package Lucian giving his Black Hat talk about the OpenSSL issues we faced earlier this year. Some queries about automated testing and that it should have found this, which originally I agreed with until I thought about it - you'd have to have run > 65536 tests and compared all the data to find this; something like the FIPS tests against a single run wouldn't have shown any issues. Lucian wanted feedback on ensuring he was presenting the Debian side of things acceptably as well. Keysigning Run by Don Armstrong. Nothing to really remark except I think key signing attendance is dropping off after things like the Helsinki experience. Also I've now managed to get my new RSA key signed by keys other than my own (and I'll try to get sorted out to sign keys myself soon). Friday
LessWatts Intel's drive towards reducing power usage. Odd to hear such things from someone who wasn't Matthew Garrett and I think I'd heard most of it before. Debian technical policy update Sorry Manoj, I should have been paying more attention. Debian Policy is something I think is important, but I'm not enough of a nitpicker to really feel I can contribute a whole lot. Virtualisation in Debian - Present and future This was depressing. What I took away was "We had 2 forms of virtualisation in etch (Xen + vserver) and we're supporting neither for Lenny". As someone running a Xen machine this is problematic. The host does have the hardware support that would allow kvm, but I'm worried about smooth migration (it's a colo box). There was some mention of Xenner, which isn't packaged for Debian. I took a look at doing so but there are some worrying items in the TODO list (like, oh, locking to enable reliable SMP) and I've spectacularly failed to get it compiling so far. I should have another go. Emdebian update Neil Williams about where Emdebian is and waved his Balloon3 about. Some interest from the Openmoko guys and discussion about why it might be better than OpenEmbedded. And equally what it couldn't do that OpenEmbedded can manage (mainly very small installs; a minimal Emdebian install is 24MB+ and with X that goes up to 75MB+ I believe). netconf I'd never actually seen Martin talk about netconf before. Am impressive flow of control diagram. It all sounds quite complex for little benefit at present, but if he pulls it off then I can see it being a much more flexible replacement for the likes of Network Manager. Saturday
Lenny - The Road To Release Neil played with putting the heads of the release team on random images. And tried to tell us all how to behave during the release process in terms of what should and shouldn't be uploaded etc. Most of it is just common sense, but apparently everything he talked about he'd experienced. Also pointed out we were supposed to release in 3 weeks and didn't even have the appropriate kernel in testing yet so it's probably not going to happen. Colour me surprised. Sustainable Computing Low power consumption/affordable computing. Interesting points about the OLPC being used in the middle of nowhere with no chance of an Internet connection being close by compared to neighbours in large cities where people can't necessarily afford top of the line computers or individual connections - in this sort of scenario mesh networking is really viable in terms of getting people connected up. Multi winner voting Manoj needs pretty diagrams, probably drawn by Martin Krafft. ;) Semi-interesting discussion about multi-winner voting (e.g. SPI board elections) and how the current Debian voting system is completely tied to Debian's infrastructure eg the LDAP setup. Manoj would like to make it more generic so it could be used by other groups as well as for different sorts of votes in Debian.

I’ve had little time in the four years I’ve lived in Roslindale to get involved in community volunteer efforts. My wife Rachele, however, has devoted several years to efforts such as the Roslindale Community Center, Roslindale Village Main Streets, and Roslindale Clean and Green. She has served as chair of both RCC and one of the RVMS committees. Over the past few months, I’ve been disappointed to see the RCC board endure repeated senseless attacks by a perhaps overzealous community member, Walter Michalik, who has effectively paralyzed the organization. I have nothing personal against this guy, but I thought I could do my part here by publishing an example of an email he broadcast to the committee, which I think is embarrassing enough on its own merits to need no editorializing from me, except to say any email that starts with “just so you won’t be surprised when the IRS launches its investigation” can be neither productive nor taken seriously. The context is a response to an announcement sent out pursuant to the Community Centers By-Laws scheduling a special meeting to discuss the recent upheaval on the Council. There’s no reason this should not be in the public record:

Rachele Just so you won’t be surprised when the IRS launches its investigation, be advised that YOU DO NOT HAVE THE AUTHORITY TO CALL FOR A SPECIAL MEETING. The By Laws do not allow the President/Chair to call for a Special meeting - that right is reserved for the MEMBERS to have a power over a hostile or non-performing President/Chair. It was created by a Membership wary of annimosity within its ranks in order to protect itself from falling into a useless dysfunctional body. That’s why our By Laws require the majority of the membership request it through the Chair and not the other way around. So you screwed that up too. Your continuous violation of rules and laws have proven beyond a doubt that this current Roslindale Community Center Council has violated the trust behind its IRS-designated not-for-profit status. The failures are on so many significant levels over 6 months it is readily apparent that the Roslindale Community is better served without a Community Center Council. There is no longer any excuse to allow the residents of Roslindale to be denied the services they deserve that you and the officers have no idea how to deliver. Because that’s what you are supposed to do - serve the residents of Roslindale and not preseide over a self-serving board. You’ve taken us from dysfunctional to non-functional over the past 60 days. You and your officers have already driven away our Archdale partners and now the merger is off. Congratulations. You got what you wanted. You and the officers have withheld information from the Members of the Council imposing gag orders along the way and in more than one instance spreading lies within this community. There are so very many lapses on your part and the rest of the officers that it is very apparent that the Roslindale Community Center exists IN SPITE OF the Roslindale Community Center Council - not because of it. It would be far better indeed, if the Center were run without the Council. What have you done in 6 months? All you do is avoid the work of leadership. Please, just gracefully step aside and let a real leader emerge - or dissolve the Council and let the Center run itself under BCYF before the IRS makes that happen. Of course this is my stated opinion. You can choose not to belive it. You can huddle with a group of self-serving officers and invent excuses or change the agenda away from the message and continue with your ad hominem attacks against the messenger. I’m thick-skinned. Feelings aren’t important to me - services to residents are important to me. While I have, in fact, enjoyed the confidences of others within this community and their true displesure with this Council, I will produce that to the appropriate authorities as I see fit along with the Bill of Particulars I have produced with documentation for all charges. As a founder of the Roslindale Community Center Council I can no longer support you or the officers as any legitimate authority in this community.

Technorati Tags: Boston, Roslindale, Walter Michalik

Share This

When you have a server on the Internet, you get lots of "brute force" attacks on the SSH daemon, trying plausible logins with a variety of passwords. Even with good passwords, these attacks might eventually succeed (and they're annoying even when they don't), so you want to thwart them. One way is to use fail2ban, a script that monitors the failed connections, and sets up firewall rules (for instance) blocking further connections from the attacking IP addresses. It's good, but it fills your logs with messages about IPs getting banned and unbanned after a while. And you're still at risk that the multiple connections crash the SSH daemon, or trigger a bug in it, or whatever. A second layer of protection can be to block all SSH connection attempts except when they come from known IP addresses, but that doesn't work when you're away from home, and you're locked out. Been there, done that. So, some wise people have devised a trick called "port-knocking". It's similar to only opening the door to people who use a special knock (think "That's all, folks"): the firewall stays closed, but it opens a tiny targeted hole to some IP addresses for a limited length of time, based on a secret handshake. The window for attack is therefore very small, and the SSH daemon stays idle most of the time. And you can still log on your hosted server when you're attending conferences. There are a variety of implementations for this concept. Some could be web-based (you need to submit the right password to a web page), some could use other services or a dedicated daemon. But when I started investigating port-knocking, I wanted something simple, preferably with no dependencies on a daemon that would need to be exposed to the net and potentially crash. I found an article on the Debian Administration website, but I wasn't entirely satisfied with it. The principles appealed to me (netfilter-only, secret handshake in the form of opening connections to secret ports), though, so I evolved it into my own implementation, which I proudly present to you today. The goals of this implementation were:

• flexibility;
• robustness;
• resistance to replay attacks;
• no dependency on user-land daemons;
• simple, easily auditable code;
• must not be a pain in the neck to use.

The bulk of the work therefore stays in the kernel's netfilter (that's for robustness and no user-land dependency), but the control interface is integrated with the usual firewalling script. Resistance to replay attacks is achieved by choosing hard-to-predict ports. So if someone snoops the wireless while I'm at a conference and catches my secret handshake, it'll only be valid for a short period of time, hopefully short enough to prevent dictionary attacks. The handshake is therefore calculated as a function of the current date and time, with an added secret seed. The following shell function calculates 5 port numbers within a given range (requires dc to be installed, for big-integer arithmetic):

calc_knock_ports ()  
    secret=$1
    bottomport=$2
    topport=$3
    nbports=$(( $topport - $bottomport + 1 ))
    hash=$(TZ=UTC date +%Y-%m-%d-%H-$secret   md5sum   awk ' print $1 '   tr a-z A-Z)
    num=$(echo 16i $hash f   dc)
    pk_port1=$(echo $num $nbports 0 ^ / $nbports % $bottomport + f   dc)
    pk_port2=$(echo $num $nbports 1 ^ / $nbports % $bottomport + f   dc)
    pk_port3=$(echo $num $nbports 2 ^ / $nbports % $bottomport + f   dc)
    pk_port4=$(echo $num $nbports 3 ^ / $nbports % $bottomport + f   dc)
    pk_port5=$(echo $num $nbports 4 ^ / $nbports % $bottomport + f   dc)
 

Okay. So this function calculates ports, now what? Now we're going to define a few chains by which netfilter will store states of IP addresses as they progress through the handshake:

setup_portknocking_tables ()  
    iptables -N portknock_into_phase1
    iptables -A portknock_into_phase1 -m recent --name PK_PHASE1 --set
    # iptables -A portknock_into_phase1 -j LOG --log-level notice --log-prefix "INTO PK_PHASE1: "
    iptables -N portknock_into_phase2
    iptables -A portknock_into_phase2 -m recent --name PK_PHASE1 --remove
    iptables -A portknock_into_phase2 -m recent --name PK_PHASE2 --set
    # iptables -A portknock_into_phase2 -j LOG --log-level notice --log-prefix "INTO PK_PHASE2: "
    iptables -N portknock_into_phase3
    iptables -A portknock_into_phase3 -m recent --name PK_PHASE2 --remove
    iptables -A portknock_into_phase3 -m recent --name PK_PHASE3 --set
    # iptables -A portknock_into_phase3 -j LOG --log-level notice --log-prefix "INTO PK_PHASE3: "                     
    iptables -N portknock_into_phase4
    iptables -A portknock_into_phase4 -m recent --name PK_PHASE3 --remove
    iptables -A portknock_into_phase4 -m recent --name PK_PHASE4 --set
    # iptables -A portknock_into_phase4 -j LOG --log-level notice --log-prefix "INTO PK_PHASE4: "
    iptables -N portknock_into_phase5
    iptables -A portknock_into_phase5 -m recent --name PK_PHASE4 --remove
    iptables -A portknock_into_phase5 -m recent --name PK_PHASE5 --set
    iptables -A portknock_into_phase5 -m recent --name PK_ESTABLISHED --set
    # iptables -A portknock_into_phase5 -j LOG --log-level notice --log-prefix "INTO PK_PHASE5: "
    iptables -N portknock_accept
    iptables -A portknock_accept -m limit -j LOG --log-level notice --log-prefix "ACCEPTED AFTER PORTKNOCKING: "
    # iptables -A portknock_accept -m recent --name PK_PHASE5 --remove
    iptables -A portknock_accept -j ACCEPT
    iptables -N portknocking
 

These chains use the recent module, which seems to be commonly available in standard kernels. You'll notice how, as one packet goes through these rules, its originating IP address moves from one set of "recent" addresses to the next. But no logic exists yet to make the packet actually go through these rules, so here comes the glue:

refresh_portknocking ()  
    calc_knock_ports f00b4r 10000 10999
    iptables -F portknocking
    iptables -A portknocking -p tcp --dport $pk_port1 -m state --state NEW                                                 -j portknock_into_phase1
    iptables -A portknocking -p tcp --dport $pk_port2 -m state --state NEW -m recent --rcheck --name PK_PHASE1 --seconds 5 -j portknock_into_phase2
    iptables -A portknocking -p tcp --dport $pk_port3 -m state --state NEW -m recent --rcheck --name PK_PHASE2 --seconds 5 -j portknock_into_phase3
    iptables -A portknocking -p tcp --dport $pk_port4 -m state --state NEW -m recent --rcheck --name PK_PHASE3 --seconds 5 -j portknock_into_phase4
    iptables -A portknocking -p tcp --dport $pk_port5 -m state --state NEW -m recent --rcheck --name PK_PHASE4 --seconds 5 -j portknock_into_phase5
    # echo clear > /proc/net/ipt_recent/PK_DONE
    echo clear > /proc/net/ipt_recent/PK_PHASE1
    echo clear > /proc/net/ipt_recent/PK_PHASE2
    echo clear > /proc/net/ipt_recent/PK_PHASE3
    echo clear > /proc/net/ipt_recent/PK_PHASE4
    echo clear > /proc/net/ipt_recent/PK_PHASE5
 

Right. This function adds rules to the portknocking chain. A packet injected into this ruleset will, depending on its destination port and whether its source IP address has already been seen, end up in one of the PK_PHASE* sets. All we have to do now is therefore to send some packets to this portknocking chain, and use the port-knocking sets to decide whether to accept incoming connections or not:

iptables -A INPUT -j portknocking
iptables -A INPUT -m recent --rcheck --seconds 5 --name PK_PHASE5 -m state --state NEW -p tcp --dport ssh -j portknock_accept

This example only mentions accepting incoming SSH connections, but it's in no way a limitation: a server of mine uses similar rules to DNAT certain ports to internal IP addresses. And there we have it for the server part: incoming SSH connections are usually ignored (well, handled by the rest of the firewall script, but let's assume that it drops these packets by default), but if one IP address knows the appropriate ports and sends a connection attempt to them in order, then it'll be able to open SSH connections for a little while after that. Of course, it's going to be boring if one has to send these packets by hand, but it can be easily automated by a script. Here's a ~/bin/portknock.sh I have:

#! /bin/sh
host=$1
port=$2
calc_knock_ports ()  
[...]
 
calc_knock_ports f00b4r 10000 10999
for i in $pk_port1 $pk_port2 $pk_port3 $pk_port4 $pk_port5 ; do
    nc -w 1 $host $i < /dev/null > /dev/null 2>&1
done
nc $host $port

It's designed to be called with two parameters, a host and a port, and it needs netcat in addition to dc. Why the last line, I hear you cry? Because then I can just add the following lines to my ~/.ssh/config:

Host blahblah
  IdentityFile foobar
  ProxyCommand /home/roland/bin/portknock.sh %h %p

...and SSH will automagically tunnel its network socket through the script, which will in turn happily tunnel that through netcat after completing the secret handshake. And when I type ssh myserver on my laptop, interesting stuff happens behind the scenes, and a special, just-for-me hole is opened in the server firewall, just for the few seconds I need to establish the SSH session (packets belonging to established TCP sockets are allowed by the firewall's connection tracking). Note: This article is deliberately short on details and ready-to-run scripts. Firstly because firewall scripts vary wildly so any script would have to be adapted anyway, but mostly because security is best handled with one's brain switched on. Fiddling with a firewall can easily open gaping holes or lock everyone out. So please make sure you understand what goes on before blindly pasting stuff into your own setup. Some of the lines that are commented out may also be of interest, and were left as an exercise for the reader. Other lines were not included, and are also left as a rather important exercise to the reader; note in particular how the netfilter rules as currently established do not mitigate the replay attacks...

The Debian-Med CDD was started in January 2002 and has evolved a lot
since this time. Debian now becomes the distribution of choice for
people who are working in the field of medicine. On the one hand this
can be obtained from the increase of pure numbers of packages in the
field of medicine.

On the other hand - which is even more interesting for general Debian
development - a group was formed that has developed a certain way of
cooperation which might serve as an example for other teams. Debian
knows a lot of technical teams focussing onto technical issues
(pkg-perl, pkg-python, d-i, etc.). An important part of the project is
to involve people who call themselves "pure users" or "non-developers"
(whatever this might mean) as it is done at a certain amount by the
i18n and Debian Edu team.

So this talk is not about boring the audience by mentioning medical
Free Software - it exists at a certain amount out there as other
specific software does as well - but rather how to attract people to a
topic where FLOSS is not common but should. It will give examples for
our way to advertise Free Software in medicine which is heavily
dominated by proprietary software, which tools we developed inside the
CDD framework to be always up to date with our web pages that are
intended to attract users to Debian and last but not least the lessons
we have learned in the project that might be of high interest for
other CDDs (or potential CDDs). Examples are given for project
management, attracting people by working techniques and making sure
that medical software finds a good home in Debian.
Full event details

Hi folks! We’re almost done for the official Summer of Code program and I thought that I couldn’t let it end without another update, so here we are (you may thank Daniel Burrows for additional poking). The Gtk+ interface for Aptitude is making great progress. The product is not final yet but already implements many of the planned ideas, with others to come. Here are the screenies: So, let’s see the tasks presented in my previous update:

• A real user interface <- much progress here
• Being reliable <- check! we don’t crash all the time anymore
• Packages dependencies, pre-dependencies, etc. <- check!
• Hyperlinks between packages <- check!
• Advanced package search <- check!
• Tags support (tag clouds ?) <- well, no clouds yet, but we have tags
• Linking with interesting data sources like popcon <- not done yet
• A lot of interesting things <- well..

In some more details: we are now much closer to the final interface. Some things are not done yet, for example, notification bars la Iceweasel (or is it Firefox ?) are in the works for unobtrusive notifications about important things and a little guidance. We are much more reliable now. We eliminated lots of memory management problems that resulted from, mmh, imperfect coding discipline. We also lock the interface when important backend stuff reload to prevent the user from shooting himself in the foot when triggering an install when the APT cache is reloading for example.. The backend refactoring took a sizable part of this second term but it was worth it. The code is now much cleaner and uses no more (at least much fewer) ugly unscalable hacks. One very important feature of Aptitude is the ability to easily display all kinds of dependencies and navigate through them by hyperlinking. It’s now working in the Gtk+ interface as well. Feel free to click on whatever looks like a package or a package version. We now support the powerful Aptitude package searching syntax. Daniel Burrows is talking with Enrico Zini to bring the power of apt-xapian-index to Aptitude: autocompletion! lightning fast full-text searches! tag clouds! ponies! There is still a lot to be done. I’m not going away after the GSoC program. I’m here to stay, for Aptitude and Debian. Daniel Burrows has been very helpful and supportive. The Debian community is as awesome as I knew it before participating in the program. Daniel Burrows is planning to merge the Gtk+ interface into the main branch in September and packages may appear into Experimental. With the very interesting evolutions of the upcoming Adept-3, Lenny+1 will show very interesting changes in the area of packages managers. Now for you. I need you to test my interface. All necessary instructions are on the development trac : http://dev.graffit.net/aptitude/trac.

I just released the first version of eweouz, the interface between emacs and evolution-data-server. Sources are available, no packages yet. It is now possible to both add contacts from within gnus and search for contacts. Patches and feedback is of course welcome.

Joey mailed lately just another announcement for the m68k port ermeeting. This year in Kiel from August 29th - 31st:

Executive summary:

2008 M68k Linux Porter Meeting
August 29th - 31st
University of Kiel, Germany


This summer we are organising a Linux porter meeting especially
targetting the m68k architecture. During the meeting current problems
of the m68k architecture, its integration in Debian, releases
etc. will be discussed.

The meeting will take place at the last weekend in August (29-31) at
the University of Kiel, Germany. Details and participants are
collected here:

This meeting is evolved from the Oldenburg porter meeting that has
started with the m68k architecture but had to stop two years ago.


Interested developers and supporters are invited to join the meeting
and help develop the m68k port of Linux.

If you are interested to attend this meeting, please drop Christian
(cts) or me a note or add yourself to the Wiki page.

Regards,

Joey

Despite all the problems the m68k faced in the last years, we're still alive and performing fine. Part of the meeting will be discussion about the current changes of the m68k port like Aranym buildds and other stuff.

So, if you're interested in the m68k port or the experience of the m68k porters for your embedded architecture, come to Kiel and visit us! :-)

A while back wanted to know about a replacement for my Dreambox. I was also asked to write up a summary of the replies. Initially I assumed that my Dreambox 7025C was failing, it showed a classic symptom, progressively increasing error rate which wasn't showing up on my neighbors. Since we share the cable they should see the problems too, so I ordered new tuners for the box and the problem persisted. In the end it turns out that the problems were initially showing on such channels that my neighbors weren't watching or in such amount that they didn't pay attention to it. In the end it was a problem in the feed and my box is just fine. I now have 2 brand new DVB-C tuners for the 7025 (anyone want to buy them?) and a perfectly working setup. (YAY!). In a way I feel lucky that the box wasn't failing on me. Nobody suggested any complete solutions, but I was able to spot ReelBox Avantgarde as a possible alternative. It runs Linux like I want it to, but it's way too expensive. Another alternative could have been Maximum 8000, which appears to be a re-branded Marusys C-8000. It has Linux as the OS but the community side appears to be rather lacking. Then again, it's a pretty new device... I was suggested VDR and MythTV as the DIY solution. I dismissed MythTV without even looking in to it. Although I must admit that it's been quite a few years since I tried MythTV, but it was way too unstable for my taste. Also I wasn't too happy about the architecture of it. VDR is something I could have tried. The downside appears to be that it lacks in hardware support. The last time I was building my own PVR I ran in to the common problem of getting a decent output to the TV. VDR folks have traditionally solved this by using a HW decoder card to output the stream directly to the TV. Using VDR with a budget DVB card is possible but not recommended because of the CPU power needed to decode the stream. I've always considered VDR to be the more sophisticated solution of the two, but it is starting to sound a lot more hassle than it's supposed to. Also, the DIY solutions are hard to get in to a decent form. Usually the cases are bulky and custom modifications are required. I'm not one of those guys that install neon lights to their computers to make it look cool, but if I'm having it in my living room I expect it to look decent. Take a look at the VDR boxes section on the website for examples. While I admit that it's up to me to build a decent box, I'm not willing to spend too much time hand picking every single component so that it fits a casing and works with the given application. Finally, I'd like to thank all the people that sent me comments. Even though I ended up sticking with the current setup, it was a valuable look in to what is out there. The Dreambox I have, doesn't have a HDMI output and lacks in few areas. Keeping that in mind I'm eventually going to take this same look in to the alternatives while picking a replacement for the current box. Lets hope VDR, MythTV and Elisa (to name a few) continue to evolve and the video output properties of Linux become better and eventually I'll have the possibility of replacing my current setup with something that is even more flexible.

First day at debconf8's debcamp! I have published an ical file with the stuff I plan to attend, if anyone is interested: http://people.debian.org/~kov/kov_debconf8.ical. Btw, dear lazy web, the official ical file is using ART as TZID, and that seems to make Evolution go nuts on the timing of the talks. Anyone has got a clue on what my be happening? I downloaded the file and changed it to use America/Sao_Paulo as TZID and now Evo acts correctly.

Various people have asked me why there'd ever be a justification for ACPI tables to base various types of behaviour on the operating system they're running on, and why Linux claims to be Windows. There's pretty straightforward explanations that don't involve conspiracies, but they're not necessarily obvious. Let's start from the beginning.

ACPI provides two mechanisms for determining the OS, _OS and _OSI. _OS is an ACPI object containing a string. This string is supposed to represent the operating system. Windows 98 contained "Microsoft Windows", NT4 "Microsoft Windows NT" and ME "Microsoft WindowsME: Millennium Edition". All later versions of Windows contain "Microsoft Windows NT". Linux was "Linux" up until 2.6.9, and has been "Microsoft Windows NT" since then.

The obvious drawback to _OS is that it's a single string. _OSI was introduced with later versions of ACPI, providing an interface for ACPI tables to request which interfaces an OS supported. Interfaces may be something like "3.0 Thermal Model", indicating support for a specific aspect of ACPI, but may also be used to indicate the interfaces supported by the OS. The _OSI method is passed a string and returns either true or false depending on whether the OS claims to support that interface. The OS can therefore claim to support many different interfaces. Linux implements pretty much every aspect of ACPI that Windows does, and so claims to support all the interfaces that Windows implements. As a result, Linux will return true when asked if it implements support for any of the Windows interfaces (up to and including Vista).

That's all straightforward enough, but leaves two questions. The first is why Linux now claims "Microsoft Windows NT" for _OS. That's actually pretty simple - some DSDTs only check for various _OSI strings if _OS is "Microsoft Windows NT". This is stupid of them, but not a violation of the ACPI spec. The second is why Linux returns false for _OSI("Linux"). This is a little more subtle, but it basically boils down to "There is no Linux interface". The behaviour of Linux changes over time. We make no guarantees that its behaviour will be consistent over time as we find and fix bugs. Microsoft take a different approach. Their ACPI behaviour has few changes over time. Something claiming to be Windows 2000 will always behave the same way. We can't even bump the interface string per release - doing so would require us to maintain every broken behaviour we've ever implemented and switch between them depending on what the BIOS asked us for. Linux does not provide a stable ACPI API to platform firmware, and we make no guarantees that it ever will. The only behaviour you can depend on is that Linux will conform to either the ACPI spec or (where it differs) the behaviour of Windows. If you find behaviour that does not fall into either of those categories, then it's likely that the behaviour will change when we notice. The reason we removed Linux from the supported interfaces list in 2.6.24 was that we were beginning to see BIOSes that changed behaviour when they detected that they were running on Linux, and changes we wanted to make could have potentially broken these BIOSes.

Anyway. That's why we claim to be Windows. Now, why would a DSDT want to do anything with that information? It should be noted that making decisions based on this is not a contravention of the ACPI spec - section 5.7.2 even describes a case of this. There are a few situations under which this can be helpful. The first is due to varying interpretations of the spec. Early versions of Windows require that hotswap bays signal their removal by sending a bus check notification to the parent IDE bus. Later versions want a device check notification on the device itself. Both are valid, but you ideally want to use the right one on the corresponding OS. Checking the OS version lets you do so.


Red Stripe makes a lousy spec-compliant ACPI implementation. That is because it is not a spec-compliant ACPI implementation, it is beer! Hooray beer!

Another is user experience. Not all hardware is supported by all operating systems. For instance, older versions of Windows don't support high-precision event timers (HPET). The HPET is defined as an ACPI device, and so will show up as an unknown device in the Windows device manager unless the firmware disables it. This is acheived by altering a flag in the _STA response depending on the Windows version - earlier versions are told that the device should be invisible, and later versions are told that it should be exposed. Finally, there's bug workarounds. An example of this is Windows 98 crashing if a thermal zone reports a temperature of less than 15.8 degrees celsius. Working around that seems like a perfectly reasonable thing for a piece of hardware to do, since Microsoft don't make it easy for vendors to provide hotpatched versions of Windows.

The final part of this mystery is why various BIOSes attempt to check whether they're running on Linux. Almost all the BIOSes I've examined do nothing with this information, which is consistent with someone writing an OS lookup table many years ago and adding Linux just in case someone found it useful. People don't generally write ACPI tables from scratch (doing so would be very dull), so they'll base it on the one from a previous version. Code won't be removed unless it's breaking things, so you'll end up with various odd evolutionary dead ends that have persisted anyway. If your ACPI firmware checks for Linux, this is not inherently a bug in your BIOS. It's more likely that nobody cared enough to remove two lines of code that might turn out to be useful one day.

I am following closely this new DNS mess. In fact, there s nothing really new in that. DNS has been attacked lots of times over the years as a result of not being designed with security in mind from the ground up -, just this new one is a combination of known attacks against known security flaws. The quick fix is not a real fix, and just incorporate old ideas into the most used DNS software, strengthening it to face the attack. The details leaked, and there s already at least one public exploit (and who knows how many in the wild). The new buzzword is DNSSEC. I don t like DNSSEC. I never did. The first time I heard of it, around year 2001, it was a centralization of a decentralized database: A proposed company (called Network Solutions) would serve as a central authority, signing every root DNS entry. It was a joke! Come on! DNS is suppose to be decentralized! Having a central company anywhere is just a huge step back in decentralization (not to mention a huge step back in security). Time passed, and the DNSSEC specs evolved to a more decentralized way of thinking. The state it is now, and the implementations we saw so far are not good. No! I am not talking about security I am talking about the KISS principle: DNSSEC turns something really simple to deploy into a full-time job, with frequent key roll-overs and re-signing everytime you change the zone a huge mess! Yes, there are automated tools, but, come on! you still have to wait for TTL to expire before publishing this part or that part of the cryptographic machinery And, if we are talking about real security, are we going to build some automated tool fire-and-forget -style and not follow it? If we are not looking at it as it goes, and it fails, we could end up with a completely wrong set-up or (even worse) a non-validating zone. And I haven t yet mentioned the increase in payload I am not completely convinced that this alone would not lead to DoS attacks just by compromising the responsiveness of the servers (and DoS attacks are already available for quite some time maybe the DNSSEC-medicine is worse than the disease ). The root ( . ) servers are not even DNSSEC-aware, and there s a whole class of other stuff to work-around the fact that they may not be DNSSEC-aware for quite some time yet. There has to be a simpler way! I can imagine at least three ways to fix the problem until we can fix DNS in a KISS way And they re all KISS also:

• Change Transaction ID field. This is the first Achiles heel of this crisis. Let s increase the length of this field to 2048 bits, or even larger. Better yet, let s make it variable, so every system administrator can set his servers own size. Yes, I know this leads to replacing ALL the DNS infrastructure, but isn t that what we are doing right now, anyway?

• Deactivate in-bailiwick injection. Over the years, DNS have been expanded to allow a lot of things other than translation of names into numbers (or to ease this translation). The second Achiles heel is the ability to inject the IP address for WWW.VICTIM.COM while consulting for 10294DKGJSDL.VICTIM.COM since both name-addresses are in the same bailiwick (in-bailiwick). Let s take a step back, and deactivate all this Before 1995, the same thing could happen with any addresses, including those out of bailiwick , and it was fixed to only allow those in-bailiwick Let s fix it again to not allow it at all!

• Good, and old iptables. Couldn t we just use iptables LIMITS to stop this attack and blacklist the attacker? We ve been doing this for a lot of other things (SYN-floods, ICMP attacks, etc). Can t we just do the same. Again: this is not a new thing it relies on multiple attacks in a short period of time, just like other attacks we ve seen and successfully blocked with these techniques

Maybe some of those three solutions are flawed Maybe none are flawed and can be deployed together Maybe I am wrong and DNSSEC is the only way to go But let s not panic, let s cool our minds and begin thinking it through. I still don t think DNSSEC is the holy grail Now I already spent more time than intended on this let me go back signing some zones ;-)

Several weeks ago, the people in charge of maintaining the Windows machines in my institute were desperate because of a series of virus outbreaks - Specially, as expected, in the public lab - but the whole network smell virulent. After seeing their desperation, I asked Rolman to help me come up with a solution. He suggested me to try replacing the Windows workstations by substituting local installations by a server having several virtual machines, all regenerated from a clean image every day, and exporting rdesktop sessions. He suggested using Xen for this, as it is the virtualization/paravirtualization solution until now best offered and supported by most Linux distributions (including, of course, RedHat, towards which he is biased, and Debian, towards I am... more than biased, even bent). So far, no hassle, right?
Of course, I could just stay clear of this mess, as everything related to Windows is off my hands... But in October, we will be renewing ~150 antivirus licences. I want to save that money by giving a better solution, even if part of that money gets translated to a big server.
Get the hardware
But problems soon arose. The first issue was hardware. Xen can act in its paravirtualization mode on basically any x86 machine - but it requires a patched guest kernel. That means, I can paravitualize many several different free OSs on just any computer I lay my hands on here, but Windows requires full- or hardware-assisted- virtualization. And, of course, only one of the over 300 computers we have (around 100 of which are recent enough for me to expect to be usable as a proof-of-concept for this) has a CPU with VT extensions - And I'm not going to de-comission my firewall to become a test server! ;-)
When software gets confused for hardware
So, I requested a Intel Core 2 Quad Q9300 CPU, which I could just drop in any box with a fitting motherboard. But, of course, I'm not the only person requiring computer-related stuff. So, after pestering the people in charge for buying stuff on a daily basis for three weeks, the head of acquisitions came smiling to my office with a little box in his hands.
But no, it was not my Core 2 Quad CPU.
It was a box containing... Microsoft Visio. Yes, they spent their effort looking for the wrong computer-related thingy :-/ And meanwhile, Debconf 8 is getting nearer and nearer. Why does that matter? Because I have a deadline: By October, I want the institute to decide not to buy 150 antivirus licenses! Debconf will take some time off that target from me.
Anyway... The university vacations started on July 5. The first week of vacations I went to sweat my ass off at Monterrey, by Monday 14 I came back to my office, and that same day I finally got the box, together with two 2GB DIMMs.
Experiences with a nice looking potential disaster
Anyway, by Tuesday I got the CPU running, and a regular Debian install in place. A very nice workhorse: 5GB RAM, quad core CPU at 2.5GHz, 6MB cache (which seems to be split in two 3MB banks, each for two cores - but that's pure speculation from me). I installed Lenny (Debian testing), which is very soon going to freeze and by the time this becomes a production server will be very close to being a stable release, and I wanted to take advantage of the newest Xen administration tools. Of course, the installation was for AMD64 - Because 64 bitness is a terrible thing to waste.
But I started playing with Xen - And all kind of disasters stroke. First, although there is a Xen-enabled 2.6.25 Linux kernel, it is -686 only (i.e. no 64 bit support). Ok, install a second system on a second partition. Oh, but this kernel is only domU-able (this is, it will correctly run in a Xen paravirtualized host), but not dom0-able (it cannot act as a root domain). Grmbl.
So, get Etch's 2.6.18 AMD64 Xen-enabled kernel, and hope for the best. After all, up to this point, I was basically aware of many of the facts I mentioned (i.e. up to this point I did reinstall once, but not three times)... And I hoped the kernel team would have good news regarding a forward-port of the Xen dom0 patches to 2.6.25 - because losing dom0 support was IMO a big regression.
But quite on time, this revealing thread came up on the debian-devel mailing list. In short: Xen is a disaster. The Xen developers have done their work quite far away from the kernel developers, and the last decent synchronization that was made was in 2.6.18, over two years ago. Not surprisingly, enterprise-editions of other Linux distributions also ship that kernel version. There are some forward-patches, but current support in Xen is... Lacking, to say the least. From my POV, Xen's future in the Linux kernel looks bleakish.
Now, on the lightweight side...
Xen is also a bit too complicated - Of course, its role is also complicated as well, and it has a great deal of tunability. But I decided to keep a clean Lenny AMD64 install, and give KVM, the Kernel Virtual Machine a go. My first gripe? What a bad choice of name. Not only Google searches for KVM gives completely unrelated answers (to a name that's already well known, even in the same context, even in the same community).
KVM takes a much, much simpler approach to virtualization (both para- and full-): We don't need no stinkin' hypervisors. The kernel can just do that task. And then, kvm becomes just another almost-regular process. How nice!
In fact, KVM borrows so very much from qemu that it even refers to qemu's manpage for everything but two command-line switches.
Qemu is a completely different project, which gets to a very similar place but from the other extreme - Qemu started off as Bochs, a very slow but very useful multi-architecture emulator. Qemu started adding all kinds of optimizations, and it is nearly useful (i.e. I use it in my desktop whenever I need a W2K machine).
Instead of a heavyweight framework... KVM is just a modprobe away - Just ask Linux to modprobe kvm, and kvm -hda /path/to/your/hd/image gets you a working machine.
Anyway - I was immediatly happy with KVM. It took me a week to get a whole "lab" of 15 virtual computers (256MB RAM works surprisingly well for a regular XP install!) configured to start at boot time off a single master image over qcow images.
KVM's shortcomings
Xen has already been a long time in the enterprise, and has a nice suite of administrative tools. While Xen depends on having a configuration file for each host, KVM expects them to be passed at the command line. To get a bird-eye view of the system, xen has a load of utilities - KVM does not. And although RedHat's virt-manager is said to support KVM and qemu virtualization (besides its native Xen, of course), it falls short of what I need (i.e. it relies on a configuration file... which lacks expresivity to specify a snapshot-based HD image).
To my surprise, KVM has attained much of Xen's most amazing capabilities, such as the live migration. And although it's easier to just use fully virtualized devices (i.e. to use an emulation of the RTL8139 network card), as they require no drivers extraneous to the operating system, performance can be greatly enhanced by using the VirtIO devices. KVM is quickly evolving, and I predict it will largely overtake Xen's (and of course, vmware and others) places.
Where I am now
So... Well, those of us that adopt KVM and want to get it into production now will have some work of building the tools to gracefully manage and report it, it seems. I won't be touching much my setup until after Debconf, but so far I've done some work over Freddie Cash's kvmctl script. I'm submitting him some patches to make his script (IMHO) more reliable and automatizable (if you are interested, you can get my current version of the script as well). And... Starting September, I expect to start working on a control interface able to cover my other needs (such as distributing configuration to the terminals-to-be, or centrally managing the configurations).

One of long standing things on my todo list was to make synchronisation work from my cell phone (Sony-Ericsson K750i) to some PIM application on Linux side (as a GNOME user Evolution is the natural choice). I tried it several times but it never actually worked. Today I gave it yet another try and I finally succeeded on first attempt :-). As a first step I just wanted to make a backup of all things. Gammu can do it quite well and it's the tool I trust for this purpose:

gammu backup /tmp/phonebook.vcf
gammu backup /tmp/calendar.vcs

Now it's time to play with OpenSync. We will use setup guide and SyncML guide as a starting point. As I had in past problems with both sides - both phone and Evolution failed with some random errors, I wanted to go step by step. So I started with setting up phone to files synchronisation:

msynctool --addgroup file2phone
msynctool --addmember file2phone file-sync
msynctool --addmember file2phone syncml-obex-client

Now we need to configure file storage, just tell it where it should store the data:

msynctool --configure file2phone 1

And change path in your editor to something like:

<?xml version="1.0"?>
<config>
  <!-- directory path for file-sync -->
  <path>/home/foo/phone-backup/</path>
  <!-- should care of subdirectories (TRUE or FALSE) -->
  <recursive>FALSE</recursive>
</config>

Now the more tricky part comes, we need to set up phone end:

msynctool --configure file2phone 2

Fortunately we can use example from the SyncML guide and just fill in Bluetooth address (you can get it using hcitool scan) and channel (sdptool browse 00:b0:0b:fa:ce:00):

<?xml version="1.0"?>
<config>
  <bluetooth_address>00:b0:0b:fa:ce:00</bluetooth_address>
  <bluetooth_channel>7</bluetooth_channel>
  <identifier>Sony Ericss</identifier>
  <version>1</version>
  <wbxml>1</wbxml>
  <username></username>
  <password></password>
  <type>2</type>
  <usestringtable>0</usestringtable>
  <onlyreplace>0</onlyreplace>
  <onlyLocaltime>0</onlyLocaltime>
  <recvLimit>0</recvLimit>
  <maxObjSize>0</maxObjSize>
  <contact_db>Contacts</contact_db>
  <calendar_db>Agenda</calendar_db>
  <note_db>Notes</note_db>
</config>

And now we should be able to synchronise whole phonebook from phone to selected directory:

msynctool --sync file2phone

Okay, this works, let's try more complicated thing - include Evolution in the chain. The steps are the same, config file for phone is the same, Evolution plugin has sane defaults you usually don't have to touch:

msynctool --addgroup phone2evo
msynctool --addmember phone2evo evo2-sync
msynctool --addmember phone2evo syncml-obex-client
msynctool --configure phone2evo 1
msynctool --configure phone2evo 2

But now comes the tricky thing - Sony-Ericsson phones usually have something broken around notes (or it is broken in OpenSync, I don't care, simply synchronisation fails without this step) and we have to avoid synchronisation of them. This can be done by changing filter file in group we've created above (usually in file ~/.opensync-0.22/group2/filter.conf):

<?xml version="1.0"?>
<filter>
  <note/>
</filter>

And finally we can start the synchronisation and it should work:

msynctool --sync phone2evo

You can also GUI multisync0.90 to do the configuration and start synchronisation, but it is not much different, you also still have to edit XML files.

At the Cola de Caballo waterfall, near Monterrey, Nuevo Le n, Mexico