June 2011 Archives

Firefox hates enterprises

That headline has made the rounds, and I can see why. Some entities require validation of new browsers before deployment, and Firefox's new schedule kinda gets in the way of validation periods that are longer than 3 months.

As usual, Ars Technica has a nice opinion piece on this one. Read it here.

Their argument is very much focused about the good of the web as a whole. Stick-in-the-mud corporate types that only update browsers every 2-3 years bring everyone back to the dark ages, and that just ain't right. The web is a fast moving thing, and clients need frequent updates to make the whole thing a better experience for everyone. They're not wrong!

But...

Corporate types (and even Governmental offices) like to restrict internet access to only 'business-appropriate' usage. Or even, business-only if they can get away with it. Social-media blocks are common at corporate internet borders, and that's just the tip of the iceberg. The browser on your work-machine is for accessing work webapps, period. Anything else is incidental, and secondary to the work webapps.

When you can restrict what parts of the web a client-base can see, and can also maintain high control over what you do allow, then the features of your browser become something that corporate decision processes can manage. I've long suspected that statistics of IE6 usage are under-reported due to corporate internet access restrictions preventing those IE6 users from hitting the right statistics gatherers.

I know of corporate-types who consider office web-app upgrades the same kind of decision as office-productivity software upgrades; something you do once every couple of years. And if that 3 year old web-app still works best with IE6, well that's what you use. Microsoft has long had the kind of controls in place to actually enforce this kind of thing, which is why IE is still king of the corporate network.

Corporates are far less interested in the good of the web than they are in the good of the company. Some may consider the good of the web to be the good of the company, but I suspect they're the small minority. For the rest using old Cold Fusion applications written for IIS5, they'll stick with what works, thank you very much, and damn the rest. They shouldn't be going there anyway.



But what can be done about this? Microsoft's Compatibility Mode in IE is designed specifically for these older browser-quirks, which is why IE upgrades are higher than they otherwise would be in the corporate space. That's one option.

The other option is simple attrition. Some corporate types don't upgrade major systems more than once every 5 years due to the expense of doing so. Eventually they'll upgrade to something with a better backwards compatibility mechanism than what they've got now, and might keep up finally. ALL of the big browser players (Microsoft, Mozilla, Google, Apple, and even Opera) have embraced incremental improvements over minor point-revs.

Unfortunately, nothing is going to stop some corporations from their "twice a decade" upgrade pace for major systems. If those systems present an HTTP interface, that 5 year old interface will still be a critical line-of-business item that'll need validation in the face of every incremental browser improvement. Some will get with the program and validate new-feature point-revs quicker than they have. Others will just stick to a single browser until such time as change is either unavoidable or permitted by the critical system.

Where I just might be in October

In case you missed it, StackOverflow is doing their DevDays thing again. Could be interesting, and they even have one near me! In fact, I've volunteered to help keep their wireless network up for the DC event. It'll be fun!

However, out in the San Francisco DevDay they're doing a 3rd day for a High Scalability conference. There is a weeny bit more information about that conference in the Blog post that announces it. This is right up my alley since scale is something I'm grappling with right now. I'm not in a position to submit anything for presentation (maybe come September I will be, but that'll likely past the submission deadline), so I'll be watching the Speakers list with interest.
We decided to change our hold music off of the stock music on our UC520 to something a bit less... like default hold music (the "MOH file"). The instructions for doing so were pretty straight forward, the hard part was creating the music file. The work can be done in Audacity, but the options are hidden. And I didn't find much out there for generating this, so this is my attempt to help people out.

Before I get into this, a warning:
There are copyright issues surrounding hold music. You can't just plug a loaded iPod into the External Music port and hit play, shunt a SiriusXM feed into it, or feed a random Pandora station into that port. Nor can you hunt the web for the perfect tune that is both inoffensive and yet un-sucky. As I understand it, the music has to be free for commercial use, or you must hold a license to use it for commercial use.

Back to the How-To.

Step 1:
Open the file in Audacity
audacityMain.png
Yes, those cats do take a while to finish their argument. No one likes being on hold. Even cats.

