/dev/urandom

So I've spent a little bit of time over the past few days trying to get audio working on my workstation at home. For those of you interested, here's some spec's on the system:

-Intel Workstation Bord (Don't recall the model number and don't want to look it up)
-Dual Quad Core Xeon Processors 2.0Ghz each
-2Gb of RAM (Soon to be 8Gb)
-Sound is on-board

That's the really important information at this point, so on with the show. I realized that for some reason, my applications were not doing 'simultaneous' audio. Now this system is pretty powerful, so I have it doing a lot. It's my main workstation, it also runs my MythTV front-end, it has a Windows XP Virtual machine in it, and is my main development platform. Soon it will a lso be running about 5 or so small Virtual Machines for a 'cluster' test that I will be running. But I digress.

So I started poking around the Alsa (http://www.alsa-project.org/) documentation. Come to find out, most on-board sound cards do not do hardware mixing. No surprise there. But, according to Alsa's own docs there is a neat Software Mixer built in called Dmix. Again, no real surprise. However, Alsa says that "For ALSA 1.0.9rc2 and higher you don't need to setup dmix. Dmix is enabled as default for soundcards which don't support hw mixing." (http://alsa.opensrc.org/DmixPlugin). Now this has me intrigued because if it is enabled by default, it sure is not working right.

So after some serious poking around the great Internet, I found some vague steps to enable this and get it working. It required installation of the 'alsa-oss' package, which appears to be non-existant for CentOS5. Bummer. Download the source for it though (ftp://ftp.alsa-project.org/pub/oss-lib/alsa-oss-1.0.14.tar.bz2 for CentOS5) and compile it. Now, there's a trick to this. Especially if you are running on a 64-bit (x86_64) system. You need to compile it TWICE.

First compile, do the following:


# ./configure --prefix=/usr --libdir=/usr/lib64
# make
# make install

Then compile the following way:

# make clean
# export CFLAGS="-m32"
# ./configure --prefix=/usr --libdir=/usr/lib
# make
# make install

Then after all that is said and done, make sure you run

# ldconfig

But you're not done yet. Open up /usr/bin/aoss and edit it to look like this:

#!/bin/sh

# A simple script to facilitate the use of the OSS compatibility library.
# Usage:
#       aoss  

if [ -d /proc/asound ]; then
  prefix=/usr
  exec_prefix=${prefix}
  LD_PRELOAD=libaoss.so${LD_PRELOAD:+:$LD_PRELOAD} exec "$@"
else
  exec "$@"
fi
exit 1

Changing the script to the above code will make it automagically find libaoss.so for the arch that the currently running binary is. THIS IS NOT DOCUMENTED ANYWHERE I COULD FIND. This is the stumbling block that I finally over came this evening. So I decided to share my information with the rest of the world in hopes that it will help.

After that is all said and done, create the file ~/.asoundrc and put in it the following:

ctl.mixer0 {
    type hw
    card 0
}

# I also had to add/alter the following, making ALSA use dmix by default
pcm.!default {
    type plug
    slave.pcm "dmix"
}

This may break mixer functionality, I haven't played with that part of it yet, but it does work. Even for the old OSS stuff, which is what the stuff above with the alsa-oss stuff, mainly deals with.

Enjoy

Sorry for the long delay in posting, but work has been kind of busy. Who knew that summer was the busy time for System Administrators that work at major colleges? Anyway, on with the show.

So for quite sometime now, I've had this little machine running in the corner that just sits there. I don't really log into it at all for large streches of time. And it probably has the most wires running into it of any of my computers currently running in my apartment. What is it you ask? Some sort of encryption cracking mega-rig? Perhaps a machine that just sits there automatically repackaging RPMS for Legacy SPARC machines that can't run Linux anyway? No it's sadly none of these. It's my MythTV (http://www.mythtv.org) box.

Now for those of you who don't click links in blogs until your done reading them (like me) then allow me to elaborate. You are all aware of such things as Tivo (http://www.tivo.com) and the DVR (http://en.wikipedia.org/wiki/Digital_video_recorder) options that your cable or satallite providers have. Well, MythTV is something very similar. Using a Linux based computer, a TV capture card, and a yearly subscription to a free TV Listing site, you can have your very own, homebrewed DVR. But MythTV doesn't stop there.

I started writing this post a while ago, but got side tracked by work. Since then I have expanded my MythTV setup. It now has a few of the MythTV plugins. Most notably are the MythGame plugin that allows you to interface with old game system emulators you might have installed. Also, I have installed the MythDVD plugin that will allow me to watch DVD's as well as archive them to a video library for easier playback.

MythTV has a slew of other options and features in it, most of which I have yet to play with to their fullest extent. Every so often I find myself tinkering with some other section of the Setup for MythTV and find out that I can do this, that or the other thing. I swear everytime I go tinkering it's almost like christmas. But if you have a slightly older machine laying around, and would like to play with MythTV, I'd suggest to give it a whirl. One thing that you should take note of, however, is this nasty Digital TV switch-over thing that is happening in Feburary. Some cable companies, like Comcast, are using this as a disguise to do away with a great deal of their old analog channels. MythTV cannot handle encrypted digital TV signals. Also, I have yet to find a good listing site that lists the contents of digital channels either. There seems to be no standard for how digital channels are numbered, and the fact that channel number can have sub-channel numbers further complicates the matter. This whole DTV switchover should be a very interesting C.F. but I digress.

What follows is a re-post of a blog post that was here: http://www.matasano.com/log/1103/reliable-dns-forgery-in-2008-kaminskys-discovery/

The thing that annoys me the most about this, is that everyone behind the discovery of this exploit has been all 'hush-hush' about it, not really saying what it was that was so bloody important that it needed to be patched. Kaminsky was scheduled to announce the whole thing at the Blackhat conference, which is my personal opinion of why this was kept quiet. If indeed that is the reason, there is nothing that upsets me more than a sell out. The patch for the exploit has been available for a few weeks now, so I am not hesitant in posting this. If you haven't patched your servers by now, that's your fault.

As far as I am concerned, there was no need to make this as hush-hush as it has been.

0.
The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.

1.
Pretend for the moment that you know only the basic function of DNS — that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.

Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob’s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice — once when he is called to the counter to place his order and again when he’s called back to get his sandwich. If you’re wondering, Bob likes ham on rye with no onions.

If you’ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It’s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.

2.
Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.

First, QIDs.

Bob’s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.

It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I’m Mallory and I’m attacking Bob, how can he distinguish my packets from Alice’s? Because I can’t see the QID in his request, and the QID in my response won’t match. The QID is the only thing protecting the DNS from Mallory (me).

QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here’s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded —- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory’s response gets to your computer before the legitimate response arrives from your ISP’s name server, you will be redirected where Mallory tells you you’re going.

Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob’s request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.

But there’s a bunch more problems here:

If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.

If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she’ll break the RNG and be able to predict its outputs.

16 bits just isn’t big enough to provide real security at the traffic rates we deal with in 2008.

Your computer’s resolver is probably a stub. Which means it won’t really save the response. You don’t want it to. The stub asks a real DNS server, probably run by your ISP. That server doesn’t know everything. It can’t, and shouldn’t, because the whole idea of DNS is to compensate for the organic and shifting nature of internet naming and addressing. Frequently, that server has to go ask another, and so on. The cool kids call this “recursion”.

Responses carry another value, too, called a time to live (TTL). This number tells your name server how long to cache the answer. Why? Because they deal with zillions of queries. Whoever wins the race between Alice and Mallory, their answer gets cached. All subsequent responses will be dropped. All future requests for that same data, within the TTL, come from that answer. This is good for whoever wins the race. If Alice wins, it means Mallory can’t poison the cache for that name. If Mallory wins, the next 10,000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0.

3.
Then there’s that other set of DNS vulnerabilities. These require you to pay attention in class. They haven’t really been talked about since 1997. And they’re hard to find, because you have to understand how DNS works. In other words, you have to be completely crazy. Lazlo Hollyfeld crazy. I’m speaking of course of RRset poisoning.

DNS has a complicated architecture. Not only that, but not all name servers run the same code. So not all of them implement DNS in exactly the same way. And not only that, but not all name servers are configured properly.

I just described a QID attack that poisons the name server’s cache. This attack requires speed, agility and luck, because if the “real” answer happens to arrive before your spoofed one, you’re locked out. Fortunately for those of you that have a time machine, some versions of DNS provide you with another way to poison the name server’s cache anyway. To explain it, I will have to explain more about the format of a DNS packet.

DNS packets are variable in length and consist of a header, some flags and resource records (RRs). RRs are where the goods ride around. There are up to three sets of RRs in a DNS packet, along with the original query. These are:

Answer RR’s, which contain the answer to whatever question you asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4)

Authority RR’s, which tell resolvers which name servers to refer to to get the complete answer for a question

Additional RR’s, sometimes called “glue”, which contain any additional information needed to make the response effective.

A word about the Additional RR’s. Think about an NS record, like the one that COM’s name server uses to tell us that, to find out where WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. That’s good to know, but it’s not going to help you unless you know where to find NS1.VICTIM.COM. Names are not addresses. This is a chicken and egg problem. The answer is, you provide both the NS record pointing VICTIM.COM to NS1.VICTIM.COM, and the A record pointing NS1.VICTIM.COM to 1.2.3.1.

Now, let’s party like it’s 1995.

Download the source code for a DNS implementation and hack it up such that every time it sends out a response, it also sends out a little bit of evil — an extra Additional RR with bad information. Then let’s set up an evil server with it, and register it as EVIL.COM. Now get a bunch of web pages up with IMG tags pointing to names hosted at that server.

Bob innocently loads up a page with the malicious tags which coerces his browser resolve that name. Bob asks Alice to resolve that name. Here comes recursion: eventually the query arrives at our evil server. Which sends back a response with an unexpected (evil) Additional RR.

If Alice’s cache honors the unexpected record, it’s 1995 —- buy CSCO! —- and you just poisoned their cache. Worse, it will replace the “real” data already in the cache with the fake data. You asked where WWW.EVIL.COM was (or rather, the image tags did). But Alice also “found out” where WWW.VICTIM.COM was: 6.6.6.0. Every resolver that points to that name server will now gladly forward you to the website of the beast.

4.
It’s not 1995. It’s 2008. There are fixes for the attacks I have described.

Fix 1:
The QID race is fixed with random IDs, and by using a strong random number generator and being careful with the state you keep for queries. 16 bit query IDs are still too short, which fills us with dread. There are hacks to get around this. For instance, DJBDNS randomizes the source port on requests as well, and thus won’t honor responses unless they come from someone who guesses the ~16 bit source port. This brings us close to 32 bits, which is much harder to guess.

Fix 2:
The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if they’re asking where WWW.VICTIM.COM is, they’re not interested in caching a new address for WWW.GOOGLE.COM in the same transaction.

Remember how these fixes work. They’re very important.

And so we arrive at the present day.

5.
Let’s try again to convince Bob that WWW.VICTIM.COM is 6.6.6.0.

This time though, instead of getting Bob to look up WWW.VICTIM.COM and then beating Alice in the race, or getting Bob to look up WWW.EVIL.COM and slipping strychnine into his ham sandwich, we’re going to be clever (sneaky).

Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Alice’s answer is NXDOMAIN, because there’s no such name as AAAAA.VICTIM.COM. Mallory has an answer. We’ll come back to it. Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM.

Alice’s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0!

Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didn’t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query. Mallory has combined attack #1 with attack #2, defeating fix #1 and fix #2. Mallory can conduct this attack in less than 10 seconds on a fast Internet link.

So it's been a while since I've posted something, and this post will, unfortunately, most likely turn out to be a rant. I have another subject I'm working on posting, but I just had some interesting communication with a Comcast (http://www.comcast.com) representative on the phone this morning. So I felt a need to disseminate this information to the masses.

One of the more interesting parts of my home entertainment system is my MythTV (http://www.mythtv.org) set up. I have a splitter on my incoming cable line that lets me hook cable up to my Cable Ready Tuner card in my MythTV PC. Because it's cable ready, I do not need a Comcast Tuner box to get the channels right? Well, mostly right...

Over the past few months, I have seen a handful of channels from my basic programming 'disappear' from my MythTV machine. These channels were still viewable from my Comcast Tuner box. I keep the tuner box around in case there are 2 shows on at the same time that I want to watch. That way I can record one with Myth and watch the other on the tuner. Well I found out this morning that a friend of mine was also seeing 'disappearing' channels, so I gave Comcast a call.

My initial theory was that the switch to DTV happening in February had something to do with what I was seeing. And as my conversation with the Comcast rep. started, my suspicions seemed to be true. But then, I started to dig deeper and found out from the Comcast rep. that there is actually 2 things going on here. The first one is that yes, there is a DTV switch over that is happening in February. And that it ONLY effects people who get over the air broadcasts. The second thing that is happening, which just happens to coincide with this 2009 switch over, is that Comcast is moving a good deal of it's lower analog channels into the digital spectrum. Now according to the Comcast rep. in order to see these channels, I would need to pay for another cable box to hook up to my second TV. WHAT?!

One of the major appeals of Cable TV was that I could take the coaxial cable from the wall, split it to a Cable Ready TV or Tuner and be able to see most of the channels in my Basic programming package. This is the entire reason I built a MythTV box. Because i could have a way to record any show on the basic programming package without having to have a second Comcast branded box. From the sounds of things, Comcast, in it's infinite wisdom of ridiculous marketing decisions, has decided that this is not something most customers find appealing. They believe this so much so that they are willing to yank channels out from under their customers with no prior notification. That just seems like poor customer service to me.

I moved down to Baltimore back in October. And perhaps I was spoiled by Time Warner Cable(http://www.timewarnercable.com/) when I was living up in NY, but in my experience with that company, they never would have done this. They always notified their customers of stuff like this. They would have also had it planned out and not just done things on a whim. Now the 'on a whim' part might have just been from the rep. I was talking to, but still, notification of a change like this would have been nice.

The short of it is, if Comcast is going to start requiring me to have a tuner box on every TV in my house, what is left to differentiate them from Satellite or FiOS? Nothing really. Which means, I'll probably wind up switching to who ever is going to provide me with the lowest cost. Then again, stupidity like this may very well be the straw that finally breaks the camel's back and makes me just completely cancel my subscription to any such services and go back to watching TV from over the air broadcast stuff. A one time charge for a digital antenna is starting to look much more cost effective. Especially if the only alternative is to give my money to an uncaring company like Comcast who doesn't view they current customers as valuable in any way. And the part that really gets me that this whole 'channel switching' that Comcast is doing just happens to coincide with the DTV switch over. And if you weren't a customer like me that likes to be informed and will dig for answers, then you would just accept that it's something having to do with this DTV thing, which you barely understand, and happily shell out the extra cash for multiple tuner boxes.

I have one thing to say to you Comcast, if you are indeed listening. Dirty Pool old man, dirty pool...

--
/dev/urandom

Ok, so I realize this may not really fit into the "System Administration" heading under which I created this journal, but everyone's allowed a little digression from time to time right? Anyway, I've had this problem for some time now with my iTunes ( http://www.apple.com/itunes/ ) Library. Random songs, seemingly ones I don't play that often, just seem to disappear from my hard drive. Today, I got it in my head to do some random searching on the problem to see if anyone else out there in the Internet was having similar issues. Well, I found a lot of people.

One post in particular caught my attention. (http://maba.wordpress.com/2006/09/19/itunes-7-might-delete-your-files-silently) This post was started back on September 19, 2006, nearly 2 years ago. And the comments in the post run straight up to present day with people complaining that they have the exact same issue. (Yes, I posted a comment on there as JJ today.)

Now, as for myself, I personally have noticed that the problem only occurs with songs that I have not purchased from the iTunes Store. Then, after thinking about that, the 'conspiracy theorist' part of me kicked in. What if it's not a bug. What if Apple purposefully put something into iTunes 7 to randomly, and as secretively as Apple developers know how, delete songs that you did not purchase through iTunes.

I know, it sounds really off the wall, but bear with me for a moment or two more as I extrapolate the thought out. Say your Apple and you have this iTunes Store thing that you want to improve purchases on. Now say you have iTunes, which is very tightly integrated with iTunes Store and the user's Music Library. Now say the user had this song in MP3 form that they didn't buy from you, and you go and delete it quietly. The user realizes the song is gone and chalks it up to a disk problem. Now, being the wonderful software designers that you are, you've given them an easy link to the iTunes Store where they can go and purchase the song and get a new copy of it. If Apple did do this on purpose, it is a horribly devious, but brilliant idea. I personally think it's appalling to mess with user's data like that. But if I were a heartless business person only concerned with the bottom line, I might think it was a good idea.

Now, you may not believe me, and at first I didn't believe me either. But then I got to thinking. Have you ever installed iTunes on a Windows machine recently from a fresh Windows install? Have you ever had that software updater thing pop up saying you had to update Safari for Windows, but you don't even have Safari installed? Kinda makes you wonder about the software and marketing people at Apple doesn't it?

So it's been a while and I've been thinking to myself, what can I blog about. Well recently my personal/project site TULG (http://www.tulg.org) needed a new home. A friend of mine suggested Linode (http://www.linode.com) as a point of consideration. I checked it out and sure enough, $19.95 per month got me a tiny little Virtual Machine to call my very own. Now I don't need much to run TULG, just a place for DNS, a few project websites, and email. So I signed up, and after a while my account was activated.

The web based console is very nice. It lets you allocate disk space from your quota to your "Linodes" as they call them. Then it formats everything and blows on a disk image of several flavors of Linux ranging from CentOS (http://www.centos.org) to Fedora (http://www.fedoraproject.org) and even Gentoo (http://www.gentoo.org) for the Uber Elitist. It only takes a matter of minutes for it to get everything up and running for you and you have your very own Linux server. You can SSH to it, set up firewall rules, install packages, have root access, everything you could do with any sort of Linux machine. They even have a watch dog program that will attempt to reboot your Linode if something goes terribly wrong with it.

All in all, I am mildly impressed with it. I would highly suggest it to anyone that is looking to for their own small piece of the Internet. Or for someone who just wants to mess with various Linux distributions and is willing to pay a small fee to do so on someone else's hardware.

So here comes my next geekish rambling about a piece of software. Dovecot (http://www.dovecot.org) is a smart little mail program. Dovecot's biggest claim to fame is it's IMAP and POP capabilities, which it does quite well. Shortly after I started my current job, one of my tasks was to create a new IMAP server to move users off the old uw-imap server that was running on a very old Sun machine. I chose to go with dovecot because I had some experience with it before.

The crux of the set up at my current employer is that the home directories and the /var/spool/mail directory are on 2 old Sun Ultra 10 machines running Solaris 2.8. These 2 directories were NFS mounted by this test IMAP machine. Predecessors to me, had experimented with this set up and found that when users used the test IMAP machine to obtain mail, the Old Sun running the home directories had a tendency to 'disappear' off the network. Come to find out, what was going on was the NFS traffic from the Linux IMAP server was flooding the Old Sun so much that the machine couldn't keep up with ANY network traffic. After some NFS tuning on both sides, that issue was solved and the test machine started it's Alpha Testing phase.

After which I was doing some reading on dovecot and found out about it's index file setup. Now this is what makes this software so interesting. The first time you access a folder in dovecot, it indexes the folder into a quickly readable index file. Subsequent connections and reads to said folder are then pulled from this smaller, more easy to read, index file, thus providing the user with a much snappier experience, especially when mbox files are used as the mail storage backend. After further reading, I found out that these index files could be hosted on local storage while the mail folders still resided in home directories via NFS as well as an inbox in /var/spool/mail, also over NFS. I set up my test instance for this configuration, restarted dovecot and noticed a marked improvement in the performance of my IMAP transactions.

Now, getting to the story that prompted me to write this entry. I recently started working on a test implementation for another group within my employer. The other group had a slightly beefier setup for me to implement dovecot on, but still keeping the folders within an NFS mounted home directory. Now, with this second test server I set up, I was able to play a bit more and do some more extensive testing than before. Mostly due to the fact that the previous test implementation was a bit more rushed to get test users using it than this second instance.

Anyway, the testing I did was checking out how long it took dovecot to index various sized folder files, how long it would take to re-download the message headers, what happens when the spool is modified outside of dovecot, and such. Come to find out that no matter what we did, it was pretty snappy. It only started to slow up when we hit large sized mail folders, over a couple hundred megs. I actually did some testing on a 1.1Gb mail folder via NFS. Indexing took about 2 or 3 minutes. Downloading the headers took about 15 seconds. And if you modified the file outside of dovecot, it would realize the changes and update the indexes pretty quick.

All in all, I was very impressed that no matter what I threw at it, the server didn't choke. The locking was done on the index files so that anyone coming in through IMAP had proper locking. Dovecot also has an LDA functionality in it, that I haven't explored yet. This allows MTA's like sendmail to use dovecot to deliver mail to mail spools as well, keeping the indexes up to date without having to do a full refresh of them if ever needed.

So 2 in one day, but I feel this is worth mentioning. For a while now, at work, I have been using a program called NX by a company called NoMachine(http://www.nomachine.com/). It's awfully handy. Installed on a Linux Server, you can use a Linux/Windows/Mac/Solaris client to connect to said Linux Server via an SSH connection and get a full Linux Desktop in a window. It's very similar, in look and feel, to what you get from something like vmplayer (http://www.vmware.com/products/player/) but it's not a virtual machine. It's actually an X desktop on a real machine somewhere else.

The authentication that the client does to the server is somewhat tricky and I feel a need to digress into it for a moment. The client comes installed with a default SSH key. When the server is installed, this default SSH key is used for the NX user that gets added to the system at install time. Since every NX client comes shipped with this key by default, I recommend regenerating the SSH key on the server for NX. (There are details about how to do this on NoMachine's website, or ask me and I'll post directions.) After which, every client that attempts to connect to the server will need to import the public part of said key.

But after the SSH connection to the server is made via the nx user and it's key, it then authenticates the 'real' user you are trying to login as, switches over to that user, and spawns the actual X session.

The even better part about this piece of software is that if you disconnect the session, the X session will continue to run even without a client connected. So the next time you connect the NX client to the server, you can resume the session you were previously running. This works very well if you would like to keep an eye on your work computer from home. I can equate its usage to Windows RDC.

In short, check it out if you are a Linux Server admin and have some time to play with things.

So I have been playing around with an ISC DHCP server and a Macintosh G4 eMac (no that is not a typo, it's labeled eMac and I will take a picture to prove it if necessary). Here's a bit of background on the whole situation:

I have been investigating a way of doing web based 'registration' of computers requesting DHCP addresses. Now, I know it's probably not the best solution, let alone the most secure, but I found this program called NetReg (http://netreg.sourceforge.net/) that I have been tooling around with lately. I installed it on a CentOS 5 machine. So my ISC DHCP was stock out of the box as well as a few other things that will come into play a bit later on in this post.

Anyway, after I got NetReg installed, I attempted to get my other Linux machines (Mostly CentOS or Fedora) working with it, which happened no problem. Then I went on to the Windows XP machine. Again, no problem. Then came the Macintosh OS 10.4 machine. (dun dun dun....)

I switch the Mac over to my test network, set it up for DHCP and hit apply thinking it'll work just as nicely. No such luck. It doesn't grab an IP at all from the DHCP server. Now I am a bit confused. So I run tcpdump (http://www.tcpdump.org/tcpdump_man.html) on both the Linux DHCP server and the Mac. I can see the Mac sending it's DHCPDISCOVER packet. I can see the Linux machine sending the DHCPOFFER packet. I can even see the Mac receiving the DHCPOFFER packet. But it seems as though the Mac just throws the packet away, ignoring it all together.

Perplexed by this seemingly odd problem, I begin to scour the Internet to try to see if any one else has had this particular problem. I find maybe 2 references to it on the ISC DHCP Mailing Lists. (http://www.isc.org/index.pl?/ops/lists/) But no response, and thus no mention of a fix.

So I get into work this morning and decide to install Wireshark. (http://www.wireshark.org/) Some of you may know this program better under it's old name, ethereal. I first ran it on the Macintosh. I checked out the DHCPOFFER packet and the first thing that stood out to me was the 'server-identifier' field of the DHCPOFFER packet. For those of you who are into the hardcore nitty-gritty of information, it appears the server-identifier field of the DHCPOFFER packet is DHCP Option Type 54.

Anyway, the server-identifier field in the DHCPOFFER packet was set to 127.0.0.1. I decided this seemed plausible enough as a problem so I pursued it. I went into the /etc/dhcpd.conf file and sure enough, there is a server-identifier field that I had set up as 'dhcp.server.name.tld.' Checking /etc/hosts on the DHCP server reveals that, as normal with CentOS installs, dhcp.server.name.tld was set to 127.0.0.1 in the /etc/hosts file. So I went back into the dhcpd.conf file, changed the server-identifier field to be the IP of the DHCP server, and retried my Macintosh's DHCP Discovery. Sure enough, that was what the problem was, because the Mac decided it liked the new DHCPOFFER packet, took the address and started merrily communicating with all the network hosts.

So it appears the summary of this story is that Macintosh DHCP will attempt to do some rudimentary validations on DHCPOFFER requests that they get. Linux and Windows DHCP clients seem to totally ignore the server-identifier field. So the moral of this story is, make sure you always set your server-identifier field in your dhcpd.conf file on your ISC DHCP server. Otherwise, your happy Mac users won't be so happy when they don't get a DHCP IP address.

Welcome to my new journal. DevUrandom is a journal/blog/whatever that I am goinng to keep of odd little computer related tidbits of information that I find floating across the web or through my own experiences as a Systems Administrator. As a result, I am going to keep this journal open to the public, which will be very different from my previous online blogs. Also as a result, you can probably expect that this jounal may not be updated very frequently. Just thought I would let you know ahead of time. I also plan to not use any lj-cut tags. So if you add me to your friends list, you might just wind up with a very long post, explaining some very odd computer problem, clogging up your friends list.

So that's it, feel free to add me if you like. No guarantees of a return add to my friends list, because I am probably not going to monitor it anyway.

Have a good one, and remember:

"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway" - Andrew S.Tanenbaum