We've Got Browsers

I mentioned that I had a project assigned to try and get multiple browsers running to the same user at the same time so that we could run the release supported by the various vendors on our intranet. One doesn't want to allow older browsers and versions of Java to get out to the Internet. Behold, three versions running in one session:



In this case, a user can use the Oracle and SAP software and currently surf the Internet using Firefox 3, 4 and 5.

I had to think about the best way to make this work, so the current version always works normally and makes use of the users bookmarks and settings (obviously). The older versions run as users "firefox3" and "firefox4" and I made use of the -ProfileManager feature in Firefox to allow multiple users to run from the same user account. I then locked down prefs.js and localstore.rdf to settings I want to be used. For instance in order to make it look more like "software" I hid the URL and menu bars so they aren't tempted to try and surf with the sessions. The beauty of this design is that when Firefox 3 and 4 are no longer needed, I simply delete the user account and all of of these settings and infrastructure for that version is deleted.

If you are struggling with the same issue, this technique allows you to run all of your Firefox sessions from the same server. Our server for Firefox is a monster, and it would have been a shame to have to offload this functionality to another server or VM instance.

Many Projects Continue

For those interested, many concurrent projects continue here at Largo.

FOG & Host Stored Configurations & Portal
We have continued working on implementing network updates using FOG and things are going very well. We have a group of about 40 devices configured to network boot and have been testing the wake-on-lan features and configuring FOG to do updates at specific times. Our network guy has been reviewing the logs to see how much these updates impact the network. I completed the UI to allow us to store host based settings for the thin clients (pic below). It's a very simple file that is downloaded at first boot of update and configures the thin client back to the settings we desire. In between things I have been hacking on the portal UI below too and slowly adding features and figuring out ways to make it easier for our support staff to perform repetitive and common tasks that are handled via the command line right now. I'll post a more detailed blog when more is finalized and working. As mentioned, this really is a back burner project.



Firefox 3, 4, 5, 6, 7 & 8

OK, I know we are only up to Firefox 5. :) But the new aggressive version upgrades and feature changes have presented a challenge for us. It's very easy to do upgrades here, it would only take me a few minutes to physically install the new release. The impact is the *software* on the backend. Many vendors are very slow in "supporting" browser and Java changes. One vendor in particular that currently owns Java has software that has to run Java that is 2-3 versions old. This whole issue is a challenge for us on a centralized computer, I can't even imagine the gray hair it's causing on a client/server network. I tend to be the type of person that tries to turn a problem into a strength; and I believe we have a solution. What we are going to do is keep a copy of older Firefox releases for specialized intranet applications and not allow these sessions to get out to the Internet (for security reasons obviously). They will be jailed inside our network. For instance we have one financial package that requires Firefox 3.6, and another that requires Firefox 4. What I am going to do is create user accounts "firefox3" and "firefox4" and when the user clicks on an icon for those apps it will "su" into that account, start the appropriate version of Firefox and then automatically connect to the software authentication screen. These sessions will not be able to "surf" to the Internet. When they click on the Firefox icon, it will launch the most recent release (5 in this case) and use their personal bookmarks and settings. I don't want these older versions of Firefox running as the end user and impacting their settings. The graphic below is what I sent out to our IT staff to illustrate how it will work. Some technical issues remain, but most of the scripting is already in my head.

Virtual GNOME Desktop Working
The other hurdle that we completed was getting the new virtual GNOME desktop server working automatically. The physical server can be copied once a week now. One issue we had was that when rebooted the server would try and use the same IP address as the live server. So a few lines of code at startup detect a VM instance and changes the address of the NICs automatically. So we had a few users log into this second server and they were very pleased that all of their settings and customizations were all the same. This virtual GNOME desktop will allow us to split the load of users and allow for a second host to be available to be available in the event of some kind of hardware failure.

NX iPad Testing Continues

Now that the NX pre-release is working well enough for testing, I have been spending time asking questions and understanding how it works. My expectation was that there would be a place to configure your resolution just as you do in the NX clients. But the way it works is that you log in 800x600 and then use the desktop tools (xrandr front ends or whatever) to change your resolution on the fly. These tools are not exposed to our users, so I had to come up with a way to do this automatically. I'm sure when I have a few days to think about it, I'll have more ideas on how to properly get this deployed.

The code below was the hack-ish thing that I did to make it work for now. The xdpyinfo string returned by NX is different than our thin clients. Xsession checks for 800x600 and then does a secondary check to see if the NX string is returned. In that case it can then kick you into any resolution that you wish using xrandr -s x.



NX then automatically implements something similar to the -scale command of xrandr and fits whatever resolution you pick into the real estate of the tablet. From the code sample, you can see that I tested 1024x768 which gives you an almost 1:1 scale for the iPad. I then bumped it to 1440x900 and it automatically fits the entire tablet and is usable, but a bit grainy. Probably we would not bump it up that high nor give it the wrong aspect ration in this manner. Regardless, it was an interesting test. In the shot below I'm running software in 1440x900:



The speed of the presentation is still not ready for end users, they are impatient and it's hard to explain that tapping icons 50 times in a row doesn't make it faster. :) My tests were over 54Mb WiFi and it seems about 80-85% the speed that I would desire. Much better than early previews, but not ready for prime time.

Next up will be additional testing of NX over EVDO and also testing the webplayer from browsers over broadband connections. If this works well, it might mean we can stop having to give City employees client software to take home to log into the City network. I need to see better performance before that change could occur.

Happy long weekend!

PS: The iPad stand from Amazon is wonderful.