Planarity is indeed an addictive flash game. I just did level 13 in 19:30 minutes. What are your scores like?

This game was also featured in that cool Multi-Touch touchscreen video you might have seen some month ago.

There is however a rather generic approach that will lead you to a solution rather reliably. Don't just move around random vertices, instead pick one and move it into the center, now grow the solution from that center node. The higher the level, the less space you'll have, so keep it dense! Always look at all "new neighbours" first, where to place them best to avoid having to swap them later.

But by just walking around clockwise around the "convex hull" of what you've built so far, you get a pretty good network. I guess you can even prove it that you'll be able to solve it in O(n) that way when done right.

In level 13 I this worked quite good for me, except I ran out of space some time. I then picked a random outer node, moved it to the very upper left, and moved the "covex hull" to the borders of the screen.

From time to time you'll see you've made a mistake, but this can usually be solved by mirroring some group in your network.

Update: Level 14 in 18:13 Minutes. Looked like this:

with a small problem at the top edge of screen due to lack of space there.

Update: Level 15 in 14:01 Minutes. The schema works perfectly, you have to touch each node at most twice (once when discovering, and maybe switch place with a sibling when discovering the new neighbours). All changes are local, and you don't actually look at the lines, just at the colored nodes.

Unless of course you run out of space and have to rearrange.

Mike, please re-read my blog posting, especially the very first sentence:

I have a box still running woody, and can't run iptables recent match on it (see an earlier post in my blog on how to use this kernel filter to effectively block ssh scanners).

I've been using that method for well over a year I think. On those boxes that support it.

I have a box still running woody, and can't run iptables recent match on it (see an earlier post in my blog on how to use this kernel filter to effectively block ssh scanners). Every few days another hacker, most of them being IPs from China, hits it with a SSH scan.

When I notice these scans via logcheck mails and it still seems to be in progress I usually manually block that IP. Maybe I should move the ssh server to a different port for now.

Anyway, I just received the following lines via logcheck:

Apr  6 01:04:50 sshd[1371]: Failed password for news from 213.80.123.21 port 42768 ssh2
Apr  6 01:05:29 PAM_unix[23403]: (ssh) session closed for user testtest
Apr  6 01:05:32 PAM_unix[6136]: (ssh) session closed for user testtest
Apr  6 01:06:20 PAM_unix[6793]: (ssh) session closed for user testtest
Apr  6 01:13:38 sudo: erich [...] block_host.sh 213.80.123.21

So first of all, I happened to block that scanner by chance just a few minutes after he had actually hit an account with a weak password.

Fortunately, that user (like all users by default) has shell /bin/false, so these three logins were pretty short. Figures that I immedeately locked that account (which apparently has been sitting around for a year and was never used, locked as in "user not found"), and I'm annoyed that someone created an account with most probably username == password, despite the account creation tool even generating secure passwords for you. I also ran a system check, but it's clear that they couldn't ran their default attacks and didn't have time to come up with some clever mail/whatever combination to get in.

But a couple of things for you to take away:

• Use filters to block scanners.
• Monitor your logfiles. It's worth it.
• If a user doesn't need ssh access, don't give him ssh access. Consider a restricted shell, or a non-exec filesytem for untrusted data.
• Make sure you don't have accounts with extremely weak passwords such as username == password on your systems. That is what they are scanning for.
• Don't ever give access to the account creation tool to anyone who doesn't enforce a strict password policy, unless your tool does ensure that.
• Don't let users with shell access or similar pick unsafe passwords.

Oh, and it is interesting, that once they hit that "locked down" account, they actually gave up scanning. They tried three times logging in to that account, and then didn't scan anymore. Maybe I should modify my ssh server to send unknown users always to /bin/false.

I'm doing too many projects. I need to step back from most of them ASAP. I just don't want them to dwindle, but prosper...

I really need to find more contributors for

• LaySVN, Layered Subversion, a svn mod written for storing the configuration of non-identical servers in SVN (read: servers that have some configuration parts in common, some differ) and probably of use for other cases.
  I've recently started a rewrite of LaySVN for speed reasons; you can't work on a per-file base with SVN but need to plan ahead a lot
• Pyroman, a firewall tool featuring a IMHO nice configuration language and which is very fast due to using iptables-restore, and it has rollback on errors
• SSDDiff, a diff tool for XML which can handle complex cases very well. Some say it's doing a "semantic" diff, actually. The "fast" (approximative) mode needs some love, the prototyp app IO needs to be redone (i.e. output filename parameters), XML attribute changes aren't reported yet in all output formats. I've also done some nice HTML diffs with it, that could be made a separate HTMLdiff application.
• Debtags central database needs to be rewritten to fit our newer requirements (e.g. moderation of edits or specific tags), and moved to a new server (old one still being woody)
• musicsquirrel (unreleased), a PyGTK duplicate finding tool using TRM ("musicbrainz") signatures, could need some magic like duplicate album detection (by "clustering"), and a UI to mass-select duplicates accoring to some rules (e.g. kill all duplicates found in the "unsorted" folder, if there is a properly tagged version in some other place)
• SELinux-Basics, a package to help getting SELinux working, has some basic sanity check shell scripts for a fresh SELinux system. These should be rewritten in OOP fashion with python or so, and extended with some extra checks.
• SELinux on Debian needs more adventurous people testing and using it, fixing policy to match Debian needs, writing new policy for new services, writing tons of documentation, doing some pretty install scripts and fixing some upstream bugs (module linking still not working). And making it as easy to use as AppArmor claims to be, because SELinux IS better and should be used instead.
• ISL3893, a wireless AP chip with a linux-based SDK available, is finally receiving some development. Too bad I can't devote any time to it. It would be cool to bring it up to par with famous OpenWRT.

Oh, and half of above projects need a fancy web design and an icon.

Anyway, I should basically turn off my computer for the next two months and refrain from going online. :-( I know that I won't have the discipline to do so...

And there are oh so many projects still only existant in my head that I'd really love to do sometime. One involving new search technologies with tags, bringing together directories like DMoz, tag based stuff like del.icio.us and "traditional" text search engines. Definitely the stuff the Web 2.0 is made out of (read: hype). But when I'm done with my diploma this new dotcom bubble is probably over, too... :-(