Beginning Development Once more

It has been almost a year since we started this project and for the last 9 months I began work on another project called Briefcase. But now that the summer is almost here again development will begin once more. Many of the bugs that existed in the last version will be fixed and we will start writing more default plugins for you to use. Possibly also create a create a compiled version of the python plugins so that they are less noticed in the overall system. I have learned a lot since I last worked on this project and there are many things to fix and make better. Gabe will be going off to work for Hasbro soon so a new person, James Kalfas, will be joining me on the fronted development. This will be fun, I am looking forward to developing this application once more.

– Asher


Creating Secure Connections

One of the main focuses of Olympus is to be able to access any number of computers securely. To do this we will be using a RSA style key-pair to securely send and receive data between client and server. The source server has a list of all of the remote server’s public keys (the pubkeys are also used a unique identifiers to make each computer unique, independent of its IP address). When a new computer is added to the list the new remote computer will send its public key over to the source server. The sys-admin can then use a fingerprint to make sure that the key is correct, thus creating another secure connection. The communication between the web client and the source server will eventually be an ssl connection however for now we are still working out a few bugs with the encryption method and the certificates.

Saving configurations using the filesystem

Olympus is meant to be loaded in parts, allowing for many queries to be made to it at once without noticeable delay. This is achieved by having each element of a the configuration, for example a list of servers, stored using the file system instead of a configuration file. This allows us to load each individual file about the server without having to load the entire set of information about every server. As a result this will allow for the program to be completely scalable to hundreds or thousands of servers without slowing down the program much on runtime, though we are not able to test more then ten at this point in time. Another benefit of this system is that if a system admin wanted to copy a server configuration from one Olympus program to another it would be a simple matter of copying a file or folder over, and would not require any kind of configuration change within Olympus. If you wanted to write a program that messes with the configurations of servers or plug-ins it would be a simple manner of changing the contents of the files, though that it not thread safe yet.

To maintain file integrity and avoid serious race conditions the process of writing to these files is contained in a single core while the process of reading from these files is un-restricted. In the future this method will change to allow for multiple files to be written to at once without fear of corruption. This will be done using file write locks to prevent a file from being opened twice.

Thats all for now

Writing Our Own Webserver Cont.

After much effort and debugging the UNIX (POSIX) version of the webserver is finally bug free enough to consistently send data across. As it is configured now you can only access the server if you are on the same network as it. This is to help against intruders accessing your file system. This will soon change so that anyone can access the server as long as they have the IP address but they will be restricted to a user defined root directory, from which they will not be able to escape (mwhahaha). After testing the first build of the webserver it was noticed that some of the files had large chunks missing from them.

The standard way to send data over an estabished socket connection is through the send() function
ssize_t send(int sockfd, const void *buf, size_t len, int flags);
When the server was first constructed I assumed that this function would send all the data you tell it to, however it does not. After much research it was figured out how to force the code to send all the data. The third version of the protocol finally worked and we are now able to send the required data flawlessly. The program currently uses the unix only fork() function and will eventually need to be rewritten for the windows build. Until then more plugins will be develped

Writing Our Own Webserver

In order to serve the live data from the remote computers to the client computer we needed to write at least part of our own web server to handle the AJAX requests for plug-in data. After writing a few dummy scripts, checking what out kind of input we will need to handle, it became very simple to handle and return data to the client computer. I wrote a C/C++ backed to handle the Ajax requests and send data back to the client computer. A port in bound on the computer then the program waits for a client to connect to it, initiating the AJAX query. After the web browser sends data to the server it is parsed and the actual request is separated from the meta-data. After the request is parsed, the server looks up the information and sends it back to the client in whatever format the data is needed in, not just HTML.

Interfacing between the Web UI and the root server

After much research into different methods of updating the UI as if it were live, we came up with three different methods of communication. The first method we found was WebSockets, which allows you to send data over a single socket. This would allow us to send all the data we needed to the user’s web browser without much trouble. The only problem is that WebSockets is not fully compatible with every web browser. Firefox 4 and Opera 11 have disabled this feature in fear of an exploit. Chrome 4 and Safari 5 continue to use the feature but appear to be planing to disable the feature if actual exploit code is developed. Until this protocol is revised it does not seem like a smart idea to write our program relying on a feature that will most likely not be enabled. From there the next idea was to build a plug in for all the major web browsers which would basically create a socket and pretended the web browser had WebSockets. The problem with this approach is that we would need to design plug ins for each web browser. While building web browser plug ins is an acceptable option, the simplistic option is to use rapid AJAX requests. This idea came from the APE (Ajax Push Engine), however instead of using APE we will be incorporating the feature into our program, allowing the user an easier time configuring their program.

How plug-ins work

There are three parts to a plug-in. The first part is the code that will run on the remote machine. This code can access any part of the machine it is running on and send data back to the root server through standardized library functions. The second part is the root server code. This will be a custom language used simply to parse what is sent to it by the remote machines and send it to the user(s). It runs on top of pre-developed code that handles all the connections using black box functions. Finally there is the Web GUI. This will consist group of HTML objects for the user to use that each display information parsed by the root server code. For now we are going to create a group of object templates. These templates include a pie chart, text box, progress bar, and a line graph. Later there will be other templates that can be used to communicate back to the server; the first will be a text box that will allow you to send messages back.

What is Olympus?

The Olympus server management system will be a program that is able to monitor remote servers, similar to any other server management program. However unlike other server management programs it will be completely based around plug-ins. These plug-ins can modify how a remote server is monitored an how the user or admin can access or control the server. All of the functionality of the program will be in the form of plug-ins, including the basic server information like processor usage. The only monitored aspects of the computer that will not be a plug-in is the current power state of the computer (On or off / disconnected) and the IP address of the machine.