A Sandbox provides a pre-configured development environment that you can run on your laptop computer. The VM version provides a Linux system on which to test the software you are developing in an environment close to what is used in production. Although the Sandbox was originally created for CAS, it can also be used for Shibboleth, Netid, or any other Java Web application. The default user is, however, named "casdev".
If you do not use the Sandbox, you can eventually stumble by trial and error to a workable development environment of your own. Along the way you will have to solve many problems. Does your Java have the unlimited cryptography files and does it have the Yale Certificate Authority files installed? Do you have both a current Maven and the old Maven 2.2.1 that Jenkins runs? Do you have Oracle and SQL Server database drivers installed in JBoss? How do you get JBoss logs to go to /var/log/jbossas/standalone instead of the log directory inside JBoss itself? None of these is a big problem, but these are just randomly chosen examples of the hundreds of small configuration issues you have to address.
The Sandbox is a friendly environment for developers to edit, compile, build, and debug the application. It is specifically not designed to duplicate the runtime configuration of production. For that you have DEV and TEST.
That's not how I do it!
I am not going to waste your time arguing that the Sandbox is the correct way to configure a development system. Everyone has their own opinions, and those who know least about things are sure that their ideas are somehow objectively correct. The Sandbox is therefore a concept and convention rather than any single fixed package. If you insist you can use Ubuntu, Fedora, Centos, Windows, or even Mac as the runtime operating system. In order to accommodate any application, it must be possible to run Java 1.6, 1.7, or 1.8 and any version of JBoss or Tomcat. Applications also can use Spring and any user interface framework.
However, after you struggle to get your first development environment just right, you will be assigned a second application, and then a third. Eventually you will tire of rearranging things to be exactly the way you like them on each new project.
So the Sandbox concept is flexible. If we try to force everyone to use a single approach, then they will hate it and blame all their problems on the tool. Better to let them exhaust themselves making meaningless adjustments and then learn eventually that "good enough" is good enough.
Thanks to Java, you can develop CAS on Windows, then run it on Linux without a problem. Therefore the choice of the OS is only an issue if the application requires a particular library or interface that isn't available on specific systems. GSSAPI, for example, behaves differently on Windows and Linux even though it is a standard Java API.
Different Linux distributions put Java or JBoss or Eclipse in different places, and they may install different versions. Fortunately, the Sandbox must provide exactly the same version of Java that the application is designed to run under, no matter what version of Java a distribution wants to install. That means that the Sandbox provides its own copy of Java, Eclipse, and JBoss separate from any version of the same programs that you installed with an RPM or apt-get. Since this "second copy" of everything has to go in an arbitrary location, we are freed from any dispute about the one true correct place to put things in Linux.
In production, applications run under a Tomcat or JBoss that has been installed as a service and is started (and configured) from /etc or the Windows Registry. In the Sandbox everything is run from Eclipse, and everything is configured in Eclipse and in the Workspace. The Sandbox makes no changes to /etc or the Registry. Of course, this means that JBoss, Tomcat, and the applications all run interactively under the default userid (casdev). This means that casdev has to have write access to any directories used by the application. If you need to validate file access security rules for the userid that runs jboss in production, you have to wait for DEV to test such chings.
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 into some of its configuration data when it is run 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 version.
There may be a different Sandbox for every application, or there may be a Sandbox that combines applications. For example, the Expired Password function runs partly in CAS (on JBoss) and partly in the Netid application (on Tomcat). If you need to test both, then with enough memory you can run two JVMs, but you can also install both JBoss and Tomcat and have both applications in the same Eclipse workspace. Of course, to run both JBoss and Tomcat on the same machine means that only one can be configured to use port 8080 and the other must be configured to a different port number.
Typically applications are debugged without SSL even if they run SSL in production.
Some applications have a custom log4j.xml or Spring configuration XML that references a cache directory or a file path explicitly. In this one type of case it is probably better to arrange the operating system and Sandbox so that the same file path can be used in development and production. Therefore, no matter what version of the OS you use, you will need to make "/var/log/jbossas/standalone" (or R:\var\log\jbossas\standalone in Windows) writable, and maybe owned, by the casdev userid.
Sandbox is not Production
The Sandbox does not have to run at maximum efficiency. It will not be up 24x7 for months, so rock solid reliability and stability are not a requirement.
Therefore, you have more flexibility choosing a VM host, Guest OS, Java runtime, and version of JBoss.
For example, while a particular application will be designed to run in a particular version of Java (1.6, 1.7, or 1.8) it doesn't matter for development if you are using OpenJDK or the Sun JVM. At various times in the past, the OpenJDK has a bad reputation for slow memory leaks that are a long term problem in production, but in development they don't matter.
While production services for some reason refuses to put routine maintenance on their VMs, the Sandbox is typically kept up to date with the latest bug fixes.
To fully exercise every part of an application you may have to install optional libraries in the system. Nominally the Netid application requires the kadmin Kerberos library to run, but it exposes a parameter and if you install it with "kadm5_activation=false" then it doesn't use that library and can even run on Windows. When a particular system service is only marginally important and can be bypassed or mocked out, this is a best practice.
Two "Disks"
The core of the Sandbox is a separate disk image (named "SandboxData") that contains the Java, Eclipse, JBoss, Maven, database drivers, and so on. This disk can be cloned or checkpointed so it can be shared between multiple virtual machines, even with different Linux distributions.
There will generally be a VM and a system disk that comes with a particular Sandbox instance, but it it comes with Fedora and you prefer Ubuntu, then switching the OS generally requires just a small amount of network reconfiguration.
There is a different version of SandboxData for Windows and Linux. Eclipse saves disk letters when it configures directly locations on Windows. Therefore, it is difficult to move the Eclipse workspace between Windows and Linux. It is better to keep the workspace directory for the system you are using but to import new projects into that directory if you want to change the development platform for an application from one OS to the other.
Linux doesn't have disk letters, but there are several different system mount points that have been proposed and replaced through the years for a second disk.
Fedora maintains the original view that Unix is a multi-user operating system and it regards mountable disks as owned by a user (as USB sticks tend to be). So Fedora prefers a very transient mount point and defaults to /run/media/[userid]/SandboxData.
Ubuntu, however, still uses the old model that no matter how many users share the machine, mountable disks are hardware devices like the CD. So it mounts disks as /media/SandboxData.
Of course there are other options, but the fact that two well known distributions make different choices frees us from expecting that there is one right answer to this question. Therefore, the system will put the disk where it wants to, and any further conventions we create will be symlinks to that system mount point.
However, the rule that the Sandbox is absolutely separate from the RPM or apt-get installed versions of the same program would prohibit configuring symlinks so /opt/eclipse points to /media/SandboxData/opt/eclipse. That could collide with the real OS install of Eclipse. So the Sandbox on linux needs a path that works on all systems, and /media/SandboxData seems to be a middle of the road choice. It implies a degree of impermanance (so you can eject one disk and mount a different one if you want to work on a different project) but also a degree of durability (so you can make symlinks to a specific path).
The Sandbox OS may be more current than the production system. Java applications don't care if they run on Windows or Linux, so they clearly don't care about the difference between Centos 7 and Fedora 22. You may find the lastest system features more convenient, or you may prefer the old version of the desktop and hate the changes in the latest version of Gnome.
The SandboxData disk, however, has to make old versions of Java and JBoss available because the applications really do care about those options. If you work on one application at a time, then you may have a SandboxData optimized for just that one application. However, development on CAS sometimes requires changes to Shibboleth and to Netid, and those three applications run on different versions of Java, and while CAS runs on JBoss 6, Shibboleth runs in production on JBoss 5 (although it can run on 6), and Netid requires Tomcat. So you may use a SandboxData disk with all of the versions needed by all of the systems.
The Sandbox system allows to to edit, compile, and debug the program. After debugging, the Sandbox commits source changes back to Subversion. To move those changes even into DEV requires a Jenkins Build job that checks the source out of Subversion, reruns the compile, and stores the JAR or WAR on the Artifactory server. So the only external consequences of the Sandbox development are the source changes in Subversion. Except for that, everything that happens in the Sandbox is private and doesn't matter.
Installation
Conceptually the Sandbox can run on VMWare Player or Hyper-V, but the disk format has to be converted and if you intend to use the supplied OS disks, then their drivers should be updated. Generally speaking, VirtualBox turns out to be the tool everyone points to when they want to convert a virtual hard disk file from one vendor format to another. So you may need to install VirtualBox as a tool even if you want to try to use a different VM host software.
Download and install the current version of Virtualbox from virtualbox.org. Unfortunately, this is a moving target because virtualbox itself is changing and the operating systems it hosts are changing. However, you only need a version that is reasonably stable and has the convenience features you need. It is a hard problem to choose a system for 24x7 production servers with the ability to dynamically migrate them across systems. On desktop machines, it is a hard problem to do 3D video acceleration or play YouTube from the VM. The Sandbox doesn't have any of these problems. It needs to run Eclipse, and that is a fairly simple requirement to meet.
It is possible to put the SandboxData files on your native laptop OS and do without the VM entirely. This is a good choice if you have only one software project that you develop full time. If you have to jump from application to application, then setting up each new application may be too much trouble. So doing the Sandbox on you native laptop is an advanced configuration that you try later, rather than a choice you make initially.
Each Sandbox OS defines a user named "casdev" with admin privileges who is the owner of SandboxData and some other directories on disk. It is an objective that this user have a specific userid number shared on all Unix hosts, so the disk file ownership transfers when the disk is moved from one OS disk to another. If that did not happen, then even though the user is named "casdev" on both systems, the SandboxData disk moved to a new system will appear to be owned by an unknown user and you have to reassign it with the chown command.
Once you have the OS system disk and the SandboxData disk sorted out, there is still a requirement to define the parameters of the VM. You must assign a number of processors, size of memory, type of disk controller, and so on. In VirtualBox this is done with an XML file with an extension of *.vbox.
Virtual Machines are an advanced feature, and people who use them need the ability to specify some advanced options. For example, the host computer can have more than one LAN adapter. One LAN adapter could be connected to the public internet, while the second adapter would be connected to a "lab" network that only includes in one room belonging to your group. When you define a VM, you need to configure its virtual LAN adapter. It could be entirely imaginary and exist only inside your machine, or it could be "connected" to one of the two real LANs. Is it going to be connected to the Internet or to the Lab network? The VirtualBox configuration tool allows you to make the choice.
Now I want to give you a copy of this VM. Your machine may also have two LAN adapters connected to the same two networks, but your machine will not be identical to my original machine. Not only might you have different hardware, but I may be running Windows and you might be running a Mac, so everything has different names. There is no way to create a VirtualBox or any other software that is smart enough on its own to automatically reconfigure the VM. A person is going to have to rename and reconfigure "dangling" devices that on the new machine no longer connect to hardware features that are identical to those on the original machine.
A VirtualBox VM is a directory on disk with an XML configuration file with an extension of *.vbox. You can try to copy the directory from one machine to another, but VirtualBox is not designed to make this easy or reliable. For example, the *.vbox file contains an explicit fully qualified path reference to any *.iso CD/DVD images that were ever used by the machine, even if they are not currently mounted in the drive. Move the VM directory to another computer that does not have an identical *.iso file in the exact same place, and VirtualBox will complain about the VM being broken.
The Sandbox is distributed as a Exported *.ova file. This is an open standard form of zip file that contains both the machine configuration and the disk image. It can be loaded into VirtualBox (or VMWare for that matter) to create the virtual machine. During installation, or any time before you start the VM, you may need to configure features that are potentially dependent on your local machine configuration. VirtualBox has a feature called "Shared Directory" that allows the host operating system to share one of its directories with the VM (like a network share, but implemented without the network). When the distribution was built, the shared directory was "D:\sandbox", but you may want to turn this off (it is a convenience) or change the host directory path, especially if you do not have a D: drive or are not running Windows on your host computer.
You may be asked to reconfigure things that you forgot to change when you start the VM for the first time. For example, on the computer that created the Sandbox there was a specific physical Ethernet adapter with a specific name assigned by Windows. Your computer will also have an Ethernet adapter, but it will have a different name. VirtualBox will ask you when it goes to replace the old name with the local name on your computer. If you only have one LAN adapter it hardly seems necessary, but in theory you could have two LAN adapters and then it would be important to choose the right one.
It is easy to go back and fix things, but do not rush to install the Sandbox image before you have read the rest of these instructions so you know what the configuration means.
casdev
There is one user named "casdev" with admin (sudo) privileges. You login, run Eclipse, and do all your development as this user. The /home/casdev directory holds the Eclipse workspace and all the casual files. Because JBoss is started from Eclipse, it also runs as casdev. Therefore, the JBoss and Eclipse directories are owned by casdev even though they are installed elsewhere in the file system.
The password for user casdev is not particularly secure, since it can only be used by the developer on the host machine. However, it will not be published here. Ask someone for it.
Where
Oracle Java comes in a standard Red Hat distribution format called an "RPM" that contains both the files and instructions where to put them. Oracle puts a JVM in /usr/local/java. Red Hat official RPMs for JBoss are not available without a subscription, and RPMs for Eclipse are typically several releases behind the current verison. So JBoss comes from http://jbossas.jboss.org/downloads.html and Eclipse comes from http://www.eclipse.org/downloads/ and they are unzipped into subdirectories of /opt.
Then ownership of the directories is assigned to the "casdev" user instead of "root". JBoss contains configuration files and it writes to work directories that are part of the single distribution directory tree, and Eclipse has to change itself whenever you add new software. Eclipse and JBoss could have been put in the casdev HOME directory, but putting them in /opt seems cleaner. They are not, after all, part of your normal development workfiles. The Eclipse workspace that you are using goes in the casdev home.
There are a few things that have to go in the same place in the Sandbox and production. For example, the log files should be written to /var/log/jbossas on the Sandbox because that is where they go in production and that specific path has to go into log4j.xml. The JBoss Server configuration in Eclipse is modified to add -Djboss.server.log.dir=... onto the end of the JBoss start command.
The VM
The VM is a standard Virtualbox 64 bit Linux configuration. With JBoss running the used memory only gos up to 1.3 GB, so the amount of virtual RAM for the VM could be reduced to 1.5 or 2 GB if you need to run two VMs on an 8G laptop.
The VirtualBox Guest Additions are a set of drivers for the VM operating systems. These mouse, keyboard, video, and filesystem drivers support the integration of the VM interactive environment with the host system. For Linux, the Guest Additions are distributed in source and are compiled and then linked into the system. The source of the Guest Additions changes when you get a new version of VirtualBox, and the Additions have to be recompiled and installed every time the Linux Kernel changes, which happens frequently after you apply normal weekly maintenance to the Linux system. If you have made a change that breaks the Guest Additions then the VM window shrinks to a fixed size and the mouse gets captured when you click in the window and can only be detached from the VM by pressing the right Ctrl key. When this happens, click the outside (VirtualBox) menu item Devices - Insert Guest Additions CD. Inside the VM window you get a popup asking if you want to autorun the software on the CD that was just inserted. Click the "Run" button and let the Guest Additions rebuild.
It is not generally possible to drag and drop files between the Linux and Windows systems. Of course, you can use network file sharing between the machines, but there is a simpler solution. VirtualBox provides a feature called "Shared Folder". In the settings for the VM, there is a section for Shared Folder. You can designate one or more directories on the host computer (D:\sandbox is configured initially for the Sandbox VM). This directory is then given a name ("sandbox" for D:\sandbox). The shared host folder appears to the VM to be a virtual disk or virtual shared disk that can be mounted in Linux or assigned a disk letter (if you have a Windows VM). For Linux VMs, the shared folder is automatically mounted (because of the check box in the VM settings) to the location /media/sf_[name] (that is, /media/sf_sandbox for the name "sandbox"). The casdev user has been added to a group that allows read/write access to the files in the shared folder. This allows easy transfer of files between the VM and the host (Windows?) operating system. Copy files to or from C:\sandbox on the one end, and to or from /media/sf_sandbox on the other end.
The Virtual Network
Each VM has a virtual LAN adapter. VirtualBox can be configured to support this virtual adapter in several different ways. This is the most complicated step in the Sandbox configuration and needs to be understood, at least in basic terms, so the developer knows how to interpret behavior.
First, we need to define a few network terms. Suppose you have several real computers that you are connecting together in a home network. If you wire them to each other through a switch but you do not connect them to any router, then you have a Private Network. The machines can talk to each other but not to the outside world. You can assign each machine a static IP address, and for home networks this is traditionally a 192.168.1.* number. Of course this is the most secure arrangement, but it is not very useful.
So you get a DSL connection from the phone company or a cable connection from you TV provider, and you connect it these days to a Wireless Router box. Home routers add two network functions: DHCP and NAT. DHCP assigns addresses (from the 192.168.1.* subnet) to machines that are not configured to use a specific private address. NAT allows the router to forward client requests from any computer on the private network to the internet, but it changes the IP address on each packet of data so that the outside world thinks the request came from the router itself. This is important because the phone or cable company only assigned one IP address to your home, and the router has to own and manage that address.
NAT works automatically when the home computer is a client and the server is out on the internet. To allow Internet machines to connect back to a computer in your home network, then you have to configure the "Port Mapping" feature of the router to direct all Internet requests for a particular port (example: 8080) to a particular home computer.
Your host computer may be a laptop connected to the Yale network, but the VMs that it runs under VirtualBox are typically unknown to Yale and you probably want them to be unavailable to other machines. So VirtualBox creates various virtual network solutions emulating different elements of the typical home network solution.
When you create a VM and give it a virtual LAN adapter, you can configure the connectivity of that adapter to use specific named options:
- NAT - One VM appears to be connected to its own network with a NAT router simulated on the host real machine. Client programs on the VM can access the Yale network and Internet, but neither the host computer nor the other VMs can talk to that VM except through ports mapped from the VM to the host computer. If you map ports, they become visible to the outside world.
- NAT Network - Several VMs are connected to a private network with a NAT router simulated on the host real machine. Like the previous configuration, except in this case the VMs can talk to each other as if they were real computers on a real network, but the host computer still can't talk to them.
- Bridge - All the VMs appear to be directly connected to the real network to which the host computer is connected. At Yale, that means that every VM has to be assigned its own IP address from Data Network Operations. Since that address is real, no other developer can use the same set of addresses for his Sandbox machines. This also exposes the VMs to the outside world (at least the Yale network). This option is useless for a sandbox.
- Host-Only Adapter - First, this creates a virtual LAN adapter on the host computer (you get a dialog box on Windows asking you to install a new device). Then logically it connects this simulated LAN adapter to a Private Network to which all the VMs are connected. Typically you assign a static address like 192.168.137.1 to the host computer and then other static addresses like 192.168.137.10 to each VM. VirtualBox does not provide any NAT router function, so this private network is isolated from the real network.
Now for Sandbox requirements: The VMs have to be able to communicate with each other just like real machines, so they can test various clustering options. The VMs have to access servers in the Yale Network (SVN for example to update or commit source changes). For security, other machines must not be able to access the VMs. It is useful, but not an absolute requirement, for the host computer to be able to connect to port 8080 (JBoss) on the VM.
It is possible to meet all these requirements with a Host-Only adapter and an exotic system configuration or third party software on the host computer. However, the simplest solution is to recognize that while one virtual LAN adapter cannot do all these things, two different adapters can provide complete coverage.
One adapter (that VirtualBox refers to as LAN Adapter 2 and Centos chooses to name "enp0s8") uses a simple "NAT" connection to give VM clients access to the Yale network (SVN) and to the Internet (the Centos software update sites). You map no ports, so this provides only outbound service. It is automatically assigned a meaningless IP address that doesn't matter because no other computer can talk to it.
The other adapter (that VirtualBox refers to as LAN Adapter 1 and Centos chooses to name "enp0s3") is a Host-Only Adapter that creates a simulated Private Network that connects the VMs to each other and to the Host computer. It is not connected, routed, or bridged to Yale or the Internet, so it cannot be used to access other machines and no computer other than the host or the VMs can use it. The host and VMs are assigned static 192.168.*.* addresses to talk to each other just like real computers connected to a regular private home network. Since these addresses are not typically available
NAT is part of VirtualBox and requires no configuration. However, a Host-Only network has to be set up before any VM can use it. In the VirtualBox management console (that lists the installed virtual machines). Click File - Preferences - Network. Select the Host-only Networks tab. If no network is listed, click the Add button to create one. It will be called "VirtualBox Host-Only Ethernet Adapter" and when you create it you have to let your real laptop operating system add a new device. If you double click the now listed adapter, you can set its IPv4 Address to 192.168.137.1 and the Network mask to 255.255.255.0. It does not need a DHCP server because static addresses are configured in the VMs.
If you run Windows as the host computer, there is one additional cleanup step. When VirtualBox create a new simulated LAN Adapter in the Windows system, it left all the default configuration options. Go to Control Panel - Netowrk and Internet - Network Connections. Right click the VirtualBox Host-Only Network connection and choose Properties. DoubleClick the "Internet Protocol Version 4" item in the list box. Click the Advanced... button, choose the DNS tab, and turn off the checkbox at the bottom for "Register this connection's addresses in DNS". If you do not do this, then when you login to the Yale AD, your Windows desktop tries to register the 192.168.137.1 private address on this adapter with the dynamic DNS service that AD maintains. It probably will not cause a problem, but if another computer at Yale (frequently another machine you own) also has a private virtual network mapped to 192.168.137.* then from that DNS name that computer can believe that your computer is a VM on its private network, and then become unable to communicate with your machine because the two private networks are not connected. You can spend hours trying to figure out why you cannot share files or start a remote desktop session before you realize that your network traffic is going into the private network black hole instead of transiting the real network.
The Sandbox VM comes configured with two virtual LAN adapters (NAT and Host-Only). The Sandbox OS is configured with three adapters (NAT and two alternate versions of Host-Only to easily configure two VMs from one system image). It uses the NAT adapter to get to the outside world. You configure one of two Ethernet hardware (MAC) addresses with the VirtualBox console, and which hardware address comes up tells the Sandbox if it is the vm-ssoboxapp-01 host with private IP address 192.168.137.10, or the "-02" host with IP address ending in ".11".
The open format distribution file (the *.ova file you install the Sandbox VM with) sort of knows that there are supposed to be two virtual LAN adapters and it sort of knows that one is to be NAT and one is to be Host-Only. There is an obvious conflict between an "open format" file that can be read by VirtualBox or VMware and configuration options like "Host-Only" that may be a VirtualBox technical term that other vendors name differently. So when you install the *.ova file, VirtualBox displays the proposed hardware configuration and gives you a chance to explicitly connect any dangling configuration items to specific local chocices. For example, if you did not follow the previous instructions and did not create the Host-Only adapter on the host computer, then there would be no Host-Only adapter to connect the Sandbox VM to, and then one of the two LAN adapters is left with nothing it can connect to. If you do not fix the configuration problem at the start of installation, you can always fix it later before you start the VM.
If you need to simulate a second VM, clone the Sandbox computer (as explained below) and then in the clone configuration you leave Adapter 1 attached to the same Host-only Adapter but now you expose the Advanced options and change the MAC Address to be one larger (change AD at the end to AE).
The Centos operating system in the Sandbox VM has two different configurations for two different LAN adapters with different MAC addresses. It selects which IP address it uses based on which MAC address the simulated LAN adapter exposes. The first VM (ending in AD) gets 192.168.137.10 and the second (AE) gets .11. However, it is not possible to automatically change the hostname based simply on the MAC address. You have to do that manually the first time you boot up the cloned second VM. Issue the following command once:
sudo hostnamectl set-hostname vm-ssoboxapp-02.web.yale.internal
to change the hostname permanently on that VM.
However, while each machine has to know its own name, it also has to be able to locate the other machine in the "cluster". In production this is accomplished through the DNS server. Fortunately, all systems support a simple static alternative called a "hosts" file. This file is /etc/hosts on Linux or Mac, and C:\windows\system32\drivers\etc\hosts on Windows. It is a simple text file where each line starts with an IP address and then contains one or more host names associated with that address. The VM has a hosts file with two lines:
192.168.137.10 vm-ssoboxapp-01.web.yale.internal casvm1
192.168.137.11 vm-ssoboxapp-02.web.yale.internal casvm2
This maps the full name and a shorter nickname (casvmx) that is easier to type. You should add these lines to the "hosts" file on your host (Windows or Mac) computer so that you can access the VMs by name through the Host-Only adapter.
CAS currently has only two VMs. If that changes, or you want to use the Sandbox to work with a different product that has a different cluster configuration with more machines, then you can follow the cookie cutter instructions and add additional Network adapter configurations in /etc/sysconfig/network-scripts and add an extra line to all the hosts files.
Centos 7 has a Firewall service (firewalld) that, like the Windows firewall service, provides some protection to a desktop or server machine. It is not used in production machines behind the corporate firewall, and similarly it is not useful on VMs that are hidden on the Host-Only private virtual network, so that service is disabled in the Sandbox. It you want to turn it back on, you have to configure it for JBoss and the clustering.
Clone
The Sandbox VM can be cloned to produce a second CAS VM for testing cluster failover.
Cloning is a VirtualBox operation performed on the VirtualBox control window. Select the machine and choose Clone from the Machine menu. There are two kinds of Clones:
A Full Clone makes a complete copy of the VM configuration and the hard disk. This is the simplest option, but it takes a few minutes to make a second copy of the hard drive file
A Linked Clone is much faster and smaller. It creates a "snapshot" of the current hard drive file (an image of the disk that does not change and can be shared between the original VM and the Clone. Then the two VMs each get a new file that holds only the changes made to the hard disk since the snapshot was taken. Once the snapshot is taken, any files that are changed, for example changes to the source files in the Eclipse workspace, are separate on the original and clone VM and so they have to be copied from one to the other. You can commit changes to SVN and then update the files on the other VM, but after a while that gets to be annoying. If you make a lot of changes, do it on the original VM, discard the old clone and make a new one. It only takes a few seconds to create a Linked Clone.
After you delete a Linked Clone you may want to take a few seconds more and delete the disk snapshot that was created for it. That merges the changes back into a single disk image file.
There are two steps that you must perform after you create the Clone to distinguish it on the network from the original VM. Before you start the Clone VM, edit the Settings - Network - Advanced - MAC address changing the last byte of the address by adding 1 (change the "AD" at the end to "AE"). Then after the clone starts up for the first time, issue the command "sudo hostnamectl set-hostname vm-ssoboxapp-02.web.yale.internal" to change the hostname. After you do this a few times it will become routine and deleting the old Clone, creating a new one, updating the MAC address, and changing the hostname will take only a few minutes and is much simpler and faster than copying files from one machine to the other.
CAS Development
CAS development is the same whether you are working on a Windows host computer (with Eclipse and JBoss) or on the Sandbox VM. You edit in Eclipse, build with Maven, and run JBoss from the Eclipse toolbar. Generic CAS develpment is described elsewhere. This section just describes the Sandbox.
When you get a new copy of the Sanbox VM, the casdev user will have an Eclipse workspace in its home directory. This will have a project for the CAS source and for the CAS installer. However, the project may have old files. So the first step is to synchronize the workspace with the SVN server and update the files with whatever is current.
If you are starting work on a whole new release of CAS, then delete the old project and create a new project using the instructions provided in CAS Development Conventions at Yale.
There are two configured Maven "jobs" in the Eclipse Run - Run Configurations...
If you click the dropdown mark (V) behind the Run icon on the toolbar (a green circle with a right pointing triangle) then there is a CAS Build job (which runs the Maven POM in the CAS parent directory to compile everything and build the CAS WAR) and a CAS Install job (which copies the CAS WAR to the JBoss deploy directory and inserts parameters into the configuration files). Run the Build first, then the Install.
Elsewhere on the toolbar there are JBoss Run and Debug icons (a green arrow pointing right and a bug with an arrow under it). They can be used to start JBoss normally or with interactive debugging using Eclipse.
Changing the Sandbox
The Sandbox is separate from the contents of the projects in the workspace or the SVN. You could use the same Sanbox to develop with CAS 3.5.3 or CAS 4.0, and you could probably use it to develop any JBoss hosted application including Shibboleth.
Updating Centos 7 with newer versions of software or changing system configuration options is just standard Linux system administration.
Therefore, changing the Sandbox means installing a different version of Java, JBoss, or Eclipse.
You can install any version of Java using the Oracle RPMs. They go automatically into /usr/java. Generally you configure different versions of Java into Eclipse (Preferences - Java - Java Runtime) and then you select the verison of Java you want to target as a parameter of the Eclipse project, or as a parameter of the CAS Build and CAS Install Run configurations, or as a parameter of the JBoss Server runtime configuration. If you want to change the default version of Java that you get at the command prompt, Google for information on the Linux "alternatives" command.
There are separate instructions in this set of documentation for starting with a vanilla version of Eclipse and then adding the Subversive and JBoss Tools components, so they will not be repeated here.
To install a new version of JBoss, get it from jboss.org and unzip it into a new directory in /opt/jboss. JBoss Tools will configure it automatically if you ask. In Eclipse, go to Preferences - JBoss Tools, JBoss Runtime Detection. Click Search ... and have it search /opt/jboss. It will notice the new server and configure it. To change the default configuration, you need to display the Servers (Window - Show View - Servers). The Servers tab lists all the configured servers. Double click on the name of the server you want to configure. Click the "Open launch configuration" link for detailed startup configuration. In particular, you may want to allow browsers on other machines (actually only on the host computer) to access http://vm-ssoboxapp-01/cas by binding JBoss to the LAN adapter instead of just the local loopback. In the command parameters, change "-b localhost" to "-b 0.0.0.0". Also add a parameter to change the log directory "-Djboss.server.log.dir=/var/log/jbossas/standalone". If in doubt, compare this to the configuration of another JBoss server.
Disclaimer: configuring modern versions of JBoss AS 7, JBoss EAP 6.x, and Wildfly 8.x are all fairly similar. If you want to configure an older JBoss 5, that changes the entire directory structure and conventions and may require extra research.