- The Cerberus Project
- Introduction
- 1. Chapter 0 - Pitch and Abstract
- 2. Chapter 1 - Pitch and Summer Work
- 3. Chapter 2 - Fall 2014 Work
- 4. Chapter 3 - Spring 2015 Work
- 5. Chapter 4 - Architecture Software, Dependencies and Provisioning
- 6. Chapter 5 - Current Hardware Configurations
- 7. Chapter 6 - Monitoring the Cluster
- 8. Chapter 7 - Current Limitations of the Project
- 9. Chapter 8 - Utilizing the Cerberus Program
- 10. Chapter 9 - Performance of the Project
- 11. Chapter 10 - Final Results and Special Thanks
Executing the Cerberus Program
All of Cerberus is hosted via distributed GitHub repository. This means that once security tokens have been granted and Cerberus has been installed on the cluster, running it is as easy as cloning the head directory to gain access to the executable files.
Using Git, the operator clone , can be used to copy all of the files to a local directory. By default, this is stored in /home/$USER/. Git can clone files to anywhere, so long as git clone is executed from the current working directory.
So long as the cluster is properly configured, once cloning is complete, the Cerberus directory can be accessed and run from the shell command line. The command can also be added to the $PATH as it is on the example server configuration. Initialization scripts are used to accomplish this on the standard, production server stack install edition.
Running /cerberus/4k_cerberus.sh will kick off the program, delivering this graphic to the shell being currently used.
The number of nodes here is smaller compared to the current server pool. The images is being used purely for demonstration stake.
Running the Program
The Cerberus conversion software initially relies heavily on user input. Once the program is started in the terminal, the program will ask for the RIT DCE login of the user. Enter the three letter and four number combination and then the program will begin and spawn a user menu.
It is important to note that authentication is currently not a feature. There is no reason to authenticate the system due to its design implementation. The system itself is closed loop and solely admin accessible. As long as a user has the physical access to the server stack (not a requirement for admin users) there is no reason to lock the system down by requiring LDAP or AD authentication.
The feature of user authentication is set for final release but is most likely going to authenticate via Kerberos or another non-Windows client method. For now, however, requiring the RIT DCE of the desired user simply allows the program to set up a correct directory structure for each user.
It is important to note that once all of the correct flags are added by the user, the software will then continue to run autonomously until finished. Each menu function is covered later in this chapter and in great detail.