Monthly Archives: January 2010

staticDHCPd 1.4.0 released

staticDHCPd 1.4.0 is now out, and it brings with it a large number of new features, many of which nobody will ever use! But adding them was a necessary step since every known relevant option and feature is now supported. (If something was missed, let us know)

From the changelog:

  • Added support for RFC2610 (options 78 and 79)
  • Added support for RFC2937 (option 117)
  • Added support for RFC3046 (option 82)
  • Added support for RFC3361 (option 120)
  • Added support for RFC3396 (long options)
  • Added support for RFC4174 (option 83)
  • Added BETA support for RFC4388 (LEASEQUERY)
  • Added support for specification of options by number
  • Rebuilt support for RFC3397 (option 119), with the caveat that the compression algorithm it describes was omitted

Hymmnoserver now more legible

Most of the Hymmnoserver‘s content is now presented in sans-serif, for your non-eye-bleeding enjoyment.

I still think the serif face looked nice and helped to give the site a “research”-type feel, which matches the feel of the original, but I do have to agree that, at smaller font sizes, sans-serif is easier to read. (If anyone complains about the switch, I’d be more than happy to change it back) deprecated has succeeded as home for all projects it once hosted. All users of the old site are strongly encouraged to switch to the new resources, categorized under the links at the top of this page, at their earliest convenience.

Of course, services like the Hymmnoserver, read-only subversion repository access, project wiki, static resources, and user directories will remain operational for the forseeable future, to make the migration process as smooth as possible. They will all be fully accessible until the fate of the network connection that currently links to the old server is decided later this year, at which point 301s and 410s will be deployed as necessary to keep search engines happy.

One exception to the keep-everything-alive-as-long-as-possible plan is that the wiki will no longer be maintained and will be entirely decommissioned once it is clear that Google’s spider has found and prioritized this site. This is to prevent duplication of effort and content drift, the avoidance of which benefits everyone. Once Google’s spider has picked up on the 301s served by the old site, it will be given a static front page explaining the migration plans and progress, to help keep everyone current with what’s happening.

Hymmnoserver now translatable

In preparation for Ar tonelico III’s launch, much of the code behind the Hymmnoserver has been reworked to make it easier to integrate whatever new dialect twists might be in the works. And, along the way, support for localizations has been dramatically improved.

So if you’ve wanted to offer the service in a non-English language, now (or maybe after all the At3 kinks have been worked out) is a really good time to start.

staticDHCPd 1.3.4

staticDHCPd 1.3.4 is out and you can grab it at Google Code or

It offers a large number of new features over 1.2.0, inspired by needs that have arisen over the past several days:

  • Support for DHCPDECLINE and DHCPRELEASE events
  • Diagnostic features to help find misconfigured clients in networks, particularly those that would interfere with normal operation of a network or a dynamic DHCP server
  • Improvements to how event-messages are formatted, making it easier to read through the event-log
  • Less-memory-intense caching logic without sacrificing speed
  • AUTHORITATIVE mode, which allows unknown MACs to be NAKed, rather than ignored, fixing an incompatibility with some vendors’ non-RFC-compliant relays
  • Support for having logfiles written to disk with the current timestamp as a suffix, simplifying the process of creating status snapshots

Hymmnoserver migration – Updated

Hymmnoserver has been re-homed at and the code has been reworked to make it much easier to port and set up; further refinements and a real setup guide will be provided as this week progresses. For the interested, will continue functioning, so there’s no reason to panic if you’re bad at remembering addresses.

There will be some inconsistency between the two servers until the migration process is complete, but it shouldn’t affect anything that matters.


The migration process is effectively complete. There will still be some code updates (addition of comments, optimizations, refactorings), but everything will be fully mirrored from now on.

Moving to Google Code

Part of the process of moving away from my old, potentially-hard-to-maintain-in-the-future project-publishing model involved moving my local SVN repositories to Google Code, Google’s open-source-friendly project-hosting service.

Setting up the project pages and moving my existing code over there was quite easy. However, I wanted to keep local read-only repositories to avoid breaking links while I get set up for future development work and because I like having redundant backups of things I consider important.

I figured I should kick this blog off with a post that others might consider helpful, so I’m documenting the actions I took below. Note that this will not preserve SVN UUIDs, so you’ll need to diff and patch any dirty working copies you or other committers may have or otherwise adapt the steps to suit your needs. I’m also assuming you’ve set up sudo. If not, do everything post-committing-to-Google as a user, like root, who has permissions that will prevent other users from being able to touch the mirror repository (only svnsync should ever be allowed to write to it, and you’ll be crontabbing that).

  1. Create and reset your Google Code repository
    1. Create a Google Code project
    2. Find and follow the “reset” link at the bottom of any page under the “source” tab
  2. Migrate your existing code to Google Code
    1. svnsync init EXISTING_REPOSITORY
      • You’ll be prompted to provide credentials to commit to Google Code; these can be found in your profile
      • If your old repository requires credentials to be read, you may also be prompted for those
    2. svnsync sync --non-interactive
  3. Wait while each commit is played out; if you have mature projects, this can take quite a while. Do NOT interrupt this process or you may be left with a locked repository on Google’s end, which you’ll need to handle manually (either by clearing the lock or resetting the repository again)
  4. At this point, everything you’ve ever done has been duplicated on Google’s side, so it’s time to create the local mirror to make sure that, in the unlikely event that Google suddenly disappears, you’ll still have access to your work
    • Before proceeding, it would be a good idea to grab a fresh checkout of your code from Google’s servers and make sure it matches your working copy, using diff and ignoring the .svn subpaths.
    • When satisfied that nothing was lost in the move, you may want to delete your old repository to avoid confusion; you can’t, using this method, just have it sync against Google’s repositories as-is (UUID mismatch); additionally, after remaking the repository, the same UUID-mismatch problem will prevent committers from updating a non-master repository, so this is a good thing
  5. Create a new repository to house code mirrored from Google Code
    1. sudo svnadmin create NEW_REPOSITORY_PATH
      • NEW_REPOSITORY_PATH should be specified in absolute terms, just to avoid confusion later
    2. sudo bash -c 'echo "#!/bin/bash" > NEW_REPOSITORY_PATH/hooks/pre-revprop-change'
    3. sudo chmod u+x NEW_REPOSITORY_PATH/hooks/pre-revprop-change
      • This avoids an error normally raised to prevent accidental damage to repositories
      • The command in step 2 may look a little funny — this is because the redirect needs to be caught within the scope of sudo, so the whole thing needs to be passed as a single argument to a new bash instance
  6. Synchronize your repository with the one on Google’s servers
    1. sudo svnsync init file://NEW_REPOSITORY_PATH
      • Note that you’ll have something that looks like ‘file:///var/svn/my_project’ here, with three forward slashes
    2. sudo svnsync sync --non-interactive file://NEW_REPOSITORY_PATH
  7. Set up a cron job to keep things synchronized every night
    1. sudo crontab -e
      • 0 3 * * * svnsync sync --non-interactive file://NEW_REPOSITORY_PATH
        • Adding this line will make your system synchronize the repository with Google’s servers every day at 3:00 AM; the first two values are minute and hour, so play with them as you see fit
  8. Everything’s done! Your code’s now on Google’s highly accessible servers, and surrounded by Google’s excellent project-management resources, and you have a local copy for paranoia’s sake