November 2009 Archives

Upgrading woes

Yesterday I upgraded my work desktop to openSUSE 11.2 from 11.0. I'd skipped 11.1 because upgrading (rather than reformat/reinstall) is always a lot of work. This proved to be no exception. Even though I was involved with the milestone builds for openSUSE, I didn't have the ability to test my guaranteed-to-have-problems desktop.

I had two problems:
  1. The XWindows hot-plug support for input devices just plain doesn't work on my system. This was introduced in 11.1, so that would have bit me then.
  2. VMWare Workstation just wouldn't compile the modules. The 11.2 kernel is too new.
I've managed to solve both problems. The first was solved by putting my old (backups are your friend!!) xorg.conf file into play and adding one line in the ServerFlags section to tell it to not bother auto-adding input devices. The second involved installing 6.5.3 instead of 6.5.2, and using a bit of crowbar-fu to make it fit. 6.5.2 just wouldn't work, where 6.5.3 required some special handling.

I don't know why the 'evdev' stuff in xorg is failing on me. It's on my list to figure out, but as I have a working config at the moment that's kind of low priority. But that needs fixing, since 11.3 will most assuredly reintroduce that fault.

VMWare.... reportedly version 7 works without a hitch. But I can't have that yet, so I had to get 6.5 in somehow. The crowbar I mentioned was killing certain processes the vmware installer spawns to compile the kernel modules it requires. Once those were ruthelessly murdered, the installer completed and it would work. Clearly, I have to be leery of kernel updates until I can use 7.

Other than some theme tweaks that I needed to redo, this was the cleanest upgrade I've had. All the Gnome stuff worked right out of the gate, which is a first. In the past I've had to blow away most of my Gnome configs and restart from scratch. I'm glad those bugs have been ironed out.

Two years ago I posted an article that has been fairly popular, Encryption and Key Demands. The phrase 'duress key' seems to drive the traffic there, even though I'm not the one who coined the term. Anyway, a real-life example of that has shown up.

UK jails schizophrenic for refusal to decrypt files

You don't fork over your decryption keys on demand, you get jail time just for that! As I said two years ago, this is a lot harder to pull off in the US due to that whole Bill of Rights thing. Harder, but not impossible.

A disturbance in the force.

A friend of mine's experiences with GIMP vs Photoshop are telling. Like many, she tried switching but found GIMP less than useful for any number of things. Such as no 'draw a hollow square' tool, among many, many others. When poking the developers about this the reply came back, in essence, "GIMP is not a Photoshop replacement, it's for photo manipulation." 

Well, it seems that the Ubuntu distribution managers agree with my friend more than the GIMP developers, as they're dropping GIMP from the default install. Why? Well...
  • the general user doesn't use it
  • its user-interface is too complex
  • it's an application for professionals
  • desktop users just want to edit photos and they can do that in F-Spot
  • it's a photoshop replacement and photoshop isn't included by default in Windows...
  • it takes up room on the disc
If the most popular desktop linux on the planet calls GIMP a Photoshop replacement, then... it just might be a Photoshop replacement. No matter what the Devs think. It will be interesting to see what openSUSE and Fedora do in their next dev-cycles. If they keep GIMP, things will probably continue as usual. The same if a user revolt forces it back into the Ubuntu defaults. On the other hand, if Fedora and openSUSE follow suit, this will be a radical change in the GIMP community environment. They may start addressing the UI issues. Who knows.

As it stands, Adobe has nothing to fear from GIMP. Anyone well versed in Photoshop will find the UI conventions of GIMP wildly different, and the same applies to methods to solve certain image problems(*). Adobe only needs to fear the people who a) don't want to pay the umpty hundred bucks for Photoshop, b) aren't willing to pirate a copy, and c) are willing to tough it out and learn a completely new package with radically different UI metaphors. There aren't that many of those.

Me? I've never used Photoshop. Or if I have, it was back in the early 90's. I've been using GIMP all this time and that's what I know. I intend to keep it that way since I really don't want to start paying Adobe all that money. That said, I totally understand why people don't like it. I also miss simple tools like 'draw a square', and 'draw a hollow circle'.

(*) Some of these solution paths are patented by Adobe, so no one else can do it that way if they wanted to. This is what closed source software brings you.

Restrictive internet policies

| 1 Comment
A friend of mine griped today:
In a stroke of utter WTF-ness... my workplace has blocked access to
It's not so WTF for me as I can see why it was blocked. LinkedIn is seen as a tool for people looking to transition jobs. So if you're blocking Monster and Dice, then LinkedIn is right up there with it. The fact that it also is a useful way to network for business is beside the point. From earlier gripes, this particular workplace is on a crusade to block all social-networking sites. I only saw this post because of email-to-post gateways, and they haven't blocked gmail yet.

