November 01, 2007
Production Launch Coming Mid November
We are quickly approaching our production launch. Details coming soon.
September 28, 2007
Virtual Sites Blog Moving to New Sites Blog
Hi folks. We are going to incorporate the Virtual Sites blog as a category of the new Sites blog located at http://mblog.lib.umich.edu/sites/ It is planned that it will updated every one to two weeks at a minimum.
Some people have been asking me if I have a personal blog. I do actually have a Sam Jones blog and its located at http://www.samuofm.com. Mostly it's an automatically updated collection of links I tag as I traverse about the internet but I do occasionally write real content and it's generally programming and development related.
August 09, 2007
Production System Getting Closer
We are currently in the process of integrating the production website and look to have it in place during the week of August 12th. Your feedback is very much welcomed and encouraged.
March 06, 2007
Virtual Test Lab Open
We recently opened up our virtual test lab to public testing. We have received a lot of good feedback and ideas for the system. And we want more! If you are a U of M member and are interested in testing out the system please send an email to email@example.com and we will send you the URL to the test lab.
February 16, 2007
Virutal Test Site Nearing Ready State
We are please to announced that the first test environment for the virtual sites project will be open to external testing starting Wednesday February 21st. We encourage any U of M personnel who is interested in helping us to begin testing to please email firstname.lastname@example.org. We will be sending out the test URL to interested parties on that date and will be very excited to receive your feedback.
January 26, 2007
The Virtual Sites team is pleased to announce that we have now completed work on the client daemon that helps to facilitate external connections to our Sites lab machines. We are currently directing our effort towards development of the web application and hoping to have an available test environment open to interested parties by mid February. We will keep you posted as we draw towards completion of the test environment and please email email@example.com with any questions or comments.
December 12, 2006
Development of Web Application
Development of the web application for machine scheduling is moving along well. We have recently finished the database design and are continuing work on the client daemon in parallel.
November 30, 2006
Project is in Full Swing
A few weeks ago we had the great fortune of having Kitty Bridges (the Associate Vice President of ITCS) officially announce the project at the Academic Computing Support Forum meeting. We are all very grateful to her for her role in that. Since that time we have been working very hard on creating a working demo of a system using a web application and client daemons running on our workstations. Initial results have been very promising and we hope to have a system that we can allow testing on sometime during the next semester.
October 25, 2006
General Campus Announcement
We are getting ready to make a general campus announcement talking about the project. Once this happens we will then schedule a meeting with interested parites and use the information gained from that meeting to prepare a needs assessment document.
October 03, 2006
Updates After the First Week
Well now the Virtual Sites project is just over a week old and it seems appropriate to give some updates on what has been going on. We posted some analysis updates to the Wiki to try to explain some of the options we are looking and the respective pros and cons of each.
One resource we received this week was a powerpoint detailing the implementation of a remote access strategy currently in use at the University of Wisconsin in Stevens Point. Their system makes use of an ActiveX control and a backend database for creating a remote connection through a remote PC running Internet Explorer. In terms of efficiency it is a great system because it makes use of off-warranty machines their IT group already had and also their campus lab machines during off hours. One of the cons we are seeing with are it though is a vunerabilty to Denial of Service attacks since a lab machine is allocated to a user before that user authenticates. So, a malicioius user (even outside of that University) could create a script to request the machines and continue to request more after each login fails, thus locking up all machines permanently. One way to defend against this would be to have the request webpage behind a Cosign authentication screen (limiting requests to people who would actually have the creditials to log into the machines) and to make use of a scheduling daemon that would keep track of which IP had requested a machine. This scheduling daemon could then dynamically create and send an .rdp file to the authenticated user which would temporarily contain valid connection information. This would allow a connection without the need for an ActiveX control (and consequently Internet Explorer and even a machine running Microsoft Windows so Macs users are represented too). We spent time some looking at several of these .rdp files in hopes of automating a login process through the use of the password hash stored in each file. Unfortuantely, the hash is specific to the machine creating the .rdp file (and also the current user logged into that machine) and therefore these files aren't completely portable. The net result is that a user would have to authenticate twice, once to request a machine and once after recieiving the .rdp file with the connection information to the machine to which they are connecting. Less than elegant for sure but a good way to solve security concerns. In an ideal setting, we would also be able to only open up a port on the lab machine for the IP that requested it and only for a set period of time.
There are a lot of questions and concerns that still would have to be answered for a solution like this to work. For example, do we poll the machines to see which ones are being used or do we let them report login and logoffs to the scheduling daemon, or do we do a combination of both? We also need to make sure the scheduling daemon makes atomic updates to its machine use state variables since it would need to be multithreaded to allow for multiple simultaneous incoming machine requests and machine login/logoff update requests. If the scheduling daemon also wrote out to an external database, we could include some interesting usage information updates on the machine request webpage and even update it dynamically through the use of AJAX.
More to come soon.
September 27, 2006
We Have a Wiki!
Today we setup a wiki for use in documenting the project. The URL for the wiki is https://webapps.itcs.umich.edu/vsites/index.php/Main_Page
September 26, 2006
And So It Begins...
This blog is dedicated to the development of the Virtual Sites project. We will be attempting to regularly post blog updates in an effort to document the development process and encourage feedback and discussion through the use of comments. We will also be putting up a wiki with project information and other various resources. Since this project will have applications for many units on campus, it is our goal to bring in as much outside influence as possible and to seek feedback at all times. Please feel free to participate and we welcome your questions and comments. If you wish to contact our group, the email address is firstname.lastname@example.org and there is a joinable mailing list with the address email@example.com. You can get to it by following this link.
The goal of this project is to create a method for remote access of sites resources outside of the physical lab enviornments. Initially we are targeting the availabily of Windows applications with hope to add support for Mac applications in the future. There are a number of approaches to fulfilling this goal and as such we have several options to investigate. To weight the various benefits and limitations of each potential solution we are first attempting to learn more about our lab usage.
We are initally concerned with exploring two facets of lab usage. Those are -
- How the lab machines are used (i.e., which software is most important to the largest demographic)
- When are resources not being utilized to their fullest potential and could therefore be reallocated for inclusion within this project (e.g., when labs are closed during off hours and holidays)
To gain insight into these areas we are currently analyzing statistical information such as lab usage details. Once we understand usage volume we will start planning solutions around that data.