Step 2: File -> Export
ExportFile.png
Make sure the format drop-down is set to "Other uncompressed files".

Step 3: Click "Options"
SpecifyUncompressedOptions.png
The settings you want are 'Header = WAV (Microsoft)' and 'Encoding: U-Law'.

Hit OK.

Save the file.

Congratulations! You now have a MOH file! There are a couple of methods of getting it onto your device.

  • Cisco Configuration Assistant
  • CLI
Cisco Configuration Assistant
  1. Open CCA
  2. Connect to your UC device
  3. Go to the Maintenance area
  4. Open "File Management"
  5. Go to the Files tab
  6. Expand "Flash:"
  7. Expand "Media"
  8. Click Upload
  9. Select the file you saved above.
  10. Click Open.
  11. Close File Management.
  12. Go to the Configure area
  13. Expand Telephony
  14. Expand Voice Features
  15. Open "Music On Hold"
  16. In the drop-down list, select the file you uploaded.
Now you have music.

CLI
  1. Connect to your UC device however you wish.
    1. Console cable
    2. Telnet
    3. The HTTP gateway
  2. Copy the file you created somewhere retrievable via any of the following protocols:
    1. ftp
    2. http
    3. https
    4. rcp
    5. scp
    6. tftp
  3. Issue the command to copy the file from wherever you saved it in the previous step
    1. copy http://10.11.12.13/TwoCatsFighting.wav flash:/media/TwoCatsFighting.wav
    2. copy ftp://10.11.12.13/pub/outgoing/TwoCatsFighting.wav flash:/media/TwoCatsFighting.wav
  4. This will upload the file to the UC appliance.
Unfortunately, I wasn't able to figure out how to set the MOH-Music file from CLI. *sad admin*. See the CCA instructions above for that (Windows Only, alas).


ObHumor: No, our hold music isn't two cats fighting. Just thought I'd spell that out.

Reading those firewall logs

I do review our firewall logs, and do what I can to keep them clear of stuff coming from my network. Even so, there is still a lot of stuff there. One particular IP address had been port-scanning us very persistently for weeks. Last Thursday I finally had enough and looked into it.

The weird thing about the log-lines was that the source TCP port was TCP/443. The target ports were the usual assortment of high-order ports. Most odd.

The reverse lookup of that IP didn't give me anything. However, an openssl query to see what SSL certificate it was offering did give me information.

One of our cloud-app providers.

Wha?

Time to sniff packets. And sniff I did. I got a couple minutes and it was long enough to get a few port-scan attempt log-entries. After correlating the source/target port numbers one pattern was pretty clear:

The cloud-app provider was issuing double RST packets after receiving a FIN packet from our side. The first RST tore down the connection as far as the Firewall was concerned, which made the second one seem like a packet from nowhere with strange flags on it and therefore suspicious.

I did helpfully tell said cloud-app provider about this, and they send back a, "situation normal, nothing to see here," reply, and googling around does show some systems do use a double-RST method for tearing down connections. I'm not sure why this is a good idea in some cases, but it's pretty clear our firewall doesn't like it. At least this is a bit of log-spam I can now safely ignore.

Doing something new

Tonight I'll be doing a new thing. I'll be going to a sporting event, tickets provided by a trio of vendors. There will be box seats. Ostensibly the #1 companies in the Fibre Channel Storage, Virtualization, and Networking spheres (I think you know who they are) are trying to convince me that their cloud/grid/massively-scaled-out solutions really are the best out there and they deserve our business. We'll see about that.

What's new is that this is not the kind of thing I could accept at WWU, or at least it was a big gray area. My boss most definitely couldn't. Since I'm actually a decision maker here (or at least a strong influencer) for IT purchases, and having spent my entire career thus far in the civil service, this seems... strange to me. I know it happens, but to have it happen to me is still kind of odd.

I was able to talk 'em into letting me take my Intern along. It'll be a nice thing all around for him, since he's pretty network focused and they'll be talking about the kind of grand high geekery that even the good tech schools don't really cover.

Too bad (or perhaps it would be a good thing) it isn't a DC United game.

An older problem

