HP SAN switch: upgrading the firmware

This was supposed to be a quick update about how we managed to reconfigure our HP Storageworks 4/8 SAN switch. Alas, it isn't. After managing to get the java configuration interface back up and running, the thing still would fail on certain configuration actions like renaming aliases.
It seemed sensible to me to upgrade the firmware, the latest firmware according to the HP support website is 6.2.2f, whereas our switch still runs on 5.3.0; carbon dating pointed out that this version might be about 5 years old.
Support page:
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=1143865&prodTypeId=12169&prodSeriesId=1143864&swLang=8&taskId=135&swEnvOID=54
Obviously, the sluggish java web start interface did not allow for any firmware updates, a 200+ MB management tool called Data Center Fabric Manager is necessary for this. The setup does not configure a username or password, it assumes that you read the manual which includes the default username and password: Administrator and password. 
Once that minor annoyance has been dealt with, you can add your switch one smile: there is an option called firmware management! We can upload new firmware versions to a repository on an FTP server, because FTP is this high tech protocol that everyone just loves you know. After adding the latest firmware, we can start the upgrade, with the following result:

Right. We need 6.1. HP is an awesome company and apart from creating annoyances, they also provide stuff to solve them. Downloading 6.1, adding it to the repo. Result:

Great. What else do they provide. Interim B-Series Firmware V6.x upgrade path for HP StorageWorks Fibre Channel Switches. Looking good, the website lists some even older versions, with an interesting footnote: effective date - September 2011. No idea what that is supposed to mean. Maybe our calendar system is a bit off and HP got it right.

After ending up with 1.44 GB of firmware upgrades, my colleague figured out a Java version that was willing to execute the java interface presented by firmware 5.3.0 without any complaints: Java 1.5 update 1. Kinda old and a reason to continue the update adventure. The update to 6.0.1a went smooth and resulted in a broken EZManager (simple version of the interface) and a nicely working advanced interface (http://<ip>/switchExplorer.html) Updating to 6.1.2b did not change this issue. It might have something to do with cached jar's, I did not investigate this as the advanced interface is ten times better. Same story for the update to the most recent version, version 6.2.2f

End result: http://local-switch-ip/switchExplorer.html works without any issues. The standard interface does not.

Update:
switchExplorer.html still has issues. We ended up updating the zoning configuration of the switch with the same tool I used for updating the firmware. :)

HP SAN switch Java web start madness

The SAN switch over here, an HP Storageworks 4/8 SAN switch, can be configured through a webpage which presents a java web start application. Apparently this is such a thing that 'used to work' that suddenly doesn't work anymore. Read: the computer that was used during the setup of the switch - which happily executed the web start app - isn't around anymore. What the web app did do was presenting some security warnings which could be clicked away with some yes/no clicking. After the warnings, a nice interface would appear, devoid of any useful information about the SAN switch. It still displayed some fancy flashing lights on a visualization of the switch though.

In the Java console, the following error popped up:

javax.xml.bind.JAXBException: Provider com.sun.xml.bind.ContextFactory_1_0_1 could not be instantiated: javax.xml.bind.JAXBException
 - with linked exception:
[java.security.AccessControlException: access denied ("javax.xml.bind.JAXBPermission" "setDatatypeConverter")]
 - with linked exception:
[javax.xml.bind.JAXBException
 - with linked exception:
[java.security.AccessControlException: access denied ("javax.xml.bind.JAXBPermission" "setDatatypeConverter")]]
at javax.xml.bind.ContextFinder.newInstance(Unknown Source)
at javax.xml.bind.ContextFinder.find(Unknown Source)
at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
at com.brocade.tm.xslt.XSLTTransport.<init>(XSLTTransport.java:42)
at com.brocade.tm.TransportFactory.makeTransport(TransportFactory.java:32)
at com.brocade.tm.TransportFactory.getTransport(TransportFactory.java:25)
at com.brocade.pm.framework.MainPanel.enableProgressIndication(MainPanel.java:831)
at com.brocade.pm.ezmgr.EZManager.initMainPanel(EZManager.java:195)
at com.brocade.pm.ezmgr.EZManager.runApplication(EZManager.java:425)
at com.brocade.pm.ezmgr.EZManager.initApplication(EZManager.java:401)
at com.brocade.pm.ezmgr.EZManager.main(EZManager.java:447)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

etc ...

