/dev/zero - page 2
The infinite stream
When most IPv6-capable computers join a network they attempt to automatically find a router on the network so they can figure out what addresses to use, how to set up routing, and so forth. On BSD systems like my router, the
rtadvd(8)program manages the router’s side of this exchange. While
rtadvdis rather flexible, its configuration file is frustratingly terse and its documentation assumes the reader has a fair amount of knowledge already.
For IPv4, my network uses DHCP to hand out addresses and DNS information. When rolling out IPv6, I wanted to set things up similarly, but without managing addresses centrally with DHCP since machines can configure themselves correctly without one. Configuration like this is the sort of thing that I tend to forget and have to re-learn periodically, so for reference, the
rtadvd.conffile I used for that setup looked something like this:
vether0:\ :addr="2001:db8:1221::":\ :prefixlen#64:\ :raflags#64:\ :rdnss="2001:db8:1221::1,2001:4860:4860::8888,2001:4860:4860::8844":\ :dnssl="internal.example.com":
This makes machines configure themselves for the network
2001:db8:1221::/64, DNS domain
internal.example.com, and three DNS servers: a local one at
2001:db8:1221::1, and both of Google’s public servers.
The source of most of my confusion was figuring out the
raflagsis a bit mask with two flags: M, which means a DHCP server manages addresses, and O, which means that non-address-related information (in this case, DNS information) is available that way even if addresses are not. This network setup requires the O flag to be set and the M flag to be unset, which means
raflagshas to be 64.
Now that I’ve rolled this out I get all the niceness of auto-configuration without the need for a central DHCP server to keep track of addresses. Well, for IPv6, at least.
I previously wrote about the big, Raspberry Pi-powered TV set at Eucalyptus HQ that displays the #eucalyptus-devel IRC channel so developers can always see what is going on and jump in if they need to. That setup has worked quite well for some time now, but I recently came up with a way to make it even better:
Googly eyes have yet to fail me at improving a machine’s appearance.
The FAT32 filesystem is the closest thing we have to a universal standard for passing data around, but with the capacity of modern USB flash drives its 4 GB file size limitation has become problematic. exFAT is a popular contender for dealing with that, but the patent issues that surround it make true portability a pipe dream at best.
Enter UDF. As the filesystem of choice for DVDs and Blu-Ray disks, UDF support is ubiquitous. Appropriately-formatted disks are readable by operating systems dating back to the early 2000s. All that remains is figuring out how to format it. In general, there seem to be three important things to keep in mind:
- Remove all traces of previous filesystems. Different operating systems use different methods to detect what filesystems a disk contains, so ensure maximum reliability by eliminating potential sources of confusion.
- Format the entire disk, not just a partition. OS X seems to only look for UDF when the filesystem takes up the whole disk, as it does on DVDs, so overwrite the partition table before formatting the disk.
- Use the correct UDF version. UDF has a number of versions that add different features, but as you might expect, newer versions require newer operating systems. Windows XP will read up to version 2.01 out of the box, though some Blu-Ray drive manufacturers have released drivers for newer versions.
I formatted my most recently-purchased USB stick on Fedora. First off, I blew away the partition table and all traces of the FAT32 filesystem it came with:
# dd if=/dev/zero of=/dev/sdb bs=1M count=1 # wipefs -a /dev/sdb
Fedora uses the
mkudffscommand for creating UDF filesystems, which is part of the
# yum install udftools # mkudffs --revision=0x0201 --media-type=hd /dev/sdb
That’s it! Now the disk seems to be usable on Fedora, OS X, and Windows, which covers just about all of my computers. I will test OpenBSD one of these days.
There are undoubtedly ways to do this on other operating systems. Feel free to comment with instructions for your favorite operating system if you know them.
Amazon’s Route53 DNS service, along with several content delivery networks and other DNS providers let one create an “alias” pseudo-record that causes the server to respond to requests for one name with results for another name. While the ways current implementations of this function vary a bit, the biggest difference between all of them and a
CNAMEis that while a
CNAMEgets applied to every query regardless of the type of record something is looking for, an alias is specific to just one type of record.
While this sounds like a trivial difference, the benefits are surprisingly enormous. The most obvious effect is that it lets you point a bare domain name (e.g.
example.com) at something else (e.g.
www.example.com). The reason you can’t normally do this is because the
CNAMErecord you would normally use to do this would conflict with the
SOArecord at the top of your domain, but since the alias you would use for this only applies to
Aaddress records, this is no longer a problem.
Another property aliases have is that they don’t actually go over the wire. While a CNAME record returns to the machine looking up a DNS name, causing it to restart its search with a different name, the answer for an alias comes right out of the DNS server’s own database. This means that aliases can only be used for records for which the server is authoritative or at least has some means of reliably learning the answer it should return, but that’s good enough for a great deal of use cases, notably including those of most content delivery networks. The fact that servers look up what an alias points to before they send anything over the wire means that they can include this functionality without violating standards – no one else needs to change their servers or their clients to support it. If DNS standards evolve to support it in the future, this makes transitioning even easier as that change rolls out.
In short, aliases would solve one of the most commonly-encountered shortcomings of DNS, namely its inability to use a CNAME to point a bare domain at its www equivalent. Given that there are multiple proprietary systems out there that do this already, it’s about time we standardized on an approach.
Eucalyptus HQ has a big TV on the wall that displays the #eucalyptus-devel IRC channel so developers can always see what is going on and jump in if they need to. Until recently, a laptop drove that display, but that seemed like overkill to me, so I went to employ my Raspberry Pi running the Raspberry Pi Fedora Remix to do that instead. Since the IRC program it’s using, irssi, is text-based I don’t need to use any of the Pi’s precious little memory to run anything graphical, so I just needed to figure out how to make systemd spawn irssi instead of a login prompt on tty1.
I would normally do this by copying
/firstname.lastname@example.org then editing that, but F18’s version of systemd let me do this in an even simpler manner. By creating a directory with the same name as that file, plus
.d, I can add a config file to that directory that overrides only the parts of the original unit file that I need to change:
[Service] After=network-online.target Wants=network-online.target ExecStartPre=/usr/bin/nm-online ExecStart= ExecStart=/usr/bin/irssi KillSignal=SIGTERM StandardInput=tty StandardOutput=tty User=kiosk
Now I can just plug the system in and have it automatically up and running irssi in less than a minute.
I didn’t expect to have to run
network-online.targetis supposed to wait for a service that runs that itself, but for some reason systemd didn’t order things that way and irssi came up before the network connection did. Running that command as part of this unit worked around that problem.
consoleblank=0kernel parameter to prevent Linux from blanking the screen after the usual ten minutes of inactivity.
I’m using the TV’s USB “service” port to power the raspberry pi. That usually works just fine, but when the TV turns off it cuts the power to that port as well, abruptly shutting the raspberry pi off. I don’t have any data loss in particular to worry about, but turning the system back on causes some annoyance: when the TV turns on the raspberry pi also powers on and attempts to detect what kind of screen it is plugged into. At that point the TV hasn’t figured out what it wants to display yet, so the detection fails and I’m left with a blank screen until I reboot the computer.