MavEtJu's Distorted View of the World - 2008-07
Internode to support IPv6 tunneling (and more)
Motorcycle lessons When things you wrong, you want useful error messages Moving on from BarNet, to... Migrating from i386 to amd64 - ldd(1) on 32 bit objects CVSROOT-ports/modules re-animated Back to index Internode to support IPv6 tunneling (and more)Posted on 2008-07-21 09:00:00 At About Internode and IPv6, Internode announces that their internal network is supporting IPv6, and that they have IPv6 connectivity to the rest of the IPv6 world. If you want to use their Tunnel Broker service on FreeBSD (i.e. have an IPv6-over-IPv4 tunnel towards their IPv6 gateway), then use the net/freenet6 port. Make sure you are using version 5.1_x. The required configuration changes in /usr/local/etc/gw6c.conf are: userid=edwing passwd=foobar server=sixgw.internode.on.net auth_method=any Besides being a tunnel broker they also support a native IPv6 connection if you have an ethernet- or fibre link with them. No comments | Share on Facebook | Share on Twitter Motorcycle lessonsPosted on 2008-07-14 09:00:00 Last weekend I had my first introduction in the art of motorcycle riding. I didn't end up in the hospital, but I am a little more worried about the teaching of the skills for traveling in a motorized vehicle on the road in Australia. In other words: cars and bikes. This introduction taught us how to setup a bike (as in from the stand to the ready position), how to figure out what is happening around you, how to start it (vroom!), how to stop it (very tricky for a cyclist like me), how to get it moving (I don't like clutch riding...), how to take corners properly (look where you are going) and how to make sure you don't end up in dangerous or worse situations. At the end I got my piece of paper showing that I know all the things above and that I know how to execute them properly. Next.. Will I buy a motorcycle? I don't think so yet. Why? There are a couple of reasons: During the practise lessons we only drove in a nicely controlled environment. We didn't get higher than second gear, we didn't go faster than 20-25 kilometers per hour. I have absolutely no idea how it is riding in the real world where I go at 50 kilometers per hour (on normal busy Sydney roads), let alone 80 kilometers per hour (on the fast busy Sydney roads) where cars, roadrage and stupid people in cars are ever present. We used the indicators only once at the last practise and of course half of us screwed this up. We only practised for six hours (two days with two times 1.5 hour blocks). Not many people know how long it took before my car-driving teacher allowed me to take the exam, but it was waaaaaaay above the average amount of hours (but less than 54 lessons :-). On the other hand, he never had to interfere with the wheel or the brakes! So to expect me to be comfortable on the seat after six hours is a little bit optimistic. The other thing is that I am a very bad pupil but have a very good engineering mindset: I learn from my mistakes, and that's how I become good at it. Being told that I do something wrong doesn't hurt me, it helps me. Riding at some high speed and making a mistake is costly, and I won't be able to learn from it. So... What's next? Not much I think. Michael and Stuart Lemon from Ride it right were great, the experience was great and I loved it. But I'm going to wait and try it again when I live in a city where the traffic isn't as mad as in Sydney. Canberra, I'm waiting for you! In the mean time I enjoy the backseat of Naomis bike :-) Show 2 comments | Share on Facebook | Share on Twitter When things you wrong, you want useful error messagesPosted on 2008-07-09 09:00:00 The time of output like this, after you do a release update: is over. I, for one, welcome our new warning message overlords:kldload: Unsupported file type Will be available in FreeBSD 6.4, 7.1 and higher.kldload: /boot/modules/test.ko: Unsupported file type No comments | Share on Facebook | Share on Twitter Moving on from BarNet, to...Posted on 2008-07-08 12:00:00 The rumours are true, it is official: I have quit my job at BarNet. For the last seven years I've worked in a couple of great projects, learned a lot more about networks, systems and people than I already knew. A couple of highlights and learned lessons:
Of course, I could bitch and moan about the bad things which have shown up in the last year but let's keep it positive. Now I'm in the handover phase... Which of course totally doesn't go as I had hoped for. We had two months time for it, in which we could do one month for handover, then two or three weeks for the last items which were missing or not clear or where the new people needed their hands to be held. But it was decided that it all should happen in the last two weeks... Next step? Nothing set in stone yet, just talking. Want to talk to me? Show 2 comments | Share on Facebook | Share on Twitter Migrating from i386 to amd64 - ldd(1) on 32 bit objectsPosted on 2008-07-04 09:00:00 In the last couple of months I have migrated left-over applications on old i386 servers running FreeBSD 4.something to jails on amd64 servers running FreeBSD 6.3. It works fine, it works like a charm, thanks to the 32 bit compatibility and the misc/compat4x port. I could just copy everything in /usr/local/ to the new jail, run ldconfig -32 /usr/local/lib and everything started without problems. There was only an issue with the ldd(1) command in the base-system: The man-page of rtld(1) revealed that it could work:[/] root@ed-exigent>ldd `which httpd` ldd: /usr/local/sbin/httpd: can't read program header ldd: /usr/local/sbin/httpd: not a dynamic executable So ldd(1) had to be educated about the differences in the ELF header for 32 bit and 64 bit ELF objects. Once that was done, no problem at all anymore![/] root@ed-exigent>LD_32_TRACE_LOADED_OBJECTS=1 `which httpd` libm.so.4 => /lib32//libm.so.4 (0x280c8000) libaprutil-1.so.2 => /usr/local/lib/libaprutil-1.so.2 (0x280de000) libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x280f2000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28110000) libapr-1.so.2 => /usr/local/lib/libapr-1.so.2 (0x281fd000) libcrypt.so.3 => /lib32//libcrypt.so.3 (0x2821d000) libpthread.so.2 => not found (0x0) libc.so.6 => /lib32//libc.so.6 (0x28235000) libpthread.so.2 => /usr/lib32/libpthread.so.2 (0x2830d000) Patches are available at bin/124906, have been commited to HEAD and will be MFCed in a week. No comments | Share on Facebook | Share on Twitter CVSROOT-ports/modules re-animatedPosted on 2008-07-03 10:40:00 When it comes to the FreeBSD Ports collection, the CVS repository and the GNATS bug tracking system, people not always understand how its can be made easier. For example: Did you know that the URL http://bugs.freebsd.org/12345 would bring you automatically to the PR with number 12345? And did you know that if you want to checkout the directory /ports/x11-wm/fvwm95, all you have to do it cvs co fvwm95 (For an easy Mozilla Firefox and Seamonkey (and probably other browsers) sidebar, visit this page) So, what is the story about that cvs co fvwm95. The magic for that is stored in the file CVSROOT-ports/modules, it contains a list of all ports and their directories. The file is updated every time a port gets commited, removed or changed from location. At least that is the theory. Adding is done manually via the addport script, but removing and changing locations has been always a manual task. Recently the caretaker of this file had enough of people whinching when he said they needed to update that file when it changed. So he said that support for it would cease. But but but... That would break at least one of my ways to do things easy! I can do only one thing now, take control over it myself! So I proposed it to portmgr@, who approved it. The second thing to make is a script which mangles /usr/ports/INDEX to generate a modules file (in the shape I like it). All that is done now, and the CVSROOT-ports/modules file is now updated once per day. See the CVS webinterface for the last update! No comments | Share on Facebook | Share on Twitter |