...
Yale tends to use the Oracle Virtualbox software to create desktop VMs. This software is easy to install, perfectly adequate for the purpose, and is relatively friendly and easy to use. However, a virtual machine image should not be strongly dependent on the hypervisor, and any use we make of Virtualbox specific features is only to achieve extra convenience and not to perform any tasks essential to the Sandbox. So if you have a Windows machine with Hyper-V installed and used for other projects, then you can certainly adapt the Sandbox VM to run under that host environment.
Generally speaking the Sandbox VM environment involves choosing two separate components.
- You need an OS VM. Typically it will run CentOS, Fedora, or Unbuntu. You can just pick up the OS configuration last used for the software you are planning to develop, or you can choose one specific OS VM to use for all your development and customize it to your preferences.
- You need the SandboxData disk/directory-tree for the particular software package you are planning to work on . By separating out the CAS project files on one virtual disk, and the Netid project files on another virtual disk, you can keep the same OS VM with your customizations and switch from one software development project to another by switching mounted disks.
Different Linux distributions put the same component in different directory locations. There is no single correct place to install a program, and if you decide to use your own customized environment to perform the Sandbox development function you may have already installed some of the same programs in the location you prefer. The only safe thing is for the Sandbox to provide all its own copies of every program on which it depends and to put all this stuff in a separate location that cannot possibly conflict with any default "system" version of the same code. So the Sandbox is packaged as a separate small self contained virtual disk drive that you mount as an additional disk on a base operating systemDifferent Linux distributions put the same component in different directory locations. There is no single correct place to install a program, and if you decide to use your own customized environment to perform the Sandbox development function you may have already installed some of the same programs in the location you prefer. The only safe thing is for the Sandbox to provide all its own copies of every program on which it depends and to put all this stuff in a separate location that cannot possibly conflict with any default "system" version of the same code. So the Sandbox is packaged as a separate small self contained virtual disk drive that you mount as an additional disk on a base operating system.
Generally speaking the Sandbox VM environment involves choosing two separate components.
- You need an OS VM. Typically it will run CentOS, Fedora, or Unbuntu. You can just pick up the OS configuration last used for the software you are planning to develop, or you can choose one specific OS VM to use for all your development and customize it to your preferences.
- You need the SandboxData disk/directory-tree for the particular software package you are planning to work on . By separating out the CAS project files on one virtual disk, and the Netid project files on another virtual disk, you can keep the same OS VM with your customizations and switch from one software development project to another by switching mounted disks.
In the operating system servers are configured in /etc or the registry, but in the Sandbox they are configured you configure every Java Runtime, every JBoss or Tomcat server, and every Maven instance in Eclipse. In the system they Java and JBoss are started at as background processes at boot as servicestime, but in the Sandbox they are started and debugged by Eclipse. There would be a conflict if the real operating system starts the standard version of a server up on a standard port and the Sandbox disk is configured to use the same port. Then you have to change either the system or the sandbox to address the conflict. Otherwise the Sandbox does not know or care what version of Java or Eclipse or JBoss you have configured in the system because the Sandbox starts its own copy with the right version from its own directories.
If you need to develop two different Yale applications at the same time (CAS and Netid depend on each other for password change functions) then each may use a different version of Java and different Application Servers (CAS uses JBoss and Netid uses Tomcat) A Sandbox configured for this development may have two Java Runtimes and both JBoss and Tomcat in side by side subdirectories of the same parent directory. However, the basic directory structure of all Sandbox disks is the same and once you learn it you know where JBoss is going to be stored even if, from one application to another, it may be a different version number of JBoss in each Sandbox.
No application ever depends on the Eclipse that built it, so if the Sandbox contains Eclipse Luna (4.4) and you want to upgrade it to Mars (4.5), then that should always work.
In production JBoss runs under its own userid (typically "jboss" or "jbossa") that owns its own directories. In the Sandbox all the files used by Eclipse, the applications, the application servers, or anything else unrelated to the system are owned by the user "casdev" who is Linux user number 1001. This means the Sandbox cannot debug disk permission problems that will show up only in DEV. You can wait until you get to DEV to find and fix them. Since the application runs under JBoss that runs under Eclipse that is running as an interactive application, that whole process tree has to run as the logged in user.
It would be great if there was only one set of Sandbox files for all operating systems. Unfortunately, Eclipse tends to automatically insert a disk letter when it configures the path to JAR libraries on Windows. So an Eclipse Workspace has to be reconfigured when you move it between Linux and Windows. In addition, executable programs like java and javac are different on different systems (and different between 32 bit and 64 bit versions of the same system). So the Sandbox has identical directory structures and equivalent configurations, but there is generally a Windows version separate from the Java versionyour run Maven or start JBoss in debugging mode by clicking the task bar in Eclipse. Not only does the Sandbox not need the server installed in /etc/init.d, but if the server started up in the background there would be a conflict when you try to debug it using the same port number. So the Sandbox does not use the standard directories for Java or JBoss, and generally works better if they are not installed at all from the point of view of the OS package manager.
You can install more than one version of Java, because you can configure more than one Java Runtime to Eclipse. You can also configure more than one JBoss and also a Tomcat server. This allows you to run develop code that runs in part in two different applications. The Expired Password function has a component that runs in CAS on JBoss and a second component that runs in the Netid application under Tomcat. You can combine the two applications in a SandboxData disk, although with enough memory you can also run two Sandbox VM machines on the same host machine.
There is a generic developer userid named "casdev" (because the Sandbox was first created for CAS, but it can be used for any application). This user must be configured to the OS as Linux user 1001 because that is the owner of all the directories in every SandboxData disk. The Sandbox OS is typically configured to log this userid in when you boot the VM. Typically the developer starts Eclipse and then everything is managed and started from Eclipse as part of this interactive login. So everything runs under the "casdev" user, and that user must have read and write access to the small number of OS directories that may be used during execution (specific subdirectories of /var/log and /media for example). Any directory permission problems will not show up until you run the code in DEV, but that is typically soon enough to deal with them.
The Sandbox approach can also be used with Windows, but Windows cannot share the same SandboxData directory tree. For one thing, there are executable programs in every Java Runtime and in an Eclipse directory, and these programs are system specific. Unfortunately, Eclipse also inserts a disk letter when you configured a file path in Windows but does not insert a letter when you make the same configuration in Linux. So an Eclipse workspace directory ends up being system specific even when all the files are relative and they are all moved as a directory tree from one system to the other. So there is a separate SandboxData for Windows whenever development can be done on either system.
Typically applications are debugged without SSL even if they run SSL in production.
...