Some Early Impressions... and Kerberos

Now that I've had the DreamPlug for a few days, it's time to share some early impressions...

I wasn't really sure what to expect, usability-wise, so I can't say I'm overly disappointed or overly pleased. Some things worked out nicely, many things I'm still working on. It was easy to ssh in to the DreamPlug after I connected it, I just had to see what IP was assigned by the router. Getting Kerberos working, on the other hand, has not only not been easy, but I still have not managed to complete that task.

If I could jump back in time a couple weeks, I would definitely include the JTAG upgrade with my DreamPlug order, to save money compared to buying it separately. If I brick this machine I'll have to buy it anyway, and having it on hand would give me more confidence to experiment more boldly. Maybe if I buy another DreamPlug I'll add in the JTAG module, since I don't foresee any reason to have more than one. (Buying another is not currently planned, however.)

The user manual is extremely sparse. As mentioned before, this is a developer tool and you're supposed to either know what you're doing or be able to figure it out. "Figuring it out" for me typically involves Google, and luckily there are people documenting their experiences on the Web. Some of that info is really helpful (such as Marc Nozell who mentioned that the shell history file for root was still populated with all the stuff that was done on the machine before it shipped, and there are interesting clues in there). On the other hand, using Google to find "documentation" can be frustrating, because many often-informal resources don't include a date (tsk, tsk) and sometimes don't even the applicable version (tsk!), so I've been challenged to find good matches between online information and the system I'm actually working on. But I can't complain about something that's freely given, right?

When it first powers up, the DreamPlug is configured as an unprotected WiFi Access Point. Hooray, I'm giving my neighbors free Internet! Thankfully I live in a relatively rural area, but turning that off was still my first priority. I do not yet have WiFi client mode working yet but am putting that off for now, as it's not critical (although if I don't get that working, I can't move the DreamPlug downstairs to the entertainment system, which will abruptly truncate the shared-music use case).

It also powers up with Bluetooth enabled, including an obnoxiously-bright flashing blue LED. I have disabled the blue LED now, but I don't think I have Bluetooth turned off, which is something I'll figure out later. I don't have anything that uses Bluetooth so there's no point having it active. The obnoxiously-bright green LEDs are still as bright as ever, and I hope I can find a way to turn those down. Initial experiments seemed to have no effect (although I can turn the WiFi LEDs off and on). The WiFi LEDs are named "green" for AP and "red" for client, although both of them are actually green the "red" one is green and the "green" one is blue. Anyway, in the meantime, an old business card will suffice to block the light. (Edited to fix info about the colors; I'd turned off and left off the WiFi AP mode and forgot that the LED used for that was blue, not green.)

As I explained in my first post in this blog, I have quite a few gaps in my Linux and network administration knowledge, but I'm necessarily filling those gaps as fast as I can. Although it's only a side effect to working on configuring the DreamPlug, my Linksys wireless router now has an improved DD-WRT configuration. That, and learning more about how Linux (in general) and Debian (Squeeze, in specific, since that is what shipped on my DreamPlug) handle DNS were all part of my Kerberos work. Experiment. Struggle. You get the idea....

So what's up with Kerberos? I'm basically stuck. I've been trying to follow the Kerberos guide from Spinlock Solutions, with the intention of also using their OpenLDAP guide. Those guides include dates, mention applicable versions, and have easy-to-follow steps, so it seemed like a good resource for me and my lack of Kerberos and LDAP experience. Things went fairly well all the way through using kadmin.local to manipulate the Kerberos database. However, I have not been able to get into kadmin with the privileged user account that I created. I can use kinit to create a ticket, and I can use klist to see that, but when I try to use kadmin (not .local) I can see that it correctly validates the password but, after a significant pause, it finally gives me the following error message:

kadmin: GSS-API (or Kerberos) error while initializing kadmin interface

There are no messages added to any of the logs between the time I enter my password and the time the above message appears. I did end up going back to make some fixes in my DNS configuration, since that delay implied to me a network time-out, but those changes had no apparent impact on this situation. I also tried to skip ahead to the krb5-rsh example, but that also failed (although with a different message). I also tried destroying and rebuilding the database a couple times, along with many attempted tweaks to the /etc/krb5.conf file, most of which had no visible impact (and those with visible impact were clearly wrong so I undid them).

So, as I said, I'm basically stuck. I'm now deciding whether to continue pursuing this goal, or for now just skip using Kerberos (and maybe LDAP) and just get the Samba server running. I don't want to do that, but we also need to have this drive accessible to everyone, and it's been offline too long already. Decisions, decisions....