Hmm. Permission stuff. The JNLP file, which coordinates the web start procedure, contains the following magic lines:

<security>

<all-permissions/>

</security>

Looking good, but it clearly was not good enough. After some head scratching, googling and pixel staring, I guessed that the Java warning at the start - The application contains both signed and unsigned code. Contact the bla bla bla to bla. - might actually have a purpose; to read and interpret it. The obvious solution would have been to fix the signing issue. However, I don't know how to fix that. The second solution is to explicitly state that the web app is allowed to 'set the datatype converter', something that wasn't really working according to the Java log. In my home directory (Windows in this case), I created a file named .java.policy with the following contents:

grant codeBase "http://<ip address of the SAN switch>/-" {  
permission javax.xml.bind.JAXBPermission "setDatatypeConverter";
};


Fixed :)

Galaxy Nexus battery drain

Just a quick post about my Galaxy Nexus. I have it for twee weeks now, and I almost started to accept the crappy battery life: unplugging it at 8:00, realizing at 20:00 that it might be a good idea to turn off the data and 3G. Meh, crappy indeed.

Yesterday I decided to try 2G only for a while, with some noticeable improvements. I started some further investigation and ended up installing Better Battery Stats. This program showed an interesting statistic: my phone refused to go in deep sleep, and a mysterious process (or service?) called BTLowPower seemed to be the little daemon that kept my phone awake day and night. I'm pretty bad at word games, so it took me some googling before I realized that it was some Bluetooth thingy. Hmm. I barely use Bluetooth. Some more googling: Bluetooth on stock Galaxy Nexus is buggy. It tends to be stuck in some phase which could best be described as: the thing tries to enable bluetooth and fails miserably.

Fast forward (got some work to do): reboot phone, if Bluetooth appears magically to be enabled, disable it. Result: no more BTLowPower!

Net result: after 7 hours, 80% battery left. And that's with data synchronization enabled and playing around with the phone (36 minutes screen time).

Boost on Visual Studio 11

Boost 1.49 is full of references to VS11, although it is still not supported by default. Some tweaks I did:

tools\build\v2\engine\build.bat
The section :Guess_Toolset has to know that VS11 exists, add the following part:

call :Clear_Error
if NOT "_%VS110COMNTOOLS%_" == "__" (
    set "BOOST_JAM_TOOLSET=vc11"
    set "BOOST_JAM_TOOLSET_ROOT=%VS110COMNTOOLS%..\..\VC\"
    goto :eof)

 Same goes for :Config_Toolset, add the following part:

:Skip_VC10
if NOT "_%BOOST_JAM_TOOLSET%_" == "_vc11_" goto Skip_VC11
if NOT "_%VS110COMNTOOLS%_" == "__" (
    set "BOOST_JAM_TOOLSET_ROOT=%VS110COMNTOOLS%..\..\VC\"
    )
if "_%VCINSTALLDIR%_" == "__" call :Call_If_Exists "%BOOST_JAM_TOOLSET_ROOT%VCVARSALL.BAT" %BOOST_JAM_ARGS%
if NOT "_%BOOST_JAM_TOOLSET_ROOT%_" == "__" (
    if "_%VCINSTALLDIR%_" == "__" (
        set "PATH=%BOOST_JAM_TOOLSET_ROOT%bin;%PATH%"
        ) )
set "BOOST_JAM_CC=cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib"
set "BOOST_JAM_OPT_JAM=/Febootstrap\jam0"
set "BOOST_JAM_OPT_MKJAMBASE=/Febootstrap\mkjambase0"
set "BOOST_JAM_OPT_YYACC=/Febootstrap\yyacc0"
rem change it back because VC11 is not officially known.
set "BOOST_JAM_TOOLSET=msvc"
set "_known_=1"

Credits for the part above: http://landoftheninja.blogspot.com/2011/11/visual-c-11-and-boost.html

In my case, the build system was still using the compiler from the VS10 installation and I had to tweak some more.

Open the following file:
tools\build\v2\tools\msvc.jam

I basically searched the file for occurences of 10.0 and added equivalent entries for 11.0
credits: http://article.gmane.org/gmane.comp.lib.boost.devel/228596/

That should do it. Open up a Visual Studio command prompt and bootstrap the build system.

bootstrap.bat

Check for errors, and start the build process, in my case I executed the following command:

 b2 link=static threading=multi address-model=64