When you have 600+ thin clients (or PCs) it's very difficult to know exactly how each is configured. There are also sometimes cases where not all updates have been applied. We also sometimes have circumstances where users request additional features that require a small change to their thin client. Steps are being take to allow all of these tasks to be performed remotely.
These ideas have moved out of my head and into the form of screens. Please, no UI nazi comments. :) I'm sure HIG is being broken, and that a few pixels here and there are wrong. Right now this is just a work in progress to move designs on paper to the real world. Some of this is coded and now working and being tested for functionality. The thin client detail screen offers as many remote features as possible. From this screen we can remote control the user, force all settings back to defaults, reboot their device, see the number/orientation/resolution of their monitors, see which cables (DVI/VGA) are in use and also for the first time store all of their settings on the server. Here is the current (rough) screen. I also plan on splitting a thumbnail of their current screens on the monitors images as well so that support has an instant preview of what the user is seeing. Looks like xrandr can return back a string that indicates the exact monitor model, and I'm checking to see how that works.
We currently configure many settings locally to ensure the best possible user experience. If their monitor won't rotate, that feature is disabled. The monitor is configured for optimal resolution only and does not perform any plug-and-pray type polling for these settings. If you have ever supported users with changing resolutions, you know how important this stability is to your mental health. :) The UI above stores these entries in a flat file sitting in a jailed area of our internal FTP server. When the thin clients are reset to factory defaults or updated with a new operating system they now try and download this file automatically. If the file is found, the configuration UI toggles the right buttons and reboots itself in 10 seconds. So no more human intervention is required. Once it works, it will now always work after upgrades. It's working well, and we are going to try and test this in our training room which contains 16 devices to evaluate a network load.
My coworker Brian is concurrently working on testing FOG to allow for PXE updates. In our initial deployment of these thin clients, PXE updates were tested with the HP provided Altiris and we were not happy with the results so it was never enabled. It's our hope that FOG will allow for easier updates and scale better. Once that is up and running, the technology described above will allow the thin clients to automatically go right back to the tried and true settings that the user was previously using. Getting everyone on the latest code will solve problems for sure and these centralized techniques will make this easier than ever.
There are a few other ideas in my head to increase efficiencies. Another that is being developed is software to make it easier to allow us to see how the servers are performing. One negative aspect of using tools like "top" is that if several of us are monitoring the same server we are all consuming resources obtaining the same data. So what I did was write a very quick background script that checks user counts, CPU usage and number of print jobs and then create charts just *once* and store it in a JPG image. When you go into this monitoring tool, all you are doing is simply loading in the JPG image every 5 minutes. 10 of us looking at this at once will be no problem and we are all sharing the same resources. I put in a bit of code so that if it detects a condition where there might be a problem the chart turns orange and then red to catch your eye. The first iteration of this test UI is below. Once the features are working as expected, the UI will be improved.
So things are busy for sure, but it's fun to be hacking again and the City will for sure easily recoup these hours in staff resources.
4 comments:
how can i work for you or in a job like yours?
don't you have any management software like cfengine that autoconfigures all your thinclients depending on a set of rules you specify?
Dave, may I ask: why do you prefer creating a GUI app instead of, say, a dedicated area on an intranet?
@arch: :) Well we just hired a new employee for development, so jobs do open here from time to time. I have been known to say, "It's only fun when it works." :)
@anonymous: After the bad install process for Altiris a few years ago, everything has become kind of home brewed. The HP stock builds didn't have enough features, so they are very customized at this point. The older thin clients never got Debian upgrades and I had to backport it myself. We have very simple needs and are keeping it very simple. FOG is pushing image updates and then they just download a single file with configuration settings. Seems like it's going to work great for us.
@Jorge: I'm not sure I understand your question. Do you mean why not develop in the browser instead of using GTK Widgets? If that is your question, glade and python are so fast that in a few days or part time hacking it's already mostly working.
Post a Comment