| 1 Comment
I deal with some large file-systems. Because of what we do, we get shipped archives with a lot of data in them. Hundreds of gigs sometimes. These are data provided by clients for processing, which we then do. Processing sometimes doubles, or even triples or more, the file-count in these filesystems depending on what our clients want done with their data.

One 10GB Outlook archive file can contain a huge number of emails. If a client desires these to be turned into .TIFF files for legal processes, that one 10GB .pst file can turn into hundreds of thousands of files, if not millions.

I've had cause to change some permissions at the top of some of these very large filesystems. By large, I mean larger than the big FacShare volume at WWU in terms of file-counts. As this is on a Windows NTFS volume, it has to walk the entire file-system to update permissions changes at the top.

This isn't the exact problem I'm fixing, but it's much like in some companies where granting permissions to specific users is done instead of to groups, and then that one user goes elsewhere and suddenly all the rights are broken and it takes a day and half to get the rights update processed (and heaven help you if it stops half-way for some reason).

Big file-systems take a long time to update rights inheritance. This has been a fact of life on Windows since the NT days. Nothing new here.

But... it doesn't have to be this way. I explain under the cut.

Me and IPv6 day

| 2 Comments
You'd think I'd be doing something, but I'm not, really. The full extent of what I'll be doing is dealing with users on our network troubleshooting why access some now-v6-available services don't work out there on the greater internet. It'll be interesting data to have, and may be useful more widely. But...

Our network isn't really v6-ready. Our core network infrastructure just doesn't have everything it needs, or if it does it's hiding from me. Also, our firewall software is just old enough I don't trust it with v6.

As for the home, I've long had a project to get a v6 tunnel going but that's been blocked since I moved out east. In large part because I suddenly have a lot less time at home, and I also need better hardware for the device that'd have to be our IPv6 gateway; the 8yo Linux server is technically good enough but I no longer trust the hardware to stay up.

So, I'm going to be spending this World IPv6 day on resolutely v4 networks. Alas.

Compatibility mode fun

Last week and this week had me upgrading a certain piece of software that desperately needed it. We're moving from a version released about 2006 to one released this year. The 2006 version (v06 for this blog-post) was installed on a Server 2003 32-bit install, and was written at a time where 64-bit was still in the future a fair piece for most offices. As you'd expect v11 was written with 64-bit in mind, heck, it's a .net 3.5 app so it should work just peachy.

The problem comes with upgrading this package. Not only am I upgrading several major point revs, but I'm also installing to Server 2008 R2 which is unavoidably 64-bit. Happily, there is a migration path. I have to upgrade to v08 first to deal with a data-conversion routine no longer present in v11, and then move up to v11.

The thing that had me pulling my hair was how to get v06 to install to Server 2008 R2. The migration documentation was pretty clear on how to migrate v06 to a new server:

  1. Install the software to the new server
  2. Export this one reg-key in HKLM/Software on the old server
  3. Stop the services on the new server
  4. Import the .reg file on the new server
  5. Copy over the datafiles to the new server
  6. Start the service.
Straight forward! However, there was a problem.

v06 didn't install right to 2008 R2. Whatever it was using for installing the needed service wasn't creating everything it needed to create. Even after I nudged things along, it was pretty clear that all was not right. In the end I had to set the installer executable to run in "Server 2003 SP1" compatibility mode. THAT got it installed, yay.

But the reg-import clearly wasn't giving it the data it needed. It was only after I threw "procmon" at it to see where it was trying to pull registry data from that I noticed it was doing it from some new place. Down there in HKLM is a new reg-key for 32-bit applications on 64-bit installs, called [HKLM/Software/Wow6432Node/]. Since this is my first time going to the registry level for this kind of pure-32 application, I hadn't run into this before.

Sure enough, the install created the needed nodes under THAT reg-key instead of HKLM/Software like the upgrade doc said. A simple search-and-replace on the exported .REG file for "Software/$Vendor" to "Software/Wow6432Node/$Vendor" and reimport got it all going again.

Yay!

And the upgrade to v08 worked just fine, as did the upgrade to v11. Whew.

What it is we do

A few links for what it is that we do. Below the fold to save the uninterested from the linkspam.