Linux: July 2006 Archives

Heard of the windows boot loader at all? If you haven't, it's called NTLDR. It actually does a really good job of being a boot loader, too, but with on exception. It MUST reside on an NTFS partition that is the first partition on the first drive that the BIOS sees. No exceptions. Windows expects this also, and likewise, won't boot unless it's booted like that. This kinda sucks for people who want to dual-boot windows and linux, because you have to either repartition to install linux on the first drive, or live without it (gasp). You can't install linux on a second drive, and use any linux boot loader to boot windows on the first hard drive. It just doesn't work.
Solution? The MBR hack.

Windows is installed on /dev/hda1. Linux /boot on /dev/hdb1. For the hack, I recommend grub, though I haven't tried it with grub, only lilo. Why grub is recommend will become quickly apparent.

With the above situation, there is no way to boot windows up from linux. Likewise, if you swap hda with hdb, windows still won't boot. So, once you have your linux boot loader installed on hdb, you image the MBR (master boot record) to a file, copy that file to the windows partition, and add an entry to C:\boot.ini to reference it. Let me put it in a little more verbose way:

dd if=/dev/hdb of=linux.mbr bs=512 count=1

cp linux.mbr /mnt/windows

echo C:\linux.mbr="Linux" >> /mnt/windows/boot.ini

And you're done. When the computer boots up NTLDR, you'll have a "Linux" option that'll pop up grub/lilo/whatever :)

And in case you didn't catch why grub is recommended: if you use lilo, you have to update the linux.mbr file every time you upgrade your kernel... which is typically stored on NTFS. Sure, the file size won't change, but it's another manual step that could be avoided easily with grub.

On another topic, I visited the University of Utah friday, for orientation (which they actually mis-scheduled me for, so I'll go again later). After 30 seconds of poking around, their network allows anything outgoing :53/udp to anywhere in the world. Oops.

/dev/md/0:
Version : 00.90.03
Creation Time : Tue Jul 11 10:31:15 2006
Raid Level : raid5
Array Size : 1172133888 (1117.83 GiB 1200.27 GB)
Device Size : 390711296 (372.61 GiB 400.09 GB)
Raid Devices : 4
Update Time : Wed Jul 12 18:28:40 2006
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Filesystem Size Used Avail Use% Mounted on
/dev/md/0 1.1T 33M 1.1T 1% /data

Now to actually put this to use. :)

gnucash 2.0 was released today. New features? GTK 2, instead of GTK1, which is huge. The second feature worth mention (for me at least) is OFX data transfer. This is the same thing that Quicken uses to sync it's data with some banks.

It turns out that Zions Bank (my bank), uses OFX, which is a plus. I can sync all data with my bank, which is nice. But, there's one small problem.

I have no clue how to setup my bank accounts.

Help. Haha, yeah, I suck. FID, Org, Broker Id, and Server URL anyone? I might be helplessly lost here. A call to Zions revealed little: "The URL changes every time you access it." I'm pretty sure that guy was confused, else Quicken wouldn't work.

Ideas, anyone?

You know what DNS is. It might be the glue of the internet. Commonly using 53/udp, and when needed, 53/tcp, this service is the most used across the entire internet. Likewise, security on this service is somewhat... lax. I don't mean in terms of who can talk to a server, I mean something a little more... subtle.

Some months ago, a friend and I went down to UVSC for a TSA competition. It was over their spring break, so no students were there. He brought his gentoo laptop, plugged into an ethernet jack, and fired up a browser.

Only to be greeted with a login page.

Thus, the quest to get internet on said laptop ensued. After asking UVSC staff, they said that we needed to get the laptop scanned for viruses before such a login would be granted. That alone gave us a few laughs ("I'd like to see them install SpyBot on linux!"), but in the end, that department was closed. Likewise, after asking around a bit more, we found that no username and password would be provided. We'd have to enroll and be a student in order to get internet, as depressing as that is.

That wasn't what we had in mind, so we plugged in and began poking.

Outbound ICMP, blocked. Outbound TCP... redirected to a HTTP login page. Proxy? Also redirected. UDP? Blocked.

So we reconfigured the DNS server to a remote one. The DNS request went on through, even though we were met with the login page still.

OpenVPN + SSL cert over 53/udp to a remote host in Texas connected to a 100mbit line.

I'd love to see a statistical breakdown of internet traffic that day. It's not often that DNS traffic will be over a few megabytes of traffic a day, let alone 3MB/sec of traffic for several minutes on end. The end result of this can be seen here. It was a fun experience.

So why do I bring this up now? Because I'm stuck at a family reunion right now, up at Cherry Hill, with a wifi access point that wants $7 for a day.

I love DNS.

EDIT: Apologies for the mass of edits, this post was written on my Zaurus keyboard while at Cherry Hill. This post might have been filled with typos, and still probably is.