It is situations like these that give rise to the scenario I described back in June: I Want my SSH. Additionally, a lot of social networking sites are publishing apps for the various app-driven smartphones out there. For users willing to invest a bit of money into it, corporate firewalls are no longer the barrier to slacking they once were.

Packet size and latency

| 1 Comment
The event-log parser I'm working on has run into a serious performance wall. Parsing 60 minutes worth of security events takes 90 minutes. The bulk of that time is consumed in the 'get the event logs' part of the process, the 'parse the event logs' portion takes 5% of that time. Looking at packets, I see why.

I'm using Powershell2 for this script, as it has the very lovely Get-WinEvents commandlet. It is lovely because I can give it filter parameters, so it'll only give me the events I'm interested in and not all the rest. In practice, this reduces the number of events I'm parsing by 40%. Also nice is that it returns static list of events, not a pointer list to the ring-buffer that is the ususal Windows Event Log, so $Event[12345].TimeCreated() will stay static.

The reason the performance is so bad is that each event-log is individually delivered via RPC calls. Looking at packets, I see that the average packet size is around 200bytes. Happily, the interval between RPC-Response and the next RPC-Request are fractions of a millisecond, and the RPC-Response times are about a half millisecond so at least the network is crazy-responsive. But that packet size and the serial nature of this request means that the overall throughput is really bad.

If there were a way to phrase the Get-WinEvents command to only populate the attributes I'm interested in and not any of the others (such as .Message(), which is the free-text message portion of the event, quite large, and noticibly laggy in retrieving), it could go a LOT faster. Since I don't have powershell installed on my domain controllers right now, I can't see how much running it directly on them would improve things. I suspect it would improve it by a lot since it should be able to use direct-API methods to extract event-log data rather than RPC-based methods.

As it is, we may have to resort to log-shipping. With over a GB of security event-log generated per DC, per day, that log server is going to have to have large logs. It has to be at least Vista or Windows 2008 in order to get shipped logs in the first place. Sad for us, we don't really have any spare hardware or VM space for a new server like that.

And finally, yes. There are 3rd party tools that do a lot of this. We need something both free and scalable, and that's a tricky combination. Windows generates a LOT of login/logout data in a network our size, keeping up is a challenge.


Over the years I've heard variations on this complaint:
"I don't need a secure password since everything I work on can be seen with a freedom-of-information-act filing anyway."
In the run up to the internal lobbying effort that allowed us to start password aging and put password complexity rules into place, we ran L0phtcrack against our Windows domain passwords. The results were astounding. A crushingly large percentage of passwords were still set to ones well known to be used by the helpdesk during password resets, users had never gone back and changed their password after having it reset by said helpdesk. A not much surprising but still disheartening number was the percentage of passwords set to either "password" or "p@$$w04D". These results are what convinced upper management to push password complexity policies onto the unwilling masses.

But that doesn't address the complaint above, merely shows the effects of this attitude. While it may be true that you work on nothing confidential, you still have one thing near and dear to your heart that you do care about; Identity. Especially with the advent of web-based Enterprise email, this is a very important thing. While it is trivial to impersonate an email address, it carries far more weight when that email is delivered from our servers. What's more, the ability to reply to legitimate emailas you is something you don't want. And finally, I don't know a single person that fails to have at least some personal correspondance in their work mailboxes, even if it only exists in the trash folder. That information may still be retrievable by an FOIA filing, but the generation of information does not, and generation of information is what you allow by having your password compromised.

We mean that. We don't allow managers to have departed employee's passwords for the same reason. Happily these sorts of gripes are becoming ever less common as the lessons of Phishing come home to more and more people. But this gripe is one that is particular to the public sector, so many of you may not have heard it before.

The Firefox anniversary

Firefox turns 5 today. I'm sure you already knew that, what with it being widely covered industry-wide and all. This has caused me to look back on my own usage of Firefox over the years.

In the beginning, there was Mozilla. And I used it. And it was good. It had a nifty integrated html editor that I used on occasion. And I had used it for many a year.

I noticed the dev-work on Phoenix/Firebird and used it a bit at home on my Linux machine. Never did any serious browsing with it, but I did use it.

And then there was Firefox. When Mozilla announced that they were killing Mozilla-the-browser and replacing it with Firefox, I dutifully switched to that for day to day usage. I believe that was the 1.0.

