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.
No comments:
Post a Comment