|
andrew.mcmillan.net.nz
cd /var/www; more /dev/rant >>index.html
|
|
Howto
The IPv6 wave progresses apace. Well, perhaps not 'apace', but it is moving... The latest kernel exploit has incidentally had some local fallout in causing more of our boxen here to be upgraded to kernels with IPv6 support, and as a consequence our mail server is now reachable on IPv6. Some have suggested that making it only reachable on IPv6 is a good solution to spam but I suspect that there are still a few mailservers out there that we do want to receive e-mail from which are not IPv6 capable yet! Since I can now SMTP and IMAP happily over IPv6 I decided it was time to get more adventurous. IPv6 is now in Squid3 head, so I built Etch packages of that and it seems to be 'basically working' in a few places now. We've been using ircd-ircu for a long time for an IRC daemon and it similarly seems that now has IPv6 support, so I backported that to Etch as well. Packages are available for i386 and amd64 from my repository: deb http://debian.mcmillan.net.nz/debian etch ipv6 deb-src http://debian.mcmillan.net.nz/debian etch ipv6 If I think of more Etch things that I need for IPv6 I'll put them there too. I do have dircproxy for Etch with support for connecting to IPv6 ircd but I seem to have misplaced the packages somewhere. If you're keen on seeing that then I'm sure I can reconstruct them somehow... Now that we are having increasing amounts of IPv6 around some things are starting to reduce down to a 'Small Matter of Firewalling', which is suggesting to me that we will need manage our firewall rulesets differently for IPv6 than we have for IPv4. In a lot of cases we can turn on/off large chunks of access related to a particular person/organisation by disabling a VPN, with the firewalling being a somewhat static monolithic overriding control above that. With the control potentially moving away from the VPN, and more directly into the firewall rules, we will need clearer association mechanisms in place. Of course we will continue to have VPNs, but they might become somewhat simpler, reducing in many cases to encrypted tunnels between exact endpoints. A GPS is one of those toys that I have wanted for a very long time. So last year I finally marshalled enough excuses in one place, lined them up and plunked down some money for a Garmin GPSmap 60CSx in the vague belief that there's enough Linux software out there which understands GPS, and the Garmin is a brand that seems to have mature Linux support. And besides, I'd been told it was a good model that would do what I wanted and then some. Once I got it I naturally wanted to do stuff with it, and in particular I wanted to connect it up to my laptop which (of course) is running Linux and I found that it wasn't nearly as trivial as I had thought. This prompted me to run around finding software to use with it, so here's my capsule review of my journey from "extremely naive" to "very naive". Perhaps I'll also learn something from the comments of people who are further down the track. My first resort was "apt-cache search gps", of course, which immediately brings up such fine sounding programs as "gpsman", described as "A GPS manager" (I haven't managed to get it to do anything yet), "gpstrans" which since it specifically mentions Garmin GPS sounded like just the ticket (it appears to be quite old and superseded). There was some useful stuff as well.
Getting Maps on the GPSSince the Garmin GPSMap series will display maps, I wanted to be able to get some mapping data on there. There are two map sources I was interested in:
Using the NZ Open GPS MapsThe NZ Open GPS Maps are built specifically for the Garmin GPS, so getting them onto my GPS was relatively simple once I found out the exact command line was remarkably hard. The program that I needed to find to be able to get the maps onto my GPS was I downloaded the maps from the NZ Open GPS Maps hosted on the cGPSMapper site. I needed the files identified as 'binary' files - the installer is a Windows program and no use on Linux. They all have filenames like The command-line I first used to install the maps onto the GPS was: That works fine, but if you have even a moderately sized micro SD card in the GPS there are much faster ways. As I found more free maps I found much better ways to do it. An alternative approachIn the GPS (well, in my one anyway) there is a micro-SD card which is FAT formatted and all of the installed maps are in one humungous combined image of all of the uploaded maps. This means that there is no way to straightforwardly add/remove maps without creating that image, and re-uploading the whole thing. The image file is called 'gmapsupp.img' and is in the 'garmin' subdirectory on the SD card. This means that you can create the file (or even several different files, with different maps on them) and move them directly on there much quicker, either by taking the SD card out and using it in a USB2 reader (for really big files) or switching the GPS to operate in USB Storage mode (which is USB1, but OK for smaller files). You can create the IMG file to copy in as QLandKarteAnother program I found useful specifically for dealing with the Garmin GPS Map format is QLandKarte, which understands the native Garmin format and will display the maps in a graphical window. You can also point and click to select maps, building up a specific set that you can then upload to the device from within QLandKarte itself. This seems to operate a lot faster than sendmap20, presumably because it's driving the USB directly, rather than through usb_serial. To get it to work I seem to have to (a) sudo rmmod garmin_gps and (b) sudo QLandKarte, however, which is definitely not ideal. For the moment I will continue to use sendmap20 to create files which are sets of the maps I want, and will put them on the device in USB storage mode. QLandKarte is still very useful, however, for looking at maps and deciding if they are worth bothering with. I used it in this way to select the Australian maps I took with me when I went to Linux.Conf.AU recently. There are more free Garmin GPS maps. OpenStreetMap.orgThose Australian maps came from OpenStreetMap.org and ultimately I expect that it will become the best source of data for creating maps for my GPS. OpenStreetMap.org is an attempt to provide community-maintained maps for the whole world and which seems to have made significant progress in UK, Europe, America and Australia as well as many other parts of the world. The data from OpenStreetMap.org does not have the same licensing restrictions as are present even in the NZ Open GPS Maps data (which is relatively free, but has problems similar to the old-style BSD license). There are also some good mapping interfaces to the OpenStreetMap data although the searching currently still leaves something to be desired. Interfaces are also available for extracting subsets of the data, which is in a fairly straightforward XML format, or you can download the whole lot, but at nearly 3GB for the bzip2 compressed version you won't do it every day. I gave a brief overview talk about OpenStreetMap.org while I was at Linux.Conf.AU and it seemed to go down quite well (I gave it several times, in fact). You don't need a GPS to contribute to the project, and of course the maps which are being created are usable for many purposes beyond their usefulness on GPS. Some people apparently even print them out, but that just seems weird! I hate spam! Which probably puts me in the same camp as 99.99999% of the world. The other 1 in 10 million are, of course, the spammers, who seem to take the space invaders approach to sending e-mail: we'll keep sending you more until you die. A few years ago I used to only receive perhaps 1 every 100 seconds, which was pretty annoying, but Spamassassin was quite able to filter out 99% of those and let through about 1-2 each day, which I could deal with. My spam levels increased to maybe 1 every 20 seconds, and late in 2005 I implemented a second layer of spam filtering on my laptop using DSpam. This worked quite effectively, but DSpam is really not the tool for the job - it's much more appropriate as a company-wide antispam solution, and potentially as a replacement for Spamassassin. It drove me nuts on my laptop because it's resource usage slowed down the interactive response. When I got my new laptop at the beginning of the year I decided against continuing with my rather baroque mail setup and to leave the spam filtering on the server. What I didn't realise is that my spam rate had increased again to around 1 every 8 seconds, and it has been slowly driving me to distraction ever since. It seems to have cranked up another notch recently, to perhaps 1 every 3 seconds now, so that 1% making its way through Spamassassin was getting to a very annoying several hundred each day. The longer I took to resolve it, the more time I would be wasting dealing with it every day. What I chose to apply on this occasion was CRM114, which I had some vague idea might be able to help. I was fairly impressed by the relatively simple install, but what completely blew me away was the speed with which it was able to learn to be useful. Starting from scratch, it seems to be correctly classifying over 90% of my incoming mail after about 12 hours of training, on a total of only 75 'Unsure' messages. Even after only an hour it was getting over 50% (I'll describe my actual CRM114 installation process in a comment below). So far there have been no false positives. Now that CRM114 is installed I will be able to look into some of it's other mail classifying features too, and I'm really looking forward to that too. The availability of IPv6 worldwide is surprisingly extensive, nowadays, but over the past years as it has slowly filtered around, people have had bad experiences with it because of poor routing. It seems that, as always, a bad rep travels about 20 times further than a good one, so an automatic response to casual problems that people see when using IPv6 is to blacklist it, without actually investigating the problem. Take today, for an example. Someone said to me "I disabled IPv6 in Firefox because it was slow for one of my favourite sites". OK, so show me this favourite site. Show me the traceroute. Give me some facts! Further investigation showed that although there is an AAAA record for www.crooksandliars.com, there is nothing listening on the other end! Looking at the AAAA record returned, we see that it is an autoconfigured IPv6 address of the form xxxx:xxxx:xxxx:xxxx:xxxx:xxFF:FExx:xxxx and can conjecture that the likely problem is that someone has done a hardware upgrade on their server, so they now have a different MAC, and consequently the autoconfigured IPv6 address has changed. Other scenarios are entirely possible, of course, but this is a likely one. This is the second case I have seen where someone was running publicly available services on IPv6 using a manual DNS record pointing at an automatic IPv6 address, but I doubt that it will be the last. Unless there is infrastructure in place to automatically update your DNS when your address is autoconfigured, you are going to get bitten by this problem at some point if people remotely connect to your system for some service. A recent thread which started on the Debian Release mailing list caught my eye this week. I attempted to aid the migration of this thread to the debian-ipv6 mailing list, which is really a better place for this and sorely in need of controversial topics for discussion. It is interesting how people can so blindly decide that broken things should be destroyed. Repair often appears not to be an option, even for a long-term, wide-reaching effort like this, though we are all working on open-source software! In this case there are an unknown number of less fortunate people in the world who are located behind some kinds of broken DNS infrastructure which discards 'AAAA' lookups. Of course 'AAAA' lookups are attempts to resolve a name to an IPv6 address, and the resolver in a 'modern' libc (i.e. one from the last five years or so :-) will try to retrieve an IPv6 address before it attempts to resolve a name as IPv4 with an 'A' lookup. That is how the standard is written, so if you want to comply with the standard you have to do it that way. Other things also interfere, but this element of the specified behaviour seems to cause the most annoying and pointless whingeing I have heard. I suppose that the people who want working IPv6 make it so, and do not have problems with this behaviour. But it seems that people who are behind this kind of broken DNS either disable IPv6, or they have to whine about IPv6 being turned on by default, and can't we please all go back to the good old days. What's wrong with IPv4 anyway? Doesn't NAT solve all of it's problems? Are we sure this new (heh!) technology is safe? Fortunately some people are so good at making their pain felt by other people that they can get other people to do their work for them. So Mithrandir has written a nice elegant patch for libc6 so that it won't do the IPv6 lookups unless you have a usable IPv6 configuration. I've filed bug #435646 against Debian to get this included, but Aurelian Jarno justifiably wants a few people to test it a bit harder... So I've taken the original patch and tweaked it to apply against current libc6 sources (2.6-5) and tested it for myself. It works as desired, as far as I can see, when comparing behaviour with an unpatched system. The patch is attached to the bug report, of course. Perhaps some other people out there can put a wee bit of CPU into testing this for other environments so that we can make life easier for those people with no time / inclination to use IPv6, to ensure that they don't just disable it because it is making life too painful for them in it's current form? How to build libc6 for fun and proftIf you have appropriate deb-src URLs configured, and are running Sid, then the following will let you build a local copy of libc6 with the patch. This is probably better testing than if I just make my packages available (which are only i386 in any case).
Wait a few hours for it to build... Install... And then confirm that this only does 'AAAA' lookups if (when) you actually have a global or site scoped IPv6 address. When you only have a loopback or link local IPv6 address then you should only see 'A' record lookups. Step 3: profit! Whoops! I forgot the fun bit: please update the bug report :-) What the patch doesIn my opinion this is quite an elegant solution from Tolleff. He has picked a single characteristic of the IPv6 interfaces to further refine whether the IPv6 configuration of some interface is actually usable. With IPv6 it is much more common to have multiple addresses assigned to a single interface. Interfaces are automatically configured with a link-local address which is not globally routable, and the loopback interface is also configured with the IPv6 equivalent of 127.0.0.1 (which is "::1"). To get a usable IPv6 setup you will also end up with a more widely usable address. In most cases this will be a global address, meaning that it is (in theory) globally routable from other people who also have global addresses, or you could have a "site" address, which is the IPv6 equivalent of RFC1918 addressing. The patch considers that for the purposes of name resolution, it will be pointless to do AAAA lookups unless you have an address of the second kind. This means that people behind broken DNS won't be impacted unless the try and set up IPv6, and people who don't try and set up IPv6 won't get the 'hesitation' while their system attempts to resolve each address in IPv6 space first. It will also mean that when people start to enable IPv6 around them, their setup will continue to work correctly. A few years ago we needed to introduce employment contracts for all staff at Catalyst. When we got the example contract back from our HR consultant, she had quite naturally biased it strongly in the employers favour, and as a consequence it had a very anal and lawyerly clause in it regarding the ownership of intellectual property. This clearly wasn't going to work well in our environment so I decided to take the opportunity to try and write a clause which was fair and reasonable, which considered the likely desires of both parties, and which expressed an understanding of the sort of environment which often happens with free open-source software. It seems that many people who are interested in working on open source software are also people who will work on (i.e. fiddle with :-) things in their spare time, but they will not necessarily consider the possible consequences of using conmpany resources to do so. I have heard of situations where employment contracts (or perhaps even government enacted legislation) will give ownership of an individual's work to their employer in such situations, so I also wanted the contract to make it clear where and how this might happen. I would like to hear people's comments on the contract clauses which we use here. Is this fair to both parties? Have I missed something? Is the meaning clear? Also, I need to make it clear that it is OK for people to use this text, so I hereby place the text of the following Intellectual Property clause in the public domain. Intellectual Property
Over To YouI wrote that because I couldn't find examples around the place of similar things. I guess I still see people looking for that sort of thing so I'm publishing it here with the idea of providing a seed which can perhaps grow into something else. A few specific questions I would like you to think about:
Then, perhaps, if we can see some general agreement on what would, or would not, be a useful standard we can encourage people to use it in their future contracts. I am hoping that through your collective wisdom I will be changing this clause in Catalyst's standard employment contract. I see Brenda talking about wanting to use "Ruby", and trying to install "Rails". This conflating of the two terms annoys me. "Ruby on Rails" is a web development framework which is written in Ruby, and which uses Ruby for some customisation, but the primary learning curve in using it is to learn the framework. I installed it ("apt-get install rails", of course :-) and tried using it but found it frustrating, though that may be because the default Debian install was against MySQL. Ruby, on the other hand, is a language which is generally just as suited to writing off-line text processing scripts as it is to writing on-line scripts. It is also a language which has good database independence and GUI libraries. Two of the talks I went to at LCA this year which have had an impact on my coding were one about Puppet, a systems management application written in Ruby, and one about writing GTK programs in several languages. The GTK people didn't quite make it through their ambitious schedule so we only got to see them writing GTK in C and in Java (not in Python) but it did suggest how easy it all was. When I got back to NZ I put those two together and started writing (well, rewriting really) an application in Ruby/GTK, and I have found it a very nice language. It seems that every time I learn something new about Ruby my code gets shorter and provides more function in a clearer and more readable way. Fun. There are times when you want to track the bleeding edge of a particular project, and having a new laptop is often one of those moments... I've recently bought an HP Compaq nx6320 and while most of it is working, one of the reasons I got it was because of Keith Packard's work on the RandR extensions for X. Well, I was definitely seeing this bug but with a small patch I can get the latest (experimental) packages for xserver-xorg-video-intel to work, and now with a few magic tweaks to my xorg.conf I can make my desktop expand to another monitor when I unsuspend at work, and contract back to just the laptop screen when I resume somewhere else. The Magic Expanding X ConfigFirst of all, when I got the driver to actually work, xrandr explained to me that my maximum resolution was 1400x1400: Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1400 x 1400 VGA disconnected (normal left inverted right) LVDS connected 1400x1050+0+0 (normal left inverted right) 305mm x 228mm 1400x1050 60.0*+ 1280x800 60.0 1280x768 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 TV disconnected (normal left inverted right) Using a few clues from Ross Burton I managed to get that "maximum 1400x1400" to increase. The trick is to add a "Virtual" setting for screen size into your "Screen" Section, like so:
Section "Screen"
Identifier "Default Screen"
Device "Intel 945GM/GMS/940GML"
Monitor "Laptop Panel"
DefaultDepth 24
SubSection "Display"
Depth 24
Virtual 2680 1050
EndSubSection
EndSection
The downside of this is that if you set the width greater than 2048 (as I have here) then DRI won't work, so you won't get 3d stuff. I guess I can manage without ice-cream, just so long as I get my cake! Once I have the "Virtual" setting, when I resume at the office I can: xrandr --output VGA --mode 1280x1024 --pos 1400x0 And then when I resume somewhere without the external monitor, I can: xrandr --output VGA --off QuibblesAll of these features are kind of under development, but Xorg 7.3 will support this stuff, and then Gnome and suchlike will have to start thinking about how to deal with it. The dynamic screen changing is not something these environments are completely ready for. One example is that while I know that monitor is always on the RHS of my docking station, X wants it to be the primary monitor and Gnome moves both panels onto that screen. Perhaps that's not a choice that can be made automatically. Someone who had an external keyboard plugged into their docking station might want the opposite behaviour, and there is certainly no way the environment can magically know whether that monitor is left or right of my laptop screen. Eventually I expect that Gnome will recognise this monitor, and will make the panels and location automatically set the RandR environment to match the way I set it last time. It is also somewhat annoying that I have to actually choose the virtual size. No doubt this configuration will disappear in due course and it is not really surprising to see it for something which is admittedly quite bleeding edge! I noticed at LCA that Keith had his own screen set for a Virtual size of 2048x2048, and now I know why: that's the maximum size that is supported for DRI, so if I expand my desktop onto a 1280x1024 screen I'm going to have some overlap. In fact I could almost configure my external monitor to be above my normal screen and use it that way, but it would feel pretty weird I think. In the meantime I've gone back to "blank screen" for my screen saver which admittedly is currently the only application for 3d acceleration on my desktop. Remaining Problems with this LaptopThe only outstanding issues for me with this laptop are:
That's about the best Linux compatibility I have had for any of my last five laptops within a month of buying it. Most of them have had much more significant stuff less supported even after three years of use! Once upon a time I bought a Telecom New Zealand "3G" CDMA card (Sierra Aircard 580) so I could be better connected in those places where broadband doesn't reach. When I bought it I needed to do a lot of investigation and playing around to get it going, so I wrote it all up. Times have changed now, but I'm still using the same 3G card... For comparison purposes, and so people don't think it's still that hard, I thought I would write up here what it took to get this going on my new laptop. First StepIt is likely that you still need to follow the first step listed in my old document: i.e., to ensure that the device is actually activated with the Telco! Second StepPlug the card in. Having plugged the card in it was automatically detected and all the appropriate magic was done to create the necessary /dev/ttyUSB0 device node so we can use it for dialout. This was with Linux 2.6.20 kernel and 0.105 of udev but I think it's been all workingness for some time. Third StepConfigure PPP. I run pppconfig (as root) to configure the card, but I'm sure you could use "gnome-ppp", "wvdial", "kppp" or something else that takes your fancy. The critical points are:
Hopefully, at this point, everything will be working for you. TroubleshootingWell, really, all of this (and much, much more) applied to my earlier information, and I'm sure there are better pages out there on "HOW TO CONFIGURE PPP", but here's the basics of troubleshooting it anyway. So if, for some reason, you have problems with the above then check: 1. Did you actually connect?You might have connected, but your default route or DNS might not have been set up. You can use the PING www.bbc.net.uk (212.58.240.32) 56(84) bytes of data as it's first line (then press [CTRL c]. Some websites don't respond to the ping itself, but as long as the first line displays the IP address next to the name then DNS resolution is working. If all three of those things are working, but you still can't see any web pages, then you may need to change your browser configuration to disable any proxy you may use when you are connected to your LAN or wireless LAN. 2. No Default RouteSomething has gone wrong with the PPP connection if it didn't create a default route, but if you only have a single route in your In the output of the 'route' command you will see a line that ends in 'ppp0' and starts with a number, something like this: aaa.bbb.ccc.d * 255.255.255.0 U 0 0 0 ppp0 Using that number, type in the following command (as root, or using sudo): /sbin/route add default gw aaa.bbb.ccc.d Where 'aaa.bbb.ccc.d' is the number from the earlier '/sbin/route' command, of course. My Own ConfigurationI used pppconfig to set this up, and I call my connection 't3g', which translates to some of the filenames, so that name might be different for you. /etc/ppp/peers/t3gYou probably will want to comment out 'debug' when you get it going, and you may also want to change 'nodetach' to 'detach' to put it in the background once it's connected. I just leave it up in the terminal when it's running, however, so I can see if the connection has dropped. nodetach ttyUSB0 # 115200 460800 debug noauth defaultroute usepeerdns user mobile@jamamobile # show-password crtscts lock connect '/usr/sbin/chat -v -t3 -f /etc/chatscripts/t3g' # Possibly these pppoe options also should be included... # RFC 2516, paragraph 7 mandates that the following options MUST NOT be # requested and MUST be rejected if requested by the peer: # Address-and-Control-Field-Compression (ACFC) noaccomp # Asynchronous-Control-Character-Map (ACCM) # default-asyncmap # Do not try to negotiate other kinds of compression. nopcomp noccp novj nobsdcomp nodeflate nopredictor1 lcp-max-configure 90 /etc/chatscripts/t3gThis is a fairly standard set of modem configuration options, and then the phone number gets dialled at the end: '' 'AT' 'OK' 'ATE0V1&F&D2&C1&C2S0=0' 'OK' 'ATE0V1' 'OK' 'ATS7=90' 'OK' 'ATDT#777' /etc/ppp/pap-secretsWill need to have a line for the password, like this (it won't be the only line though): mobile@jamamobile * telecom If it still isn't workingIf you can't get it working from this point, then you probably have a different whatever-it-is than me, and I probably can't help you. Maybe it is device driver debugging that you need (/dev/ttyUSB0 is not created, perhaps) or maybe it is ppp debugging (if it is). Google Is Your Friend |
|