And then there were the fights. Firefox did things differently than Mozilla did. I tried to take things in stride, but it was hard. Cookie handling was a big pet-peeve of mine (since remedied). The other one is still true.

I flirted with Opera briefly, but it was annoying in different ways. Sad.

And then there was the breakup. Which I blogged about here. You see, I'd learned about SeaMonkey, which is an OpenSource project aimed at bringing the defunct Mozilla-browser into the future. It had the experience I was used to, and worked with most of the Firefox extensions too! What's NOT to like? I was hooked and made the switch. Good by, Firefox! Won't miss you.

And then I moved to openSUSE as my primary desktop. This required a certain amount of Firefox usage simply because that was the 'built in' browser. Mostly I ignored it, since they had SeaMonkey as an option.

And then SeaMonkey started getting stale. The same UI for, like, 5 years gets old. And the little bits where it differed from the IE/FF experience were growing. So I started using FireFox on the side at work, as a way to do things like run my Google apps in a separate browser so I could do all of my other searching without directly associating my search terms with my Google account.

And then Firefox 3.5 came out. And it sucked less. I converted to FF3.5 at home, but still kept with SeaMonkey at work. It still involved some nose-holding in various spots, but I was determined to bull through. I got used to the popularity contest in the drop-down bar. I still miss the way typed in (or pasted in) URLs never show up in that list, but I got used to it.

And then SeaMonkey looked to be in PermaBeta for 2.0. Knowing I am a very small minority of web users by using SeaMonkey (0.58% of viewers of this blog, which is less than the 2.08% of you still using Mozilla), I had doubts about the long term prospects of SM. My Firefox usage ticked up again. And when Opera 10 came out, I gave it a real going over. For work stuff it didn't cut it, but it just might for home use.

And then SeaMonkey 2.0 actually released. Download it now! It integrated some of the more annoying-but-need-to-have features of Firefox (like the SSL handling) but kept the drop-down sort the way I like it. An MRU list.

And that brings me to today. At work Firefox is the browser I keep logged in to Google for various things, and still use SM for all of my other browsing. I find that handy.

And now you know.

Audit logging

| 1 Comment
When I first arrived here we used to get this question four or five times a year:
Can you check to see who was logged in to server X at 2:34pm yesterday?
Back in 2003, "Server X" was 98% likely to be a NetWare server. In 2003, Novell hadn't come out with Nsure Audit yet, so the only such logging available were the NW4.11-era text-mode audit logging. Which, to put it politely, didn't even come close to scaling to our levels of access. Logs like that take a lot of space. A LOT of it.

Fast forward a few years, and we're now doing a heck of a lot more Microsoft networking. The domain controllers have security auditing turned on by default. While a day's worth of logs are smaller than the Novell logs would have been (not sure about NSure Audit log sizes, never got a chance to use them), it's still very large. A gig a day is not unreasonable, if not more.

One thing that MS auditing doesn't give us is 'lockout address'. So when a student walks up to the helpdesk and asks, "why am I locked out?" the helpdesk staff and look and see what IP did the locking. We can't do that right now on the Microsoft side. I'm attempting to fix this, which requires creating a log-parser for windows.

Happily, this is doable with PowerShell. Unhappily, it means 1.8 million events to chug through when I parse said log. Even more unhappily, the key data I want (IP, Username) is not in a straight up field and requires parsing the Message text. Any time you parse text like that, you become vulnerable to text format changes. It's not the ideal solution, but its what we have.

Once this is done we'll even have a lockout history which we didn't have before. So we'll be able to tell patterns like having a lockout 7 minutes after turning on their Mac, repeatedly. But first I have to finish writing it.

Novell federates with Google

| 1 Comment
It seems that Novell is the first company out of the gate to interoperate with Google Wave. Meet Novell Pulse. Like wave, it'll be a cloud-hosted service for enterprise collaboration at first, but will come out in a software package later. Not at all surprisingly, this will be a commercial product Novell will attempt to make bank with. Also, it is not open source. Unlike Google, Novell makes its money from subscription costs not advertising.

That said, with Pulse offering interoperability with Wave, it is entirely possible for extra-organizational users to collaborate with in-organization users on specific items. Sort of an Open-ID enabled version of SharePoint perhaps. This could be good.

To ship or not to ship

| 1 Comment
The openSUSE project is attempting a vote to determine if 11.2 is baked enough to ship it now, or if it needs to slip.

If you have an opinion, go ahead and vote. Or just read the comments!

Yes, there are bugs. Perhaps a lot of them. If some of these are the type to break your install, start working on it!