I haven't even finished reading it yet, and I can't link to it yet because it hasn't hit the archive, but Joerg's Bit's from the DAMs is priceless!
I haven't even finished reading it yet, and I can't link to it yet because it hasn't hit the archive, but Joerg's Bit's from the DAMs is priceless!
I have finished reading The Thread. It nearly killed me, but I avoided killing much of it so I could try and be as informed about it as possible. I don't think reading it across such a period of time helped me retain much though...
I don't think my opinion on the proposal has changed much. I'd still like to see Sparc make the grade, and I still think it can. If anything, this proposal has given all the ports a bit of a shake up. They can't just sit back and assume that their port will release with Etch, and that they need to keep their houses in order. (I'm sweating on udev to build on arm so can get the fix for #300435, peddle harder guys!)
I'll certainly be taking a more active interest in the Sparc port (other than just using it), and helping out where I can.
My favourite TV show is Rage, I tape about 5 hours of it every Saturday morning, and usually watch at least some of it during the course of the weekend.
I was sitting down watching a bit this afternoon, when I noticed two songs that were close to each other in the charts sounding very identical.
Falling Stars by the Sunset Strippers sounds virtually indistinguishable from Star2Fall by Cabin Crew. Different record companies. A bit of Googling turned up this bit of juicy gossip.
Now if they'd just use something original, there wouldn't be a problem...
Mikal just enlightened me on the wonders of ACPI suspend...
Here I was thinking I was going to have to totally reinstall my laptop because I hadn't made my swap partition big enough, and I was using LVM and was all out of partitions, and all I had to do was put a 3 in /proc/acpi/sleep! Sheesh...
A quick bit of extra hackery to acpid and now when I close the lid, my laptop takes a snooze. I'm so happy. I really need to read up on the ACPI thing...
I think GNU/Screen should get some sort of award for being a really cool piece of software. Or maybe it's Unix Ptys that should, but screen is what really exploits them...
The multiuser feature is something that I use rarely, but when I do, I really appreciate it. Today, I used it to help diagnose a co-worker's problems with building some software, from the comfort of my desk, without having to try and squeeze in next to him at his desk, and squint at his ridiculously small xterm font.
I've previously used it to train another sysadmin, so rather than two of us having to sit on each others laps in front of one computer, we could both sit at our own desks and talk to each other, while taking turns to drive the same shell.
This week has been fun. I've been reverse-engineering how a a Linux-based load balancing appliance works.
Up until version 4.5, they used to be BSD-based, but they went to a new hardware platform, and decided to double 4.5 and came up with v9, which incidentally, appears to be Red Hat 9 based.
We want to be able to customise the build process so that we spit out a site-specific-configured BIG-IP. No problem I think, I'll just build an RPM containing all of our config files in it. I'd previously pulled to bits the installation process, and it was quite trivial to just grab the ISO, unpack it, chuck an extra RPM on, add that RPM's filename to a file, and rebuild the ISO. Hey presto, my "Hello, World" proof of concept RPM was being installed on a BIG-IP.
So then I tried to go for gold, and built a preliminary config RPM, with our password file in it and whatnot. This is where I got too clever for myself and forgot one minor problem. Half the files I'm trying to install in my RPM belong to other RPMs already installed, so of course RPM bleats, and the package doesn't install. Bummer. I need to find out if I can declare that one RPM overwrites bits of another one, otherwise I'll really have to hack to the installer so that it can force a specific bunch of RPMs in.
<rant> It would help if I could find a canonical, current source of documentation for the RPM spec file and RPM building in general. Google is useless. You put "rpm" and "spec" together, and you start finding all sorts of random spec files for packages, which is not what I want. www.rpm.org is grossly out of date, and not terribly in-depth, and the chapter of the Fedora Developer's Guide is a joke. </rant>
I think Steve Langasek's wife has very nicely summed up Steve's proposal in her blog.
I'm still trying to wade through the 400+ emails that followed up the announcement, so I haven't been able to digest what the general vibe is, and I've only briefly lurked on IRC today (but I log #debian-devel, so if I really cared I could go back through it).
As I said yesterday, the new release strategy doesn't impact me in a negative manner terribly much. My pet non-x86 architecture that is affected is SPARC, and it's a pretty neglected pet at that.
One thing that I thought about today when I opened by debian-devel folder and was greeted by 400+ emails in one thread, was that if all the energy had been expended on fixing bugs, then we'd be able to freeze Sarge tomorrow...
I just learned yesterday, that the reason the assignment for COMP2100 is to be done in pairs is more because they can only afford to pay for marking of half as many assignments as there are students in COMP2100, than because they want to encourage us to be able to work in groups.
It's pretty tragic that the Department is so strapped for cash that they've had to cut back on the continuous assessment in this manner. They've also cut back the laboratory sessions this year by one half as well.
It's a bit of a fudge, the ANU jumping up and down about how they haven't raised fees, if students enrolled in COMP2100 this year are paying the same amount as students who were previously enrolled in COMP2100, and receiving a vastly inferior teaching experience. I think I'd rather pay more to maintain the same level of education.
The Stunning New Release StrategyTM sounds pretty good to me.
I think I'd like to see the SPARC architecture hang in there though.
Real men don't backup, they just use Google's cache.
Argh. I just got bitten by #265021 again. Thank $DEITY for Google's cache. I managed to repair the damage with about half an hour of reverse engineering the HTML output with a cached copy and vimdiff.
I vented my frustration by raising the severity of the bug.
Meanwhile, rather than just bitching and moaning about it, I'll put blosxom on hold and put some thought into how to handle it better.
I had an interesting discussion this afternoon at work regarding the pros and cons of permitting ICMP messages into the classified gateway environment that we manage.
The necessity came up because something has been changed with the WAN link between the site where I work and the site in Sydney, and the MTU is now something more like 1300.
We're faced with the choice of:
I have to admit that I hadn't heard about this until today. I had a read of the Phrack article in question, and it talks about doing it with ICMP Echo Request and Echo Reply packets, because these can readily have data added to the payload.
I'm interested in hearing about any exploitation of ICMP Destination Unreachable packets for such unintended purposes. I've raised this on the SAGE-AU mailing list, and the general consensus of responses so far is that blocking such ICMP messages is going to cause all sorts of breakage, and that if you're going to get paranoid about covert tunnelling over ICMP, you need to start worrying about IP over DNS and HTTPS proxying and a lot of physical security issues.
I agree completely. I'm all for Path MTU Discovery working as intended, unless someone can give me a good reason to the contrary. If I get time over the weekend, I'll have a bit of a play with Ethereal and something like sendip on my home LAN.
Just when you thought it was safe to push a firewall policy...
Today one of the Operations guys tried to push an updated policy to the enforcement module that I migrated recently and was greeted by some errors regarding "No valid FM license". (I still haven't figured out what FM stands for yet).
I've no idea why this happened out of the blue. I could certainly push a policy after I finished the migration. I restarted Firewall-1, and also received some "No valid FM licenses" during the initialisation messages.
I pulled up the SmartUpdate application, and detached the licenses associated with that node and reattached them (well I noticed that one of them was for an IP address that wasn't on that firewall so I left that detached) and did a cprestart, and everything came good. I gave it a reboot just to make sure it wasn't going to return to SNAFUness after a reboot, and it was still good.
I look forward to the next enforcement module migration with much fear and trepidation.
I finally managed to get my hands on a QFE card today.
These things pop up reasonably frequently on the Australian EBay, but they are always hotly contested, and the price usually ends up skyrocketing by the end of the auction. They're popular because Sun has effectively discontinued them in favour of the Quad GigaSwift Ethernet adapters. They're pricing a QFE at $US 1,795 compared to $US 895 for a GigaSwift. I heard this was to deter customers from buying the QFEs as Sun want to stockpile what they currently have to use as spare parts for customers on hardware maintenance contracts. At around $AUD 100 - $AUD 150 on EBay, arguably brand new, they're a huge bargain.
After losing the third auction for one, I got sick of stuffing around with the auction process, and bought one outright from EBay in the US for less than what they were going for in Australian dollars on the Australian EBay. Gotta be happy with that.
I think I only paid for it on Saturday, and it turned up in the mail today, which totally blew me away for $AUD 12 in shipping. I don't imagine I could send something in the opposite direction for that much...
I quickly chucked it in my desktop PC to make sure it actually worked before providing some feedback to the seller. Linux picked it up fine, but my other NIC seems to be playing up. It didn't get a DHCP lease. Audio also went a bit bonkers. I suspect I have a resource issue of some sort, or I managed to scratch the motherboard when I snapped off the blanking plate for the last PCI slot in the box. I'll deal with it later.
I want to start having a play bridging under Linux, and build a bridging firewall that is totally transparent. I also want to build an inline transparent Argus probe. All these require lots of interfaces, so having four on one card is perfect.
Now I just need to have the spare time (and additional hardware) to do this. Argh. I have too many projects going at once.
That's why I'm blogging at 11pm instead of Zzzing.
A the best of times, I have a 2 hour lecture at 1pm, for which finding a carpark seems to be a nighmare on a Wednesday (Monday at 3pm and Friday at 1pm is significantly easier). Then I dash back to work for a token hour or so of work, then I dash back to Uni again for a 1 hour tutorial at 5pm, which for the next four weeks, I have to leave a bit early so as to make it to Deakin to a Senior First Aid course at 6pm until 10pm.
But it's all good. The First Aid course is interesting. The four hours went fairly quickly tonight. I met Renee, who has just started doing a PhD at ANU and just moved here from overseas (she's French-Canadian, but I'm not sure if that's where she's most recently from) with her Australian husband (who has just started a lecturing job at the ANU). One of the reasons she was doing the course was to meet people, so I might invite her and her husband around for dinner when I see her next week.
When the hard drive in my VAIO died a few months ago, I figured it could still be put to use as a "server" of sorts with an NFS root filesystem. Yesterday, I spent some time trying to make that come about, with mixed success.
Because the VAIO PCG-F590 does not have an onboard Ethernet interface (what was Sony thinking?) I've had to rely on USB Ethernet adapters to get by, or a PCMCIA wireless card. As I wanted to use this laptop as the new under-bed Festival-powered weather-reading alarm clock (it has way better audio quality than my Ultra 5, which used to do the job), I didn't see the point in tying up a wireless card for something that was never going to move, so I went for the USB Ethernet adapter option.
I could have built a live CD, but the thought of constantly having to recreate and reburn a CD every time I forgot to install a package really didn't appeal to me, so the NFS root seemed much more practical. As the laptop was incapable of directly booting from a external Ethernet device, I created a bootable CD using the most excellent isolinux.
To get the kernel and initrd required for isolinux, I made a chroot (using debootstrap) on my NFS server. In this chroot, I added the initrd-netboot-tools package, which is part of the lessdisks suite of goodies, a project I'd never heard of until yesterday.
The beauty of using initrd-netboot-tools is I can still use a stock Debian kernel image, and with a bit of tweaking, the initrd does all the heavy lifting of acquiring a DHCP lease and mounting the NFS root. Very cool.
I had to do some slight hacking in the chroot that I was exporting so that the initrd was created correctly. The first problem I struck was there was a slight delay between loading the module for the USB Ethernet device and eth0 becoming available. I had to introduce a 2 second sleep before the DHCP request was made, otherwise it would declare that there was no Ethernet device, and not bother DHCPing at all. Here is an exact list of things I had to change in my chroot:
Once I'd done all of this, I installed a kernel-image package into the chroot (2.6.8-2 in my case) and then pilfered the vmlinuz and initrd.img for putting onto the CD.
The CD just had the kernel and initrd and isolinux.bin on it, ala:
. `-- boot |-- initrd.img |-- isolinux | |-- isolinux.bin | `-- isolinux.cfg `-- vmlinuz
The isolinux.cfg is really basic (I need to change it so that I can actually pass some parameters at boot time):
DEFAULT /boot/vmlinuz APPEND initrd=/boot/initrd.img rw root=/dev/nfs nfsroot=172.16.0.2:/export/laptop ip=dhcp hda=none nfs_opts=rw,sync,nolock
That's about it. Then I struck the problem with doing NFS over a USB Ethernet adapter, which I'm yet to resolve. I tested the whole process out on my current laptop (which has an onboard Ethernet) and it worked fine, so once I resolve the issues with NFS over a USB Ethernet adapter, I should have the VAIO working nicely as a diskless server under my bed reading the weather to me.
I received a suggestion from Uwe Klein via the Linux USB users mailing list to lower the rsize to 1000. This allowed the bootup to proceed slightly further, before it got bogged down again in a similiar manner. Andreas Metzler suggested I switch to NFS over TCP, which ended up being just the ticket, and laughably easy to do.
For the record, I also ended up adding /bin/hostname to the initrd_exe line of /etc/lessdisks/mkinitrd/initrd-netboot.conf and my final isolinux.cfg contained:
DEFAULT /boot/vmlinuz APPEND initrd=/boot/initrd.img rw root=/dev/nfs nfsroot=172.16.0.1:/usr/local/share/lazarus ip=dhcp hda=none nfs_opts=rw,tcp,sync,nolock,rsize=8192,wsize=8192 vga=0x317
The talking weatherman returns!
I don't normally regurgitate vulnerabilities already announced on Bugtraq, but when one is so blatantly self-deprecating it deserves a special mention:
This is a spectacular fuckup, it pretty much destroys what PaX has always stood and been trusted for. For this and other reasons, PaX will be terminated on 1st April, 2005, a fitting date... Brad Spengler offered to take it up but if you're interested in helping as well, contact pageexec at freemail hu
I've hacked changelogs.debian.net so that rather than redirecting to the relevant changelog on packages.debian.org, it essentially proxies the request (using curl) and does some substitution to make all bug references hyperlinks to the BTS, and all URLs normal hyperlinks.
I've asked Frank Lichtenheld if he can make the changelogs on packages.debian.org do this, so I'll revert back to the old behavior if and when this happens.