Posts Tagged‘putty’

Automating The Configuration of Brocade Interconnects.

Once an IT environment gets past a certain size the requirement for automation grows exponentially. When you’re working in an environment with a handful of servers and a dozen or so PCs its easy to just spend the time doing everything manually. If you’re in a situation like I am right now where a single deployment covers some 400+ physical servers then that process isn’t particularly feasible, especially if you want any level of consistency across the fleet. It should come as no surprise then that I spend the vast majority of my time automating the commissioning of IT infrastructure and since I don’t want to do something 400 times it usually sees me trying to automate things that really don’t want to be automated.

Dell 8 4 FC SAN Fibre Interconnect Module

Take for instance this little fellow, a Dell 8/4 Fibre Channel Interconnect module for a M1000e chassis (sounds sexy, right?). Don’t let that Dell badge on the outside fool you, like a lot of Dell hardware it’s actually a rebranded Brocade fibre switch under the hood, albeit with a significantly paired down feature set. For the most part it’s just a dumb NPIV device that acts as a pass through for high speed connections but it does have a little bit of smarts in it, enough so it would typically come under the purview of your on site storage team. However due to its paired down nature it doesn’t work with any of Brocade’s management software (at least none that we have here) and so the storage team wasn’t particularly interested in managing it. Fair cop but there was still a few things that needed to be configured on it, so my colleague and I set about figuring out how to do that.

Usually this is when I’ll track down the CLI or automation guide for the particular product and then dig around for the commands I need in order to get it configured. Try as I might I couldn’t find anything from Brocade themselves as they usually recommend using something like DCFM for configuration. There is a SSH interface on the devices however which does have a rather comprehensive set of commands in it but there didn’t appear to be any way to get at these remotely. We could, of course, use something like TCL with EXPECT to essentially automate this process but that’s traditionally quite messy so we asked our on site resident from Brocade if there was a better solution.

There isn’t, apparently.

So off we went building up a TCL file that would do the configuration for us and initially it all worked as expected (pun completely unintentional I assure you). Our test environment worked every time once we had all the initial kinks worked out of the script and we were confident enough to start moving it up the chain. Of course this is when problems start to become apparent and during our testing we began to find some really weird behaviours coming from the switches, things that aren’t mentioned anywhere nor are obvious unless you’re doing exactly what we’re doing.

So in order to build up the original TCL script file I’d PuTTy into one of the switches and execute the command. Then once I had confirmed the changes I wanted to be done had been done I’d then put them into the script. Pretty standard stuff but after re-running the scripts I’d find they inexplicably fail at certain points, usually when attempting to reconfigure a switch that had already been deployed. Essentially I’d look for a “Access denied” message after trying the default password and then send along the correct one afterwards as that’s all that was required when using PuTTy.

However looking at the logs not only is the message it sends back different, saying “Login incorrect”, it also doesn’t just ask for the correct password it also requests the user name again. There are also significant differences in the way output is written between the two interfaces which means for things like EXPECT you have to code around them otherwise you’ll end up trying to send input at wrong times and read lines that you might not want to. It’s clear that there’s 2 interfaces to the Brocade switches and they differ enough between each other to make coding against one incompatible with the other which is just unacceptable.

Realistically what’s required is for Brocade to release some kind of configuration tool like Dell’s RACADM which provides a direct hook into these devices so they can be automated properly. I’ve found old forum posts that reference something like that for Perl but as far as I, and the Brocade people I’ve talked to, am aware there’s nothing like that available for these particular devices. It’s not like its impossible to code EXPECT up to do what we want it to but it’s ugly, unmaintainable and likely to break with firmware updates. If there is a better solution I’d love to hear it but after all the time I have invested in this I’m pretty sure there isn’t one.

Unless Brocade has something in the works, nudge nudge 😉

Windows RT Running on ARM Has Full Win32 Compatibility.

As far back as I can remember the differences between the full version of Windows 8 and the tablet version, now dubbed Windows RT, were made pretty clear. Whilst the Modern UI section of them was going to be essentially identical the full version of Windows wasn’t going to run on anything that wasn’t x86 compatible and RT would be the version that could run on low power systems like ARM. This, logically, came with some draw backs the largest of which is the omission of the desktop environment on Windows RT devices. In all honesty this didn’t bother me as Microsoft is making a version of their Surface tablet (and I’m sure others will as well) that would run the full desktop anyway.

The delineation also made a lot of sense due to the different markets that both versions were targeting. The full version is squarely aimed at the desktop/laptop space whilst the RT version is strictly for mobile computing. In terms of functionality there’s a lot of crossover between these two spaces but the separation essentially meant that you had your desktop with its oodles of backwards compatibility that Microsoft is known for whilst also getting that nice, highly focused tablet environment should you want it.

However as it turns out Windows RT is far more full featured that I first thought and is capable of running Win32 applications:

Windows 8 RT Running x86 Programs

Thanks one intrepid user, Clrokr, over at XDA Developers it has been found out that Microsoft actually included full Win32 compatibility in Windows RT devices that run on the ARM architecture. Whilst this doesn’t mean you can straight up run those executables on said platform it does mean that any Windows application that you have the source of can be recompiled to run, without issue, on Windows RT devices. The above screenshot is from another user, peterdn, who has recompiled PuTTy to run on ARM and it appears to be functioning quite fine. Other applications have also been tested as well and shown to work as you’d expect.

Thinking about it more clearly this shouldn’t have come as a surprise as the architecture diagram for Windows 8 clearly shows that C/C++/C# are fully supported on both platforms and the inclusion of the desktop on Windows RT devices (again something I wasn’t aware of) would have you thinking everything was there to support this. As it turns out the only thing that was stopping this from working in the first place was runtime authentication level that was hard coded to only allow Microsoft signed applications to run in such an environment. The jailbreak that Clrokr details in this post is simply an in memory overwrite of this value which will allow any application to run. From there you just need to recompile your application and you’re golden.

The reasons for the lock out make sense from a business point of view: Microsoft was trying to create a pristine tablet environment that was tightly controlled in order to create a better experience. However at the same time porting all of the underlying architecture to ARM would have required quite a bit of effort and locking this functionality away from people seems like a strange idea. Whilst I’m not going to say they should unlock it for everyone having it as a configurable option would have meant that most users wouldn’t know about it but power users, like the ones who discovered this, could take advantage of it. I haven’t seen if Microsoft has made an official response to this yet or not but I’m sure they’d win more than a couple fans if they did this and it doesn’t look like it would be that hard to implement.

I was genuinely surprised by this as I hadn’t caught on pretty much all of Windows, including everything that makes it tick under the hood, had been ported across to the ARM architecture. I had believed that it was just a port of the core functionality required to support the WinRT framework but as the above screenshots prove Windows RT devices are pretty much fully fledged copies of Windows, they just need their applications recompiled in order to work. Of course questions of how those applications fair vs their modernized counterparts in a tablet environment remains to be seen but it’s interesting that the option is there and that Microsoft has gone to such lengths to keep people from fiddling with it.